跳到主要内容

这样的可观测数据平面让AI自动诊断故障

· 阅读需 15 分钟

cover 图

当今云原生和微服务盛行的时代,分布式系统的复杂性与日俱增。保障系统稳定性、快速进行故障诊断成为了运维和开发团队面临的核心挑战。传统的可观测性工具在数据收集和展示方面取得了长足进步,但在应对海量数据、告警风暴以及深度根因分析方面仍显不足。AI,特别是大模型(LLM)的崛起,为自动化故障诊断带来了新的曙光。然而,要充分释放 AI 在可观测性领域的潜力,我们需要一个全新的、为 AI 量身打造的数据平面。

APO (AutoPilot Observability) 正是为此而生。作为一款开源的可观测性平台,APO 并非简单地将 AI 应用于现有数据,而是从根本上重新设计了数据平面,使其更适合 AI Agent 进行分析和推理,从而实现更高效、更精准的自动化故障诊断。本文将深入探讨大模型在可观测性领域的价值,分析为何需要为 AI 定制数据平面,并详细介绍 APO 如何构建一个真正适合 AI 的可观测性数据基础。


LLM:解锁高效数据分析的钥匙

可观测性的三大支柱——Metrics, Tracing, Logging——为我们理解系统状态提供了丰富的数据源。Grafana、Datadog、Jaeger 等工具在可视化和手动分析方面做得非常出色。但面对日益庞大的系统和数据量,传统方法遇到了瓶颈:

  • 告警风暴与信息过载:系统抖动或关联故障可能触发大量告警,淹没关键信号,导致运维人员疲于奔命,产生“告警疲劳”。
  • 专家经验依赖:精准、快速的故障诊断往往依赖少数经验丰富的专家,这种能力难以复制和规模化,成为效率瓶颈。
  • 高昂的 On-Call 成本:运维人员需要 7x24 小时待命,处理重复性高、压力大的排障工作,时间和心理成本巨大。

大模型驱动的 AI Agent 和 Agentic Workflow 为解决这些痛点提供了革命性的途径。通过将领域知识(如系统架构、常见故障模式)和排障经验(如何关联分析 Metrics, Tracing, Logging)注入 AI Agent,我们可以:

  • 自动化初步分析:AI 可以快速扫描海量数据,识别异常模式。
  • 执行根因推断:结合上下文信息和知识库,AI 可以提出可能的故障原因。
  • 辅助甚至替代重复工作:AI 可以处理大量标准化的排障流程,将工程师从繁琐的任务中解放出来。这不仅能大幅提升故障诊断的效率和准确性,还能显著降低运维压力,提升整体系统稳定性。

为什么需要专为LLM优化的数据平面?

仅仅将现有的可观测性数据(如 Prometheus 的指标、Jaeger 的链路、Loki 的日志)直接喂给大模型,效果往往不尽人意。原因在于,传统的数据平台主要面向人类工程师,侧重于可视化和手动探索,而 AI Agent 对数据的需求有着本质的不同:

  1. AI 需要“可理解”的数据结构
    AI 并非全知全能,难以直接理解各种异构、原始的数据格式。例如,直接输入原始的 Trace Span 数据,AI 可能难以准确构建服务依赖关系。数据需要经过预处理和结构化,转换成 AI 更容易理解的格式(如图、结构化指标)。
  2. 数据间需要显式的关联性
    故障诊断往往需要结合多种数据源。例如,通过指标发现延迟升高,通过链路定位到问题服务,再通过日志查找具体错误。如果这些数据(Metrics, Tracing, Logs)之间缺乏统一的、可关联的标签(如 TraceID、Pod Name、时间戳),AI 就需要执行复杂的跨系统查询和关联操作,效率低下且容易出错。
  3. 实时性与效率要求数据预聚合与模式提取
    AI Agent 需要快速响应(例如,用户问“服务 X 为什么慢了?”时,期望秒级回答)。这要求数据平面能够提供预先计算好的统计信息和模式,而不是让 AI 每次都从海量原始数据中临时计算。直接分析原始数据不仅消耗大量 Token(成本高昂),速度也无法满足交互式分析的需求。
  4. AI 对噪声敏感,需要过滤和统计
    单次的网络抖动或偶发的应用错误可能产生“噪声”数据。AI 分析需要基于统计趋势而非孤立事件,以避免误判。例如,需要将零散的错误日志聚合成错误率指标,将单次请求的毛刺延迟平滑为 P99 延迟趋势。

传统数据平面的局限与 APO 的创新设计

了解了 AI 对数据的特殊需求后,我们再来看传统可观测性数据平面(如 Jaeger Trace, Loki Log, Prometheus Metrics)存在的具体局限,以及 APO 是如何通过创新设计来克服这些挑战的:

面向存储/UI 的数据结构对 LLM 不友好

  • 问题:传统工具的数据结构设计优先考虑存储效率(如压缩)或 UI 展示(如可视化)。
  • 对 AI 的挑战:这些非 AI 优化的数据结构可能导致 AI 理解困难、识别错误,甚至产生“幻觉”。
  • APO 的设计:APO 针对性地设计了适合 AI 理解的拓扑和指标数据结构,并通过 Few-shot Prompt Engineering 进行了优化,显著提高了 AI(如 DeepSeek-V2)识别服务拓扑、指标异常的准确率(实验准确率超过 98%)。

