在不到一小时内将 Datadog Kubernetes 仪表板迁移到 Elastic Observability

作者来自 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 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 中运行此工具请固定一个版本标签。如果想从 Datadog API 拉取仪表板而不是使用 JSON 文件请将datadog_creds.env.example复制为datadog_creds.env并设置DD_API_KEY、DD_APP_KEY和DD_SITE。首先采集 Kubernetes 指标上传后出现空面板通常意味着 Elasticsearch 中还没有 Datadog 查询所引用的时间序列。请务必在运行迁移之前确认数据采集已经完成。有两种常见方式使用 Kubernetes receiverskubeletstats、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/的目录中。从该目录运行迁移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