Kubernetes微服务监控体系

监控系统是运维体系乃至整个软件产品生命周期中最重要的一环，完善的监控可以帮助我们事前及时发现故障，事后快速追查定位问题。而在以微服务为代表的云原生架构体系中，系统分为多个层次，服务之间调用链路复杂，系统中需要监控的目标非常多，如果没有一个完善的监控系统就难以保证整体服务的持续稳定。

监控对象及分层

在实际场景中监控系统按照监控的对象及系统层次结构，从底向上可以依次划分为基础层、中间层、应用层、业务层等多个层面的监控。具体可如图所示：

基础层监控就是对主机服务器(包括宿主机、容器)及其底层资源进行监控，以保证应用程序运行所依赖的基础环境的稳定运行。基础层监控主要有两个方向：

• 资源利用：是对像I/O利用率、CPU利用率、内存使用率、磁盘使用率、网络负载等这样的硬件资源进行监控。避免因应用程序本身或其它特殊情况引起的硬件资源耗尽而出现的服务故障。

• 网络通信：是对服务器之间的网络状态进行监控。网络通信是互联网的重要基石，如果主机之间的网络出现如延迟过大、丢包率高这样的网络问题，将会严重影响业务。

需要说明的是，在基于Kubernetes容器化技术的新型云原生基础设施中，基础层的监控不仅要对宿主机本身进行监控，也要对Kubernetes集群状态及其容器资源使用情况进行监控。这在后面我们构建基于Kubernetes的基础层监控体系时将会具体介绍。

 

中间层监控主要是指对诸如Nginx、Redis、MySQL、RocketMQ、Kafka等应用服务所依赖的中间件软件的监控，它们的稳定也是保证应用程序持续可用的关键。一般来说特定的中间件软件都会根据自身特点构建针对性的监控体系。

 

应用层监控这里就是指对业务性服务程序的监控，一般来说我们对应用程序监控的关注点主要体现在以下几个方面：

• HTTP接口请求访问。包括接口响应时间、吞吐量等；

• JVM监控指标。对于Java服务，还会重点关注GC时间、线程数、FGC/YGC耗时等JVM性能相关的指标；

• 资源消耗。应用程序部署后会消耗一定的资源，例如应用程序对内存、CPU的消耗情况；

• 服务的健康状态。例如当前服务是否存活，运行是否稳定等；

• 调用链路。在微服务架构中，由于调用链路变长，还需要重点监控服务之间的调用关系和调用情况，避免局部上下游服务之间的链路故障引发系统全局性雪崩；

 

业务层监控也是监控系统所关注的一个重要内容，在实际场景中如果你只是让应用程序稳定运行那肯定是远远不够的。因此，我们常常会对具体业务产生的数据进行监控，例如网站系统所关注的PV、UV等参数；后端如交易之类的系统我们则会关注订单量、成功率等。

业务指标也是体现系统稳定性的核心要素。任何系统，如果出现了问题，最先受到影响的肯定是业务指标。对于核心业务指标的设定因具体的业务和场景而异，所以对于业务层的监控需要构建具备业务特点的业务监控系统。

常见的监控指标类型

在指标类监控系统中，通过统计指标可以感性地认识到整个系统的运行情况。出现问题后，各个指标会首先出现波动，这些波动会反映出系统是那些方面出了问题，从而可以据此排查出现问题的原因。下面我们分别来看下统计指标到底有哪些类型，以及常见的统计指标都有哪些，它是我们进一步理解指标类监控系统的基础。

从整体上看，常见的Metrics指标类型主要有：计数器（Counter）、测量仪（Gauge）、直方图（Histogram）、摘要（Summary）这四类。它们的特点分别如下：

1. 计数器（Counter）

计数器是一种具有累加特性的指标类型，一般这个值为Double或者Long类型。例如常见的统计指标QPS、TPS等的值就是通过计数器的形式，然后配合一些统计函数计算得出的。

 

2. 测量仪（Gauge）

表示某个时间点，对某个数值的测量。测量仪和计数器都可以用来查询某个时间点的固定内容的数值，但和计数器不同，测量仪的值可以随意变化，可以增加也可以减少。比如获取Java线程池中活跃的线程数，使用的是ThreadPoolExecutor中的getActiveCount方法;此外，还有比较常见的CPU使用率、内存占用量等具体指标都是通过测量仪获取的。

 

3. 直方图（Histogram）

直方图是一种将多个数值聚合在一起的数据结构，可以表示数据的分布情况。比如以常见的响应耗时举例，可以把响应耗时数据分为多个桶（Bucket）,每个桶代表一个耗时区间，例如0～100毫秒、100～500毫秒，以此类推。通过这样的形式，可以直观地看到一个时间段内的请求耗时分布࿰