这篇文章主要讲解了“ceilometer的数据处理和管道怎么配置”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“ceilometer的数据处理和管道怎么配置”吧！

网站建设哪家好，找创新互联建站！专注于网页设计、网站建设、微信开发、微信小程序定制开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了郁南免费建站欢迎大家使用！

处理数据的机制称为管道。 在配置级别上，管道描述数据来源和相应的汇合点之间的耦合，用于转换和公布数据。 此功能由通知代理处理。

source是数据的生产者: samples 或 events 。 实际上， 它是一组为匹配的 meters和事件类型集合 发出数据点的通知处理程序。

每个source配置将名称匹配和映射封装到一个或多个 sinks 中以供发布。

另一方面，sink是数据的使用者，为转换和发布来自相关源的数据提供逻辑。

实际上，sink描述了一系列的处理程序。 该 chain 从零或更多的 transformers 开始，并以一个或多个 publishers 结束。 chain中的第一个transformer从对应的source传递数据， 采取一些操作， 例如 deriving变动率, 执行单位转换或聚合, 然后 publishing。

管道配置

通知代理支持两种管道: 一个处理 samples，另一个处理events。 通过在[notifications]设置管道选项，可以启用和禁用管道。

默认情况下，每个管道的实际配置存储在单独的配置文件中: pipeline.yaml 和 event_pipeline.yaml。配置文件的位置可以由 pipeline_cfg_file 和 event_pipeline_cfg_file 选项设置，配置文件模板查看：Ceilometer Configuration Options。

meter pipeline 的定义如下的：

---
sources:
  - name: 'source name'
    meters:
      - 'meter filter'
    sinks:
      - 'sink name'
sinks:
  - name: 'sink name'
    transformers: 'definition of transformers'
    publishers:
      - 'list of publishers'

有几种方法可以定义管道源的meters列表。 有效计量表的清单可以在 Measurements中找到。 有种方式可以定义所有的 meters 或者只包含或过滤部分 meters，一个 source 配置操作应该按下面方式：

• 包含所有的 meters 使用*号通配符。但明智的做法是只选择您打算使用的meters，以避免使用了未使用过的数据淹没了计量数据库。

• 要定义meters列表，可使用下列任何一种:

                要包含部分meters，可使用 meter_name 语法。

                要过滤部分meters，可使用 !meter_name 语法。

备注： OpenStack遥测服务在管道之间没有任何重复检查， 如果您在多个管道中添加了一个 meter，则假定重复是有意的，并且可以根据指定的接收器多次存储。

上述定义方法可用于以下组合：

• 只使用通配符符号。

• 使用 included meters。

• 使用 excluded meters。

• 通配符与 excluded 结合使用。

备注： 以上变化中至少有一种应该被包括在meters section。 Included 和excluded meters不能共存于同一管道中。 通配符和included meters 不能在同一管道定义部分中共存。

管道sink的 transformers部分提供了添加 transformers定义列表的可能性。 现有的transformers：

Transformer 的名字	配置的引用名称
Accumulator	accumulator
Aggregator	aggregator
Arithmetic	arithmetic
Rate of change	rate_of_change
Unit conversion	unit_conversion
Delta	delta

发布者部分包含发布者列表，其中样本数据应该在可能的转换之后发送。

类似地，事件管道定义看起来像下面这样:

---
sources:
  - name: 'source name'
    events:
      - 'event filter'
    sinks:
      - 'sink name'
sinks:
  - name: 'sink name'
    publishers:
      - 'list of publishers'

事件过滤器使用与meter管道相同的过滤逻辑。

Transformers

  备注：Transformers在内存中保存数据，因此不能保证在某些场景下的持久性。 使用像Gnocchi这样的解决方案可以实现更持久、更有效的解决方案。

转换器的定义可以包含以下字段:

• name转换器的名称

• parameters转换器的参数

参数部分可以包含transformer特定字段,  在变化速率的案例中，像source和target字段包含有不同的子字段，这依赖于 transformer 的实现。

下面是支持的 transformers:

Rate of change transformer

此种转换器是计算两个数据点之间的时间变化值。下面的transformer例子定义了 cpu_util meter:

transformers:
    - name: "rate_of_change"
      parameters:
          target:
              name: "cpu_util"
              unit: "%"
              type: "gauge"
              scale: "100.0 / (10**9 * (resource_metadata.cpu_number or 1))"

变化率的transformer从cpu计数器的样本值生成 cpu_util meter， 它代表了纳秒的累计CPU时间。 上面的transformer定义定义了一个比例因子(用于纳秒和多cpu), 在转换之前应用于从cpu表的顺序值派生出一个带有%单位的度量样本序列。

