AI-Powered OpenTelemetry Analysis

AI 驱动的 OpenTelemetry 分析

🚀 将可观测性数据转化为可执行的洞察

别再被仪表板淹没。开始与遥测数据对话。

现代应用通过 OpenTelemetry 生成海量可观测性数据——包含所有运维问题答案的链路、指标和日志。但要找到这些答案，需要应对复杂的查询语言、构建自定义仪表板，还要手动关联不同类型的数据。

如果只需提问就能找到答案呢？

这个 MCP 服务连接了 AI 助手与 OpenTelemetry 数据，让你能够通过自然语言与整个可观测性技术栈交互：

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

📡 什么是 OpenTelemetry？

OpenTelemetry（OTEL）是用于收集和管理应用遥测数据的行业标准框架。它提供了一种与供应商无关的方式，用于为遥测数据添加检测、生成、收集和导出遥测数据。

可观测性的三大支柱

OpenTelemetry 可采集三种重要类型的遥测数据：

链路

• 跟踪请求在分布式系统中的流转过程
• 展示事务经过多个服务的完整过程
• 包含每个步骤的耗时、状态和上下文信息
• 示例：跟踪用户的结账流程，从前端 → 购物车服务 → 支付服务 → 通知服务

指标

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

日志

• 对离散事件的结构化记录
• 包含时间戳、严重性级别和上下文属性
• 可与链路和指标关联，以提供完整上下文
• 示例：错误消息、审计记录、调试信息

OpenTelemetry 为何重要

传统监控工具往往会将你锁定在专有格式中。OpenTelemetry 打破这些数据孤岛，提供以下优势：

1. 供应商中立：采集一次，发送到任意位置——适用于 Elasticsearch、OpenSearch、Jaeger、Prometheus 等
2. 统一采集：通过一次检测即可采集所有类型的遥测数据
3. 自动关联上下文：内置链路、指标和日志之间的关联能力
4. 行业标准：由 Cloud Native Computing Foundation 支持

此服务器如何增强 OpenTelemetry

OpenTelemetry 解决了数据采集问题，但分析这些数据仍需要专业知识。此 MCP 服务让你能够以对话方式使用 OpenTelemetry 数据：

• 无需查询语言：用通俗语言提问，无需编写复杂查询
• 跨信号关联：AI 自动关联追踪、指标和日志
• 模式识别：发现你可能会在手动分析时忽略的异常和趋势
• 上下文理解：AI 能理解服务之间的关系和依赖

了解更多：

• OpenTelemetry 文档
• OTEL Collector 配置
• 为你的应用进行埋点
• OpenTelemetry 示例应用

💡 为什么这很重要

传统的可观测性工具擅长采集和存储数据，但仍需要人类专家从中提取洞见。通过将 AI 直接连接到遥测数据，你可以：

即时响应事件

凌晨 3 点发生服务中断时，你没有时间编写复杂查询。用自然语言让 AI 调查错误模式、追踪系统中的故障并找出根本原因。

主动发现问题

无需设置数百条静态警报，让 AI 持续分析数据并发现异常。你可以询问“今天的流量中有没有异常模式？”之类的问题，并获得基于历史基线的智能分析。

让更多人能够使用可观测性

团队中并非每个人都是查询专家。通过自然语言访问，开发人员、SRE 甚至产品经理都能探索系统行为，无需学习复杂的查询语言。

了解上下文的开发

在审查代码或设计功能时，开发人员可以即时查看类似代码在生产环境中的表现、产生的错误以及对系统性能的影响。

🎯 实际应用场景

处理事件期间

• “查找身份验证流程中所有出现错误的追踪”
• “显示过去 30 分钟内服务依赖故障的情况”
• “哪些服务的延迟升高了？”

性能分析

• “找出结账服务中速度最慢的操作”
• “将今天的 CPU 使用率与上周的基线进行比较”
• “查找购物车服务中的内存泄漏”

了解系统

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

异常检测

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

🛠️ 工作原理

此服务器实现了 Model Context Protocol（MCP），为 AI 助手提供结构化接口，以访问存储在 Elasticsearch/OpenSearch 中的 OpenTelemetry 数据。当你提出问题时，AI 会：

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

⚡ 快速入门

