cat全链路监控_谛听全链路监控平台实践与思考

一、项目背景

近几年，信也科技的研发技术伴随着业务的快速增长逐步演化为微服务化的分布式体系架构，但随之带来的系统间的上下游依赖关系的复杂度也呈指数级上升，已有的烟囱式的监控产品(CAT、ELK等)存在数据散落、指标覆盖度低的特点，用户定位、分析异常故障需要切换多个监控产品，并且经常需要上下游多人协作定位，定位问题的效率非常低下，甚至会出现找不到问题根源等难题，同时监控数据的价值也没有有效挖掘与使用。为了解决这些问题，谛听全链路监控平台应运而生。

二、产品介绍

谛听全链路监控平台通过自动化埋点、收集、存储、分析分布式系统中的指标数据、链路数据和日志数据，将流转在上下游站点间的信息串联起来，形成全链路跟踪，通过多维指标、链路与日志的关联分析与计算，提供统一告警、信息检索和展示等功能，极大的提升了定位故障的效率。目前线上已接入300多个应用，每日产生近百亿条数据，支撑公司多个重要项目(测试多环境、OneID、应用水位线、风险模型变量监控、AlarmBox等)的实施。

三、设计理念

监控系统本质是海量数据的采集、处理、分析、存储及展示，平台设计的难点在于我们不仅要知道“有没有问题”，还要知道“是什么原因”导致的问题，以及发现问题如何快速修复。目前我们主要对系统的运行状态(请求量、响应时间、异常数、出错率等)、事件状态(配置变更、发版、重启、告警等)及内部状态(健康状态、连接池情况、线程池情况、队列积压数、GC次数以及时长等)等数据进行多维度监测，从面到线再到点逐步排除过滤，进而发现故障根因，支撑开发快速排障，这是当初设计谛听监控高效排障的思路。

进一步，我们是否可以利用应用的实时运行的数据，通过检测算法和模型，提前发现问题避免故障的发生，这是我们后续努力尝试探索的一个方向。

举个典型的例子来说，用户收到一条应用响应慢的告警信息，大致的排障流程如下：

1. 收到告警信息后，首先查看应用概览页并结合拓扑关系图分析是自身问题(异常、慢查询等情况)还是外部服务(DB、缓存、三方服务等)依赖问题。

2. 查看事件中心分析是否是近期系统发版或者容器自动重启导致的系统异常，是否有其它告警事件发生。

3. 在应用监控指标页查看接口列表定位具体慢的接口，按时间区间查询链路日志，发现是慢SQL导致的问题。

4. 查看慢SQL对应的日志报文信息，发现是参数传递错误，导致接口变慢。

5. 查看接口上游，分析定位到调用方应用及接口与应用负责人沟通修复问题。

目前我们已在积极探索将一些标准化定位问题的流程通过自动化分析手段，将诊断结果附加到告警消息中(例如应用异常的堆栈摘要推送到异常类告警中)，帮助开发人员进一步提升定位问题的效率。

四、总体架构

信也根据内部现有的监控系统及基础设施并结合开源系统为基础，打通日志Logging、指标(时序)Metrics和链路Tracing数据，经过近1年的逐步演化实践形成以下架构：