作者：来自 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 状态中的容器。
下面是源仪表板中的一些代表性查询：
bash
`
1. # Pod CPU by host
2. sum:kubernetes.cpu.usage.total{$scope,$cluster,$label,$node} by {host}
`AI写代码
bash
`
1. # Pod memory by pod
2. sum:kubernetes.memory.usage{$scope,$deployment,$statefulset,$replicaset,$daemonset,$cluster,$namespace,!pod_name:no_pod,$label,$service,$node} by {pod_name}
`AI写代码
bash
`
1. # Pods not running (pressure / scheduling signal)
2. 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}
`AI写代码
bash
`
1. # CrashLoopBackOff
2. sum:kubernetes_state.container.status_report.count.waiting{$cluster,$namespace,$deployment,$statefulset,$replicaset,$daemonset,reason:crashloopbackoff,$scope,$daemonset,$label,$node,$service} by {pod_name}
`AI写代码如果这个仪表板能够顺利转换，那么大多数生产环境中的 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：
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 中运行此工具，请固定一个版本标签。
如果想从 Datadog API 拉取仪表板，而不是使用 JSON 文件，请将 datadog_creds.env.example 复制为 datadog_creds.env ，并设置 DD_API_KEY 、DD_APP_KEY 和 DD_SITE。
首先采集 Kubernetes 指标
上传后出现空面板，通常意味着 Elasticsearch 中还没有 Datadog 查询所引用的时间序列。请务必在运行迁移之前确认数据采集已经完成。
有两种常见方式：
-
使用 Kubernetes receivers（
kubeletstats、k8s_cluster）通过 OpenTelemetry 写入托管 OTLP，然后在 Discover 中进行探索 -
已存在的 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/ 的目录中。
从该目录运行迁移：
scss
`
1. datadog-migrate \
2. --source files \
3. --input-dir ./datadog_k8s_exports \
4. --output-dir ./migration_output \
5. --assets all \
6. --field-profile otel \
7. --data-view "metrics-*" \
8. --logs-index "logs-*" \
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 仪表板很重要：
-
--field-profile otel将 Datadog Kubernetes 字段映射到 Elasticsearch 中的 OpenTelemetry 字段名称 -
--assets all在存在时包含仪表板和 Datadog monitor 定义 -
--validate在上传之前针对你的集群运行生成的 ES|QL 进行验证 -
--create-alert-rules创建处于禁用状态的 Kibana 规则
统一 CLI 执行相同的工作：
scss
`
1. obs-migrate migrate \
2. --source datadog \
3. --input-mode files \
4. --input-dir ./datadog_k8s_exports \
5. --output-dir ./migration_output \
6. --assets all \
7. --field-profile otel \
8. --data-view "metrics-*" \
9. --logs-index "logs-*" \
10. --validate \
11. --es-url "$ELASTICSEARCH_ENDPOINT" \
12. --es-api-key "$KEY" \
13. --kibana-url "$KIBANA_ENDPOINT" \
14. --kibana-api-key "$KEY" \
15. --upload \
16. --create-alert-rules
`AI写代码直接从 Datadog 获取仪表板：
scss
`
1. datadog-migrate \
2. --source api \
3. --env-file datadog_creds.env \
4. --dashboard-ids YOUR_DASHBOARD_ID \
5. --output-dir ./migration_output \
6. --assets all \
7. --field-profile otel \
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
`AI写代码
在 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