监控告警成长之路.docxVIP

监控告警成长之路 2021-12-07 背景 在过去的两年里，我们从零开头搭建了整个事业群的监控。目前整套系统接入 200+ 的服务，700+ 的实例，收集了上万个目标。不停探究，历经曲折，方得自在。本文次要内容是总结两年间走过的路，趟过的坑，学习到的阅历。 一无全部 业务刚开头上线时，是没有任何监控的，全部的监控都是依靠接入层的Nginx的监控数据，全部的毛病都是从用户猎取到反馈才能发觉；排查问题依靠日志系统；从上游服务开头，逐层查询日志。每次发布上线内心都在敲锣打鼓。 疲于奔命 在业务第一个大版本上线之后，我们开头着手给业务系统接入监控，此时的选择是兄弟团队搭建的 Open-Falcon，使用 Grafana 作为看板。基于对立体化监控的理解，开头着手建立各种纬度的看板。 服务纬度：供应 Client、Server 端视图，从服务的形态、功能、质量、容量四个维度，分析需要添加到看板的目标 业务纬度：关注业务的关键路径，建立业务监控树，用于消灭问题时，快速定位到具体的服务 产品纬度：分析产品关键目标，构建公共看板 在这个阶段，我们投入了大量的人力资源到监控中，却收效甚微，次要有以下几点缘由： 从下往上的构建看板，需要不停的耗费人力补齐遗漏的目标 关注服务质量的目标多于关注产质量量目标，对于产品目标缺少足够的生疏 受限于 Open-Falcon+Grafana 的力量，建立和维护 监控和告警，人力成本极高 全部人都要摸索生疏监控的基础概念、门槛高 告警与业务关联度不高，业务一有波动就会误告，真正消灭问题又发觉没有配置告警 在这个阶段，我们投入了大量的人力，建立和维护各种看板，处理各种告警，疲于奔命，却不尽如人意。 前路始现 在第一个版本稳定之后，很长一段时间没有大需求，促使我们考虑如何处理这些问题。同时在这个阶段，在部门内部开头开发本人的 RPC 框架，基于在微信的工作阅历，促使我们把目光投向 Prometheus 等基于数据的监控平台。在监控方面，我们使用 SDK（数据上报） + Prometheus（数据收集）+ Grafana（监控看板），构建了更机警便利的看板。 服务纬度，在开发RPC框架的同时，将服务纬度的上报直接嵌入框架中，同时供应SDK给兄弟团队用于现有服务的接入。然后统一维护了两套服务看板：全局看板，具体看板。前者担任日常运营，后者担任排查问题。 业务产品纬度，SDK设计了统一简约的上报接口，便利构建业务、产品相关的看板 至此，服务纬度的数据变成了可以渐渐迭代优化的统一视图，随着阅历的积累，对监控的生疏越深刻，看板使用越是应手。在告警方面，使用 Prometheus（数据计算） + Promgen（规章管理） + AlertManager（告警管理） + Webhook （告警调用）+ 企业微信群，构建了完善的告警链条。 方得自在 在监控告警中，我们会频繁遇到以下问题： 阈值设定：不同业务场景，不同目标，如何衡量阈值是过于宽松，还是过于严格。 流量波动：在抱负的世界里，流量是有崎岖规律的，监控系统能够把握这种规律，当流量上升时，告警阈值自动上升 瞬态告警：每个人都会遇到这样的情况，同样的问题隔段时间就消灭一次，持续时间不过几分钟，来得快去得也快。说实话，你已经忙得不行开交了，近期内也不大会去排解这种问题。是忽视呢？还是忽视呢？ 信息过载：典型的信息过载场景是，给全部需要的地方都加上了告警，以为这样即可高枕无忧了，结果随着而来的是，各种来源的告警轻松挤满你的收件箱。 毛病定位：在相对简单的业务场景下，一个“告警大事” 除了包含“时间”（何时发生）、“地点”（哪个服务器/组件）、“内容”（包括错误码、形态值等）外，还包含地区、机房、服务、接口等，毛病定位之路道阻且长。 那么目前我们处理的怎样样了呢？ 问题 1、2，为了处理该问题，在监控平台里，引入了特别检测算法（anomaly detection） ，得到了很好的处理 问题 3，使用Prometheus的力量，得以处理 问题 4，我们对告警目标进行分级，只在调用链条的最上游配置细化的重要告警目标，告警之后通过链接跳转到对应的具体看板进行问题排查，告警更少更精确可查，维护起来也更简约了。 问题 5，目前仍旧没有得到很好的处理，但是已经有了方案，将在后续进一步优化 将来之路 基于 Prometheus 的数据平台力量，可以构建出业务全部服务的调用的树状图，并且当时的错误变化情况，进行自动毛病根源分析，这也是我们以后将要做的。附： 全局看板部分视图 - END - 点一下在看再走吧