监控工具配置指南
OpenStack 日志记录和监控工具指南
摘要
使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息。
对红帽文档提供反馈
我们感谢您对文档提供反馈信息。与我们分享您的成功秘诀。
使用直接文档反馈(DDF)功能
使用 添加反馈 DDF 功能,用于特定句子、段落或代码块上的直接注释。
- 以 Multi-page HTML 格式查看文档。
- 请确定您看到文档右上角的 反馈 按钮。
- 用鼠标指针高亮显示您想评论的文本部分。
- 点 添加反馈。
- 在添加反馈项中输入您的意见。
- 可选:添加您的电子邮件地址,以便文档团队可以联系您以讨论您的问题。
- 点 Submit。
第 1 章 Red Hat OpenStack Platform 监控工具简介
监控工具是一个可选的工具套件,旨在帮助操作员维护 OpenStack 环境。该工具执行以下功能:
- 集中式日志记录:从一个中央位置收集 OpenStack 环境中所有组件的日志。您可以识别所有节点和服务中的问题,也可以选择将日志数据导出到红帽以获得诊断问题的帮助。
- 可用性监控:监控 OpenStack 环境中的所有组件,并确定任何组件当前遇到了停机或无法正常工作。您还可以将系统配置为在发现问题时发出警报。
1.1. 支持监控组件的状态
使用此表查看 Red Hat OpenStack Platform (RHOSP)中监控组件的支持状态。
组件 | 完全支持自 | 弃用 | 删除自 | 备注 |
---|---|---|---|---|
aodh | RHOSP 9 | RHOSP 15 | 支持自动扩展用例。 | |
ilo | RHOSP 4 | 支持自动扩展和服务遥测框架(STF)用例中 RHOSP 的指标和事件集合。 | ||
collectd | RHOSP 11 | RHOSP 17.1 | 支持 STF 的基础架构指标集合。 | |
Gnocchi | RHOSP 9 | RHOSP 15 | 支持存储自动扩展用例的指标。 | |
panko | RHOSP 11 | RHOSP 12,不默认安装,因为 RHOSP 14 | RHOSP 17.0 | |
QDR | RHOSP 13 | RHOSP 17.1 | 支持将指标和事件数据从 RHOSP 传输到 STF。 |
第 2 章 监控架构
监控工具使用客户端-服务器模型以及部署到 Red Hat OpenStack Platform overcloud 节点上的客户端。Rsyslog 服务提供客户端集中式日志记录(CL)和 collectd,启用了 sensubility 插件提供客户端侧可用性监控(AM)。
2.1. 集中式日志记录
在 Red Hat OpenStack 环境中,在一个中央位置从所有服务收集日志简化了调试和管理。这些日志来自操作系统,如 syslog 和审计日志文件、RabbitMQ 和 MariaDB 等基础架构组件,以及身份、计算等 OpenStack 服务。
集中式日志记录链由以下组件组成:
- 日志集合代理(Rsyslog)
- 数据存储(Elasticsearch)
- api/Presentation Layer (Kibana)
Red Hat OpenStack Platform director 不会为集中式日志记录部署服务器端组件。红帽不支持服务器端组件,包括 Elasticsearch 数据库和 Kibana。
2.2. 可用性监控
通过可用性监控,您有一个集中位置,可监控整个 OpenStack 环境中所有组件的高级别功能。
可用性监控链由多个组件组成:
- 监控代理(收集启用了 sensubility 插件)
- 监控中继/代理(RabbitMQ)
- 监控控制器/服务器(Sensu 服务器)
- api/Presentation Layer (Uchiwa)
Red Hat OpenStack Platform director 不会部署服务器端组件以进行可用性监控。红帽不支持服务器端组件,包括 Uchiwa、Sensu Server、Sensu API 和 RabbitMQ,以及在监控节点上运行的 Redis 实例。
在以下图中列出了可用性监控组件及其交互:
blue 中显示的项目表示红帽支持的组件。
图 2.1. 高级别的可用性监控架构

图 2.2. Red Hat OpenStack Platform 的单节点部署

图 2.3. Red Hat OpenStack Platform 的 HA 部署

