Zeek vs Arkime: which to choose

Zeek or Arkime: which fits your network monitoring question

If your SOC needs to answer "what talked to what, and what did it say" across the network, Zeek is usually the starting point. If it needs to replay the exact bytes of a session after an alert fires, Arkime is the better fit. Both are open source and both run passively on a sensor, but they store different things and cost different amounts to keep. Zeek is BSD-licensed and writes protocol logs such as connections, DNS, HTTP, SSL certificates and SMTP as tab-separated or JSON files that a SIEM can ingest. Its detection logic is written in its own scripting language, and its storage footprint is typically far smaller than a full packet archive. Arkime, licensed under Apache-2.0, captures PCAP to local disk on each sensor, parses packets, and sends session metadata to OpenSearch or Elasticsearch so analysts can search sessions and open the original packets in Wireshark-compatible format.

Zeek fits teams that want scripted, protocol-level detection, long retention of compact logs, and a SIEM that already handles structured events. Arkime fits teams whose investigations depend on the payload itself, such as reconstructing a file transfer or proving what a command contained. The decision turns on three questions. First, can metadata alone answer the questions your analysts ask in a typical incident? Second, how far back must packets be kept, and does that requirement come from your own incident response policy or from an external obligation you must confirm with counsel or your assessor? Third, how much sensor disk and cluster capacity can you fund? Arkime keeps packets on the sensors, so PCAP retention depends on sensor disk, while metadata retention depends on the size of the search cluster.

Many teams do not have to pick one. Malcolm, which is Apache-2.0 licensed, runs Zeek and Arkime together and adds Suricata alerts and OpenSearch Dashboards, so the metadata and packet views share one interface. Before you commit, run a short test on a representative segment. Measure how many gigabytes per day each source produces, how long your sensors hold PCAP at that rate, and whether analysts resolve a sample of past incidents from logs alone. Ask any vendor or integrator to size the disk and cluster for your traffic rate and retention period in writing, and confirm current release lines such as Malcolm releases before you standardize on a version.

Which platform fits which monitoring scenario

This table maps common monitoring scenarios to the platform that fits each one better, with the condition that would flip the choice. Read each row as a starting point: the answer depends on how much you need to retain, whether you need the original bytes, and how much storage and operating effort your team can carry.

Scenario	Better fit and reason	When the other platform is the better choice
Protocol-level threat hunting with long metadata retention	Zeek. It writes connection, DNS, HTTP, SSL and SMTP logs that stay small enough to keep for long periods, and its scripts let analysts add detections without replaying traffic.	Arkime fits when hunters need to pivot from a metadata hit to the exact bytes of the session, not only the log fields.
Incident responders who need raw packets for one session	Arkime. Its capture stores PCAP on sensors and links each session to its packets, so responders can open the exact conversation in a browser and export standard PCAP for Wireshark.	Zeek is the better choice when the question is about behavior patterns across many hosts and no packet evidence is needed for the case.
ICS or OT visibility	Zeek with a Malcolm deployment. Zeek parses a wide set of ICS and OT protocols, including Modbus, DNP3, S7comm and PROFINET, and Malcolm documents which of these Arkime also parses.	Arkime alone fits when the OT protocol you need is in its parser set and the team's main need is reviewing packets from specific OT sessions. Confirm protocol coverage for your exact devices.
Small team with limited storage	Zeek, usually. Metadata is far smaller than full packet capture, so the same disk supports a longer lookback window. Confirm sizing with your own traffic volume before committing.	Arkime fits a small team only when the sensor disk is sized for the packets they must keep and the team has a clear reason to review full sessions.
Regulated environment that must show evidence of network activity	Both, in practice. Zeek logs give auditors a consistent record of network activity, and Arkime PCAP shows what was actually transmitted for a specific incident. Confirm with your assessor which evidence form they accept.	Zeek alone may satisfy a monitoring-only requirement when the assessor accepts log records and retention is documented. Packet retention adds storage and access-control obligations, so confirm them before you start.
Signature-based detection	Neither platform is the primary choice. The Zeek documentation says it is not a classic signature IDS and points users to Suricata for that job, and Arkime is designed to work alongside an IDS.	Pair either platform with Suricata or Snort when signature matching is a requirement. Confirm integration steps with the vendor documentation.

How Zeek and Arkime are built and what that means for operations

Zeek and Arkime both sit on the network tap, but they keep different things: Zeek keeps structured logs about sessions, while Arkime keeps the packets and an index of session metadata. The components below show where each platform stores data, what has to scale, and which parts need patching on your own hardware.

Zeek scripting and log output

