03-浅谈监控与报警
前言
“报警”，“监控”都是一个大问题，而且搞不好还会有以下问题：
- 监控不到位，往往是被别人告知故障的发生；
- 报警信息杂乱，产生免疫力；
- 遇到验证故障时无处开刀；
So~, 带着上面的痛点我们来解析下正确的监控和报警的姿势。
1、基于用户监控
通过标题我们也不难发现，监控的核心应该是基于用户的监控，还有另外一种说话叫做“基于症状的监控”，同时还有另外一种监控方式“基于原因的监控”。我们更加推荐基于用户监控，比如：作为你产品的用户不会去关心你的MySQL是否是健康的，而用户关心的是输出是否能够正常加载，功能是否正常使用。
通常用户关心问题总是少数的，如：
- 服务的可用性，没有500，没有缺少Javascript或CSS或图像或视频，等或者其他影响用户体验的问题；
- 是不是够快，网页加载慢如乌龟；
- 功能，上线新的功能对用户的体验；
- 安全性，比如你某某账户中的资产；
数据库服务器和用户之前存在微妙的关系，但重要的区别是不可用和用户数据不可用; 前者是近因，后者是症状。我们不能总是的清楚区分这些东西，特别是我们没有模仿用户的监控方式（黑盒监控）；如果有条件我们应该配备上。
基于原因的警报很糟糕，但有时是必要的；但是，你可能会说，我知道无法访问的数据库服务器从而导致用户数据不行。没关系。警告数据不可用和警告症状500、白盒指标，这里请注意并非所有服务器都是从数据库中获取的客户。
- 无论如何，你将不得不抓住这个症状。也许它可能发生，因为网络断开或CPU争用，又或你没有的无数其他问题想到了。所以你必须抓住这个症状。
- 一旦发现症状和原因，就会有冗余警报; 这些需要单独调整，并导致重复或复杂的依赖规则；
- 据称不可避免的结果并非总是不可避免的：也许是你的数据库服务器不可用，因为您正在启动新实例或拒绝旧实例一。或者可能添加了一项功能来执行请求的快速故障转移，因此您不需要关心单个服务器的可用性。当然，你可以捕获所有这些情况随着规则越来越复杂，但为什么要这么麻烦？
但有时他们是必要的。 （通常）没有“几乎”用完配额的症状或内存或磁盘I / O等，所以你想要规则知道你正走向悬崖。使用这些要谨慎；不要为你可以捕获的症状编写基于原因的监控项规则。
1.1 故障
最佳的故障告警往往是来自客户端的信息，例如：
- 客户端可以看到重试的结果、客户端和服务器之间的网络延迟，以及与服务器相比可以更好地了解面向用户的延迟和错误；
- 在许多情况下，客户端正在聚合响应来自许多后端，如缓存服务、数据库、权限服务，其他服务等；
- 在许多情况下，客户端可以呈现比后端更简单的故障信息。对于例如：如果搜索分片服务器出现问题，数百个查询服务器，则每个查询服务器也都有有限的警报源。
于许多服务而言，这意味着警告最前面的负载平衡器所看到的内容延迟，错误等；这样，也只能看到服务器损坏的结果把它交给用户；相反，通过客户端你看到的问题比你看到的更多。
从服务器来说，如果他们全部关闭，或服务超时60s，或下降10％的连接，您的负载均衡器知道，但您的服务器可能不知道。
也需要注意，走得太远可能会引入超出控制问题。例如可以可靠地捕获用户看到的确切内容（例如，通过浏览器端），这非常棒！但是，信息充满噪音的（他们的ISP，浏览器）。
1.2 原因规则
基于原因的规则仍然有用。特别是，它们可以帮助您快速跳到已知的状态生产系统不足。
如果你在将症状绑定到原因上获得了很多价值，推荐技巧：
- 编写表示原因的规则时，请检查症状是否正确也抓住了；
- 每个监控项中触发的所有基于原因的规则的简要发出，可以快速浏览可以确定他们刚刚获得的症状；
- 删除或调整有噪声或持久性或其他低值的基于原因的规则；
如果调试仪表板可以让您从症状中快速移动到原因改善，无论如何，你不需要花时间在基于原因的规则上。
2、报警
无论如何，有一些需要尽快注意的警报，但现在不是；而是应该注意哪些紧急状态的。
推荐报警技巧：
- 有警报打开错误可以解决很好，只要同一警报的多次发出都能正确地连接成一个错误；如果没有对其分类和抑制该系统将失败；
- 报警信息要对应到人，不然这就是垃圾信息；
- 或许在有些时候，还需要报警升级的功能；
2.1 手册
手册是警报系统的重要组成部分; 最好有一个事件或者条目对于捕获症状的每个警报或警报系列，可以进一步解释警报的内容手段以及如何解决。
一般来说，如果你的手册有一个很长的详细流程图，这个记录可能出错的东西和修复它的时间太少 ，除非是根原因完全超出你的控制或从根本上需要人为干预。我见过的最好的手册有一些关于确切警报的注释意味着什么，以及目前有关警报的内容，大多数这样的笔记应该是短暂的，所以WIKI是一个很好的工具。
2.2 跟踪和完善
跟踪一个监控项和所有其他提醒：如果一个故障被发出，人们只是说“我看了，没有错“，那说明你需要删除监控规则，或降级或以其他方式收集数据。
建立一个系统（例如每周审查所有监控项和季度统计数据）可以帮助处理正在发生的事情的大局，并梳理丢失的故障信息。
