9.11. 性能分析

性能问题有许多潜在原因。在本节中，我们将指导您完成一些选项。第一部分将介绍基本步骤并介绍一些有用的工具。第二部分将包括更深入的解释和角落案例。

9.11.1. 系统负荷

第一步应该是检查系统负载。运行顶级工具 htop 了解系统负载的概况，以及流量分布是否存在瓶颈。例如，如果您可以看到只有少数cpu核心始终达到100%，而其他人没有，则可能与流量分布不良或大象流有关，如屏幕截图中所示，一个核心因一个大大象流而达到峰值。

../_images/htopelephantflow.png

如果所有核心都处于峰值负载，则系统对于流量负载可能太慢，或者可能配置错误。还要注意内存使用情况，如果实际内存使用率太高，而系统需要交换内存，则会导致性能非常差。

加载将首先向您指出从何处开始调试，我们将在第二部分中更详细地描述具体部分。

9.11.2. 日志文件

下一步是检查所有日志文件，重点是 stats.log 和 suricata.log 如果发现任何明显的问题。最明显的指标是 capture.kernel_drops 理想情况下甚至不会出现但应低于 capture.kernel_packets 高下降率可能导致事件和警报数量减少。

如果 内存盖 在统计中可以看到配置中的memcap值可以增加。这可能会导致更高的内存使用率，在更改设置时应将其考虑在内。

别忘了检查任何系统日志，即使是 启动信息 运行可以显示潜在的问题。

9.11.3. Suricata负载

除了系统负载，另一个潜在性能问题的指标是Suricata本身的负载。一个有用的工具是 perf 这有助于发现性能问题。确保您已经安装了它，并且为Suricata安装了调试符号，否则输出将不会有很大帮助。当您报告性能问题时，这个输出也很有帮助，因为Suricata开发团队可以缩小可能的问题。

sudo perf top -p $(pidof suricata)

如果您在顶部看到红色的特定函数调用，则表明这些是瓶颈。例如，如果你看到 IPOnlyMatchPacket 它可以是高下降率的结果，也可以是导致性能下降的不完全流的结果。要查看可以传递的特定线程上的性能问题 -t TID 去完成任务。在其他情况下，您可以看到一些函数，这些函数向您提示，某个特定的协议解析器被大量使用，并且可以尝试调试性能错误或尝试过滤相关的流量。

../_images/perftop.png

一般情况下，尝试使用Suricata提供的不同配置选项，重点关注中描述的选项 高性能配置 .

9.11.4. 交通

在大多数情况下，硬件足够快来处理流量，但下降率仍然很高，这与特定的流量问题有关。

9.11.4.1. 基础

一些基本检查包括：

  • 检查流量是否是双向的，如果大部分是单向的，则会丢失流的相关部分（请参见 tshark公司 示例在底部）。另一个指标可能是SYN和SYN-ACK之间的巨大差异，以及Suricata统计中的RST计数器。

  • 检查封装的流量，当支持GRE、MPLS等时，它们也可能导致性能问题。尤其是如果有几层封装。

  • 使用诸如 伊夫托普 发现大象的流动。长时间速率超过1Gbit/s的流量可能会导致一个cpu核心峰值始终为100%，并增加下降速率，但深入研究此流量可能没有意义。

  • 另一种缩小问题范围的方法是使用 bpf过滤器 . 例如，使用 不是443端口 排除可能有问题的流量或只查看一个特定端口 端口25 如果你认为某个协议有问题。看到了吗 忽略流量 了解更多详细信息。

  • 如果使用VLAN，可能有助于禁用 vlan.use-for-tracking 在只有一个流方向有VLAN标记的情况下。

9.11.4.2. 先进的

有几个先进的步骤和角落案件，当涉及到一个深入的交通。

如果使用VLAN QinQ（IEEE 802.1ad），请务必谨慎使用 cluster_qm 与Intel驱动程序和AF峎u数据包运行模式结合使用。而RFC在本例中需要ethertype 0x8100和0x88A8（请参阅https://en.wikipedia.org/wiki/IEEE_802.1ad)大多数实现只在每个层上添加0x8100。如果第一个看到的层具有相同的VLAN标记，但内部层具有不同的VLAN标记，则它仍将在同一队列中结束 cluster_qm 模式。这是在i40e驱动程序2.8.20和firmare版本7.00之前观察到的，如果更新版本修复了这个问题，请随时报告（请参见https://suricata-ids.org/support/).

如果你想用 tshark公司 要获得交通方向的概述，请使用以下命令：

sudo tshark -i $INTERFACE -q -z conv,ip -a duration:10

输出将显示10秒内的所有流量，如果一个方向的流量为0，则表示单向流量，例如，您看不到ACK数据包。由于Suricata正在努力研究流量，这将对可见性产生相当大的影响。重点解决单向交通问题。如果根本不可能，您可以启用 async-oneside 在 流动 配置设置。

检查其他不受支持的异常或复杂的协议。您可以尝试过滤这些内容，看看它是否对性能有任何影响。在这个例子中，我们用bpf过滤器过滤Cisco结构路径（ethertype 0x8903） 不是乙醚原型0x8903 因为这是一个性能问题（参见https://redmine.openinfosecfoundation.org/issues/3637)

9.11.4.3. 大象流

所谓的大象流或交通高峰是很难处理的。在大多数情况下，这些都是大文件传输或备份流量，不可能解码整个流量。从网络安全监控的角度来看，记录该流的元数据并在开始时进行数据包检查就足够了，但不是整个流。

如果您可以发现上面描述的特定流，则尝试过滤这些流。最简单的解决方案是bpf过滤器，但这仍然会对性能造成影响。理想情况下，您甚至可以在驱动程序或NIC级别（请参阅eBPF/XDP）或甚至在它到达运行Suricata的系统之前过滤这些流量。一些商业数据包代理支持调用这种过滤 分流 或 流动切片 .

9.11.5. 规则

规则集在检测中起着重要的作用，同时也对Suricata的性能起着重要的作用。因此，建议您也研究已启用规则的影响。

如果遇到性能问题并努力缩小性能问题，请从不启用任何规则的情况下运行Suricata开始，然后再次使用第一部分中介绍的工具。请记住，即使没有启用签名功能的Suricata仍然会执行大部分解码和流量分析，因此仍然应该看到相当数量的负载。如果负载仍然很高，并且可以看到下降，并且硬件应该能够处理这种流量负载，那么如果存在任何特定的流量问题（见上文），则应该深入研究，或者报告性能问题，以便进行调查（请参见https://suricata-ids.org/support/).

Suricata还在rules文件夹中提供了几个与流量相关的特定签名，这些签名可以用于测试以发现特定的流量问题。那些是在 规则 你应该从 decoder-events.rules ， stream-events.rules 和 app-layer-events.rules .

它也可以帮助使用 规则分析 和/或 数据包分析 找出有问题的规则或交通模式。这是通过编译Suricata来实现的 --enable-profiling 但请记住，这对性能有影响，只应用于故障排除。