基于AI的OpenTelemetry分析

🚀 将您的可观测性数据转化为可操作的情报

不再淹没在仪表板中。开始与您的遥测数据进行对话。

现代应用程序通过OpenTelemetry生成大量的可观测性数据——追踪、指标和日志，这些数据包含了每一个运营问题的答案。但找到这些答案需要导航复杂的查询语言，构建自定义仪表板，并手动关联不同数据类型中的信号。

如果您可以直接提问呢？

这个MCP服务器弥合了AI助手与您的OpenTelemetry数据之间的差距，使您能够以自然语言与整个可观测性堆栈进行交互：

• “显示支付服务在过去一小时内出现的所有错误” - AI查询您的追踪和日志，发现您可能忽略的模式。
• “为什么结账服务变慢了？” - 获得即时的延迟模式、瓶颈和异常分析。
• “昨天下午2点到3点之间我的系统发生了什么变化？” - 比较指标，识别异常，并跨服务关联事件。
• “找出身份验证失败的根本原因” - 让AI跟踪分布式系统中的错误传播。

📡 什么是OpenTelemetry？

OpenTelemetry (OTEL) 是一个行业标准框架，用于从您的应用程序收集和管理遥测数据。它提供了一种供应商中立的方式来对应用程序进行工具化、生成、收集和导出遥测数据。

可观测性的三大支柱

OpenTelemetry捕获三种基本类型的遥测数据：

追踪

• 追踪请求在分布式系统中的流动过程
• 展示交易在整个多个服务中的完整旅程
• 包括每个步骤的时间、状态和上下文信息
• 示例：跟随用户从前端→购物车服务→支付服务→通知服务的结账流程

指标

• 随时间变化的系统行为的数值测量
• 包括计数器、量表和直方图
• 跟踪资源使用情况、业务关键绩效指标(KPI)和性能指标
• 示例：CPU使用率、请求延迟百分位数、每分钟销售的商品数量

日志

• 结构化的离散事件记录
• 包括时间戳、严重级别和上下文属性
• 可以与追踪和指标相关联，以获得完整的上下文
• 示例：错误消息、审计轨迹、调试信息

为什么OpenTelemetry重要

传统的监控工具经常将您锁定在专有格式中。OpenTelemetry打破了这些孤岛，通过以下方式：

1. 供应商中立性：一次收集，发送到任何地方——适用于Elasticsearch、OpenSearch、Jaeger、Prometheus等。
2. 统一收集：所有遥测类型的单一工具化。
3. 自动上下文：内置的追踪、指标和日志之间的关联。 4.. 行业标准：由云原生计算基金会支持。

这个服务器如何增强OpenTelemetry

虽然OpenTelemetry解决了数据收集的问题，但分析这些数据仍然需要专业知识。这个MCP服务器使您的OpenTelemetry数据变得可以对话：

• 无需查询语言：用简单的英语提问，而不是编写复杂的查询。
• 跨信号关联：AI自动关联追踪、指标和日志。
• 模式识别：发现您可能忽视的异常和趋势。
• 上下文理解：AI理解服务关系和依赖。

了解更多：

• OpenTelemetry 文档
• OTEL 收集器配置
• 应用工具化
• OpenTelemetry 演示应用

💡 为什么这很重要

传统的可观测性工具擅长收集和存储数据，但仍需要人类专业知识来提取见解。通过将AI直接连接到您的遥测数据，您可以获得：

即时事件响应

当凌晨三点发生故障时，您没有时间去构建复杂的查询。让AI用自然语言调查错误模式，跟踪系统中的故障，并确定根本原因。

主动问题检测

无需设置数百个静态警报，让AI持续分析您的数据以查找异常。询问诸如“今天的流量中是否有任何不寻常的模式？”等问题，并基于历史基线获得智能分析。

民主化的可观测性

您的团队中并非每个人都是查询专家。有了自然语言访问，开发人员、SRE和产品经理都可以探索系统行为，而无需学习复杂的查询语言。

上下文感知开发

在审查代码或设计功能时，开发人员可以立即检查类似代码在生产中的表现，它产生的错误以及它如何影响系统性能。

🎯 实际案例

在事件期间

• “查找所有带有错误的身份验证流追踪”
• “显示过去30分钟内服务依赖失败”
• “哪些服务正在经历升高的延迟？”

性能分析

• “识别结账服务中最慢的操作”
• “比较今天的CPU使用情况与上周的基线”
• “查找购物车服务中的内存泄漏”

系统理解

• “绘制所有服务依赖关系”
• “展示订单处理的关键路径”
• “哪些服务与支付网关通信？”

异常检测

• “查找过去一小时内的异常日志模式”
• “检测所有服务中的度量异常”
• “显示今天开始出现的罕见错误消息”

🛠️ 它是如何工作的

此服务器实现了模型上下文协议（MCP），为AI助手提供了与存储在Elasticsearch/OpenSearch中的OpenTelemetry数据进行结构化交互的接口。当您提出一个问题时，AI：

1. 理解您的意图并识别相关的数据类型（追踪、指标或日志）。
2. 使用提供的工具构建适当的查询。
3. 分析结果并以自然语言呈现见解。
4. 可以执行后续查询以深入研究问题。

⚡ 快速入门

对于Windsurf/Claude桌面用户

在您的MCP设置中添加以下内容：

{
  "mcpServers": {
    "otel-mcp-server": {
      "command": "npx",
      "args": ["-y", "otel-mcp-server"],
      "env": {
        "OPENSEARCH_URL": "http://localhost:9200",
        "USERNAME": "elastic",
        "PASSWORD": "changeme",
        "OPENAI_API_KEY": "sk-..."  // 可选：用于ML功能
      }
    }
  }
}

