红帽全球峰会操作测量
使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始：master、slave、黑名单和白名单。由于此项工作十分艰巨，这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息。
对红帽文档提供反馈
我们感谢您对文档提供反馈信息。与我们分享您的成功秘诀。
使用直接文档反馈(DDF)功能
使用 添加反馈 DDF 功能，用于特定句子、段落或代码块上的直接注释。
- 以 Multi-page HTML 格式查看文档。
- 请确定您看到文档右上角的 反馈 按钮。
- 用鼠标指针高亮显示您想评论的文本部分。
- 点 添加反馈。
- 在添加反馈项中输入您的意见。
- 可选：添加您的电子邮件地址，以便文档团队可以联系您以讨论您的问题。
- 点 Submit。
第 1 章 操作测量简介
您可以使用 Red Hat OpenStack Platform (RHOSP)环境中的 Telemetry 服务组件来跟踪物理和虚拟资源，并使用在 Gnocchi 后端上存储聚合的数据收集守护进程收集指标，如 CPU 使用率和资源可用性。
您可以使用可用性和性能监控工具来测量和维护 RHOSP 环境。这些工具执行以下功能：
- 可用性监控
- 监控 RHOSP 环境中的所有组件，并确定任何组件当前是否出现停机或无法正常工作。您还可以将系统配置为在发现问题时提醒您。
- 性能监控
- 定期收集系统信息并提供使用数据收集守护进程存储和监控值的机制。此守护进程存储它收集的数据，如操作系统和日志文件。它还可使数据通过网络可用。您可以使用从数据收集的统计信息来监控系统、查找性能瓶颈和预测将来的系统负载。
1.1. Telemetry 架构
Red Hat OpenStack Platform (RHOSP) Telemetry 为基于 OpenStack 的云提供用户级使用情况数据。您可以使用这些数据进行客户计帐、系统监控或警报。您可以配置 Telemetry 组件从现有 RHOSP 组件发送的通知中收集数据，如计算使用情况事件，或者轮询 RHOSP 基础架构资源，如 libvirt。Telemetry 将收集的数据发布到包括数据存储和消息队列的各种目标。
Telemetry 由以下组件组成：
- 数据收集 ：Telemetry 使用 Ceilometer 收集指标和事件数据。更多信息请参阅 第 1.2.1 节 “Ceilometer”。
- 存储 ：Telemetry 将指标数据存储在 Gnocchi 中，并将事件数据存储在 Panko 中。更多信息请参阅 第 1.3 节 “使用 Gnocchi 存储”。
- 警报服务：Telemetry 使用 Alarming 服务(Aodh)根据定义的规则根据 Ceilometer 收集的指标或事件数据来触发操作。
收集数据后，您可以使用第三方工具显示和分析指标数据，您可以使用 Alarming 服务为事件配置警报。
图 1.1. Telemetry 架构
1.1.1. 监控组件的支持状态
使用这个表来查看 Red Hat OpenStack Platform 中监控组件的支持状态。
| 组件 | 完全支持自 | 中弃用 | 删除自 | 备注 |
|---|---|---|---|---|
| Aodh | RHOSP 9 | RHOSP 15 | 支持自动扩展用例。 | |
| Ceilometer | 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。 |
1.2. Red Hat OpenStack Platform 中的数据收集
Red Hat OpenStack Platform (RHOSP)支持两种类型的数据收集：
- Ceilometer 用于 OpenStack 组件级监控。更多信息请参阅 第 1.2.1 节 “Ceilometer”。
- collectd 用于基础架构监控。更多信息请参阅 第 1.2.2 节 “collectd”。
1.2.1. Ceilometer
Ceilometer 是 OpenStack 遥测服务的默认数据收集组件，能够在所有 OpenStack 核心组件中规范化和转换数据。Ceilometer 收集与 OpenStack 服务相关的计量和事件数据。用户可以根据部署配置访问收集的数据。
Ceilometer 服务使用三个代理从 Red Hat OpenStack Platform (RHOSP)组件收集数据：
-
计算代理(ceilometer-agent-compute) ：在每个 Compute 节点上运行，并轮询资源利用率统计。此代理与轮询代理
ceilometer-polling与使用参数--polling namespace-compute一起运行相同。 -
中央代理(ceilometer-agent-central) ：在中央管理服务器上运行，以轮询不与实例或 Compute 节点关联的资源利用率统计。您可以启动多个代理来横向扩展服务。这与轮询代理
ceilometer-polling与参数--polling namespace-central一起运行相同。 - 通知代理(ceilometer-agent-notification) ：在中央管理服务器上运行，并使用来自消息队列的消息来构建事件和计量数据。数据发布到定义的目标。Gnocchi 是默认目标。这些服务使用 RHOSP 通知总线进行通信。
Ceilometer 代理使用发布者将数据发送到对应的端点，如 Gnocchi。您可以在 pipeline.yaml 文件中配置这些信息。
其他资源
- 有关发布程序的更多信息，请参阅 第 1.2.1.1 节 “publishers”。
1.2.1.1. publishers
遥测服务提供多种传输方法，用于将收集的数据转让给外部系统。此数据的使用者则不同，例如，监控系统可接受数据丢失，以及计费系统，这需要可靠的数据传输。Telemetry 提供了一种方法来减轻这两种系统类型的要求。您可以使用服务的发布组件将数据通过消息总线将数据保存到持久性存储中，或将其发送到一个或多个外部用户。个链可以包含多个发布程序。
支持以下发布程序类型：
- Gnocchi （默认） ：当启用 Gnocchi 发布程序时，指标和资源信息将推送到 Gnocchi，以优化时间序列。确保您在身份服务中注册了 Gnocchi，因为 Ceilometer 通过身份服务发现确切的路径。
- Panko ：您可以在 panko 中存储 Ceilometer 的事件数据，该界面提供了一个 HTTP REST 接口，以在 Red Hat OpenStack Platform 中查询系统事件。Panko 已被弃用。
配置发布者参数
您可以为遥测服务内每个数据点配置多发布程序，使相同的技术计量或事件多次发布到多个目的地，每个都可能使用不同的传输方法。
流程
创建一个 YAML 文件来描述可能的发布程序参数和默认值，如
ceilometer-publisher.yaml。在parameter_defaults中插入以下参数：parameter_defaults: ManagePipeline: true ManageEventPipeline: true EventPipelinePublishers: - gnocchi://?archive_policy=high PipelinePublishers: - gnocchi://?archive_policy=high
部署 overcloud。在
openstack overcloud deploy命令中包含修改后的 YAML 文件。在以下示例中，将 <environment_files> 替换为您要包含在部署中的其他 YAML 文件：$ openstack overcloud deploy --templates \ -e /home/custom/ceilometer-publisher.yaml -e <environment_files>
1.2.2. collectd
性能监控会定期收集系统信息，并提供一种机制，使用收集的数据代理以各种方式存储和监控值。红帽支持 collectd 守护进程作为数据收集代理。此守护进程将数据存储在时间序列数据库中。红帽支持的数据库之一称为 Gnocchi。您可以使用此存储的数据来监控系统、查找性能瓶颈和预测将来的系统负载。
其他资源
- 有关 Gnocchi 的更多信息，请参阅 第 1.3 节 “使用 Gnocchi 存储”。
1.3. 使用 Gnocchi 存储
Gnocchi 是开源时间序列数据库。它以非常大的规模存储指标，并提供对操作器和用户的指标和资源的访问权限。Gnocchi 使用归档策略来定义计算和要保留的聚合数；以及索引器驱动程序，以存储所有资源、归档策略和指标的索引。
1.3.1. 归档策略：存储时间序列数据库中的短期和长期数据
归档策略定义了计算的聚合以及要保留的聚合数量。Gnocchi 支持不同的聚合方法，如最小值、最大值、平均数、Nthile 和标准偏差。这些聚合会在特定时间段的时间段内计算名为 granularity 并保留的。
归档策略定义了指标的聚合方式，以及它们的存储时间。每个归档策略定义为 timespan 的点数。
例如，如果您的归档策略定义了粒度为 1 秒的 10 点策略，则时间序列存档最多保留 10 秒，各自代表一个超过 1 秒的聚合。这意味着，时间序列的最大值为上限，在最近点和旧点之间保留 10 秒的数据。
归档策略也定义使用哪些聚合方法。默认设置为参数 default_aggregation_methods，其默认值为 mean、min、max. sum、std、count。因此，根据用例，归档策略和粒度会有所不同。
其他资源
- 有关归档策略的更多信息，请参阅 规划和管理归档策略。
1.3.2. 索引器驱动程序
索引器负责存储所有资源、归档策略和指标的索引及其定义、类型和属性。它还负责将资源与指标链接。Red Hat OpenStack Platform director 默认安装 indexer 驱动程序。您需要一个数据库来索引 Gnocchi 处理的所有资源和指标。支持的驱动程序是 MySQL。
1.3.3. Gnocchi Metric-as-a-Service 术语
下表包含 Metric-as-a-Service 功能常用术语的定义。
| 术语 | 定义 |
|---|---|
| 聚合方法 | 种函数用于将多个测量结果聚合到聚合中。例如，min 聚合方法将不同测量结果的值聚合到时间范围中所有测量结果的最小值。 |
| aggregate | 根据归档策略，从多个测量结果生成的数据点元数据。聚合由时间戳和值组成。 |
| 归档策略 | 附加到指标的聚合存储策略。归档策略决定聚合在指标中保留的时长，以及如何聚合聚合（聚合方法）。 |
| granularity | 在一系列指标的聚合中两个聚合之间的时间。 |
| 测量 | API 发送到时间序列数据库的传入数据点元。测量由时间戳和值组成。 |
| 指标 | 由 UUID 标识的实体。指标可以使用名称附加到资源。指标存储其聚合的方式由与指标关联的归档策略定义。 |
| 资源 | 代表您与指标关联的任何实体。资源由唯一 ID 标识，可以包含属性。 |
| 时间序列 | 按时间排序的聚合列表。 |
| timespan | 指标保留其聚合的时间周期。它用于归档策略的上下文。 |
1.4. 显示指标数据
您可以使用以下工具显示和分析指标数据：
- Grafana ：开源指标分析和视觉化套件。Grafana 最常用于可视化时间序列数据以进行基础架构和应用程序分析。
- 红帽 CloudForms ：IT 部门用来控制用户自助式服务功能的基础架构管理平台，以调配、管理并确保虚拟机及私有云中的合规性。
其他资源
- 有关 Grafana 的更多信息，请参阅 第 1.4.1 节 “使用并连接 Grafana 来显示数据”。
- 有关 Red Hat Cloudforms 的更多信息，请参阅 产品文档。
1.4.1. 使用并连接 Grafana 来显示数据
您可以使用第三方软件（如 Grafana）来查看收集和存储的指标的图形化表示。
Grafana 是一个开源指标分析、监控和视觉化套件。要安装和配置 Grafana，请参阅官方 Grafana 文档。
第 2 章 规划运营测量
您监控的资源取决于您的业务需求。您可以使用 Ceilometer 或 collectd 来监控您的资源。
- 如需有关 collectd 测量的更多信息，请参阅 第 2.2 节 “collectd 测量”。
- 有关 Ceilometer 测量的更多信息，请参阅 第 2.1 节 “Ceilometer 测量”。
2.1. Ceilometer 测量
有关 Ceilometer 测量的完整列表，请参阅 https://docs.openstack.org/ceilometer/train/admin/telemetry-measurements.html
2.2. collectd 测量
以下测量是最常用的 collectd 指标：
- disk
- interface
- load
- 内存
- 进程
- tcpconns
有关测量结果的完整列表，请参阅 collectd 指标和事件。
2.3. 规划数据存储
Gnocchi 存储数据点的集合，其中每个数据点都是一个聚合的。存储格式使用不同的技术进行压缩。因此，若要计算时间序列数据库的大小，您必须根据最糟糕的情况来估算大小。
流程
计算数据点数：
point 数量 = timespan / granularity
例如，如果要使用一分钟分辨率保留一个年的数据，请使用公式：
数据点数 = (365 天 24 小时 X 60 分钟)/1 分钟的数据点数 = 525600
计算时间序列数据库的大小：
字节大小 = 数据点 X 8 字节数
如果您将这个公式应用到示例，则结果为 4.1 MB：
字节大小 = 525600 点 X 8 字节 = 4204800 字节 = 4.1 MB
这个值是一个单一聚合时间序列数据库的估算存储要求。如果您的归档策略使用多个聚合方法(min、max、mean、ided、std、std 和 count)，则按您使用的聚合方法数乘以该值。
2.4. 规划和管理归档策略
归档策略定义了您如何聚合指标，以及将指标存储在时间序列数据库中的时长。归档策略定义为 timespan 的点数。
如果您的归档策略定义了粒度为 1 秒的 10 点策略，则时间序列存档最多保留 10 秒，各自代表 1 秒的聚合。这意味着，时间序列在最近点和旧点之间保留最多 10 秒的数据。归档策略也定义要使用的聚合方法。默认设置为参数 default_aggregation_methods，其中默认值设置为 mean、min、max。总、std、count.因此，根据用例，归档策略和粒度可能会有所不同。
要计划归档策略，请确定您熟悉以下概念：
- 指标.更多信息请参阅 第 2.4.1 节 “指标”。
- 测量结果。更多信息请参阅 第 2.4.2 节 “创建自定义测量结果”。
- 聚合.更多信息请参阅 第 2.4.4 节 “计算时间序列聚合的大小”。
- 指标的 worker。更多信息请参阅 第 2.4.5 节 “metricd worker”。
要创建和管理归档策略，请完成以下任务：
- 创建归档策略。更多信息请参阅 第 2.4.6 节 “创建归档策略”。
- 管理归档策略。更多信息请参阅 第 2.4.7 节 “管理归档策略”。
- 创建归档策略规则。更多信息请参阅 第 2.4.8 节 “创建归档策略规则”。
2.4.1. 指标
Gnocchi 提供名为 metric 的对象类型。指标是您可以测量的任何内容，例如，服务器的 CPU 使用量、空间温度或网络接口发送的字节数。指标具有以下属性：
- 用于标识它的 UUID
- 一个名称
- 用于存储和聚合测量结果的归档策略
其他资源
- 有关术语定义，请参阅 Gnocchi Metric-as-a-Service 术语。
2.4.1.1. 创建指标
流程
创建资源。将 <resource_name> 替换为资源名称：
$ openstack metric resource create <resource_name>
创建指标。将 <resource_name> 替换为资源名称，将 <metric_name> 替换为指标的名称：
$ openstack metric metric create -r <resource_name> <metric_name>
在创建指标时，归档策略属性会被修复并不可更改。您可以通过
archive_policy端点更改归档策略的定义。
2.4.2. 创建自定义测量结果
测量 API 发送到 Gnocchi 的传入数据点数。它由一个时间戳和值组成。您可以创建自己的自定义测量结果。
流程
创建自定义测量：
$ openstack metric measures add -m <MEASURE1> -m <MEASURE2> .. -r <RESOURCE_NAME> <METRIC_NAME>
2.4.3. 默认归档策略
默认情况下，Gnocc 具有以下归档策略：
低
- 5 分钟粒度超过 30 天
-
使用的聚合方法：
default_aggregation_methods - 每个指标的最大估算大小： 406 KiB
中
- 1 分钟粒度超过 7 天
- 365 天 1 小时粒度
-
使用的聚合方法：
default_aggregation_methods - 每个指标的最大估算大小：887 KiB
high
- 1 小时第二个粒度
- 1 周的 1 分钟粒度
- 1 小时粒度超过 1 年
-
使用的聚合方法：
default_aggregation_methods - 每个指标的最大预计大小：1 057 KiB
bool
- 1 年超过 1 秒的粒度
- 使用的聚合方法：最后
- 每个指标的最大优化大小：1 539 KiB
- 每个指标的最大 pessimistic 大小：277 172 KiB
2.4.4. 计算时间序列聚合的大小
Gnocchi 存储一系列数据点，其中每个点都是一个聚合的。存储格式使用不同的技术进行压缩。因此，根据最糟糕的情况，计算时间序列的大小估计是估算的，如下例所示。
流程
使用此公式计算点数：
point 数量 = timespan / granularity
例如，如果要使用一分钟分辨率保留一年的数据：
点数 = (365 天 X 24 小时 X 60 分钟)/1 分钟
点数 = 525600
要计算点大小（以字节为单位），请使用这个公式：
字节大小（以字节为单位） = 点 X 8 字节数
字节大小 = 525600 点 X 8 字节 = 4204800 字节 = 4.1 MB
这个值是一个单一聚合时间序列的估算存储要求。如果您的归档策略使用多个聚合方法 - 分钟、max、mean、sted、std、count - 按您使用的聚合方法数乘以该值。
2.4.5. metricd worker
您可以使用 metricd 守护进程来处理测量结果，创建聚合、存储测量结果，以及删除指标。metricd 守护进程负责 Gnocchi 中大多数 CPU 用量和 I/O 作业。每个指标的归档策略决定指标守护进程执行的速度。metricd 会定期检查传入的存储是否有新的测量结果。要配置每个检查之间的延迟，您可以使用 [metricd]metric_processing_delay 配置选项。
2.4.6. 创建归档策略
流程
创建归档策略。将 <archive-policy-name> 替换为策略的名称，将 <aggregation-method> 替换为聚合的方法。
# openstack metric archive policy create <archive-policy-name> --definition <definition> \ --aggregation-method <aggregation-method>
注意<definition> 是策略定义。使用逗号分隔多个属性（、）。使用冒号(:)分隔归档策略定义的 name 和值。
2.4.7. 管理归档策略
删除归档策略：
openstack metric archive policy delete <archive-policy-name>
查看所有归档策略：
# openstack metric archive policy list
查看归档策略的详情：
# openstack metric archive-policy show <archive-policy-name>
2.4.8. 创建归档策略规则
归档策略规则定义了指标和归档策略之间的映射。这样，用户可以预定义规则，以便基于匹配模式将归档策略分配给指标。
流程
创建归档策略规则。将 <rule-name> 替换为规则的名称，<archive-policy-name> 替换为归档策略的名称：
# openstack metric archive-policy-rule create <rule-name> / --archive-policy-name <archive-policy-name>
2.5. 验证 Red Hat OpenStack Platform 部署
您可以使用 openstack metric 命令验证部署是否成功。
流程
验证部署：
(overcloud) [stack@undercloud-0 ~]$ openstack metric status +-----------------------------------------------------+-------+ | Field | Value | +-----------------------------------------------------+-------+ | storage/number of metric having measures to process | 0 | | storage/total number of measures to process | 0 | +-----------------------------------------------------+-------+
第 3 章 管理警报
您可以使用遥测 Alarming 服务(aodh)根据定义的规则根据 Ceilometer 或 Gnocchi 收集的指标数据来触发操作。
警报可处于以下状态之一：
- ok
- 指标或事件处于可接受的状态。
- 触发
- 指标或事件超出定义的 ok 状态。
- 数据不足
- 警报状态未知。这有多种原因，例如，请求的粒度没有数据，检查还没有执行，以此类推。
3.1. 查看现有警报
您可以查看现有的 Telemetry 警报信息，并列出分配给资源的计量，以检查指标的当前状态。
流程
列出现有的 Telemetry 警报：
# openstack alarm list +--------------------------------------+--------------------------------------------+----------------------------+-------------------+----------+---------+ | alarm_id | type | name | state | severity | enabled | +--------------------------------------+--------------------------------------------+----------------------------+-------------------+----------+---------+ | 922f899c-27c8-4c7d-a2cf-107be51ca90a | gnocchi_aggregation_by_resources_threshold | iops-monitor-read-requests | insufficient data | low | True | +--------------------------------------+--------------------------------------------+----------------------------+-------------------+----------+---------+
要列出分配给资源的计量，请指定资源的 UUID。例如：
# openstack metric resource show 22592ae1-922a-4f51-b935-20c938f48753 | Field | Value | +-----------------------+-------------------------------------------------------------------+ | created_by_project_id | 1adaed3aaa7f454c83307688c0825978 | | created_by_user_id | d8429405a2764c3bb5184d29bd32c46a | | creator | d8429405a2764c3bb5184d29bd32c46a:1adaed3aaa7f454c83307688c0825978 | | ended_at | None | | id | 22592ae1-922a-4f51-b935-20c938f48753 | | metrics | cpu: a0375b0e-f799-47ea-b4ba-f494cf562ad8 | | | disk.ephemeral.size: cd082824-dfd6-49c3-afdf-6bfc8c12bd2a | | | disk.root.size: cd88dc61-ba85-45eb-a7b9-4686a6a0787b | | | memory.usage: 7a1e787c-5fa7-4ac3-a2c6-4c3821eaf80a | | | memory: ebd38ef7-cdc1-49f1-87c1-0b627d7c189e | | | vcpus: cc9353f1-bb24-4d37-ab8f-d3e887ca8856 | | original_resource_id | 22592ae1-922a-4f51-b935-20c938f48753 | | project_id | cdda46e0b5be4782bc0480dac280832a | | revision_end | None | | revision_start | 2021-09-16T17:00:41.227453+00:00 | | started_at | 2021-09-16T16:17:08.444032+00:00 | | type | instance | | user_id | f00de1d74408428cadf483ea7dbb2a83 | +-----------------------+-------------------------------------------------------------------+
3.2. 创建警报
在达到阈值时，使用 Telemetry Alarming 服务(aodh)创建在满足特定条件时触发的警报，例如：在本例中，警报激活并在单个实例的平均 CPU 利用率超过 80% 时添加一个日志条目。
流程
归档策略会在部署过程中预先填充，很少需要创建新的归档策略。但是，如果没有配置归档策略，则必须创建一个。要创建为 5s * 86400 点(5 天)创建指标的归档策略，请使用以下命令：
# openstack archive-policy create <name> \ -d granularity:5s,points:86400 \ -b 3 -m mean -m rate:mean+ 将 <name > 替换为归档策略的名称。
注意确保将 Telemetry Alarming 服务的评估周期值设置为大于 60 的整数。Ceilometer 轮询间隔与评估期间相关联。确保将 Ceilometer 轮询间隔值设置为 60 到 600 之间的数字，并确保该值大于遥测 Alarming 服务的评估周期值。如果 Ceilometer 轮询间隔太低，这可能会影响系统负载。
创建警报并使用查询来隔离实例的特定 ID 以进行监控。以下示例中实例的 ID 是 94619081-abf5-4f1f-81c7-9cedaa872403。
注意要计算阈值，请使用以下公式： 1,000,000,000 x {granularity} x {percentage_in_decimal}
# openstack alarm create \ --type gnocchi_aggregation_by_resources_threshold \ --name cpu_usage_high \ --granularity 5 --metric cpu \ --threshold 48000000000 \ --aggregation-method rate:mean \ --resource-type instance \ --query '{"=": {"id": "94619081-abf5-4f1f-81c7-9cedaa872403"}}' --alarm-action 'log://' +---------------------------+-------------------------------------------------------+ | Field | Value | +---------------------------+-------------------------------------------------------+ | aggregation_method | rate:mean | | alarm_actions | [u'log://'] | | alarm_id | b794adc7-ed4f-4edb-ace4-88cbe4674a94 | | comparison_operator | eq | | description | gnocchi_aggregation_by_resources_threshold alarm rule | | enabled | True | | evaluation_periods | 1 | | granularity | 5 | | insufficient_data_actions | [] | | metric | cpu | | name | cpu_usage_high | | ok_actions | [] | | project_id | 13c52c41e0e543d9841a3e761f981c20 | | query | {"=": {"id": "94619081-abf5-4f1f-81c7-9cedaa872403"}} | | repeat_actions | False | | resource_type | instance | | severity | low | | state | insufficient data | | state_timestamp | 2016-12-09T05:18:53.326000 | | threshold | 48000000000.0 | | time_constraints | [] | | timestamp | 2016-12-09T05:18:53.326000 | | type | gnocchi_aggregation_by_resources_threshold | | user_id | 32d3f2c9a234423cb52fb69d3741dbbc | +---------------------------+-------------------------------------------------------+
3.3. 编辑警报
编辑警报时，您可以增加或降低警报的值阈值。
流程
若要更新阈值，可使用
openstack alarm update命令。例如，要将警报阈值增加到 75%，请使用以下命令：# openstack alarm update --name cpu_usage_high --threshold 75
3.4. 禁用警报
您可以禁用和启用警报。
流程
禁用警报：
# openstack alarm update --name cpu_usage_high --enabled=false
3.5. 删除警报
使用 openstack alarm delete 命令删除警报。
流程
要删除警报，请输入以下命令：
# openstack alarm delete --name cpu_usage_high
3.6. 示例：监控实例的磁盘活动
本例演示了如何使用属于 Telemetry Alarming 服务的警报来监控特定项目中包含的所有实例的累积磁盘活动。
流程
检查现有项目，再选择要监控的项目的适当 UUID。本例使用
admin租户：$ openstack project list +----------------------------------+----------+ | ID | Name | +----------------------------------+----------+ | 745d33000ac74d30a77539f8920555e7 | admin | | 983739bb834a42ddb48124a38def8538 | services | | be9e767afd4c4b7ead1417c6dfedde2b | demo | +----------------------------------+----------+
使用项目 UUID 创建警报，以分析
admin租户中实例生成的所有读取请求的sum （）。您可以使用--query参数进一步限制查询：# openstack alarm create \ --type gnocchi_aggregation_by_resources_threshold \ --name iops-monitor-read-requests \ --metric disk.read.requests.rate \ --threshold 42000 \ --aggregation-method sum \ --resource-type instance \ --query '{"=": {"project_id": "745d33000ac74d30a77539f8920555e7"}}' +---------------------------+-----------------------------------------------------------+ | Field | Value | +---------------------------+-----------------------------------------------------------+ | aggregation_method | sum | | alarm_actions | [] | | alarm_id | 192aba27-d823-4ede-a404-7f6b3cc12469 | | comparison_operator | eq | | description | gnocchi_aggregation_by_resources_threshold alarm rule | | enabled | True | | evaluation_periods | 1 | | granularity | 60 | | insufficient_data_actions | [] | | metric | disk.read.requests.rate | | name | iops-monitor-read-requests | | ok_actions | [] | | project_id | 745d33000ac74d30a77539f8920555e7 | | query | {"=": {"project_id": "745d33000ac74d30a77539f8920555e7"}} | | repeat_actions | False | | resource_type | instance | | severity | low | | state | insufficient data | | state_timestamp | 2016-11-08T23:41:22.919000 | | threshold | 42000.0 | | time_constraints | [] | | timestamp | 2016-11-08T23:41:22.919000 | | type | gnocchi_aggregation_by_resources_threshold | | user_id | 8c4aea738d774967b4ef388eb41fef5e | +---------------------------+-----------------------------------------------------------+
3.7. 示例：监控 CPU 使用
要监控实例的性能，可检查 Gnocchi 数据库以确定您可以监控哪些指标，如内存或 CPU 使用量。
流程
要识别您可以监控的指标，请使用实例 UUID 输入
openstack metric resource show命令：$ openstack metric resource show --type instance 22592ae1-922a-4f51-b935-20c938f48753 +-----------------------+-------------------------------------------------------------------+ | Field | Value | +-----------------------+-------------------------------------------------------------------+ | availability_zone | nova | | created_at | 2021-09-16T16:16:24+00:00 | | created_by_project_id | 1adaed3aaa7f454c83307688c0825978 | | created_by_user_id | d8429405a2764c3bb5184d29bd32c46a | | creator | d8429405a2764c3bb5184d29bd32c46a:1adaed3aaa7f454c83307688c0825978 | | deleted_at | None | | display_name | foo-2 | | ended_at | None | | flavor_id | 0e5bae38-a949-4509-9868-82b353ef7ffb | | flavor_name | workload_flavor_0 | | host | compute-0.redhat.local | | id | 22592ae1-922a-4f51-b935-20c938f48753 | | image_ref | 3cde20b4-7620-49f3-8622-eeacbdc43d49 | | launched_at | 2021-09-16T16:17:03+00:00 | | metrics | cpu: a0375b0e-f799-47ea-b4ba-f494cf562ad8 | | | disk.ephemeral.size: cd082824-dfd6-49c3-afdf-6bfc8c12bd2a | | | disk.root.size: cd88dc61-ba85-45eb-a7b9-4686a6a0787b | | | memory.usage: 7a1e787c-5fa7-4ac3-a2c6-4c3821eaf80a | | | memory: ebd38ef7-cdc1-49f1-87c1-0b627d7c189e | | | vcpus: cc9353f1-bb24-4d37-ab8f-d3e887ca8856 | | original_resource_id | 22592ae1-922a-4f51-b935-20c938f48753 | | project_id | cdda46e0b5be4782bc0480dac280832a | | revision_end | None | | revision_start | 2021-09-16T17:00:41.227453+00:00 | | server_group | None | | started_at | 2021-09-16T16:17:08.444032+00:00 | | type | instance | | user_id | f00de1d74408428cadf483ea7dbb2a83 | +-----------------------+-------------------------------------------------------------------+
因此，指标值列出了您可以使用 Alarming 服务监控的组件，如
cpu。要监控 CPU 用量，请使用
cpu指标：$ openstack metric show --resource-id 22592ae1-922a-4f51-b935-20c938f48753 cpu +--------------------------------+-------------------------------------------------------------------+ | Field | Value | +--------------------------------+-------------------------------------------------------------------+ | archive_policy/name | ceilometer-high-rate | | creator | d8429405a2764c3bb5184d29bd32c46a:1adaed3aaa7f454c83307688c0825978 | | id | a0375b0e-f799-47ea-b4ba-f494cf562ad8 | | name | cpu | | resource/created_by_project_id | 1adaed3aaa7f454c83307688c0825978 | | resource/created_by_user_id | d8429405a2764c3bb5184d29bd32c46a | | resource/creator | d8429405a2764c3bb5184d29bd32c46a:1adaed3aaa7f454c83307688c0825978 | | resource/ended_at | None | | resource/id | 22592ae1-922a-4f51-b935-20c938f48753 | | resource/original_resource_id | 22592ae1-922a-4f51-b935-20c938f48753 | | resource/project_id | cdda46e0b5be4782bc0480dac280832a | | resource/revision_end | None | | resource/revision_start | 2021-09-16T17:00:41.227453+00:00 | | resource/started_at | 2021-09-16T16:17:08.444032+00:00 | | resource/type | instance | | resource/user_id | f00de1d74408428cadf483ea7dbb2a83 | | unit | ns | +--------------------------------+-------------------------------------------------------------------+
archive_policy 定义用于计算 std、count、min、max、sum 和 mean 值的聚合间隔。
检查
cpu指标当前所选的归档策略：$ openstack metric archive-policy show ceilometer-high-rate +---------------------+-------------------------------------------------------------------+ | Field | Value | +---------------------+-------------------------------------------------------------------+ | aggregation_methods | rate:mean, mean | | back_window | 0 | | definition | - timespan: 1:00:00, granularity: 0:00:01, points: 3600 | | | - timespan: 1 day, 0:00:00, granularity: 0:01:00, points: 1440 | | | - timespan: 365 days, 0:00:00, granularity: 1:00:00, points: 8760 | | name | ceilometer-high-rate | +---------------------+-------------------------------------------------------------------+
使用 Alarming 服务创建查询
cpu的监控任务。此任务会根据您指定的设置触发事件。例如，当实例在延长持续时间超过 80% 时，要引发日志条目，请使用以下命令：$ openstack alarm create \ --project-id 3cee262b907b4040b26b678d7180566b \ --name high-cpu \ --type gnocchi_resources_threshold \ --description 'High CPU usage' \ --metric cpu \ --threshold 800,000,000.0 \ --comparison-operator ge \ --aggregation-method mean \ --granularity 300 \ --evaluation-periods 1 \ --alarm-action 'log://' \ --ok-action 'log://' \ --resource-type instance \ --resource-id 22592ae1-922a-4f51-b935-20c938f48753 +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | aggregation_method | rate:mean | | alarm_actions | ['log:'] | | alarm_id | c7b326bd-a68c-4247-9d2b-56d9fb18bf38 | | comparison_operator | ge | | description | High CPU usage | | enabled | True | | evaluation_periods | 1 | | granularity | 300 | | insufficient_data_actions | [] | | metric | cpu | | name | high-cpu | | ok_actions | ['log:'] | | project_id | cdda46e0b5be4782bc0480dac280832a | | repeat_actions | False | | resource_id | 22592ae1-922a-4f51-b935-20c938f48753 | | resource_type | instance | | severity | low | | state | insufficient data | | state_reason | Not evaluated yet | | state_timestamp | 2021-09-21T08:02:57.090592 | | threshold | 800000000.0 | | time_constraints | [] | | timestamp | 2021-09-21T08:02:57.090592 | | type | gnocchi_resources_threshold | | user_id | f00de1d74408428cadf483ea7dbb2a83 | +---------------------------+--------------------------------------+
- comparison-operator：如果 CPU 使用率大于或等于 80%，ge 运算符定义了警报触发。
- granularity：指标关联有一个归档策略，策略可以具有各种粒度。例如，每月 1 小时的 5 分钟聚合为 1 小时聚合。granularity 值必须与归档策略中描述的持续时间匹配。
- 评估-periods：在警报触发前需要传递的粒度周期数。例如，如果您将此值设置为 2，则在警报触发前，CPU 用量需要超过 80% 才能触发两个轮询周期。
[U'log://']：当您将
alarm_actions或ok_actions设置为[u'log://']时，事件会被触发或返回到普通的状态，则会记录到 aodh 日志文件。注意您可以定义在警报触发时运行的不同操作(alarm_actions)，并在返回正常状态(ok_actions) （如 Webhook URL）时运行。
3.8. 查看警报历史记录
若要检查是否触发了特定警报，您可以查询警报历史记录并查看事件信息。
流程
使用
openstack alarm-history show命令：$ openstack alarm-history show 1625015c-49b8-4e3f-9427-3c312a8615dd --fit-width +----------------------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------+ | timestamp | type | detail | event_id | +----------------------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------+ | 2017-11-16T05:21:47.850094 | state transition | {"transition_reason": "Transition to ok due to 1 samples inside threshold, most recent: 0.0366665763", "state": "ok"} | 3b51f09d-ded1-4807-b6bb-65fdc87669e4 | +----------------------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------+
第 4 章 安装和配置日志服务
Red Hat OpenStack Platform (RHOSP)将信息消息写入特定的日志文件中；您可以使用这些消息来故障排除和监控系统事件。日志收集代理 Rsyslog 收集客户端的日志，并将这些日志发送到在服务器端运行的 Rsyslog 实例。服务器端 Rsyslog 实例将日志记录重定向到 Elasticsearch 以进行存储。
您不需要手动将单个日志文件附加到您的支持问题单中。sosreport 工具会自动收集所需日志。
4.1. 集中式日志系统架构和组件
监控工具使用客户端-服务器模型以及部署到 Red Hat OpenStack Platform (RHOSP) overcloud 节点上的客户端。Rsyslog 服务提供客户端集中式日志记录(CL)。
所有 RHOSP 服务都会生成和更新日志文件。这些日志文件记录操作、错误、警告和其他事件。在 OpenStack 等分布式环境中，将这些日志收集中央位置简化了调试和管理。
通过集中式日志记录，有一个中心可在整个 RHOSP 环境中查看日志。这些日志来自操作系统，如 syslog 和 audit 日志文件、基础架构组件（如 RabbitMQ 和 MariaDB）以及 OpenStack 服务，如 Identity、Compute 等等。集中式日志记录工具链包括以下组件：
- log Collection Agent (Rsyslog)
- 数据存储(ElasticSearch)
- API/Presentation Layer (Grafana)
Red Hat OpenStack Platform director 不会为集中式日志记录部署服务器端组件。红帽不支持服务器端组件，包括 Elasticsearch 数据库和 Grafana。
4.2. 使用 Elasticsearch 启用集中式日志记录
要启用集中式日志记录，您必须指定 OS::TripleO::Services::Rsyslog 可组合服务的实现。
Rsyslog 服务只使用 Elasticsearch 作为集中式日志记录的数据存储。
先决条件
- Elasticsearch 已在服务器端安装。
流程
将日志记录环境的文件路径添加到
overcloud 部署命令中，以及与您的环境和部署相关的任何其他环境文件，如下例所示：openstack overcloud deploy \ <existing_overcloud_environment_files> \ -e /usr/share/openstack-tripleo-heat-templates/environments/logging-environment-rsyslog.yaml
使用
<existing_overcloud_environment_files>属于现有部署一部分的环境文件列表替换。
4.3. 配置日志记录功能
要配置日志记录功能，修改 logging-environment-rsyslog.yaml 文件中的 RsyslogElasticsearchSetting 参数。
流程
-
将
tripleo-heat-templates/environments/logging-environment-rsyslog.yaml文件复制到您的主目录。 在
RsyslogElasticsearchSetting参数中创建条目以适合您的环境。以下片段是RsyslogElasticsearchSetting参数配置示例：parameter_defaults: RsyslogElasticsearchSetting: uid: "elastic" pwd: "yourownpassword" skipverifyhost: "on" allowunsignedcerts: "on" server: "https://log-store-service-telemetry.apps.stfcloudops1.lab.upshift.rdu2.redhat.com" serverport: 443
其他资源
- 有关可配置参数的详情请参考 第 4.3.1 节 “可配置的日志记录参数”。
4.3.1. 可配置的日志记录参数
下表包含用来配置 Red Hat OpenStack Platform (RHOSP)中的日志记录功能的日志参数的描述。您可以在 tripleo-heat-templates/deployment/logging/rsyslog-container-puppet.yaml 文件中找到这些参数。
| 参数 | 描述 |
|---|---|
|
|
配置 |
|
| 包含发布 Elasticsearch 服务器证书的 CA 证书的 CA 证书。 |
|
| 包含用于对 Elasticsearch 进行客户端证书授权的客户端证书内容。 |
|
|
包含与 cert |
4.4. 管理日志
容器化服务日志文件存储在 /var/log/containers/<service> 中，如 /var/log/containers/cinder。容器内运行的服务的日志文件存储在本地。可用的日志可以根据启用和禁用的服务而有所不同。
以下示例强制 logrotate 任务在达到 10 MB 时创建新日志文件，并在日志文件达到 14 天时保留日志文件。
parameter_defaults LogrotateRotate: '14' LogrotatePurgeAfterDays: '14' LogrotateMaxsize: '10M'
要自定义日志轮转参数，请在环境模板中包括这些参数 _defaults，然后部署 overcloud。
openstack overcloud deploy \ --timeout 100 \ --templates /usr/share/openstack-tripleo-heat-templates \ ... \ -e /home/stack/templates/rotate.yaml \ --log-file overcloud_deployment_90.log
验证：在任何 overcloud 节点上，确保 logrotate_crond 已更新：
[root@compute0 ~]# podman exec -it logrotate_crond cat /etc/logrotate-crond.conf
/var/log/containers/*/*log /var/log/containers/*/*/*log /var/log/containers/*/*err {
daily
rotate 14
maxage 14
# minsize 1 is required for GDPR compliance, all files in
# /var/log/containers not managed with logrotate will be purged!
minsize 1
# Do not use size as it's not compatible with time-based rotation rules
# required for GDPR compliance.
maxsize 10M
missingok
notifempty
copytruncate
delaycompress
compress
}
在以下示例中，nova-compute.log 文件已轮转一次。
[root@compute0 ~]# ls -lah /var/log/containers/nova/ total 48K drwxr-x---. 2 42436 42436 79 May 12 09:01 . drwxr-x---. 7 root root 82 Jan 21 2021 .. -rw-r--r--. 1 42436 42436 12K May 12 14:00 nova-compute.log -rw-r--r--. 1 42436 42436 33K May 12 09:01 nova-compute.log.1 -rw-r--r--. 1 42436 42436 0 Jan 21 2021 nova-manage.log
日志文件轮转过程发生在 logrotate_crond 容器中。/var/spool/cron/root 配置文件是读取的，发送到进程的配置。
验证：确保配置在任何控制器节点上存在：
[root@controller0 ~]# podman exec -it logrotate_crond /bin/sh
()[root@9410925fded9 /]$ cat /var/spool/cron/root
# HEADER: This file was autogenerated at 2021-01-21 16:47:27 +0000 by puppet.
# HEADER: While it can still be managed manually, it is definitely not recommended.
# HEADER: Note particularly that the comments starting with 'Puppet Name' should
# HEADER: not be deleted, as doing so could cause duplicate cron jobs.
# Puppet Name: logrotate-crond
PATH=/bin:/usr/bin:/usr/sbin SHELL=/bin/sh
0 * * * * sleep `expr ${RANDOM} \% 90`; /usr/sbin/logrotate -s /var/lib/logrotate/logrotate-crond.status /etc/logrotate-crond.conf 2>&1|logger -t logrotate-crond
/var/lib/config-data/puppet-generated/crond/etc/logrotate-crond.conf 文件绑定到 logrotate_crond 容器中的 /etc/logrotate-crond.conf。
由于历史原因，旧配置文件保留下来，但不会使用它们。
4.5. 覆盖日志文件的默认路径
如果您修改默认容器和修改包含服务日志文件的路径，还必须修改默认的日志文件路径。每个可组合服务都有一个 < service_name>LoggingSource 参数。例如，对于 nova-compute 服务，参数是 NovaComputeLoggingSource。
流程
要覆盖 nova-compute 服务的默认路径，请在配置文件中添加
NovaComputeLoggingSource参数的路径：NovaComputeLoggingSource: tag: openstack.nova.compute file: /some/other/path/nova-compute.log注意对于每个服务，定义
tag和file。其他值默认是派生的。您可以修改特定服务的格式。这会直接传递给 Rsyslog 配置。
LoggingDefaultFormat参数的默认格式为 /(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d+) (<pid>\d+) (<priority>\S+) (<message>.*)$/使用以下语法：<service_name>LoggingSource: tag: <service_name>.tag path: <service_name>.path format: <service_name>.format以下片段是一个更复杂的转换示例：
ServiceLoggingSource: tag: openstack.Service path: /var/log/containers/service/service.log format: multiline format_firstline: '/^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d{3} \d+ \S+ \S+ \[(req-\S+ \S+ \S+ \S+ \S+ \S+|-)\]/' format1: '/^(?<Timestamp>\S+ \S+) (?<Pid>\d+) (?<log_level>\S+) (?<python_module>\S+) (\[(req-(?<request_id>\S+) (?<user_id>\S+) (?<tenant_id>\S+) (?<domain_id>\S+) (?<user_domain>\S+) (?<project_domain>\S+)|-)\])? (?<Payload>.*)?$/'
4.6. 修改日志记录格式
您可以修改特定服务的日志记录的开头格式。这会直接传递给 Rsyslog 配置。
Red Hat OpenStack Platform (RHOSP)日志记录的默认格式为（'^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2} [0-9]{2}(.0-9]+ [0-9]+)?(DEBUG|INFO|WARNING|ERROR) '。
流程
要添加一个用于解析日志记录开始的正则表达式，请在配置中添加
startmsg.regex：NovaComputeLoggingSource: tag: openstack.nova.compute file: /some/other/path/nova-compute.log startmsg.regex: "^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}(.[0-9]+ \\+[0-9]+)? [A-Z]+ \\([a-z]+\\)
4.7. 测试 Rsyslog 和 Elasticsearch 之间的连接
在客户端，您可以验证 Rsyslog 和 Elasticsearch 之间的通信。
流程
-
进入到 Rsyslog 容器或主机上的
/var/log/rsyslog/omelasticsearch.log中的 Elasticsearch 连接日志文件/var/log/containers/rsyslog/omelasticsearch.log。如果此日志文件不存在，或者日志文件存在但不包含日志，则不会发生连接问题。如果日志文件存在并包含日志，Rsyslog 没有成功连接。
要测试来自服务器端的连接，请查看 Elasticsearch 日志是否有连接问题。
4.8. 服务器端日志
如果您有一个 Elasticsearch 集群正在运行，您必须配置 logging-environment-rsyslog.yaml 文件中的 RsyslogElasticsearchSetting 参数来连接 overcloud 节点上运行的 Rsyslog。要配置 RsyslogElasticsearchSetting 参数，请参阅 https://www.rsyslog.com/doc/v8-stable/configuration/modules/omelasticsearch.html
4.9. 回溯
当您遇到问题并开始故障排除时，您可以使用回溯日志来诊断问题。在日志文件中，追溯通常包含多行信息，与同一问题相关的所有内容。
rsyslog 提供了一个正则表达式，用于定义日志记录启动方式。每个日志记录通常以时间戳开头，并且回溯的第一行是包含此信息的唯一行。rsyslog 使用第一行捆绑缩进记录，并将其作为一个日志记录发送。
为此，使用了 <Service>LoggingSource 中的 startmsg.regex。以下正则表达式是 director 中所有 <service>LoggingSource 参数的默认值：
startmsg.regex='^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}(.[0-9]+ [0-9]+)? (DEBUG|INFO|WARNING|ERROR) '
当此默认与添加或修改的 LoggingSource 的日志记录不匹配时，您必须相应地更改 startmsg.regex。
4.10. OpenStack 服务的日志文件位置
每个 OpenStack 组件都有一个单独的日志记录目录，其中包含特定于正在运行的服务的文件。
4.10.1. 裸机置备(ironic)日志文件
| 服务 | 服务名称 | 日志路径 |
|---|---|---|
| OpenStack Ironic API | openstack-ironic-api.service | /var/log/containers/ironic/ironic-api.log |
| OpenStack Ironic Conductor | openstack-ironic-conductor.service | /var/log/containers/ironic/ironic-conductor.log |
4.10.2. Block Storage (cinder)日志文件
| 服务 | 服务名称 | 日志路径 |
|---|---|---|
| Block Storage API | openstack-cinder-api.service | /var/log/containers/cinder-api.log |
| 块存储备份 | openstack-cinder-backup.service | /var/log/containers/cinder/backup.log |
| 信息性信息 | cinder-manage 命令 | /var/log/containers/cinder/cinder-manage.log |
| 块存储调度程序 | openstack-cinder-scheduler.service | /var/log/containers/cinder/scheduler.log |
| 块存储卷 | openstack-cinder-volume.service | /var/log/containers/cinder/volume.log |
4.10.3. compute (nova)日志文件
| 服务 | 服务名称 | 日志路径 |
|---|---|---|
| OpenStack Compute API 服务 | openstack-nova-api.service | /var/log/containers/nova/nova-api.log |
| OpenStack 计算证书服务器 | openstack-nova-cert.service | /var/log/containers/nova/nova-cert.log |
| OpenStack 计算服务 | openstack-nova-compute.service | /var/log/containers/nova/nova-compute.log |
| OpenStack Compute Conductor 服务 | openstack-nova-conductor.service | /var/log/containers/nova/nova-conductor.log |
| OpenStack Compute VNC 控制台身份验证服务器 | openstack-nova-consoleauth.service | /var/log/containers/nova/nova-consoleauth.log |
| 信息性信息 | nova-manage 命令 | /var/log/containers/nova/nova-manage.log |
| OpenStack Compute NoVNC 代理服务 | openstack-nova-novncproxy.service | /var/log/containers/nova/nova-novncproxy.log |
| OpenStack 计算调度程序服务 | openstack-nova-scheduler.service | /var/log/containers/nova/nova-scheduler.log |
4.10.4. 仪表板(horizon)日志文件
| 服务 | 服务名称 | 日志路径 |
|---|---|---|
| 特定用户交互的日志 | 仪表板接口 | /var/log/containers/horizon/horizon.log |
Apache HTTP 服务器将多个额外的日志文件用于 Dashboard Web 界面，您可以使用网页浏览器或命令行客户端（如 keystone 和 nova）进行访问。下表中的日志文件有助于跟踪控制面板的使用和诊断错误：
| 用途 | 日志路径 |
|---|---|
| 所有已处理的 HTTP 请求 | /var/log/containers/httpd/horizon_access.log |
| HTTP 错误 | /var/log/containers/httpd/horizon_error.log |
| admin-role API 请求 | /var/log/containers/httpd/keystone_wsgi_admin_access.log |
| admin-role API 错误 | /var/log/containers/httpd/keystone_wsgi_admin_error.log |
| member-role API 请求 | /var/log/containers/httpd/keystone_wsgi_main_access.log |
| member-role API 错误 | /var/log/containers/httpd/keystone_wsgi_main_error.log |
另外还有 /var/log/containers/httpd/default_error.log，它存储在同一主机上运行的其他 Web 服务报告的错误。
4.10.5. Identity Service (keystone)日志文件
| 服务 | 服务名称 | 日志路径 |
|---|---|---|
| OpenStack 身份服务 | openstack-keystone.service | /var/log/containers/keystone/keystone.log |
4.10.6. Image Service (glance)日志文件
| 服务 | 服务名称 | 日志路径 |
|---|---|---|
| OpenStack Image Service API 服务器 | openstack-glance-api.service | /var/log/containers/glance/api.log |
| OpenStack Image Service Registry 服务器 | openstack-glance-registry.service | /var/log/containers/glance/registry.log |
4.10.7. networking (neutron)日志文件
| 服务 | 服务名称 | 日志路径 |
|---|---|---|
| OpenStack Neutron DHCP Agent | neutron-dhcp-agent.service | /var/log/containers/neutron/dhcp-agent.log |
| OpenStack 网络层 3 代理 | neutron-l3-agent.service | /var/log/containers/neutron/l3-agent.log |
| 元数据代理服务 | neutron-metadata-agent.service | /var/log/containers/neutron/metadata-agent.log |
| 元数据命名空间代理 | 不适用 | /var/log/containers/neutron/neutron-ns-metadata-proxy-UUID.log |
| Open vSwitch 代理 | neutron-openvswitch-agent.service | /var/log/containers/neutron/openvswitch-agent.log |
| OpenStack 网络服务 | neutron-server.service | /var/log/containers/neutron/server.log |
4.10.8. Object Storage (swift)日志文件
OpenStack Object Storage 仅将日志发送到系统日志功能。
默认情况下，所有 Object Storage 日志文件都会使用 local0、local1 和 local2 syslog 工具进入 /var/log/containers/swift.log。
对象存储的日志消息分为两大类：由 REST API 服务以及后台守护进程使用它们。API 服务消息包含每个 API 请求的一个行，其方式与常见的 HTTP 服务器类似；前端(Proxy)和后端(Account、Container、Object)服务也会发布此类消息。守护进程消息的结构较少，通常包含有关执行定期任务的守护进程的人类可读信息。但是，无论对象存储的哪个部分生成消息，源身份始终位于行首。
以下是代理消息的示例：
Apr 20 15:20:34 rhev-a24c-01 proxy-server: 127.0.0.1 127.0.0.1 20/Apr/2015/19/20/34 GET /v1/AUTH_zaitcev%3Fformat%3Djson%26marker%3Dtestcont HTTP/1.0 200 - python-swiftclient-2.1.0 AUTH_tk737d6... - 2 - txc454fa8ea4844d909820a-0055355182 - 0.0162 - - 1429557634.806570053 1429557634.822791100
以下是来自后台守护进程的临时信息示例：
Apr 27 17:08:15 rhev-a24c-02 object-auditor: Object audit (ZBF). Since Mon Apr 27 21:08:15 2015: Locally: 1 passed, 0 quarantined, 0 errors files/sec: 4.34 , bytes/sec: 0.00, Total time: 0.23, Auditing time: 0.00, Rate: 0.00 Apr 27 17:08:16 rhev-a24c-02 object-auditor: Object audit (ZBF) "forever" mode completed: 0.56s. Total quarantined: 0, Total errors: 0, Total files/sec: 14.31, Total bytes/sec: 0.00, Auditing time: 0.02, Rate: 0.04 Apr 27 17:08:16 rhev-a24c-02 account-replicator: Beginning replication run Apr 27 17:08:16 rhev-a24c-02 account-replicator: Replication run OVER Apr 27 17:08:16 rhev-a24c-02 account-replicator: Attempted to replicate 5 dbs in 0.12589 seconds (39.71876/s) Apr 27 17:08:16 rhev-a24c-02 account-replicator: Removed 0 dbs Apr 27 17:08:16 rhev-a24c-02 account-replicator: 10 successes, 0 failures
4.10.9. 编配(heat)日志文件
| 服务 | 服务名称 | 日志路径 |
|---|---|---|
| OpenStack Heat API 服务 | openstack-heat-api.service | /var/log/containers/heat/heat-api.log |
| OpenStack Heat Engine Service | openstack-heat-engine.service | /var/log/containers/heat/heat-engine.log |
| 编排服务事件 | 不适用 | /var/log/containers/heat/heat-manage.log |
4.10.11. 遥测(ceilometer)日志文件
| 服务 | 服务名称 | 日志路径 |
|---|---|---|
| OpenStack ceilometer 通知代理 | ceilometer_agent_notification | /var/log/containers/ceilometer/agent-notification.log |
| OpenStack ceilometer 中央代理 | ceilometer_agent_central | /var/log/containers/ceilometer/central.log |
| OpenStack ceilometer 集合 | openstack-ceilometer-collector.service | /var/log/containers/ceilometer/collector.log |
| OpenStack ceilometer 计算代理 | ceilometer_agent_compute | /var/log/containers/ceilometer/compute.log |
4.10.12. 支持服务的日志文件
下列服务由核心 OpenStack 组件使用，并拥有自己的日志目录和文件。
| 服务 | 服务名称 | 日志路径 |
|---|---|---|
| 消息代理(RabbitMQ) | rabbitmq-server.service |
/var/log/rabbitmq/rabbit@short_hostname.log |
| 数据库服务器(MariaDB) | mariadb.service | /var/log/mariadb/mariadb.log |
| 虚拟网络交换机(Open vSwitch) | openvswitch-nonetwork.service |
/var/log/openvswitch/ovsdb-server.log |
4.10.13. Aodh （警报服务）日志文件
| 服务 | 容器名称 | 日志路径 |
|---|---|---|
| 警报 API | aodh_api | /var/log/containers/httpd/aodh-api/aodh_wsgi_access.log |
| 警报评估器日志 | aodh_evaluator | /var/log/containers/aodh/aodh-evaluator.log |
| 警报监听程序 | aodh_listener | /var/log/containers/aodh/aodh-listener.log |
| 警报通知 | aodh_notifier | /var/log/containers/aodh/aodh-notifier.log |
4.10.14. Gnocchi （指标存储）日志文件
| 服务 | 容器名称 | 日志路径 |
|---|---|---|
| Gnocchi API | gnocchi_api | /var/log/containers/httpd/gnocchi-api/gnocchi_wsgi_access.log |
| Gnocchi 指标 | gnocchi_metricd | /var/log/containers/gnocchi/gnocchi-metricd.log |
| Gnocchi statsd | gnocchi_statsd | /var/log/containers/gnocchi/gnocchi-statsd.log |
第 5 章 collectd 插件
您可以根据 Red Hat OpenStack Platform (RHOSP) 16.1 环境配置多个 collectd 插件。
以下插件列表显示了可设置为覆盖默认值的可用 heat 模板 ExtraConfig 参数。每个部分都提供 ExtraConfig 选项的一般配置名称。例如，如果存在一个名为 example_plugin 的 collectd 插件，则插件标题的格式是 collectd::plugin::example_plugin。
请参考特定插件的可用参数表，如下例所示：
ExtraConfig: collectd::plugin::example_plugin::<parameter>: <value>
引用 Prometheus 或 Grafana 查询的特定插件的指标表。
collectd::plugin::aggregation
您可以使用 聚合 插件将多个值聚合到一起。使用聚合函数，如 sum、average、min 和 max 来计算指标，如平均和 CPU 统计。
| 参数 | 类型 |
|---|---|
| 主机 | 字符串 |
| plugin | 字符串 |
| plugininstance | 整数 |
| agg_type | 字符串 |
| 类型实例 | 字符串 |
| sethost | 字符串 |
| setplugin | 字符串 |
| setplugininstance | 整数 |
| settypeinstance | 字符串 |
| groupby | 字符串数组 |
| computesum | 布尔值 |
| computenum | 布尔值 |
| Computeaverage | 布尔值 |
| 计算最小值 | 布尔值 |
| 计算最大大小 | 布尔值 |
| calculatestddev | 布尔值 |
配置示例：
部署三个聚合配置以创建以下文件：
-
aggregator-calcCpuLoadAvg.conf：按主机和状态分组的所有 CPU 内核的平均 CPU 负载 -
aggregator-calcCpuLoadMinMax.conf: : minimum and maximum CPU load groups by host and state -
aggregator-calcMemoryTotalMaxAvg.conf：最大、平均值和总计内存，按类型分组的内存总数
聚合配置使用默认的 CPU 和内存插件配置。
parameter_defaults:
CollectdExtraPlugins:
- aggregation
ExtraConfig:
collectd::plugin::aggregation::aggregators:
calcCpuLoadAvg:
plugin: "cpu"
agg_type: "cpu"
groupby:
- "Host"
- "TypeInstance"
calculateaverage: True
calcCpuLoadMinMax:
plugin: "cpu"
agg_type: "cpu"
groupby:
- "Host"
- "TypeInstance"
calculatemaximum: True
calculateminimum: True
calcMemoryTotalMaxAvg:
plugin: "memory"
agg_type: "memory"
groupby:
- "TypeInstance"
calculatemaximum: True
calculateaverage: True
calculatesum: Truecollectd::plugin::amqp1
使用 amqp1 插件将值写入 amqp1 消息总线，例如 AMQ Interconnect。
| 参数 | 类型 |
|---|---|
| manage_package | 布尔值 |
| 传输 | 字符串 |
| 主机 | 字符串 |
| port | 整数 |
| user | 字符串 |
| password | 字符串 |
| address | 字符串 |
| 实例 | hash |
| retry_delay | 整数 |
| send_queue_limit | 整数 |
| interval | 整数 |
使用 send_queue_limit 参数来限制传出指标队列的长度。
如果没有 AMQP1 连接，则插件将继续队列消息来发送，这会导致未绑定的内存消耗。默认值为 0，即禁用传出指标队列。
如果缺少指标，则增大 send_queue_limit 参数的值。
配置示例：
parameter_defaults:
CollectdExtraPlugins:
- amqp1
ExtraConfig:
collectd::plugin::amqp1::send_queue_limit: 5000
collectd::plugin::apache
使用 apache 插件从 Apache Web 服务器提供的 mod_status 插件收集 Apache 数据。提供的每个实例都有一个按间隔 值（以秒为单位）。如果您为实例提供 超时 间隔参数，则该值为 毫秒。
| 参数 | 类型 |
|---|---|
| 实例 | hash |
| interval | 整数 |
| manage-package | 布尔值 |
| package_install_options | list |
| 参数 | 类型 |
|---|---|
| url | HTTP URL |
| user | 字符串 |
| password | 字符串 |
| verifypeer | 布尔值 |
| verifyhost | 布尔值 |
| cacert | AbsolutePath |
| sslciphers | 字符串 |
| timeout | 整数 |
配置示例：
在本例中，实例名称为 localhost，它连接到 Apache Web 服务器，地址为 http://10.0.0.111/mod_status?auto。您必须将 ?auto 附加到 URL 的末尾，以防止状态页面返回为与插件不兼容的类型。
parameter_defaults:
CollectdExtraPlugins:
- apache
ExtraConfig:
collectd::plugin::apache::instances:
localhost:
url: "http://10.0.0.111/mod_status?auto"其他资源
有关配置 apache 插件的更多信息，请参阅 apache。
collectd::plugin::battery
使用 battery 插件报告笔记本电脑的剩余容量、能力或自愿。
| 参数 | 类型 |
|---|---|
| values_percentage | 布尔值 |
| report_degraded | 布尔值 |
| query_state_fs | 布尔值 |
| interval | 整数 |
其他资源
有关配置 btery 插件 的更多信息，请参阅 battery。
collectd::plugin::bind
使用 bind 插件检索与 DNS 服务器查询和响应相关的编码统计。插件将值提交到 collectd。
| 参数 | 类型 |
|---|---|
| url | HTTP URL |
| memorystats | 布尔值 |
| opcodes | 布尔值 |
| parsetime | 布尔值 |
| qtypes | 布尔值 |
| resolverstats | 布尔值 |
| serverstats | 布尔值 |
| zonemaintstats | 布尔值 |
| 视图 | 数组 |
| interval | 整数 |
| 参数 | 类型 |
|---|---|
| name | 字符串 |
| qtypes | 布尔值 |
| resolverstats | 布尔值 |
| cacherrsets | 布尔值 |
| zones | 字符串列表 |
配置示例：
parameter_defaults:
CollectdExtraPlugins:
- bind
ExtraConfig:
collectd::plugins::bind:
url: http://localhost:8053/
memorystats: true
opcodes: true
parsetime: false
qtypes: true
resolverstats: true
serverstats: true
zonemaintstats: true
views:
- name: internal
qtypes: true
resolverstats: true
cacherrsets: true
- name: external
qtypes: true
resolverstats: true
cacherrsets: true
zones:
- "example.com/IN"
collectd::plugin::ceph
使用 ceph 插件从 ceph 守护进程收集数据。
| 参数 | 类型 |
|---|---|
| Daemon | 数组 |
| longrunavglatency | 布尔值 |
| convertspecialmetrictypes | 布尔值 |
| package_name | 字符串 |
配置示例：
parameter_defaults:
ExtraConfig:
collectd::plugin::ceph::daemons:
- ceph-osd.0
- ceph-osd.1
- ceph-osd.2
- ceph-osd.3
- ceph-osd.4
如果 Object Storage Daemon (OSD)不在每个节点中，您必须列出 OSD。
当您部署 collectd 时，ceph 插件添加到 Ceph 节点。不要将 Ceph 节点上的 ceph 插件添加到 CollectdExtraPlugins，因为这会导致部署失败。
其他资源
有关配置 ceph 插件的更多信息，请参阅 ceph。
collectd::plugins::cgroups
使用 cgroup 插件收集 cgroup 中进程的信息。
| 参数 | 类型 |
|---|---|
| ignore_selected | 布尔值 |
| interval | 整数 |
| Cgroups | list |
其他资源
有关配置 cgroups 插件的更多信息，请参阅 cgroups。
collectd::plugin::connectivity
使用 connectivity 插件监控网络接口的状态。
如果没有列出接口，则默认监控所有接口。
| 参数 | 类型 |
|---|---|
| interfaces | 数组 |
配置示例：
parameter_defaults:
ExtraConfig:
collectd::plugin::connectivity::interfaces:
- eth0
- eth1
其他资源
有关配置连接插件的更多信息，请参阅 连接 。
collectd::plugin::conntrack
使用 conntrack 插件跟踪 Linux 连接跟踪表中的条目数。此插件没有参数。
collectd::plugin::contextswitch
使用 ContextSwitch 插件收集系统处理的上下文切换数。唯一可用的参数是 interval，这是以秒为单位定义的轮询间隔。
其他资源
有关配置 contextswitch 插件的更多信息，请参阅 contextswitch。
collectd::plugin::cpu
使用 cpu 插件监控 CPU 在各种状态花费的时间，如空闲、执行用户代码、执行系统代码、等待 IO-operations 和其他状态。
cpu 插件会收集 jiffies，而不是百分比值。jiffy 的值取决于您的硬件平台的时钟频率，因此不是一个绝对的时间间隔单位。
要报告百分比值，请将布尔值参数 reportbycpu 和 reportbystate 设置为 true，然后将布尔值 值percentage 设置为 true。
此插件默认为启用。
| Name | 描述 | 查询 |
|---|---|---|
| idle | 空闲时间量 |
|
| interrupt | 由中断阻止的 CPU |
|
| nice | 运行低优先级进程的时间 |
|
| softirq | 保留中断请求所花费的周期数量 |
|
| steal | 虚拟 CPU 等待实际 CPU 的时间百分比，而虚拟机监控程序为另一个虚拟处理器提供服务 |
|
| system | 系统级别花费的时间（内核） |
|
| user | 用户进程使用的差异 |
|
| wait | CPU 在未完成的 I/O 请求时等待 |
|
| 参数 | 类型 | 默认值 |
|---|---|---|
| reportbystate | 布尔值 | true |
| valuespercentage | 布尔值 | true |
| reportbycpu | 布尔值 | true |
| reportnumcpu | 布尔值 | false |
| reportgueststate | 布尔值 | false |
| subtractgueststate | 布尔值 | true |
| interval | 整数 | 120 |
配置示例：
parameter_defaults:
CollectdExtraPlugins:
- cpu
ExtraConfig:
collectd::plugin::cpu::reportbystate: true
其他资源
有关配置 cpu 插件的更多信息，请参阅 cpu。
collectd::plugin::cpufreq
使用 cpufreq 插件收集当前的 CPU 频率。此插件没有参数。
collectd::plugin::csv
使用 csv 插件将值写入 CSV 格式的本地文件。
| 参数 | 类型 |
|---|---|
| datadir | 字符串 |
| storerates | 布尔值 |
| interval | 整数 |
collectd::plugin::df
使用 df 插件收集文件系统的磁盘空间使用信息。
此插件默认为启用。
| Name | 描述 | 查询 |
|---|---|---|
| free | 可用磁盘空间量 |
|
| 保留 | 保留磁盘空间量 |
|
| 使用的 | 已用磁盘空间量 |
|
| 参数 | 类型 | 默认值 |
|---|---|---|
| devices | 数组 |
|
| fstypes | 数组 |
|
| ignoreselected | 布尔值 | true |
| 挂载点 | 数组 |
|
| reportbydevice | 布尔值 | true |
| reportinodes | 布尔值 | true |
| reportreserved | 布尔值 | true |
| valuesabsolute | 布尔值 | true |
| valuespercentage | 布尔值 | false |
配置示例：
parameter_defaults:
ExtraConfig:
collectd::plugin::df::fstypes: ['tmpfs','xfs']
其他资源
有关配置 df 插件的更多信息，请参阅 df。
collectd::plugin::disk
使用 disk 插件收集硬盘的性能统计信息，如果支持，则需使用分区。
所有磁盘会被默认监控。您可以使用 ignoreselected 参数来忽略磁盘列表。示例配置会忽略 sda、sdb 和 sdc 磁盘，并监控列表中不包含的所有磁盘。
此插件默认为启用。
| 参数 | 类型 | 默认值 |
|---|---|---|
| disks | 数组 |
|
| ignoreselected | 布尔值 | false |
| udevnameattr | 字符串 | <undefined> |
| Name | 描述 |
|---|---|
| 合并 | 可以合并在一起的已排队操作数量，例如，一个物理磁盘访问服务两个或者多个逻辑操作。 |
| time | I/O 合作完成的平均时间。该值可能不正确。 |
| io_time | 进行 I/O (ms)的时间。您可以使用此指标作为设备负载百分比。值 1 秒匹配 100% 的负载。 |
| weighted_io_time | 测量 I/O 完成时间和可能积累的积压。 |
| pending_operations | 显示待处理 I/O 操作的队列大小。 |
配置示例：
parameter_defaults:
ExtraConfig:
collectd::plugin::disk::disks: ['sda', 'sdb', 'sdc']
collectd::plugin::disk::ignoreselected: true
其他资源
有关配置磁盘插件的更多信息，请参阅 磁盘 。
collectd::plugin::hugepages
使用 hugepages 插件收集巨页信息。
此插件默认为启用。
| 参数 | 类型 | 默认值 |
|---|---|---|
| report_per_node_hp | 布尔值 | true |
| report_root_hp | 布尔值 | true |
| values_pages | 布尔值 | true |
| values_bytes | 布尔值 | false |
| values_percentage | 布尔值 | false |
配置示例：
parameter_defaults:
ExtraConfig:
collectd::plugin::hugepages::values_percentage: true
其他资源
-
有关配置
巨页插件的更多信息，请参阅 大页。
collectd::plugin::interface
使用 interface 插件来测量 octets 中的接口流量，每秒数据包每秒和错误率。
此插件默认为启用。
| 参数 | 类型 | 默认 |
|---|---|---|
| interfaces | 数组 |
|
| ignoreselected | 布尔值 | false |
| reportinactive | 布尔值 | true |
配置示例：
parameter_defaults:
ExtraConfig:
collectd::plugin::interface::interfaces:
- lo
collectd::plugin::interface::ignoreselected: true
其他资源
-
有关配置
接口插件的更多信息，请参阅 接口。
collectd::plugin::load
使用 load 插件收集系统负载以及系统使用的概览。
此插件默认为启用。
| 参数 | 类型 | 默认 |
|---|---|---|
| report_relative | 布尔值 | true |
配置示例：
parameter_defaults:
ExtraConfig:
collectd::plugin::load::report_relative: false
其他资源
-
有关配置
load插件的更多信息，请参阅 加载。
collectd::plugin::mcelog
使用 mcelog 插件，在出现时发送通知和与机器检查例外相关的统计信息。将 mcelog 配置为以守护进程模式运行并启用日志记录功能。
| 参数 | 类型 |
|---|---|
| Mcelogfile | 字符串 |
| 内存 |
hash |
配置示例：
parameter_defaults:
CollectdExtraPlugins: mcelog
CollectdEnableMcelog: true
其他资源
-
有关配置
mcelog插件的更多信息，请参阅 mcelog。
collectd::plugin::memcached
使用 memcached 插件检索有关 memcached 缓存使用情况、内存以及其他相关信息的信息。
| 参数 | 类型 |
|---|---|
| 实例 | hash |
| interval | 整数 |
配置示例：
parameter_defaults:
CollectdExtraPlugins:
- memcached
ExtraConfig:
collectd::plugin::memcached::instances:
local:
host: "%{hiera('fqdn_canonical')}"
port: 11211
其他资源
-
有关配置
memcached插件的更多信息，请参阅 memcached。
collectd::plugin::memory
使用 memory 插件检索有关系统内存的信息。
此插件默认为启用。
| 参数 | 类型 |
|---|---|
| 默认值 | valuesabsolute |
| 布尔值 | true |
| valuespercentage | 布尔值 |
配置示例：
parameter_defaults:
ExtraConfig:
collectd::plugin::memory::valuesabsolute: true
collectd::plugin::memory::valuespercentage: false
其他资源
-
有关配置
内存插件的更多信息，请参阅 内存。
collectd::plugin::ntpd
使用 ntpd 插件查询本地 NTP 服务器，该服务器已配置为允许访问统计数据，并检索有关配置的参数和时间同步状态的信息。
| 参数 | 类型 |
|---|---|
| 主机 | Hostname |
| port | 端口号（整数） |
| reverselookups | 布尔值 |
| includeunitid | 布尔值 |
| interval | 整数 |
配置示例：
parameter_defaults:
CollectdExtraPlugins:
- ntpd
ExtraConfig:
collectd::plugin::ntpd::host: localhost
collectd::plugin::ntpd::port: 123
collectd::plugin::ntpd::reverselookups: false
collectd::plugin::ntpd::includeunitid: false
其他资源
-
有关配置
ntpd插件的更多信息，请参阅 ntpd。
collectd::plugin::ovs_stats
使用 ovs_stats 插件收集 OVS 连接接口的统计信息。ovs_stats 插件使用 OVSDB 管理协议(RFC7047)监控机制从 OVSDB 获取统计信息。
| 参数 | 类型 |
|---|---|
| address | 字符串 |
| Bridge | list |
| port | 整数 |
| socket | 字符串 |
配置示例：
以下示例演示了如何启用 ovs_stats 插件。如果使用 OVS 部署 overcloud，则不需要启用 ovs_stats 插件。
parameter_defaults:
CollectdExtraPlugins:
- ovs_stats
ExtraConfig:
collectd::plugin::ovs_stats::socket: '/run/openvswitch/db.sock'其他资源
-
有关配置
ovs_stats插件的更多信息，请参阅 ovs_stats。
collectd::plugin::processes
进程插件 提供有关系统进程的信息。如果没有指定进程匹配，则插件仅通过状态收集进程数量和进程分叉率。
要收集特定进程的更多详细信息，您可以使用 process 参数指定进程名称或 process_match 选项指定与正则表达式匹配的进程名称。process_match 输出的统计信息按进程名称分组。
此插件默认为启用。
| 参数 | 类型 | 默认值 |
|---|---|---|
| 进程 | 数组 | <undefined> |
| process_matches | 数组 | <undefined> |
| collect_context_switch | 布尔值 | <undefined> |
| collect_file_descriptor | 布尔值 | <undefined> |
| collect_memory_maps | 布尔值 | <undefined> |
其他资源
-
有关配置进程插件的更多信息，请参阅
进程。https://collectd.org/documentation/manpages/collectd.conf.5.shtml#plugin_processes
collectd::plugin::smart
使用 智能 插件从节点上的物理磁盘收集 SMART 信息。您还必须将参数 CollectdContainerAdditionalCapAdd 设置为 CAP_SYS_RAWIO 以允许 智能 插件读取 SMART 遥测。如果您没有设置 CollectdContainerAdditionalCapAdd 参数，则会将以下消息写入 collectd 错误日志：
smart 插件：以 root 用户身份运行 collectd，但缺少 CAP_SYS_RAWIO 功能。插件的读取功能可能会失败。您的 init 系统是否丢弃功能？。
| 参数 | 类型 |
|---|---|
| disks | 数组 |
| ignoreselected | 布尔值 |
| interval | 整数 |
配置示例：
parameter_defaults: CollectdExtraPlugins: - smart CollectdContainerAdditionalCapAdd: "CAP_SYS_RAWIO"
附加信息
-
有关配置
智能插件的更多信息，请参阅 smart。
collectd::plugin::swap
使用 swap 插件收集有关可用和已用 swap 空间的信息。
| 参数 | 类型 |
|---|---|
| reportbydevice | 布尔值 |
| reportbytes | 布尔值 |
| valuesabsolute | 布尔值 |
| valuespercentage | 布尔值 |
| reportio | 布尔值 |
配置示例：
parameter_defaults:
CollectdExtraPlugins:
- swap
ExtraConfig:
collectd::plugin::swap::reportbydevice: false
collectd::plugin::swap::reportbytes: true
collectd::plugin::swap::valuesabsolute: true
collectd::plugin::swap::valuespercentage: false
collectd::plugin::swap::reportio: true
collectd::plugin::tcpconns
使用 tcpconns 插件收集有关配置的端口入站或出站的 TCP 连接数的信息。本地端口配置代表到端口的入站连接。远程端口配置代表来自端口的出站连接。
| 参数 | 类型 |
|---|---|
| localports | 端口(ay) |
| remoteports | 端口(ay) |
| listening | 布尔值 |
| allportssummary | 布尔值 |
配置示例：
parameter_defaults:
CollectdExtraPlugins:
- tcpconns
ExtraConfig:
collectd::plugin::tcpconns::listening: false
collectd::plugin::tcpconns::localports:
- 22
collectd::plugin::tcpconns::remoteports:
- 22
collectd::plugin::thermal
使用 rmal 插件检索 ACPI 热区域信息。
| 参数 | 类型 |
|---|---|
| devices | 数组 |
| ignoreselected | 布尔值 |
| interval | 整数 |
配置示例：
parameter_defaults: CollectdExtraPlugins: - thermal
collectd::plugin::uptime
使用 uptime 插件收集有关系统正常运行时间的信息。
此插件默认为启用。
| 参数 | 类型 |
|---|---|
| interval | 整数 |
collectd::plugin::virt
使用 virt 插件通过 libvirt API 在主机上为虚拟机收集 CPU、磁盘、网络负载和其他指标。
此插件在计算主机上默认启用。
| 参数 | 类型 |
|---|---|
| 连接 | 字符串 |
| refresh_interval | hash |
| domain | 字符串 |
| block_device | 字符串 |
| interface_device | 字符串 |
| ignore_selected | 布尔值 |
| plugin_instance_format | 字符串 |
| hostname_format | 字符串 |
| interface_format | 字符串 |
| extra_stats | 字符串 |
配置示例：
ExtraConfig: collectd::plugin::virt::hostname_format: "name uuid hostname" collectd::plugin::virt::plugin_instance_format: metadata
其他资源
有关配置 virt 插件的更多信息，请参阅 virt。
collectd::plugin::vmem
使用 vmem 插件从内核子系统收集虚拟内存的信息。
| 参数 | 类型 |
|---|---|
| 详细 | 布尔值 |
| interval | 整数 |
配置示例：
parameter_defaults:
CollectdExtraPlugins:
- vmem
ExtraConfig:
collectd::plugin::vmem::verbose: true
collectd::plugin::write_http
使用 write_http 输出插件，使用带有 JSON 的 POST 请求和编码指标，或使用 PUTVAL 命令向 HTTP 服务器提交值。
| 参数 | 类型 |
|---|---|
| 确保 | enum[present,absent] |
| 节点 | hash[String, Hash[String, Scalar]] |
| urls | hash[String, Hash[String, Scalar]] |
| manage_package | 布尔值 |
配置示例：
parameter_defaults:
CollectdExtraPlugins:
- write_http
ExtraConfig:
collectd::plugin::write_http::nodes:
collectd:
url: “http://collectd.tld.org/collectd”
metrics: true
header: “X-Custom-Header: custom_value"
其他资源
-
有关配置
write_http插件的更多信息，请参阅 write_http。
collectd::plugin::write_kafka
使用 write_kafka 插件将值发送到 Kafka 主题。使用一个或多个主题块配置 write_kafka 插件。对于每个主题块，您必须指定一个唯一名称和一个 Kafka producer。您可以使用主题块中的以下每主题参数：
| 参数 | 类型 |
|---|---|
| kafka_hosts | 数组[String] |
| 主题 | hash |
| 属性 | hash |
| meta | hash |
配置示例：
parameter_defaults:
CollectdExtraPlugins:
- write_kafka
ExtraConfig:
collectd::plugin::write_kafka::kafka_hosts:
- remote.tld:9092
collectd::plugin::write_kafka::topics:
mytopic:
format: JSON
其他资源：
有关如何配置 write_kafka 插件的更多信息，请参阅 write_kafka。
