☰

在过渡到新的 Kibana 服务器期间如何处理过多的日志条目？

tag-icon • tag-icon ubuntu elasticsearch
在过渡到新的 Kibana 服务器期间如何处理过多的日志条目？

我在更新 Elasticsearch/Kibana 设置时遇到了一个挑战，该设置涉及两个名为Kibana01和 的独立虚拟机Kibana02。每个虚拟机都托管一个 Ubuntu 和 ELK 堆栈实例。我们正在从 上的旧设置过渡Kibana01到 上的新设置Kibana02，旨在利用 ELK 堆栈的最新功能和改进。以下是每个设置的具体信息：

Kibana01虚拟机：

  • 操作系统：Ubuntu 16.04.6 LTS
  • ELK 堆栈：Elasticsearch 7.5.2，以及相应版本的Logstash和Kibana。

Kibana02虚拟机：

  • 操作系统：Ubuntu 22.04.2 LTS
  • ELK 堆栈：Elasticsearch 7.17.10，以及相应版本的Logstash和Kibana。

已确定的问题：

我们发现，与旧服务器 ( ) 相比，pim_queue_manager.sh新 Kibana 服务器 ( ) 上的服务日志条目数量异常高。以下是在两台服务器上运行以下命令后获得的结果：Kibana02Kibana01

administrator@par-kibana:~$ time gunzip -c syslog_facilities.txt | sort | uniq -c | sort -n

Kibana01（Ubuntu 16.04.6 LTS，Elasticsearch 7.5.2）：

numberfacilities_Kibana01

Kibana02（Ubuntu 22.04.2 LTS，Elasticsearch 7.17.10）：

号码facilities_kibana02

比较结果显示： Kibana01 VM 中 pim_queue_manager.sh 的日志：465,589 个条目 Kibana02 VM 中 pim_queue_manager.sh 的日志：32,786,602 个条目

在 上Kibana02，pim_queue_manager.sh服务记录了 32,786,602 条条目，而 上只有 465,589 条Kibana01。这种过载导致/var/log/syslog目录填满得太快，超出了 logrotate 的管理能力并阻止了新日志的记录。

假设：

  • 进程循环：进程中的循环Kibana02可能是造成此日志过载的原因。
  • 完整传输日志历史记录：在切换期间，虚拟机似乎将其整个日志历史记录发送到Kibana02，将其视为新日志。通常，只应传输切换后的日志。

请求协助：

我正在寻求有关如何解决这些问题的建议。如何防止将完整的日志历史记录传输到新的 Kibana 服务器并确保过渡而不会使日志系统过载？

相关内容