這篇文章主要講解了“ceilometer的數(shù)據(jù)處理和管道怎么配置”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“ceilometer的數(shù)據(jù)處理和管道怎么配置”吧！
網(wǎng)站建設哪家好，找創(chuàng)新互聯(lián)建站！專注于網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、微信小程序定制開發(fā)、集團企業(yè)網(wǎng)站建設等服務項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了郁南免費建站歡迎大家使用！
處理數(shù)據(jù)的機制稱為管道。 在配置級別上，管道描述數(shù)據(jù)來源和相應的匯合點之間的耦合，用于轉換和公布數(shù)據(jù)。 此功能由通知代理處理。
source是數(shù)據(jù)的生產者: samples 或 events 。 實際上， 它是一組為匹配的 meters和事件類型集合 發(fā)出數(shù)據(jù)點的通知處理程序。
每個source配置將名稱匹配和映射封裝到一個或多個 sinks 中以供發(fā)布。
另一方面，sink是數(shù)據(jù)的使用者，為轉換和發(fā)布來自相關源的數(shù)據(jù)提供邏輯。
實際上，sink描述了一系列的處理程序。 該 chain 從零或更多的 transformers 開始，并以一個或多個 publishers 結束。 chain中的第一個transformer從對應的source傳遞數(shù)據(jù)， 采取一些操作， 例如 deriving變動率, 執(zhí)行單位轉換或聚合, 然后 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，以避免使用了未使用過的數(shù)據(jù)淹沒了計量數(shù)據(jù)庫。
要定義meters列表，可使用下列任何一種:
要包含部分meters，可使用 meter_name 語法。
要過濾部分meters，可使用 !meter_name 語法。
備注： OpenStack遙測服務在管道之間沒有任何重復檢查， 如果您在多個管道中添加了一個 meter，則假定重復是有意的，并且可以根據(jù)指定的接收器多次存儲。
上述定義方法可用于以下組合：
只使用通配符符號。
使用 included meters。
使用 excluded meters。
通配符與 excluded 結合使用。
備注： 以上變化中至少有一種應該被包括在meters section。 Included 和excluded meters不能共存于同一管道中。 通配符和included meters 不能在同一管道定義部分中共存。
管道sink的 transformers部分提供了添加 transformers定義列表的可能性。 現(xiàn)有的transformers：
| Transformer 的名字 | 配置的引用名稱 |
|---|---|
| Accumulator | accumulator |
| Aggregator | aggregator |
| Arithmetic | arithmetic |
| Rate of change | rate_of_change |
| Unit conversion | unit_conversion |
| Delta | delta |
發(fā)布者部分包含發(fā)布者列表，其中樣本數(shù)據(jù)應該在可能的轉換之后發(fā)送。
類似地，事件管道定義看起來像下面這樣:
--- sources: - name: 'source name' events: - 'event filter' sinks: - 'sink name' sinks: - name: 'sink name' publishers: - 'list of publishers'
事件過濾器使用與meter管道相同的過濾邏輯。
備注：Transformers在內存中保存數(shù)據(jù)，因此不能保證在某些場景下的持久性。 使用像Gnocchi這樣的解決方案可以實現(xiàn)更持久、更有效的解決方案。
轉換器的定義可以包含以下字段:
name轉換器的名稱
parameters轉換器的參數(shù)
參數(shù)部分可以包含transformer特定字段, 在變化速率的案例中，像source和target字段包含有不同的子字段，這依賴于 transformer 的實現(xiàn)。
下面是支持的 transformers:
此種轉換器是計算兩個數(shù)據(jù)點之間的時間變化值。下面的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計數(shù)器的樣本值生成 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"
此種轉換器應用于單位轉換。 它接收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"
在到達足夠的樣本或超時之前， 此種轉換器會對輸入的樣本進行匯總。
可以使用 retention_time 選項指定超時。 如果您想要刷新aggregation，在聚合了一定數(shù)量的samples之后，請指定參數(shù)大小。
所創(chuàng)建的樣本容量是輸入到l轉換器的樣本容量的總和。 樣本可以通過 project_id, user_id 和 resource_metadata 屬性聚合。 根據(jù)所選擇的屬性進行聚合，在配置中指定它們，并設置該屬性的值以獲取新樣本( 首先使用第一個樣本屬性，最后取最后一個樣本屬性，然后刪除該屬性)。
通過 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
這種轉換器只是簡單地緩存樣本，直到達到足夠的樣本，然后立即將它們全部沖下管道:
transformers: - name: "accumulator" parameters: size: 15
此種轉換器使我們能夠在一個或多個meters上進行算術運算，進行 and/or元數(shù)據(jù)。例如:
memory_util = 100 * memory.usage / memory
根據(jù) transformer 配置的 target 部分里的屬性描述會創(chuàng)建一個新的sample。 樣本容量是根據(jù)提供的表達式計算的結果。 對同一資源的樣本進行計算。
備注： 計算的范圍僅限于同一區(qū)間內的 meter。
例子配置文件:
transformers: - name: "arithmetic" parameters: target: name: "memory_util" unit: "%" type: "gauge" expr: "100 * $(memory.usage) / $(memory)"
為了演示元數(shù)據(jù)的使用，以下一種新型測量器的實現(xiàn)顯示了每個核心的平均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. 在這種情況下，它不會創(chuàng)建一個新的sample，而是只記錄一個警告。
這種轉換器計算一個資源的兩個樣本數(shù)據(jù)點之間的變化。 它可以配置為只捕獲正增長的增量(deltas)。
實例配置：
transformers: - name: "delta" parameters: target: name: "cpu.delta" growth_only: True
遙測服務提供幾種傳輸方法，將收集到的數(shù)據(jù)傳輸?shù)酵獠肯到y(tǒng)。 這些數(shù)據(jù)的消費者有很大的不同，就像監(jiān)視系統(tǒng)一樣，數(shù)據(jù)丟失是可以接受的但計費系統(tǒng)需要可靠的數(shù)據(jù)傳輸。遙測技術提供了滿足兩種系統(tǒng)要求的方法。
發(fā)布者組件可以通過消息總線將數(shù)據(jù)保存到持久存儲中，或將其發(fā)送給一個或多個外部消費者。一個chain可以包含多個發(fā)布者。
為了解決這個問題，可以為遙測服務中的每個數(shù)據(jù)點配置多發(fā)布者，允許將相同的技術meter或事件多次發(fā)布到多個目的地，每個目的地都可能使用不同的傳輸。
支持下面的發(fā)布者類型:
在啟用gnocchi發(fā)布者時，會將度量和資源信息推送到gnocchi進行時間序列優(yōu)化存儲。 Gnocchi必須在 Identity服務中注冊，因為Ceilometer通過Identity服務來發(fā)現(xiàn)確切的路徑。
關于如何啟用和配置gnocchi的更多細節(jié)可以在其官方文檔頁面找到。
云計算中的事件數(shù)據(jù)可以存儲在panko中，它提供了一個HTTP REST接口來查詢OpenStack中的系統(tǒng)事件。 把數(shù)據(jù)推給panko， 設置 publisher 為 panko:// 。
notifier publisher 可以以 notifier://?option1=value1&option2=value2 的形式指定。 它使用oslo.messaging來發(fā)出AMQP的數(shù)據(jù)。 然后，任何消費者都可以訂閱已發(fā)布的主題進行額外的處理。
以下是可用的定制選項:
per_meter_topic
這個參數(shù)的值是1。 它用于在額外的 metering_topic.sample_name 主題隊列，除了默認的 metering_topic 隊列,發(fā)布samples。
policy
用于配置案例的行為，當發(fā)布者無法發(fā)送樣品時，可能的預定義值是:
default : 用于等待和阻塞，直到samples被發(fā)送。
drop: 用于丟棄未能發(fā)送的samples。
queue: 用于創(chuàng)建內存中的隊列，并在下一次樣本發(fā)布期間重新嘗試將樣品發(fā)送到隊列中(隊列長度可以用 max_queue_length 屬性來配置，默認值是 1024 )。
topic
要發(fā)布到的隊列的主題名稱。 設置這個選項將會覆蓋由 metering_topic 和 event_topic 默認設定的主題。 這個選項可以用來支持多個消費者。
此publisher 可以用 udp://的形式指定。 它通過UDP發(fā)出計量數(shù)據(jù)。
此publisher 可以用 file://path?option1=value1&option2=value2 的形式指定。 此種發(fā)布者將測量數(shù)據(jù)記錄到一個文件中。
備注： 如果沒有指定文件名和位置， file 發(fā)布者不會記錄任何meters，而是為Telemetry在配置的日志文件中記錄一條警告消息。
以下選項可供 file publisher 使用：
max_bytes 當這個選項大于零時，它將導致翻轉。 當指定的大小即將溢出時，文件將被關閉，一個新的文件將被靜默打開以輸出。 如果它的值為零，那么翻轉就不會發(fā)生。
backup_count 如果該值是非零的，則擴展將被追加到舊日志的文件名，如.1、.2等等，直到達到指定的值為止。 編寫狀態(tài)和包含最新數(shù)據(jù)的文件始終是沒有任何指定擴展的。
遙測服務支持將samples發(fā)送到外部HTTP目標。samples沒有任何修改地發(fā)出。 要將此選項設置為通知代理目標，請將 http:// 設置為管道定義文件中的發(fā)布者端點。 HTTP目標應該與發(fā)布者聲明一起設置。 例如，可以通過 http://localhost:80/?option1=value1&option2=value2 來傳遞額外的配置選項。
下面的選項是可用的：
timeout HTTP請求超時前的秒數(shù)。
max_retries 在失敗之前重試請求的次數(shù)。
batch 如果為 false， 發(fā)布者將分別發(fā)送每個sample和event，無論通知代理是否被配置成批量處理。
verify_ssl 如果為 false，則禁用ssl證書驗證。
默認發(fā)布者是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的支持下， 它有次要的好處。 在大的工作負載下，可以部署多個通知代理來處理來自監(jiān)視服務的傳入消息的泛濫。 如果在管道中啟用了轉換，則必須協(xié)調通知代理，以確保將相關消息路由到同一代理。 要啟用協(xié)調，請在 notification 部分設置 workload_partitioning 值。
要跨代理分發(fā)消息，應該設置 pipeline_processing_queues 選項。 這個值定義了要創(chuàng)建多少個管道隊列，然后將其分發(fā)給活動的通知代理。 建議處理隊列的數(shù)量至少與代理的數(shù)量匹配。
增加處理隊列的數(shù)量將改進消息在代理之間的分布。 它還有助于將請求最小化到Gnocchi存儲后端。 它還將增加對消息隊列的加載，因為它將使用隊列到碎片數(shù)據(jù)。
警告： 減少處理隊列的數(shù)量可能會導致數(shù)據(jù)丟失，因為以前創(chuàng)建的隊列可能不再被分配給活動代理。 只建議您增加處理隊列。
感謝各位的閱讀，以上就是“ceilometer的數(shù)據(jù)處理和管道怎么配置”的內容了，經過本文的學習后，相信大家對ceilometer的數(shù)據(jù)處理和管道怎么配置這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關知識點的文章，歡迎關注！
重慶分公司
重慶分公司
