浅谈互联网系统监控体系
一、前言
监控，是所有系统必不可少的组成部分，完善的监控体系能让我们及时发现业务系统的相关问题，同时，也能为业务系统的优化方向提供指引。然而，对绝大多数业务系统来说，一开始关注的重点基本都是在实现业务功能需求方面，相应的监控体系的搭建往往都比较靠后才考虑，在实际工作当中，这也是可以理解的事情。
正如业务系统是一步一步迭代完善而来，对应的监控系统也是随着业务系统的逐步完善而逐步演进的，最终的理想状况，当然是构建一个完善的立体监控体系，能够实现对业务系统全方位的监控预警。目前，业界已有各种组件用于支撑搭建监控系统，也不乏成熟的整体解决方案，如 ELK 日志体系、Telegraf 体系等。而本文要说的，重点则是随着业务系统的逐步演进，相应的监控系统演进过程。
实际业务情况是灵活多变的，绝不可生搬硬套，笔者以为，没有最好的监控体系，只有最适合的监控体系。笔者浅陋，难免有错漏不当之处，欢迎批评指正、沟通交流。（本文所述主要基于 Java 生态体系）
二、监控系统的一些基础知识
2.1、监控系统的组成架构
监控系统，不论架构简单还是复杂，在某种意义上来说，基本都包含 3 大核心组成板块，分别是：数据采集、数据存储、数据查询/展示。面对业务系统不同的发展阶段，不同的业务场景，不同维度的监控需求等等，其具体的实现方式自然也会有所不同。
数据采集，指对监控指标项的原始监控数据的采集。常见的采集方式有服务本身暴露监控指标接口、第三方组件采集业务日志、手动埋点上报数据等等。
数据存储，指对采集到的数据进行存储/清洗。有时需要对原始数据进行聚合后再存储，有时则是存储后再清洗聚合，如微服务某一个 http 接口的访问量、平均耗时等，可能就需要对该接口所有的机器节点上的数据进行聚合后存储。而存储的方式，可以是内存、日志文件、存储组件服务等。总之，存储是为了后续查询/展示服务的，且由于监控数据量一般都较大，存储的结构设计、保留时长策略就比较重要了。同时，存储的监控数据也为告警服务的告警规则匹配提供支持。
数据查询/展示，对存储的监控数据进行查询/展示，支持条件查询语句的查询入口/接口，或是友好可视化的监控面板。可以方便地查询、分析监控数据，有利于及时找出/发现线上服务的问题；一个“好用”的展示面板对监控系统来说，是非常重要的，毕竟，监控是要给人看的。
2.2、监控的范围指标
我们到底要监控哪些方面的指标呢？从服务器 CPU/内存使用率、网络 IO 情况到应用存活状态、GC 情况等，可以说非常的庞杂，而目前业界可选的各种监控组件/方案也非常的丰富，不论是各种开源方案，还是直接基于云 SAAS 服务的方案，选择项还是比较多的。但在选择具体方案之前，我们首先需要理清楚，系统在当前阶段，最需要实现的，是哪些监控指标，需要监控到哪种程度。
总的来说，需要监控的指标大致可分为以下 4 个方面：
1、服务机基础指标。主要包括服务器 CPU 使用率、内存使用率、磁盘使用率、网络/磁盘 IO、系统整体负载等服务器基础指标。如果是基于容器部署的，则还有容器 Pod 数量、Pod 状态，k8s 集群状态等基础指标。
2、中间件服务指标。主要指系统使用的一些中间件服务的监控指标，如 Redis 的 CPU/内存使用率、缓存命中率等，Mysql 的 QPS、磁盘 IO、主从延迟等，MQ 的 TPS、消息堆积情况等。
3、应用服务指标。主要包括存活状态、QPS/TPS、RT、JVM 基本情况、GC 情况、线程情况等指标。
4、业务指标。指实际业务场景中的一些监控指标，如 UV/PV、订单数、交易金额、成功支付率等。（这些业务指标，通常是强业务绑定的，通常需要手动埋点的方式以支持更精确的数据监控）
一个立体监控体系，需要监控的维度、粒度是非常庞杂的，逐步完善需要付出的人力、时间等也并不少。我们不必一开始就直接搭建起整套立体监控体系，而应该根据实际的业务系统需要去逐步完善，毕竟，监控系统本身是辅助/支持业务系统的稳定运行的，把业务系统完善的优先级更高一些。
2.3、监控数据采集的推/拉模式
监控数据的采集是搭建监控系统最源头的工作，而采集的方式一般来说有两种类型，分别是 Push（推）模式、Pull（拉）模式，这两种模式的推/拉，主要指的是监控系统、被监控对象之间在监控数据获取上的主动/被动区别。Push 模式指的是被监控对象主动将监控指标数据 Push（推送）到监控系统中，Pull 模式指的是监控系统主动 Pull（拉取）被监控对象的监控数据（被监控对象需支持被远端访问）。
不难看出，由于采集监控数据的主动发起者不一样，Push/Pull 模式的系统负载压力方也会不一样，目前开源方案中，Push 方式的代表方案有 TICK（Telegraf, InfluxDB, Chronograf, Kapacitor）、ELK（Elasticsearch、Logstash、Kibana），Pull 方式的代表有 Prometheus、Grafana 系列。总的来说，Push 模式/Pull 模式在部署、运维成本、业务耦合程度等细节方面还是有一些差异，实际落地时，需结合本身的实际业务情况、团队技术栈等综合考虑（一般是混合用）。
2.4、搭建监控系统注意事项
监控系统本身是服务于业务系统的，但又相对独立于业务系统。监控系统本身需监控的原始数据均来源于业务系统，所以说基本不可能完全独立于业务系统存在而存在，说完全对业务系统没影响，基本是不可能的，但是我们应当尽量降低这些影响，包括性能影响、稳定性影响等。笔者以为，在搭建监控系统时，应当注意以下这些事项：
1、部署要独立于业务系统。包括从域名、接入层 NG 服务、到后续存储服务等，都应当尽量从架构设计、到服务器部署都应当完全隔离，这样的话，当业务系统出现问题的时候，监控系统还能用，还能帮助定位业务系统到底是哪个环节出了问题。（笔者曾经所在团队就遇到过，由于监控系统面板的入口和业务系统的入口是同一 Nginx 集群，结果 Nginx 出问题的时候，监控系统面板也看不了了。）
2、监控粒度要控制好。既要避免没有监控，又要避免什么都监控，否则就是感觉什么都监控到了，但出问题的时候又不能快速地定位并解决问题。而应该聚焦最核心、最关键的系统节点，重点关注重要的且容易出问题的节点。然后，对于系统中不同的问题方向，应当做好分类/分组，以方便日常巡检，以及出现问题时快速定位问题。
3、权限要控制好。一是避免误操作，二是监控系统通常能看到/检索到很多公司业务运营数据、用户数据等敏感信息，这些信息可能并不能随意开放，所以要控制好访问权限。
4、应当反哺业务。不要监控系统搭建完成后就不管了，而应当依据监控系统，巡查/发掘系统的短板、风险点，从而为业务系统的完善、优化提供指引方向，促进业务系统的不断完善。
5、一步一步来。没有最完美的，只有最合适的，要在业务系统迭代、监控系统建设之间取一个平衡。不要觉得简单的监控系统就很挫，看起来高大上的监控系统就很厉害，重点应该在于能解决实际问题。
三、架构演进过程中的监控系统搭建
正如业务系统架构是逐步演进而来的（也谈互联网系统架构演进），对应阶段的监控系统也是伴随着一步步演进的，因为在业务系统不同发展阶段中团队资源、工作侧重点等方面有所不同，搭建监控系统时也应该根据实际情况来选择 。大致来说，相应阶段的可选方案如下：
3.1、单体应用/简单集群阶段初期。
这一阶段的主要矛盾在于业务系统功能实现上，团队可能没有什么资源投入到监控系统搭建中，可使用 SpringBoot Admin 来快速搭建，解决“从无到有”的问题。SpringBoot Admin 最主要的特点就是使用简单、能快速接入，在业务系统本身就是 SpringBoot 应用的情况下，基本上几个小时就能够快速搭建起一套可用的监控系统。SpringBoot Admin 官方 2.7.10 版本接入文档地址是 https://docs.spring-boot-admin.com/2.7.10（其它版本改版本号即可）。
从官方文档可知，SpringBoot Admin 的接入还是比较简单的，基本上就是启动一个 Server 端的 SpringBoot 项目，然后在原业务项目中添加几行 Client 端的配置，自动注册到 Server 端就可以了。
SpringBoot Admin 简洁而不简单，UI 面板还是比较丰富的，基本可以实现监控应用服务存活状态、依赖的 DB、Redis 等组件的存活状态，以及查看服务器信息、应用线程情况、JVM 内存、GC 情况等信息，通过实现InfoContributor接口则可以实现自定义监控指标；安全方面，通过简单Security配置就可实现访问权限保护。另外，通过简单配置，还支持邮件、钉钉等方式告警，通过继承AbstractStatusChangeNotifier类，则可实现手机短信等其它方式的告警。
此时，监控系统架构大致如下图所示：
3.2、复杂集群/微服务初级阶段。
这一阶段，整个业务系统逐渐复杂起来，随着业务体量的增长，出现各种线上问题的概率也增加了，此时就需要一个更加详细的监控系统，来帮助我们及时发现问题并解决问题，而 Promethues + Grafana + Micrometer 的方案来监控业务系统的相关服务指标是个不错的选择。（SpringBoot Admin 的监控还是有所不足，比方说监控面板不够清晰、中间件指标过于简陋、自定义指标编写代码繁琐，监控数据没有持久化不支持历史监控指标查询等。）
这应该算是一套强大、成熟、简洁而高效的监控组合了。
Promethues支持强大的数据 Pull 采集能力以及存储能力，在容器化日渐普及的今天尤其适用（支持监控对象对象自动发现），其有现成的大量exporter可供直接使用，基本覆盖了绝大多数中间件的监控数据采集。（Promethues本身是支持 Pull 模式，如果需要主动 Push 数据的话，则可以通过pushgateway的方式来实现。另外，Promethues还有alertmanager组件支持告警配置。【部署】）
Grafana 拥有丰富而漂亮的的监控面板，支持包含 Promthues 在内的众多数据源的数据图表展示，也有大量现成的Dashboard可直接使用，几乎已经成为了各监控体系展示面板的标配组件了。（部署）
Micrometer 支持多种度量类型的度量器，可以满足各种类型监控指标的应用数据采集；通过继承MeterRegistry类，可以非常方便地将自定义指标添加进去。（集成Promethues使用）
如果是 SpringBoot 项目的话，利用这几个监控组件，然后再在项目中添加以下关键pom依赖，就可以方便地搭建起相对完善的服务监控体系。
此时，监控系统架构大致如下图所示：
3.3、大规模复杂微服务阶段。
随着业务场景的不断增加，服务调用链路越发复杂，仅仅只有Promethues + Grafana + Micrometer 的监控体系，已越发不能满足对系统更细粒度的监控诉求，且监控到问题时，也不能更好的快速定位业务问题。此时，就需要ELK（Elasticsearch、Logstash、Kibana）体系，全链路追踪skywalking等来进一步完善监控体系了，同时，一般还需要引入实时流聚合计算、手动业务埋点等工具/手段来提供支撑。
ELK体系提供了非常丰富的整体监控解决方案，其中包括日志监控。
skywalking算是微服务链路追踪服务的标杆了，可以实现对微服务全链路的追踪监控，新版的监控面板非常丰富。（演示）
不论是ELK体系还是skywalking体系都是非常强大而复杂的解决方案，支持基本的监控只是其中一小部分功能；当然，其对资源投入，对团队成员技能要求都是相对比较高的，这时一般需要一个小团队去专门负责了。
四、其它
1、监控体系通常和告警体系紧密关联，一起组合使用，为了更清晰地聚焦问题，本文的主要是讲述监控体系的相关问题，告警体系则没有详述。
2、目前监控系统相关的开源组件/方案众多，在实际落地时，一般都会选择相对成熟的组件/方案，要结合实际场景与需要，平衡取舍，尽量不要过度设计太复杂的监控架构，在解决实际问题的前提下，监控链路也应当尽量简洁。
3、一个完善的立体监控体系，涉及到的应用系统、基础组件、技术团队等是非常多的，实际落地时面临的各方面问题也是非常繁杂的，笔者此文只是简述而已，真正落地时，组件的部署配置，团队的技能培养，团队之间的沟通协调等，都需要投入足够的资源与耐心。
越学越无知，我是老农小江，欢迎交流~
版权声明: 本文为 InfoQ 作者【老农小江】的原创文章。
原文链接:【http://xie.infoq.cn/article/0f59ecadd9f0c62f83ec1f7eb】。
本文遵守【CC-BY 4.0】协议，转载请保留原文出处及本版权声明。
好好学习，天天向上 2020-03-26 加入
越学越无知，一个普通老码农，欢迎交流~
评论