配置流量捕获选项
编辑配置流量捕获选项
编辑部署 Packetbeat 主要有两种方式
- 在专用服务器上,从镜像端口或监控端口获取流量。
- 在您现有的应用程序服务器上。
第一种方案的优势在于,对您的应用程序服务器没有任何开销。但它需要专用的网络设备,这在云环境中通常不可用。
在这两种情况下,嗅探性能(被动地从网络读取数据包)都非常重要。对于专用服务器,更好的嗅探性能意味着所需的硬件更少。当 Packetbeat 安装在现有的应用程序服务器上时,更好的嗅探性能意味着更少的开销。
目前 Packetbeat 提供了几个流量捕获选项
-
pcap
,它使用 libpcap 库,适用于大多数平台,但它不是最快的选项。 -
af_packet
,它使用内存映射嗅探。此选项比 libpcap 快,并且不需要内核模块,但它是 Linux 专用的。
af_packet
选项,也称为“内存映射嗅探”,利用了 Linux 特有的 特性。这可能是专用服务器和在现有应用程序服务器上部署 Packetbeat 时最佳的嗅探模式。
它的工作原理是内核和用户空间程序映射相同的内存区域,并且在这个内存区域中组织了一个简单的循环缓冲区。内核将数据包写入循环缓冲区,用户空间程序从中读取。poll 系统调用用于获取第一个可用数据包的通知,但其余可用数据包可以通过内存访问简单地读取。
af_packet
嗅探器可以进一步调整以使用更多内存以换取更好的性能。循环缓冲区的大小越大,所需的系统调用越少,这意味着消耗的 CPU 周期越少。缓冲区的默认大小为 30 MB,但您可以像这样增加它
packetbeat.interfaces.device: eth0 packetbeat.interfaces.type: af_packet packetbeat.interfaces.buffer_size_mb: 100
Windows Npcap 安装选项
编辑在 Windows 上,Packetbeat 需要安装 Npcap DLL。对于 Elastic 许可版本的用户,Packetbeat 提供了此功能。在某些情况下,用户可能希望使用自己安装的版本。为此,可以使用 packetbeat.npcap.never_install
选项。将此选项设置为 true
将不会在启动时尝试安装捆绑的 Npcap 库,除非尚未安装任何 Npcap。
packetbeat.npcap.never_install: true
嗅探配置选项
编辑您可以在 packetbeat.yml
配置文件中的 packetbeat.interfaces
部分指定以下选项。这是一个示例配置
packetbeat.interfaces.device: any packetbeat.interfaces.snaplen: 1514 packetbeat.interfaces.type: af_packet packetbeat.interfaces.buffer_size_mb: 100
device
编辑要从中捕获流量的网络设备。指定的设备会自动设置为混杂模式,这意味着 Packetbeat 可以捕获同一 LAN 上其他主机之间的流量。
示例
packetbeat.interfaces.device: eth0
在 Linux 上,您可以为设备指定 any
,Packetbeat 将捕获安装 Packetbeat 的服务器发送或接收的所有消息。
当您为设备指定 any
时,接口不会设置为混杂模式。
device
选项还接受通过其在可用嗅探设备列表中的索引指定设备。要获取可用设备的列表,请使用以下命令运行 Packetbeat
packetbeat devices
此命令返回如下所示的列表
0: en0 (No description available) 1: awdl0 (No description available) 2: bridge0 (No description available) 3: fw0 (No description available) 4: en1 (No description available) 5: en2 (No description available) 6: p2p0 (No description available) 7: en4 (No description available) 8: lo0 (No description available)
以下示例设置了对列表中第一个接口的嗅探
packetbeat.interfaces.device: 0
在 Windows 上,设备名称可能很长,因此指定索引特别有用。
或者,可以指定 default_route
、default_route_ipv4
或 default_route_ipv6
设备。这会将捕获设备设置为与 Packetbeat 启动时识别的第一个默认路由关联的设备。 default_route
将从 IPv4 或 IPv6 中选择第一个默认路由,并优先选择 IPv4 路由,而 default_route_ipv4
和 default_route_ipv6
将仅从指定的协议栈中选择。选定的接口在选择后不会更改。
snaplen
编辑要捕获的数据包的最大大小。默认为 65535,对于几乎所有网络和接口类型来说,这都足够大了。如果您在物理网络接口上嗅探,则最佳设置是 MTU 大小。但是,在虚拟接口上,接受默认值更安全。
示例
packetbeat.interfaces.device: eth0 packetbeat.interfaces.snaplen: 1514
type
编辑Packetbeat 支持以下嗅探器类型
-
pcap
,它使用 libpcap 库,适用于大多数平台,但它不是最快的选项。 -
af_packet
,它使用内存映射嗅探。此选项比 libpcap 快,并且不需要内核模块,但它是 Linux 专用的。
默认嗅探器类型为 pcap
。
这是一个指定 af_packet
嗅探类型的示例配置
packetbeat.interfaces.device: eth0 packetbeat.interfaces.type: af_packet
在 Linux 上,如果您尝试优化 Packetbeat 的 CPU 使用率,我们建议您尝试 af_packet
选项。
如果您使用 af_packet
嗅探器,则可以通过指定以下选项来调整其行为
buffer_size_mb
编辑内核和用户空间之间使用的共享内存缓冲区的最大大小。更大的缓冲区通常会导致更低的 CPU 使用率,但会消耗更多内存。此设置仅适用于 af_packet
嗅探器类型。默认为 30 MB。
示例
packetbeat.interfaces.device: eth0 packetbeat.interfaces.type: af_packet packetbeat.interfaces.buffer_size_mb: 100
fanout_group
编辑要跨多个 Packetbeat 进程扩展处理,可以指定扇出组标识符。当使用 fanout_group
时,Linux 内核通过使用流哈希将数据包拆分到同一组中的 Packetbeat 实例之间。它使用 Packetbeat 进程数对流哈希进行取模运算,以便一致地将流路由到同一个 Packetbeat 实例。
值必须介于 0 和 65535 之间。默认情况下,不会设置任何值。
这仅在 Linux 上可用,并且需要使用 type: af_packet
。每个进程必须在相同的网络命名空间中运行。所有进程都必须使用相同的接口设置。您必须负责运行 Packetbeat 的多个实例。
示例
packetbeat.interfaces.type: af_packet packetbeat.interfaces.fanout_group: 1
metrics_interval
编辑为支持的接口类型配置指标轮询间隔。目前,仅支持 af_packet
。
值必须是持续时间字符串。默认为 5s
(5 秒)。小于或等于零的值将设置为默认值。
示例
packetbeat.interfaces.type: af_packet packetbeat.interfaces.metrics_interval: 5s
auto_promisc_mode
编辑使用 auto_promisc_mode
,Packetbeat 会在启动时自动将接口置于混杂模式。此选项不适用于 any
接口设备。默认选项为 false,需要手动设置混杂模式。警告:在某些情况下(例如 beat 崩溃),即使 beat 关闭后,混杂模式也可能保持启用状态。
示例
packetbeat.interfaces.device: eth0 packetbeat.interfaces.type: af_packet packetbeat.interfaces.buffer_size_mb: 100 packetbeat.interfaces.auto_promisc_mode: true
with_vlans
编辑Packetbeat 会自动生成一个 BPF,用于仅捕获其期望在其上找到已知协议的端口上的流量。例如,如果您已将端口 80 配置为 HTTP,并将端口 3306 配置为 MySQL,则 Packetbeat 会生成以下 BPF 过滤器:"port 80 or port 3306"
。
但是,如果流量包含 VLAN 标签,则 Packetbeat 生成的过滤器无效,因为偏移量会移动四个字节。要解决此问题,您可以启用 with_vlans
选项,它会生成如下所示的 BPF 过滤器:"port 80 or port 3306 or (vlan and (port 80 or port 3306))"
。
bpf_filter
编辑Packetbeat 会自动生成一个 BPF,用于仅捕获其期望在其上找到已知协议的端口上的流量。例如,如果您已将端口 80 配置为 HTTP,并将端口 3306 配置为 MySQL,则 Packetbeat 会生成以下 BPF 过滤器:"port 80 or port 3306"
。
您可以使用 bpf_filter
设置覆盖生成的 BPF 过滤器。例如
packetbeat.interfaces.device: eth0 packetbeat.interfaces.bpf_filter: "net 192.168.238.0/0 and port 80 or port 3306"
此设置禁用 BPF 过滤器的自动生成。如果您使用此设置,则您有责任使 BPF 过滤器与 protocols
部分中定义的端口保持同步。
ignore_outgoing
编辑如果启用了 ignore_outgoing
选项,则 Packetbeat 将忽略从运行 Packetbeat 的服务器发起的全部事务。
当两个 Packetbeat 实例发布相同的事务时,这很有用。因为一个 Packetbeat 在其传出队列中看到事务,而另一个 Packetbeat 在其传入队列中看到事务,所以您最终可能会得到重复的事务。要删除重复项,您可以在其中一台服务器上启用 packetbeat.ignore_outgoing
选项。
例如,在以下场景中,您将看到一个 3 台服务器的架构,其中每台服务器上都安装了一个 Beat。t1 是 Server1 和 Server2 之间交换的事务,t2 是 Server2 和 Server3 之间的事务。
默认情况下,每个事务都被索引两次,因为 Beat2 会看到两个事务。因此,您将看到以下已发布的事务(当 ignore_outgoing
为 false 时)
- Beat1:t1
- Beat2:t1 和 t2
- Beat3:t2
要避免重复,您可以强制您的 Beat 仅发送传入事务并忽略本地服务器创建的事务。因此,您将看到以下已发布的事务(当 ignore_outgoing
为 true 时)
- Beat1:无
- Beat2:t1
- Beat3:t2
internal_networks
编辑如果指定了 internal_networks
选项,则在监控网络监控端口或镜像端口时,Packetbeat 将尝试根据其与网络周界的关系对非目标主机流量的网络方向进行分类。 internal_networks
中指定的任何 CIDR 块都被视为周界内部,并且任何位于这些 CIDR 块之外的 IP 地址都被视为外部。
当 Packetbeat 在位于网络边界(如防火墙或 VPN)的设备上运行时,这很有用。请注意,这仅影响网络流量方向的分类方式。