Show HN: Xenoeye – analyze network without AI using netflow, PostgreSQL, Grafana

Sorry for the slightly truncated title. It should have been "Network traffic analysis and monitoring without AI, using netflow-family protocols, PostgreSQL or ClickHouse, Grafana, and some scripts".In 2026, it might seem a bit presumptuous to announce AI-free software on HN.
But building a netflow analyzer manually is no less presumptuous!There are quite a few xFlow analyzers out there these days, and I'm constantly reminded of this. But I think there's always room for an alternative approach. After all, that's how software evolves, isn't it?So, how does xenoeye differ from popular (at least from popular open source) analyzers?- The analyzer has a feature called "monitoring objects". For some reason, open-source analyzers rarely use this feature, while commercial ones do.
The monitoring object can be a subnet, autonomous system, geo-object (data on geo and AS are taken from external databases), application traffic (protocol, TCP/UDP ports, etc.), VLAN, etc.
Almost everything in flow records can be used as a filter for a monitoring object.
Of course, object filters can be composite - the classic operations AND, OR, NOT are supported. The analyzer contains a tiny virtual machine that matches each flow to an object.- We don't store all flows. At least for now. It may seem strange, but this is an important feature, especially for large networks.
We store aggregated data on monitored objects. The user chooses what to store. It could be just in/out, top talkers, top protocols, etc.
The time for which to aggregate data is also specified by the user.
Aggregation occurs inside the analyzer. We use a fast trie-based in-memory db.
Because of this, the analyzer can process flows quite quickly (hundreds of thousands of FPS per vCPU) and export a measured amount of information to the database.
You can easily use even vanilla PostgreSQL. Or ClickHouse with compression.
The analyzer is not very resource-intensive; small network traffic can be processed on low-end hardware or in a VM with a small amount of memory.
Or you can process large network traffic on a single server, without building clusters. I know of installations with multi-terabit traffic and hundreds of MOs on a single virtual machine (of course they have a high sampling rate on their routers).- We can monitor traffic thresholds being exceeded using moving averages.
That is, as soon as an excess is detected, an external script is launched at the same second (actually even faster).
This feature is typically used to detect volumetric DoS/DDoS attacks.
The scripts announce BGP Blackhole or BGP Flowspec and notify users via messenger.- We don't have our own visualization utility; we use Grafana. Grafana works with PostgreSQL out of the box, although some complex time-series charts require some tinkering with SQL queries.
Ok, it's a controversial decision, but users (and we ourselves) are putting up with it for now.I tried to describe the rest in the documentation.Yes, this isn't the first time I've tried to announce this project on HN, and I'm under no illusions - for some reason, hackers aren't very fond of this type of software.
Perhaps everyone thinks that the production of netflow analyzers is too boring a matter, there is nothing to discuss.However, if anyone is interested, it would be great to get feedback.What would you do differently than it was done and why?
What do you like most about your favorite analyzer that you can't find anywhere else?How did you even see this post? This isn't AI or even a Rust-related thing