メニュー
Use when migrating observability from Datadog, New Relic, Dynatrace, or Prometheus to Netdata. Covers SDK replacement, exporter reconfiguration, Prometheus endpoint passthrough, and dashboard parity expectations.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | netdata-migration |
| description | Use when migrating observability from Datadog, New Relic, Dynatrace, or Prometheus to Netdata. Covers SDK replacement, exporter reconfiguration, Prometheus endpoint passthrough, and dashboard parity expectations. |
| version | 0.1.0 |
| author | Netdata |
| license | Apache-2.0 |
| tags | ["netdata","migration","datadog","new-relic","dynatrace","prometheus","opentelemetry"] |
This skill guides a migration from another observability vendor's metric pipeline to Netdata. The goal is OpenTelemetry-native instrumentation that exports to Netdata over OTLP/gRPC, with existing dashboards and alerts rebuilt on the Netdata side where parity is possible.
prometheus receiver, or use Netdata's
native Prometheus endpoint scraping.Inventory what the current stack emits:
Pick a strategy:
Replace the SDK. See the per-vendor rule files in References.
Reconfigure the exporter. OTLP/gRPC at the Netdata receiver
port (default 4317). Set service.name, service.version,
deployment.environment as resource attributes.
Rebuild alerts against Netdata. Prioritize by current alert firing frequency; low-volume alerts can wait.
Decommission the vendor agent once the parallel-run window shows no regressions.
A reliable migration order for a medium-sized fleet (20-100 services, multiple teams):
A cutover under two weeks is possible for a small shop. A fleet migration under six weeks usually means something was skipped.
Run the MCP integration skill's telemetry-flow check against the service that was just migrated. Before cutover, also run the same check against the old vendor. A parallel-run comparison:
For service <name>, list the top 10 metrics by volume in Netdata
in the last 30 minutes. List the top 10 metrics by volume in the
old vendor for the same window. Identify any metric present in
the old vendor but absent in Netdata.
Gaps revealed by that check usually trace back to missing instrumentation packages (for example, the Datadog SDK wrapped a library that the OTel auto-instrumentation set does not yet cover).
A second check to run a week after cutover: have every on-call acknowledge that the runbooks they actually used in the last 30 days still work against Netdata. A runbook that no longer matches the observability tool is a silent hazard.
Plan an explicit "metric inventory" diff, not just a spot check.
Export the metric list from the old vendor (most have an API for
this), and compare to Netdata's list_metrics output. The diff
is what tells you whether something was quietly dropped.
rules/from-datadog.mdrules/from-new-relic.mdrules/from-dynatrace.mdrules/from-prometheus.mdrules/parity-expectations.mdUse when migrating alerting rules from VictoriaMetrics (vmalert), Prometheus, Thanos Ruler, or Mimir/Cortex to Netdata health alerts. These tools share the same Prometheus alerting-rule YAML and PromQL/MetricsQL, so the method is identical. Covers the stock-first decision (Netdata already ships alerts for most common signals), the translation methodology from PromQL expressions to Netdata lookup/calc/warn/crit on a chart context, the constructs that do not map cleanly (cross-metric joins, predict_linear, histogram_quantile, fleet aggregations, absent), notification-routing parity with Alertmanager (agent roles and Netdata Cloud), and automatic verification over MCP. Pairs with netdata-mcp-integration to connect and netdata-custom-collector when a rule alerts on a metric Netdata does not yet collect.
Use when you need Netdata to collect metrics from something it does not already monitor, such as a custom application, an internal service, the output of a script or CLI tool, or a device. Covers the decision tree from the built-in StatsD server (zero collector code) through writing a collector in any language via the external-plugin line protocol (CHART/DIMENSION/BEGIN/SET/END on stdout), or the legacy python.d and charts.d module frameworks. Teaches how to pick the cheapest approach that works, scaffold it from a real example, and, when a Netdata MCP server is connected, automatically verify over MCP that the metrics are collected in the right format without user handholding.
Use when building or modifying an OpenTelemetry Collector pipeline that forwards telemetry to Netdata. Covers receivers, processors, exporters, and three deployment patterns (DaemonSet, gateway, and OpenTelemetry Operator). Teaches how to shape chart dimensions via an OTLP attribute plus a mapping file, since Netdata does not expose producer-driven annotations for chart layout.
Use when a customer or prospect has sent a written requirements document, architecture brief, or RFP and the deliverable is a config bundle (Netdata otel.yaml, OpenTelemetry Collector pipelines, per-language instrumentation handoff, verification playbook) that the customer applies themselves. Unlike netdata-instrumentation and netdata-otel-setup, this skill operates without access to the customer's codebase or running infrastructure: inputs are prose, outputs are YAML files, Markdown runbooks, and an explicit list of open questions for the account team. Covers requirements extraction, ambiguity flagging, bundle layout, and composition with netdata-otel-setup, netdata-collector-config, netdata-instrumentation, and netdata-migration.
Use when adding OpenTelemetry instrumentation to application code that will report to Netdata. Covers SDK setup, resource attributes, auto-instrumentation, and patterns for Node.js, Python, Java, Go, .NET, Ruby, and PHP. Emits metrics and logs via OTLP gRPC to Netdata. Traces are not yet supported by Netdata; use an alternative trace backend until Q2 2026.
Use when an AI coding agent needs to connect to a Netdata Agent, Parent, or Netdata Cloud via MCP to verify telemetry, query live metrics, cross-reference instrumentation with infrastructure signals, or troubleshoot services. Covers Claude Code, Cursor, Codex, and Gemini CLI client configs for both local (http://HOST:19999/mcp) and Netdata Cloud endpoints.