處理數據的機制稱為管道。 在配置級別上，管道描述數據來源和相應的匯合點之間的耦合，用于轉換和公布數據。 此功能由通知代理處理。
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/