OpenStack监控：Monasca的性能改进

最新推荐文章于 2024-08-07 10:17:12 发布

新钛云服

最新推荐文章于 2024-08-07 10:17:12 发布

阅读量869

点赞数

本文链接：https://blog.csdn.net/NewTyun/article/details/105985614

版权

在StackHPC，我们使用Kolla-Ansible部署Monasca，这是一种与OpenStack集成的多租户监控即服务解决方案，允许用户将InfluxDB部署为时间序列数据库。由于该数据库会随着时间的推移被无限期的数据填满，因此数据库的响应时间将与最初部署时的响应时间不同就不足为奇了。我们的客户在生产中对Monasca的长期运行需要采取积极主动的方法，以保持监视和日志记录服务保持最佳运行状态。为此，我们看到的问题与查询性能有关，这直接影响了我们的客户和其他Monasca用户。在本文中，我们将讲述一个有关如何克服这些问题的故事，并介绍一种可选的将Monasca的每个租户数据库功能推向上游能力，以使我们的客户和更广泛的OpenStack社区受益，他们可能正在应对类似的大规模监控挑战。

大规模监控的挑战

我们的问题始于以下各点（但从某种意义上说，它们都是OpenStack部署集群不断增长后同时会发生），同时引起我们注意：

当用户在Monasca Grafana仪表板（使用Monasca作为数据源）上查看收集的指标时，其目的是动态获取主机名列表。该查询不考虑可以在仪表板上选择的时间范围，而是扫描整个数据库的结果。自然，当数据库较小时，这一点不会引起注意，但是随着收集的指标的基数随时间增长（一个站点上的峰值为3.45亿，即3.45亿个唯一的时间序列），这个查询的持续时间在最终超时之前需要一个小时。同时，它会阻塞其他查询的资源。
来自新OpenStack项目的用户将与来自另一个具有更大度量存储库的项目的用户一样，在针对Monasca API的查询时间上经历相同的延迟。这是因为Monasca当前默认情况下实现了一个InfluxDB数据库，并且使用WHERE语句对项目范围的指标进行了过滤。这是一个明显的瓶颈。
最后但并非最不重要的一点是，所有收集的指标都遵循相同的保留策略。InfluxDB支持每个数据库多个保留策略。为了进一步隔离，还可以为每个租户建立一个数据库，每个数据库都有自己的默认保留策略。这不仅增加了项目的可移植性，而且还消除了每次执行查询时按项目过滤结果的开销，自然提高了性能。

为了解决这些问题，我们实施了以下快速修复，尽管它们可以在短期内缓解症状，但我们将不认为它们是可持续的或可扩展的解决方案，因为它们很快将需要进一步的手动干预：

通过提供主机名的static inventory来禁用动态主机名查找（对于静态项目，可以在部署时自动进行查找）。但是，对于dynamic inventories，此方法依赖于inventory的手动更新。
删除具有高度可变维度的监控指标，这些指标不成比例地增加了数据库基数（基数越大，influxdb的查询时间就越长，尽管其他时间序列数据库（如TimescaleDB）声称不受类似方式的影响）。许多度量标准来源公开了具有高度可变维度的度量标准，避免这是一个本身上的难题，而不仅仅局限于Monasca。例如，像cAdvisor这样的在默认情况下公开了许多维度高度可变的指标，因此必须谨慎判断要选取哪些指标。在我们基于Kolla Ansible的部署中，可轻易实现的主要是与源自OpenStack控制平面的regex模式*.log日志相匹配的指标，该控制平面可用于触发警报，然后用于审计有限的时间范围。但是，由于所有数据当前都存储在同一数据库和保留策略下（因为Monasca API当前没有设置每个项目保留策略的方法），因此无法定义特定于项目的数据到期日期。例如，通过删除这些日志度量，我们能够将3.45亿个唯一的时间序列减少到仅为22.7万个，仅为原始时间序列的0.07%（以每小时700万个序列的速度删除，总共49小时）。同样，在另一个网站上，我们可以从200万个系列减少到18.6万个，是原来的9%（以每小时29000个系列的速度删除77个小时）。在这两种情况下，我们都设法将查询时间从查询超时的状态显著缩短到几秒。然而，使用每个租约的数据库并对保留期进行精细控制仍然是提供持续性能的最佳方法。

性能提升

我们的多管齐下的方法，使监测堆栈更具性能和弹性，可以总结如下：

我们改善这种情况的第一部分工作是向Monasca引入每租户数据库特性。影响monasca-{api，persister}项目的启用补丁现在已经在上游合并，可以从OpenStack Train release获得。这为使用每个租户的influxdb实例进一步分离租户之间的数据库后端铺平了道路。总之，这些更改使最终用户能够：
- 通过在monasca-{api，persister}配置文件中将db_per_tenant设置为True，为单个influxdb实例中的租户启用数据库。
- 通过在monasca-persister配置文件中定义default_retention_hours来设置默认保留策略。该线程的进一步开发将涉及使项目所有者能够通过API设置其租期的保留策略。
- 使用我们高效迁移工具，将现有的整体数据库迁移到每个租户模型的数据库。
我们还引入了实验性更改，以将搜索结果限制为在Grafana仪表板上选择的查询时间窗口。跨越多个项目（monasca- {api，grafana-datasource，tempest-plugin}）的所需更改已全部合并到上游，也可以从Openstack Train版本中获得。因为以前唯一的选择是搜索整个数据库，所以针对大型数据库的查询是超时的，现在可以避免。这种方法唯一需要注意的是，结果是近似的，即返回结果的准确性取决于shardGroupDuration的长度。当保留政策为无限时，默认情况下，该时间解析为1周。如果保留策略为2周，则默认为1天。考虑到较早的行为是扫描整个数据库，尽管精度损失很小，但这种方法仍带来了很大的改进。

