Cacti
RRDtool-based network graphing and monitoring solution
Cacti is a complete network graphing solution that harnesses RRDtool for data storage and graphing. It polls devices over SNMP and scripts, presenting historical performance data through a web interface.
Key features
- RRDtool-based graphing
- SNMP and script polling
- Plugin architecture
- Templating for devices
Pros & cons
Strengths
- Mature and reliable
- Detailed graph templates
Trade-offs
- Dated interface
- Configuration can be tedious
Cacti replaces
Last reviewed Sep 13, 2026 · 849 words
Cacti is a graphing engine that happens to poll devices. Everything it does is in service of RRDtool graphs: it asks a switch for interface counters over SNMP every 5 minutes, stores them in round-robin files that never grow, and draws graphs from templates that people have refined since 2001. The result is the most precise, most customisable per-port graphing you can self-host, and the price is configuration: every device is added by hand, every graph is created from a template you pick, and the interface looks like the year it was born. Whether that trade suits you is the whole question.
What you are actually buying
RRD files are fixed-size. A graph of one interface for 10 years costs the same disk as a graph for 1 week, and old data is consolidated rather than deleted. Cacti wraps that with a template system: a device template says "this is a Cisco switch, it has these interfaces, graph in and out bits per second, errors, and CPU", and one click creates the whole set. The graph tree lets you arrange 2,000 graphs by site, rack and device, and the 1.x line added aggregate graphs, a real-time mode, and a permissions model good enough for a NOC with junior staff. If you have ever wanted a single page with every uplink in the building on it, drawn identically, this is that tool.
The install that doesn't fight you
The stack is PHP, MariaDB or MySQL, RRDtool, net-snmp and a web server. Distribution packages exist, the project's own install guide is thorough, and there are community Docker images but no official one, so bare metal or a VM is where most people run it. Cacti's installer checks a list of database settings and refuses to continue until they are right; the ones that catch everyone are innodb_file_per_table, a large enough innodb_buffer_pool_size (it wants about a quarter of RAM), max_heap_table_size and tmp_table_size in the hundreds of MB, and the MySQL timezone tables loaded with mysql_tzinfo_to_sys. Set them before running the web installer, not after, and give the box the 512 MB floor at minimum; 2 GB is comfortable for a few hundred devices. Pick the poller interval once, before you add devices: changing it later means recreating every RRD file, because the step is baked into each one.
Swap cmd.php for spine early
The default poller is a PHP script, cmd.php, and it is fine for 20 devices. Beyond that, install spine, the threaded C poller, point Settings, Poller at it, and watch a poll cycle drop from minutes to seconds. It is a separate package (cacti-spine on most distributions) and needs the same database credentials in spine.conf. The poller must finish inside its interval, and the Cacti log tells you when it does not; that is the number to watch as you grow.
Templates are where the time goes
Adding a device is: hostname, SNMP community or v3 credentials, pick a device template, then choose which interfaces and data queries to graph. Cacti ships templates for generic SNMP hosts, Linux, Windows, Cisco and a few more, and the package import in 1.x plus the forums supply hundreds of others. For gear with a vendor MIB and no template, you build one, which means learning data queries and their XML; budget a day the first time. This is the single biggest reason people leave. Plugins soften it: thold adds thresholds and alerting (Cacti has no alerts without it), monitor gives a green-and-red status board, weathermap draws network diagrams with live utilisation, and the plugin API is stable enough that these have survived a decade.
LibreNMS does most of it with less typing
LibreNMS auto-discovers devices, ports, sensors and neighbours, ships alerting in the core, and draws serviceable RRD graphs of its own. For a network of any size the hours saved are real, and it is the safer default for someone starting today. Cacti wins where you want exact control over what is graphed and how it is drawn, where you have odd gear that needs a hand-built template anyway, or where a NOC already has years of Cacti history it is not going to throw away. Zabbix is the pick if alerting matters more than graphs, and if you already run Prometheus with Grafana, snmp_exporter covers the same counters with modern dashboards at the cost of RRD's tidy fixed-size storage. The monitoring category has all of these.
What I'd do
Home network with a managed switch and a router: LibreNMS, and be done in an evening. Anything with Cisco, Juniper or Aruba gear where you want per-port graphs that look the same for a decade: Cacti on a VM, MariaDB tuned before install, spine from day one, thold and weathermap installed, and a 5-minute poller you never change. It is 25 years old and works exactly the way it did last year, which in monitoring is a compliment.
Compare Cacti
11 head-to-head comparisons.
Similar monitoring & status apps
Uptime Kuma
Monitoring & StatusEasy self-hosted uptime monitoring tool
Replaces Pingdom, UptimeRobot
Netdata
Monitoring & StatusReal-time per-second infrastructure monitoring
Replaces Datadog, New Relic
Grafana
Monitoring & StatusOpen observability dashboards and visualization
Replaces Datadog
Prometheus
Monitoring & StatusMetrics-based monitoring and alerting toolkit
Replaces Datadog
Glances
Monitoring & StatusCross-platform system monitoring at a glance
Replaces Datadog
InfluxDB
Monitoring & StatusPurpose-built time series database for metrics and events
Replaces Datadog, AWS Timestream