一、监控系统需要完成的功能为：

全栈监控；

关联分析；

跨系统调用的串联；

实时报警和自动处置；

系统性能分析。

多层体系的监控

二、全栈监控（就是三层监控）

基础层：CPU、内存、网络吞吐、硬盘 I/O、硬盘使用等。

中间层：Nginx、Redis、ActiveMQ、Kafka、MySQL、Tomcat等。

应用层：HTTP 访问的吞吐量、响应时间、返回码，调用链路分析，性能瓶颈，还包括用户端的监控。

监控的标准化：

(1)日志数据结构化；

(2)监控数据格式标准化；

(3)统一的监控平台；

(4)统一的日志分析。

三、什么才是好的监控系统

1.监控做不好，它们主要有两个很大的问题。

监控数据是隔离。因为公司分工的问题，开发、应用运维、系统运维，各管各的，所以很多公司的监控系统也是各是各的，完全串不起来。

监控的数据项太多。信息太多等于没有信息

2.好的监控系统应该有以下几个特征：

（1）关注于整体应用的 SLA（Service-Level Agreement服务等级协议）。主要从为用户服务的 API 来监控整个系统。

（2）关联指标聚合。 把有关联的系统及其指标聚合展示。主要是三层系统数据：基础层、平台中间件层和应用层。其中，最重要的是把服务和相关的中间件以及主机关联在一起，服务有可能运行在Docker 中，也有可能运行在微服务平台上的多个 JVM 中，也有可能运行在 Tomcat 中。无论运行在哪里,都要把服务的具体实例和主机关联在一起，否则定位问题犹如大海捞针。

（3）快速故障定位。 做用户请求跟踪的 trace 监控，监控到所有的请求在分布式系统中的调用链，做成没有侵入性的。

3.好的监控系统主要是为以下两个场景所设计的

“体检”

容量管理。 提供一个全局的系统运行时数据的展示，可以让工程师团队知道是否需要增加机器或者其它资源。

性能管理。可以通过查看大盘，找到系统瓶颈，并有针对性地优化系统和相应代码。

“急诊”

定位问题。可以快速地暴露并找到问题的发生点，帮助技术人员诊断问题。

性能分析。当出现非预期的流量提升时，可以快速地找到系统的瓶颈，并可以帮助开发人员深入代码。

四、如何做出一个好的监控系统

1.服务调用链跟踪

监控系统从对外的 API 开始，将后台的实际服务关联起来，服务的依赖服务给关联起来，直到最后一个服务（如 MySQL 或 Redis），整个系统服务全部串连。

对于 Java 类的服务，使用字节码技术进行字节码注入，做无侵入式。

如下图所示（截图来自我做的一个 APM 的监控系统）。

2.服务调用时长分布

下图是 Zipkin 的服务调用时间分布。可以看到一个服务调用链上的时间分布，知道最耗时的服务是什么。

3.服务的 TOP N 视图

三种排名的方法：a）按调用量排名，b) 按请求最耗时排名，c）按热点排名（一个时间段内的请求次数的响应时间和）。

4.数据库操作关联

对于 Java 应用，我们可以很方便地通过 JavaAgent 字节码注入技术拿到JDBC 执行数据库操作的执行时间和相关的请求对应起来。

5.服务资源跟踪。

我们的服务可能运行在物理机/虚拟机里/Docker 的容器里(运行在物理机或是虚拟机上)。我们需要把服务运行的机器节点上的数据（如 CPU、MEM、I/O、DISK、NETWORK）关联起来。到如下的目标。

    当一台机器挂掉是因为 CPU 或 I/O 过高、SQL 操作过慢、消息队列拥塞的时候，我们马上可以知道其会影响到哪些对外服务API。

    当一个服务响应过慢的时候，我们马上能关联出来是否在做 Java GC，或是其所在的计算结点上是否有资源不足的情况，或是依赖的服务是否出现了问题。

一旦发现某个服务过慢是因为 CPU 使用过多，我们就可以做弹性伸缩。

一旦发现某个服务过慢是因为 MySQL 出现了一个慢查询，做流量限制或降级操作了。

所以，一个分布式系统，或是一个自动化运维系统，或是一个 Cloud Native 的云化系统，最重要的事就是把监控系统做好。在把数据收集好、关联好。这样，我们才可能很快地定位故障，进而才能进行自动化调度。

上图只是简单地展示了一个分布式系统的服务调用链接上都在报错，其根本原因是数据库链接过多，服务不过来。另外一个原因是，Java 在做 Full GC 导致处理过慢。于是，消息队列出现消息堆积堵塞。这个图只是一个示例，其形象地体现了在分布式系统中监控数据关联的重要性。