磁盘I/O速率的定义，也由变化率的转换器生成 :

transformers:
    - name: "rate_of_change"
      parameters:
          source:
              map_from:
                  name: "disk\\.(read|write)\\.(bytes|requests)"
                  unit: "(B|request)"
          target:
              map_to:
                  name: "disk.\\1.\\2.rate"
                  unit: "\\1/s"
              type: "gauge"

Unit conversion transformer

此种转换器应用于单位转换。 它接收meter的volume，并将它乘以给定的尺度表达式。 也支持如 transformer变化率一样带有 map_from 和 map_to 字段。

样本配置:

transformers:
    - name: "unit_conversion"
      parameters:
          target:
              name: "disk.kilobytes"
              unit: "KB"
              scale: "volume * 1.0 / 1024.0"

 使用 map_from 和 map_to:

transformers:
    - name: "unit_conversion"
      parameters:
          source:
              map_from:
                  name: "disk\\.(read|write)\\.bytes"
          target:
              map_to:
                  name: "disk.\\1.kilobytes"
              scale: "volume * 1.0 / 1024.0"
              unit: "KB"

Aggregator transformer

  在到达足够的样本或超时之前， 此种转换器会对输入的样本进行汇总。

可以使用 retention_time 选项指定超时。 如果您想要刷新aggregation，在聚合了一定数量的samples之后，请指定参数大小。

所创建的样本容量是输入到l转换器的样本容量的总和。 样本可以通过 project_id, user_id 和 resource_metadata 属性聚合。 根据所选择的属性进行聚合，在配置中指定它们，并设置该属性的值以获取新样本( 首先使用第一个样本属性，最后取最后一个样本属性，然后删除该属性)。

通过 resource_metadata 汇总60秒的样本值，并保存最新收到的样本的 resource_metadata ：

transformers:
    - name: "aggregator"
      parameters:
          retention_time: 60
          resource_metadata: last

通过 user_id 和 resource_metadata 聚合每个15个样本， 并保留第一个接收到的sample的 user_id ，并删除 resource_metadata ：

transformers:
    - name: "aggregator"
      parameters:
          size: 15
          user_id: first
          resource_metadata: drop

Accumulator transformer

 这种转换器只是简单地缓存样本，直到达到足够的样本，然后立即将它们全部冲下管道:

transformers:
    - name: "accumulator"
      parameters:
          size: 15

Multi meter arithmetic transformer

此种转换器使我们能够在一个或多个meters上进行算术运算，进行 and/or元数据。例如:

memory_util = 100 * memory.usage / memory

根据 transformer 配置的 target 部分里的属性描述会创建一个新的sample。 样本容量是根据提供的表达式计算的结果。 对同一资源的样本进行计算。

备注： 计算的范围仅限于同一区间内的 meter。

例子配置文件:

transformers:
    - name: "arithmetic"
      parameters:
        target:
          name: "memory_util"
          unit: "%"
          type: "gauge"
          expr: "100 * $(memory.usage) / $(memory)"

为了演示元数据的使用，以下一种新型测量器的实现显示了每个核心的平均CPU时间:

transformers:
    - name: "arithmetic"
      parameters:
        target:
          name: "avg_cpu_per_core"
          unit: "ns"
          type: "cumulative"
          expr: "$(cpu) / ($(cpu).resource_metadata.cpu_number or 1)"

备注： Expression evaluation gracefully handles NaNs and exceptions. 在这种情况下，它不会创建一个新的sample，而是只记录一个警告。

Delta transformer

这种转换器计算一个资源的两个样本数据点之间的变化。 它可以配置为只捕获正增长的增量(deltas)。

实例配置：

transformers:
    - name: "delta"
      parameters:
        target:
            name: "cpu.delta"
        growth_only: True

Publishers

遥测服务提供几种传输方法，将收集到的数据传输到外部系统。 这些数据的消费者有很大的不同，就像监视系统一样，数据丢失是可以接受的但计费系统需要可靠的数据传输。遥测技术提供了满足两种系统要求的方法。

发布者组件可以通过消息总线将数据保存到持久存储中，或将其发送给一个或多个外部消费者。一个chain可以包含多个发布者。

为了解决这个问题，可以为遥测服务中的每个数据点配置多发布者，允许将相同的技术meter或事件多次发布到多个目的地，每个目的地都可能使用不同的传输。

支持下面的发布者类型:

gnocchi (默认)

