阶段 2：监控¶

《扩展之旅》的第二阶段是监控。

在正确配置集群以处理扩展之后，您需要正确监控它，以发现负载压力迹象。OpenStack 中的监控可能有些复杂，有时很难确定如何有意义地监控您的部署，以便提前预警负载过高。此页面旨在帮助回答这些问题。

一旦建立了有意义的监控，您就可以进入《扩展之旅》的第三阶段：扩展。

常见问题解答¶

问：监控如何帮助我们？

答：监控可以帮助我们

问：可以用来监控 OpenStack 集群的可能指标有哪些？

答：OpenStack 中存在各种各样的指标，包括但不限于

问：如何检测 RabbitMQ 是否是瓶颈？

答：oslo.metrics 将引入对 rpc 调用的监控，目前正在开发中。RabbitMQ 节点 CPU 和 RAM 使用率也是您的 RabbitMQ 集群过载的指标，如果您发现 CPU 或 RAM 使用率很高，则应扩展 RabbitMQ 节点。

问：如何检测数据库是否是瓶颈？

答：oslo.metrics 也会将 oslo.db 集成为在 oslo.messaging 之后的下一步。

问：如何跟踪延迟问题？

答：如果您在 OpenStack API 服务器前面有负载均衡器或代理（例如 haproxy、nginx），您可以根据这些服务提供的指标监控 API 延迟。

问：如何跟踪错误率？

答：监控指标对于了解错误发生时的情况非常有用。错误率有两种类型

当操作失败时
- 由于 API 服务无法工作导致的 API 失败
  - 通过跟踪 HTTP 返回码（3xx、4xx、5xx）来完成
- 当消息队列已满时
  - 我们可以使用 RabbitMQ Exporters 来跟踪当前 MQ 状态
  - 其他 MQ 的想法
- 当资源利用率超过阈值时
  - 使用 Node Exporter、cAdvisor、自定义 Exporters，我们可以跟踪资源
- 当 C-Plane 资源或服务 Agent 停止工作时，等等
  - 可以通过收集不同节点（控制、计算、网络、存储节点等）上的 Agent 当前状态来跟踪
当操作速度慢时
- API 速度慢，但正在运行
  - 我们可以在主连接点（例如 haproxy）跟踪请求/响应之间的时滞，以了解 API 速度有多慢
- 资源 CRUD（例如，VM CRUD）速度慢
  - 这涉及计算完成创建/删除等资源所需的时间。由于资源 CRUD 可能是异步的，因此 API 响应时间可能无法给出确切的响应

问：我们如何跟踪性能问题？

VM 创建/删除/重建的时间增加
- 可以通过检查 Nova 发送的通知来计算
  - Nova 在开始创建/删除 VM 时以及操作结束时发送通知。这两个事件之间的时间间隔可用于查找时间
某些 Hypervisor 上调度的 VM 数量明显高于其他 Hypervisor（调度不当）
- 可以使用 libvirt Exporters 计算，libvirt Exporters 提供正在部署在计算节点上的 VM 的状态，并将其暴露给 Prometheus
- 也可以基于其他 Hypervisor 解决方案创建替代方案
API 响应时间过高
- 我们可以在主连接点（例如 haproxy）跟踪请求/响应之间的时滞，以了解 API 性能有多慢。

等等…

问：如何跟踪流量问题？

问：如何跟踪饱和度问题？