当前位置：首页 > news >正文

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

news 2026/7/23 17:25:08

作者：来自 Elastic Peter Simkins

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

Elasticsearch 现已原生支持运行 PromQL。使用 Observability Migration Platform，将一个 GrafanaKubernetes / 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 查询：

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

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

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

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

如果这个仪表板能够顺利完成转换，那么大多数生产环境中的 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：

export ELASTICSEARCH_ENDPOINT="https://YOUR_ES_ENDPOINT" export KIBANA_ENDPOINT="https://YOUR_KIBANA_ENDPOINT" export KEY="YOUR_API_KEY"

安装 CLI 并确认工具链：

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

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/的目录中。

从该目录运行迁移：

grafana-migrate \ --source files \ --input-dir ./grafana_k8s_exports \ --output-dir ./migration_output \ --assets all \ --native-promql \ --data-view "metrics-*" \ --esql-index "metrics-*" \ --upload \ --kibana-url "$KIBANA_ENDPOINT" \ --kibana-api-key "$KEY" \ --ensure-data-views \ --create-alert-rules \ --validate \ --es-url "$ELASTICSEARCH_ENDPOINT" \ --es-api-key "$KEY"

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

--native-promql保留 Pod CPU、内存、限流（throttling）和重启查询中的 PromQL。
--assets all在存在 Grafana PromQL 告警定义时，同时包含仪表板和这些告警定义。
--validate在上传之前，针对 Elasticsearch 运行生成的查询进行验证。
--create-alert-rules创建处于禁用状态的 Kibana 规则。

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

obs-migrate migrate \ --source grafana \ --input-mode files \ --input-dir ./grafana_k8s_exports \ --output-dir ./migration_output \ --assets all \ --native-promql \ --data-view "metrics-*" \ --validate \ --es-url "$ELASTICSEARCH_ENDPOINT" \ --es-api-key "$KEY" \ --kibana-url "$KIBANA_ENDPOINT" \ --kibana-api-key "$KEY" \ --upload \ --create-alert-rules

在 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。