数据孤岛与关联性缺失

  • 问题:Trace, Log, Metrics 数据通常存储在独立的系统中,缺乏统一的上下文标识进行默认关联。工程师需要手动将 Jaeger 中的延迟、Prometheus 中的 CPU 飙升、Loki 中的错误日志拼接起来分析。
  • 对 AI 的挑战:AI 需要执行多次跨系统查询和复杂的关联逻辑,耗时可达秒级甚至分钟级,无法满足实时故障诊断的需求。
  • APO 的设计:APO 利用 eBPF 技术,在数据采集层面就将 Trace、Log、Metrics 与丰富的上下文信息(如 Pod、Node、进程、线程、TraceID)进行自动关联。输出的 API 级别拓扑数据本身就包含了关联信息,AI 无需再进行耗时的二次关联。 1 图

缺乏预处理与模式提取

  • 问题:传统平台存储的是原始数据记录(如每个 Span、每条 Log),缺乏统计意义上的模式信息。工程师需要人眼观察火焰图或日志大海捞针。
  • 对 AI 的挑战:让 AI 直接处理海量原始数据,计算量巨大,响应缓慢,且成本高昂。
  • APO 的设计:APO 在数据处理管道中对 Trace 和 Log 进行预聚合和模式提取。例如,将大量 Trace 预计算为 API 级别的服务调用图和关键性能指标(延迟、错误率、吞吐量),甚至可以预先计算出下游节点对整体延迟的贡献度(如“数据库调用耗时占比 71%”)。AI 可以直接利用这些统计结果快速定位问题方向,而非在原始数据中低效探索。 2 图

服务拓扑粒度粗糙,缺乏业务视角

  • 问题:基于 Tracing 生成的服务拓扑通常只到服务级别(Service-Level)。当某个服务(如 service-a)出现性能问题时,难以直接判断影响了哪些具体业务功能(如“下单接口”还是“查询接口”),需要进一步下钻分析。
  • 对 AI 的挑战:AI 的分析停留在服务层面,无法直接关联到业务影响,需要多轮交互或复杂的下钻查询才能触达问题本质,可能导致分析不准确或效率低下。
  • APO 的设计:APO 将服务调用拓扑细化到 API 级别(如 /api/order, /api/product/{id}),更贴近实际业务场景。同时,APO 引入了“业务入口”的概念,将相关的 API 调用链路按业务功能进行分组。这使得 AI 的分析结果更精确,输出的故障诊断报告也更容易被业务和开发人员理解。 3 图

关键数据仅有关联性,缺乏因果性

  • 问题:传统可观测性数据(如 Metrics 和 Trace)通常只能展示现象之间的相关性(例如,API 延迟升高与 CPU 使用率升高同时发生),但难以直接证明因果关系。Trace 数据虽然能展示请求路径,但仍可能存在监控盲区(如内核态耗时、锁等待),无法精确分解请求耗时的具体构成。
  • 对 AI 的挑战:AI 在缺乏因果性指标的情况下,难以建立标准化的、可靠的故障诊断路径,更多依赖于模式匹配和相关性猜测,导致诊断结论可能不准确或不稳定。
  • APO 的设计:APO 再次利用 eBPF 技术深入内核和应用运行时,实现了请求级别的耗时分解(北极星指标)。能够将一个 API 请求的总耗时,精确地分解为 CPU 执行耗时、CPU 等待调度(runqueue)耗时、网络调用耗时、磁盘 I/O 耗时、锁等待耗时等具有明确因果关系的组成部分。这为 AI 提供了一条清晰、标准化的分析路径,能够准确定位性能瓶颈的直接原因,极大提升了故障诊断的准确性和深度。 4 图

总结:APO - 为 AI 打造的智能可观测基石

为了让 AI 在可观测性领域发挥最大价值,APO 通过以下关键设计构建了一个面向 AI 的数据平面:

  • LLM 友好的数据结构:精心设计拓扑和指标结构,提升 AI 理解准确性。
  • eBPF 驱动的数据关联:自动关联 Trace, Log, Metrics 及系统上下文。
  • 预处理与模式提取:将原始数据转化为包含统计意义的指标和模式。
  • API 级业务拓扑:细化服务调用图至 API 级别,并按业务入口分组。
  • 因果性北极星指标:基于 eBPF 实现请求耗时精确分解,直击性能瓶颈。

通过这些专门为 AI 设计的优化,APO 构建的数据平面能够让 AI Agent 更高效、更准确地进行故障诊断和根因定位,显著提升系统稳定性,真正成为工程师的得力助手,将他们从繁琐、重复的排障工作中解放出来。

如果你对利用 AI 提升可观测性和故障诊断效率感兴趣,如果你也希望借助大模型的力量来保障系统稳定性,那么 APO 值得你深入了解和尝试。想了解更多或亲自体验 APO 的魔力吗?欢迎访问我们的项目地址,查阅文档、下载试用,并加入我们的社区,让我们一起探索 AI 可观测性的未来!


5 图

APO v1.6.0 更新:告警工作流优化;服务列表排序;故障现场数据关联

· 阅读需 3 分钟

cover 图

本次 APO v1.6.0 版本更新带来了以下内容。注意本次更新存在破坏性变更,请参考官网的“安装手册”-“版本升级手册”进行升级。

更新日志

⚠️破坏性变更

  • 使用 PV 替换 HostPath 持久化方式,提高可维护性。如果您创建或修改过工作流,建议备份Postgres后再升级,否则工作流数据会重置。
  • 数据持久化变更:Grafana 和 apo-backend 数据库默认使用 PostgreSQL。请参考官网的“安装手册”-“版本升级手册”进行数据备份和升级。
  • Helm Charts 配置变量变更:工作流对应 baseurl 中的固定端口优化为可编辑端口,升级时请修改 values 文件中对应变量。

