Operations/Monitoring
< 操作
目录
监控
此页面总结了在 Operations/Meetups 期间发生过的讨论
- https://etherpad.openstack.org/p/juno-summit-ops-monitoringlogging
- https://etherpad.openstack.org/p/kilo-summit-ops-monitoring
监控类别
- 传统的服务监控
- 租户健康监控
- 将此监控暴露给租户
- 为租户提供监控服务
工具
存在许多监控工具。请参阅 Operations/Tools 页面以获取清单。另请注意 Monasca，它是一个旨在创建监控即服务解决方案的项目。
监控痛点
- 操作人员通常对监控 OpenStack 感到不满意
- 工具太多了
- OpenStack 中需要监控的地方太多了
- 不清楚如何以及监控什么
- 监控量会对整个云产生性能影响
- 如何了解需要监控的主机/服务的信息？
- 主机信息的中央管理机构？
- 如何轻松/自动发现这些信息？
- 用于监控实例的实例元数据
- Puppet, Chef 等
解决方案？
- 创建和分享最佳实践
- 列出 OpenStack 中需要监控的所有区域，并创建如何监控它们的示例
- 工作量很大，但潜在回报很高
- 为每个主要版本提供此列表
当前已知实践
这些是在讨论期间收集的项目。实际实施会有所不同。这可能是上述清单的一个很好的起点。
服务守护进程
下表列出了作为 OpenStack 集成版本一部分的项目服务守护进程。
| 项目 | 组件 | 备注 |
|---|---|---|
| Glance | glance-api | glance-api 是一个服务器守护进程，它为镜像存储、检索和发现提供 API。 |
| Glance | glance-registry | glance-registry 是一个服务器守护进程，它为与镜像相关的元数据提供存储、处理和检索。 |
| Keystone | keystone-server | keystone-server 是一个服务器守护进程，它提供身份管理服务。 |
| Neutron | neutron-server | neutron-server 是一个服务器守护进程，它提供一个 Web 服务器，该服务器暴露 Neutron API，并将所有 Web 服务调用传递给 Neutron 插件进行处理。 |
| Nova | nova-api | nova-api 是一个服务器守护进程，它在单独的绿线程中提供 nova EC2 和 OpenStack API。 |
| Nova | nova-cert | nova-cert 是一个服务器守护进程，它为 Nova 证书提供 Nova Cert 服务，用于 X509 证书。仅适用于 EC2 API，用于生成 euca-bundle-image 证书。 |
| Nova | nova-conductor | nova-conductor 是一个服务器守护进程，它提供 Nova Conductor 服务，为 Nova 提供协调和数据库查询支持。 |
| Nova | nova-consoleauth | nova-consoleauth 是一个服务器守护进程，它为 Nova 控制台提供身份验证。 |
| Nova | nova-nonvncproxy | nova-nonvncproxy 是一个服务器守护进程，它提供对 OpenStack Nova novnc 控制台的访问。 |
| Nova | nova-scheduler | nova-scheduler 是一个服务器守护进程，它负责选择计算节点来运行 VM 实例。 |
需要监控的内容
- 服务守护进程
- nova-compute, glance-registry 等
- 确保它们正在运行
- 确保它们正常工作
- Tempest, Rally
- 实例可达性
- iptables / nat
- 附加卷
- 未关闭的 iSCSI 会话
- RabbitMQ 队列深度和健康状况
- OVS 隧道
- 租户可以执行的所有操作的功能
- 金丝雀实例
内核日志
计算节点的大部分错误仅报告到内核日志
- qemu 的 OOM（实例在没有租户意愿的情况下进入“shutdown”状态）
- 磁盘 IO 错误
- 网络闪烁（接口的链路上下波动）
- MCE（机器检查错误，如内存和处理器错误）
- ovs-vswitchd 的分段错误
netconsole 是收集这些日志并对它们做出反应的好方法。
监控媒介
- SNMP
- NRPE
- Consul
- Ansible / SSH
告警媒介
- 电子邮件
- 短信
- 电子邮件到短信
- Jabber / XMPP
- IRC
- NOC 控制台（详细信息？）
- 工单系统
- VoIP
健康检查
受众定义：一种查询服务并使其报告其是否“正常”的方法
- 它可靠吗？
- “正常”是如何确定的？
- 操作人员会依赖它，还是仍然会仔细检查服务正在检查的内容？
statsd
操作人员是否希望每个 OpenStack 服务都提供像 Swift 那样的声明式指标？
- “是”，但大多数人甚至没有将其用于 Swift。为什么？
- 大多数用户已经在轮询自己的指标
行动项目
完成这些项目并不能解决上述所有痛点，但将是一个很好的开始。
- 开始创建需要监控的每个 OpenStack 组件的“事物”列表
- 不需要是_完整的_列表——那将始终是一个持续进行的项目
- 为这些项目创建示例告警
- Nagios / NRPE 检查是否是示例的最佳形式？这可能是大多数操作人员熟悉且与非 Nagios 监控系统兼容的风格。
- 如果监控特定服务或功能变得过于复杂，请确定是否可以从服务内部更轻松地实现它，并建议或创建该服务的蓝图。
- 其中很多已经存在，但分散在许多不同的地方。
- 有人能展示一个使用 Rally 或 Tempest 包装在 Nagios 插件中的示例吗？
