日志监控告警系统实践

Posted 2021-05-02 微保技术

基于日志的应用监控告警系统，能帮助我们及时发现问题，将问题消灭在萌芽阶段，防患于未然。

01

背景

监控告警是IT系统基础建设中非常重要的一环，可以帮助开发和运维及时发现线上问题，从而能够快速响应，防止问题进一步扩大化。

业界有很多开源的监控告警产品可供选择，但是大多数产品都是基于服务器的硬件资源、系统性能或者数据趋势来实现的，通常需要问题积累到一定程度以后才能识别出故障并发出告警，在时效性方面还是有一些滞后。有没有办法能够提前一点感知和发现问题呢？

由于应用系统都会输出日志，而错误的第一反馈点就是日志，如果我们能够把这些日志有效地利用起来，基于错误日志进行监控告警，就能够更及时地感知和发现问题。

日志监控告警还有另外一个适用场景，互联网业务开发通常需要支持快速敏捷迭代，有一些复杂的、可测性不高的需求场景很难在有限的时间内做到完全充分地测试，难免会遗留一些隐藏bug，很难通过一般的监控告警手段及时发现，通常是程序上线后用户反馈了才知道，但是有了日志监控系统，只要在异常的地方有错误日志输出，开发就可以第一时间发现问题从而快速响应。

业界也有一些应用监控告警系统是基于埋点上报来实现的，代码侵入性比较强，且上报埋点需要提前预判是否可能存在问题，如果没有准确预判或者忘记上报埋点就无法实现监控。而程序代码中通常都会有日志输出，即使开发忘记输出日志，在程序出错的时候也通常会有底层框架或者依赖组件输出错误日志信息。

基于日志的应用监控告警系统，为业务开发提供了极大的便利，它作为全方位立体化监控平台建设的一个有效补充，帮助我们更早一步发现问题，将问题消灭在萌芽阶段，防患于未然。

微保自研的日志监控告警系统目前已经全面应用到公司内部的各个业务模块，我们也利用这个系统提前发现了大多数的线上故障。接下来介绍一下我们的实践经验。 

02

实践

我们的日志监控告警平台经历了从无到有、从最初作为一个自给自足的小工具起步，逐步迭代优化，最终进化到一个功能相对比较完善的平台，主要经历了以下三个阶段。

第一阶段：Agent分散管理

作为一个新团队，项目初期一切追求快，所以我们先解决“有没有”的问题。我们首先开发了一个错误日志监控的小工具，实现原理也很简单，就是在应用服务器上部署一个agent客户端，监控错误日志文件的变化事件，发现错误以后直接调企业微信http接口发送告警信息，通过客户端配置文件来配置日志监控路径和告警接收用户的企业微信id。

这个小工具上线以后逐步成为我们应用服务部署的标配，同时我们在推动应用服务部署标准化的时候也进一步规范了日志输出的规范，包括日志路径、日志格式、日志级别等标准。

但是随着业务量的增长和应用服务模块的增加，问题也逐步凸显。其中最主要一个问题是告警刷屏问题，有一些确实是程序bug或者配置错误之类的问题导致的告警，但更多时候并不是问题导致的告警，只是开发在写代码的时候觉得某个逻辑可能会有问题顺手多打了一行错误日志，结果上线以后发现这个错误是正常逻辑，或者是暂时无需关注的错误，但是却依旧会刷屏告警，而且像这种无意义的告警还非常多。

针对告警刷屏的问题我们做了一些优化，例如在本地配置文件中添加了一些错误关键字过滤、告警收敛策略等，但还是不能有效解决问题。其中一个原因是需要登录到各个服务器上修改配置比较繁琐，另外一个原因是每个应用服务集群都有多个节点，无法做到统一的频率控制，例如部署了四个节点，即便每个节点都做了频率控制，也会同时收到四条告警。当告警逐步增多到一定量级的时候，大家也都逐渐降低了告警的敏感性，这样告警也就失去了它本身的价值。

第二阶段：平台化管理

上面讲到我们虽然针对告警刷屏问题做了一些针对性的优化，但因为agent客户端是分散的，不能集中管理，所以无法有效解决问题，因此这一阶段我们调整了架构，做了一些重构优化，同时也进一步丰富了功能特性：

• 将原agent客户端的功能做了拆分，增加了告警服务端，agent只负责收集和上报错误日志。

• 服务端支持丰富的告警配置和收敛策略。

• 新增了报表统计功能，支持查看各系统的错误日志和告警发送次数以及趋势。

  
  

下面重点介绍一下我们这个阶段主要解决的告警刷屏问题。我们从频率规则、分组和开关三个角度来收敛告警。

首先是通过错误关键字的出现频率和次数进行收敛，主要支持以下规则：

• 关键字排除，匹配到该关键字的错误日志不发送告警通知。例如一些已知的错误，可能没有什么业务影响或者评估为暂时无需处理的错误，我们不希望再接收到此类告警通知以免干扰到其他新的或者更重要的错误告警，就可以先通过关键字排除的方式忽略掉，等后续迭代优化代码逻辑，不再输出此类错误信息或者将错误日志降级处理。