新增功能

  • 进一步优化“告警有效性分析”工作流和“告警简单根因分析”工作流,增加识别效果和准确率

  • 服务概览中的服务列表支持按照不同指标排序。现在可以点击表格标题按照该指标进行排序: 1 图

  • 支持根据TraceID从故障现场链路跳转至故障现场日志 2 图

  • 故障现场日志新增TraceID筛选条件 3 图

  • (企业版)新增线程级北极星指标和展示仪表盘 4 图

功能优化

  • 故障现场链路默认展示故障数据,新增既错又慢状态筛选 5 图

  • OneAgent 支持自动监控新建的namespace中的服务

  • 可配置告警有效性检查的执行频率和采样方式

  • 告警列表自动更新最新数据和状态

  • 优化工作流页面展示布局

缺陷修复

  • 修复 apo-backend 中的 polaris-analyzer 内存未及时清理的问题
  • 修复 OneAgent 注入Trace探针时可能覆盖JVM配置的问题
  • 修复链路追踪断链场景时,缺失下游服务的问题
  • 修复服务详情中仪表盘未匹配对应服务的问题

其他

  • apo-otel-collector 新增prometheus-remote-write receiver

6 图

试试智能体工作流,自动化搞定运维故障排查

· 阅读需 8 分钟

cover 图

APO 1.5.0版本全新推出的智能体工作流功能,让运维经验不再零散!只需将日常的运维操作和故障排查经验转化为标准化流程,就能一键复用,效率翻倍,从此告别重复劳动,把时间留给更有价值的创新工作。更贴心的是,APO无需改造现有监控系统,轻松对接即可使用,真正实现“开箱即用”。

下面带大家快速上手这一功能,先从官方内置的实用工作流开始体验!

「开箱即用」的工作流

我们精心打磨了两款告警处理神器:告警有效性分析告警根因分析。它们就像24小时在线的智能助手,帮你自动处理告警,让运维工作事半功倍!

1. 告警有效性分析:告别「无效告警轰炸」

面对海量告警信息,这个工作流能快速识别哪些告警需要紧急处理,哪些可以暂缓。有了它,你既能从容应对关键问题,又能放心设置更灵敏的告警规则,在故障发生时自动收集完整上下文,为后续排查打下坚实基础。

1 图

2. 根因分析:5分钟定位问题源头

触发告警后,这个工作流会立即行动:自动关联主机、服务或Pod的上下文数据,分析指标异常,并通过「北极星指标」进行多维度根因排查。无论是服务延迟激增还是资源异常波动,它都能帮你快速锁定问题根源,让故障修复效率提升80%!

后续我们会详细解析这些工作流的设计逻辑和实战效果。所有内置流程都支持按需调整,灵活适配你的业务场景,打造专属智能运维助手!


手把手教你搭建专属工作流

第一步:进入工作流平台

登录APO后,点击左侧菜单栏的「工作流」进入编辑页面。

(若未找到入口,请确认版本≥1.5.0,并检查管理员是否在「系统管理」-「菜单」中开启了该功能)

在这里呈现了很多内置的工作流,可以根据需求直接修改这些工作流,也可以从零开始根据专家经验构建属于自己的流程。

2 图

第二步:创建工作流

这里我们从零开始创建一个工作流。点击“创建空白应用”,在弹出的页面中输入应用名称,点击“创建”进入工作流编辑页面。

3 图

4 图

第三步:拖拽节点,连接流程

5 图

编辑界面左侧为功能节点库,通过鼠标拖拽即可自由组合流程,就像搭积木一样简单!将画布上的节点连接起来,就完成了工作流的创建。

在构建工作流时需要注意以下几点:

  • 填写每个节点的输入参数;
  • 使用大模型节点前,需在设置中配置API权限;
  • 通过「检查列表」实时排查流程逻辑问题;
  • 阶段性点击「运行」测试流程是否符合预期。

APO 工作流平台基于开源项目 Dify 开发,平台本身的使用在 Dify 官网有详尽的文档,这里重点介绍APO专为可观测性场景深度优化的功能:数据查询节点、异常检测节点和数据验证图表。

数据查询节点:一键调取全维度数据

可观测性平台的基础能力是展示数据并分析问题,因此数据查询是工作流最基本的能力。APO将各类丰富的数据查询工具集成到了工作流编排平台中,方便用户快速将需要查看的数据放入工作流中。

通过搜索可以快速找到你需要的数据,同时可以输入查询参数来检查当前数据:

6 图

异常检测节点:智能识别潜在风险

使用APO内置的异常检测工具,可以在查询数据后判断数据是否存在异常,针对异常数据能够进一步执行工作流分析。目前内置的异常检测工具包括阈值判断、趋势判断、分位数检测等,未来还需进一步丰富异常检测工具。

除了使用内置的异常检测节点,你还可以将数据输入大模型,让AI辅助判断异常类型,也有不错的效果!

数据验证图表:结果可视化,一目了然

回溯工作流的执行结果有助于我们理解执行过程。 APO采用图表的方式展示可观测性数据,大大增强了结果的可解释性。APO为每一类数据都设计了对应的图表,方便检查数据内容:指标数据用折线图展示趋势,链路数据用拓扑图呈现依赖关系。每一步分析结果清晰可见,轻松回溯排查逻辑。

7 图

通过智能体工作流,APO让运维从「救火式响应」进阶为「自动化治理」。现在就动手搭建你的第一个工作流,体验高效运维的乐趣吧!下一篇文章,我们将手把手展示如何构建「告警诊断」工作流,敬请期待!