Zeek writes connection records and application transcripts such as HTTP, DNS, SSL and SMTP to tab-separated or JSON files by default. Because logging and all default analyses are implemented as scripts, the log schema is something you can change, and every custom script you add is code your team must test and keep working across upgrades. Check which log fields your detections depend on before you change or disable any default script. Zeek does not keep payloads, so questions about exact bytes need packets from another source.

Zeek clusters and the manager

Large Zeek deployments run back-end workers behind a front-end load balancer, coordinated by a central manager, and ZeekControl supports this layout out of the box. The manager and worker configuration, and the traffic split across workers, become part of your operating model. Ask who owns cluster health checks, how log shipping fails over, and how you add capacity when a sensor saturates. This is the main place where Zeek's operating effort grows with traffic volume.

Arkime capture and local PCAP

Arkime capture is a multithreaded C application that reads traffic, writes PCAP files to local disk and sends session metadata to OpenSearch or Elasticsearch. The packets stay on the sensors, so PCAP retention is limited by sensor disk space, while metadata retention depends on the size of the search cluster. Plan disk and index capacity separately and confirm both retention targets with your compliance owner before you size hardware.

Node.js viewer on each capture machine

The Arkime viewer is a Node.js application that runs on every capture machine, serves the web interface and delivers packets to the browser. Each capture host therefore carries a web-facing service as well as capture processes, so patching, access control and TLS configuration apply to every sensor, not only the central cluster. Confirm how you restrict viewer access, and whether your security team accepts a web service on each sensor.

Optional Arkime applications

Arkime's optional applications include esProxy between capture and the database, Parliament as a front door to several clusters, Cont3xt for contextual intelligence and wiseService for adding threat intelligence to session metadata. Each one is a separate service you may need to deploy, scale and patch. Decide early which of these you need, because a multi-cluster design using Parliament changes where users log in and where searches run.

Capability comparison: Zeek against Arkime

This table sets Zeek's protocol logs and scripting against Arkime's packet capture and session search, row by row. Read the rows on output and retention first, because they decide how much storage and search effort each platform needs.

Capability	Zeek	Arkime
License	BSD license (permissive)	Apache-2.0
Latest release noted in sources	Zeek 9.0.0 (LTS), with Zeek 8.0.10 as the previous LTS	Arkime 6.8.0, published September 30, 2026
Primary output	Connection records and application transcripts in TSV or JSON logs	PCAP files on sensor disk plus indexed session metadata
Signature detection	Not a classic signature IDS; the Zeek documentation points users to tools such as Suricata	Not meant to replace an IDS; the README says it works alongside one
Retention driver	Log volume and the external database or SIEM that stores the logs	Sensor disk space for packets; OpenSearch or Elasticsearch cluster size for metadata
Detection logic	Turing-complete scripting language; default analyses are scripts	Analysis is driven by the capture pipeline and optional applications such as wiseService for threat intelligence
Scaling claim	Large sites run clusters with a load balancer, back-end instances and a manager under ZeekControl	README cites tens of gigabits per second across many systems; confirm sizing for your own sensors
Identity integration in Malcolm	Malcolm supports Keycloak or LDAP authentication for the stack; confirm which components each login covers	Same Malcolm Keycloak or LDAP authentication; confirm access controls on packet download with your deployment

License terms and what each platform costs to adopt

Zeek is licensed under the permissive BSD license, and Corelight acts as custodian of the project, providing financial backing and code without owning it. The supplied facts do not describe a paid Zeek edition or tier, so the license cost is zero. What you pay for is the work around the software: the sensors, the traffic feeds, the scripts that match your environment, and the log pipeline that carries Zeek output into a SIEM or database.

License scope: BSD licensing permits internal use and modification without a license fee. Confirm the exact terms in the project's own license file before you redistribute a modified build.
Paid support: Ask the Zeek project and Corelight, in writing, which support or commercial services are available, and what they cover. The supplied facts do not list any.
Recurring labor: Sensor hardware, tuning, script maintenance and upgrades to the 9.0.0 LTS or 8.0.10 LTS lines recur every year, and each needs a named owner.
Log storage: Zeek writes logs to local files, so storage and shipping costs depend on your SIEM or database choice.
Check: Confirm with your own security team which Zeek version your sensor image will use, and who will maintain it after go-live.

Why Malcolm runs Zeek and Arkime together for ICS protocols

Malcolm runs Zeek and Arkime side by side because OT incident review often needs both a protocol-level record and the original packets behind it. Malcolm processes full packet capture files, Zeek logs and Suricata alerts, normalizes and correlates them, and uses Arkime to find and identify network sessions while OpenSearch Dashboards handles visualization. Zeek supplies the parsed industrial protocol fields, and Arkime supplies the session search and the PCAP that an analyst can open in a tool such as Wireshark. The key decision is whether your review workflow needs the raw bytes, not whether Malcolm can ingest them.

