Atom feed of this document
  

 告警创建

一个创建基于阀值的警告案例,基于特定实例的CPU利用率上限:

$ ceilometer alarm-threshold-create --name cpu_hi \
  --description 'instance running hot' \
  --meter-name cpu_util --threshold 70.0 \
  --comparison-operator gt --statistic avg \
  --period 600 --evaluation-periods 3 \
  --alarm-action 'log://' \
  --query resource_id=INSTANCE_ID

当一个单独实例的平均 CPU 利用率在三次连续的 10 分钟时间超过 70%,会创建一个警报。这个情况下的通知仅仅是一个日志消息,尽管它可以选择作为一个 webhook URL。

[注意]注意

对于和一个独立的项目相关联的警告来说,警告名称必须是唯一的。

The cloud administrator can limit the maximum resulting actions for three different states, and the ability for a normal user to create log:// and test:// notifiers is disabled. This prevents unintentional consumption of disk and memory resources by the Telemetry service.

在这个示例中,警报所评估的平滑的时间窗口是 30 分钟。这个窗口并不是夹在 wall-clock 时间界限之间,相反,它在每个评估周期中停留在当前的时间上,并在每个评估周期到来之前持续缓慢地前进 (默认情况下,每分钟都会发生)。

在这个案例中,周期长度设置为 600s,以反映相关计量收集的开箱默认节奏。这个周期匹配说明了一个重要的一般原则,以记得进行警报:

[注意]注意

报警周期应为对应于目标计量的管道中设置的一个整数 (1 或更大) 间隔。

另外,由于实际保存在计量中的数据点频率和用于比较警报阀值的状态查询之间的不匹配,警报会趋向进入或脱离 insufficient data 状态。如果需要一个更短的警报时间,那么相应的间隔应该在 pipeline.yaml 文件中进行调整。

其它显目的警告属性应在创建时设置,或者是通过稍后的更新来设置,这包括:

状态

初始化警告状态(默认为insufficient data)。

描述

警告的自由文本描述(默认是警告规则的简介)。

激活

如果为True的话,就表明了为此警告启用了评估和行为(默认即为True)。

repeat-actions

如果为True的话,当警告仍旧在目标状态中时须重复发送通知(默认是False)。

ok-action

当警告状态转换为ok时所调用的动作。

insufficient-data-action

当警告状态转换为insufficient data时调用的动作。

time-constraint

用来限制警告的评估,如一天的某些时间,或一周的某几天(表示为cron表达式加可选的时区)。

一个创建组合警告的例子,基于两个底层报警的组合状态:

$ ceilometer alarm-combination-create --name meta \
  --alarm_ids ALARM_ID1 \
  --alarm_ids ALARM_ID2 \
  --operator or \
  --alarm-action 'http://example.org/notify'

当这两个底层的警告其中一个转换警告状态时,此创建的警告就会发出。此情景下的通知是一个webhook的调用。使用 andor的方法可将任意数量的底层警告组合起来。

Questions? Discuss on ask.openstack.org
Found an error? Report a bug against this page


loading table of contents...