AIOps 生产实战：基于 LLM 与 OpenTelemetry 的故障根因自动诊断系统 (0801版)

AIOps 生产实战基于 LLM 与 OpenTelemetry 的故障根因自动诊断系统 (0801版)在微服务架构普及的今天一次简单的数据库慢查询可能会沿着 RPC 调用链迅速扩散引发上游数十个微服务的超时告警。值班运维工程师面对瞬间涌入的数百条告警短信和漫天飞舞的日志往往需要花费数十分钟甚至数小时去排查最底层的根因。许多团队尝试引入大语言模型LLM来辅助排障但直接把原始日志塞给模型通常效果很差。模型容易产生幻觉或者因为上下文超长而遗漏关键报错。本文分享一套在生产环境落地的 AIOps 诊断系统核心思想是用 OpenTelemetry 完成确定性的数据拓扑提取再用有限状态机和校验器去治理 LLM 的推理过程。一、排障痛点与系统整体架构传统告警治理的最大痛点在于数据孤岛。指标Metrics告诉你系统慢了日志Logs记录了具体的报错信息而链路追踪Traces展现了调用的上下游关系。排障时运维人员需要在 Grafana、Kibana 和 Jaeger 三者之间频繁切换视角。为了让 LLM 能够精准定位根因我们不能依赖随机的 Prompt必须为模型提供具备拓扑约束的上下文数据。以下是系统的整体数据流与诊断逻辑整个架构包含三个核心要素数据准备通过 OpenTelemetry Collector 聚合 TraceID 相关的异常 Span 和上下文 Logs。状态机控制限制 LLM 的诊断步骤强制其按照“现象提取 - 拓扑路径分析 - 异常特征比对 - 结论输出”的顺序思考。结构化闸门对模型的输出进行强类型 JSON 标准校验一旦格式畸形或逻辑自相矛盾立即触发重试或降级。二、拓扑数据提取与结构化 Prompt 组装排障的第一步是把模糊的告警转化为具体的图结构。我们通过 OpenTelemetry Go SDK 提取异常链路上的关键节点。下面的代码演示了如何从 OpenTelemetry 导出的 Trace 结构中抽取延迟最高和包含StatusCodeError的微服务节点及其上下文日志。package aiops import ( context fmt sort time ) type SpanData struct { SpanID string json:span_id ParentSpanID string json:parent_span_id ServiceName string json:service_name OperationName string json:operation_name DurationMs int64 json:duration_ms HasError bool json:has_error Attributes map[string]string json:attributes Logs []string json:logs } type TraceTopology struct { TraceID string json:trace_id RootService string json:root_service CriticalPath []SpanData json:critical_path } // ExtractCriticalPath 提取异常调用链上的关键节点过滤无关的正常 Span func ExtractCriticalPath(spans []SpanData) *TraceTopology { if len(spans) 0 { return nil } var anomalySpans []SpanData for _, s : range spans { if s.HasError || s.DurationMs 500 { anomalySpans append(anomalySpans, s) } } sort.Slice(anomalySpans, func(i, j int) bool { return anomalySpans[i].DurationMs anomalySpans[j].DurationMs }) limit : 5 if len(anomalySpans) limit { limit len(anomalySpans) } return TraceTopology{ TraceID: spans[0].Attributes[trace_id], RootService: spans[0].ServiceName, CriticalPath: anomalySpans[:limit], } }提取出TraceTopology后我们使用严格的 System Prompt 约束大模型。不要让模型做自由创作而是要求它以 JSON 格式输出根因诊断结果。三、确定性防御Schema 校验与自动修复机制大模型在处理复杂文本时偶尔会返回非标准的 JSON。我们采用 Python 实现了一个带有自动修复Auto-repair功能的 LLM 调用保护层import json import re from typing import Dict, Any, Optional def parse_and_validate_llm_response(raw_text: str) - Optional[Dict[str, Any]]: cleaned_text raw_text.strip() try: data json.loads(cleaned_text) if validate_schema(data): return data except json.JSONDecodeError: pass json_match re.search(r(?:json)?\s*(\{.*?\})\s*, cleaned_text, re.DOTALL) if json_match: try: data json.loads(json_match.group(1)) if validate_schema(data): return data except json.JSONDecodeError: pass return None def validate_schema(data: Dict[str, Any]) - bool: required_keys [root_cause_service, confidence_score, suspected_reason, suggested_action] return all(key in data for key in required_keys)四、生产落地的边界条件与 Trade-offs上下文长度与成本控制微服务场景下的 Trace 数据量巨大必须在 Collector 端做前端预聚合仅挑选耗时异常点和带有 Error 标记的边缘节点。避免将模型结论作为自动止损依据AI 诊断给出的建议可以用来生成排障卡片并推送到钉钉/飞书告警群但决不能直接挂载自动重启脚本。日志脱敏与安全隔离日志中往往包含敏感字段在送入外部 API 之前必须完成掩码脱敏。五、总结通过 OpenTelemetry 建立确定的数据拓扑用状态机约束推理步骤再配上代码层面的 Schema 校验防线就能在非确定性的 AI 能力与要求绝对稳定的生产系统之间搭建起一条安全可靠的自动化排障流水线。