ceilometer的數(shù)據(jù)處理和管道怎么配置

這篇文章主要講解了“ceilometer的數(shù)據(jù)處理和管道怎么配置”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“ceilometer的數(shù)據(jù)處理和管道怎么配置”吧！

處理數(shù)據(jù)的機(jī)制稱為管道。 在配置級別上，管道描述數(shù)據(jù)來源和相應(yīng)的匯合點(diǎn)之間的耦合，用于轉(zhuǎn)換和公布數(shù)據(jù)。 此功能由通知代理處理。

source是數(shù)據(jù)的生產(chǎn)者: samples 或 events 。 實(shí)際上， 它是一組為匹配的 meters和事件類型集合 發(fā)出數(shù)據(jù)點(diǎn)的通知處理程序。

每個(gè)source配置將名稱匹配和映射封裝到一個(gè)或多個(gè) sinks 中以供發(fā)布。

另一方面，sink是數(shù)據(jù)的使用者，為轉(zhuǎn)換和發(fā)布來自相關(guān)源的數(shù)據(jù)提供邏輯。

實(shí)際上，sink描述了一系列的處理程序。 該 chain 從零或更多的 transformers 開始，并以一個(gè)或多個(gè) publishers 結(jié)束。 chain中的第一個(gè)transformer從對應(yīng)的source傳遞數(shù)據(jù)， 采取一些操作， 例如 deriving變動率, 執(zhí)行單位轉(zhuǎn)換或聚合, 然后 publishing。

管道配置

通知代理支持兩種管道: 一個(gè)處理 samples，另一個(gè)處理events。 通過在[notifications]設(shè)置管道選項(xiàng)，可以啟用和禁用管道。

默認(rèn)情況下，每個(gè)管道的實(shí)際配置存儲在單獨(dú)的配置文件中: pipeline.yaml 和 event_pipeline.yaml。配置文件的位置可以由 pipeline_cfg_file 和 event_pipeline_cfg_file 選項(xiàng)設(shè)置，配置文件模板查看：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列表。 有效計(jì)量表的清單可以在 Measurements中找到。 有種方式可以定義所有的 meters 或者只包含或過濾部分 meters，一個(gè) source 配置操作應(yīng)該按下面方式：

• 包含所有的 meters 使用*號通配符。但明智的做法是只選擇您打算使用的meters，以避免使用了未使用過的數(shù)據(jù)淹沒了計(jì)量數(shù)據(jù)庫。

• 要定義meters列表，可使用下列任何一種:

                要包含部分meters，可使用 meter_name 語法。

                要過濾部分meters，可使用 !meter_name 語法。

備注： OpenStack遙測服務(wù)在管道之間沒有任何重復(fù)檢查， 如果您在多個(gè)管道中添加了一個(gè) meter，則假定重復(fù)是有意的，并且可以根據(jù)指定的接收器多次存儲。

上述定義方法可用于以下組合：

• 只使用通配符符號。

• 使用 included meters。

• 使用 excluded meters。

• 通配符與 excluded 結(jié)合使用。

備注： 以上變化中至少有一種應(yīng)該被包括在meters section。 Included 和excluded meters不能共存于同一管道中。 通配符和included meters 不能在同一管道定義部分中共存。

管道sink的 transformers部分提供了添加 transformers定義列表的可能性。 現(xiàn)有的transformers：

發(fā)布者部分包含發(fā)布者列表，其中樣本數(shù)據(jù)應(yīng)該在可能的轉(zhuǎn)換之后發(fā)送。

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

---
sources:
  - name: 'source name'
    events:
      - 'event filter'
    sinks:
      - 'sink name'
sinks:
  - name: 'sink name'
    publishers:
      - 'list of publishers'

事件過濾器使用與meter管道相同的過濾邏輯。

Transformers

  備注：Transformers在內(nèi)存中保存數(shù)據(jù)，因此不能保證在某些場景下的持久性。 使用像Gnocchi這樣的解決方案可以實(shí)現(xiàn)更持久、更有效的解決方案。

轉(zhuǎn)換器的定義可以包含以下字段:

• name 轉(zhuǎn)換器的名稱

• parameters 轉(zhuǎn)換器的參數(shù)

參數(shù)部分可以包含transformer特定字段,  在變化速率的案例中，像source和target字段包含有不同的子字段，這依賴于 transformer 的實(shí)現(xiàn)。

下面是支持的 transformers:

Rate of change transformer

此種轉(zhuǎn)換器是計(jì)算兩個(gè)數(shù)據(jù)點(diǎn)之間的時(shí)間變化值。下面的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計(jì)數(shù)器的樣本值生成 cpu_util meter， 它代表了納秒的累計(jì)CPU時(shí)間。 上面的transformer定義定義了一個(gè)比例因子(用于納秒和多cpu), 在轉(zhuǎn)換之前應(yīng)用于從cpu表的順序值派生出一個(gè)帶有%單位的度量樣本序列。

磁盤I/O速率的定義，也由變化率的轉(zhuǎn)換器生成 :

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

