将你的 Grafana Kubernetes 仪表板迁移到 Elastic Observability：相同的 PromQL，30 倍更快的查询

作者：来自 Elastic Peter Simkins

以一个真实的 Grafana Kubernetes 仪表板为例，涵盖 Pod CPU、内存、节点压力和重启次数等指标，然后在不到一小时内，使用原生 PromQL 将其迁移到 Elastic Observability。

Elasticsearch 现已原生支持运行 PromQL。使用 Observability Migration Platform，将一个 Grafana Kubernetes / Views / Global 仪表板迁移到 Elastic Observability。示例仪表板涵盖 Pod CPU、工作集内存（working set memory）、CPU 限流（throttling）信号以及容器重启次数。如果 Kubernetes 指标已经存储在 Elasticsearch 中，整个转换、验证和上传过程通常可以在一小时内完成。

迁移工具会保留面板查询使用 PromQL，而不是将它们改写为新的查询语言。当你传入 --validate 参数时，它会验证这些查询，并将编译后的仪表板上传到 Kibana。之后，你只需要查看迁移报告，并根据自己的计划启用告警即可。

本次迁移使用的 Grafana Kubernetes 仪表板示例

本次演示使用的是 Kubernetes / Views / Global，这是迁移仓库中的一个社区版 Grafana 仪表板。它包含了运维人员在处理故障时最常查看的指标：命名空间 CPU 和内存、CPU 限流压力，以及重启次数。

下面是源仪表板中的一些代表性 PromQL 查询：

`

1.  # Pod / container CPU by namespace
2.  sum(rate(container_cpu_usage_seconds_total{image!="", cluster="$cluster"}[$__rate_interval])) by (namespace)

`AI写代码

`

1.  # Memory working set by namespace
2.  sum(container_memory_working_set_bytes{image!="", cluster="$cluster"}) by (namespace)

`AI写代码

`

1.  # Node / CPU pressure style signal: throttled seconds
2.  sum(rate(container_cpu_cfs_throttled_seconds_total{image!="", cluster="$cluster"}[$__rate_interval])) by (namespace) > 0

`AI写代码

`

1.  # Container restart counts
2.  sum(increase(kube_pod_container_status_restarts_total{cluster="$cluster"}[$__rate_interval])) by (namespace) > 0

`AI写代码

如果这个仪表板能够顺利完成转换，那么大多数生产环境中的 Grafana Kubernetes 仪表板目录都值得使用同样的工作流进行迁移测试。

为什么现在 Grafana 到 Elastic 的迁移速度更快

迁移平台自动完成了查询转换和面板重建，而这些过去往往是 Grafana 迁移中最耗时的工作。原生支持 Prometheus Remote Write 和 Kibana 中的 PromQL，让你可以继续使用值班团队已经熟悉的查询语言。--native-promql 参数会原样保留 PromQL，而不会对其进行转换。有关存储和查询方面的更多背景信息，请参阅 将 Elasticsearch 用作指标引擎。

前提条件

你需要一个 Elastic Observability Serverless 项目、一个 项目 API Key，以及从 observability-migration-platform 仓库安装的迁移 CLI。

导出你的 endpoint 和 API Key：

`

1.  export ELASTICSEARCH_ENDPOINT="https://YOUR_ES_ENDPOINT"
2.  export KIBANA_ENDPOINT="https://YOUR_KIBANA_ENDPOINT"
3.  export KEY="YOUR_API_KEY"

`AI写代码

安装 CLI 并确认工具链：

`

1.  python3 -m venv .venv
2.  .venv/bin/pip install ".[all]"
3.  .venv/bin/obs-migrate doctor

`AI写代码

doctor 命令会检查编译和代码检查依赖。在迁移生产环境仪表板之前，请先解决所有错误。如果计划在 CI 中运行此工具，请固定一个版本标签。

如何将 Kubernetes 指标导入 Elasticsearch？

上传后出现空面板通常意味着 Elasticsearch 中还没有 PromQL 所引用的指标序列。在运行迁移之前，请确认数据已经成功摄取。

有两种常见方式：

1. 从 kube-state-metrics、cAdvisor 或 kubelet 指标以及 node exporter，通过 Prometheus Remote Write 写入 Elasticsearch。

2. 通过 Kubernetes receivers 将 OpenTelemetry 数据发送到托管 OTLP，然后在 Discover 中进行探索。

