kubernetes日志系统

发布于 2019-05-03  12 次阅读


前言

在前面的文章中我们介绍了如何在kubernetes上部署服务,既然跑了服务,作为系统管理者我们应该对服务的日志进行记录和搜集,方便运维的排错以及开发的debug,传统的日志收集方案有一个进化的过程,从日志分布在各个机器到分布式日志集中管理(ELK/EFK)。而kubernetes的日志处理原理也是类似的,并且官方也为用户提供了几种解决方案,每种都有其优缺点,选择一个符合自己业务场景的方案是重要的。下面我们一起来学习下kubernetes的日志系统。

日志需要集中处理么?

当服务和机器规模较小的时候,代码或者程序出现了问题,我们可以登陆机器查看相应的日志,但是当业务逐渐发展,机器越来越多,服务做成了高可用集群以及各种分布式时,当问题出现时我们往往需要对比查看多个机器的日志,此时如果再一个个的查看每台机器的日志会很麻烦。此时就需要我们将分布在每台机器的日志进行集中化处理.

常见的日志处理工具

  • goaccess

(一款轻型的web日志分析工具,可以对日志生成html报表,但是功能有些鸡肋)

  • 第三方日志工具

阿里云/腾讯云的saas服务

日志易

  • ELK/EFK

一款目前主流的日志集中处理方案,最初的架构和组件为elasticsearch +logstash+kibina 。logstash作为日志采集端对日志进行收集和格式处理,然后将处理好的数据传送给elasticsearch进行存储,他是一款全文检索和搜索引擎,然后通过kibina建立index对日志进行可视化分析。

但是由于logstash也是由java编写的,如果作为日志采集端则需要每个节点都部署,未免太重了些。后来演变为将日志采集端logstash替换为消耗资源更少的filebeat或者fluentd,如果需要复杂的格式处理,则filebeat后面可以接logstash,如下图所示。

注意:

目前filebeat和flunted都集成了很多插件,大多数的日志格式需求都可以满足,有时候为了节省资源,可以将Logstash组件去掉

当收集日志的节点更多的时候,此时filebeat也会很多,收集的日志也达到了很大的量级,纵使filebeat后面配置了Logstash集群难免压力还是很大,此时需要引入消息队列用来压力缓冲,kafka是不二的选择。此时的架构如图所示

注意:

kafka集群是为了缓冲filebeat与后端(logstash)之间的压力。并且kafka做成了集群后需要zookeeper进行协调管理。

kubernetes的日志方案模式与原理

原理:

对于容器化的应用程序来说,这些日志会通过docker的日志引擎输出为json格式的日志文件中,我们可以通过建立日志代理来对容器的日志进行统一的收集,然后上报到elasticsearch。

模式:

kubernets平台常见的日志处理方案也是基于ELK/EFK,原理基本相同,只不过收集的日志是在容器中,需要我们建立一个日志代理,kubernetes官方也针对不同的场景提出了三种模式供用户选择。

模式1:node级别的日志代理

在每个node节点上独立运行一个日志代理,通常的实现方式为DaemonSet,应用程序只需要将日志写到stdout或者stderr ,docker的日志驱动会将每个容器的stdout和stderr收集并写入到宿主的文件系统(默认是/var/lib/docker/container ,这个有你自己的存储位置有关)。同时可以使用k8s的logrotate或者docker的log-opt对日志进行轮转


一个幽默,喜欢动漫,音乐,爱小动物,逐渐成为二次元肥宅的LINUX运维工程师,我会用心写博客,刚开始写的不太好。但是我会不断进步的!。就像我的博客下面写的。我宁愿做错,也不愿什么都不做 ps:好像是伊泽瑞尔说的,看来你游戏没少玩啊 23333333333333