云原生日志系统 EFK 实践(一)
为什么需要分布式日志系统
在以前的项目中,如果想要在生产环境中通过日志定位业务服务的Bug 或者性能问题,则需要运维人员使用命令挨个服务实例去查询日志文件,这样导致的结果就是:排查问题的效率非常低。
在微服务架构中,服务多实例部署在不同的物理机上,各个微服务的日志也被分散储存在不同的物理机。集群足够大的话,使用上述传统的方式查阅日志就变得非常不合适。因此需要集中化管理分布式系统中的日志,其中有开源的组件如Syslog,用于将所有服务器上的日志收集汇总。
然而集中化日志文件之后,我们面临的是对这些日志文件进行统计和检索,比如哪些服务有报警和异常,这些都需要有详细的统计。所以,在以前出现线上故障时,经常会看到开发和运维人员下载服务的日志,并基于 Linux 下的一些命令(如 grep、awk 和 wc 等)进行检索和统计。这样的方式不仅工作量大、效率低,而且对于要求更高的查询、排序和统计等操作,以及庞大的机器数量,难免会有点“力不从心”,无法很好地胜任。
容器的日志收集方式
如果日志放到容器内部,会随着容器删除而被删除。容器数量很多,按照传统的查看日志方式已变不太现实。
- K8S 中收集日志与传统条件下的日志收集有什么区别?
- 他一般是收集哪些日志?
- 确定收集日志类型之后又是怎么去收集的?
容器日志的分类
关于容器的日志分好几种,针对 k8s 本身而言有三种:
1、资源运行时的event事件。比如在k8s集群中创建pod之后,可以通过 kubectl describe pod 命令查看pod的详细信息。
2、容器中运行的应用程序自身产生的日志,比如 tomcat、nginx、php的运行日志。比如kubectl logs redis-master-bobr0。这也是官方以及网上多数文章介绍的部分。
3、k8s各组件的服务日志,比如 systemctl status kubelet。
k8s 的方式
K8s本身特性是容器日志输出控制台,Docker 本身提供了一种日志采集能力。如果落地到本地文件,目前还没有一种好的采集方式。所以新扩容Pod属性信息(日志文件路径,日志源)可能发生变化流程和传统采集是类似的,如下图。
一般来说,我们用的日志收集方案有两种:
- 容器外收集。将宿主机的目录挂载为容器的日志目录,然后在宿主机上收集。
- 容器内收集。node上部署日志的收集程序,比如用 daemonset 方式部署,对本节点容器下的目录进行采集。并且把容器内的目录挂载到宿主机目录上面。目录为对本节点 /var/log/kubelet/pods 和 /var/lib/docker/containers/ 两个目录下的日志进行采集。
- 网络收集。容器内应用将日志直接发送到日志中心,比如 java 程序可以使用 log4j 2 转换日志格式并发送到远端。
- 在 Pod 中附加专用日志收集的容器。每个运行应用程序的 Pod 中增加一个日志收集容器,使用 emtyDir 共享日志目录让日志收集程序读取到。
官方使用的是最后一种方式,将 ElesticSearch 和 kibana 都运行在 k8s 集群中,然后用 daemonset 运行 fluentd。
ELKB 分布式日志系统
- Kibana :可视化化平台。Kibana 用于搜索、分析和可视化存储在 Elasticsearch 指标中的日志数据,是一个 Web 网页。Kibana 利用 Elasticsearch 的 REST 接口来检索数据,调用 Elasticsearch 存储的数据,将其可视化。它不仅允许用户自定义视图,还支持以特殊的方式查询和过滤数据。
- Elasticsearch :分布式搜索引擎。具有高可伸缩、高可靠、易管理等特点。可以用于全文检索、结构化检索和分析,并能将这三者结合起来。Elasticsearch 基于 Lucene 开发,现在使用最广的开源搜索引擎之一,Wikipedia 、*、Github 等都基于它来构建自己的搜索引擎。
- Logstash :数据收集处理引擎。支持动态的从各种数据源搜集数据,并对数据进行过滤、分析、丰富、统一格式等操作,然后存储以供后续使用。
- Filebeat :轻量级数据收集引擎。基于原先 Logstash-fowarder 的源码改造出来。换句话说:Filebeat 就是新版的 Logstash-fowarder,也会是 ELK Stack 第一选择。
这种架构下我们把 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 的资源消耗问题。
前置条件:数据储存持久化
部署前需要创建数据持久化存储,pv 和 pvc。
选择 Node1:192.168.11.196 作为 NFS 服务器 。
# 三台都安装 NFS 和 RPCBIND yum -y install nfs-utils rpcbind mkdir -pv /ifs/kubernetes systemctl enable rpcbind systemctl enable nfs systemctl start nfs
$ vim /etc/exports /ifs/kubernetes *(rw,no_root_squash)
exportfs -r
找其他机器测试:
mount -t nfs 192.168.11.196:/ifs/kubernetes /mnt/
在 NFS 即 k8snode1 上新建三个文件夹:
mkdir -pv /ifs/kubernetes/{pv00001,pv00002,pv00003}
采用动态分配 pv 的方式。
#生产动态存储卷 kubectl apply -f class.yaml #生成pods kubectl apply -f deployment.yaml #赋权 kubectl apply -f rbac.yaml # 最后自动创建存储卷 kubectl apply -f deployment-pvc.yaml #验证效果 kubectl get pv,pvc
小结
本文主要介绍了云原生日志系统 EFK 的相关概念以及集群搭建的前期准备,接下来的文章将会继续介绍 EFK 的配置实现。