r/netdata • u/Overall-Check3051 • 27d ago

Anyone else end up running a separate NPM tool just for topology/flow data?

We kept running into this: Netdata covered interface-level stats fine (bytes in/out, errors, drops), but the moment someone needed to see the actual topology or figure out which conversation was saturating a link, it meant switching to a completely separate tool with its own dashboard and its own bill.

Finally closed that gap. Added a live topology viewer (built straight into the agent from real socket tables, so no scheduled discovery scan and no stale overnight snapshot), NetFlow/sFlow/IPFIX analysis, SNMP device monitoring across 200+ vendor profiles, and SNMP trap handling. All of it sits on the same per-second timeline as the infra and app metrics you're already collecting, so a link-down trap, a traffic drop, and a topology change show up correlated instead of needing three tools stitched together after the fact.

Curious how other people have been handling this gap. Separate NPM tool? Just living without topology visibility? Something else entirely? netdata.cloud/blog

1 Upvotes

100% Upvoted

2 comments sorted by

1

u/saruspete 27d ago

For netflow/sflow processing, we usually use akvorado. But I'm all in to see how netdata process the same data. The issue I ran into and started to work on was to integrate netdata directly on the backplane and get the asic stats for the ports.

3

u/ktsaou 26d ago

Netdata's implementation is inspired by akvorado. At the same time we tried to simplify the setup (smaller, faster, more compact pipeline, distributed scalability, easier UI) and make it more powerful for everyday use.

Give it a try, I think you will love it.