共计 2371 个字符，预计需要花费 6 分钟才能阅读完成。
大家是否遇到过这样的场景，老板在群里 @ 你，向你反馈线上有 BUG。个别老板反馈的问题，都属于重要且紧急的需要，须要疾速解决。这样的高优需要，即让你神经紧绷，又突破了你原有的打算，经常弄的人很累。靠充沛的测试可能解决一部分问题，然而线上的场景永远比测试的场景更加丰盛，难免会有脱漏 BUG 被带上线，造成业务损失。
牢靠地、实时地、精确地提前发现问题
一个好的告警零碎会提前发现问题，收回正告。你就有可能在老板 @ 你之前，就把问题给解决。
告警零碎要提前发现问题的三个要害是：
- 可靠性。告警零碎自身要牢靠，不能时灵时不灵。
- 实时性。要快，慢了就没有意义了。
- 准确性。狼没来，喊狼来了，喊了三次后就没人信了。
接下来，我会先带大家看下咱们的告警零碎设计的全貌，再从可靠性、实时性、准确性三方面来具体介绍。
实时告警：整体实现
实时告警性能次要的工作量在 node.js 层，其整体实现如下：
- 每分钟批量执行一次定时工作
- 向 Druid 发出请求，获取线上实时的聚合数据
- 判断聚合数据是否超出阈值，如果超出则执行下一步
- 发送短信、微信、邮件告诉开发者
可靠性：每台机器启动一个定时工作，会执行屡次
一台机器运行定时工作，只有一个定时工作，指标超出阈值也只会收回一次告警。
然而，为了保障可靠性，咱们就要防止单点危险，也就是至多要启动两台机器来运行定时工作，即便其中一台机器挂了，告警性能也能失常运行。然而，引入多台机器问题就来了。
二台机器运行定时工作，有两个定时工作，会收回两次告警。分布式 node.js 集群，会有多台机器运行定时工作，超出阈值就会收回屡次告警，引入了反复告警的新问题。
定时工作：Redis 锁保障只执行一次
咱们须要的是多台机器，只执行一次定时工作，有啥方法来保障呢？咱们想了两个计划。
- 共识计划：一个集群中的多台机器之间，选出一台机器来执行定时工作。
- 抢锁计划：一个集群中的多台机器同时向 redis 发出请求，谁抢到 redis 锁谁执行定时工作。
共识计划，在 Java 中有 zookeeper 之类的散布式调度工具能够应用，底层共识算法会选举出一台机器作为主 (leader)，其余机器作为从 (follower)。能够只让主机器执行定时工作。然而在 node.js 中，咱们并未找到相似于 zookeeper 的框架，所以就放弃了。
抢锁计划，是咱们采纳的计划。其原理是通过共享缓存的唯一性，来保障定时工作执行的唯一性，依赖的是 redis 的可靠性。在理论的业务中，咱们认为 redis 比较稳定，单台就够了。如果当前发现问题，再改用多台 redis 也不迟。node.js 中有 bull、redlock 的分布式锁工具能够用。
- bull 的性能次要是分布式队列，用来实现分布式锁有些大材小用。
- redlock 是 redis 官网提出的分布式锁算法，也有 node.js 的实现，正好合乎咱们的需要。
因而，在告警性能的可靠性上，咱们应用了 node.js 集群，防止了单点故障。同时，应用 redis 锁，保障一个告警定时工作，只会执行一次。
实时性：要害是“快”
实时性的关键词是“快”，从用户异样产生到开发者收到异样告警的工夫越快越好。
其中关键点是：
- Web 产生异样后，马上上报，SDK 层不缓存。
- 应用工夫序列数据库 Druid，缩小海量数据聚合耗时。
- 每分钟 node.js 执行一次告警定时工作。
大家能够看到，从产生工夫到告警工夫，两头有 8 个工夫点，用哪个工夫点好呢？
在 8 个工夫点中，最为要害工夫点有 2 个：
- 产生工夫（橙色）：用户行为轨迹须要对用户异样日志、失常日志按工夫进行排序。异样日志是立即上报的，失常日志是用户被动上报的，这就只能用产生工夫进行排序，其余工夫必定都不对。
- 接管工夫（蓝色）：开发者搜寻某天某个用户产生的异样，如果用户本地工夫是错的，可能就会搜不到。但咱们能够置信，服务端的接管工夫是精确的，依照接管工夫搜寻，必定能搜到。
那么告警指标的统计以那个工夫点为准呢？具体的统计形式应该怎么设计呢？
实时性：统计形式
从两方面思考，咱们的统计工夫点用的是接管工夫。一方面，服务端工夫的准确性是咱们本人管制的，是可信的。另一方面，思考有海内用户会跨时区，时区问题解决起来会比拟麻烦，对立用服务端工夫更好。
然而，这里还是有一些细节须要大家留神，从接管到可被读取之间，还有通过 kafka 音讯队列和 druid 聚合计算的工夫。实践上 kafka 只有不产生音讯沉积，是能马上被 druid 进行生产的，druid 自身又有实时计算模块，聚合计算也是十分快的。然而，咱们思考到可能会有偶发的一些超时状况，可能会导致统计数据偏少，从而导致误报。因而，拍脑袋给 kafka 和 druid 预留了 1 分钟的缓冲工夫，算作对实时性的一种斗争吧。
准确性：线上异样的总量监控指标不牢靠？
当初，咱们来聊聊最初一个个性，准确性，也就是告警指标是否可不牢靠。
咱们假如一个场景，有位开发者看到异样总数这个指标疾速回升，他心中一紧，这线上是啥状况啊？
如果凑巧，前端页面刚刚有上线，大概率是前端问题。
如果凑巧，后端同时收回宕机告警，大概率是后端问题。
如果凑巧，业务刚刚在冲量，那么引起页面异样总数指标疾速回升的起因，大概率只是因为 PV 涨了而已。
同理，在 0~6 点是业务范围量少，到了 8 点~10 点，流量会有很大的上涨，同时也会影响异样总量上涨。
准确性：异样 PV 比代表均匀每个 PV 产生异样的数量
在异样总数和 PV 同步增长的状况下，异样 PV 的比值其实会放弃不变。其起因是均匀用户每次拜访，页面产生异样数量是一样的。因而，在咱们的业务中，绝对于异样总数，咱们认为异样 PV 比的变动更重要。
当业务异样 PV 比大于预设的阈值，或者环比回升较快，那么就能够判断线上呈现新的异样了。并向业务收回告警。
准确性：全面的监控指标
为了更全面的监控线上利用，咱们设定了一系类的监控指标，其中深蓝色的是外围指标，它的准确性会更高一些。
