网易基于Filebeat的日志采集服务设计与实践.docxVIP

网易基于Filebeat的日志采集服务设计与实践 云原生技术大潮已经来临，技术变革迫在眉睫。在这股技术潮流之中，网易推出了?轻舟微服务平台，集成了微服务、Service Mesh、容器云、DevOps等组件，已经广泛应用于公司内部，同时也支撑了很多外部客户的云原生化改造和迁移。在这其中，日志是平常很简约被人忽视的一部分，却是微服务、DevOps的重要一环。没有日志，服务问题排查无从谈起，同时日志的统一采集也是很多业务数据分析、处理、审计的基础。但是在云原生容器化环境下，日志的采集又变得有点不同。 - 容器日志采集的痛点 - 传统主机模式 对于传统的物理机或者虚拟机部署的服务，日志采集工作清楚明白。业务日志直接输出到宿主机上，服务运转在固定的节点上，手动或者拿自动化工具把日志采集agent部署在节点上，加一下agent的配置，就可以开头采集日志了。同时为了便利后续的日志配置修改，还可以引入一个配置中心，用来下发agent配置。 Kubernetes环境 而在Kubernetes环境中，情况就没这么简约了。一个Kubernetes node节点上有很多不同服务的容器在运转，容器的日志存储方式有很多不同的类型，例如stdout、hostPath、emptyDir、pv等。由于在Kubernetes集群中经常存在Pod自动或者被动的迁移，频繁的销毁、创建，我们无法像传统的方式一样人为给每个服务下发日志采集配置。另外，由于日志数据采集后会被集中存储，所以查询日志时，可以依据Namespace、Pod、Container、Node，甚至包括容器的环境变量、Label等维度来检索、过滤很重要。以上都是有别于传统日志采集配置方式的需求和痛点，究其缘由，还是由于传统的方式并非针对Kubernetes设计，无法感知Kubernetes，更无法和Kubernetes集成。经过最近几年的快速进展，Kubernetes已经不只仅是容器编排的现实标准，甚至可以被认为是新一代的分布式操作系统。在这个新型的操作系统中，controller的设计思路驱动了整个系统的运转。controller的笼统解释如下图所示：由于Kubernetes良好的可扩展性，Kubernetes设计了一种自定义资源CRD的概念，用户可以本人定义各种资源，并借助一些framework开发controller，使用controller将我们的期望变成现实。基于这个思路，对于日志采集来说，一个服务需要采集哪些日志，需要什么样的日志配置，是用户的期望，而这一切，就需要我们开发一个日志采集的controller去实现。 - 探究与架构设计 - 有了上面的处理思路，除了开发一个controller，剩下的就是围围着这个思路的一些选型分析。 日志采集agent选型 日志采集controller只担任对接Kubernetes，生成采集配置，并不担任真正的日志采集。目前市面上的日志采集agent有很多，例如传统ELK技术栈的Logstash，CNCF已毕业项目Fluentd，最近推出不久的Loki，还有beats系列的Filebeat。下面简约分析一下。1. Logstash基于JVM，分分钟内存占用达到几百MB甚至上GB，有点重，首先被我们排解。2.?Fluentd背靠CNCF看着不错，各种插件也多，不过基于Ruby和C编写，对于轻舟团队的技术栈来说，还是让人止于观望。虽然Fluentd还推出了纯粹基于C言语的Fluentd-bit项目，内存占用很小，看着格外引诱，但是使用C言语和不能动态reload配置，还是无法令人亲近。3.?Loki推出的时间不久，目前功能有限，而且一些压测数据表明功能不太好，临时观望。4.?Filebeat和Logstash、Kibana、Elasticsearch同属Elastic公司，轻量级日志采集agent，推出就是为了替换Logstash，基于Golang编写，和轻舟团队技术栈完善契合，实测下来功能、资源占用率各方面都比较优秀，于是成为了轻舟日志采集agent第一选择。 agent集成方式 对于日志采集agent，在Kubernetes环境下一般有两种部署方式。1. 一种为sidecar的方式，即和业务Container部署在同一个Pod里，这种方式下，Filebeat只采集该业务Container的日志，也只需配置该Container的日志配置，简约、隔离性好，但最大的问题是， 每个服务都要有一个Filebeat去采集，而一个节点上通常有很多的Pod，内存等开销加起来不容乐观。 2.?另外一种也是最常见的每个Node上部署一个Filebeat容器，相比而言，内存占用要小很多，而且对Pod无侵入性，比较