跨地域网关流量统计，我选择这个组合搞定异地流量采集的-天行1st的博客

背景

前情提要：15 台网关（16核 32G 内存 40G 硬盘），分布在全国 3 个地市。需要收集这 15 台网关的流量——请求 IP、目标 IP、协议、请求时间等——然后存入一个异地日志服务器，用于统计分析。

这个需求看起来不复杂，但真正动手选型时，问题才一个个冒出来：抓包工具怎么选？数据怎么传？存到哪里？每个环节都有好几个方案，选错了轻则浪费资源，重则上线后天天救火。

下面把我选型的过程整理成文，供有类似需求的朋友参考。

一、抓包工具

网络流量采集工具一抓一大把，tcpdump、tshark、Suricata、Zeek……哪个都能用，但哪个都不是专门为"流量统计"这个场景设计的。

我们把主流工具拉出来对比了一下：

工具	优势	劣势	适用场景
pmacct	专为流量统计设计；支持 NetFlow/IPFIX/sFlow；资源占用低；可直出 Kafka/文件	功能相对单一	✅ 网关流量采集
sFlow	标准化协议，厂商支持广；采样机制省资源	采样有丢失；需要配合 collector	高速网络监控
tshark	Wireshark 命令行版，协议解析强	资源占用高，不适合长期运行	临时故障排查
tcpdump	系统自带，轻量快速	无统计分析；需配合其他工具	快速抓包
Suricata	IDS/IPS 功能强，支持 DPI	侧重安全，配置复杂	入侵检测
Zeek	流量分析框架，脚本可扩展	学习曲线陡	网络安全分析

最终选 pmacct，理由很简单：

专注流量统计 — 它的设计目标就是我们需要的：把流量"统计"起来，不是抓包分析，而是计量记账。
资源占用低 — 15 台网关要长期跑，轻量稳定是刚需，pmacct 比 Zeek/tshark 轻好几个量级。
原生支持多种协议 — NetFlow v5/v9、IPFIX、sFlow 都能接，以后扩展不需要换工具。
输出格式友好 — 直接出 JSON，vector 读取零门槛。

二、数据采集传输

Vector 做"搬运工"

抓到的数据要传到异地的中心服务器，这段传输才是真正的挑战：网络不稳定、数据不能丢、还要跨地市加密。

常见方案对比：

工具	优势	劣势	适用场景
Vector	Rust 编写，性能高；内存低；VRL 数据转换；断点续传；ClickHouse 原生 Sink	相对较新	✅ 日志采集传输
Fluent-bit	CNCF 毕业，K8s 集成好	复杂数据处理能力弱	容器日志
Logstash	ELK 官方，插件生态最丰富	Java 编写，资源占用高	中心化日志处理
Filebeat	轻量简单	功能单一，仅文件采集	简单文件日志

选 Vector 的原因：

Rust** 带来的稳定性** — 在边缘节点上跑，内存不会悄悄爆掉，这点很关键。
VRL 脚本 — pmacct 输出的 JSON 字段要清洗重组，VRL 几句话就能搞定。
断点续传 — 跨地市网络偶尔抖动，Vector 自动重试，不丢数据。
ClickHouse Sink — 直写 ClickHouse，少跳一个中间件。

三、数据存储

ClickHouse 是最合适的那一个

数据量大、查询以聚合为主、时间维度重要——这三个特点基本锁定了存储选型。

数据库	优势	劣势	适用场景
ClickHouse	列式存储，查询极快；压缩率高；SQL 接口；时序友好；分布式成熟	不支持事务；并发写入有限	✅ 日志分析/流量统计
PostgreSQL	ACID 事务；功能全	海量聚合不如 ClickHouse	业务数据
Elasticsearch	全文检索强；扩展容易	JVM 资源占用高；存储成本大	日志检索
MySQL	生态成熟	不适合海量日志分析	业务交易
MongoDB	文档模型灵活	分析能力弱	非结构化数据

选 ClickHouse 的理由：

按 IP、按时间窗口做聚合查询是家常便饭，ClickHouse 的列式存储能把这类查询速度拉到毫秒级。
流量日志数据量大，高压缩比能省下 5-10 倍的存储空间。
时间序列数据天然适合 ClickHouse 的分区机制。
SQL 接口，统计分析直接写 SQL，不用学 ES 的 DSL。

四、整体架构图

选型确定后，架构就清晰了：

┌──────────────────────────────────────────────────────────────┐
│                    3 个地市 · 15 台网关                        │
│                                                              │
│   ┌──────────┐    ┌──────────┐    ┌──────────┐              │
│   │ 网关 1-5 │    │ 网关 6-10│    │网关 11-15│              │
│   │ pmacct   │    │ pmacct   │    │ pmacct   │              │
│   │  +vector │    │  +vector │    │  +vector │              │
│   └────┬─────┘    └────┬─────┘    └────┬─────┘              │
│        │               │               │                     │
│        └───────────────┼───────────────┘                     │
│                        │                                      │
│               （加密传输 · 跨地市）                             │
└────────────────────────┼──────────────────────────────────────┘
                         │
                         ▼
             ┌─────────────────────┐
             │    异地日志服务器     │
             │  ┌───────────────┐  │
             │  │     Vector    │  │
             │  │   （聚合接收）  │  │
             │  └───────┬───────┘  │
             │          │          │
             │          ▼          │
             │  ┌───────────────┐  │
             │  │   ClickHouse   │  │
             │  │  （分布式集群）  │  │
             │  └───────────────┘  │
             └─────────────────────┘
                         │
                         ▼
             ┌─────────────────────┐
             │    统计分析应用      │
             │  （Grafana 可视化）  │
             └─────────────────────┘

数据流是这样的：

网关层（15 台）
1. pmacct 捕获流量，提取源 IP、目标 IP、端口、协议、时间戳、字节数等字段
2. Vector 读取 pmacct 输出的 JSON 日志，做字段清洗和格式化，然后加密传输到中心
中心服务器层
1. Vector 接收 15 个节点的日志流，做缓冲和二次聚合
2. ClickHouse 持久化存储，支持高效查询
应用层
1. 直接用 SQL 做统计分析
2. 对接 Grafana，做可视化大屏

五、方案优势一览

维度	具体表现
性能	pmacct 专注统计 + Vector 高吞吐传输 + ClickHouse 毫秒级查询
成本	边缘节点资源占用低；ClickHouse 高压缩节省 5-10 倍存储
可靠	Vector 断点续传；ClickHouse 分布式副本，数据不丢
扩展	从 15 台扩到 150 台网关，ClickHouse 水平扩展成熟，无需换架构
易用	SQL 查询，Grafana 可视化，团队学习成本低
维护	每个组件都是各自领域的最佳选择，没有凑数的

写在最后

这套方案从选型到落地花了些时间，但稳定性超出预期。pmacct + Vector + ClickHouse 这个组合，在边缘节点采集、跨地域传输、集中式存储这个链路上，配合度很高。

如果你也在为网关流量采集选型，希望这篇文章能帮你少走几个弯路。有具体问题欢迎留言交流 👇

目录CONTENT

跨地域网关流量统计，我选择这个组合搞定异地流量采集的

背景