Filebeat CPU 在 Zabbix 和 Kibana 堆栈监控上的利用率不同

Question

性能测试在我们的系统上进行了运行一小时。运行产生了如此多的日志，以至于 Filebeat（版本 7.2.1）处理所有这些日志实际上又花了三个小时。令人困惑的是 Zabbix 和 Kibana Stack Monitoring.

关于 CPU 利用率的报告

Zabbix 报告如下所示

表明CPU在测试结束后的三个小时内（即从13:00开始）以20%的速率使用。

另一方面，Kibana Stack Monitoring 显示 CPU 同期使用率为 80%。

Kibana 上的工具提示说：

Percentage of CPU time spent executing (user+kernel mode) for the Beat process.

所以，这个用法显然只针对 Filebeat 进程。这与 Zabbix 报告的 20% 不相符。

提一下，在filebeat.yml中没有设置max_procs的值，这意味着默认情况下它使用所有系统中的逻辑CPUs 。（参见 here）。我们在系统中有四个核心，总共有四个逻辑 CPU。来自 lscpu

的输出

CPU(s):                4
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1

我们使用systemctl来运行Filebeat。

谁能解释一下这种行为？会不会是 Filebeat 以某种方式只使用一个内核或 systemctl 将其限制为一个内核？

Answer 1

只是一个假设：

Zabbix system.cpu.* 项已规范化，因此您的 20% 使用率应符合两种情况：

通过在线检查，在我看来（但如果我错了请纠正我，我不是麋鹿专家！）默认情况下 kibana/metricbeat CPU 用法未标准化，所以 4 CPUs 的上限是 400%。

有讨论here and the corresponding workaround with normalized percentages

这可以解释 Zabbix 的归一化 20% 等于 Kibana/Metricbeat 未归一化的 80% 值。

但是，metricbeat 是在 80% 时使用 1 CPU 还是在 20% 时使用 4 CPU？我不知道，但根据 max_procs 它应该使用全部 4

Filebeat CPU utilization differs on Zabbix and Kibana Stack Monitoring