使用类似 sum(rate(container_cpu_usage_seconds_total[5m])) by (namespace) 的查询在 Elastic 中进行测试。如果返回数据，则继续执行。如果没有返回数据，请先修复数据摄取问题。

运行 Grafana 仪表板迁移 CLI

导出你的 Grafana 仪表板 JSON，或者从迁移仓库中的 infra/grafana/dashboards/ 目录复制示例 k8s-views-global.json 。将文件放入类似 ./grafana_k8s_exports/ 的目录中。

从该目录运行迁移：

`

1.  grafana-migrate \
2.    --source files \
3.    --input-dir ./grafana_k8s_exports \
4.    --output-dir ./migration_output \
5.    --assets all \
6.    --native-promql \
7.    --data-view "metrics-*" \
8.    --esql-index "metrics-*" \
9.    --upload \
10.    --kibana-url "$KIBANA_ENDPOINT" \
11.    --kibana-api-key "$KEY" \
12.    --ensure-data-views \
13.    --create-alert-rules \
14.    --validate \
15.    --es-url "$ELASTICSEARCH_ENDPOINT" \
16.    --es-api-key "$KEY"

`AI写代码![](https://csdnimg.cn/release/blogv2/dist/pc/img/runCode/icon-arrowwhite.png)

这些参数对于 Kubernetes 仪表板很重要：

• --native-promql 保留 Pod CPU、内存、限流（throttling）和重启查询中的 PromQL。

• --assets all 在存在 Grafana PromQL 告警定义时，同时包含仪表板和这些告警定义。

• --validate 在上传之前，针对 Elasticsearch 运行生成的查询进行验证。

• --create-alert-rules 创建处于禁用状态的 Kibana 规则。

统一 CLI 会执行相同的工作：

`

1.  obs-migrate migrate \
2.    --source grafana \
3.    --input-mode files \
4.    --input-dir ./grafana_k8s_exports \
5.    --output-dir ./migration_output \
6.    --assets all \
7.    --native-promql \
8.    --data-view "metrics-*" \
9.    --validate \
10.    --es-url "$ELASTICSEARCH_ENDPOINT" \
11.    --es-api-key "$KEY" \
12.    --kibana-url "$KIBANA_ENDPOINT" \
13.    --kibana-api-key "$KEY" \
14.    --upload \
15.    --create-alert-rules

`AI写代码![](https://csdnimg.cn/release/blogv2/dist/pc/img/runCode/icon-arrowwhite.png)

在 Kibana 中验证迁移后的 Grafana 仪表板

打开 Kibana → Dashboards ，找到 Kubernetes / Views / Global。确认在你选择的时间范围内，命名空间或 Pod CPU 使用率、内存工作集面板、限流或压力指标组件，以及重启图表都能够返回数据。

如果你迁移了告警，请打开 Observability → Rules。导入的规则在你检查阈值并确认后，仍会保持禁用状态，直到你手动启用它们。

CLI 还会在本地 ./migration_output/ 下写入以下产物：

• dashboards/yaml/ 包含转换后的仪表板定义。

• dashboards/migration_report.json 列出已自动转换的面板，以及标记为需要人工审核的面板。

• alerts/ 在导出内容中包含告警定义时，会保存告警转换结果。

当 Grafana 面板无法自动迁移时该怎么办？

Observability Migration Platform 会标记无法自动转换的 PromQL 表达式。复杂关联、不常见的算术运算，以及一些 Alertmanager 时代遗留的边界情况，会作为迁移报告中的人工审核条目显示，而不会静默生成损坏的图表。

结果	建议操作
面板返回数据	接受转换结果并继续
面板为空	确认指标名称存在于 metrics-* 中，然后扩大或调整时间范围
标记为人工审核	打开原始 PromQL，并简化或重新设计面板
告警从未触发	确认规则已启用，并检查阈值是否与你的环境匹配

这条路径会将 Grafana PromQL 仪表板和 Grafana 统一 PromQL 告警定义迁移到 Kibana。它不会导入原始的 alertmanager.yml。目标是在不从零重建 Kubernetes 仪表板的情况下，继续使用你的告警系统已经信任的 PromQL。

相关指南

有关平台级背景信息，请参阅将 Datadog 和 Grafana 仪表板及告警迁移到 Kibana。

在迁移所有生产环境目录之前，请查看已知限制。

原文：Grafana to Elastic: migrate Kubernetes dashboards with native PromQL --- Elastic Observability Labs