Arkime是一套开源的大规模网络流量抓取、存储与检索系统，前身名为Molina，常用于安全运营中心的全流量回溯。在面对每日数TB甚至PB级的流量时，它并没有采用把所有数据包直接塞进数据库的做法，而是把“原始报文”和“结构化元数据”拆成两条完全独立的存储路径。原始报文经过压缩后写成RAW文件，元数据则提取成SPI会话记录送入Elasticsearch。这样的设计使得存储层可以依靠廉价磁盘做顺序写入，检索层则利用搜索引擎的分布式能力做灵活过滤，从而同时满足低成本留存与快速取证的诉求。
RAW文件存储格式与写入机制
Arkime的捕获进程（capture）在收到数据包后，并不会立即逐条写盘，而是按时间窗口或大小阈值批量聚合成一个RAW文件。每个RAW文件内部采用自研的紧凑二进制格式，前面是文件头，后面是一系列带时间戳和链路层偏移的记录块。这种顺序追加的写法避开了随机IO，使得普通SATA盘也能达到接近线速的写入吞吐。文件默认使用gzip或zstd压缩，在多数企业流量中能获得三到五倍的空间缩减。
为了便于后续检索，每一个RAW文件都会被分配一个唯一的fileId，并注册到Elasticsearch的files索引中，里面记录了该文件对应的时间范围、节点名、大小以及覆盖的会话ID列表。当用户通过Arkime界面查询某个连接时，系统先查SPI数据拿到对应的fileId与包偏移，再直接向存储节点拉取RAW文件的解压片段。这种“索引轻、数据重”的分离，让元数据集群不必承载海量字节，扩容时只需增加capture存储节点挂载新磁盘即可。
在实际部署中，RAW文件可以落在本地磁盘，也可以通过S3接口写到对象存储。对于跨机房留存，很多团队会把热数据放本地NVMe，冷数据周期性迁移到MinIO或公有云桶。下面的配置片段展示了capture节点如何指定RAW路径与压缩方式：
[default] # 原始流量文件存放根目录 pcapDir = /data/arkime/raw # 单个RAW文件最大体积，到达后滚动新建 maxFileSizeG = 2 # 使用zstd压缩以平衡CPU与比率 compress = zstd # 冷数据同步到对象存储的脚本钩子 coldStorageScript = /opt/arkime/db/moveToS3.pl
Elasticsearch中的SPI元数据索引设计
SPI（Session Profile Information）是Arkime对每次网络会话提取出的结构化描述，包含五元组、协议类型、字节数、应用层识别结果等上百个字段。capture在写RAW的同时，会把这些字段组装成JSON文档批量写入Elasticsearch的sessions索引。由于只存摘要不存报文，单条记录通常只有几百字节，因此即便会话量极大，索引总体规模也远小于原始流量。
Arkime对Elasticsearch的映射做了大量定制，例如将IP转为数值类型、端口建为短整型、协议名做成keyword以便聚合。它还利用路由字段把同一时间段的数据集中到某些分片，减少跨节点查询。在检索时，用户在前端输入的复杂过滤条件（如host含某域名且bytes大于10000）会被翻译成ES的bool查询，依托倒排索引实现亚秒级响应。下面的示例是用ES DSL查找某一内网IP在指定时间窗内的对外HTTPS会话：
{
"query": {
"bool": {
"must": [
{ "term": { "proto": "tcp" } },
{ "term": { "port.dst": 443 } },
{ "range": { "ip.src": { "gte": "10.0.0.0", "lte": "10.255.255.255" } } }
],
"filter": [
{ "range": { "firstPacket": { "gte": "1700000000000", "lt": "1700086400000" } } }
]
}
},
"size": 50
}
值得注意的是，SPI字段并非越多越好。每增加一个深度解析字段，capture的CPU开销和ES索引体积都会上涨。因此在大规模场景下，运维人员通常关闭不必要的应用层解析器，仅保留溯源与检测强相关的字段，以此换取集群稳定。Arkime也支持按时间滚动关闭老索引，将超过留存期的SPI数据冻结或删除，进一步控制成本。
横向扩展架构与容量规划实践
当流量规模从每日十TB增长到百TB以上，单集群的写入与查询压力必须靠横向扩展化解。Arkime的组件天然无状态化：capture节点只管抓包写盘并推SPI，viewer节点提供Web与API，ES集群独立承担索引。新增捕获节点不需要改动现有集群，只要指向同一个Elasticsearch并配置独立pcapDir，就能线性提升存储与写入能力。
在容量规划上，团队应先估算原始流量与压缩比，得出RAW所需磁盘；再根据会话密度算出SPI文档数，选择ES分片数与节点规格。一个常见误区是盲目给ES堆大内存，实际上Arkime的检索多依赖磁盘上的倒排文件，给每个ES节点配合理比例的SSD与堆外缓存比单纯加内存更有效。下表给出中等规模部署的参考比例：
| 组件 | 每日流量 | 推荐磁盘 | 说明 |
|---|---|---|---|
| capture节点 | 20TB | 60TB HDD | 按3倍压缩后空间加冗余 |
| ES数据节点 | 对应SPI | 2TB SSD | 存放约30天热索引 |
| viewer节点 | 查询并发 | 无状态 | 可随前端负载弹性增减 |
此外，Arkime支持多集群联邦查询，通过配置多个Elasticsearch后端，把不同地域的流量分别索引，又在统一界面聚合展示。对于合规要求数据不出域的场景，这种边缘存储、中心检索的模式既满足了隔离，又不牺牲排查效率。在真正落地时，建议先以小流量灰度观察RAW写盘延迟与ES索引拒绝率，再逐步放大到全量镜像端口。
Arkime大规模流量存储Elasticsearch修改时间：2026-08-17 14:38:38