Use 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.
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.
Use when enabling the Netdata otel.plugin, writing /etc/netdata/otel.yaml, defining metric-to-chart mappings, configuring TLS on the OTLP receiver, or debugging OTLP ingestion issues with Netdata. Covers OTLP gRPC ingestion for metrics (v2.7.0+) and logs (v2.9.0+). Traces are not yet supported.