大语言模型需要的可观测性数据的关联方式

可观测性数据的关联方式及其优缺点

随着现代分布式架构和微服务的普及，可观测性（Observability）已经成为确保系统健康、排查故障、优化性能的重要组成部分。有效的可观测性数据关联方式不仅能够帮助我们实时监控系统的运行状态，还能在故障发生时迅速定位问题根源。本文将探讨不同的可观测性数据关联方式，重点梳理什么样的关联方式才能更好的与大模型结合。

可观测性数据与大模型结合的矛盾点在于：

• 可观测性数据属于海量
• 大模型的上下文有限制无法直接分析海量的可观测性数据

什么是可观测性数据关联？

可观测性数据关联是指将系统中不同来源和维度的可观测性数据（如日志、指标、Trace）关联起来，形成一个完整的监控视图。通过这种关联，我们能够更全面地理解系统的行为和性能，尤其在故障排查时，能够实现更加精准的定位。数据关联方式的选择直接影响故障排查的效率、准确性以及可视化效果。

可观测性数据关联的目的

在讨论具体的可观测性数据关联方式之前，我们首先需要明确为什么要进行数据关联。数据关联的目的是为了优化故障排查过程、提高系统监控的效率，并帮助用户从多维度获取对系统健康的全面理解。具体来说，数据关联的目的包括：

1.提高故障诊断的准确性和效率

系统中的各个组件和服务彼此依赖，问题往往是多因素、多维度的。单纯依赖某一维度的数据（如单一的日志或单一的指标）难以全面展现问题的全貌，容易导致诊断错误或延误。通过关联不同的数据源（如日志、Trace、指标等），我们可以更准确地定位问题所在，并缩短故障排查的时间。

2.减少数据噪音

系统运行中产生的数据量巨大，尤其是在大规模分布式系统中。没有合理的数据关联，可能会导致用户面对大量的无关数据，从而被“信息过载”淹没。数据关联有助于筛选出关键的、相关的事件或行为，帮助用户专注于最重要的信息，减少不必要的噪音。

3.提高系统的可理解性

对于复杂的分布式系统，理解每个组件和服务的行为变得异常困难。通过数据关联，用户可以跨多个维度（如服务、接口、业务等）对系统的状态进行统一视图的展示，从而增强系统的可理解性。这使得开发人员、运维人员和其他利益相关者可以更加直观地看到系统的工作情况以及潜在的问题。

4.支持根因分析与问题追溯

一旦发生故障或性能问题，快速准确地进行根因分析是至关重要的。数据关联能够帮助用户从多个层次上回溯问题的发生过程，从而帮助确定故障的根本原因。这是特别重要的，尤其是在微服务架构中，问题可能是由多个服务交互引发的，而不仅仅是某个服务本身的问题。

大语言模型与可观测性数据关联

大语言模型具备智能推理能力，在可观测性领域的根因分析和智能诊断等功能中，自然而然地引发了将大模型应用于故障根因定位的想法。然而，考虑到大模型的上下文限制（通常为128K），无法将一段时间内所有的 Trace、Metrics、Logs 等数据完整提交给模型进行分析。因此，大模型无法直接从所有数据中提取故障特征。

在可观测性数据中，Trace、Metrics、Logs 和 Events 各自具有独特的价值。在实际应用中，我们不能仅依赖单一数据源，而忽视其他数据，否则可能会遗漏关键的故障线索。

因此，合理组织和关联这些可观测性数据，并进行综合分析，以提取出有价值的故障特征，是实现大模型故障分析的前提。

常见的可观测性数据关联方式

1.链路级别（Trace）数据关联

链路数据关联是目前最常见的关联方式之一。它通过跟踪请求在微服务架构中的全过程，捕获每个服务的调用链路信息。每个请求会生成一个 Trace，每个 Trace 包含多个 Span（即单个服务的调用记录），这些 Span 按顺序构成完整的调用链。在日志中，通过记录 traceId 和 spanId，实现 trace 与日志的关联，同时通过 timestamp 和主机、容器的标签（label）实现 trace、日志、指标（metrics）和事件（event）的关联。

