CA

Cacti

RRDtool-based network graphing and monitoring solution

Monitoring & Status ★ 1.9k stars Medium setup GPL-2.0

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