作者：来自 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 查询：
bash
`
1. # Pod / container CPU by namespace
2. sum(rate(container_cpu_usage_seconds_total{image!="", cluster="$cluster"}[$__rate_interval])) by (namespace)
`AI写代码
vbnet
`
1. # Memory working set by namespace
2. sum(container_memory_working_set_bytes{image!="", cluster="$cluster"}) by (namespace)
`AI写代码
bash
`
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写代码
bash
`
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：
ini
`
1. export ELASTICSEARCH_ENDPOINT="https://YOUR_ES_ENDPOINT"
2. export KIBANA_ENDPOINT="https://YOUR_KIBANA_ENDPOINT"
3. export KEY="YOUR_API_KEY"
`AI写代码安装 CLI 并确认工具链：
bash
`
1. python3 -m venv .venv
2. .venv/bin/pip install ".[all]"
3. .venv/bin/obs-migrate doctor
`AI写代码doctor 命令会检查编译和代码检查依赖。在迁移生产环境仪表板之前，请先解决所有错误。如果计划在 CI 中运行此工具，请固定一个版本标签。
如何将 Kubernetes 指标导入 Elasticsearch？
上传后出现空面板通常意味着 Elasticsearch 中还没有 PromQL 所引用的指标序列。在运行迁移之前，请确认数据已经成功摄取。
有两种常见方式：
-
从 kube-state-metrics、cAdvisor 或 kubelet 指标以及 node exporter，通过 Prometheus Remote Write 写入 Elasticsearch。
-
通过 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/ 的目录中。
从该目录运行迁移：
scss
`
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写代码这些参数对于 Kubernetes 仪表板很重要：
-
--native-promql保留 Pod CPU、内存、限流（throttling）和重启查询中的 PromQL。 -
--assets all在存在 Grafana PromQL 告警定义时，同时包含仪表板和这些告警定义。 -
--validate在上传之前，针对 Elasticsearch 运行生成的查询进行验证。 -
--create-alert-rules创建处于禁用状态的 Kibana 规则。
统一 CLI 会执行相同的工作：
scss
`
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写代码
在 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