• 优点：
  ■ 精准定位： 通过完整的调用链路，能够清晰展示服务之间的调用关系，有助于快速定位性能瓶颈和故障源。
  ■ 端到端可视化： 提供全链路视图，帮助用户了解跨多个服务的调用流，尤其是在微服务架构中，能够直观呈现各服务的健康状况。
  ■ 支持跨服务分析： Trace 数据能够跨多个服务，具备跨系统、跨平台的故障排查能力。

• 缺点：
  ■ 高资源消耗： 生成和存储 Trace 数据需要较高的资源消耗，尤其是在大量并发请求时，可能会对数据存储和处理造成较大压力。
  ■ 复杂性： 在服务间调用关系复杂的情况下，Trace 数据可能包含过多信息，导致分析难度增加。很多运维人员也反馈看不懂Trace的具体span数据，特别是慢方法，不知道如何根据Trace信息指导接下来的运维动作。
  ■ 数据噪声： 某些不相关的调用链可能增加数据噪声，影响故障定位的准确性。

大模型的针对链路级别trace用法

通过关联 Trace、日志、指标（metrics）和事件（event），异常相关信息可以提交给大模型进行分析。大模型能够对这些异常数据进行深入分析，例如，针对一段错误日志，提供日志的分析总结；对于异常的 Trace，分析出具体异常的 Span 等信息。

尽管大模型在分析异常数据方面已经对用户提供了极大的帮助，但它并未完全解决用户的排障难题。在如此大量的 Trace 和日志数据中，用户为何要分析某一条异常的 Trace 或日志，这一选择的过程往往充满了随机性。而被分析的 Trace 或日志是否具有代表性呢？

如果连续分析的几条 Trace 或日志都揭示了相同的故障原因，这是否就足以说明问题？在日常工作中，许多用户可能会直接根据这些分析结果进行后续的运维动作。

这种排障方法在没有统计信息支持的情况下，确实有一定的成功概率，但我们认为，这并不是最佳的方案。

此种大模型的用法适合在故障已经定界到具体的服务或者接口之后，再进一步结合此种数据重点分析根因。

2.服务级别数据关联

服务级别关联主要关注服务本身的健康状况和性能，服务的定义可以类比为 Kubernetes 中的 Service。它通过聚合同一实例中不同接口的指标、日志和 Trace 信息，形成以服务为单位的可观测性视图。这种方式将系统中的每个服务视为独立实体，帮助用户全面了解服务的整体健康状况。

• 优点：
  ■ 简洁直观：用户可以通过服务级别的指标（如 CPU 使用率、内存占用率、错误率等）快速了解各个服务的状态。
  ■ 高效监控：与链路级数据相比，服务级数据聚合简洁，减少了数据存储和处理负担。它是很多可观测性平台的入口，帮助用户快速识别故障范围，从而确定故障分析的切入点。
  ■ 易于扩展：随着服务数量的增加，可以方便地扩展和整合新的服务监控。

• 缺点：
  ■ 噪音和关键信息丢失：在实际开发中，一个服务可能会提供多个接口，且接口作用不一。若按照服务的不同接口进行统计，可能会引入噪音或导致关键信息被淹没。例如，某个接口的调用量很少，而另一个接口调用量很大。当调用量少的接口发生故障时，由于大接口占据统计数据的主要部分，调用量少的接口故障可能会被忽略。

大模型的针对服务级别数据关联的用法

服务级别的统计数据可以直接提交给大模型进行分析，大模型能够基于这些数据识别疑似故障的服务节点。然而，这一过程中通过提示词引导大模型存在尺度把握的问题，即如何引导大模型判断服务节点存在疑似故障。

如果阈值设置过于严格，例如只要错误率不为零或 CPU 使用超过某一阈值即认为存在潜在问题，可能会导致大量服务被判定为疑似故障节点，尤其是在没有后续数据进一步支持的情况下，这样的结果难以继续深入分析。

相反，如果阈值设置过于宽松，大模型可能会错误地得出“系统正常”的结论，从而忽略实际的故障。

