作者：来自 Elastic Peter Simkins

了解迁移 CLI 如何将一个真实的 Datadog Kubernetes 仪表板转换为经过验证的 Kibana 面板，并在不到一小时内上传到你的集群，无需手动重新构建任何组件。

Observability Migration Platform 将 Datadog Kubernetes 仪表板转换为 Kibana 中由 ES|QL 驱动的 Lens 面板。它会在上传之前针对你的实时集群验证查询，整个过程通常可以在不到一小时内完成。本演示使用 Kubernetes - Overview 仪表板：包括 Pod CPU、工作集内存、Pod 阶段以及 CrashLoopBackOff 计数。根据已发布的基准测试，在常见的 gauge 和 counter 工作负载中，Elasticsearch 执行 ES|QL 时间序列查询的速度最高可达到 Prometheus 的 30 倍，同时存储效率最高提升 2.5 倍。查看迁移报告，并在准备好后启用告警。

此次迁移中使用的 Datadog Kubernetes 仪表板

本演示使用迁移仓库中 infra/datadog/dashboards/integrations/kubernetes.json 文件里的 Kubernetes - Overview。这是一个集群范围的仪表板，包含运维人员在故障事件期间会检查的信号：Pod 数量、按主机或 Pod 维度统计的 CPU 和内存、未运行的 Pod，以及卡在 CrashLoopBackOff 状态中的容器。

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

# Pod CPU by host
sum:kubernetes.cpu.usage.total{$scope,$cluster,$label,$node} by {host}

# Pod memory by pod
sum:kubernetes.memory.usage{$scope,$deployment,$statefulset,$replicaset,$daemonset,$cluster,$namespace,!pod_name:no_pod,$label,$service,$node} by {pod_name}

# Pods not running (pressure / scheduling signal)
sum:kubernetes_state.pod.status_phase{$scope,$cluster,$namespace,$deployment,$statefulset,$replicaset,$daemonset,!pod_phase:running,!pod_phase:succeeded,$label,$node,$service} by {kube_cluster_name,kube_namespace,pod_phase}

# CrashLoopBackOff
sum:kubernetes_state.container.status_report.count.waiting{$cluster,$namespace,$deployment,$statefulset,$replicaset,$daemonset,reason:crashloopbackoff,$scope,$daemonset,$label,$node,$service} by {pod_name}

如果这个仪表板能够顺利转换，那么大多数生产环境中的 Datadog Kubernetes 文件夹都值得使用相同的工作流进行测试。

为什么 Datadog 到 Elastic 的迁移现在更快

迁移平台自动化了过去占据 Datadog 迁移主要工作量的查询转换和面板重建过程。Elasticsearch 能够高效存储 Kubernetes 指标，并运行这些面板所使用的 ES|QL 查询。查看 Elasticsearch 作为指标后端 了解基准测试背景和存储对比。

该平台会将 Datadog 查询映射到 Kibana 面板，针对实时数据验证 ES|QL，并生成你可以在任何内容进入生产环境之前进行检查的产物。

前置条件

你需要一个 Elastic Observability Serverless 项目、一个 项目 API key，以及从 Observability Migration Platform 仓库安装的迁移 CLI。

导出你的端点和 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 中运行此工具，请固定一个版本标签。

如果想从 Datadog API 拉取仪表板，而不是使用 JSON 文件，请将 datadog_creds.env.example 复制为 datadog_creds.env，并设置 DD_API_KEY、DD_APP_KEY 和 DD_SITE。

首先采集 Kubernetes 指标

上传后出现空面板，通常意味着 Elasticsearch 中还没有 Datadog 查询所引用的时间序列。请务必在运行迁移之前确认数据采集已经完成。

有两种常见方式：

1. 使用 Kubernetes receivers（kubeletstats、k8s_cluster）通过 OpenTelemetry 写入托管 OTLP，然后在 Discover 中进行探索

2. 已存在的 Prometheus 或 agent 数据管道，这些管道已经将 Pod 和节点指标写入 metrics-*

迁移 CLI 接受 --field-profile otel 参数，用于将 Datadog 标签（例如 pod_name、kube_namespace 和 kube_cluster_name）映射到 OpenTelemetry 字段，例如 kubernetes.pod.name 和 kubernetes.namespace。