Zeek's protocol coverage is the broad one. Malcolm's protocol documentation lists ICS and OT protocols parsed by Zeek, including BACnet, BSAP, DNP3, EtherCAT, EtherNet/IP, HART-IP, IEC 60870-5-104, Modbus, OPC UA Binary, PROFINET, S7comm and Synchrophasor, while only a smaller subset is also parsed by Arkime. Before you commit to a design, check the Malcolm protocols documentation against the exact fields your plant uses, and confirm which of your protocols appear on the Arkime side. Zeek alone is enough when your questions are answered by fields such as function codes, read and write events or device conversations, and when retaining packets for a long period is not a requirement. Packet retention also consumes sensor disk, so a metadata-only design is cheaper to run.

Running both makes sense when a finding must be proven at the packet level, such as a disputed write command to a controller or an unexplained S7comm session that needs byte-level review. Arkime keeps PCAP on the sensors, so retention length depends on sensor disk space, which you should size against your review window before deployment. Malcolm's Kubernetes deployment is described by its maintainers as a new and still somewhat experimental feature, so if you plan to run the stack on Kubernetes, treat that path as a pilot and confirm its support posture with the project. A Malcolm documentation review of the container deployment is the natural next read before you pick a host model.

What drives the running cost of Zeek and Arkime

Zeek and Arkime carry most of their running cost in storage, compute and people rather than licenses, since both are open source. The cards below separate one-time build work from costs that recur every month, and list what to ask for in a written quote.

Sensor disk for PCAP

Arkime keeps packets on the sensors, so PCAP retention depends on sensor disk space. This is the cost that grows fastest with traffic volume and retention days, and it recurs as hardware refreshes and disks fill. Ask the implementer how retention is enforced per sensor, how disk pressure is alarmed, and what happens to older packets when a sensor fills. Zeek logs are far smaller, so this line item usually separates the two designs most clearly.

Cluster size for metadata

Session metadata and Zeek logs both land in an OpenSearch or Elasticsearch cluster, so index storage, shard count and replica settings drive that cost. Metadata volume recurs with traffic and with how long you keep it searchable. Ask for the assumed daily volume, retention by index, replica count and the hot and warm tiering plan. Ask whether the quote includes cluster capacity growth or only the first build.

Sensor and compute hardware

Zeek is largely single-threaded per worker and scales by adding workers or cluster nodes, while Arkime capture is multithreaded and benefits from NIC and CPU choices made for the traffic rate. Hardware is a one-time purchase or lease, but it recurs at refresh. Ask the implementer for the traffic rate, packet size assumptions, NIC type and the number of sensors each site needs, and whether the quote includes spares and out-of-band management.

Staff skills for Zeek and PCAP

Writing and tuning Zeek scripts, and reading packets in Wireshark or the Arkime viewer, are skills that few generalist operators already have. This is a recurring payroll or contractor cost, and it rises when detections need custom scripts or when analysts must work across both tools. Ask who will maintain scripts after handover, what training is included, and whether the team can answer a packet-level question without a specialist.

Malcolm and Arkime upkeep

Malcolm bundles Zeek, Arkime, OpenSearch Dashboards and other components into containers, so each upgrade touches several parts at once. Kubernetes deployment is described as new and still somewhat experimental, which adds test effort if you choose it. Upgrade work recurs with each release. Ask how upgrades are tested, who owns rollback, which versions are supported, and how security patches are delivered between releases.

Outside implementation and support

Fixed-scope implementation covers planning, sensor placement, parser and dashboard work, hardening and handover, and is usually a one-time cost. Ongoing support, upgrades and continuous testing are typically a recurring retainer. Ask for a written scope listing sensors, sites, protocols to parse, dashboards delivered, documentation and training, plus what is excluded, such as storage expansion or new Zeek scripts after handover.

Moving from metadata-only Zeek to Zeek with Arkime packet capture, or back

This sequence moves a team between Zeek-only metadata and Zeek paired with Arkime packet capture, so retention, storage and detections are settled before any sensor is changed. The result is a documented path that a reviewer can check at each stage.

