告警的指标设计主要围绕2个方向进行，一个是指标，一个是维度。
指标
指标顾名思义就是我们常说的指标项。简单来说，指标是有两部分组成。
- 指标名
- 指标值
指标一般都是可量化的东西。
例如cpu使用率80%，线程个数20。
按照这个角度，例如我们常说的地名等字符表达的信息，一般都是维度。
维度
维度相当于指标信息的补充。
例如下面这个指标
cpu 80
单独看这个其实获取到的信息很少。这是那个机器的cpu使用率，这个机器所在的机房是哪个。他是什么业务的。什么时候发生的。所以我们尝试补充下面的信息。
ip 192.168.0.1
业务 1号产品
产品级别 测试
安全度 低
发生时间
加上这些信息，我们的表达就更明确了。
演变
我们常常看到的指标，其实是指标和维度的组合。
那我们为什么非得区分这些呢。这个就有很多的演变了。
随着机器的增多，原来单机的玩法在找异常的时候是可行的。那么如何衡量现在运行的状态呢。指标的聚合也就出现了。
聚合的角度是什么，主要就是我们的维度。
例如看看1号产品的cpu数据，一看3000条。这里是不是得看看最大值，最小值，平均值，中位数。这些都需要按照维度进行区分。
此时产品了一条新的指标。他是1号产品的cpu使用率平均值。在聚合后，其余维度就自动消失了。我们只能看到个如下
cpu_avg 30 产品1 时间点
产生新的指标，是查询的一个需求。
3000条数据的筛选，运算是需要时间的。如果查询的时候反映不会很快，随着数据越来越多。这个问题会越来越严重。
这里就需要进行预计算。
例如采集的时候先按照集群，产品进行求和。记录总数和求和值。后面再聚合的时候可以直接获取集群的数据。集群的数据相比原来的数据就小很多了。这样就形成了一个金字塔的结构。一层一层的预计算。
维度与告警
维度最重要的一点就是可以用来减少告警。
在相同水平扩展出来的业务中。出问题的时候，往往可能不是一个，而是一群。这就造成了告警的洪荒。维度是我们识别一群的主要手段。
指标的暴露设计
指标设计有个很难的点就是如果丢数据了怎么办。例如传输过程中，丢了2条。我们是否能接受这样的场景，没有一种情况是完全可靠的传输。在指标设计时，是否能弥补丢失的指标呢。我们常用的方式就是累加值。数值是一直累加的。
1 1
2 2
3 3
4 10
加入2丢失了，我们依旧可以再1和3之间反应出增长了2。只不过无法确定1个时间间隔内的效果。例如丢失的是3。2个点增长了8。知道增长的挺多的，但是无法确认3的情况，这里他是算，如果线性补偿的话，那这里应该是6。其实与3的真实情况不吻合，但是保证了一个大概的趋势是正确的。