An SNMP trap is an asynchronous, pushed event notification that a network device sends when something happens — an interface changes state, authentication fails, a config changes, or a sensor crosses a threshold. Traps catch transient events that scheduled polling might miss between collection intervals.

No. The snmp_traps collector inside Netdata’s Go plugin binds its own UDP socket, decodes the SNMP PDU, resolves it against YAML trap profiles, and writes structured log rows — all natively inside the Agent. There is no external trap server dependency.

Netdata receives SNMPv1, SNMPv2c, and SNMPv3 Trap and INFORM notifications. SNMPv3 supports USM authentication and privacy (authPriv) with SHA-256 and AES. Every INFORM is acknowledged automatically.

Traps appear primarily as structured logs in Netdata’s unified Logs UI — the SNMP Trap Logs view — filterable by trap name, category, severity, source IP, device vendor, and job. The collector also publishes receiver self-metrics (pipeline counters, events by category and severity, and processing-error breakdowns) with ~21 default health alerts. There is no separate trap console to learn.

No — traps and polling are complementary. Traps catch transient transitions that polling would miss between intervals; polling confirms current state and catches devices too hard-faulted to send a trap. The rule is simple: traps are the ceiling, polling is the floor. Silence is never proof of health. Pair traps with SNMP device monitoring for complete coverage.

Unknown OIDs are still stored — the trap row carries TRAP_CATEGORY=unknown, TRAP_SEVERITY=notice, the numeric OID, and source information. Unknown-OID is a coverage signal, not broken ingestion. You can add vendor MIBs offline using the bundled snmp-trap-profile-gen generator, or write operator profiles that hot-reload while the listener runs.

Yes. Netdata supports OTLP/gRPC Logs export to forward decoded traps to an OpenTelemetry Collector, SIEM, or log platform. You can run the local journal and OTLP export simultaneously — the local journal remains authoritative even if OTLP delivery is interrupted.

Netdata’s ML anomaly detection runs on all metrics, including the trap receiver’s self-metrics — pipeline counters, events by category and severity, and error rates. ML scores trap volume and severity patterns for anomalies. It does not interpret individual trap log text.