☰

Syslog-NG 服务器上 RX 字节与 TX 字节（ifconfig）之间存在巨大差异

tag-icon • tag-icon linux networking tcp udp ifconfig
Syslog-NG 服务器上 RX 字节与 TX 字节（ifconfig）之间存在巨大差异

我们有一个 syslog-ng 服务器充当中间记录器。

服务器从网络上的所有设备（来自 UDP 和 TCP 端口上的许多不同来源）接收数据，对其进行一些过滤，然后将数据转发到 SIEM（splunk）。

查看 ifconfig 统计数据时，我可以看到以下内容：

[root@xxxxxxxx ~]# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:50:56:00:00:00
          inet addr:1.1.1.1    Bcast:1.1.1.1    Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:60451021996 errors:0 dropped:0 overruns:0 frame:0
          TX packets:158501574 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:5000
          RX bytes:12508573129969 (11.3 TiB)  TX bytes:220148785267 (205.0 GiB)

这部分对我来说相当震惊：

          RX bytes:12508573129969 (11.3 TiB)  TX bytes:220148785267 (205.0 GiB)

显然，自上次启动（15 天正常运行时间）以来，服务器已收到大约 11 TB 的数据，但“仅”传输了其中的一小部分？（250 Gbs）。

有什么方法可以让我检查这是怎么可能的？我知道有很多 UDP 丢失的消息，但是这些消息被考虑进去了吗？（丢失的消息显示为 0）。

我预计 TX 会少一点（因为我们过滤了一些消息），但不会少太多（最多 10%）。

有关信息，UDP 上的 Netstat 显示：

Udp:
 10903564401 packets received
 8401685 packets to unknown port received.
 49356622070 packet receive errors
 43665773 packets sent
 RcvbufErrors: 34287641

关于如何调查此事有什么建议吗？谢谢！

答案1

需要明确的是，接收和德克萨斯州是收到和发送（而不是传输）。
即，流量分别发送到此主机（在其网络接口上接收）和从此主机发送（在其网络接口上发送）。

      RX packets:60451021996 errors:0 dropped:0 overruns:0 frame:0
      TX packets:158501574 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:5000
      RX bytes:12508573129969 (11.3 TiB)  TX bytes:220148785267 (205.0 GiB)

在上面的示例中，该网络接口具有已收到比它拥有的数据多得多已传输。

如果这里发生的主要流量是其他主机向其发送日志，那么听起来它接收的数据比传输的数据多。

答案2

第 3 层计数器无法证明第 7 层（应用程序）上正在发生什么。可能您拥有更多的非日志流量，如 IP 存储或软件更新。或者过滤日志比您想象的更积极。

在日志服务器上进行几个小时的数据包捕获以获取样本。查找协议的比例，例如使用 Wireshark 的Statistics > Protocol Hierarchy。syslog 占多少百分比？

考虑暂时保存未过滤的日志条目以对其进行统计。这需要相当大的快速存储。像 Graylog 这样的日志搜索引擎可以接收您发送的尽可能多的消息，但代价是维护一个 Elasticsearch 集群。

将通过 syslog 传输的原始数据与 SIEM 进行比较。获取 syslog 数据采集与 SIEM 存储的实际比率。计算唯一主机名或 IP 地址的数量，并与您的清单进行比较。

如果任何主机也在本地存储日志消息，请选择一些并查询这些文件。查找应该到达 SIEM 的消息并确认它们确实到达了。（当存在中央日志记录时，本地日志并不理想，但也可以检查它们。）

相关内容