8 图

APO v1.5.0更新:新增工作流编排、数据接入和告警事件列表;新增Traces数据采样

· 阅读需 6 分钟

cover 图

Agentic workflow(工作流):你的经验,Agents的灵魂

本次更新带来了专为可观测性系统设计的Agentic工作流编排功能,通过使用工作流,能将你的专家经验转变为可复用的执行流程,赋予智能体专业决策能力,提高故障排查效率。核心亮点:

  • 经验驱动的智能体:通过直观的工作流编排平台,用户可将运维智慧转化为自动化工作流,赋予智能体专业决策能力。

1 图

  • 预定义场景工作流:APO内置告警智能分析、自动化运维巡检和复杂故障快速诊断等场景,开箱即用,提升运维效率。

2 图

  • 灵活编排与定制:基于Dify打造的平台提供数据查询和异常检测工具,用户可轻松创建和修改工作流,适应多样化系统环境。

3 图


数据接入:支持通过页面接入新的监控集群或已有数据源

新增了“接入中心”-“数据接入”页面,现在可以在该页面配置探针安装命令,并根据指引监控新的集群。

您可以根据实际环境情况选择数据接入的方式,目前支持安装新的APO探针(基于OpenTelemetry)采集链路追踪数据,也支持对接已有的OpenTelemetry+Jaeger和SkyWalking数据源。

您还可以在接入中心中查看和管理已经接入的集群信息。注意通过其他方式手动安装APO OneAgent时,无法在该页面中管理。

4 图


告警事件列表

新增的告警事件列表中展示了最近产生的告警事件。在该列表中,APO结合“告警有效性”工作流和“告警根因分析”工作流自动分析告警。

  • “有效性”意味着该告警是否对系统中的服务造成影响,如果该告警不是偶发的波动且对服务造成了影响,则会被判定为“有效”
  • 针对单个告警,您可以点击“查看根因分析”,自动执行工作流来分析告警的深层原因

5 图

这些工作流均可在“工作流”页面中进行编排和优化,您可以根据实际环境情况和排查经验对工作流做出修改。


Traces数据采样

如果您使用APO OneAgent采集Traces数据,现在您可以通过修改配置开启数据采样功能。开启数据采样后将大量减少Traces数据的保存数据量,降低存储成本。根据环境和采样设置的不同,存储成本将降低到原来的30%或更低。

与传统的头采样和尾采样均不同,APO基于分布式采样策略实现了Traces数据采样。分布式采样在边缘侧(服务所在主机)决定当前数据是否保存,有效降低了整体系统的资源开销。

详细配置方式请参考“文档”-“配置Traces数据采样”。注意如果您安装APO时,采用对接已有的OpenTelemetry和SkyWalking安装方式,则不支持采样功能。

更多变化请查看下面的更新日志。


更新日志

新增功能

  • 工作流:专为可观测性领域设计的工作流编排平台,预设了多种常用工作流帮助用户解决日常问题
  • 告警事件列表:显示近期的告警事件,并通过工作流自动分析告警的根因
  • 数据接入:现在APO支持通过可视化页面接入多种外部数据源,当前版本支持对接 OpenTelemetry 和SkyWalking 链路追踪数据
  • 链路追踪采样:APO OneAgent安装的链路追踪探针现在默认开启了数据采样,有效降低数据量

功能优化

  • 支持在对接SkyWalking探针时,获取网关类型应用的请求延时指标
  • 增强了eBPF北极星指标在 Linux 内核版本5.8以上的适配性

缺陷修复

  • 修复odiglet在传统服务器上将不同的JAVA应用的服务名全部设置为'java'的情况
  • 修复告警分析中按故障贡献度排序时,有时因为指标中缺少服务信息label导致的异常

6 图

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

· 阅读需 8 分钟
Kindling-OriginX
故障根因推理引擎

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

运维的挑战与责任

在数字化时代,运维团队面临的挑战前所未有。他们不仅要确保系统的高可用性和高性能,还要快速响应并解决故障,以减少对业务的影响。在这种背景下,运维团队急需工具和技术,能够帮助他们提高效率,减轻负担。AIOps(人工智能运维)应运而生,旨在通过应用人工智能和机器学习技术来自动化监控、预测、优化和故障排除过程。

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

AIOps当前技术与输出

AIOps核心功能包括事件聚合、异常检测、自动化根因分析等。这些技术能够帮助运维团队从海量的监控数据中快速识别问题,预测潜在故障,并自动化常见问题的解决过程。通过AIOps,许多组织已经显著提高了故障响应时间,减少了误报,优化了运维流程,提升了IT系统的整体可靠性和性能。

AIOps仍然存在挑战:故障根因与可观测性数据割裂

尽管AIOps技术取得了显著进步,但在故障根因分析方面仍面临一个重大挑战:故障根因与可观测性数据(如日志、指标、追踪)之间的割裂。AIOps系统虽然能够推荐可能的故障根因,但往往难以直接将这些推荐与具体的可观测性数据紧密关联。这就要求运维人员依靠自己的经验和知识,在海量的数据中寻找证据来验证这些推荐,这一过程既耗时又容易出错。

Gartner 魔力象限中领先象限做到的效果

Dynatrace 效果

Dynatrace 的AI故障推理效果和介绍详情可参见 Dynatrace 官方网站。

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

从 Dynatrace 的视频中,如果发生了故障之后,AI推荐出AI根因之后,用户仍然需要使用根据 Visual resolution path 去从众多的Trace以及各种可观测性数据中筛选出证据来证明这个AI的推断。

