Operations | Monitoring | ITSM | DevOps | Cloud

An alert tells you what changed. It rarely tells you why. That answer usually lives somewhere else: the pull request that shipped minutes earlier, the incident already open in PagerDuty, the runbook sitting in Confluence. Netdata AI can now reach those systems directly. Through the Model Context Protocol, it connects to the tools your team already runs and reads from them while it investigates. It pulls that context alongside the metrics, logs and anomalies Netdata detects on every node, then reasons across both.

Netdata started as a lightweight agent you install across your systems to collect and visualize metrics in real time. In this clip, we walk through how that model evolved as OpenTelemetry became the industry standard, and why logs pushed that evolution even further.

OTLP (the OpenTelemetry Protocol) gives telemetry data a common format, so it can travel from one system to another without extra massaging or remapping. In this clip, we break down how that standard applies to metrics and logs, and how that data can land directly in Netdata.

Most teams run one tool for SNMP polling, another for topology, and a third for flow analysis, then spend their time stitching the views together. This webinar shows how Netdata brings all three into a single dashboard, with 100+ vendor profiles out of the box, automatic Layer 2 topology mapping, and a flow collector that auto-detects NetFlow, IPFIX, and sFlow on a single port.

If you've standardized on OpenTelemetry (or you're heading that way), you probably know the collector gets your data out, but where it lands and how useful it is once it gets there are separate problems. Netdata now ingests both OTLP metrics and OTLP logs natively, so your OTel pipelines feed directly into the same monitoring experience as everything else in your infrastructure: same dashboards, same alerting, same query interface. No separate backends, no context switching.