Skip to main content

migrate-all-supported-assets

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.

Quellinformationen

Repository
elastic/observability-migration-platform
Letzte Quellaktivität
3. August 2026 um 21:07
Erkannte Sprache von SKILL.md
Englisch
Sterne
7
Forks
9

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
name
migrate-all-supported-assets
description
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.
# Migrate every supported dashboard / alerting rule **Audience:** operators of the published `obs-migrate` CLI (PyPI/`uvx`), using public docs and their real source + Elastic/Kibana — not a repo lab harness. Goal: migrate **everything the engine supports** from a source in one run, then give the user a straight account of what landed and **what could not migrate**. This is the full-sweep step for teams that have already assessed readiness and decided to switch. This skill writes all supported assets to the target. It is otherwise read-only on the source. ## Prerequisites (install) These skills help **operators** of the published CLI (not a repo checkout). If `obs-migrate` is missing or `doctor` is not **Ready**, follow `install-obs-migrate` first — that skill owns PyPI/`uvx`/pip, extras, and Python/`uv` gotchas. Do not invent alternate install commands here. ```bash uvx --from 'elastic-observability-migration[all]' obs-migrate doctor # After a persistent install, the same check is: obs-migrate doctor ``` Source/Elastic credentials: `connect-to-o11y-source` (and your env exports). ## Core fact: "all" is the absence of a selector There is no `--all` flag. A bulk migration is simply `--assets all` (or `--assets dashboards` / `--assets alerts`) **with no id/query / `--select-*` selector** — the engine then processes the full set the source returns and reports the ones it cannot translate. Unsupported assets are **surfaced, never silently dropped** (degrade-gracefully). - `--assets dashboards` → every supported dashboard, no alert artifacts. - `--assets alerts` → every supported rule/monitor, no dashboard YAML. - `--assets all` → both isolated pipelines in one command (the union). Look for both `…/dashboards/` and `…/alerts/` under the output dir. ## Step 1 — Run the full migration Datadog, everything, live API (creates rules disabled + tagged in the same run): ```bash export ELASTICSEARCH_ENDPOINT="https://...es..." KIBANA_ENDPOINT="https://...kbn..." KEY="<api-key>" export DD_API_KEY="..." DD_APP_KEY="..." DD_SITE="datadoghq.com" obs-migrate migrate \ --source datadog \ --input-mode api \ --env-file datadog_creds.env \ --output-dir full_out \ --assets all \ --field-profile otel \ --data-view "metrics-*" \ --es-url "$ELASTICSEARCH_ENDPOINT" --es-api-key "$KEY" \ --kibana-url "$KIBANA_ENDPOINT" --kibana-api-key "$KEY" \ --upload \ --create-alert-rules ``` Grafana, everything, live API: ```bash export GRAFANA_URL="https://grafana.example.com" GRAFANA_USER="..." GRAFANA_PASS="..." obs-migrate migrate \ --source grafana \ --input-mode api \ --output-dir full_out \ --assets all \ --data-view "metrics-*" \ --esql-index "metrics-*" \ --es-url "$ELASTICSEARCH_ENDPOINT" --es-api-key "$KEY" \ --kibana-url "$KIBANA_ENDPOINT" --kibana-api-key "$KEY" \ --upload \ --create-alert-rules ``` - `--upload` pushes dashboards via the **typed Dashboards API** (in-memory / persisted `native/*.native.json` payloads). That is the only upload path — there is no YAML/NDJSON compile step and no external tool to install. `--create-alert-rules` creates the emitted rules **disabled** and tagged `obs-migration`. - Drop `--upload` / `--create-alert-rules` for a dry, target-aware translation pass first; add them once the readout looks right. You can also split into two runs: produce artifacts, inspect `full_out/dashboards/native/*.native.json` (upload payload) and `full_out/dashboards/ir/*.ir.json` (translator decisions, inspection-only), then `obs-migrate upload --artifact-dir full_out/dashboards`. - Without `--create-alert-rules`, alert translation still writes `monitor_migration_results.json` (Datadog) / equivalent Grafana alert artifacts — **not** `monitor_rule_upload_results.json` / `alert_rule_upload_results.json` (those appear only when rules are created in Kibana). - File-based sources: swap `--input-mode api` for `--input-mode files --input-dir <dir>` pointing at all exported dashboard JSON. - **Custom-CA / self-signed clusters:** `--ca-cert <path>` (env `OBS_MIGRATE_CA_CERT`) verifies against a private CA; `--insecure` (env `OBS_MIGRATE_INSECURE`) skips verification for testing only. Both cover source, Elasticsearch, and Kibana (including the dashboard upload). ## Step 2 — Read what landed and what did NOT The whole point of a bulk run is the **coverage report**. Read it; do not assume exit 0 means every asset is perfect. | What you want | File | Field(s) | |---|---|---| | Human-readable verdict + per-dashboard table + must-fix worklist | `full_out/dashboards/migration_summary.md` | verdict, scorecard, must-fix list, grouped warnings | | Dashboard coverage buckets | `full_out/dashboards/migration_report.json` | `summary` (counts), readiness buckets | | Per-panel status / why a panel didn't migrate | `full_out/dashboards/migration_manifest.json` | `panels[].status`, `panels[].reasons`; Grafana type: `panels[].grafana_type`; Datadog widget type: `panels[].datadog_widget_type` | | Which asset families ran | `full_out/run_summary.json` | top-level summary | | Alert translation (always for `--assets alerts\|all`) | `full_out/alerts/monitor_migration_results.json` (Datadog) | tiers / kinds / failures | | Alert rule creation results (only with `--create-alert-rules`) | `full_out/alerts/monitor_rule_upload_results.json` (Datadog) / `full_out/alerts/alert_rule_upload_results.json` (Grafana) | created / failed / skipped | The dashboards that **cannot** migrate appear as non-clean entries in `migration_summary.md` and as `requires_manual` / `not_feasible` panels (with `reasons`) in the manifest. Panels that **migrated with warnings** (accepted approximations such as `histogram_quantile` → `PERCENTILE`) are also non-clean — triage with `explain-migration-gaps` rather than counting them as hard failures by default. Alerts that cannot be emitted are reported in the alert artifacts. Relay these explicitly — that list is the deliverable, not an afterthought. ## Step 3 — Verify and hand off the gaps 1. State the **coverage**: how many dashboards/panels and rules migrated cleanly vs. warned vs. need rework, straight from the summary/report. 2. For broken/empty uploaded panels, hand off to the `debug-uploaded-kibana-dashboard` skill (captures real ES|QL and classifies `render_error` vs field/data gaps). 3. For warned or blocked panels, use `explain-migration-gaps` — it separates accepted approximations from redesign work. 4. Stronger gates when staking a cutover claim: `obs-migrate verify` / `validate-side-by-side`, `verifier.live_validate`, `verifier.dashboards_api`, and **render audit** (`https://github.com/elastic/observability-migration-platform/blob/main/docs/testing.md`) — the last is the only gate for Lens accessor / "invalid column" / empty-state failures that ES|QL execution misses. 5. Migrated rules are **disabled**; review with `obs-migrate audit-rules` before enabling (`review-and-enable-migrated-alerts`). ## Honest limits (tell the user) - **Exit 0 ≠ everything is perfect.** The run can succeed while individual panels are `requires_manual` / `migrated_with_warnings` / empty. Trust the report, not just the exit code. - **Grafana API extraction is capped at 500 dashboards** per search request — a very large org may not be fully covered in one API pass; note it and consider file exports for the remainder. - **No `--es-url` ⇒ no live validation.** A target-less run still translates and reports, but does not prove panels render against real data. - **Created rules are disabled.** A bulk alert migration arms nothing; rules are disabled and tagged `obs-migration` until enabled by a human. - **Empty panels are often missing data, not a bug.** A clean translation renders empty without matching telemetry in the target; use `prepare-target-telemetry` and/or `obs-migrate seed-sample-data` (auth flag **`--api-key`**, defaults to env `KEY` — not `--es-api-key`). - **Degrade gracefully:** unsupported assets are surfaced with reasons, never hidden — that is the contract. ## Do NOT - Do **not** report "migrated everything" without reading the coverage report and naming what could not migrate. - Do **not** treat exit 0 as proof every panel is correct. - Do **not** claim a bulk alert migration enabled rules — it creates them disabled. - Do **not** invent flags. Bulk = `--assets all` with no selector; confirm with `obs-migrate migrate --help`. - Do **not** cite manifest fields you have not confirmed (e.g. `grafana_type` exists on Grafana manifest panels; open the JSON when unsure). ## See also - `install-obs-migrate` — install/doctor when the CLI is missing or not Ready. - `assess-migration-readiness` skill — run this first to know how much will migrate (and at what evidence level) before sweeping. - `migrate-selected-assets` skill — migrate a chosen subset instead of everything. - `explain-migration-gaps` skill — plain-language triage of warned vs blocked panels. - `debug-uploaded-kibana-dashboard` skill — diagnose individual broken uploaded panels after the sweep. - `prepare-production-cutover` skill — go/no-go after the sweep + validation. - `revert-migration` skill — remove the generated dashboards/rules if the user backs out. - `obs-migrate migrate --help` — authoritative asset/upload flags for the installed version. - `https://github.com/elastic/observability-migration-platform/blob/main/docs/command-contract.md` — asset-scope contract and artifact descriptions (online docs / repo). - `https://github.com/elastic/observability-migration-platform/blob/main/docs/testing.md` — layered verifier and render-audit gates.
Auf GitHub ansehen