メニュー
Use when migrated Kibana panels are empty, show missing/unknown fields, query the wrong index or data view, or the user needs to fix Prometheus label / Datadog tag / metric-name mapping gaps after an obs-migrate run.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | remediate-field-mapping-gaps |
| description | Use when migrated Kibana panels are empty, show missing/unknown fields, query the wrong index or data view, or the user needs to fix Prometheus label / Datadog tag / metric-name mapping gaps after an obs-migrate run. |
Goal: move from "the migrated panel is empty or wrong" to a concrete source-to-Elastic mapping fix. Field mapping gaps are expected in observability migrations; treat them as schema alignment work, not automatically as translator bugs.
| Symptom | First move |
|---|---|
| Empty uploaded panel / "No results found" | Use debug-uploaded-kibana-dashboard to capture the exact ES |
| Unknown column / missing field error | Read the field name from the Kibana/ES error and locate it in required_target_contract.json (Grafana), target_readiness_contract.json (Datadog), or the emitted query |
| Values look wrong but data exists | Compare source query fields/tags to translated query fields in verification_packets.json and the schema report |
| Many panels fail the same way | Fix the rule pack / field profile and rerun; do not hand-edit every panel first |
Assume the user installed the package (obs-migrate on PATH); prefix .venv/bin/ only for a repo checkout.
| What you need | File / command |
|---|---|
| Per-panel source fields -> target fields | <output-dir>/dashboards/schema_change_report.md (written by migration); use obs-migrate schema-report --artifact-dir <output-dir>/dashboards --output schema_change_report.md --contract-out telemetry_contract.json only to regenerate or combine outputs |
| Required target fields and missing/confirmed status | Grafana: <output-dir>/dashboards/required_target_contract.json; Datadog: <output-dir>/dashboards/target_readiness_contract.json |
| Source query and translated query | <output-dir>/dashboards/verification_packets.json |
| Human-readable must-fix list | <output-dir>/dashboards/migration_summary.md |
| Uploaded-panel runtime truth | debug-uploaded-kibana-dashboard capture of Kibana's actual /_query request |
<output-dir>/dashboards/schema_change_report.md and find the row for the failing panel. Regenerate with obs-migrate schema-report only if you are combining old artifact dirs or rebuilding the report.required_target_contract.json (Grafana) or target_readiness_contract.json (Datadog). Prioritize fields marked missing or unknown.--rules-file <custom-rule-pack.yaml>.--field-profile (otel, prometheus, elastic_agent, passthrough) or pass a custom YAML profile.--suggest-rule-pack-out <path>; both sources can emit templates with obs-migrate extensions --source grafana|datadog --template-out <path>.try-one-source-dashboard) or selected assets before a full sweep.validate-side-by-side for numeric parity where applicable, and debug-uploaded-kibana-dashboard if the UI is still empty.Grafana rule-pack path:
obs-migrate extensions --source grafana --format yaml --template-out custom-rule-pack.yaml
# edit label_rewrites / label_candidates
obs-migrate migrate --source grafana ... --rules-file custom-rule-pack.yaml
Datadog field-profile path:
obs-migrate extensions --source datadog --template-out custom-field-profile.yaml
# edit metric_map / tag_map / prefixes
obs-migrate migrate --source datadog ... --field-profile custom-field-profile.yaml
verification_packets.json keys from memory. Open the file and read the actual shape for the run.obs-migrate schema-report, obs-migrate extensions, --rules-file, --field-profile, and --suggest-rule-pack-out are the package-native paths.understand-source-schema — source-to-target mapping model and report locations.debug-uploaded-kibana-dashboard — capture Kibana's actual runtime query.validate-side-by-side — compare translated results after remediation.try-one-source-dashboard / migrate-selected-assets — rerun the smallest useful scope.Use when the user wants a readiness assessment, feasibility verdict, "what will/won't migrate", how much manual effort is required, a go/no-go before committing, or to know how confident they can be in the result — assesses how much of a connected Grafana/Datadog environment will migrate cleanly versus need manual rework, and how trustworthy that assessment is. For a plain count/type inventory (no verdict), use scan-o11y-environment instead.
Use when the user wants to connect, authenticate, point the tool at, or verify connectivity/credentials to their Grafana or Datadog instance, or asks "can the tool reach my Grafana/Datadog" / "how do I set up access" — connects the obs-migrate / mig-to-kbn tool to a source observability vendor (Grafana or Datadog) and proves it can actually reach it before any migration.
Use when the user reports a panel rendering empty / "No results found" / "Migration Required" / wrong-shape values after running parity-rig/upload-all.sh or obs-migrate upload, or hands over a Kibana dashboard URL and asks "why is this panel broken" — diagnoses a Kibana dashboard that mig-to-kbn uploaded to the Serverless cluster by driving Chrome via the chrome-devtools MCP server, capturing the per-panel ES|QL the Kibana UI is actually running, the /_query network response, browser console errors, and a screenshot of the failing panel.
Use when the user asks whether their credentials/API key has the right permissions, roles, or privileges to export from their source or to import dashboards / create alert rules into Kibana, or wants to check access before committing to a migration — verifies the credentials have what an obs-migrate / mig-to-kbn migration needs end-to-end — read/export on the source (Grafana/Datadog) and write on the Elastic/Kibana target.
Use when the user asks "why didn't this panel migrate", "what does not_feasible mean here", "how do I fix the panels that need manual work", "explain the warnings", or "how do I rebuild this in Kibana" — explains WHY panels and widgets did NOT migrate cleanly, in plain language, with step-by-step guidance to rebuild them in Kibana. Read-only; reads migration artifacts already on disk. For an overall coverage summary use report-migration-coverage; to numerically verify the panels that DID migrate use validate-side-by-side.
Use when the user has decided to fully switch and wants to "migrate everything", "do the whole environment", "migrate all my dashboards and alerts", or a complete cutover — bulk-migrates EVERY supported dashboard and/or alerting rule from a connected Grafana or Datadog environment into Kibana in one sweep, and reports exactly which assets could not migrate. For a chosen subset use migrate-selected-assets; for a single proof dashboard use try-one-source-dashboard.