系统监控与报警的相关思考

背景

最近组内有一些关于系统监控与报警的讨论！一些同学觉得现在系统的error log太多了，由于每次打印error log，都会导致一次报警，导致每天都会收到大量报警，报警的噪声很大，很容易忽略有价值的报警。

下面是这次讨论的一些想法：

1. 应该在代码开发阶段，对error log慎重打印，只在对用户体验有感知的情况下，才需要打印
2. 利用大数据、人工智能的一些方法，对报警做拟合，用算法来对报警做降噪

上面两种想法，第一种，对开发人员要求比较高，而且很多时候，是很难判断是否对用户体验有感知的；第二种，目前业界没有比较成熟的方案，感觉可行性不大。

my thought

之所以报警的噪声大，我理解，是因为我们的报警系统，都是建立在系统层面上的，比如rpc调用超时了，某某接口调用报错了等等，并不能很好的反应业务层面，系统的运行状况，所以导致在看到报警时，我们无法对系统的运行状况有一个整体的了解。我认为，如果在业务层面，也做一层监控与报警，情况会好很多；比如我们是一个im系统，那可以对每秒钟消息的创建数量做监控，然后同比和环比做一下对比，如果某一时刻，消息的创建量有大幅度的下降，再进行报警，至少我们在收到报警时，可以肯定系统一定出问题了，再结合系统层面的报警，可以很快定位到系统哪里出问题了。

系统层面的监控

系统层面的监控，我理解应该分为两种情况：

1. 自动化监控，比如公司服务治理平台应该对rpc接口的qps、tp99等数据的监控
2. 开发者的手动报警，比如对系统的报错，打印错误日志，然后再根据错误日志的数量来进行报警

我觉得，对于系统的错误日志的梳理，应该是一个长期的过程，在系统的第一个版本，那些地方应该打error，是很难判断的,只有在线上，发现不合理的地方，再不断调整。

业务层面的监控

业务层面的监控，主要的工作有两个：

1. 决定业务指标
2. 打点

决定可量化的业务指标，是最重要的，比如广告系统的自然流量、收入等