前言
最近在做监控告警相关的东西，基本新上功能或者应用服务之类的东西的时候，都要搞一堆监控告警来观测。然而很多（特指我）开发同学在碰上问题之前并不太清楚需要搞什么告警。
ps: 下面这些内容很多都是从SRE google运维解密这本书看来的，结合点自己的理解。
一、为什么要监控
1. 分析长期趋势
技术层面：根据监控可以看出数据的变化量，资源情况。从而判断是否需要扩缩容。
业务层面：可以根据调用量增长速度来判断决策是否正确，新需求是否受欢迎和应用现在火不火等。
2. 对比
在架构变更或者技术更新、业务代码优化后。对比变化情况。
从而判断新方案是否和旧方案对比下来优化了多少（重要指标，汇报吹牛逼用）。
以及是否在自己没考虑到的地方带来了什么不好的效果等等。
3. 告警
有东西出故障了，需要修复。或者根据数据发现可能会出问题了。
4. 构建监控页面
基于监控数据，可以构建一个良好的监控页面用于直观的观测数据。以及汇报使用
5. 协助分析问题
当出现问题时，可以根据监控指标来判断问题可能出在哪里，比如缓存或数据库的负载情况，cpu占用情况等等
二、关于怎么监控
2.1 黑盒监控&白盒监控
黑盒监控:针对某种现象或者功能的监控，比如A接口异常等
白盒监控:针对系统内部信息的监控，比如日志、业务节点存活状况、数据库情况等。
2.2 四个黄金指标
监控系统的四个黄金指标是:延迟、流量、错误和饱和度(saturation)。
延迟:
服务处理某个请求所需要的时间。需要注意的是，区分成功请求和失败请求是很重要的。比如失败请求因为数据库连接丢失或其他原因导致的失败。若计算总体延时时，全都记录在内，可能会产生误导性的结果
流量
主要是使用某个高层次指标对系统负载和繁忙程度的度量。对web服务器来说，一般是指http每秒请求数量。对音视频流媒体来说，可能是指网络IO速率等。不同的服务有不同的度量方式
错误
请求失败的速率，显示失败（请求500）、隐式失败（请求200但是返回中包含错误信息）或策略失败（例如要求1s内返回，超过1s的就算失败）
饱和度
服务容量的饱和情况。通常指系统中重要首先指标的情况。例如IO,内存等。在简单系统中（例如返回一个唯一单向递增ID的服务），根据测试得到的数据可以设定一个指标。但大部分情况都是复杂服务，可以根据其他高层次的负载度量来使用，例如cpu利用率，或者网络带宽等代替。P99可以作为一个饱和度早期预警的指标，因为负载较高的时候，延迟增加是一个常见的现象。
2.3 关于长尾问题
长尾问题是指影响较小的部分存在较多的实例。
很多人倾向于采用某种量化指标的平均值，如果cpu平均使用率，延迟平均使用率等。而且这样的统计不一定是准确的，cpu利用率就不说了，波动较大。
比如某个web服务QPS=1000，平均请求延迟为100ms。但是1%的请求占用了5s时间。然后前端依赖了多个这样的后端服务，这个时候后端的P99可能会成为前端延迟的中位数。（如果1%的请求需要10倍的平均时间，那么其他请求大概只需要平均值的一半）
一个比较好的方法是按延迟分组（可以用来绘制直方图）。如0-10ms的请求有多少，30-100ms的请求有多少，100-300ms之间的有多少。据说将直方图的边界定义为指数型增加是展示的最好方式。
2.4 采用合适的度量指标
针对不同的监控需求使用不同的进度进行度量
- 观察1分钟内IDECPU平均负载可能会导致上述的长尾问题
- 对于年可用率99.9%的服务来说，每分钟检测1次或2次可能过于频繁
- 对目标可用率为99.9%的服务频繁检测硬盘空间也是没必要的
降低成本
如果有高精度监控数据的需求，但是不需要极低延时的话，可以通过内部采样外部汇总的方式降低成本。
例如：
当然了，现在大数据这么普及，搞一套所有服务通用的监控系统也是没啥毛病的。
同时对于不同层面的系统采集的监控也不同，层面越高的监控现象越容易，而数据库的性能参数饱和度等，应该直接走数据库采集。
三、关于告警
3.1 告警信息需要明确
告警和监控需要解决的两个问题，什么东西故障了，以及为什么故障。
告警是为了提示或者预防故障，重要的是可以根据告警信息快速的定位问题，解决问题。同样的，监控系统的信噪比应该很高，发出紧急告警的时候，告警应该简单易懂，同时代表了一个清晰的故障场景。
比如: 当发生慢请求的时候，如果能判断出来是数据库慢，则发一条数据库缓慢的告警，否则发一套网站缓慢的告警。
3.2 不要随意发送紧急告警
告警不应当依赖人来分析，而是应该有系统自动分析，当需要人工处理的时候，才触发紧急告警。如果可以自动处理，那么他就不应该成为紧急告警。
处理紧急告警会占用俺们的宝贵时间，打断原有的工作进程。如果在家，那就更完蛋，会影响个人生活。并且容易出现“狼来了”的情况。怀疑告警的有效性甚至忽略这个告警。
不要出现大量的无效告警，这样会影响处理真正的问题。
3.3 区分告警方式
不同的告警可以区分不同的方式进行处理。
当紧急告警和非紧急告警混杂在一起的时候，很容易漏掉关键信息。
可以构建一个良好的监控台页面，展示所有的非紧急异常情况。而紧急异常情况则需要紧急方式告警，例如短信。邮件等。
四、总结
监控和告警应该是非常简单、易于理解的。
紧急告警应该针对现象。
需要根据实际情况和需求合理制定监控指标
短信或邮件告警通常价值有限，不要把告警直接全怼上去
