Grafana Labs 已将 Grafana Assistant 的查询能力扩展到 30 多种数据源。变化的重点不只是“支持列表变长”，而是让 AI 助手可以通过自然语言跨数据源查询并关联信息：工程师不必在指标、日志、追踪和事件页面之间反复切换，而可以从一个故障问题出发，逐步收集证据。
从查询一种数据，走向关联多个信号
传统排障经常沿着固定路径展开：先看监控指标确认异常时间，再检索日志寻找错误，随后打开追踪系统定位慢调用，最后检查部署或事件记录。每一步都可能使用不同的数据源、查询语言和标签体系。
当助手能够访问 30 多种数据源后，自然语言可以成为这些查询入口之上的统一交互层。例如，值班工程师可以提出这类问题：
找出过去 30 分钟结账服务延迟升高的时间段，并关联同一时间范围内的错误日志和异常请求链路。
这里真正困难的不是生成一句查询语句，而是完成三个动作：
- 识别“结账服务”在不同数据源中的名称、标签或资源属性；
- 将指标异常映射到准确的时间窗口；
- 使用该窗口和服务标识继续检索日志、追踪或其他运维数据。
因此，数据源数量只是能力边界的一部分。跨系统的命名一致性、时间对齐和访问权限，才决定关联结果是否可靠。
自然语言不会自动修复数据质量
AI 助手降低了查询门槛，但无法替代可观测性治理。如果指标使用 service="checkout"，日志写入 app="checkout-api"，追踪数据却记录 service.name="payment-web"，助手就很难稳定判断它们是否属于同一个服务。
团队在引入跨数据源问答前，至少应检查以下基础约定：
- 服务名称是否在指标、日志和追踪中保持一致；
environment、cluster、namespace、region等关键维度是否统一；- 时间戳、时区和数据保留期是否满足关联分析需要；
- 数据源账号是否遵循最小权限原则；
- 敏感日志、客户标识和安全事件是否允许进入 AI 辅助工作流。
还要注意，自然语言回答适合帮助工程师形成调查路径，不应天然被视为最终事实。缺失数据、错误标签、采样策略和查询时间范围都可能改变结论。对于生产事故，关键判断仍应回到原始面板、查询结果和变更记录进行核验。
可以这样实践：先盘点 Grafana 数据源
下面的示例使用 Grafana HTTP API 列出当前实例中的数据源，并按类型统计数量。它不调用 Grafana Assistant，也不代表助手的内部 API；它是一段可以用于接入前盘点的实践脚本。
运行前设置 Grafana 地址和具有读取权限的 Service Account Token：
export GRAFANA_URL="https://grafana.example.com"
export GRAFANA_TOKEN="glsa_your_service_account_token"
curl --fail --silent --show-error \
--header "Authorization: Bearer ${GRAFANA_TOKEN}" \
"${GRAFANA_URL}/api/datasources" \
| jq -r 'group_by(.type)[] | "\(length)\t\(.[0].type)"' \
| sort -nr
如果环境中还没有 jq，可在 Debian 或 Ubuntu 上安装：
sudo apt-get update
sudo apt-get install -y jq
还可以只输出适合审计的字段，避免把数据源配置中的其他内容带入工单或日志：
curl --fail --silent --show-error \
--header "Authorization: Bearer ${GRAFANA_TOKEN}" \
"${GRAFANA_URL}/api/datasources" \
| jq '[.[] | {
name,
type,
uid,
access,
isDefault
}]'
不要把令牌写入仓库或命令历史。生产环境可以通过 CI 密钥、临时环境变量或组织已有的密钥管理系统注入凭据，并为盘点任务使用只读账号。
把问题写成可验证的调查步骤
自然语言提示越具体，跨数据源关联越容易验证。可以把提问组织为“对象、范围、基线、证据、输出”五部分：
对象：production 环境中的 checkout-api 服务
时间范围：过去 45 分钟
基线：与过去 7 天同一时段比较
调查步骤：
1. 找出 p95 延迟和 5xx 错误率同时上升的时间窗口。
2. 在这些窗口中检索相同 service.name、cluster 和 namespace 的错误日志。
3. 查找持续时间最长或包含错误状态的请求链路。
4. 分开列出观察到的事实、推测以及缺失的数据。
输出：给出每条结论对应的数据源、时间范围和可复查条件。
这类提示不会保证回答正确，但能减少范围漂移，并强制输出可检查的证据。对于高风险操作，还应明确要求助手只读查询，不执行告警修改、数据源变更或生产操作。
采用时先从只读排障开始
更稳妥的落地方式，是选择一个标签规范较完整的服务和一组只读数据源，使用历史事故复盘来检验结果。团队应记录助手能否找到正确时间窗口、是否遗漏关键证据，以及回答能否被原始查询复现。
上线前可以使用这份检查清单：
- 为 Assistant 和相关数据源配置最小读取权限；
- 统一服务名称与核心资源标签；
- 明确哪些数据不得进入 AI 查询上下文；
- 要求重要结论附带数据源、时间范围和过滤条件；
- 用已知事故建立评测集，比较答案的准确性和稳定性；
- 保留人工核验与传统查询入口。
支持 30 多种数据源扩大了 Grafana Assistant 可处理的可观测性范围，但实际价值取决于数据是否能被正确关联。自然语言可以缩短调查入口，统一的数据模型、严格的权限和可复查的证据链则决定它能否进入日常生产排障流程。