坚持更新文章的博客写手，擅长Java、python、vue、shell等编程语言和各种应用程序、脚本的开发。记录成长，分享认知，留住感动。
最近在研究一个很有意思的事情：如何收集 里的日志。问题就是这的简单，但是实现下来就有一点点的复杂了。
这里，我们先来捋一下k8s的架构图，我就不整那么复杂了，什么 之类的。我们就简化一点：以下是一主三从的k8s集群。
每一个从节点都有对应的pod在运行，具体的pod运行什么，这个就是节点来决定。某个pod就类似于我们用到的dokcer容器，每个容器运行我们的每个实例。现在，我们的每个实例都会有对应的日志输出，我们需要采集起来，放到中存储，展示的话，就要依靠我们熟知的n了。
这就是具体的业务场景。那解决的思路是这样的，我们由浅入深。
方案一
直接在官方的中找到对应的pod查询日志。
这个界面相信大家都熟悉不过了，当初搭建k8s的时候都是奔着这个界面去的。上边的都很详细，监控、日志都可查看。唯一不足的是：需要懂基本的lunix命令。
额，是不是觉得有点low了，开启第二种方式。
方案二
从日志文件分析，我们会发现我们的每个pod 产生的日志会被收集起来，集中挂载到物理机目录下边。而这些文件的命名规则也很给力：
基本是容器的名字+容器的ID，这些文件的日志格式也是k8s提前帮我们规定好了，我们似乎解析这些文件就可以获得pod的日志了。
但是问题来了，根据我们上边的架构图，pod运行在哪里是master决定的，不是我们决定的。当然，在上我们可以加上一些策略，让k8s选择我们规定的节点部署，但是这样有破坏了集群的负载均衡功能啊。
总不能在每个k8s节点上都部署一个日志解析的工具吧。加一个极点我就要部署一套日志解析的服务，这样真的是不划算！
相信这个时候ELK的技术方案已经提上了日程。
这种架构的思想是：我们的日志传输到，然后由解析日志，写入到，最后由展示和统计。
我很有幸在我实习的公司就接触到了这样的项目，我们当时采用的是消息队列传输日志，中间自写服务消费日志，最后把日志输出到存储起来。一气呵成，知道今天我也为当时的架构师设计方式感到由衷的赞叹。
当时我在接触这个项目的时候，其实也有这样的问题：为什么不去使用官方推荐的呢？那样用起来更简单，而且维护的成本很低，当时得到的解答是：是用java编写的，它的资源消耗比较大。当时我也没有多想，毕竟我们当时的日志量是非常大的，一秒钟的峰值接近条，如果直接用单实例的跑，直接会把服务干崩了。
好了，继续回到现在的问题场景，貌似我们使用第一套的可能性比较小，因为引入消息队列，又需要额外的维护成本。而且，我们也不是专业的运维，很多服务的监控指标都没法采集的。于是果断的放弃。
那只能基于下边的的方式了。今天的文章中，也是采用的这种方式解决的问题。
方案三
我直接先展示我的架构图吧：
在我们生成日志的时候，通过的接口异步的传输日志，后边的事情就交给了，我们只需要在的查询页面开始观测日志的输出和查询。
基于以上的方案，我们先来看一下效果：
我本地的ELK集群是这样的：
我使用搭建起来了我的服务，docker-compose文件可以参考我的，已经设计好了各种端口的映射、文件的挂载，直接运行即可。
现在我们的三个服务都起来了，我们持续监控一下服务的状态，同时打开我们的服务，它的日志是这样的：
和我们常见的都一样，输出了查询的sql语句。我们再来看下的界面，刚才我们的日志也展示出来了。而且字段很全，自动的帮我们处理了。
那边的日志我们也看到了实时的解析。
在下一篇的文章里，我会具体的讲解如何的配置，共同期待。
参考文章：
- logback（三）mybatis-plus结合logback将sql语句输出到日志文件
- logstash-codec-json_lines
- spring boot整合ELK
- Logstash数据源为日志文件操作
- Logstash作为udp/tcp数据
- 🥰springboot中使用logback将日志写入到ELK平台
- Logging Architecture
- Run Filebeat on Cloud Foundry
以上就是今天分享的全部内容了，觉得不错的话，记得支持一下哈，您的鼓励和支持将是坚持日更的动力。同时，在多个平台都有文章的同步，也可以同步的浏览和订阅：
与一起，每天不一样！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
如需转载请保留出处：https://bianchenghao.cn/bian-cheng-ri-ji/57704.html