第 3 章 安装客户端工具
在部署 overcloud 之前,您需要确定要应用到每个客户端的配置设置。从 heat 模板集合中复制示例环境文件,并修改文件以适合您的环境。
3.1. 设置集中式日志记录客户端参数
如需更多信息,请参阅 Logging, Monitoring, and Troubleshooting 指南中的 Enabling centralized logging with Elasticsearch。
3.2. 设置监控客户端参数
监控解决方案定期收集系统信息,并提供使用数据收集代理以各种方式存储和监控值的机制。红帽支持 collectd 作为集合代理。collectd-sensubility 是 collectd 的扩展,并通过 RabbitMQ 与 Sensu 服务器端通信。您可以使用 Service Telemetry Framework (STF)存储数据,并依次监控系统、查找性能瓶颈和预测将来的系统负载。有关 Service Telemetry Framework 的更多信息,请参阅 Service Telemetry Framework 1.3 指南。
要配置 collectd 和 collectd-sensubility,请完成以下步骤:
在主目录中创建
config.yaml
,如/home/templates/custom
,并将MetricsQdrConnectors
参数配置为指向 STF 服务器端:MetricsQdrConnectors: - host: qdr-normal-sa-telemetry.apps.remote.tld port: 443 role: inter-router sslProfile: sslProfile verifyHostname: false MetricsQdrSSLProfiles: - name: sslProfile
在
config.yaml
文件中,列出在CollectdExtraPlugins
下要使用的插件。您还可以在ExtraConfig
部分中提供参数。默认情况下,collectd 附带cpu
、df
、disk
、hugepages
、interface
、load
、内存
、进程
、tcpconns
、UNIXsock
和uptime
插件。您可以使用CollectdExtraPlugins
参数添加额外的插件。您还可以使用ExtraConfig
选项为CollectdExtraPlugins
提供额外的配置信息。例如,要启用virt
插件并配置连接字符串和主机名格式,请使用以下语法:parameter_defaults: CollectdExtraPlugins: - disk - df - virt ExtraConfig: collectd::plugin::virt::connection: "qemu:///system" collectd::plugin::virt::hostname_format: "hostname uuid"
注意不要删除
unixsock
插件。删除会导致将 collectd 容器标记为不健康。可选: 要通过 AMQ Interconnect 收集指标和事件数据,请将
MetricsQdrExternalEndpoint: true
行添加到config.yaml
文件中:parameter_defaults: MetricsQdrExternalEndpoint: true
要启用 collectd-sensubility,请在
config.yaml
文件中添加以下环境配置:parameter_defaults: CollectdEnableSensubility: true # Use this if there is restricted access for your checks by using the sudo command. # The rule will be created in /etc/sudoers.d for sensubility to enable it calling restricted commands via sensubility executor. CollectdSensubilityExecSudoRule: "collectd ALL = NOPASSWD: <some command or ALL for all commands>" # Connection URL to Sensu server side for reporting check results. CollectdSensubilityConnection: "amqp://sensu:sensu@<sensu server side IP>:5672//sensu" # Interval in seconds for sending keepalive messages to Sensu server side. CollectdSensubilityKeepaliveInterval: 20 # Path to temporary directory where the check scripts are created. CollectdSensubilityTmpDir: /var/tmp/collectd-sensubility-checks # Path to shell used for executing check scripts. CollectdSensubilityShellPath: /usr/bin/sh # To improve check execution rate use this parameter and value to change the number of goroutines spawned for executing check scripts. CollectdSensubilityWorkerCount: 2 # JSON-formatted definition of standalone checks to be scheduled on client side. If you need to schedule checks # on overcloud nodes instead of Sensu server, use this parameter. Configuration is compatible with Sensu check definition. # For more information, see https://docs.sensu.io/sensu-core/1.7/reference/checks/#check-definition-specification # There are some configuration options which sensubility ignores such as: extension, publish, cron, stdin, hooks. CollectdSensubilityChecks: example: command: "ping -c1 -W1 8.8.8.8" interval: 30 # The following parameters are used to modify standard, standalone checks for monitoring container health on overcloud nodes. # Do not modify these parameters. # CollectdEnableContainerHealthCheck: true # CollectdContainerHealthCheckCommand: <snip> # CollectdContainerHealthCheckInterval: 10 # The Sensu server side event handler to use for events created by the container health check. # CollectdContainerHealthCheckHandlers: # - handle-container-health-check # CollectdContainerHealthCheckOccurrences: 3 # CollectdContainerHealthCheckRefresh: 90
部署 overcloud。在 overcloud deploy 命令中包含
config.yaml
、collectd-write-
文件:qdr.yaml
以及其中一个 qdrjpeg.yaml$ openstack overcloud deploy -e /home/templates/custom/config.yaml -e tripleo-heat-templates/environments/metrics/collectd-write-qdr.yaml -e tripleo-heat-templates/environments/metrics/qdr-form-controller-mesh.yaml
-
可选: 要启用 overcloud RabbitMQ 监控,请在
overcloud deploy
命令中包含collectd-read-rabbitmq.yaml
文件。
其他资源
- 有关 YAML 文件的详情请参考 第 3.5 节 “YAML 文件”。
- 有关 collectd 插件的更多信息,请参阅 第 3.4 节 “collectd 插件配置”。
- 有关 Service Telemetry Framework 的更多信息,请参阅 Service Telemetry Framework 1.3 指南。
3.3. 通过 AMQ Interconnect 收集数据
要订阅可用的 AMQ Interconnect 地址进行指标和事件数据消耗,请创建一个环境文件来公开 AMQ Interconnect 用于客户端连接并部署 overcloud。
Service Telemetry Operator 简化了用于单个云部署的所有数据存储组件的部署。要将数据存储域与多个云共享,请参阅 Service Telemetry Framework 1.3 指南中的 配置多个云。
无法在 QDR 网格模式和 QDR 边缘模式间切换,如 Service Telemetry Framework (STF)使用。另外,如果您为 STF 启用数据收集,则无法使用 QDR 网格模式。
流程
-
以
stack
用户身份登录 Red Hat OpenStack Platform undercloud。 -
在
/home/stack
目录中创建一个名为data-collection.yaml
的配置文件。 要启用外部端点,请将
MetricsQdrExternalEndpoint: true
参数添加到data-collection.yaml
文件中:parameter_defaults: MetricsQdrExternalEndpoint: true
要启用 collectd 和 AMQ Interconnect,请在 Red Hat OpenStack Platform director 部署中添加以下文件:
-
data-collection.yaml
环境文件 qdr-form-controller-mesh.yaml
文件,它允许客户端侧 AMQ Interconnect 连接到外部端点openstack overcloud deploy <other arguments> --templates /usr/share/openstack-tripleo-heat-templates \ --environment-file <...other-environment-files...> \ --environment-file /usr/share/openstack-tripleo-heat-templates/environments/metrics/qdr-form-controller-mesh.yaml \ --environment-file /home/stack/data-collection.yaml
-
-
可选: 要收集 Ceilometer 和 collectd 事件,请在
overcloud deploy
命令中包含ceilometer-write-qdr.yaml
和collectd-write-qdr.yaml
文件。 - 部署 overcloud。
其他资源
- 有关 YAML 文件的详情请参考 第 3.5 节 “YAML 文件”。
3.4. collectd 插件配置
Red Hat OpenStack Platform director 有很多可能性配置。您可以配置多个 collectd 插件以适合您的环境。每个记录的插件都有一个描述和示例配置。有些插件具有可从 Grafana 或 Prometheus 查询的指标表,以及您可以配置的选项列表(如果可用)。
其他资源
- 要查看 collectd 插件选项的完整列表,请参阅 Service Telemetry Framework 指南中的 collectd 插件。
3.5. YAML 文件
在配置 collectd 时,您可以在 overcloud 部署命令
中包含以下 YAML 文件:
-
collectd-read-rabbitmq.yaml
:启用并配置python-collect-rabbitmq
以监控 overcloud RabbitMQ 实例。 -
collectd-write-qdr.yaml
:允许 collectd 通过 AMQ Interconnect 发送遥测和通知数据。 -
qdr-edge-only.yaml
: 启用 AMQ Interconnect 部署。每个 overcloud 节点都有一个本地 qdrouterd 服务,并在边缘模式下运行。例如,直接向定义的MetricsQdrConnectors
发送接收的数据。 -
qdr-form-controller-mesh.yaml
:启用 AMQ Interconnect 的部署。每个 overcloud 节点都有一个本地 qdrouterd 服务组成网格拓扑。例如,控制器上的 AMQ Interconnect 路由器以 interior 路由器运行,连接到定义的MetricsQdrConnectors
,在其他节点类型上的 AMQ Interconnect 路由器将以边缘模式连接到控制器上运行的 interior 路由器。
其他资源
有关配置 collectd 的更多信息,请参阅 第 3.2 节 “设置监控客户端参数”。