pmacct turns flow and routing telemetry into accounting records you can query

A family of daemons, one per kind of telemetry

pmacct is described as a small set of multi-purpose passive network monitoring tools, and the bracket in the project description lists the sources it reads: NetFlow, IPFIX, sFlow, libpcap, BGP, BMP, RPKI, IGP and Streaming Telemetry.

That list is the scope of the project. The subject is traffic and routing telemetry that a network already produces, and the job is to turn it into something you can account for. Nothing here probes the network, and nothing here is an IDS.

The repository shows the family in the example configurations. There are files for pmacctd, for nfacctd and for sfacctd, including pmacctd-imt.conf.example, pmacctd-multiple-plugins.conf.example, pmacctd-sql.conf.example, pmacctd-sqlite3.conf.example, nfacctd-print.conf.example and nfacctd-sql.conf.example. The names describe the shape of the set: pmacctd is the configurable one that can load several plugins at once, while nfacctd and sfacctd are the single purpose daemons, and the Docker documentation uses sfacctd as its worked example.

The nfacctd naming is the clearest statement of what the project does. An accounting daemon takes the flow records the network produced and turns them into a stream of counted, tagged records, and pmacct's job is to get from the telemetry to a database row with the right tags in it.

The homepage is pmacct.net, the documentation is on the GitHub wiki, and the project is written in C. The last push was on 2026-10-15 and the project is not archived, although the release tags are older, with v1.7.9 from 2024-08-01, v1.7.8 from 2022-12-31 and v1.7.7 from 2022-03-02.

One process with plugins, or one process per source

The example configurations point at two different architectures, and choosing between them is the first decision an operator makes.

The plugin based approach is pmacctd, and the example configuration is called pmacctd-multiple-plugins.conf.example. One daemon loads several plugins, each of which handles a different source, and the daemon correlates what they produce. That is the shape you want when a router exports NetFlow to you and a BGP session or a BMP feed from a monitoring system is describing the topology, because the plugin set can join the two.

The single protocol approach is the standalone daemons, nfacctd and sfacctd, each with its own configuration. sfacctd is the one the Docker documentation uses, and the example in the README runs it with a configuration file mounted into the container.

 ~# docker pull pmacct/sfacctd:latest
 ~# docker run -v /path/to/sfacctd.conf:/etc/pmacct/sfacctd.conf pmacct/sfacctd

The image is on Docker Hub under the pmacct organisation, and the README points at a Docker documentation section for more detail, options and troubleshooting.

The difference in approach between the two is worth being explicit about. A single protocol daemon is simple to reason about and simple to run, and it does one job. The plugin daemon is the more interesting arrangement, because it is the only way to have the accounting and the topology in the same process, and the IMT example configuration, which is named for the protocol that is part of the name, is the case where that matters.

Both share the same configuration language and the same output layer, so the choice is about how much correlation you need, not about which file format you end up with.

The output side is where the choices live

pmacct is a collector, and a collector is only as useful as what it feeds. The topic list of the repository names the sinks, and the examples directory contains the configurations to match them.

There is a Kafka directory and an AMQP directory under examples/, alongside an avro directory, which tells you that the messaging path is a first class output rather than an afterthought. The SQL side has its own top level directory in the repository, described in the documentation list as SQL documentation, default SQL schemas and customization tips, and there is a scripts/ directory and a docs/ directory for internals, UNIX signals and SQL triggers documents.

The database targets are named in the topics: MySQL, PostgreSQL and SQLite3, along with JSON as an output format. The configuration examples include pmacctd-sql.conf.example and pmacctd-sqlite3.conf.example side by side, which suggests SQLite is a supported sink in its own right rather than only a development convenience.

Two other dependencies in the topic list point at what the data is used for. ndpi is a deep packet inspection library, and geoip2 is a GeoIP database format, so the pipeline can enrich a flow with protocol and geography before it is written out. The Avro example is the format that fits streaming consumers, since a schema carrying Avro data is what a Kafka consumer usually expects.

The point of the architecture is that the accounting record, not the raw flow, is the product. pmacct decides how a flow is classified, tagged and aggregated, and everything downstream works on that.

Configuration is documented as files, not as a wizard

The documentation section of the README is organised around files, and reading it tells you how the project expects to be used.

