Grafana vs Kibana：从数据源到故障调查，怎么选更合适

订单服务突然变慢，延迟曲线在 Prometheus，错误日志在 Elasticsearch。值班同事已经知道异常发生在哪个服务，却还要在两个页面之间复制时间、环境和请求标识。Grafana 与 Kibana 的差别，就从这一步开始显现。

已有几个稳定运行的数据后端，主要麻烦是查询入口分散，Grafana 很自然。日志和其他遥测已经进入 Elasticsearch，平时就在 Discover 和 Elastic 应用中调查，继续用 Kibana 往往更省事。两者也可以共用 Elasticsearch，没有必要先把现有系统推倒。

观测云编辑部 · 资料核对于 2026-10-21。下文用订单超时说明查询与维护方式，未进行双方性能测试；托管服务与自管理软件分别讨论。

图表打开以后，数据仍在哪里

Grafana 通过数据源插件查询 Prometheus、Elasticsearch、Loki、SQL 等后端，日志仍由相应后端保存。Kibana 的常规工作流则围绕 Elasticsearch 中的数据展开，Discover 用于检索，Lens 和其他应用继续做分析。Grafana 不是日志仓库，Kibana 也不会因为界面安装完成就开始接收全部业务数据。

这也影响故障调查的范围。Grafana 可以把不同后端的数据呈现在同一入口，查询语义却仍属于各自的数据源；Kibana 中的指标和日志可以沿 Elastic 的字段与应用继续分析，前提是它们已经正确接入。完整 APM 还需要追踪采集、存储与关联配置。Grafana Cloud 有托管组合，Elastic 有 APM/OTel 接入，不能把这些能力都算作两个界面本身已经具备。

Grafana 的 Elasticsearch 数据源可以查询指标和日志。因此，“用了 Elasticsearch 就只能选 Kibana”并不成立。反过来，换成 Grafana 也不会替团队接管 Elasticsearch 的容量、映射或备份。

Prometheus 接入：直接查与再采一份的区别

Grafana 内置的 Prometheus 数据源直接向查询 API 发请求。已有 PromQL 和 recording rules 可以继续围绕原来的指标后端工作，不必为了展示数据先搬家。

Kibana 的常规路径不同。Elastic 的 Prometheus 集成支持采集 exporter 指标、接收 Prometheus remote_write，以及通过 PromQL 查询采集结果。这些是把指标接入 Elastic 的方式，不能理解成 Kibana 拥有一个与 Grafana 相同的外部 Prometheus 查询面板，也不要把 remote_write 发往任意 Elasticsearch HTTP 地址。

如果指标仍以 Prometheus 为准，只为了复刻一张看板就新增第二套存储，往往会引出采样周期、字段映射、保留期和账单问题。若团队本来就希望将日志与指标放进同一套 Elastic 分析流程，第二份数据也可能有实际价值。关键是说清楚它解决了哪一步调查，而不是单纯减少一个浏览器标签页。

从订单延迟找到错误日志

先假设 Prometheus 中的订单延迟上升，Elasticsearch 中存在订单服务日志。在 Grafana 中，值班人员可以从延迟面板缩小时间范围，再通过配置好的数据链接进入对应服务的日志。链接应传递服务名、环境和时间范围；有 Trace ID 时，还可以指向相应追踪后端。

这条路最容易卡在字段上：指标叫 service="orders"，日志却只有容器名；一个系统记录毫秒，另一个显示秒。把图表摆在一起不会修复这些差异。先统一服务和环境标识，再确认日志与链路中的请求标识，关联才有意义。

在 Kibana 中，可以从 Discover 按时间、服务、版本和错误字段筛选，用 Lens 看异常集中在哪一组实例；已接入 Elastic APM 时，再检查失败请求与下游调用。这条路径沿用 Elastic 的字段和应用，但仍依赖完整的采集、映射和权限。没有追踪数据，日志搜索也不会自动还原一次请求的全部调用。

看板能画出来，不代表查询和告警已经等价

Grafana 保留各数据源的查询语言：PromQL、LogQL、SQL 等不会因为出现在同一看板里就变成同一种计算。Kibana 的 KQL仅负责筛选，不负责聚合、转换或排序。需要统计或处理结果时，应选择 Lens、ES|QL 或其他适用的 Elasticsearch 查询能力。

例如迁移一张“支付失败率”图，两边都画出 2% 的曲线，也可能一个算的是请求，另一个算的是日志条数。重试会增加日志条数，时间窗口和空值处理也会改变结果。图例相同并不足以说明指标已经迁好，原来那条告警想捕获的失败才是需要保留的东西。

告警还要单独处理。Grafana-managed 告警在后端评估，只支持符合要求的数据源插件；浏览器里的面板变换或看板变量不能直接当成告警可用性的证明。无数据、查询失败和恢复通知也应分别设计。

Kibana 告警的规则与连接器同样有部署和订阅边界。Classic Alerting 与 Universal Alerting 是不同文档体系，配置时要对应实际使用的系统。评估间隔还受任务容量影响，不是严格实时保证。多团队共享时，再用普通角色验证底层数据访问；管理员能打开面板，不等于权限隔离已完成。

许可与成本要看具体发行方式

Grafana OSS 采用 AGPLv3，Enterprise 和 Cloud 有各自商业条款。Elastic 的情况不能只用一句“7.11 后不再开源”概括：2021 年的 7.11 转向 SSPL/ELv2；2024 年又为 Elasticsearch 与 Kibana 的免费源码部分增加 AGPLv3 选项，默认发行包仍采用 ELv2。源码许可与付费功能权益是两个问题，部署时应核对实际版本、文件许可和订阅范围。Elastic 许可说明。

算成本时，把数据后端放回账单里。自托管 Grafana 需要计算指标、日志和追踪存储的容量与运维；自管理 Elastic Stack 需要计算 Elasticsearch 集群和所需订阅。托管服务则要分别核对 Grafana Cloud、Elastic Cloud Hosted 或 Serverless 的用量与保留口径，不能拿一个界面的免费价格比较一整套托管平台。

原有后端已经稳定、看板也有人维护时，换一个入口的收益可能只是少切几次页面；如果每天都要跨源追查请求，这些重复操作才可能值得集中处理。备份、升级、商业插件和跨区传输仍会产生费用。数据量、保留时间或权限范围不同，演示时的查询速度与报价就不能直接比较。

哪个入口更值得留下

Prometheus、Elasticsearch 等后端都已经用顺，常见问题只是入口分散，Grafana 更适合延续这套系统。把服务字段、时间范围和跳转配置好，通常比为了统一界面再搬一次数据更直接。

日常调查主要发生在 Elasticsearch 内部，团队已经积累了查询、映射、权限和告警，Kibana 更容易把这些经验继续用下去。换成另一套界面不会自动降低底层集群的维护成本。

两种任务同时存在时，共用 Elasticsearch、保留两个入口也是合理方案。最终应保留的是能帮助值班人员把问题查到底的路径，而不是为了工具数量更少而重新建设一套数据管道。

使用观测云时，关联仍依赖字段

同样的字段问题也会影响观测云中的关联。其链路详情页提供关联日志等入口，能够减少反复复制请求标识的操作；日志、链路和关联字段仍须先正确采集。换了调查入口，数据缺口不会自动消失。