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://pwwzsj.com/article/gcccpj.html