Confirm retention and investigation requirements
The security lead, with the SOC and the compliance owner, writes down which questions must be answered after the fact, how far back the answers must reach, and whether raw packets are needed as evidence or metadata is enough. Arkime keeps packets on sensor disks and metadata in the OpenSearch or Elasticsearch cluster, so these two retention periods are separate decisions. Done when the requirement is signed off as two numbers, one for PCAP and one for metadata, and the compliance owner confirms whether any rule requires packet evidence. Confirm the exact obligations with the relevant regulator or assessor rather than assuming them.
Size sensors and storage against those requirements
The platform engineer estimates PCAP volume from observed traffic at the monitoring points and checks sensor disk space against the PCAP retention target. Arkime's README ties PCAP retention to sensor disk space and metadata retention to the size of the search cluster, so both are sized separately. Ask the Arkime maintainers or your Linux and hardware vendors to confirm sizing guidance for your traffic profile before purchase. Done when a written sizing sheet shows disk per sensor and cluster capacity, and the owner accepts it.
Deploy Arkime capture beside the existing Zeek sensors
The platform team installs Arkime capture and viewer on the sensors that already run Zeek, configured to write PCAP to local disk and send session metadata to the search cluster. Existing Zeek output keeps flowing to the same log pipeline throughout, so the current detections are not interrupted. Keep the Arkime configuration in version control and note which interfaces each instance monitors. Done when Arkime reports packets on each sensor and a test session can be found in the viewer and matched to the corresponding Zeek connection record.
Set index templates and retention policy for each data type
The search team creates separate index templates and lifecycle rules for Arkime session metadata and for Zeek logs, because the two are indexed and aged out on different schedules. Retention for PCAP is enforced by the sensor disk policy, which is a different control from index deletion, so both must be documented. Confirm the index and lifecycle settings with the search backend's documentation and your own environment before enabling deletion. Done when a test index has the expected fields, the lifecycle policy is visible in the cluster, and the PCAP purge job is tested on a non-production sensor.
Validate Zeek log schemas and detections still run
The detection engineer compares Zeek log fields and detection scripts before and after the change, confirming that no Zeek script, log format or dashboard query has been altered by the Arkime deployment. Zeek's default analyses are implemented as scripts, so any local script changes should be tracked and retested. Run a replay of known traffic through the pipeline if one is available. Done when each detection produces the same alert on the test set, and any difference is recorded with an owner and a fix.
Rebuild dashboards and Arkime links in the analyst workflow
The SOC lead rebuilds dashboards and pivots so that an analyst can move from a Zeek alert to the matching Arkime session and back. Zeek script outputs and log formats carry over, but Arkime sensor configuration, index templates and dashboards are rebuilt for this environment, so they need explicit review. Test the workflow with at least one analyst who did not build it. Done when the analyst can open the packets for a flagged connection within the viewer and the workflow is written into the runbook.
Retire the older path or keep both on purpose
The security lead decides whether to keep metadata-only Zeek, keep Zeek with Arkime, or run both for a defined period. If moving back to metadata-only, Arkime is stopped on each sensor and its index is retained or deleted according to the retention decision made in step one. If keeping both, the runbook records which system is authoritative for each question. Done when the decision is recorded, the removed components are deleted or disabled with evidence, and the retention and access controls match the signed requirement.

Where Zeek and Arkime projects usually run long

Implementation time for a Zeek and Arkime deployment rarely goes to installing the software. It goes to sensor placement and traffic mirroring, because Zeek and Arkime only see what the mirror or tap delivers. Before anyone tunes a script, the team should map every segment that matters, confirm each sensor sees both directions of the traffic it is meant to inspect, and document the gaps that remain. Those gaps are the most common source of delay, since they surface only when an analyst asks a question the data cannot answer.

Zeek work continues after go-live. Script tuning, log shipping to a SIEM and the handling of noisy notices take iterations, and each change needs regression checks. Arkime work centers on capture disk and OpenSearch or Elasticsearch sizing. Packet retention depends on sensor disk, and metadata retention depends on cluster size, so storage growth is often underestimated. Ask the vendor or your own test lab to model retention at your real traffic volume before you commit to a retention target. In Malcolm, authentication through Keycloak or LDAP and the enrichment sources, such as NetBox for asset inventory, MISP and STIX/TAXII feeding the Zeek Intelligence Framework, each add a configuration and validation step.

Two areas need extra time. OT protocol validation is one: Malcolm documents Zeek parsing for a range of ICS protocols, but parsing support does not prove that your plant traffic is decoded correctly, so test with captures from your own environment. The other is acceptance testing. Write a set of real incident questions, such as which hosts contacted a given domain in the last thirty days (illustrative), and confirm the platform answers each one from packets, metadata or both. Teams that skip this step often learn in an actual investigation that the data they stored cannot answer the question.

Questions buyers ask before choosing Zeek or Arkime

Can Zeek store full network packets?