为了解决这一问题，我们认为可以采取更高层次的策略。首先，将阈值设置得相对严格，尽可能暴露所有潜在问题；然后，在具有因果关系的拓扑结构上进一步分析。所谓因果关系拓扑，指的是明确的上下游调用关系：当下游出现故障时，由于因果关系，故障会传递至上游。

然而，构建服务级别的因果关系拓扑图存在挑战，因为同一实例的不同接口可能出现在不同的业务链路中，同时，拓扑中可能会出现环路，所以APO并没有选择服务级别的数据关联做法。

目前在可观测性领域很少看到将服务级别数据交由大模型分析，因为大模型分析出服务级别的故障概览和人直接看服务级别的故障概览效果基本一致，没有额外的信息补充。

3.接口层级数据关联

接口URL层级数据关联是一种较为新颖的关联方式，类似于服务级别的数据关联，但它专注于具体的URL。对于同一实例的不同URL，它会根据不同的数据源（如 Trace、日志和指标）进行单独聚合。由于日志和指标通常属于实例级别，因此在聚合后，可能会出现误报的情况。然而，这种方法简化了用户的认知负担，更有利于帮助用户聚焦于业务接口层面的性能和故障排查。

• 优点：
  ■ 简洁直观： 用户无需过多关注 Trace、日志、指标或事件等具体数据，可以通过接口层面的抽象来理解接口的健康状态。
  ■ 服务级别聚合的优势：与服务级别聚合数据类似，接口层级聚合也具有简化监控和排查的优点。

• 缺点：
  ■ 难以完全避免数据噪音： 由于日志和指标依然是基于服务级别的数据，划分到接口级别后，仍只能将其视为疑似问题，无法完全避免数据噪音的干扰。

APO最后使用的接口级别的关联方式，形成如下图的状态信息汇总。

• 应用接口异常：数据主要来自于trace，主要是对TPS、latency、error rate 指标进行异常判定之后的汇总状态
• 容器异常类型：主要来自与k8s事件，实现对k8s event的状态汇总
• 基础设施异常：来自于容器的CPU、内存、网络和主机CPU、内存、网络等基础指标的异常判定之后的汇总状态（同主机的CPU告警可能产生对被关联的接口而言，存在误告警可能，需要在业务调用拓扑中用专家经验分析判定 ）
• 网络异常：来自于对网络丢包、延时的状态判定之后的汇总状态
• java exception：来自于对日志的error、exception的异常判定之后的汇总状态
• 应用实例异常：来自与应用探测的事件状态判定之后的汇总状态

近期还会增加，该接口调用的中间件的异常状态判定，比如kafka的指标状态异常了，会影响调用kafka接口的指标状态异常。

大模型的针对服务级别数据关联的用法

接口级别的统计数据可以直接提交给大模型进行分析，大模型可以基于这些数据判断哪些接口所在的服务可能是故障的疑似节点。然而，与服务级别的数据分析一样，接口级别的数据也面临阀值设定的问题。如果阀值设置过于严格，可能会导致大量接口被标记为疑似故障根因；如果设置过于宽松，可能会错过一些潜在的问题。

尽管存在阀值设置的问题，但我们可以通过更高层次的分析来解决这些挑战。具体来说，所有接口异常的数据都可以通过业务调用链路进一步追踪。在这个链路中，接口之间的调用关系是明确的，并且可以从 Trace 数据中构建出接口维度的因果关系拓扑图。下游接口的延迟、错误等问题，往往会传递到上游接口，影响其性能和错误率。

最后通过自然语言描述的“专家经验”的指导，大模型可以帮助理清业务调用链路中的接口关系，并结合上下游接口的故障情况，从而更准确地判断出疑似故障的根因节点。这样的分析方式，能够让大模型模仿人类专家进行故障定位，有效地提升故障定位的准确性。

APO就是如此设计的，根据这些状态汇总信息结合业务级别的数据关联，快速进行故障定界。最后在根据链路数据进行根因定位，所有的数据关联都被思维链聚合在一个对话中，最终可以用户快速实现故障定界定因。暂时还未见同类型的可观测性产品如此操作。

