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学习小组的同学可以关注下方公众号~**
2313
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
