关于告警系统的设计
参考：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等