Dynatrace 做到全球最牛的地方,就是能够将各种可观测性数据融为一体,并以时间线为维度还原故障现场,这个本质上还是人为分析,所谓的AI推荐,给出的是关键节点。

如果没有这个故障根因推荐,用户使用 Dynatrace 怎么做呢?仍然是围绕着故障时间点,利用 Dynatrace 的 Visual resolution path 人为分析故障根因。

结论:故障根因的推荐聊胜于无,还是需要人为在可观测性数据中分析找证据。

Datadog 效果

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

Datadog 的 Watchdog RCA给出仍然是可能性,具体从可观测性中找证据来证明这点,仍然需要用户自己来做。

结论:故障根因的推荐聊胜于无,还是需要人为在可观测性数据中分析找证据。

可观测性盲区的存在导致AIOps的根因结论与可观测性数据存在割裂

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

举例说明:Dynatrace 的根因例子为节点CPU利用率达到100%,其实绝大多数运维人员都能识别出100% CPU利用率是有问题的。但是如果CPU利用率是50%,这个时候人是很难判断程序是否会受到CPU供给瓶颈,需要额外提供更多的数据去判断CPU利用50%的时候,程序的执行是否会受到调度器的影响,这取决于很多因素,比如机器上需要调度的程序多少,CPU调度器排队的长度等,总而言之,可观测性数据存在盲区。

可观性数据由于存在盲区,导致人都很难根据可观测性数据推理出故障,只能根据事后的结论去关联出CPU利用率50%在某些场景下也是存在可能性导致故障根因的(资深运维人员在判断这两点的时候CPU利用率为50%,是故障根因也是需要非常深厚的经验)。

可观测性数据盲区更详细的介绍,请参考之前的文章。

内核视角持续剖析解决AIOps的故障根因结论与可观测性的割裂问题

在之前的文章介绍了可以使用内核视角下持续剖析,能够形成基于北极星指标的排障体系。可参见:内核视角下持续剖析 VS 代码视角下的持续剖析

AIOps实践中常见的挑战:故障根因与可观测性数据的割裂

基于这个标准化排障体系进行故障根因推导的时候,就能够同时自动化关联相关指标。比如如果发现网络时间很长,这个时候就可以关联网络相关性指标,必要时还可以同步 DeepFlow 等关键网络事件及数据,提供证据证明网络确实有问题。

APO OneAgent 设计思路

· 阅读需 12 分钟
Autopilot Observability
APO 向导式可观测性平台

Cover 图

之前的文章介绍过APO是如何使用Grafana Alloy采集prometheus生态的指标体系。这篇文章介绍APO是如何采集Trace和log的,这两项数据的采集存在以下问题:

  • 日志需要配置采集的日志目录,并不是每个应用的日志目录都非常规范,这就导致配置工作量的增加
  • Trace需要配置针对语言的Agent完成数据采集
  • 在容器环境不管是修改镜像或者使用init Container方式,都有挺多配置的工作

OneAgent的设计目标

OneAgent的设计目标是尽量减少用户的配置工作,尽快的完成数据的采集。在设计过程中,参考了很多的业界先进的技术实现,比如datadog的onestep agent的实现机制,另外重要的就是Odigos这家公司的实现。Datadog不用做更多的介绍,这里简单介绍下Odigos这家公司:Odigos的口号是“Instant Distributed Tracing”,有兴趣可以访问其官网:https://odigos.io/ ,OpenTelmetry 的 GO auto instrument 项目:https://github.com/open-telemetry/opentelemetry-go-instrumentation 就是由该公司捐献的。

Odigos开源的https://github.com/odigos-io/odigos 实现中能够实现以下功能:

  • 基于应用当前已经启动的POD进行语言识别
  • 基于K8s manifest挂载对应语言的探针文件和配置到对应的应用
  • 通过更新K8s manifest触发应用重启以应用探针

为了实现OneAgent的设计目标,我们调整了Odigos的执行流程,使用Webhook将'更新K8s manifest'和'应用重启'两个步骤进行了分离:

  1. 更新内容以patch形式存储到应用的Annotations中
  2. 用户手动重启pod时,通过webhook拦截pod创建请求,应用Annotations中保存的patch

这样可以避免用户对整个Namespace装载探针时,集群所有应用同时重启,造成资源紧张;而是预先设置好探针配置,在应用下次更新时,自动完成探针的添加。

Odigos中没有包含非K8s应用的实现,我们采用了Linux的Preload机制来完成下面的工作:

  • 通过LD_PRELOAD加载Preload库,在应用启动前拦截启动命令,完成语言识别和后续工作
  • 基于识别到的语言设置探针配置,通常以特定的环境变量加入到启动命令
  • 将改造后的启动命令交给Linux继续执行,完成应用的启动和探针的应用

为了实现OneAgent的设计目标,我们调整了Odigos的执行流程,使用Webhook将'更新K8s manifest'和'应用重启'两个步骤进行了分离:

  1. 更新内容以patch形式存储到应用的Annotations中
  2. 用户手动重启pod时,通过webhook拦截pod创建请求,应用Annotations中保存的patch

这样可以避免用户对整个Namespace装载探针时,集群所有应用同时重启,造成资源紧张;而是预先设置好探针配置,在应用下次更新时,自动完成探针的添加。

Odigos中没有包含非K8s应用的实现,我们采用了Linux的Preload机制来完成下面的工作:

  1. 通过LD_PRELOAD加载Preload库,在应用启动前拦截启动命令,完成语言识别和后续工作
  2. 基于识别到的语言设置探针配置,通常以特定的环境变量加入到启动命令
  3. 将改造后的启动命令交给Linux继续执行,完成应用的启动和探针的应用

