“哎哎，XX，很多客服反馈这个业务挂了怎么回事，赶紧看看。” 正在安安静静写代码的你心头一颤，出问题了。赶紧打开业务链接看看，真出问题了，怎么办，怎么查问题？一脸闷逼。
据说
现代医学始于听诊器的发明，医生凭借该物收集放大从各个器官发出的声音以诊断问题。
我一直喜欢把我们做后台做业务的，称之为
在快速飞行的飞机上修零件。边飞边升级。
。在飞机上有各种各样的仪表盘指示着各个模块的运行情况。如果没有这些，估计只有等到飞机坠毁的时候才知道出问题了，这个时候为时已晚。
飞机如此，我们的业务与服务又该有什么样的
仪表盘/听诊器
呢？
这是我这篇文章想说的，当我们自己的后台服务及业务运行情况生病出问题了，怎么做好服务/业务的仪表盘-
业务监控告警
。
意义与想要达到的效果
没有一个系统是100%没有问题的，那么我们要保证我们的业务和服务的可靠性。我们希望达到如下的效果：
- 我们要能够及时的发现问题（先于客户/老板发现问题）。
- 不想每天半夜爬起来处理不知道怎么来的问题（有一些事情准备）。
- 出了问题，能够帮助我们，快速定位问题。
需要想清楚的问题
为了达到这样的效果，我不得不思考我们需要解决的问题和点。
1.什么是我们需要关心的点
只有了解你的业务，才能做出更好的系统设计。
通常来说，只有了解你的业务，你才知道哪些点应该是你重点关注的、哪些点是容易根据业务进展而做扩展的。一般来讲，一个业务服务应该关注的点，我觉得如下：
- 机器系统资源（CPU/内存/网络/磁盘）、CDN等。
- 如果是JAVA，需要关注JVM虚拟机运行情况。
- 接口的调用量、耗时情况、错误异常等。
- 具体业务节点（如注册、开户、交易、付款等等流程）
- 具体运营节点（运营渠道来源统计、场景等）
2.怎么定义异常情况
通常来讲，如果没有什么特殊处理，今天同一时间与昨天同一时间的监控数值应该会基本一致。基于这样一个依据，我们可以做一些比较以发现问题。
- 同比 ：当前时间跟昨天同一时刻进行比较，是上升还是下降。 用于突然的掉底或上升问题发现。
- 环比 ：当前一段时间与前一段时间比较，一般用得比较少。
- 七日平均值 ：当前时间与前七天同一时刻平均值进行同比。减少某天波动带来的影响。
3.什么时候发现异常情况
通常来讲，做一件事情，
投入的成本
、
时效性
、
准确性
三者之间同时达到比较好的状态是一件及其困难的事情。这个时候我们希望投入的成本带来最大化的，部分作出妥协。
- 实时监控处理：强调实时性，针对关键节点、存在少量数据不一致或丢失情况。
- 隔日处理：有充足的资源、全量节点、数据准确、利用大数据能力。
4.异常的程度如何
如同一个人生病一样，可能只是一个小感冒，也有可能得了大病。我们不可能为了小感冒而住院，也不可能忽略了大病的存在。因此我们需要给异常分级处理。
