从全链路监控到全链路分析

上周五的时候，虽然感觉深圳的疫情有点严重，还是忍不住回了趟家，没想到周日下午发布了深圳加强管控的通知，福田区出现了一个高风险区。国内其他城市也纷纷出台了管控措施，于是我就被困在深圳了。希望一周时间内能够让工作生活回归正常。被封闭在家里也有好处，少了往返公司路途上浪费的时间，早上吃过早饭就能坐在电脑前静静地思考。

今天我们来聊一下全链路监控的事情。2019年我们帮一个客户建设了一套信息系统全链路监控系统，针对整个系统的拓扑进行监控，从而及时发现系统中的风险。不过那套系统最后的运行效果并不理想，一方面是因为针对每套信息系统，因为拓扑结构，IT基础设施的差异，都需要进行定制化的开发或者配置，用户没有费用把上百套系统都纳入监管，仅仅实现了一套系统的全链路展示与监控。

本系统没有全面推广的第二个原因是基础数据不够全面，全链路监控系统中的很多IT组件的数据较为简单，仅仅能够用于状态展示，真的如果哪个IT基础设施出问题了，没办法较为深入的下钻分析，这就让全链路监控系统成了要给摆设。如果真的信息系统出问题了，以目前的监控手段，要想知道哪个基础设施有问题，并不是件很难的事情，而定位问题到底出在哪才是客户想解决的难题。

实际上全链路监控系统在很多企业都有建设，而且都取得了一定的成效。这方面金融行业起步较早，利用NPM监控整个业务流程及相关IT基础设施的情况，通过综合日志分析发现全链路中各个环节中存在的问题。这些系统的建设都对IT系统的健康问题发现发挥了极大的作用。NPM能够很好的了解整个系统的拓扑与调用流程，而如果你想进一步了解应用中的各种调用关系，还可以通过在JVM中部署探针的APM工具去进一步的分析。

不过这些工具虽然构建起了全链路监控的整体框架，但是无法实现真正的全链路分析。如果我们发现某个IT基础设施出现问题了，使用NPM/APM或者全链路日志分析不一定能够定位问题的根因，而随着信息系统的发展和运维能力的提升，实际上单一IT基础设施的简单问题已经不是运维管理面临的棘手问题了。比较棘手的问题是当系统出现一些莫名其妙的问题的时候，我们缺乏深入分析与根因定位的能力，因此在全链路监控的基础上，我们还需要引入全链路分析的能力。

对某个IT基础设施的分析需要有专业的经验和数据，因此一般来说具有强大分析能力的运维工具往往都是基于某一个IT组件的，因为链路级的状态组合过于复杂，很难构建通用的分析模型。D-SMART作为一个智能化运维工具，其实也存在这样的缺陷，整个工具的最初设计都是为了针对某个运维对象-比如数据库进行深入的诊断和分析的，因此在跨运维对象的分析能力上存在较大的不足。

2020年的时候，一个客户的4A系统出现严重的性能问题，导致大量的系统都出现了问题。在做根因分析的时候，我们发现系统的IO性能很差，很可能是后端存储出现了问题。于是我们立即开发了一个关联性分析的工具，对这个客户的所有的Oracle数据库的某个指标（这个案例中是IO延时）做一个扫描，找出关联性很强的数据库对象来。这一扫描还真有大发现。

有好几套系统都存在类似的IO延时特征，其中另外一套核心系统的问题与本系统类似，只是那个时间段里，另外一套系统的IO负载较小，而且受到4A的影响，本身就存在一些问题。因此大家都没有发现这个关联关系。发现了这个问题后，再仔细核查，我们发现原来这两套数据库共用了一套存储系统。随后对该存储进行分析发现，在IO高峰期，这套存储的IO延时本身就是有问题的。

当时这个案例因为处于疫情期间，我们是采用远程离线分析的，定位IO问题是导致系统故障的原因，并找到引发IO问题的SQL语句，整个过程不到半个小时。最终定位在高IO负载下，后端存储的IO吞吐能力不足我们足足花了一天的时间。因为就单一数据库来说，IO负载不高，似乎不会引发后端存储的能力不足。而存储监控上看，IO负载没有达到瓶颈前一切都是正常的，所以存储管理人员总是说存储不存在问题。

从这个案例中我们已经看到了全链路分析能力建设对于提高问题定位效率的重要性了。实际上这些年里，我们也在不断地尝试打通IT基础设施的全链路分析这个瓶颈。因此作为一个从数据库工具出发的运维工具，D-SMART目前支持的IT组件已经不仅仅是数据库系统了。

网络交换机、应用中间件、存储系统这些非数据库对象也出现在了系统支持的对象列表里。

不过光有这些基础对象还不够，我们还需要构建一个全链路的监控视图，把相关的运维对象之间的关系构建出来。这些关系有些能够通过自动化发现的手段来发现，有些能够通过企业CMDB中的数据通过自动接口来获得。有些就只能够通过手工配置来构建他们之间的关系了。作为一个运维工具来说，其构建这张监控视图的方法必须是通用的，简单的。否则在用户现场应用时的成本太高，只能用于一些定制化建设的场景，而无法做成物美价廉的工具。

完成拓扑构建并不是全链路分析的终极目标，必须在这张拓扑上建设全链路分析能力。

这个全链路分析能力可以通过整个拓扑中的IT基础设施的运行状态，详细指标，发现其中存在的隐患，或者定位某类特殊的问题。这时候就又需要引入运维专家的经验了。运维专家必须梳理跨对象的链路级运维经验。然后实现对全链路拓扑的高级分析。

对于运维经验，我们可以先列出几条：
l如果某个存储上的IO吞吐量经常超过存储的总体IO能力，则存储可能会存在性能隐患；
l如果使用某个存储的多个数据库系统的IO延时存在问题，则存储可能存在IO性能问题；
l如果使用某个存储的读IO延时都很正常，写IO延时都不正常，则存储的复制链路可能存在问题；
l如果某个数据库的CURSOR争用比较严重，应用服务器的SQL调用数量出现暴增，则可能应用存在问题；
l……

最后我们来总结一下今天讨论的话题，全链路监控能力的构建让企业可以清晰的看到信息系统的整体健康情况，当系统故障的时候能够更快的找到出现问题的IT组件。而这种能力的建设对于现在日益复杂的IT来说，已经不足够了，我们需要进一步的深入下去，构建全链路诊断能力。利用运维专家的知识定义出大量的全链路影响的模型，是一条可行的道路。