针对日志数据的采集,我们采用了阿里开源的 https://github.com/alibaba/ilogtail 工具,它有下面一些优点:

  1. 基于Linux的inotify机制,相较于轮询读取文件,消耗更低
  2. 内置一套设计良好的插件系统,性能开销较大的采集阶段使用C语言实现,确保高效;后续处理采用Go实现,可以快速的进行数据完善和处理
  3. 内置的采集插件支持了对父级目录下日志文件检索,避免用户手动配置每个应用日志地址

在ilogtail基础上,我们实现了功能增强插件,用于统计需要的日志指标,填充日志进程信息和日志数据采样。


程序语言的自动识别

目前的程序语言识别均基于启动命令特征和启动文件信息:

  1. JAVA: 检查启动命令是否满足 java [-options] class [args。。。] 或 java [-options] -jar jarfile [args。。。] 格式
  2. PYTHON: 检查启动命令中是否包含python
  3. Golang: 读取启动文件的内容,检查是否有可识别的buildInfo信息
  4. NodeJS: 检查启动命令中和启动文件路径中是否包含node
  5. Dotnet: 检查启动环境变量中的环境变量名中是否包含DOTNET和ASPNET

探针配置的注入

在完成应用语言类型的识别后,开始准备探针的配置信息。

1.OTEL体系下的APM探针均原生支持基于环境变量来设置探针,我们目前主要预设了下面的配置:

  • OTEL_EXPORTER_OTLP_ENDPOINT 设置探针数据的发送地址
  • OTEL_SERVICE_NAME 设置应用名称
  • OTEL_METRICS_EXPORTER/OTEL_LOGS_EXPORTER 设置为 none,关闭指标/日志采集

2.Skywalking当前以内置的配置文件作为中转,也支持使用环境变量进行配置,主要设置:

  • SW_AGENT_COLLECTOR_BACKEND_SERVICES 设置探针数据发送地址
  • SW_AGENT_NAME 设置应用名称

对于K8s应用,大部分的环境变量会由Odigos通过k8s提供的Device Plugins加入到容器内;

用户已经在K8s Manifest定义了的环境变量,会在K8sManifest显式的合并到用户定义的Envs部分。

对于非K8s应用,环境变量会直接被添加到启动命令中,如果和用户定义变量发生冲突,始终使用用户定义变量。


探针的拷贝

在K8s环境中,由于容器的文件隔离特性,应用无法直接获取到需要的探针文件。Odigos通过将宿主机路径挂载到应用容器内部来向应用提供探针文件,默认将探针文件放到应用的/var/odigos 目录下。

在非K8s环境中,由于应用可以直接获取到宿主机上的探针文件,所以当前没有进行探针文件的拷贝。

日志和进程信息关联

在K8s环境下,采集器通过日志的文件路径可以直接关联到容器,再由容器可以直接关联到所属的应用。这使得在查询日志时,可以通过应用来过滤日志,对于查找关键信息有很大帮助。

非K8s环境中,采集器获得的日志的文件路径就不再像K8s环境中那么规范。不论是ilogtail所使用的inotify机制,或者其他基于文件轮询的日志采集工具,都无法获取到日志是由哪个进程产生的。常规的处理方式是整个项目推行日志文件路径规范,从而可以解析日志文件路径来获取应用信息,这是一种成本较高的解决方案。

APO使用了Linux的Fanotify接口来关联文件和应用信息,它是一个在linux内核2.6.37引入的系统接口,利用Fanotify可以自动关联进程所产生日志文件。

为了降低监听Fanotify事件的资源开销,APO遵循下面这套方案进行文件到应用关联关系的维护:

  1. 通过inotify获取到日志文件更新信息
  2. 将日志文件路径添加fanotify监控标记,监控该文件的修改和关闭事件
  3. 日志文件下次被修改时,获取到修改该文件的进程信息。缓存该日志文件路径对应的进程信息,并关闭对该文件修改事件的监控
  4. 直到接收到该日志文件的关闭事件,这意味着之前获取的进程停止了对该文件的写入;此时重新开始监控该文件的修改事件,以更新该日志文件路径对应的进程信息

通常仅应用进程会对日志文件进行修改,因此上面这套方案可以以极低的消耗完成较为可靠的日志文件路径到进程信息的关联。


总结

APO通过OneAgent中的集成修改的Odigos机制,实现了不同语言的应用程序自动完成OTEL trace探针的安装和环境变量配置,同时通过集成ilogtail采集了日志,并能够实现日志和应用的关联。

OneAgent能够在容器环境和传统虚拟机上同样工作。

APO介绍:

国内开源首个 OpenTelemetry 结合 eBPF 的向导式可观测性产品

apo.kindlingx.com

https://github.com/CloudDetail/apo

APO v0.3.0 发布:关联告警事件;提升数据筛选效率;优化安装体验

· 阅读需 5 分钟
Autopilot Observability
APO 向导式可观测性平台

Cover 图

APO 软件的新版本 v0.3.0 已经正式发布了!这次的更新不仅带来了功能上的改进,还有用户体验上的重大升级。以下是此次更新的主要亮点:

关联告警事件,快速发现故障

在 v0.3.0 版本中,我们引入了全新的告警事件关联功能。这一特性可以帮助您更高效地识别和定位服务相关的潜在问题。通过将相关的告警事件聚合在一起,您可以更容易地追踪到问题的根本原因,从而加快故障排除的速度。 1 图