4.业务级别数据关联

业务级别数据关联将可观测性数据按照业务场景进行聚合。例如，电商平台的“下单”过程可以视为一个完整的业务流程，涉及到多个接口。在这种方式中，所有与“下单”相关的请求数据会被聚合在一张业务调用拓扑中，帮助用户从业务视角进行故障排查和优化。

• 优点：
  ■ 直观的业务视角：将可观测性数据从业务角度进行聚合，可以帮助用户更好地理解业务流程中的瓶颈和问题。
  ■ 增强的用户体验：用户可以直接看到与业务相关的数据和故障，而无需关心底层的服务和技术实现。
  ■ 业务优先的故障排查：这种方式能够帮助用户从业务层面进行高效的故障诊断，尤其适用于大型电商、金融等对业务流畅度要求高的行业。

• 缺点：
  ■ 数据聚合复杂度高：将业务流程与系统架构紧密结合，需要对系统和业务流程有深刻的理解，聚合的复杂度较高。
  ■ 节点过多带来的拓扑复杂的问题：节点过多，拓扑实在太大，上百个节点也会导致大模型上下文打满的问题，同时也存在拓扑仍然成环的可能性。

大模型的针对业务级别数据关联的用法

大模型能够接受业务调用拓扑的前提是业务调用拓扑结构不会过于复杂，也要没有环状结构。

• 拓扑结构过大，可能导致大模型上下文限制突破，从而大模型分析失效
• 环状结构的出现，导致专家也很难有好的手段分析因果关系

所以需要提前对业务拓扑结构进行处理，可以利用业务调用链路的不同接口的延时、错误率曲线的相似性，从而快速得到更精简的业务拓扑结构，实现按照故障的贡献度来聚合业务调用拓扑，从而能够让大模型能够在此精简的业务拓扑数据之上分析问题。

未处理的业务调用拓扑：

按照相似度算法处理过之后的业务调用拓扑：

最后按照专家经验可以引导大模型模拟专家在业务调用拓扑之上分析故障。

总结

随着分布式系统的复杂性增加，合理的数据关联方式在可观测性中变得尤为重要。通过将不同来源和维度的可观测性数据（如日志、指标、链路等）进行有效关联，我们能够更全面地诊断系统故障、提高问题定位的准确性，并减少噪声带来的干扰。然而，随着数据量的剧增，传统的数据关联方法也面临着一些挑战，如高资源消耗、信息过载等问题。

通过业务关联和接口关联进行数据定界是故障排查中至关重要的一步。我们可以首先确定业务层面的关键接口，聚焦于用户交互最直接的入口点，利用专家经验，引导大模型模仿专家迅速定位潜在故障源。这一层次的定界有助于将可疑问题限定在业务逻辑的关键路径中，从而减少需要分析的数据范围，提高排查效率。

在此疑似故障节点确定的基础上，通过引入链路的详细关联数据，我们可以进一步深挖每一个相关节点的状态，追踪程序执行过程，从而理解故障根因。通过这种逐层深入的方式，我们能够准确判断出故障的根因。尤其是在复杂的系统中，链路数据能够帮助我们精确地还原请求的完整路径，识别出具体的故障节点。

受限于大模型的上下文限制，直接对所有可观测性数据进行分析并不可行，因此，合理的预处理和数据筛选成为成功应用大模型的前提。大语言模型在这一过程中提供了推理能力，能够按照自然语言描述专家规则操作，这样先比传统AIOPS而言具有很好的可解释性。相比运维数据的预训练的专有大模型，实现成本也相对较低。

总体而言，将可观测性数据按照不同层级（如链路、服务、接口、业务等）进行关联，并结合大模型的智能分析，可以大大提高故障排查的效率和准确性。在此过程中，通过业务和接口层的定界，快速锁定问题范围，再通过链路详细数据的关联逐层深入分析，最终实现精确的根因定位。合理的策略是通过精简和优化拓扑结构、聚合数据并利用专家经验，帮助大模型准确判断故障根因，最终实现高效的故障定位和问题解决。