The full packet capture system developed at AOL since 2012 under the name Moloch was renamed Arkime in July 2021, together with the 3.0 release. The licence stays Apache 2.0 and the repository moved from AOL’s GitHub organisation to its own (arkime/arkime). The project site puts the change down to a wish to avoid the connotations of the previous name; technically nothing changes.

Context and problem

Full packet capture (fPCAP) records the entire network traffic to disk, payload included, not just flow metadata. It is there for retrospective analysis: when an IDS alert, an indicator of compromise or an external report arrives days late, having the raw packets for that period means you can reconstruct what actually crossed the wire, instead of stopping at a NetFlow record or an already-aggregated application log.

The problem is scale. The Arkime documentation estimates that 1 Gbps of uncompressed traffic consumes on the order of 11 TB of disk per day. At those figures recording is the easy part; the real constraint is keeping the data searchable within useful time and rotating storage without filling the volume. Three components share these responsibilities.

Architecture

There are three main components.

  • capture — a C process that reads packets from the interface, writes them to disk as PCAP files and sends Elasticsearch the metadata for each session. There is a structural requirement: all packets in the same 5-tuple (source IP, destination IP, source port, destination port, protocol) must go through the same capture process, a constraint to respect when spreading traffic across queues or nodes.
  • viewer — a Node.js web interface for search, session inspection and PCAP download. It is also the component that deletes PCAP files when free disk space drops below the configured thresholds.
  • Elasticsearch — the database of session metadata, not of packets. With 3.0 the viewer was rewritten on Vue 3.

What matters is understanding what lands where. Raw packets stay on disk as PCAP files on the capture node; only the SPI (Session Profile Information) goes to Elasticsearch — the fields extracted per flow: addresses, ports, bytes and duration — plus whatever application fields the parsers can recognise. Search works against the SPI index; the PCAP is fetched and served on demand by the node that wrote it.

The critical point: separating PCAP and index

The documentation is explicit about a constraint that is easy to underrate at provisioning time: the PCAP directory (pcapDir) and the Elasticsearch data directory must not sit on the same filesystem. The reason is operational. The two deletion paths are independent and follow different logic.

PCAP files are deleted by the viewer when space is needed, based on disk thresholds: a rotation governed by the capacity of the capture volume. Session metadata, by contrast, is left untouched by that mechanism: it expires through Elasticsearch ILM/ISM policies or via scheduled db.pl expire runs under cron. The two retentions are decoupled. If both datasets share a filesystem, the space pressure from PCAP — which grows far faster — ends up interfering with the index, and an aggressive PCAP rotation puts at risk the very database that is meant to outlive the packets. Keeping them on distinct volumes makes capacity planning a separable calculation: the PCAP volume sizing sets the packet retention window, the index sizing sets the metadata searchability window. The two windows can and usually must differ, because a flow’s SPI costs orders of magnitude less than its payload.

Parsers and enrichment

The value of the SPI depends on how many fields the parsers extract. Arkime ships parsers for the common application protocols — HTTP (URI, host, user-agent, response code), TLS (SNI, certificate issuer and subject, fingerprint), DNS (query, type, response), plus SMB, SSH, SMTP and others. These fields become indexed and searchable from the interface: you query on host.http or on the SNI of an encrypted connection without opening a single packet.

External enrichment runs through WISE (With Intelligence See Everything), the subsystem that annotates sessions with third-party data — GeoIP, ASN, reputation lists, threat intelligence feeds — loaded from files, Redis or HTTP endpoints. WISE adds no capture capability: it enriches metadata that is already indexed, so a search can filter, say, sessions toward addresses present in a list.

The typical IDS integration follows the same logic: alerts (from Suricata, for instance) are correlated to the matching sessions in the index, so you can go from the alert to the full PCAP of the flow that produced it. This is exactly the use case that justifies fPCAP: the alert says something happened, the packet says what.

Limits

The model scales horizontally by adding capture nodes onto a shared Elasticsearch cluster, but with three constraints to size up front. The first is PCAP storage, linear in throughput and retention: the 11 TB/day per Gbps cited above sets a practical ceiling on the retrospective window. The second is the Elasticsearch cluster, which must absorb the session insertion rate and the search load: the useful metadata window is bounded by index capacity, not PCAP capacity. The third is the 5-tuple-to-same-process constraint, which conditions how parallelisation and load balancing across capture interfaces can be exploited.

There remains a limit intrinsic to fPCAP that no architecture resolves: encrypted traffic stays opaque in the payload. Arkime indexes TLS metadata — SNI, certificates — but not the application content under encryption. fPCAP preserves what crossed the wire; what it means, for encrypted flows, depends on how much the metadata leaves in clear.

Cover image: Screenshot of the Wireshark program analysing a captured network packet: a DNS query, with the Ethernet, IP, UDP and DNS protocol… — screenshot by Laurachappell, CC BY-SA 4.0 — https://commons.wikimedia.org/wiki/File:Wireshark_Network_Analyzer_Screen.png