此外,我们还将告警状态灯关联到了具体的告警原因,只需要将鼠标悬浮到状态灯上即可查看,再也不需要问“为啥这里红”了! 2 图

提升数据筛选效率

为了帮助用户更好地从海量数据中获取有价值的信息,我们在新版本中加强了“服务概览”页面数据筛选的功能。现在,您可以基于“服务名”、“服务端点”或“命名空间”来精确定位期望查看的数据,这将极大地提高数据分析的效率。 3 图

更顺滑的安装流程,优化安装体验

我们一直致力于简化软件的安装步骤,以减少用户的前期投入时间和精力。在本次更新中,我们重新设计了安装流程,尤其减少了探针无法启动的情况,使得整个过程更加流畅。

我们衷心感谢所有参与测试和支持 APO 社区的用户们。正是因为有了你们的反馈和支持,APO 才能不断进步。我们期待着您的宝贵意见,也欢迎您继续参与到 APO 的成长旅程中来!


更多变化请查看下述更新列表。

新增功能

  • “服务概览”页面新增筛选条件,可模糊查询服务名、服务端点和命名空间
  • “服务详情”页面新增告警事件列表
  • 告警状态灯支持鼠标悬浮显示告警原因
  • 指标曲线图支持鼠标悬浮放大,便于查看具体时间的指标
  • “服务详情”页面指标曲线图支持通过选择时间范围修改查询时间
  • 新增中间件指标监控大盘

功能优化

  • 在 Kubernetes 环境安装 OneAgent 时,支持对所有命名空间进行监控
  • 服务概览页面展示服务所属的命名空间,在传统服务器环境中显示N/A
  • 优化“应用基础设施大盘”指标显示效果,兼容各类监控环境
  • 接入 SkyWalking 后,“链路追踪”页面支持按照 SkyWalking 的 TraceID 进行检索

缺陷修复

  • 修复时间选择器在切换页面时可能被重置的问题
  • 修复容器环境可能无法获取到容器启动时间的问题
  • 修复 node-agent 部分情况下会内存溢出的问题

其他

  • 首次进入服务详情页时,展示功能引导
  • 增加功能与术语的解释说明

APO v0.4.0 发布:新增影响面分析;新增调用数据库指标;优化告警事件关联展示

· 阅读需 4 分钟
Autopilot Observability
APO 向导式可观测性平台

Cover 图

APO 新版本 v0.4.0 正式发布!本次更新主要包含以下内容:

新增影响面分析,识别服务端点对服务入口的影响

服务入口是指业务被访问时调用的第一个服务端点,在调用拓扑图中处于最上游。服务入口直接反映了系统对外提供服务的状态,因此了解服务入口的状态对于保证系统服务的稳定性至关重要。

APO 实现了服务端点粒度的拓扑图,还原了每一个服务端点的调用路径,能够准确定位其调用路径上的服务入口。我们在服务详情页中关联了服务入口,便于用户及时了解当前服务对服务入口的影响情况,对影响面进行分析。 1 图

新增服务调用的数据库指标

应用的RED指标(请求次数、错误率、响应延时)反映了应用提供的服务质量,而服务质量受到多种因素影响,其中应用对外部服务的依赖是重要的一部分。本次更新 APO 优先引入了数据库调用指标,当服务质量发生问题时,能在第一时间了解是否是外部数据库导致的。 2 图

优化告警事件关联展示

本次更新中,如果服务端点关联到告警事件,将优先展示告警详情,同时优化了告警列表的展示效果。 3 图

我们衷心感谢所有参与测试和支持 APO 社区的用户们。正是因为有了你们的反馈和支持,APO 才能不断进步。我们期待着您的宝贵意见,也欢迎您继续参与到 APO 的成长旅程中来!


更多变化请查看下述更新列表。

新增功能

  • 服务详情页新增针对服务入口的影响面分析
  • 服务详情页新增数据库调用指标(服务粒度)
  • 调整架构提高适配性,基础功能支持全部内核版本

功能优化

  • 查询故障现场链路增加更多筛选条件
  • Kubernetes 事件统计将警告事件标记为红色
  • 优化 OneAgent 中 Alloy 的内存占用

缺陷修复

  • 修复重启 OneAgent 导致 JS、Python 语言 Instrument 探针丢失的问题
  • 修复服务概览页无法通过指标曲线图切换时间范围的问题

APO v0.5.0 发布:可视化配置告警规则;优化时间筛选器;支持自建的ClickHouse和VictoriaMetrics

· 阅读需 5 分钟
Autopilot Observability
APO 向导式可观测性平台

Cover 图

APO 新版本 v0.5.0 正式发布!本次更新主要包含以下内容:

新增页面配置告警规则和通知

在之前的版本中,APO 平台仅支持展示配置文件中的告警规则,若用户需要添加或调整这些规则,必须手动编辑配置文件。而在新版本中,我们新增了一套可视化的告警规则配置界面,使用户能够直接通过 APO 控制台来进行告警设置。此外,配置界面内置了常用的指标查询模板,用户只需根据实际需求选取相应的指标并设定阈值,即可轻松完成规则配置。

1 图

同时新版本还支持配置告警通知,目前支持邮件通知和 Webhook 通知。

2 图

0.5.0 作为告警配置的第一个版本,仅包含了基础功能,未来我们还将继续优化用户体验,并带来更丰富的配置选项以满足更复杂的场景需求。欢迎大家积极向我们提出建议。

更好用的时间筛选器

