AI驱动的开放遥测分析
🚀 将您的可观察性数据转化为可操作的智能
不要沉迷于仪表板。开始与遥测数据进行对话。
现代应用程序通过OpenTetry生成大量的可观察性数据——跟踪、指标和日志，其中包含每个操作问题的答案。但要找到这些答案，需要导航复杂的查询语言，构建自定义仪表板，并手动关联不同数据类型的信号。
如果你能问问呢？
此MCP服务器弥合了AI助手和您的OpenTetry数据之间的差距，使您能够与整个可观测性堆栈进行自然语言交互：
- “显示最近一小时付款服务中的所有错误” -AI会查询你的痕迹和日志，找到你可能错过的模式
- “为什么结账服务很慢？” -即时分析延迟模式、瓶颈和异常
- “昨天下午2点到3点之间，我的系统发生了什么变化？” -比较指标，识别异常，并跨服务关联事件
- “查找身份验证失败的根本原因” -让AI跟踪错误在分布式系统中的传播
📡 什么是开放遥测？
开放遥测 （OTEL）是用于收集和管理应用程序遥测数据的行业标准框架。它提供了一种与供应商无关的方式来检测、生成、收集和导出遥测数据。
可观察性的三大支柱
OpenTetry捕获三种基本类型的遥测数据：
- 跟踪请求在分布式系统中的流动
- 显示跨多个服务的交易的完整过程
- 包括每个步骤的时间、状态和上下文信息
- 示例：从前端遵循用户的结账流程→ 购物车服务→ 支付服务→ 通知服务
- 系统行为随时间变化的数值测量
- 包括计数器、仪表和直方图
- 跟踪资源使用情况、业务KPI和绩效指标
- 示例：CPU使用率、请求延迟百分比、每分钟售出的物品
- 离散事件的结构化记录
- 包括时间戳、严重性级别和上下文属性
- 可以与跟踪和指标相关联，以获得完整的上下文
- 示例：错误消息、审核跟踪、调试信息
为什么开放遥测很重要
传统的监控工具通常会将您锁定在专有格式中。OpenTetry通过以下方式打破了这些孤岛：
- 供应商中立性：收集一次，发送到任何地方-与 弹性搜索, 开放搜索, 猎手, 普罗米修斯，以及更多
- 统一收藏：所有遥测类型的单一仪器
- 自动上下文：跟踪、指标和日志之间的内置相关性
- 行业标准：由 云原生计算基础
此服务器如何增强OpenTetry
虽然OpenTetry解决了数据收集问题，但分析这些数据仍然需要专业知识。此MCP服务器使您的OpenTetry数据具有对话性：
- 无需查询语言：用简单的英语提问，而不是写复杂的问题
- 交叉信号相关性：AI自动关联跟踪、指标和日志
- 模式识别：手动发现可能遗漏的异常和趋势
- 情境理解：AI理解服务关系和依赖关系
了解更多：
💡 为何这很重要
传统的可观察性工具擅长收集和存储数据，但它们仍然需要人类的专业知识来提取见解。通过将AI直接连接到遥测数据，您可以获得：
即时事件响应
当凌晨3点发生故障时，您没有时间处理复杂的查询。让人工智能调查错误模式，跟踪系统中的故障，并确定根本原因——所有这些都是用自然语言完成的。
主动问题检测
与其设置数百个静态警报，不如让AI不断分析您的数据以发现异常。提出诸如“当今交通中是否存在任何异常模式？”之类的问题，并根据历史基线进行智能分析。
民主观察
并非团队中的每个人都是查询专家。通过自然语言访问，开发人员、SRE甚至产品经理都可以在不学习复杂查询语言的情况下探索系统行为。
情境感知开发
在审查代码或设计功能时，开发人员可以立即检查类似代码在生产中的表现、产生的错误以及对系统性能的影响。
🎯 真实世界用例
事故期间
- “查找身份验证流程中所有有错误的痕迹”
- “显示过去30分钟内的服务依赖性故障”
- “哪些服务正在经历延迟增加？”
性能分析
- “确定结账服务中最慢的操作”
- “将今天的CPU使用率与上周的基线进行比较”
- “在购物车服务中查找内存泄漏”
系统理解
- “绘制所有服务依赖关系”
- “显示订单处理的关键路径”
- “哪些服务与支付网关通信？”
异常检测
- “查找过去一小时的异常日志模式”
- “检测所有服务中的指标异常”
- “显示今天开始出现的罕见错误消息”
🛠️ 运作原理
此服务器实现了模型上下文协议（MCP），为AI助手提供了一个结构化的接口，用于存储在Elasticsearch/OpenSearch中的OpenTetry数据。当你问一个问题时，AI：
- 了解您的意图并识别相关数据类型（跟踪、指标或日志）
- 使用提供的工具构造适当的查询
- 分析结果并提供自然语言见解
- 可以执行后续查询以更深入地了解问题
⚡ 快速开始
适用于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-..." // 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。*")
分析工具
- 异常检测：查找指标、跟踪和日志模式中的异常值
- 服务拓扑和依赖关系映射:
- 从OpenTetry跨父子关系中发现服务关系 - 每个依赖项的详细延迟统计数据（平均值、最小值、最大值、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从小时减少到分钟
- 无需在多个工具之间进行上下文切换
- 跨数据类型的即时相关性
较低的进入门槛
- 新团队成员可以立即调查问题
- 不需要查询语言专业知识
- 自然语言是唯一需要的接口
主动洞察
- 人工智能可以发现人类可能错过的模式
- 无需人工干预的连续分析
- 历史比较和趋势检测
统一接口
- 整个调查的一个对话线索
- 无需在仪表板之间切换
- 整个分析过程中保留了上下文
🚀 开始使用真实数据
使用OpenTetry演示
使用真实的微服务数据进行测试：
# 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尝试这些查询
连接后，探索您的数据：
- “显示所有可用服务”
- “查找前端服务中的错误”
- “分析结账服务延迟模式”
- “检测CPU使用率异常”
- “用延迟指标映射服务依赖关系”
- “显示最慢的服务连接”
- “哪些服务的错误率最高？”
- “识别服务拓扑中的瓶颈”
📚 高级功能
ML-动力分析（需要OpenAI API密钥）
- 语义日志搜索：使用嵌入查找类似的错误模式
- 自动跟踪聚类：将类似问题归为一组
- 时间序列预测：预测未来指标趋势
要启用ML功能，请设置 OPENAI_API_KEY 环境变量。
智能关联
- 自动关联跟踪、指标和日志
- 使用错误传播分析进行服务依赖性跟踪
- 跨分布式事务的根本原因分析
灵活部署
- 适用于Elasticsearch 7.x/8.x和OpenSearch
- 支持OTEL和ECS映射模式
- 自动适应可用的数据类型
🤝 贡献
我们欢迎捐款！最大的贡献是尝试一下，并根据贡献指南提交问题。对于直接贡献，无论是添加新的分析工具、改进查询功能还是增强文档，您的输入都有助于使每个人都能更容易地访问可观察性。
📄 许可证
MIT许可证-使用❤️ OpenTelemetry社区
______________________________________________________________________
准备好改变您与可观察性数据的交互方式了吗？ 今天就开始与你的遥测技术进行对话。