ceilometer的数据处理和管道怎么配置
这篇文章主要讲解了“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://6mz.cn/article/gcccpj.html