1.2　监控架构分类

近年来，随着以Kubernetes为代表的云原生技术的崛起，软件的研发流程已经逐步进化到IaaS层、Kubernetes层、团队组织层。

Kubernetes是强大的声明式容器编排工具，可以提供计算、存储、网络等功能接口，通过这些接口以插件形式实现相关功能。这种灵活、开放的设计理念使Kubernetes非常容易集成外部工具，强化相应的功能。所以Kubernetes逐渐发展成中间件和微服务的“底座”，同时也成为企业上云的“底座”。如表1-1所示，Kubernetes和IaaS有着天然的联系，Kubernetes已经可以和诸如OpenStack、AWS、Google云等IaaS云平台进行集成^[1]，在弹性、敏捷、动态方面，它都可以发挥巨大作用。在IaaS层可以实现对硬件、网络等的监控；在Kubernetes层则可以实现对日志、健康检查、自愈系统、分布式链路等的监控，Kubernetes层作为中间件和微服务的“底座”，很多产品的监控都可以在这一层完成。

表1-1　Team/Org、Kubernetes、IaaS层次模型

在我的第一本书《HikariCP数据库连接池实战》的第10章中，介绍过3种应用于微服务架构的监控体系——Metrics、Tracing和Logging，这里补充第四种监控体系——HealthCheck。HealthCheck用于健康监控（这种监控方式在微服务Spring Boot中使用较多），如图1-3所示。

图1-3　微服务监控架构

一般来说，开源监控系统由集中式日志解决方案（以ELK^[2]为代表）和时序数据库解决方案构成。时序数据库解决方案以Graphite、TICK^[3]和Prometheus等为代表，其中前两个是推模式，后一个则以拉模式为主，拉模式对整体代码和架构的侵入较小。

当代新的监控三要素为Metrics、Logging和Tracing。

·Metrics的特点是可聚合（Aggregatable），它是根据时间发生的可以聚合的数据点。通俗地讲，Metrics是随着时间的推移产生的一些与监控相关的可聚合的重要指标（如与Counter计数器、Historgram等相关的指标）。

·Logging是一种离散日志（或称事件），分为有结构的日志和无结构的日志两种。

·Tracing是一种为请求域内的调用链提供的监控理念。

Prometheus同时覆盖了Logging和Metrics两个要素。

关于Metrics、Logging、Tracing的比较如图1-4所示，其中CapEx代表搭建的投入成本，OpEx代表运维成本，Reaction代表监控手段的响应能力，Investigation代表查问题的有效程度。一般来说，Metrics和HealthCheck对于监控告警非常有帮助，Metrics、Tracing和Logging对于调试、发现问题非常有帮助。

Prometheus是基于Metrics的监控系统，具有投入成本（CapEx）中等、运维成本（OpEx）低、响应能力（Reaction）高等特点。图1-4中查问题的有效程度（Investigation）较低，是相对于logging和Tracing等模式而言的。一般在业务开发中，通过查日志的方式就能定位到系统存在问题，通过Tracing模式可以查到链路上出现问题的环节。但是这并不代表Metrics监控的有效程度是最低的，合理的监控埋点、完美的监控大盘配置、超前的监控告警往往能让开发者在业务方发现问题之前就已经发现问题。

图1-4　当代监控方案在4个维度上的对比

微服务的监控反馈环节是非常重要的。姑且不提那些让人眼花缭乱的监控软件，单从宏观上来说，云原生、微服务场景下的监控该如何按类别使用呢？如图1-5所示，成熟的分布式软件系统在使用过程中可以分为监控告警、问题排查和稳定性保障这3个部分。

图1-5　监控分类的使用通用顺序

进行监控告警时，HealthCheck^[4]是运维团队监测应用系统是否存活、是否健康的最后一道防线，这是必须引起重视的一道防线。HealthCheck在微服务中通过对一个特定的HTTP请求进行轮询实现监控。通过对这个请求进行轮询，不但可以得到微服务的监控状态，还可以得到相关中间件如MQ、Redis、MySQL、配置中心等的健康状态。当然，开发人员最为关心的监控还是自身定制的Metrics监控，所以监控告警的优先级依然是Metrics监控最高，HealthCheck最低。

进行问题排查时，在监控系统不那么先进的年代，研发人员往往是通过查日志解决问题的。但是如果需要查询分布式集群上几十台到几百台机器的日志，不借助一些日志软件，而是使用命令行集中查询，那将是一件非常麻烦的事情。而在当下这个云原生和微服务架构盛行的时代，监控系统百花齐放，往往会基于Metrics的监控大盘进行查询从而定位问题。比如Prometheus就支持非常强大的Metrics查询——PromQL语句查询。Metrics查询是基于时间序列的数据库设计得到的，其可以直接定位到过去的任意时间点，可以对系统层、中间件层、应用层、业务层乃至端上的所有监控指标进行查询。如果Metrics无法定位问题或者需要更多信息，Tracing监控手段可以提供协助，帮助定位该问题发生在微服务链路的哪个环节（比如是物流服务、订单服务还是支付服务）。最后，可以再根据日志找到最根本的问题。通过Metrics→Tracing→Logging的顺序分析问题，比直接去查日志更高效，很多问题都可以在日志之前的环节直接被定位并解决。

在流量洪峰到来之前，比如“双十一”大促，研发团队往往要进行技术演练以保障系统的稳定性（性能、多机房、高可用），此时会使用Chaos混沌工程以建立抵御生产环境中失控条件的能力及信心，还会使用Tracing进行全链路压测，尤其是针对复杂业务场景和海量数据冲击，要保障整个业务系统链的可用性和稳定性。

[1] Volume能和OpenStack的Cinder以及AWS的EBS集成，Pod网络能和云平台的VPC网络集成，Kubernetes Service和Ingress分别适合与IaaS云平台的四层防火墙、七层防火墙集成。

[2] ELK，即Elasticsearch、Logstash（性能高于Beas）、Kibana。

[3] TICK是influxData开发的开源高性能时序中台，集成了采集、存储、分析、可视化等能力，由Telegraf、InfluxDB、Chronograf、Kapacitor这4个组件以一种灵活松散但紧密配合、互为补充的方式构成。TICK专注于DevOps监控、IoT监控、实时分析等场景。

[4] 这类似于Java进程检测，如果Java进程挂掉了，就会直接被“看门狗”程序拉起。