heat和ceilometer的取樣時間

在上一篇文章中, 我們記錄下一篇問題:
https://bugs.launchpad.net/ceilometer/+bug/1457923
其中, 發問的主題, 也就是heat stack的取樣時間必須和ceilometer的時間一致,

為了解釋原因, 我們必須先了解heat和ceilometer的偕同架構,
以最簡單的圖說來說, 可以以下圖來表示:


在heat和ceilometer的協作中,
ceilometer負責收集各OpenStack的各項資訊,
heat則根據ceilometer所得到的數據, 進行stack的auto-scaling,

其中, ceilometer取樣個數據的時間定義在/etc/ceilometer/pipeline.yaml中,

    - name: network_source
      interval: 60
      meters:
          - "network.incoming.bytes"
          - "network.incoming.packets"
          - "network.outgoing.bytes"
          - "network.outgoing.packets"
      sinks:
          - network_sink

其中, interval: 60就是ceilometer的取樣時間, 單位為秒,
該時間必須要大於heat所取樣的時間差,
該數值被定義於HOT template中, 舉例來說, 我們可以定義

  cpu_alarm_high:
    type: OS::Ceilometer::Alarm
    properties:
      description: Scale-up if the average bytes > 100000 for 1 minute
      meter_name: cpu_util
      statistic: avg
      period: 60
      evaluation_periods: 1
      threshold: 50
      alarm_actions:
        - {get_attr: [scale_up_policy, alarm_url]}
      matching_metadata: {'metadata.user_metadata.stack': {get_param: "OS::stack_id"}}
      comparison_operator: gt

其中, period就是取樣的時間, 單位也是秒,
此時間必須至少等於ceilometer的取樣時間, 建議是大於會比較好,
如果此時間小於ceilometer的取樣時間, 則會出現insufficient data的狀態,
如果出現此狀態, 應該就是heat有一些問題, 必須處理,

另外, insufficient data也可能是因為取得的數值過大,
因此, 不要把network.incoming.bytes這種累加的數值當作scaling的準則,



留言

熱門文章

LTE筆記: RSRP, RSSI and RSRQ

[WiFi] WiFi 網路的識別: BSS, ESS, SSID, ESSID, BSSID

LTE筆記: 5G NR Measurement Events