注意：您可以使用ELASTICSEARCH_URL或OPENSEARCH_URL中的任何一个——两者都适用。

对于开发人员

# 克隆并安装
git clone https://github.com/ryanwith/melchi.git
cd melchi
npm install

# 配置您的连接
cp .env.example .env
# 编辑.env以包含您的Elasticsearch详细信息

# 构建并运行
npm run build

# 使用直接node命令运行dist/server.js集成到您的MCP客户端

📊 可用功能

查询工具

• 直接查询：执行针对追踪、指标和日志的Elasticsearch查询。
• 服务发现：列出并搜索系统中的服务。
• 字段发现：使用通配符支持探索可用字段（例如，“.error”，“span.”）。

分析工具

• 异常检测：在指标、追踪和日志模式中查找异常值。
• 服务拓扑及依赖映射：
  • 从OpenTelemetry跨度父子关系中发现服务关系。
  • 每个依赖的详细延迟统计（平均值、最小值、最大值、p50、p95、p99）。
  • 每个服务连接的成功率和错误率。
  • 服务间的吞吐量指标（每分钟调用次数）。
  • 可视化准备的数据，包括节点大小、边缘宽度和颜色编码。
  • 自动识别关键服务和瓶颈。
• 时间序列分析：检测指标的趋势、季节性和异常。
• 健康总结：获取即时系统健康报告，识别瓶颈。

关联工具

• 错误传播：跟踪分布式系统中的错误。
• 事件分析：在停机期间关联日志、指标和追踪。
• 性能剖析：识别缓慢的操作和资源瓶颈。

🔧 示例交互

分析服务依赖

您： "显示具有高延迟的服务依赖关系"

AI： 我将分析服务依赖及其性能指标。

[AI 执行依赖分析并返回]：
找到了15个服务依赖关系。以下是关键的几个：

1. checkout-service → payment-service
   - 平均延迟：450毫秒（第95百分位：1200毫秒）
   - 错误率：2.3%
   - 调用量：每分钟1,250次调用
   
2. frontend → recommendation-service  
   - 平均延迟：890毫秒（第95百分位：2100毫秒）
   - 错误率：0.5%
   - 调用量：每分钟3,400次调用
   - ⚠️ 这是一个瓶颈——高延迟影响用户体验

推荐服务是主要瓶颈，其第95百分位延迟超过2秒。

查找性能问题

您： "为什么今天的结账服务变慢了？"

AI： 我将分析结账服务的性能。让我：
1. 检查延迟异常
2. 识别缓慢的操作
3. 查找错误模式

[AI 执行查询并返回]：
结账服务在支付处理操作上经历了三倍于正常水平的延迟。
这种情况从下午2:15开始，并与来自支付网关的错误率增加相关。
该服务在5秒后超时，导致级联故障。

调查错误

您： "查找过去一小时内的所有身份验证失败"

AI： 我将在日志和追踪中搜索身份验证失败。

[AI 执行查询并返回]：
在过去一小时内发现了847个身份验证失败：
- 92%是来自移动应用（v2.3.1）的“无效令牌”错误
- 失败每15分钟激增一次，表明存在令牌刷新问题
- 所有失败都源自三个特定的API端点
- 这种模式始于下午1:30的部署后

🌟 关键优势

调查速度

• 将MTTR从数小时减少到数分钟
• 不需要在多个工具间切换上下文
• 数据类型之间的即时关联

入门门槛低

• 新团队成员可以立即调查问题
• 不需要查询语言专业知识
• 唯一需要的界面就是自然语言

主动洞察

• AI可以发现人类可能忽略的模式
• 没有人工干预的持续分析
• 历史比较和趋势检测

统一界面

• 整个调查过程只需一个对话线程
• 不需要在仪表板之间跳转
• 分析过程中上下文得以保存

🚀 使用真实数据开始

使用OpenTelemetry演示

使用真实的微服务数据测试：

# 使用Kubernetes部署OTEL演示
kubectl create namespace otel-demo
helm install demo open-telemetry/opentelemetry-demo -n otel-demo --values demo/otel-demo-values.yaml

# 端口转发OpenSearch
kubectl port-forward -n elastic svc/opensearch 9200:9200

# 使用以下环境变量启动您的MCP客户端：
# OPENSEARCH_URL=http://localhost:9200

尝试这些查询

一旦连接，探索您的数据：

• “显示所有可用服务”
• “查找前端服务中的错误”
• “分析结账服务的延迟模式”
• “检测CPU使用情况的异常”
• “映射具有延迟指标的服务依赖关系”
• “显示最慢的服务连接”
• “哪些服务具有最高的错误率？”
• “识别服务拓扑中的瓶颈”

📚 高级功能

基于ML的分析（需要OpenAI API密钥）

• 语义日志搜索：使用嵌入查找相似的错误模式
• 自动追踪聚类：将相似的问题分组在一起
• 时间序列预测：预测未来的度量趋势

要启用ML功能，请设置OPENAI_API_KEY环境变量。

智能关联

• 自动关联追踪、指标和日志
• 带有错误传播分析的服务依赖跟踪
• 分布式事务中的根本原因分析

灵活部署

• 适用于Elasticsearch 7.x/8.x和OpenSearch
• 支持OTEL和ECS映射模式
• 自动适应可用的数据类型

🤝 贡献

我们欢迎贡献！最大的贡献是尝试它，并根据贡献指南提交问题。对于直接贡献，无论是添加新的分析工具、改进查询能力还是增强文档，您的意见有助于使可观测性对所有人来说更加容易获取。

📄 许可证

MIT许可证 - 为OpenTelemetry社区打造，充满爱心

---

准备好改变您与可观测性数据互动的方式了吗？ 今天就开始与您的遥测数据进行对话吧。