作者：来自 ElasticSubham Sarkar及Vinay Chandrasekhar

了解如何使用 Observability Migration Platform 将受支持的 Datadog 和 Grafana 仪表板与告警迁移到 Kibana。

Observability Migration Platform 是一个基于 CLI 的工作流，它可以将受支持的 Grafana 和 Datadog 资产转换为 Kibana 原生输出，并生成用于审查结果所需的验证证据。它将迁移过程从手动重建转变为 “翻译 + 验证” 的工作流，从而帮助团队更快迁移到 Elastic Observability。

Observability Migration Platform 支持的迁移范围

当前支持范围涵盖 Datadog 和 Grafana。该平台可以基于导出的资产或实时 API 运行，重点处理 Datadog 和 Grafana 路径下受支持的仪表板与告警内容。

两者的支持程度并不完全相同。Datadog 提供端到端的流程，包括提取、校验、编译、上传、冒烟测试以及验证，但当前支持的 widgets 和 monitors 范围较窄。Grafana 的覆盖范围更广。该平台为已支持的路径提供了一条可执行的翻译流水线。

下方截图展示了迁移后的仪表板示例。

Observability Migration Platform 的工作原理

从高层来看，该工作流分为两个部分：进入阶段的源系统感知翻译，以及输出阶段的目标系统感知验证与交付。这个拆分非常重要，因为 Grafana 和 Datadog 不仅在 JSON 结构上不同，在查询语言、面板类型、控制方式以及告警模型上也存在差异。

一次运行以导出的资产或实时源 API 开始。从那里开始，工作流会对源系统特定对象进行规范化处理，为每一个受支持的仪表板、面板以及告警工件选择对应的转换路径，并生成 Kibana 原生输出。这一阶段承载了大部分与源系统相关的逻辑：包括查询或 Datadog 公式的转换、面板语义映射、尽可能保留控制项与链接，以及在无法进行精确转换时判断是否需要采用替代方案tgcode。

第二部分是目标系统感知的处理。生成的输出会在 Elastic 目标环境中进行验证、编译，并通过共享运行时上传到 Kibana。在理想情况下，这会生成一个可正常运行的已转换仪表板。在更复杂的情况下，验证可能发现某些面板无法安全执行。此时工作流会采取保守失败策略：可以将该面板标记为人工审查，或用可安全上传的占位符替代，而不是直接发布可能损坏运行时的面板。

同样重要的是，最终结果不仅仅是“一个仪表板出现在 Kibana 中”。该工作流还会生成面向审查者的证据材料，例如迁移报告、清单、验证包以及上线计划，从而清晰展示哪些内容成功转换、哪些被降级或转为人工处理，以及哪些仍需人工判断。这些产物使整个过程具备可运营性：团队可以基于这些具体证据进行检查、对比并采取行动。

运行迁移

该平台以 CLI 为驱动，非常适合需要可重复、可审查且易于自动化的迁移工作。用户可以从 Grafana 或 Datadog 中选取一部分具有代表性的仪表板和告警内容，指向 Elastic 目标环境，并通过第一次运行来评估转换质量、验证结果以及后续需要多少人工审查。

要在 Elastic 环境中运行完整流程，需要创建一个 Elastic Observability Serverless 项目，生成 Serverless 项目的 API key，并将 CLI 指向你的 Elasticsearch 和 Kibana 端点：

obs-migrate migrate 
  --source grafana 
  --input-mode files 
  --input-dir ./grafana_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

该运行会在 Elastic 中验证生成的查询，编译生成的仪表板，将其上传到 Kibana，并生成标准迁移产物以供审查。

一个典型的运行流程如下：

1. 从 Grafana 或 Datadog 的导出资产或实时源 API 开始
2. 使用 --assets dashboards、--assets alerts 或 --assets all 选择资产范围
3. 将受支持的仪表板、查询、控制项以及告警工件转换为 Kibana 原生输出
4. （如已配置 Elastic 目标环境）在 Elastic 上验证生成内容，然后编译并上传可用于仪表板的结果
5. 审查迁移证据，包括 migration_report.json、verification_packets.json、run_summary.json 等，以了解哪些内容转换顺利、哪些存在语义差距tgcode，以及哪些仪表板、面板或告警规则仍需人工处理
6. 如果启用了告警规则创建，在 Kibana 中审查已迁移的规则（默认处于禁用状态），再决定哪些需要启用或重新设计

下一步

该平台仍在持续演进，并将不断增强深度与自助能力。目前最主要的待完善方向包括：更强的源到目标语义验证能力、更广泛的 Datadog 覆盖、更复杂查询类型与非仪表板场景的支持，以及在整个工作流中更清晰的共享运行时契约。

同时，该平台是可持续扩展的。源端与目标端的边界是刻意设计为显式的，这为未来扩展覆盖范围以及支持更多源系统路径提供了空间。

总结

如果你计划迁移到 Elastic，一个良好的起点是创建 Elastic Observability Serverless 项目。这将为已转换的仪表板与告警内容提供一个可用于验证和审查的目标环境。

如需了解更多迁移工作流信息，可以联系你的 Elastic 代表，获取当前访问权限、支持范围以及它如何帮助你的迁移需求。

原文：https://www.elastic.co/observability-labs/blog/migrate-datadog-grafana-dashboards-alerts-to-kibana