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

作者来自 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 Keyexport ELASTICSEARCH_ENDPOINThttps://YOUR_ES_ENDPOINT export KIBANA_ENDPOINThttps://YOUR_KIBANA_ENDPOINT export KEYYOUR_API_KEY安装 CLI 并确认工具链python3 -m venv .venv .venv/bin/pip install .[all] .venv/bin/obs-migrate doctordoctor命令会检查编译和代码检查依赖。在迁移生产环境仪表板之前请先解决所有错误。如果计划在 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。相关指南有关平台级背景信息请参阅将 Datadog 和 Grafana 仪表板及告警迁移到 Kibana。在迁移所有生产环境目录之前请查看已知限制。原文Grafana to Elastic: migrate Kubernetes dashboards with native PromQL — Elastic Observability Labs