在启用gnocchi发布者时，会将度量和资源信息推送到gnocchi进行时间序列优化存储。 Gnocchi必须在 Identity服务中注册，因为Ceilometer通过Identity服务来发现确切的路径。

关于如何启用和配置gnocchi的更多细节可以在其官方文档页面找到。

panko

云计算中的事件数据可以存储在panko中，它提供了一个HTTP REST接口来查询OpenStack中的系统事件。 把数据推给panko， 设置 publisher 为 panko:// 。

notifier

notifier publisher 可以以 notifier://?option1=value1&option2=value2 的形式指定。 它使用oslo.messaging来发出AMQP的数据。 然后，任何消费者都可以订阅已发布的主题进行额外的处理。

以下是可用的定制选项:

per_meter_topic

    这个参数的值是1。 它用于在额外的 metering_topic.sample_name 主题队列，除了默认的 metering_topic 队列,发布samples。

policy

     用于配置案例的行为，当发布者无法发送样品时，可能的预定义值是:

     default : 用于等待和阻塞，直到samples被发送。

     drop: 用于丢弃未能发送的samples。

     queue: 用于创建内存中的队列，并在下一次样本发布期间重新尝试将样品发送到队列中(队列长度可以用 max_queue_length 属性来配置，默认值是 1024 )。

topic

     要发布到的队列的主题名称。 设置这个选项将会覆盖由 metering_topic 和 event_topic 默认设定的主题。 这个选项可以用来支持多个消费者。

udp

 此publisher 可以用 udp://:/的形式指定。 它通过UDP发出计量数据。

file

此publisher 可以用 file://path?option1=value1&option2=value2 的形式指定。 此种发布者将测量数据记录到一个文件中。

备注： 如果没有指定文件名和位置， file 发布者不会记录任何meters，而是为Telemetry在配置的日志文件中记录一条警告消息。

以下选项可供 file publisher 使用：

max_bytes 当这个选项大于零时，它将导致翻转。 当指定的大小即将溢出时，文件将被关闭，一个新的文件将被静默打开以输出。 如果它的值为零，那么翻转就不会发生。

backup_count 如果该值是非零的，则扩展将被追加到旧日志的文件名，如.1、.2等等，直到达到指定的值为止。 编写状态和包含最新数据的文件始终是没有任何指定扩展的。

http

遥测服务支持将samples发送到外部HTTP目标。samples没有任何修改地发出。 要将此选项设置为通知代理目标，请将 http:// 设置为管道定义文件中的发布者端点。 HTTP目标应该与发布者声明一起设置。 例如，可以通过 http://localhost:80/?option1=value1&option2=value2 来传递额外的配置选项。

下面的选项是可用的：

timeout HTTP请求超时前的秒数。

max_retries 在失败之前重试请求的次数。

batch 如果为 false， 发布者将分别发送每个sample和event，无论通知代理是否被配置成批量处理。

verify_ssl 如果为 false，则禁用ssl证书验证。

默认发布者是gnocchi，没有指定其他选项。 /etc/ceilometer/pipeline.yaml 配置文件里的 sample  publisher部分类似下面： 

publishers:
    - gnocchi://
    - panko://
    - udp://10.0.0.2:1234
    - notifier://?policy=drop&max_queue_length=512&topic=custom_target

管道分割

备注: Partitioning只有当管道包含有transformations时才是必须的。在某些publishers的支持下， 它有次要的好处。 在大的工作负载下，可以部署多个通知代理来处理来自监视服务的传入消息的泛滥。 如果在管道中启用了转换，则必须协调通知代理，以确保将相关消息路由到同一代理。 要启用协调，请在 notification 部分设置 workload_partitioning 值。

要跨代理分发消息，应该设置 pipeline_processing_queues 选项。 这个值定义了要创建多少个管道队列，然后将其分发给活动的通知代理。 建议处理队列的数量至少与代理的数量匹配。

增加处理队列的数量将改进消息在代理之间的分布。 它还有助于将请求最小化到Gnocchi存储后端。 它还将增加对消息队列的加载，因为它将使用队列到碎片数据。

警告： 减少处理队列的数量可能会导致数据丢失，因为以前创建的队列可能不再被分配给活动代理。 只建议您增加处理队列。

感谢各位的阅读，以上就是“ceilometer的数据处理和管道怎么配置”的内容了，经过本文的学习后，相信大家对ceilometer的数据处理和管道怎么配置这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！

文章题目：ceilometer的数据处理和管道怎么配置
文章网址：http://kswjz.com/article/gcccpj.html