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：

發布者部分包含發布者列表，其中樣本數據應該在可能的轉換之后發送。

類似地，事件管道定義看起來像下面這樣:

---
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存儲后端。 它還將增加對消息隊列的加載，因為它將使用隊列到碎片數據。

警告： 減少處理隊列的數量可能會導致數據丟失，因為以前創建的隊列可能不再被分配給活動代理。 只建議您增加處理隊列。

感謝各位的閱讀，以上就是“ceilometer的數據處理和管道怎么配置”的內容了，經過本文的學習后，相信大家對ceilometer的數據處理和管道怎么配置這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！