在之前的版本中,APO 的时间筛选器仅支持查询绝对时间,并且需要用户手动触发更新操作。而在新版本中,我们重新设计了时间筛选器,增加了相对时间的支持,并实现了页面的自动刷新功能。以后再也不会出现“新监控了一个应用,但怎么刷新页面也没数据”的问题啦!

3 图

支持使用自建的 ClickHouse 和 VictoriaMetrics

从 0.5.0 版本开始,APO 支持将数据存储到用户自建的 ClickHouse 和 VictoriaMetrics 中,无论您是使用单节点还是分布式集群方案,APO 都能够无缝接入。在生产环境中,我们建议使用托管的 ClickHouse 和 VictoriaMetrics 集群来保证可用性。

近期,APO 社区正在积极设计开发“全量日志”的功能,我们调研分析了业内优秀的日志方案,结合在可观测性领域积累多年的经验,完整设计了从日志的采集、处理、存储到展示的方案,将 APO 对日志的思考融入其中。我们的目标始终是为社区提供一款开箱即用、高效率、低成本、强扩展性且拥有良好用户体验的可观测性产品,全量日志方案自然也不例外。全量日志功能预计将于10月开源,敬请期待!

我们衷心感谢所有参与测试和支持 APO 社区的用户们。正是因为有了你们的反馈和支持,APO 才能不断进步。我们期待着您的宝贵意见,也欢迎您继续参与到 APO 的成长旅程中来!


更多变化请查看下述更新列表。

新增功能

  • 新增页面配置告警规则和通知功能
  • 服务实例中关联实例所在节点信息,辅助排查节点

功能优化

  • 优化时间选择器,支持查看相对时间,支持自动更新
  • 优化故障现场链路页面描述,使信息显示更清晰

缺陷修复

  • 修复单进程镜像覆盖JAVA_OPTIONS环环境变量失败导致无法加载探针的问题
  • 修复部分情况下无法获取 Go 语言程序的链路追踪数据的问题

其他

  • 支持对接自建的低版本 VictoriaMetrics,建议版本 v1.78 以上
  • 支持对接自建的 ClickHouse 集群(安装时配置)
  • 服务概览无数据时提示安装和排查手册
  • 提供一键安装脚本部署测试应用,验证 APO 安装结果和产品功能
  • 提供仅使用链路追踪或采集指标的安装方案

APO v0.7.0 更新:日志功能完整版发布!

· 阅读需 5 分钟

Cover 图

在 v0.6.0 版本中,APO 发布了基于 ClickHouse 开箱即用的高效日志方案,为用户提供了采集、处理和检索全量日志的基础功能。新版本在此基础上进一步强化了日志处理和检索的能力,提升了用户体验。

支持为不同日志设置不同的解析规则,提取出关键信息并加速检索

日志中往往存在许多关键信息,将这些关键信息提取出来能够针对性的检索数据,通过分析此类关键信息能够发现平时难以注意到的洞察。通常不同的应用在输出日志时,会采用不同的日志格式,要从日志中提取关键信息,需要能够针对应用和日志格式设置解析规则。

新版本中用户可以根据不同的日志格式设定自定义解析规则,从日志内容中提取出关键字段,例如从 Nginx 日志中解析出用户IP地址、访问路径、响应状态码等信息。通过设置解析规则,APO 能够将这些关键信息独立展示,这不仅加速了检索过程,还提高了数据的准确性和相关性。

1 图

支持对接外部日志表,在同一个平台中查看不同数据源

用户通常需要处理来自多个系统和平台的日志数据。APO 新版本支持对接外部日志表,使用户能够在同一平台上查看和分析不同来源的数据。这一功能简化了数据整合流程,消除了多平台切换的繁琐,提高了管理效率和协作能力。

2 图

支持全文检索和查看日志上下文

全文检索功能使用户能够迅速定位具体信息,而查看日志上下文的能力则为用户提供了更全面的事件背景。这对于问题排查和事件分析尤为重要,用户可以更清晰地理解问题的复杂性,快速制定解决方案,从而提高系统的稳定性和可靠性。

3 图

4 图

增强对 Go 语言程序的兼容性

此外,该版本使用 Grafana Beyla 探针替换了 opentelemetry-go-instrumentation 探针,增强对 Go 语言程序的兼容性。Grafana Beyla 能够无侵入性地采集 Go 语言程序的链路追踪数据,APO 集成并增强了该探针,使各类数据能够无缝集成,保证不同语言程序间体验的一致性。 注意 Grafana Beyla 仅支持运行在满足以下条件的内核中:

  • Linux 内核 5.8 及以上版本并且开启了 BTF 内核编译选项;通常 5.14 及以上版本已经默认开启
  • RedHat Enterprise Linux 4.18 kernels build 348 及以上,包括 CentOS, AlmaLinux 和 Oracle Linux

更多变化请查看下述更新列表。

新增功能

  • 日志功能支持为不同的应用配置不同的日志解析规则
  • 支持对接外部 ClickHouse 日志表,在同一个平台中查看不同日志数据源

功能优化

  • 采用 Beyla 替换 openTelemetry-go-instrument 探针,优化对 Go 语言程序的兼容性
  • 优化 OneAgent 的内存开销

缺陷修复

  • 修复 apo-backend 非持久化配置下 SQLite 创建数据库文件失败的问题
  • 修复 ClickHouse 中全量日志数据无法配置副本的问题
  • 修复响应时间90分位数查询失败的问题
  • 修复多实例情况下日志错误数查询失败的问题

APO介绍:

国内开源首个 OpenTelemetry 结合 eBPF 的向导式可观测性产品

apo.kindlingx.com

https://github.com/CloudDetail/apo