Windsurf/Claude Desktop 用户

将此内容添加到 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-..."  // Optional: for ML-powered features
      }
    }
  }
}

注意：你可以使用 ELASTICSEARCH_URL 或 OPENSEARCH_URL，两者都可用。

开发人员

# Clone and install
git clone https://github.com/ryanwith/melchi.git
cd melchi
npm install

# Configure your connection
cp .env.example .env
# Edit .env with your Elasticsearch details

# Build and run
npm run build

# Integrate with your MCP client using a direct node command to run dist/server.js

📊 可用功能

查询工具

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

分析工具

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

关联分析工具

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

🔧 交互示例

分析服务依赖关系

You: "Show me service dependencies with high latency"

AI: I'll analyze service dependencies and their performance metrics.

[AI executes dependency analysis and returns]:
Found 15 service dependencies. Here are the critical ones:

1. checkout-service → payment-service
   - Average latency: 450ms (95th percentile: 1200ms)
   - Error rate: 2.3%
   - Call volume: 1,250 calls/minute
   
2. frontend → recommendation-service  
   - Average latency: 890ms (95th percentile: 2100ms)
   - Error rate: 0.5%
   - Call volume: 3,400 calls/minute
   - ⚠️ This is a bottleneck - high latency affecting user experience

The recommendation service is your primary bottleneck, with p95 latency over 2 seconds.

查找性能问题

You: "Why is the checkout service slow today?"

AI: I'll analyze the checkout service performance. Let me:
1. Check for latency anomalies
2. Identify slow operations
3. Look for error patterns

[AI executes queries and returns]:
The checkout service is experiencing 3x normal latency on the payment-processing operation. 
This started at 2:15 PM and correlates with increased error rates from the payment gateway.
The service is timing out after 5 seconds, causing cascading failures.

调查错误

You: "Find all authentication failures in the last hour"

AI: I'll search for authentication failures across logs and traces.

[AI executes queries and returns]:
Found 847 authentication failures in the last hour:
- 92% are "invalid token" errors from the mobile app (v2.3.1)
- Failures spike every 15 minutes, suggesting a token refresh issue
- All failures originate from 3 specific API endpoints
- The pattern started after the 1:30 PM deployment

🌟 主要优势

加快调查速度

• 将 MTTR 从数小时缩短至数分钟
• 无需在多个工具之间切换上下文
• 即时关联不同类型的数据

降低使用门槛

• 新团队成员可以立即调查问题
• 无需掌握查询语言
• 只需使用自然语言即可交互

主动洞察

• AI 可以发现人类可能忽略的模式
• 无需人工干预即可持续分析
• 支持历史对比和趋势检测

统一界面

• 整个调查过程都在一个对话线程中进行
• 无需在不同仪表板之间切换
• 在整个分析过程中保留上下文

🚀 开始使用真实数据

使用 OpenTelemetry Demo

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

# Deploy the OTEL demo with Kubernetes
kubectl create namespace otel-demo
helm install demo open-telemetry/opentelemetry-demo -n otel-demo --values demo/otel-demo-values.yaml

# Port-forward OpenSearch
kubectl port-forward -n elastic svc/opensearch 9200:9200

# Start your MCP Client with the following environment variables:
# OPENSEARCH_URL=http://localhost:9200

试试这些查询

连接后，探索你的数据：

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

📚 高级功能

ML 驱动的分析（需要 OpenAI API 密钥）

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

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

智能关联

• 自动关联追踪、指标和日志
• 通过错误传播分析追踪服务依赖关系
• 跨分布式事务进行根因分析

灵活部署

• 兼容 Elasticsearch 7.x/8.x 和 OpenSearch
• 支持 OTEL 和 ECS 两种映射模式
• 自动适配可用的数据类型

🤝 参与贡献

欢迎参与贡献！最重要的贡献是试用本项目，并按照贡献指南提交问题。无论是添加新的分析工具、改进查询功能，还是完善文档，你的参与都能帮助让所有人更轻松地使用可观测性。

📄 许可证

MIT 许可证 - 为 OpenTelemetry 社区倾情打造 ❤️

---

准备好改变你与可观测性数据交互的方式了吗？ 立即开始与你的遥测数据对话。