// the find
open-falcon/falcon-plus
An open-source and enterprise-level monitoring system.
Open-Falcon is a host-centric monitoring system originally built at Xiaomi for large-scale bare-metal and VM fleets. It collects metrics via a polling agent, routes them through a transfer layer, stores them in a custom graph backend, and fires alerts through a judge component. The README opens by telling you to use Nightingale instead — that tells you everything about where this project stands.
- The modular architecture (agent, transfer, judge, graph, alarm as separate processes) means you can scale or replace individual components without touching the rest — useful if you have a genuinely large fleet
- Plugin system is practical: drop any executable into the plugin directory and the agent runs it on a schedule, pushing whatever metrics it emits — no SDK required
- Grafana datasource plugin exists, so you can front it with a dashboard toolchain you already know rather than learning a custom UI
- Has been production-tested at Xiaomi scale, so the core time-series storage and alert evaluation paths are not naive
- The project is in soft sunset: the README's first substantive paragraph says 'go use Nightingale instead,' last meaningful activity is 2024, and Go >= 1.6 is listed as a prerequisite — a runtime from 2016 that predates modules entirely
- Setup is a pain: you manually run 5 separate SQL files, stand up MySQL and Redis yourself, start 10+ individual processes, and the only upgrade documentation is a link to a Chinese blog post on jianshu.com
- No native Prometheus exposition format — there's a falcon2p8s bridge component but adding a shim to speak the format every other tool already speaks is a sign of architectural age, not a feature
- Agent-per-host polling design is fundamentally mismatched with ephemeral workloads: every k8s pod churn event creates registration/deregistration noise, which is exactly why the maintainers are pointing you at Nightingale