在早期的项目中,如果想要在生产环境中通过日志定位业务服务的Bug 或者性能问题,则需要运维人员使用命令挨个服务实例去查询日志文件,这样导致的结果就是排查问题的效率非常低。
在微服务架构中,服务多实例部署在不同的物理机上,各个微服务的日志也被分散储存在不同的物理机。集群足够大的话,使用上述传统的方式查阅日志就变得非常不合适。因此需要集中化管理分布式系统中的日志,其中有开源的组件如Syslog,用于将所有服务器上的日志收集汇总。
然而集中化日志文件之后,我们面临的是对这些日志文件进行统计和检索,比如哪些服务有报警和异常,这些都需要有详细的统计。所以,在以前出现线上故障时,经常会看到开发和运维人员下载服务的日志,并基于 Linux 下的一些命令(如 grep、awk 和 wc 等)进行检索和统计。这样的方式不仅工作量大、效率低,而且对于要求更高的查询、排序和统计等操作,以及庞大的机器数量,难免会有点“力不从心”,无法很好地胜任。
如果日志放到容器内部,会随着容器删除而被删除。容器数量很多,按照传统的查看日志方式已变不太现实。了解容器的日志收集方式,我们首先看下如下三个问题:
大家可以思考如上的问题,我们在后面会逐步解答。
关于容器的日志分好几种,针对 k8s 本身而言有三种:
1、资源运行时的event事件。比如在k8s集群中创建pod之后,可以通过 kubectl describe pod 命令查看pod的详细信息。
2、容器中运行的应用程序自身产生的日志,比如tomcat、nginx、php的运行日志。比如kubectl logs redis-master-bobr0。这也是官方以及网上多数文章介绍的部分。
3、k8s各组件的服务日志,比如 systemctl status kubelet。
K8s本身特性是容器日志输出控制台,Docker 本身提供了一种日志采集能力。如果落地到本地文件,目前还没有一种好的采集方式。所以新扩容Pod属性信息(日志文件路径,日志源)可能发生变化流程和传统采集是类似的,如下图。
一般来说,我们用的日志收集方案有两种:
官方使用的是最后一种方式,将 ElesticSearch 和 kibana 都运行在 k8s 集群中,然后用 daemonset 运行 fluentd。
ELKB 是一个完整的分布式日志收集系统,很好地解决了上述提到的日志收集难,检索和分析难的问题。ELKB 分别是指 Elasticsearch、Logstash、Kibana 和 Filebeat。elastic 提供的一整套组件可以看作为 MVC 模型,logstash 对应逻辑控制 controller 层,Elasticsearch 是一个数据模型 model 层,而 Kibana 则是视图 view 层。logstash 和 Elasticsearch 基于 Java 编写实现,Kibana 则使用的是 node.js 框架。
这种架构下我们把 Logstash 实例与 Elasticsearch 实例直接相连。Logstash 实例直接通过 Input 插件读取数据源数据(比如 Java 日志, Nginx 日志等),经过 Filter 插件进行过滤日志,最后通过 Output 插件将数据写入到 ElasticSearch 实例中。
Filebeat 是基于原先 logstash-forwarder 的源码改造出来的,无需依赖 Java 环境就能运行,安装包10M不到。
如果日志的量很大,Logstash 会遇到资源占用高的问题,为解决这个问题,我们引入了Filebeat。Filebeat 是基于 logstash-forwarder 的源码改造而成,用 Go 编写,无需依赖 Java 环境,效率高,占用内存和 CPU 比较少,非常适合作为 Agent 跑在服务器上。
Filebeat 所消耗的 CPU 只有 Logstash 的 70%,但收集速度为 Logstash 的7倍。从应用实践来看,Filebeat 确实用较低的成本和稳定的服务质量,解决了 Logstash 的资源消耗问题。
本文介绍了分布式日志系统 EFK 的相关概念介绍,日志主要用来记录离散的事件,包含程序执行到某一点或某一阶段的详细信息。ELKB 很好地解决了微服务架构下,服务实例众多且分散,日志难以收集和分析的问题。
下面的文章将会进入具体实践,如何在 K8s 上搭建出 EFK 日志系统,并进行相应的微服务日志采集。