# 在没有线上监控的情况下放肆裸奔




如果你的产品出现了一个线上问题，你会是怎么样的反应？

也许会跟下面这张图一样。

哇！有一个线上bug，好慌呀！！

咦，问题似乎自动解决了？ 渐渐冷静。

不对！！！ 这个问题竟然突然自己就好了？？？ 更慌了！！！

很多测试同学应该有上面这样的心路历程。线上bug不经意间出现，却又突然消失无踪，这会让我们精神紧张，心里各种没底，寝食难安。

这时候可能就需要做一些线上监控和告警了。

其实我之前有分享过，监控可以分为3个层次。

* 基础监控。线上机器的内存，cpu，硬盘，网卡等核心指标的监控和告警。
* 服务监控。服务监控程度的监控，比如接口的调用成功率，相应时间，错误码分布等。
* 业务监控。定义核心的业务指标，比如电商的核心指标就是订单数，对业务指标进行监控和告警，一旦业务指标有异常，立即告警。

基础监控和服务监控大家都比较好理解。这里稍微具体讲一下业务监控。

以电商的核心业务指标订单为例，假设我们通过各种方式计算出在每天下午2点的时候，大概一小时会有1万单，那么如果哪天下午2点左右订单数掉到5000了，那么可能是下单链路上某个环节出问题了，就需要立即排查。

另外业务监控也可以用自动化的方式辅助去做，这样监控的路径会更长一些，排查问题也能迅速一点。

还是以下单为例，我们可以在线上用一个特殊用户不停的买一些特殊商品（当然了，有影子库和特殊策略就更好了），如果下单流程失败，另外数据又监控到订单数环比确实有异常，那么就可以根据自动化用例的报错迅速定位到问题。

最近我们线上出了一次比较严重的事故，当然导致事故的核心原因是开发流程没有正确进行，不过没有线上监控而放肆裸奔也是求生欲不够强的表现，如果一些核心数据可以被监控和告警的话，我们可能在上线之后就能迅速定位到问题，而不会等到用户投诉再去处理了。

我们在线上监控很多时候都是通过阈值去感知变化的离散程度的，合理的阈值会让告警更加精准。不过由于一些突发性的原因，这些阈值可能会在短时间被突破，但是过完一个时间周期之后自动恢复正常，在这种情况下，为了减少误报，我们可能不仅要报异常情况，还要报问题自动恢复的情况。

关于监控工具，目前市面上有很多开源免费的监控工具，都非常好用，比如

* prometheus。普罗米修斯，github star超30k，部署简单，功能强大，小白入坑无脑选择的最佳推荐；
* open-falcon。小米开源的企业级监控平台，国内很多企业都在使用。高可用易扩展，可以分布式部署，自带dashboard，最关键的是有中文文档，英文拙计的同学可以试试；

2020年大家可以给自己定一个小目标，那就是生产环境的业务监控先跑起来，不要再放肆裸奔了吧。




原始封面

![课程图片](https://images.unsplash.com/photo-1516108317508-6788f6a160e4?w=300)