日志VS网络数据，谁能做好全链路监控？

2021-07-07 15:36:44

对系统的运行状态进行监控，是IT工程师的一项重要工作。

如果不能确保整个系统及其链路处于稳定运行的状态，那么，企业的业务稳定发展就无从谈起。

21世纪以来，随着云计算的兴起，系统架构发生了显著的变化。分布式崛起，开始取代单体式，成为行业的主流选择。微服务概念的提出，容器等云原生技术的发展，加剧了这一变化。

系统架构变化之后，对系统进行监控的需求也随之变化，监控难度大幅增加。

目前，对系统进行全链路监控，根据数据源、监控路径、落地方式等不同，存在多种监控方式。市场上主流的监控派别，是日志类和网络数据类。

接下来，我们通过对比的方式，看看这两种技术派别的主要差异。

▉ 数据源对比

日志类的数据来源有两类：

一种是传统物理设备上的日志文件，这种日志文件能够提供的数据格式、数据精细度、数据内容，都是各个设备厂商预先设定的。

另外一种，是程序开发过程中或开发完成后，为捕获程序或者系统本身的运行信息，开发出来的日志系统。

日志系统本身不对应用程序发起主动式访问，只是伴随着程序的运行，将相关的运行数据（机器本身或者程序运行的状态信息）输送出来。

此外，日志属于采样数据，信息级别与功能均由人工定义，在存储以及分析的过程中，时常因前端需求而更改，按照人为需求进行目标输出，因此边界十分明显。

再来看看网络数据。

网络数据是应用程序之间通过网络进行传输的独特过程数据。它能够提供业务活动、应用性能、安全性与IT基础架构等方面的信息。

获取网络数据的方式比较简单，通过交换机镜像的方式，就可以将网络数据复制出来。

网络数据获取之后，送至分析服务器，即可实现性能监控。

网络数据是一种全量数据，通过旁路捕获数据包，不消耗任何系统资源，可以实时反映设备、服务器、系统等运行的状态。

日志时间由系统程序自动打印，一般到毫秒。

网络数据的时间戳，由捕获服务器的高性能网卡抓包时进行标记，快可以实现纳秒级。

尽管两者同样采用ntp时间同步，但两者之间的时间准确程度也会因网络传输等因素产生毫秒级以上的差距。

在网络传输过程中，由于Delayed ACK与Nagle算法的相互作用，会导致大500毫秒的延迟。日志往往无法排查此类问题，而通过网络数据可以进行数据包回溯分析。因此，网络数据比日志具备更高的实时性。

▉ 监控路径对比

作为两种数据源，日志与网络数据所监控的定义与范围有着天然的差别。

分布式追踪领域有三个重要的概念：Metrics、Trace、Log：

（Metrics、Tracing、Logging三者间的关系示意图）

全链路监控，就是利用上述三者之间的关系，分步骤实现的。

一般来说，进行全链路监控有两种做法：

种做法：首先通过指标（Metrics），查看组件的健康程度、受影响的交易类型；再通过指标关联，查看整个交易路径的健康度（Trace）；后，定位具体的问题节点（Log），找出根因。
第二种做法：当交易出现问题，首先查看出错的具体路径（Trace），再查看相对应的指标（Metrics），如服务器或应用性能指标等，后查看详细日志数据（Log）。

网络数据，通常反映的是指标。然而，无论是指标还是日志，都必须经过数据加工处理，才能进入全链路追踪体系。

Metrics辅助于应用监控，倾向于节省资源，会对数据进行天然的“压缩”。而Log倾向于无限增加，会频繁地超出预期容量。

无论是日志类还是网络数据类监控，都可以采用以上两种做法。只不过介于数据源的因素，网络数据类监控具有天然可操作性，而日志类监控却经过了一个漫长的发展期，并衍生出许多新的问题。

▉ 落地方式对比

全链路监控的需求，并不是一开始就有的。受制于网络技术与业务发展等诸多因素，不同阶段对全链路监控的标准和需求也有着明显的差异。

网络发展初期，业务规模小，企业通常采用标准作业程序（SOP）。

此时，由于系统多为单体架构，操作简单、易部署，为节省资源、缩短时间成本，除核心系统外，没有监控其它系统的需求。因此，系统版本迭代较慢，不易扩展，全链路监控也就无从谈起。

到了2010年左右，互联网发展进入飞跃期。随着业务量逐渐增多，业务分支越来越细，垂直架构逐渐兴起。

然而，这一时期，系统与系统之间存在数据冗余，且同一个子系统中的业务无法实现关联。尽管全链路监控的需求与日俱增，如何实现却成为一道现实难题。

在追求全链路监控的过程中，由于缺乏统一的标准，对现有系统进行改造成为当时较为普遍的解决方案。

然而，改造系统同样面临两个严峻问题：