There is CONFIG-KEYS, the available configuration directives explained. There is QUICKSTART, with examples, command lines and quickstart guides. There is a ChangeLog, a history of features version by version, and a FAQS document. The docs/ directory holds miscellaneous internals, UNIX signals and SQL triggers documents, the examples/ directory holds sample configs, maps, AMQP and Kafka consumers and clients, and the sql/ directory holds the SQL documentation and default schemas with customization tips.

That is a lot of surface, and the file layout is the way a project of this age explains itself. There is no configuration generator and no dashboard, and the reason is visible in the directory listing: a copy of the configuration is part of the deliverable, because the same configuration has to run on a server, in a container, and on a laptop during development, and because a file can be diffed and reviewed.

The examples directory reinforces the point. Alongside the daemon configurations there are map files, bgp_agent.map.example, bgp_xconnects.map.example, flow_to_rd.map.example, lpref.map.example, med.map.example, pcap_interfaces.map.example, pretag.map.example, and list files such as allow.lst.example, bgp_md5.lst.example, networks.lst.example, ports.lst.example and primitives.lst.example. These are the pieces that turn a raw export into something with addresses, tags and routing context attached.

The Quickstart and the examples are the documentation a new operator should read first, and the FAQS document is where the recurring questions are answered.

Building from git takes autotools and a short dependency list

The build section starts with dependencies, and it gives the package list for two distributions.

For Debian and Ubuntu the README lists apt-get install libpcap-dev pkg-config libtool autoconf automake make bash libstdc++-dev g++, and for CentOS and RHEL the equivalent yum install libpcap-devel pkgconfig libtool autoconf automake make bash libstdc++-devel gcc-c++.

Then the build itself, which is the standard autotools sequence.

 ~# git clone https://github.com/pmacct/pmacct.git
 ~# cd pmacct
 ~# ./autogen.sh
 ~# ./configure #check-out available configure knobs via ./configure --help
 ~# make
 ~# make install #with super-user permission

The comment on the configure line is the instruction that matters most in practice, because the daemon set is not uniform. A deployment that only needs a flow collector does not need the BGP and BMP machinery, and the configure knobs are how you leave that out.

The repository is laid out like the build system suggests, with configure.ac and a Makefile.am at the top level, an autogen.sh, the m4/ directory for the autoconf macros, the C sources in src/ and the headers in include/, the test-framework/ and tests/ directories, and a ci/ directory for continuous integration.

The Docker route skips all of that for the common case, and the README is clear that it is the path most people should take.

The licence is the one thing still in motion

The licence of the project is the part of the README that reads like a status report rather than a statement.

The repository contains a LICENSE.template file and a COPYING file, and the project description records the licence as one that GitHub cannot classify. Then there is a section headed LICENSE INITIATIVE, which says the pmacct project is looking to make its code base available under a more permissive BSD style licence, with the motivation and the process described in an announcement linked from the README.

That is a meaningful thing for an adopter to know. The code today is under terms that are not one of the standard licences, and the project has publicly stated an intention to move to a permissive BSD style grant. Anyone evaluating pmacct for commercial use needs to read the current terms and the announcement rather than assume either the present or the future state.

The rest of the project metadata is ordinary. The repository is not archived, the CI workflow badge is on the master branch, the Docker images are published under the pmacct organisation, and the contributing section explains the fork, commit and pull request flow, with a separate note that wiki content is edited online or cloned locally by collaborators.

For a project that has been doing this since long before the current wave of flow and telemetry standards, the fact that it is still changing its licence terms is a sign that the maintainers are still in the middle of a project rather than maintaining a fossil.

Editorial conclusion

pmacct fits a network operator who needs per flow accounting from routers that already export flow data, and who wants the result in a database or a queue rather than in a collector's proprietary format. It is the wrong tool for a network that exports nothing, since the daemons consume telemetry rather than generate it. Verify first which source your devices export and in which version, check that the plugin or daemon you pick matches it, and read the licensing announcement, because the project is explicitly working towards a more permissive BSD style licence and the terms in the repository today are not the ones it intends to keep.

Frequently asked questions

Official sources

1. Issues
2. pmacct/pmacct on GitHub
3. Project website
4. README
5. Releases