Xenoeye: Network Monitoring via NetFlow and SQL, Without AI
A GitHub project replaces AI-driven network anomaly detection with PostgreSQL queries and Grafana dashboards for transparency and auditability.
Last verified:
NetFlow + SQL as an Alternative to Vendor AI
According to the Xenoeye GitHub repository, the tool ingests NetFlow data—standardized network traffic exports from routers and switches—into a PostgreSQL database, then surfaces patterns through Grafana dashboards. The core design choice is to replace machine-learning-driven anomaly detection with manual SQL queries written by network operators.
The repository’s architecture separates data collection (NetFlow ingestion), storage (PostgreSQL), and visualization (Grafana) as decoupled components. This modular approach allows teams to adapt each layer independently—swapping Grafana for another visualization tool, or scaling PostgreSQL to handle high-volume traffic without reimplementing collection logic.
SQL Rules vs. AI Convenience
The trade-off is explicit: SQL queries are transparent and auditable, but require manual authoring. For example, detecting port-scan attempts becomes a concrete, inspectable rule: SELECT src_ip, COUNT(*) FROM netflow WHERE flags='S' GROUP BY src_ip HAVING COUNT(*) > 100. An operator can see exactly what triggered an alert and modify thresholds without retraining a model.
By contrast, commercial network monitoring vendors—including those integrating large language models for anomaly summarization—provide pre-built detection rules and black-box scoring. Operators gain convenience but lose visibility into why an alert fired.
Operational Constraints
According to the Xenoeye GitHub page, the tool is designed for environments where teams have existing PostgreSQL and Grafana expertise. Self-hosted deployments require operational overhead: database tuning, retention policies, backup management. Teams lacking SQL fluency or on-premises infrastructure will find vendor SaaS platforms (which handle scaling and rule maintenance) more practical.
Why This Matters
Air-gapped networks and compliance-sensitive deployments—finance, utilities, government—often cannot use cloud-based SaaS monitoring due to data residency rules. Xenoeye lowers that friction by enabling on-premises, vendor-independent network analysis. However, adoption depends on operator SQL competency. Organizations with centralized data engineering teams can cost-optimize; those without may face years of rule-tuning overhead. The tool’s value is therefore highly context-dependent on team skill and infrastructure constraints.
Frequently Asked Questions
What is Xenoeye and what does it do?
According to the Xenoeye GitHub repository, it is an open-source tool that ingests NetFlow traffic data into PostgreSQL and visualizes network flows using Grafana dashboards. Users write custom SQL queries to detect anomalies instead of relying on pre-trained machine-learning models.
Why would operators choose SQL queries over AI-based anomaly detection?
SQL-based detection is auditable and deterministic—operators can inspect exactly which traffic patterns trigger alerts. AI models, by contrast, are often opaque. However, SQL requires manual rule authoring and SQL expertise, which adds operational burden compared to vendor-provided SaaS solutions.
Does Xenoeye replace commercial network monitoring products?
For teams with in-house SQL expertise and air-gapped (offline) environments, Xenoeye reduces dependency on proprietary SaaS. However, it requires self-hosting PostgreSQL and Grafana infrastructure and does not include pre-built detection rules or vendor support.