我经历过的监控系统演进史

转载：https://www.cnblogs.com/imyalost/p/14989371.html

基础必知

要对监控有个全面的了解，大体要了解三方面的知识，如下图所示：

常见监控类型

一般在企业级技术监控领域，大体分为五种类型的监控：

1. 基础监控：包括带宽、CDN、服务器CPU、Memory、DiskIO、Network、Load5等指标；
2. 指标监控：服务+接口维度，常见指标有QPS、TPS、SLB、RT、99RT、timeout、activethreads等指标；
3. 业务监控：拿电商来说，常见的有同比下单量、支付量、履约率、DAU、GMV、支付取消率等多重指标，一般需要根据具体的业务需要来定制化；
4. 链路监控：链路监控主要用来快速定位排查问题，在目前大多数互联网公司的微服务架构下，服务调用关系复杂，链路追踪监控可以帮助技术同学快速的找到调用链路上某个环节的问题；
5. 舆情监控：主要指对外部的一些讯息的监控，比如某APP突然挂了、下不了单、有BUG可以刷单、客诉等一些列对企业或者品牌不利的因素，便于快速处理甚至公关；

处理过程及注意点

监控从采集到告警通知，大体分为五个步骤，每个步骤的注意事项各有不同又有部分通用的考虑。

1. 数据采集

• • 释义说明：通过各种方式采集原始的相关数据，常见的有agent、埋点等方式；
  • 注意事项：主要为数据采集对业务服务的性能损耗以及对业务的侵入性两点：
    • 一般采样都是百分比采样，比如10%，如果100%采样，对业务服务的性能损耗会比较大；
    • 良好的监控系统，对业务来说应该是无感知的，能快速接入又不影响正常的业务迭代；

2. 数据存储

• • 释义说明：采集到的原始数据需要进行存储，以便于进行后续的聚合计算；
  • 注意事项：这里需要注意的点为存储时间和成本控制两方面：
    • 存储时间：大多场景只关注最近一周或最近一个月，但有时候为了审计安全等需要，部分数据需要存储的时间会比较长，甚至有1-2年，因此需要根据具体情况来设定数据过期和清理时间；
    • 成本控制：有些场景对数据的实时性要求比较高，因此需要存储到高速SSD，有些场景数据实时性没那么高，就可以考虑更低成本的存储方式，甚至做数据归档，然后离线计算的方式来进行后续的计算；

3. 数据计算

• • 释义说明：通过对采集到的原始数据进行各种维度的计算，才能得到我们想要的监控指标；
  • 注意事项：数据计算这一环节，主要考虑的点为计算速度和结果的准确性：
    • 计算速度：上面提到了，某些场景对于数据的实时性要求较高，因此在计算环节就需要考虑到这点。在具体的技术方案实现过程中，需要根据不同的业务需要来采用不同的技术选型和实现；
    • 数据准确：比如上面提到的每分钟订单量，以及履约率、错误率等指标，对准确度要求是比较高的。再比如QPS这种指标，如果实时计算，对服务压力比较大，但如果取单位时间的均值，又会造成结果的准确性降低，因此在实际实践过程中，需要综合考量。

4. 数据展示

• • 释义说明：即通过界面动态可视化的方式，将我们关注的监控指标进行展示。
  • 注意事项
    • 时延：时延这部分，上面已经阐述过了，主要还是要考虑到具体的业务场景，灵活采用技术方案；
    • 便捷：监控是个很复杂庞大的体系，但对使用者来说，往往只关注和自己有关的模块，因此便捷可定制化的展示，良好的界面，是很需要下功夫去设计的。

5. 告警通知

• • 释义说明：将已发生的或者即将发生的错误异常及时通知给相关同学，快速处理，降低影响。
  • 注意事项
    • 时延：告警是需要及时的做到通知的，因此对实时性要求很高。
    • 降噪：这涉及到告警的一个敏感度问题，某些阈值怎么设置，通知到谁，怎么通知，不同等级的告警采用什么方式通知，都有很多需要考量的方面。

监控体系

监控体系是个很庞大复杂的体系，从技术角度来说，可以看下面这张图：

更多关于监控分级体系的内容，可参考我之前的博客：性能测试从零开始实施指南-性能监控篇 

工具漫谈

这一部分，聊聊我自己使用过或者了解过的一些监控工具，就是个漫谈部分。

刚开始从事测试工作时候，公司还有部分服务是Windows server服务器+SQL server的数据库。

那时候的监控，基本就是Windows自带的各种计数器，界面是很直观，但放在现在的时间点，应该只有极少数公司有这种情况。

后来在银行接触到运维同学搭建的Zabbix以及基于Prometheus+grafana搭建的一套监控。

zabbix从我个人角度来说，是个综合性质的监控工具，够全面，但只适合中小型企业。

当需要处理的数据和定制化需求较强时，他会有越来越明显的短板。

Prometheus体系算是监控领域很全面灵活的，支持多种数据源，灵活配置可定制化，很多企业都在使用这套体系，但到了一定的层级维度，灵活往往会变成桎梏。

上家公司最初接触到的是听云，高度企业级商业监控工具，但成本和灵活度又是另一个维度的考量因素。

后续运维和监控团队的同学陆续介入了pinpoint、cat、Prometheus、skywalking、jaeger，arthas，再演变到现在的二次开发封装的一站式监控平台。

pinpoint的采样和链路追踪做的是比较友好的，但太灵活，反而在某些阶段，不是最优解。

cat是美团开源的监控产品，但也有部分缺点，比如：监控环比只有分钟级，缺少更细的维度，界面不太友好。

skywalking是需要深度开发和改造，才能很好的应用于企业级监控需求的，它的UI操作部分，有些会显得很迷。

jaeger是个很好用的轻量级链路追踪工具，使用手感不错，建议尝试。

arthas是阿里开源的java问题定位和分析工具，谁用谁知道有多爽。

最后，综合来说，每个公司在不同阶段，对监控的需求和痛点是不一样的，技术栈的选型又受限于做监控的团队本身的一些因素。灵活使用工具，提高效率解决问题，才是技术人最该关注的。