Arkime 高吞吐抓包实战：Myricom SNF Reader 插件配置与原理全解析

网络安全网络后端数据可视化【免费下载链接】arkimeArkime is an open source, large scale, full packet capturing, indexing, and database system.项目地址https://gitcode.com/gh_mirrors/ar/arkime点击查看免费下载导读本文聚焦 Arkime原 Moloch开源全包捕获系统中与 Myricom SNF 网卡协同工作的 reader 插件——reader-snf.so。当使用 Myricom 的高性能网络捕获卡时SNF reader 能以接近线速的方式把报文直接送入 Arkime 抓包管道替代默认的 libpcap 读取路径。读完本文你将掌握SNF 插件涉及的全部配置项及其取值范围与默认值、多抓包进程共享同一块 Myricom 板卡的正确配置方法、从源码编译到配置加载的完整部署流程以及插件内部 ring 管理、统计上报的底层实现原理。一、SNF reader 在 Arkime 中的定位Arkime 的 capture 进程通过一套可插拔的 reader 机制完成报文读取。在 capture/readers.c 中arkime_readers_set()读取配置项pcapReadMethod默认值为libpcap然后从 reader 哈希表中查找对应实现并调用其初始化函数而arkime_readers_add()capture/readers.c负责把各 reader 的名字注册进这张哈希表。内置 reader 包括libpcap、tpacketv3、afpacketv3、null、pcapoverip、tzsp、scheme、bpf、netmap等见 capture/readers.c而SNF reader 是以插件.so 动态库形式提供的位于capture/plugins/snf/目录下。这决定了它与其他内置 reader 的加载路径不同必须在 capture 启动早期通过rootPlugins加载然后才能被pcapReadMethodsnf选中。在 capture/main.c 中可以看到关键的执行顺序arkime_readers_init()初始化内置 reader 哈希表arkime_plugins_init()初始化插件框架arkime_plugins_load(config.rootPlugins, FALSE)加载 rootPluginsroot 插件在解析器初始化之前运行随后才调用arkime_readers_set(NULL)根据pcapReadMethod选择 reader。插件加载机制在 capture/plugins.c 中实现通过g_module_open打开 .so查找符号arkime_plugin_init并调用。SNF 插件的入口函数正是void arkime_plugin_init() { arkime_readers_add(snf, reader_snf_init); }见 capture/plugins/snf/reader-snf.c它将snf这个名字注册进 reader 哈希表使得pcapReadMethodsnf得以解析成功。二、核心配置参数详解SNF 插件在 reader_snf_init 中读取以下配置项全部位于配置文件的 capture 节点下配置项含义默认值取值范围/边界snfNumRings每个接口使用的 ring 数同时也等于每接口启动的抓包线程数11 ~ 10MAX_RINGSsnfDataRingSize对应 SNF 的SNF_DATARING_SIZE即数据 ring 的容量00 ~ 0x7fffffff0 表示使用 SNF 默认值snfFlags控制进程共享bit 0即值 1、端口聚合bit 1即值 2、报文复制bit 2即值 3 的组合语义详见 SNF 文档-10 ~ -1-1 表示使用 SNF 默认 flagssnfNumProcs共享同一块 Myricom 板卡的抓包进程总数11 ~ 10MAX_PROCSsnfProcNum当前进程在共享集群中的编号00 ~ 10多进程场景下必须非 0源码中对应的解析逻辑capture/plugins/snf/reader-snf.c如下snfNumRings arkime_config_int(NULL, snfNumRings, 1, 1, MAX_RINGS); snfNumProcs arkime_config_int(NULL, snfNumProcs, 1, 1, MAX_PROCS); snfProcNum arkime_config_int(NULL, snfProcNum, 0, 0, MAX_PROCS); int snfDataRingSize arkime_config_int(NULL, snfDataRingSize, 0, 0, 0x7fffffff); int snfFlags arkime_config_int(NULL, snfFlags, -1, 0, -1);其中arkime_config_int是 Arkime 的通用配置解析函数实现见 capture/config.c会强制把取值钳制在[min, max]区间内。配置项之间的联动关系snfNumRings决定线程数每个接口、每个 ring 各对应一个抓包线程。reader_snf_start()中为每个接口创建snfNumRings个线程线程名形如arkime-snf{接口序号}-{ring序号}见 capture/plugins/snf/reader-snf.c。snfProcNum与snfNumRings共同决定 ring 区间插件通过ringStartOffset (snfProcNum - 1) * snfNumRings计算当前进程应使用的 ring 起始下标capture/plugins/snf/reader-snf.c并在打开接口时向 SNF 申请snfNumRings * snfNumProcs个 ringcapture/plugins/snf/reader-snf.c从而保证多进程场景下每个进程拿到互不重叠的 ring 段。上限保护若snfProcNum * snfNumRings超过MAX_RINGS(10)插件会直接CONFIGEXIT退出并给出提示。多进程共享板卡的特殊设置当需要让多个 capture 进程同时监听同一块 Myricom 网卡例如为了横向扩展抓包吞吐时文档明确要求同时满足以下条件设置环境变量SNF_APP_ID其值必须在同一主机上唯一用于区分不同的应用实例避免进程间共享状态冲突snfFlags必须包含进程共享标志0x01即snfFlags1需要叠加其他标志时做按位或如进程共享端口聚合为3snfNumProcs设置为共享该接口的抓包进程总数为每个进程分别设置snfProcNum例如snfNumProcs2时一个进程配置snfProcNum1另一个配置snfProcNum2二者不能相同。插件对此有一处强制校验capture/plugins/snf/reader-snf.c// Quick config sanity check for clustered processes if (snfNumProcs 1) { if (snfProcNum 0) { CONFIGEXIT(Myricom: snfNumProcs set 1 but snfProcNum not present in config); } } else { snfProcNum 1; }即只要声明了多进程共享就必须为当前进程显式给出非 0 的snfProcNum否则启动即失败。而单进程模式下snfProcNum会被强制置为 1。完整配置示例# 位于 capture 节点配置中 rootPluginsreader-snf.so pcapReadMethodsnf # 使用 OS 接口名或使用 snf 端口号形式 snf## 为 portnum interfaceeth0 # 每接口 ring/线程数按需调大 snfNumRings4 # 多进程共享板卡时启用bit0 进程共享 snfFlags1 snfNumProcs2 snfProcNum1 # 第二个进程配置为 2三、从源码编译到配置加载的完整部署流程第 1 步安装 SNF 软件包在所有构建主机和所有运行 capture 的主机上安装 Myricom SNF 软件包。SNF 的 API 头文件与链接库是编译和运行该插件的前提——插件源码直接#include snf.hcapture/plugins/snf/reader-snf.c。第 2 步编译插件在capture/plugins/snf目录下执行make。其构建规则见 capture/plugins/snf/Makefile.in默认 SNF 安装目录为/opt/snfSNFDIR /opt/snf编译时以-I$(SNFDIR)/include引入头文件链接时以-L$(SNFDIR)/lib -lsnf链接 SNF 库并通过-Wl,-rpath$(SNFDIR)/lib指定运行时库搜索路径产物是reader-snf.so输出到上级目录../%.so规则即capture/plugins/reader-snf.so编译依赖../../arkime.h、../../hash.h、../../dll.h等 Arkime 头文件因此应先在仓库根目录完成 configure/make 后再构建插件。若你的 SNF 安装路径不同需要相应修改Makefile.in中的SNFDIR。第 3 步配置 rootPlugins 加载插件在 capture 配置文件中加入rootPluginsreader-snf.sorootPlugins在 capture/config.c 中被解析为插件列表并在 capture/main.c 中于 reader 选择之前加载——这是关键点SNF 必须先作为 root 插件注册进 reader 哈希表后续pcapReadMethodsnf才能被识别。配置示例文件 release/config.ini.sample 中也有#rootPluginsreader-pfring.so; reader-daq.so的同类写法可供参考分号分隔多个插件。第 4 步指定 reader 方法与接口pcapReadMethodsnf interfaceeth0interface有两种写法OS 接口名如eth0插件启动时会调用snf_getifaddrs()遍历 SNF 接口列表将接口名匹配到 SNF 端口号见 capture/plugins/snf/reader-snf.csnf#形式#为 SNF 端口号portnum例如snf0。当 OS 接口名匹配失败时插件会用sscanf(config.interface[i], snf%d, portnums[i])尝试解析这种写法。若两种方式都无法解析出端口号插件会CONFIGEXIT(Myricom: Couldnt find interface %s)直接退出。四、源码级原理ring 生命周期与报文读取路径初始化阶段reader_snf_init调用snf_init(SNF_VERSION_API)初始化 SNF 库失败即退出调用snf_getifaddrs()获取本机 SNF 接口列表用于接口名→端口号映射对每个配置的接口调用snf_open(portnums[i], snfNumRings * snfNumProcs, NULL, snfDataRingSize, snfFlags, handles[i])打开句柄其中第二个参数表明该板卡为所有共享进程预留的 ring 总数对当前进程的 ring 区间逐 ring 调用snf_ring_open()完成后调用snf_freeifaddrs()释放接口列表挂接全局回调arkime_reader_start reader_snf_start、arkime_reader_stats reader_snf_stats见 capture/plugins/snf/reader-snf.c。这两个全局函数指针正是 capture/readers.c 中声明、由主循环调用的 reader 契约接口。运行阶段reader_snf_start reader_snf_thread启动时先调用arkime_packet_set_dltsnap(DLT_EN10MB, config.snapLen)声明链路层类型为以太网snapLen的默认值为 16384见 capture/config.c随后为每个接口、每个 ring 创建抓包线程。每个线程的核心循环capture/plugins/snf/reader-snf.cint err snf_ring_recv(ring, 1000, req); if (err) { if (err EBUSY || err EAGAIN || err EINTR) { // 无报文到达先把批处理中累积的报文交出去 arkime_packet_batch_flush(batch); continue; } LOG(SNF quitting %d, err); arkime_quit(); break; }snf_ring_recv以 1000ms 超时轮询 ring返回EBUSY/EAGAIN/EINTR视为空闲其余错误会触发整体退出收到报文后用 SNF 的时间戳填充 Arkime 包头req.timestamp纳秒除以 1e9 得秒、除以 1000 取模得微秒capture/plugins/snf/reader-snf.c报文通过arkime_packet_batch()进入批量处理通道批内报文数超过 10000 时强制arkime_packet_batch_flush()下发给后续解析/存储管道避免长时间攒批每收到一个报文对应 ring 的totalPktsRead[pos][offset]计数加 1作为统计上报的依据。统计阶段reader_snf_statsreader_snf_statscapture/plugins/snf/reader-snf.c汇总每个 ring 的统计total直接累加本进程实际读取的报文数totalPktsRead而非采用 SNF 文档中标注为“估算值”的ring_pkt_recv——源码注释明确说明这是有意为之以反映真实观测到的报文数dropped取自snf_ring_getstats()的ring_pkt_overflowNIC 层溢出丢弃。由于 Myricom 在网卡层面报告丢包、并不按 ring 区分插件只在该进程首个 ring 上取一次值并除以snfNumProcs分摊到各进程以避免多进程重复统计造成丢包数虚高。源码注释也指出当前 SNF 实现无法把溢出丢包精确归属到某个 ring/进程这是其固有限制。arkime_reader_stats这个函数指针会被 capture/packet.c 等处的统计输出路径周期调用从而在 capture 的监控指标中呈现 SNF 抓包的收包与丢包情况。五、验证与常见问题排查如何确认插件已正确加载启动 capture 后观察日志若rootPluginsreader-snf.so未被找到capture/plugins.c 会打印WARNING - plugin reader-snf.so not found若 .so 缺失arkime_plugin_init符号会打印ERROR - Module ... doesnt have an arkime_plugin_init若pcapReadMethodsnf但 reader 未注册成功capture/readers.c 会输出Couldnt find pcapReadMethod snf implementation并退出。常见错误与对策现象原因与对策Myricom: failed in snf_init(%d) %dSNF 库未安装或版本不匹配检查所有运行主机上的 snf 包Myricom: failed in snf_getifaddrsSNF 接口枚举失败确认 Myricom 驱动已加载、板卡可被系统识别Myricom: Couldnt find interface %sinterface既不是有效的 OS 接口名也不是snf#端口号形式对照snf_getifaddrs输出核对名称Myricom: Couldnt open interface %s %dsnf_open失败检查snfDataRingSize/snfFlags取值是否超出板卡能力Myricom: snfNumProcs set 1 but snfProcNum not present多进程共享模式未设置snfProcNum为每个进程配置 1..N 的编号snfProcNum * snfNumRings (...) exceeds MAX_RINGS (10)ring 总数超限调低snfNumRings或snfNumProcs使其乘积 ≤ 10运行环境的约束提醒SNF reader 仅用于在线实时抓包从 capture/main.c 可见离线 pcap 文件/目录读取路径会强制选择libpcap-file或scheme不会走 SNF插件要求snf.h头文件与-lsnf库在构建期可用运行期则依赖-Wl,-rpath$(SNFDIR)/lib定位动态库因此 SNF 安装目录的变更需要同步修改 Makefile 并重新编译单进程模式snfNumProcs1无需设置SNF_APP_ID环境变量和snfFlags进程共享位仅多进程共享板卡时需要。六、结语Arkime 的 SNF reader 插件通过 capture/plugins/snf/reader-snf.c 约 200 行代码完整覆盖了 Myricom SNF 的初始化、多 ring 并发抓包、多进程共享板卡和丢包统计上报是 Arkime 在高性能专用网卡场景下的标准接入方案。核心要点可归结为四句话以rootPlugins提前注册、以pcapReadMethodsnf启用、以snfNumRings扩展并发、以snfNumProcs/snfProcNum编排多进程共享。结合文中的配置示例与源码依据你可以直接在当前仓库的capture/plugins/snf目录下复现编译、部署并验证完整的 SNF 抓包链路。赞分享网络安全网络后端数据可视化【免费下载链接】arkimeArkime is an open source, large scale, full packet capturing, indexing, and database system.项目地址https://gitcode.com/gh_mirrors/ar/arkime点击查看免费下载相关推荐如何快速上手aitviewer5分钟完成SMPL模型加载与渲染教程如何快速上手aitviewer5分钟完成SMPL模型加载与渲染教程 aitviewer是一套用于可视化和交互3D数据序列的强大工具能够帮助用户轻松加载、渲染网络安全网络后端数据可视化3个配置让TiKV批量操作吞吐量提升300%从原理到实战3个配置让TiKV批量操作吞吐量提升300%从原理到实战 TiKV 是一个高性能、可扩展的分布式键值存储系统支持事务和分布式锁适用于大数据存储和分布式系统数据库KV存储分布式数据库云原生DragonflyDB超高性能调优10倍吞吐量配置实战指南DragonflyDB超高性能调优10倍吞吐量配置实战指南 DragonflyDB 是一个高性能分布式KV存储系统专为大规模数据场景设计通过优化架构实现低数据库KV存储缓存上一篇终极Linux系统监控如何用Linux-Dash打造极简主义服务器仪表盘下一篇exchangelib完全指南Python轻松对接Microsoft Exchange Web Services创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考