• 关键字在x秒内出现y次以上发送一条告警，x秒结束以后再发送一条汇总计数告警，这里的x和y都可以按照实际的业务场景灵活地调整到一个合理的范围。主要应用场景如下:

  a). 某个已知错误暂时无需处理，但同时我们希望能够定期关注它的出现频率。

  b). 某个错误在60秒内出现10次以下，可能是用户正常操作错误或者客户端兼容之类的问题，我们暂时不需要关注。但是超过10次以上，可能是接口被恶意刷了或者下游出现异常了，我们需要积极应对。

• 告警数在1分钟内发送达到系统默认阈值以后，发送一条汇总的通知，不再额外发送新的通知，直到告警数降到阈值以下恢复正常。主要是防止某些突然出现的新错误大量刷屏，这样的错误如果放任不管其实是没有任何意义的，而且可能会导致忽略其他更重要的告警，所以额外做了一层默认的控制。

其次是分组功能，之前举的一个例子，如果有四个服务节点同时报错瞬间收到四条错误告警，我们在服务端集中处理以后，就可以按照应用模块进行分组统计，再按照规则发送告警通知。另外我们针对告警接收人也做了分组，我们按业务归属创建了监控告警企业微信群，同一个业务组的错误告警集中发送到一个群里，这样也避免每个人都收到零零散散的通知不能及时处理。

最后是开关功能，这个是最简单暴力的，就是给所有告警按照应用系统的维度加了一个全局的开关，在关闭开关以后就不会发送任何告警通知了。主要应用场景是已知在处理的错误，避免继续刷屏就可以临时关闭所有告警，但这其实是一个比较危险的操作，更多时候还是使用基于频率规则的告警抑制功能。

经过这一轮的优化，监控告警功能也趋于完善，逐步成为开发运维过程中不可或缺的一个工具。

第三阶段: 容器化管理

CVM的部署架构存在服务器资源利用率低、扩容缩容效率不高等问题，公司也启动了容器化部署架构升级来降低服务器资源成本和提升开发运维效率。为了更好地适配容器化部署架构，日志监控告警系统也启动了新一轮的迭代优化。

按照之前CVM部署的系统架构，监控告警的agent客户端进程是跟业务系统进程部署在同一个CVM上的，而且客户端的进程还有一些简单配置，例如系统名称等都还是在客户端配置的，如果继续应用到容器化部署架构里，就会导致容器不够轻量，维护配置起来比较麻烦。

由于我们用到了ELK收集分析日志，在每个node节点上启了一个filebeat进程，统一收集上报到ELK，而监控告警系统的客户端进程功能跟filebeat很类似，主要都是用来收集和上报日志的，所以我们跟ELK做了整合，监控告警的日志收集上报功能也基于filebeat实现。

整合后的架构是filebeat采集上报日志到logstash，再由logstash写入kafka，Log Monitor监听kafka消息，处理告警逻辑。因为基于kafka异步处理，本身会有一个削峰限流的作用，所以这样改造以后我们的系统更加健壮了。

另外我们也跟公司内部的BLC（统一运维管理平台）做了融合，将配置功能放到了BLC统一管理，而BLC里也集成了CMDB的功能，这样我们就可以基于CMDB做监控告警。

这一阶段的重构优化没有再额外引入新的功能，主要是跟公司的系统架构做整合和优化，同时也进一步提升了易用性。

03

未来展望

这一套应用监控告警系统目前已经全面应用到公司内部的各个业务模块，也为开发和运维工作带来了很大的便利。 关于未来的优化方向有以下几点思考。

• 进一步完善功能，提升易用性，提高定位分析和排查问题的效率。 我们会跟目前正在建设的基于ServiceMesh的全链路监控系统做整合。现阶段我们是接收到告警上报的问题以后，去ELK查询和定位分析问题，未来希望能够通过点击告警通知中的链接自动跳转，通过跳转链接中的traceId就能够快速拉通各个微服务模块的调用堆栈，能够看到各个环节的调用状态和处理时间以及上下文日志，从而快速定位到错误原因。

• 将错误告警中发现的问题进行闭环处理，即：发现->记录跟踪->解决。 工具有了，怎么利用好这个工具则是我们需要面对的更大的挑战。就好像我们做了一扇门，不断地去改进让它更牢固更好用，但总是会有人有意无意地忘记关门，可能他只是为了自己方便，也可能就是懒得关或者忘记关了，这样不管我们怎么改进还是不能解决问题，要想办法让大家都养成关门的习惯。虽然告警屏蔽和收敛功能用起来比较方便，但是怎么能够避免有人滥用，怎么让所有人都能够及时去响应和处理问题，怎么进一步规范大家的日志习惯和提高告警的敏感性是我们下一步要解决的问题。目前我们在尝试把错误告警发现的问题同步到tapd，以bug管理的形式来帮助大家记录和跟踪解决问题，从而规范约束和形成好的日志习惯。 只有大家用好了这个工具，线上服务的稳定有了保障，这个工具的真正价值才能发挥出来。

以上就是在开发和建设这一套日志监控告警系统过程中的实践经验和心得体会，希望能够带给大家一些启发，也欢迎感兴趣的同学与我们进一步交流探讨。

后台留言功能已开启，欢迎留言吐槽哦~

or

长按扫码可关注

▼ 请长按二维码，可加入我们哦！▼