这些附加功能使我们能够在一年保留策略的100多个节点的大型部署中进一步将查询时间减少到不到一秒；与没有任何时间限制的查询相比，这是一个巨大的改进，因为我们的用户经常遇到查询超时。此外，我们还为管理不同租户生成和使用的数据的生命周期提供了更可持续的方法。例如，这允许控制平面日志的租赁具有较短的保留期限。

完善的迁移策略

希望从我们目前讨论的功能中获益的现有生产环境也可能希望将其现有的单片数据库迁移到每个租户的数据库模型中。一个好的迁移工具需要一个好的迁移策略。为了确保对我们的客户造成最小的干扰，在应用生产中的更改之前，我们在预生产环境中演练了以下迁移策略。

首先，将数据库的当前快照迁移到所需的迁移结束时间偏移量（--migrate-end-time-offset），例如，迁移到过去的52周。这很像虚拟机迁移，我们首先同步大部分数据，这些数据需要的最小可用磁盘空间相当于数据库的当前大小。以下示例与基于Kolla Ansible的部署相关：

docker exec -it -u root monasca_persister bashsource /var/lib/kolla/venv/bin/activatepip install -U monasca-persisterdocker exec -it -u root monasca_persister python /var/lib/kolla/venv/lib/python2.7/site-packages/monasca_persister/tools/influxdb/db-per-tenant/migrate-to-db-per-tenant.py \--config-file /etc/monasca/persister.conf \--migrate-retention-policy project_1:2,project_2:12,project_3:52 \--migrate-skip-regex ^log\\..+ \--migrate-time-unit w \--migrate-start-time-offset 0 \--migrate-end-time-offset 52

初始迁移可能会花费一些时间，具体取决于要迁移的数据量和内置磁盘的类型。发生这种情况时，monasca_persister容器正在将新指标插入原始数据库，在完成初始迁移后，将需要重新同步。记下此迁移阶段需要花费的时间，因为这将确定需要迁移的数据库部分。您将看到为project_1创建了一个新的数据库，其特定于项目的保留策略为2w：

docker exec -it influxdb influx -host 192.168.7.1 -database monasca_project_1 -execute "SHOW RETENTION POLICIES"name    duration shardGroupDuration replicaN default----    -------- ------------------ -------- -------2w      336h0m0s 24h0m0s            1        true

初始迁移完成后，请停止monasca_persister 容器并确认它已停止。对于具有多个控制的部署，您需要确保在所有节点上都是这种情况。

docker stop monasca_persisterdocker ps | grep monasca_persisterr

持久性停止后，就不会有任何新的东西写入原始数据库，而任何新条目都将在Kafka上进行缓冲。最好将此数据库备份，因为InfluxDB为此提供了方便的命令行界面：

docker exec -it influxdb influxd backup -portable /var/lib/influxdb/backup

将Monasca容器升级到具有按租户数据库功能的*OpenStack Train*版本。例如，Kayobe/Kolla-Ansible用户可以运行以下Kayobe cli命令，该命令还可以确保新版本的 monsasca_persister容器已备份并在所有控制上运行，并且每个租户将条目写入数据库：

kayobe overcloud service reconfigure -kt monasca

用丢失的数据库条目填充新数据库（最少为1个时间单位）。influxdb自动防止重复条目，因此如果迁移窗口中存在重叠，则不成问题。在下面的命令中，我们假设原始迁移只花了不到一周的时间就完成了，因此将--migrate end time offset设置为1：

docker exec -it -u root monasca_persister python /var/lib/kolla/venv/lib/python2.7/site-packages/monasca_persister/tools/influxdb/db-per-tenant/migrate-to-db-per-tenant.py \--config-file /etc/monasca/persister.conf \--migrate-retention-policy project_1:2,project_2:12,project_3:52 \--migrate-skip-regex ^log\\..+ \--migrate-time-unit w \--migrate-start-time-offset 0 \--migrate-end-time-offset 1

第六期混合云2.0系列沙龙—《OpenStack 优化深度实践》课程回放：

课件下载地址：

链接：https://pan.baidu.com/s/187zEytvdoLkegaBe66PR4w

提取密码:关注新钛云服公众号，回复“OpenStack实践”，获取提取密码

点击“阅读原文”，即刻申请试用 “混合云运维管理平台“

了解新钛云服

新钛云服正式获批工信部ISP/IDC(含互联网资源协作)牌照

TiOps，支持多云环境安全远程运维，疫情期间免费对外开放，助力远程安全办公！

深耕专业，矗立鳌头，新钛云服获千万Pre-A轮融资

新钛云服，打造最专业的Cloud MSP+，做企业业务和云之间的桥梁

新钛云服一周年，完成两轮融资，服务五十多家客户

上海某仓储物流电子商务公司混合云解决方案