此種轉(zhuǎn)換器應(yīng)用于單位轉(zhuǎn)換。 它接收meter的volume，并將它乘以給定的尺度表達(dá)式。 也支持如 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

  在到達(dá)足夠的樣本或超時(shí)之前， 此種轉(zhuǎn)換器會對輸入的樣本進(jìn)行匯總。

可以使用 retention_time 選項(xiàng)指定超時(shí)。 如果您想要刷新aggregation，在聚合了一定數(shù)量的samples之后，請指定參數(shù)大小。

所創(chuàng)建的樣本容量是輸入到l轉(zhuǎn)換器的樣本容量的總和。 樣本可以通過 project_id, user_id 和 resource_metadata 屬性聚合。 根據(jù)所選擇的屬性進(jìn)行聚合，在配置中指定它們，并設(shè)置該屬性的值以獲取新樣本( 首先使用第一個(gè)樣本屬性，最后取最后一個(gè)樣本屬性，然后刪除該屬性)。

通過 resource_metadata 匯總60秒的樣本值，并保存最新收到的樣本的 resource_metadata ：

transformers:
    - name: "aggregator"
      parameters:
          retention_time: 60
          resource_metadata: last

通過 user_id 和 resource_metadata 聚合每個(gè)15個(gè)樣本， 并保留第一個(gè)接收到的sample的 user_id ，并刪除 resource_metadata ：

transformers:
    - name: "aggregator"
      parameters:
          size: 15
          user_id: first
          resource_metadata: drop

Accumulator transformer

 這種轉(zhuǎn)換器只是簡單地緩存樣本，直到達(dá)到足夠的樣本，然后立即將它們?nèi)繘_下管道:

transformers:
    - name: "accumulator"
      parameters:
          size: 15

Multi meter arithmetic transformer

此種轉(zhuǎn)換器使我們能夠在一個(gè)或多個(gè)meters上進(jìn)行算術(shù)運(yùn)算，進(jìn)行 and/or元數(shù)據(jù)。例如:

memory_util = 100 * memory.usage / memory

根據(jù) transformer 配置的 target 部分里的屬性描述會創(chuàng)建一個(gè)新的sample。 樣本容量是根據(jù)提供的表達(dá)式計(jì)算的結(jié)果。 對同一資源的樣本進(jìn)行計(jì)算。

備注： 計(jì)算的范圍僅限于同一區(qū)間內(nèi)的 meter。

例子配置文件:

transformers:
    - name: "arithmetic"
      parameters:
        target:
          name: "memory_util"
          unit: "%"
          type: "gauge"
          expr: "100 * $(memory.usage) / $(memory)"

為了演示元數(shù)據(jù)的使用，以下一種新型測量器的實(shí)現(xiàn)顯示了每個(gè)核心的平均CPU時(shí)間:

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)建一個(gè)新的sample，而是只記錄一個(gè)警告。

Delta transformer

這種轉(zhuǎn)換器計(jì)算一個(gè)資源的兩個(gè)樣本數(shù)據(jù)點(diǎn)之間的變化。 它可以配置為只捕獲正增長的增量(deltas)。

實(shí)例配置：

transformers:
    - name: "delta"
      parameters:
        target:
            name: "cpu.delta"
        growth_only: True

Publishers

遙測服務(wù)提供幾種傳輸方法，將收集到的數(shù)據(jù)傳輸?shù)酵獠肯到y(tǒng)。 這些數(shù)據(jù)的消費(fèi)者有很大的不同，就像監(jiān)視系統(tǒng)一樣，數(shù)據(jù)丟失是可以接受的但計(jì)費(fèi)系統(tǒng)需要可靠的數(shù)據(jù)傳輸。遙測技術(shù)提供了滿足兩種系統(tǒng)要求的方法。

發(fā)布者組件可以通過消息總線將數(shù)據(jù)保存到持久存儲中，或?qū)⑵浒l(fā)送給一個(gè)或多個(gè)外部消費(fèi)者。一個(gè)chain可以包含多個(gè)發(fā)布者。

為了解決這個(gè)問題，可以為遙測服務(wù)中的每個(gè)數(shù)據(jù)點(diǎn)配置多發(fā)布者，允許將相同的技術(shù)meter或事件多次發(fā)布到多個(gè)目的地，每個(gè)目的地都可能使用不同的傳輸。

支持下面的發(fā)布者類型:

gnocchi (默認(rèn))

在啟用gnocchi發(fā)布者時(shí)，會將度量和資源信息推送到gnocchi進(jìn)行時(shí)間序列優(yōu)化存儲。 Gnocchi必須在 Identity服務(wù)中注冊，因?yàn)镃eilometer通過Identity服務(wù)來發(fā)現(xiàn)確切的路徑。

關(guān)于如何啟用和配置gnocchi的更多細(xì)節(jié)可以在其官方文檔頁面找到。

panko

云計(jì)算中的事件數(shù)據(jù)可以存儲在panko中，它提供了一個(gè)HTTP REST接口來查詢OpenStack中的系統(tǒng)事件。 把數(shù)據(jù)推給panko， 設(shè)置 publisher 為 panko:// 。

notifier

