关于告警系统的设计

参考：https://segmentfault.com/a/1190000003021919

什么是告警系统

当我们的服务器或某些业务指标出现差错时，告警系统可以反馈信息

为什么需要告警系统

减少人力监控，算是自动化运维的一种手段
这样不用时时盯着服务器，可以睡个稍微好一点的觉~

告警系统的要求

1.每次收到告警提示之后可以立即评估影响的范围，并且每一个告警都需要做出分级响应；

2.使一些无关紧要的事情不会告警；

3.要采集真正重要的指标，盲目地采集那些容易获取的指标，并随意地设定阈值告警是大部分糟糕的告警质量的根源。

4.告警的本质是当一些无法自动化维护的服务出错后，通知人去修正，所以一些可以自动化的操作，告警系统可以自己执行
比如服务器挂了，自动切换为备份机，再去人工修复主机。

告警的对象

• 1.业务规则的监控
• 2.系统可靠性监控

关于业务规则的监控的例子：
比如吃鸡中，不同的枪和被打中人的护甲造成的伤害应该是一定的，如果超过这个限度，就说明有人开挂了，这时候就应该告警了；

当然，还有很多其他维度，比如开枪后枪的后座力如何等等，只要不符合实际情况，即可告警。

关于系统可靠性的监控的例子：
比如服务器是否挂了，并发是否过高等等；

架构设计

系统1：
可以使用消息队列，来将请求和响应解耦，也加快处理速度，因为告警并非实时性的业务

当然，实际应用中，系统不会孤立运行，改造成的系统2如下：

最下方为其他系统，不同系统需要不同的资源
如一个DB会依赖于底层的cpu，内存，磁盘等资源；一个Http服务会依赖于底层的DB服务；一个应用会依赖于数个底层的RPC服务

采集的指标

• 系统1：
  请求的数量，请求到达的速率
  正常响应数，正常响应占比
  错误响应数，错误响应占比
  响应延时
  队列长度，排队时间

• 系统2增加：
  资源A的调用量（比如CPU使用率）
  资源B的调用量（比如内存分配和释放）
  资源C的调用量（比如网络发送包量）

如何判断需要获取哪些指标呢？可以根据我们的目标来判断：

a.系统是否在持续完成其设定的工作
b.用户体验是否好
c.问题或者瓶颈在哪里

第一个问题是最重要的，我们必须保证系统正常的运行，而系统能否正常运行，取决于许多服务，如DB等