基于指标的报警
如同上文所提到的，Cloud Insight 支持不同数据源的报警。
而基于指标的报警是指，针对 Cloud Insight 采集到的指标，通过聚合的指标数值（选择标签信息），和设定报警条件（时间窗口、判断条件等），进行报警。
创建报警策略
有多个入口可以进入，创建报警策略页面。编辑已创建的报警策略，也会显示如下类似的页面。
所以，我们在此一同为大家解释页面的涵义。
创建基于指标的报警策略，分为以下几步：
1. 选择性能指标
如图仪表盘的创建监控图表，在创建基于指标的报警策略时，我们需要选择以下几个条件：
- 聚合算法：
minmaxavgsum。 - 指标名称：选择指标的名称。
- 聚合范围：选择标签信息，来确定指标聚合的范围。
如图，此时的检索语句为：
avg:docker.container.size_rootfs {container_name:auth1, container_name:auth2}
2. 设置报警条件
当选择完性能指标时，按照指标名称、聚合算法、聚合范围，会聚合为一条曲线。显示在页面上方。
此时，您需要根据这条曲线设置报警条件。包括：
- 时间窗口：规定在多长的时间窗口内，对一组数值来进行运算。
- 算法：规定该时间窗口内，对一组数值进行
平均至少一次总是总计计算。 - 判断条件：选择
小于小于等于等判断条件。 - 判断数值：选择判断数值。数值后可承接数值单位，如 K k M 等，数值单位的书写规范见国际标准。
- 数据丢失。
如图，此时的检索语句为：
avg(last_5m) avg:docker.container.size_rootfs {container_name:auth1, container_name:auth2} < 1.5 G
意思是，avg:docker.container.size_rootfs {container_name:auth1, container_name:auth2} 这条指标，在 5 分钟的时间窗口内的平均值，如果小于 1.5 G 则报警被触发。
稀疏型指标和密集型指标
因为数据指标的类型不同，可以根据数据指标对应的主机是否一直处于运行状态，将其分为：
- 密集型指标
- 稀疏型指标
如果一台物理主机，除开存在宕机、网络瘫痪，再或者保险丝被烧断，这些可怕的情况外；一直处于运行情况。那么该物理主机的 system.load.1 是一个密集型指标。
因为 Cloud Insight Agent 会一直采集数值，并上传给后端。
而在 AWS 中由于存在 Auto-Scaling 机制，一些主机只有在业务量特别大的情况下，才启动。此时这些主机的 system.load.1 只有业务量增长，才会有数值。此时该指标就是一个稀疏型指标。
而在 Cloud Insight 测试环境中，Docker 的 Container 存在周期性的停止和重启，此时 Docker 有关的指标，都是稀疏型的。
当如果一个指标是密集型指标时，那么掉点就意味着重大事故已经发生。此时，应该选择：当数据丢失超过 X 分钟时，通知用户。。反之，则不通知。
而数据丢失的检查的窗口，最小值为 10 分钟，且只能为整数。
在报警条件的 2.算法 选择中，我们提示用户：
对稀疏的指标设置报警条件时，建议使用「总计」或「至少一次」来设置；因为使用「平均值」或「总是」的条件时， 只有当指标在选择的时间段内是一条较为完整的曲线时，才准确；而针对稀疏的指标时，触发会不准确。
也是因为不同场景下，需要设置不同的算法来保证报警触发的准确性。
3. 命名报警
给报警策略取一个您和您的同事都可以快速了解系统运行情况的名称吧。
4. 通知用户
选择当报警触发时，需要通知的用户。
Cloud Insight 会通过邮件的方式通知他们，策略被触发和关闭。
为了避免报警风暴的产生，Cloud Insight 设定最小的邮件发送间隔为：20 分钟。