如果迁移后面板为空，请先验证字段映射和选择的时间范围，然后再修改转换器设置。

运行 Datadog 仪表板迁移 CLI

从 UI 导出 Datadog 仪表板 JSON，或者从迁移仓库中的 infra/datadog/dashboards/integrations/ 目录复制示例 kubernetes.json。将文件放入类似 ./datadog_k8s_exports/ 的目录中。

从该目录运行迁移：

datadog-migrate \
  --source files \
  --input-dir ./datadog_k8s_exports \
  --output-dir ./migration_output \
  --assets all \
  --field-profile otel \
  --data-view "metrics-*" \
  --logs-index "logs-*" \
  --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 仪表板很重要：

• --field-profile otel 将 Datadog Kubernetes 字段映射到 Elasticsearch 中的 OpenTelemetry 字段名称

• --assets all 在存在时包含仪表板和 Datadog monitor 定义

• --validate 在上传之前针对你的集群运行生成的 ES|QL 进行验证

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

统一 CLI 执行相同的工作：

obs-migrate migrate \
  --source datadog \
  --input-mode files \
  --input-dir ./datadog_k8s_exports \
  --output-dir ./migration_output \
  --assets all \
  --field-profile otel \
  --data-view "metrics-*" \
  --logs-index "logs-*" \
  --validate \
  --es-url "$ELASTICSEARCH_ENDPOINT" \
  --es-api-key "$KEY" \
  --kibana-url "$KIBANA_ENDPOINT" \
  --kibana-api-key "$KEY" \
  --upload \
  --create-alert-rules

直接从 Datadog 获取仪表板：

datadog-migrate \
  --source api \
  --env-file datadog_creds.env \
  --dashboard-ids YOUR_DASHBOARD_ID \
  --output-dir ./migration_output \
  --assets all \
  --field-profile otel \
  --data-view "metrics-*" \
  --validate \
  --es-url "$ELASTICSEARCH_ENDPOINT" \
  --es-api-key "$KEY" \
  --kibana-url "$KIBANA_ENDPOINT" \
  --kibana-api-key "$KEY" \
  --upload

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

打开 Kibana → 仪表板（Dashboards），找到迁移后的 Kubernetes - Overview 仪表板。确认在你选择的时间范围内，集群和命名空间 Pod 数量、CPU 和内存时间序列、Pod 状态面板、CrashLoopBackOff 组件以及部署副本图表都能够返回数据。

如果你迁移了 monitor，请打开 可观测性（Observability）→ 规则（Rules）。导入的规则在你检查阈值并启用它们之前，会保持禁用状态。

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

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

• dashboards/migration_report.json 列出自动转换成功的面板，以及标记为需要人工检查的面板。

• alerts/ 在导出内容包含 monitor 时，包含 monitor 转换结果。

处理需要人工检查的面板

某些 Datadog widget 类型在第一次转换时无法完成转换。复杂公式、仅日志面板以及不受支持的 widget 会作为迁移报告中的人工检查条目显示，而不是静默生成损坏的图表。

结果	建议操作
面板返回数据	接受转换结果并继续
面板为空	在 metrics-* 中确认指标名称和 data_stream.dataset 值，然后扩大或调整时间范围
人工检查标记	打开原始 Datadog 查询，并简化或重新设计该面板
Monitor 从未触发	确认规则已启用，并检查阈值是否符合你的环境

在某些领域，Datadog 的覆盖范围比 Grafana 更有限。在向管理层承诺完全一致之前，请先阅读迁移报告。该平台更倾向于保守失败，而不是上传那些看起来正确但实际查询了错误字段的面板。

相关的 Datadog 和 Grafana 迁移指南

有关 Grafana PromQL 版本的此工作流，请查看 将你的 Grafana Kubernetes 仪表板迁移到 Elastic Observability。有关平台级别的背景信息，请查看 将 Datadog 和 Grafana 仪表板及告警迁移到 Kibana。在迁移所有生产环境文件夹之前，请先查看 已知限制。

原文：Datadog to Elastic: migrate Kubernetes dashboards fast — Elastic Observability Labs