No, not by default. Zeek writes connection records and application-layer transcripts, such as HTTP sessions, DNS requests and replies, SSL certificates and SMTP content, to tab-separated or JSON log files. That makes it a metadata source for investigations, not a packet store. If your investigators need the original bytes of a session, you need a separate packet capture layer such as Arkime, or a platform like Malcolm that runs both. Confirm with your analysts which evidence they must replay, since that answer decides whether packet storage is in scope at all.

How long can PCAP be kept, and what limits retention?

Retention is set by sensor disk space, not by the search cluster. Arkime keeps packets on the capture machines and writes them as PCAP files to local disk, so the amount you can keep depends on how much storage each sensor has and how much traffic it sees. Session metadata is stored in OpenSearch or Elasticsearch, and its retention depends on that cluster's size. Ask your team to model peak traffic against the disk you can dedicate per sensor, and confirm the rotation behavior in the Arkime documentation for your version before you commit to a retention target.

Does Arkime replace an intrusion detection system?

No. The Arkime README says it is not meant to replace an IDS but to work alongside one. Arkime answers what happened in a session by letting analysts search and replay packets, while an IDS such as Suricata or a Zeek-based detection pipeline raises alerts. Plan both roles explicitly in your architecture, and decide which tool owns alert triage and which owns evidence retrieval. Treating Arkime as the detection layer is a common scoping error.

How much effort does this work take in-house compared with outside help?

The effort depends on how many components you run and how many sensors you add. A single Zeek deployment plus a capture sensor is a different job from a multi-site cluster with a search backend, dashboards, authentication and upgrades. In-house work carries the recurring costs of patching, tuning, storage planning and on-call response. Outside help is usually bought as a fixed-scope engagement for design, implementation and documentation, with retainers for ongoing upgrades and support. Ask any provider, including DeployOpen, for a written scope that lists sensors, sites, integrations, deliverables and timelines before comparing quotes.

What skills does the team need to run Zeek and Arkime?

Plan for network analysts who read protocol logs and write or tune Zeek scripts, and for engineers who can operate Linux servers, containers, storage and the search backend. Arkime also needs people who understand packet captures and retention policy. Zeek's scripting language is Turing-complete, so detection content becomes code that needs review and version control. Confirm the staffing model during scoping, including who owns on-call response, who handles upgrades and who signs off on changes to capture and retention settings.

Can a team run Malcolm without a dedicated SOC platform team?

It depends on your operating model. Malcolm runs as a set of containers managed with setup and run-time scripts, and it is intended for long-term use on a Linux server in a SOC as well as short-term incident response on a laptop. Its Kubernetes deployment is documented but described by the project as new and still somewhat experimental, which argues for Docker-based operation unless your platform team already runs Kubernetes well. Malcolm still needs someone to own storage, upgrades, authentication and ICS protocol coverage, so confirm who that is before you deploy.

What does a fixed-scope engagement for this work include?

A fixed-scope engagement from DeployOpen covers the scope, deliverables and timelines agreed in writing before work starts. For this stack, that scope would typically name the Zeek and Arkime components, the sensors and sites, storage and retention targets, integrations with your existing log or SIEM tools, authentication, hardening and documentation. It does not include audit reports or certifications, which independent auditors issue. Ongoing upgrades, support and continuous testing are available as retainers. Ask for the written scope and check whether it covers handover, runbooks and post-deployment support.

How DeployOpen helps teams choose and implement network monitoring

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Zeek vs Arkime, the work starts with a written scope that decides whether metadata, packets or both fit your monitoring goals and storage budget.

How we scope

Map which investigations need Zeek protocol logs, which need full packet retrieval, and which need both.
Size sensor disk for PCAP retention and the OpenSearch or Elasticsearch cluster for metadata retention.
Confirm ICS and OT protocol coverage, identity integration and where sensors will sit before any build begins.

How we build

Deploy Zeek and Arkime in your cloud accounts, data centers or air-gapped networks, with the storage layout agreed in writing.
Configure Zeek scripts, log shipping and any Arkime optional applications your scope names, such as wiseService or Parliament.
Test capture, indexing and search against sample traffic, then document the results against the agreed acceptance criteria.

How we hand over

Deliver architecture notes, sensor and retention settings, runbooks and rollback steps in the written scope.
Walk operators through daily Zeek log queries and Arkime session searches, including PCAP export for analysts.
Record which items remain your responsibility, such as sensor hardware replacement and retention policy changes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Plan upgrades for Zeek and Arkime releases against your change windows and storage capacity.
Ask any provider, including DeployOpen, to confirm support windows, response terms and upgrade scope in writing before you sign.

Zeek vs Arkime