1.概述/Overview

近几年，全链路监控系统已经成为了各大互联网公司的“标配”系统。开启全链路监控，不仅可以使我们全面了解系统拓扑结构，掌握系统实时吞吐量、响应时间等关键指标数据，还能在出现问题时，帮忙我们快速定位故障点，提高分析效率。

为了实现全链路监控，我们从请求的入口处（通常是客户端），生成唯一标识traceId，然后在涉及资源调用的地方，记录资源id、耗费时间等信息（如果涉及跨多个系统，还可以透传traceId，实现多个系统间串联），最后以traceId为标识，将整个调用链串起来。通过调用链，我们可以直观的看到整个请求的资源拓扑结构，以及各个节点花费的时间。

使用SpringCloud构建的微服务之间的链路监控，现有方案大多只做到了服务层级的跟踪，而我们在此实现的“全链路”监控，不仅实现了不同服务间的调用跟踪，还实现了当前系统内涉及的所有外部资源，例如redis、memcache、数据库等资源的监控。这些都是我们自己一步一步摸索出来的，在业界也是走在前列。

本系列文章，主要介绍下如何从0到1，一步步构建属于我们自己的全链路监控系统，以及在构建过程中遇到的问题及解决方法。

为了更好的理解相关内容，先从整体上介绍下系统核心功能，然后再把系统的中涉及的关键技术及数据流转过程给大家梳理下。

2.1系统功能

资源拓扑图

如下图，我们可以直接在系统资源拓扑图上，看到本系统依赖哪些资源，例如redis、数据库、其他系统等；同时可以看到每分钟各个资源的平均响应时间和QPS。

百分位图

当点击资源拓扑图中的资源时，例如点击redis，就可以看到redis资源响应时间的百分位图。

资源QPS/平均响应时间变化趋势

当点击资源拓扑图中的资源时，还可以看到对应资源的QPS/平均响应时间变化趋势。

实时监控报警功能

监控系统最重要的就是报警功能，我们通过使用storm流式计算框架，完成了实时数据的收集、分析、聚合、异常检测、报警收敛、报警等功能。

当检测到异常情况，例如接口响应变慢，我们会通过短信、邮件或IM工具，及时通知相关同事。所有接口请求都包含traceid，同样在报警中，也添加了traceid信息，便于我们更快定位报警接口及具体的请求。

监控看板-快速查询问题

我们可以通过报警信息查询页面，查询最近报警信息，例如下图：

也可以通过报警信息中的traceid，快速查询对应请求。例如下图中，通过调用链，我们直接定位到该接口慢的原因，在数据库查询。

监控看板-错误堆栈查询

系统error级别的错误，之前我们收到报警后，一般都是登录服务器，查询对应的错误日志，然后通过上下文或其他日志，一步步找到对应的具体请求，排查问题。

在接入全链路监控后，通过使用traceid串联，我们可以直接在错误日志监控中，查询到具体的请求，效果如上节内容：

同时也可以直接查看对应的堆栈信息：

监控看板-Nginx监控

除了对服务本身（例如tomcat）进行监控，我们将nginx日志也纳入到监控范围，这样在tomcat本身宕机时，我们可以通过nginx日志中的返回码，第一时间检测到。

通过看板，我们看到nginx各个状态码（、、等）的趋势图，也可以看到具体的错误原因：

URL实时监控排行

通过与历史数据对比，实时展示各个接口的平均响应时间和QPS变化。

下钻功能

对于很多数据，我们还提供数据下钻功能，例如当发现某个资源的访问量很多，我们可以通过资源下钻，看看哪些接口会造成这些影响：

如下图，从次数上，我们可以看到第一个接口，贡献了一半的访问次数。

上面以图文的形式，对系统的核心功能做了简单介绍。

2.2系统功能

说完系统功能，再梳理下系统中涉及的关键技术及数据流转过程，我们先看下面结构图：

（1）首先在业务系统中，使用javaAgent技术，对系统中涉及的资源调用方法进行增强。使用javaAgent技术，是为了使各个业务系统在引入全链路监控时，无需修改代码，实现“无侵入埋点”；（2）我们将相关信息记录到日志中后，可以通过logstash统一收集，采集，将相关日志写入kafka；（3）kafka中的数据，一部分会进入由storm搭建的流式计算集群，进行分析和异常检测，对于异常数据，在做报警收敛后，会通知相关负责同事；（4）此外采集到kafka中的数据，会全部持久化到ES中，供后续分析和看板展示；（5）可视化看板中，包括了实时资源拓扑、各个资源的实时QPS、响应时间、系统健康度、错误日志看板、全链路查询等多个看板项和功能。

上面对系统做了整体介绍，接下来我们将从多个角度，和大家一起，从0到1构建整个系统，预计包括如下章节：

（1）javaAgent篇

javaAgent技术初探

使用MDC无法获取数据，从而重新认识ClassLoader机制

如何对数据库、redis、memcache、