处理数据的机制称为管道。 在配置级别上，管道描述数据来源和相应的汇合点之间的耦合，用于转换和公布数据。 此功能由通知代理处理。
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 Delta
unit_conversion 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://<host>:<port>/ 的形式指定。 它通过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存储后端。 它还将增加对消息队列的加载，因为它将使用队列到碎片数据。
警告： 减少处理队列的数量可能会导致数据丢失，因为以前创建的队列可能不再被分配给活动代理。 只建议您增加处理队列。
转载: http://luozn.top/2018/04/11/223/