1. 问题
大周一早上就收到一封惊喜邮件,内容是:服务告警!!!,内存从周五晚上到周一早上突然升高,高于平均值10个百分点。
2. 问题排查
说明:我们使用的日志管理和日志分析的框架是 ELK(Elasticsearch, Logstash, Kibana),然后业务服务的容器和filebeat的容器在k8s的同一个pod下
- 遇到内存或者cpu突然升高首先要想到的就是服务是否有大面积报错或者内存溢出。
- 查看服务日志发现日志平稳无异常报错等。
- 查看服务上报日志看下是否用户在这个区间使用量比之前多。
- 如果是用户量增加或者访问高峰期也有可能出现内存升高或者cpu升高,这种情况可能就要优化服务或者增加硬件配置等。
- 查看kibana上报日志的时候发现一个奇怪的问题,发现kibana上的日志在出现问题的时间区间没有被收集到。
- 开始排查logstash(收集日志管道),发现logstash在这段时间出现了问题,这里细节就不展开了。
- 由于logstash故障,所以容器服务的filebeat在往logstash写数据时出现异常,最终导致数据可能被缓存到内存的队列当中,这个时候出现内存升高。
ps:如果遇到cpu升高内存升高这种问题,除了以上还可以排查JVM垃圾回收信息,或者通过VisualVM来查看堆栈等相关信息,这种排查方式后面也会出一篇文章和大家分享~
3. 知识扩展
理解Logstash 和 Filebeat
Logstash 和 Filebeat 在 ELK(Elasticsearch, Logstash, Kibana)框架中的两个组件,ELK框架是一种流行的开源日志管理和分析解决方案。它提供了从收集、处理到存储和可视化日志数据的一整套工具。
- Filebeat:
○ Filebeat 是一个轻量级的日志转发器,主要用于从不同源收集日志文件并将其发送给 Logstash 或 Elasticsearch。
○ 它通常运行在目标服务器上,负责日志的采集和预处理。 - Logstash:
○ Logstash 是一个数据处理管道,用于接收来自 Filebeat 的数据,执行数据转换、过滤和丰富等操作,最后将处理后的数据发送到 Elasticsearch 存储。
○ 它通常运行在一个独立的服务节点上,负责数据的处理和转发。
两者之间的关系如下:
● Filebeat 收集日志数据后,可以通过多种方式发送给 Logstash,包括直接发送、通过 TCP/UDP 协议或者使用 Beats 输入插件。
● Logstash 通过特定的输入插件(如 Beats 输入插件)接收来自 Filebeat 的数据。
Logstash 或 Filebeat 影响内存或其他负载的因素
- Filebeat 配置:
○ 如果 Filebeat 配置为使用缓冲队列(queue),当 Logstash 无法接收数据时,Filebeat 会继续收集数据并将其暂存在本地队列中。如果 Logstash 无法处理数据的速度超过了 Filebeat 发送数据的速度,那么 Filebeat 的内存使用可能会增加。
○ 特别是 queue.mem.events 参数控制了队列中事件的数量,如果设置得较小,可能会更快达到上限,导致更多的数据被缓冲在内存中。 - Logstash 处理能力:
○ 如果 Logstash 因为性能问题(如高 CPU 使用率、内存不足或配置不当等)而无法及时处理来自 Filebeat 的数据,那么 Filebeat 的内存使用量可能会增加。
○ 如果 Logstash 完全崩溃或不可达,Filebeat 可能会尝试重试发送数据,这也会导致内存中的数据积压。 - Filebeat 的重试机制:
○ Filebeat 具有重试机制,如果 Logstash 不可用,Filebeat 会尝试重新发送数据直到成功。
○ 如果重试间隔设置得太短,或者 Logstash 问题持续时间较长,这可能导致 Filebeat 的内存使用量显著增加。
总结
如果 Logstash 出现问题并且不能及时处理来自 Filebeat 的数据,那么 Filebeat 的内存使用量确实有可能增加。为了避免这种情况,我们可以调整 Filebeat 的配置,比如增大队列大小或调整重试间隔,同时也要确保 Logstash 的稳定性和性能足够好。如果发现容器或者pod内存使用过高,检查 Logstash 的状态也是一个不错的起点。
本篇文章到这里就结束了,最后送大家一句话 白驹过隙,沧海桑田
获取2024大厂面试资料、学习工具、微服务电商项目源码,加入java学习小组的同学可以关注下方公众号~**