notifier publisher 可以以 notifier://?option1=value1&option2=value2 的形式指定。 它使用oslo.messaging來發(fā)出AMQP的數(shù)據(jù)。 然后，任何消費(fèi)者都可以訂閱已發(fā)布的主題進(jìn)行額外的處理。

以下是可用的定制選項(xiàng):

per_meter_topic

    這個(gè)參數(shù)的值是1。 它用于在額外的 metering_topic.sample_name 主題隊(duì)列，除了默認(rèn)的 metering_topic 隊(duì)列,發(fā)布samples。

policy

     用于配置案例的行為，當(dāng)發(fā)布者無法發(fā)送樣品時(shí)，可能的預(yù)定義值是:

     default : 用于等待和阻塞，直到samples被發(fā)送。

     drop: 用于丟棄未能發(fā)送的samples。

     queue: 用于創(chuàng)建內(nèi)存中的隊(duì)列，并在下一次樣本發(fā)布期間重新嘗試將樣品發(fā)送到隊(duì)列中(隊(duì)列長度可以用 max_queue_length 屬性來配置，默認(rèn)值是 1024 )。

topic

     要發(fā)布到的隊(duì)列的主題名稱。 設(shè)置這個(gè)選項(xiàng)將會覆蓋由 metering_topic 和 event_topic 默認(rèn)設(shè)定的主題。 這個(gè)選項(xiàng)可以用來支持多個(gè)消費(fèi)者。

udp

 此publisher 可以用 udp://<host>:<port>/的形式指定。 它通過UDP發(fā)出計(jì)量數(shù)據(jù)。

file

此publisher 可以用 file://path?option1=value1&option2=value2 的形式指定。 此種發(fā)布者將測量數(shù)據(jù)記錄到一個(gè)文件中。

備注： 如果沒有指定文件名和位置， file 發(fā)布者不會記錄任何meters，而是為Telemetry在配置的日志文件中記錄一條警告消息。

以下選項(xiàng)可供 file publisher 使用：

max_bytes 當(dāng)這個(gè)選項(xiàng)大于零時(shí)，它將導(dǎo)致翻轉(zhuǎn)。 當(dāng)指定的大小即將溢出時(shí)，文件將被關(guān)閉，一個(gè)新的文件將被靜默打開以輸出。 如果它的值為零，那么翻轉(zhuǎn)就不會發(fā)生。

backup_count 如果該值是非零的，則擴(kuò)展將被追加到舊日志的文件名，如.1、.2等等，直到達(dá)到指定的值為止。 編寫狀態(tài)和包含最新數(shù)據(jù)的文件始終是沒有任何指定擴(kuò)展的。

http

遙測服務(wù)支持將samples發(fā)送到外部HTTP目標(biāo)。samples沒有任何修改地發(fā)出。 要將此選項(xiàng)設(shè)置為通知代理目標(biāo)，請將 http:// 設(shè)置為管道定義文件中的發(fā)布者端點(diǎn)。 HTTP目標(biāo)應(yīng)該與發(fā)布者聲明一起設(shè)置。 例如，可以通過 http://localhost:80/?option1=value1&option2=value2 來傳遞額外的配置選項(xiàng)。

下面的選項(xiàng)是可用的：

timeout HTTP請求超時(shí)前的秒數(shù)。

max_retries 在失敗之前重試請求的次數(shù)。

batch 如果為 false， 發(fā)布者將分別發(fā)送每個(gè)sample和event，無論通知代理是否被配置成批量處理。

verify_ssl 如果為 false，則禁用ssl證書驗(yàn)證。

默認(rèn)發(fā)布者是gnocchi，沒有指定其他選項(xiàng)。 /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只有當(dāng)管道包含有transformations時(shí)才是必須的。在某些publishers的支持下， 它有次要的好處。 在大的工作負(fù)載下，可以部署多個(gè)通知代理來處理來自監(jiān)視服務(wù)的傳入消息的泛濫。 如果在管道中啟用了轉(zhuǎn)換，則必須協(xié)調(diào)通知代理，以確保將相關(guān)消息路由到同一代理。 要啟用協(xié)調(diào)，請?jiān)?notification 部分設(shè)置 workload_partitioning 值。

要跨代理分發(fā)消息，應(yīng)該設(shè)置 pipeline_processing_queues 選項(xiàng)。 這個(gè)值定義了要?jiǎng)?chuàng)建多少個(gè)管道隊(duì)列，然后將其分發(fā)給活動的通知代理。 建議處理隊(duì)列的數(shù)量至少與代理的數(shù)量匹配。

增加處理隊(duì)列的數(shù)量將改進(jìn)消息在代理之間的分布。 它還有助于將請求最小化到Gnocchi存儲后端。 它還將增加對消息隊(duì)列的加載，因?yàn)樗鼘⑹褂藐?duì)列到碎片數(shù)據(jù)。

警告： 減少處理隊(duì)列的數(shù)量可能會導(dǎo)致數(shù)據(jù)丟失，因?yàn)橐郧皠?chuàng)建的隊(duì)列可能不再被分配給活動代理。 只建議您增加處理隊(duì)列。

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