数据收集¶

Telemetry 在 OpenStack 中的主要职责是收集有关系统的信息，这些信息可供计费系统使用或由分析工具解释。

收集的数据可以以样本或事件的形式存储在支持的数据库中，这些数据库列于支持的数据库中。

可用的数据收集机制是

通知: 通过从配置的消息队列系统中消费消息，处理来自其他 OpenStack 服务的通知。
轮询: 直接从 hypervisor 处检索信息，或使用其他 OpenStack 服务的 API。

通知¶

所有 OpenStack 服务都会发送有关已执行的操作或系统状态的通知。多个通知携带可以计量化的信息。例如，由 OpenStack Compute 服务创建的 VM 实例的 CPU 时间。

通知代理负责消费通知。此组件负责从消息总线消费并转换通知为事件和测量样本。

默认情况下，通知代理配置为构建事件和样本。要启用选择性数据模型，请使用 pipelines 选项在 [notification] 部分下设置所需的管道。

此外，通知代理还负责发送到任何支持的发布者目标，例如 gnocchi 或 panko。这些服务将数据持久化到配置的数据库中。

不同的 OpenStack 服务会发出多个通知，这些通知涉及系统在正常运行期间发生的各种类型的事件。 Telemetry 服务并非消费所有这些通知，因为其意图只是捕获可计费事件和可用于监控或分析目的的通知。处理的通知包含在 ceilometer.sample.endpoint 命名空间下。

注意

某些服务需要额外的配置才能发出通知。请参阅安装和配置控制器服务以获取更多详细信息。

计量定义¶

Telemetry 服务通过过滤其他 OpenStack 服务发出的通知来收集一部分计量器。您可以在单独的配置文件中找到计量定义，该文件名为 ceilometer/data/meters.d/meters.yaml。这使得操作员/管理员可以通过更新 meters.yaml 文件来向 Telemetry 项目添加新的计量器，而无需进行额外的代码更改。

注意

应谨慎修改 meters.yaml 文件。除非有意，否则请勿从文件中删除任何现有的计量定义。此外，在某些情况下，收集的计量器可能与文档中引用的计量器不同。

它还支持加载多个计量定义文件，并允许用户根据不同类型的指标将自己的计量定义添加到 /etc/ceilometer/meters.d 目录下的多个文件中。

标准的计量定义如下所示

---
metric:
  - name: 'meter name'
    event_type: 'event name'
    type: 'type of meter eg: gauge, cumulative or delta'
    unit: 'name of unit eg: MB'
    volume: 'path to a measurable value eg: $.payload.size'
    resource_id: 'path to resource id eg: $.payload.id'
    project_id: 'path to project id eg: $.payload.owner'
    metadata: 'addiitonal key-value data describing resource'

上面的定义显示了一个简单的计量定义，其中包含一些字段，其中 name、event_type、type、unit 和 volume 是必需的。如果事件类型匹配，则会为计量器生成样本。

meters.yaml 文件包含 Telemetry 从通知中收集的所有计量器的样本定义。每个字段的值都通过使用 JSON 路径来指定，以便从通知消息中找到正确的值。为了能够指定正确的字段，您需要了解所消费通知的格式。需要在通知消息中搜索的值使用以 $. 开头的 JSON 路径设置。例如，如果您需要 payload 中的 size 信息，则可以将其定义为 $.payload.size。

通知消息可能包含多个计量器。您可以使用 * 在计量定义中捕获所有计量器并分别生成样本。您可以使用通配符，如以下示例所示

---
metric:
  - name: $.payload.measurements.[*].metric.[*].name
    event_type: 'event_name.*'
    type: 'delta'
    unit: $.payload.measurements.[*].metric.[*].unit
    volume: payload.measurements.[*].result
    resource_id: $.payload.target
    user_id: $.payload.initiator.id
    project_id: $.payload.initiator.project_id

在上面的示例中，name 字段是一个与通知消息中定义的计量器名称列表匹配的 JSON 路径。

您可以在 JSON 路径上使用复杂的运算。在以下示例中，volume 和 resource_id 字段执行算术和字符串连接

---
metric:
- name: 'compute.node.cpu.idle.percent'
  event_type: 'compute.metrics.update'
  type: 'gauge'
  unit: 'percent'
  volume: payload.metrics[?(@.name='cpu.idle.percent')].value * 100
  resource_id: $.payload.host + "_" + $.payload.nodename

您可以使用 timedelta 插件来评估来自一个通知的两个 datetime 字段之间的秒数差异。

---
metric:
- name: 'compute.instance.booting.time'
  event_type: 'compute.instance.create.end'
 type: 'gauge'
 unit: 'sec'
 volume:
   fields: [$.payload.created_at, $.payload.launched_at]
   plugin: 'timedelta'
 project_id: $.payload.tenant_id
 resource_id: $.payload.instance_id

轮询¶

Telemetry 服务旨在存储基础设施的复杂图像。实现此目标需要比每个服务发布的事件和通知所提供的信息更多的信息。有些信息不会直接发出，例如 VM 实例的资源使用情况。

因此，Telemetry 使用另一种方法通过轮询基础设施（包括不同 OpenStack 服务的 API 和其他资产，如 hypervisor）来收集此数据。后一种情况需要与计算主机更紧密的交互。为了解决此问题，Telemetry 使用基于代理的架构来满足数据收集的要求。

配置¶

轮询规则由 polling.yaml 文件定义。它定义了要启用轮询器以及应轮询的间隔。

每个源配置封装了与轮询器入口点匹配的计量器名称匹配。它还包括：轮询间隔确定、可选的资源枚举或发现。

由轮询生成的所有样本都放置在队列中，由通知代理加载的管道配置处理。

轮询定义可能如下所示

---
sources:
  - name: 'source name'
    interval: 'how often the samples should be generated'
    meters:
      - 'meter filter'
    resources:
      - 'list of resource URLs'
    discovery:
      - 'list of discoverers'

源部分中的 interval 参数定义了样本生成的频率（以秒为单位）。

轮询插件根据每个源的 section 及其 meters 参数与插件的计量器名称匹配而被调用。它的匹配逻辑与管道过滤相同。

轮询源的可选 resources 部分允许配置静态资源 URL 列表。所有静态定义的资源列表都传递给各个轮询器进行轮询。

轮询源的可选 discovery 部分包含发现器列表。这些发现器可用于动态发现轮询器要轮询的资源。

如果同时设置了 resources 和 discovery，则传递给轮询器的最终资源将是发现器返回的动态资源与 resources 部分中定义的静态资源的组合。

代理¶

有三种类型的代理支持轮询机制，分别是 compute agent、central agent 和 IPMI agent。在底层，所有类型的轮询代理都是相同的 ceilometer-polling 代理，只是它们从不同的命名空间加载不同的轮询插件（轮询器）来收集数据。以下子部分提供了有关这些组件的架构和配置细节的更多信息。

运行 ceilometer-agent-compute 与

$ ceilometer-polling --polling-namespaces compute

运行 ceilometer-agent-central 与

$ ceilometer-polling --polling-namespaces central

运行 ceilometer-agent-ipmi 与

$ ceilometer-polling --polling-namespaces ipmi

计算代理¶

此代理负责收集 OpenStack 部署中各个计算节点上 VM 实例的资源使用数据。此机制需要与 hypervisor 更紧密的交互，因此单独的代理类型可以满足相关计量器的收集，该代理放置在主机机器上以本地检索此信息。

必须在每个计算节点上安装一个计算代理实例，安装说明可以在安装教程和指南的安装和配置控制器服务部分中找到。

受支持的 hypervisor 列表可以在支持的 hypervisor 中找到。计算代理使用安装在计算主机上的 hypervisor 的 API。因此，每个虚拟化后端提供的支持的计量器可能不同，因为每个检查工具提供不同的计量器集。

收集的计量器列表可以在 OpenStack Compute 中找到。 support 列提供了有关 Telemetry 服务支持的每个 hypervisor 可用的计量器的信息。

中央代理¶

此代理负责轮询公共 REST API 以检索有关 OpenStack 资源的额外信息，这些信息尚未通过通知公开。

使用此代理轮询的一些服务包括

OpenStack Networking
OpenStack 对象存储
OpenStack 块存储

要安装和配置此服务，请使用安装教程和指南的为 Red Hat Enterprise Linux 和 CentOS 安装和配置部分。

虽然 Ceilometer 具有一组默认轮询代理，但操作员可以通过动态轮询器子系统动态轮询器子系统的介绍动态添加新的轮询器。

IPMI 代理¶

此代理负责收集 OpenStack 部署中各个计算节点上的 IPMI 传感器数据和 Intel Node Manager 数据。此代理需要一个支持 IPMI 的节点，该节点安装了 ipmitool 实用程序，该实用程序通常用于各种 Linux 发行版上的 IPMI 控制。

可以安装 IPMI 代理实例在每个支持 IPMI 的计算节点上，除非该节点由 Bare metal 服务管理，并且 Bare metal 服务中的 conductor.send_sensor_data 选项设置为 true。在不支持 IPMI 的计算节点上安装此代理不会造成任何危害，因为该代理会检查硬件，如果不可用 IPMI 支持，则返回空数据。建议仅在支持 IPMI 的节点上安装 IPMI 代理，以提高性能。

收集的计量器列表可以在 IPMI 计量器中找到。

注意

请勿在一个计算节点上部署 IPMI 代理和 Bare metal 服务。如果设置了 conductor.send_sensor_data，则此错误配置会导致重复的 IPMI 传感器样本。

数据收集

数据收集¶

通知¶

计量定义¶

轮询¶

配置¶

代理¶

计算代理¶

中央代理¶

IPMI 代理¶

Ceilometer 25.0.0.0rc2.dev2

页面内容