导读：网易从2015年就开始了云原生的摸索与实际，作为可观测性的重要一环，日志平台也经验了从主机到容器的演进，撑持了团体内各业务部门的大规模云原生化革新。本文会讲述在这个过程中咱们遇到的问题，如何演进和革新，并从中积淀了哪些教训与最佳实际。
次要内容包含：
- Operator化的⽇志采集
- ⼤规模场景下的窘境与挑战
- 开源Loggie的当初与将来
01云原⽣最后的摸索 Operator化的⽇志采集
晚期公司外部业务跑在物理机上时，各业务应用的日志采集工具、日志直达和存储、配置下发都比拟凌乱，选型品种多。公司内基于轻舟平台推动了各服务容器化和云原生化，随着服务一直地迁徙到K8s上，咱们对于采集K8s容器日志和日志平台方面积攒很多实践经验。
云原生日志是什么样的，容器日志采集和主机上服务的日志采集有什么差别？首先Pod在K8s中会频繁地产生迁徙，手动去节点上变更配置日志采集配置不太切实际。 同时，云原生环境中日志存储的形式多样，有容器规范输入和HostPath，EmptyDir，PV等。另外，采集日志后，个别会依据云原生环境的Namespace、Pod、Container、Node甚至容器环境变量、Label等维度进行检索和过滤，这些元信息须要在日志采集时被注入。
常见的云原生环境日志采集有以下三种思路：
- 只采集规范输入
日志打印到规范输入的操作尽管合乎云原生十二因素，然而很多业务还是习惯输入到日志文件中，而且只采集规范输入日志难以满足一些简单业务的需要。惯例的采集规范输入日志的形式是挂载/var/lib/docker，/var/log/pods下的目录。同时须要留神选型的日志Agent是否反对注入k8s元信息。
- Agent⽇志门路全局挂载
日志能够放在EmptyDir，HostPath或PV存储中，通过DaemonSet形式把日志采集Agent部署到每一台k8s节点上。EmptyDir等存储映射到节点的目录能够通过通配的形式配置到Agent进行采集，由Agent读取配置门路下的日志文件。
但这种通用匹配的形式无奈依据服务级别进行独自配置。如果须要配置只采集某些服务的日志、或是某一个利用和其余利用的格局不同，例如某个利用的日志是多行的日志，此时须要独自批改配置，治理老本比拟高。
- Sidecar⽅式
每个业务Pod在部署时都减少一个日志采集的Agent SideCar，能够通过容器平台或k8s webhook的形式把日志采集Agent注入到Pod内。Agent能够通过挂载雷同的HostPath或EmptyDir的形式采集到业务容器的日志。
这种形式的弊病是对Pod侵入性强，Pod数量多时资源耗费较大。
比照DaemonSet和SideCar两种部署形式，DaemonSet在稳定性、侵入性、资源占用方面有劣势，但隔离性、性能方面SideCar形式更好。咱们实际中会优先应用DaemonSet形式采集日志。如果某个服务日志量较大、吞吐量较高，能够思考为该服务的Pod配置Sidecar形式采集日志。
针对日志采集方面的痛点，咱们提出的第一个初步计划是：自研的Ripple Operator配合开源的日志采集客户端Filebeat进行业务日志采集。
部署方面，FileBeat、Ripple通过SideCar形式部署在一起，Ripple监听k8s。在应用方面，用户通过CRD，一个CRD能够示意一个服务的日志采集配置，Ripple能够和k8s交互感知到Pod生命周期。Ripple能够下发配置到Agent，主动增加Pod相干元信息并注入到日志中。存储方面HostPath、EmptyDir、PV、Docker Rootfs都能够反对。
图中日志采集的架构先在网易严选进行了利用， 前面逐步地被公司内绝大多数部门参考落地，具体架构会依据理论环境有所区别。首先日志平台下发配置，Ripple监听到K8s的CRD配置变动后，把配置下发给Filebeat。Filebeat把采集到的日志发送到中转折，中转折发送给Kafka，Flink生产Kafka数据进行解决后转发给后端日志存储。
02进⼊深⽔区 ⼤规模场景下的窘境与挑战
随着接入的业务越来越多，1.0版本的日志架构逐步裸露了一些问题：超大规模下零碎的稳定性问题、日志平台性能问题、排障艰难和排障需要一直增多、保护人力老本直线升高等。
在后面介绍的架构中，Filebeat会把每个服务的日志发送给中转折。然而Filebeat是一个繁多的队列架构，在中转折的阻塞会影响整个节点的Filebeat日志上报。
咱们尝试把Filebeat革新成多队列的模式加强隔离性，然而因为Filebeat自身的设计架构局限，重构的成果和运行状态都不现实，同时与开源版本的保护和降级存在很大艰难。
Filebeat只反对单个Output，当用户须要把日志发送到多个Kafka集群时，只能在同一个节点上部署多个Filebeat。导致运维老本高、计算资源耗费大、程度扩大艰难。
Filebeat设计之初是为了解决Logstash的问题，作为轻量级的日志采集端运行，不适宜作为直达。Logstash在日志切分、解析等方面表现出色，然而问题在于性能较弱。尽管Flink性能和表现出色，但咱们的很多场景只须要简略的日志切分，Flink个别依赖流式解决根底平台的反对，同时在交付过程中用户要额定付出Flink的机器和运维老本，所以咱们须要一个更轻量、老本更低的计划。
此外，日志采集过程的可观测性和稳定性也很重要。在用户应用过程中常常会遇到日志没有按预期采集、日志采集提早、日志失落、日志量增长速度过快磁盘爆满等问题，Filebeat没有提供这些欠缺等监控指标，同时还须要额定部署prometheus exporter。
咱们以一个线上问题为例。线上某集群常常遇到磁盘使用量短时间内暴增到90%以上并触发报警的状况。理论登录节点排查问题后，发现报警的起因在于上游Kafka吞吐量不够，一些日志文件没有齐全采集结束，Filebeat过程默认保留文件句柄直到文件采集结束，因为文件句柄没有开释，底层的文件无奈被真正删除。但在这种状况下，Filebeat不足输出提早、发送提早和沉积状况等指标，影响稳定性。
在一个大流量的节点，咱们发现Filebeat发送数据到上游Kafka时整体数据处理速度不现实，于是进行了很多优化的尝试，比方换SSD的Kafka集群、改Kafka配置、优化Filebeat配置等调优。咱们发现在Filebeat不关上数据压缩的状况下，最大数据发送速度达到80MB/s后很难再有晋升，关上数据压缩后Filebeat的CPU的耗费又暴增。调整Kafka或Filebeat参数、机器等配置的优化成果不显著。
那么除了Filebeat外，其余的日志采集工具能不能满足需要？以后支流的日志采集Agent对容器化场景下的日志采集反对不太现实，大部分开源日志采集工具仅反对到容器规范输入的采集，对云原生下日志采集也没有整体解决方案。
03新的征程 开源Loggie的当初和将来
基于Filebeat和现有支流数据采集工具的状况，咱们决定自研日志采集Agent——Loggie。它是基于Golang的轻量级、⾼性能、云原⽣⽇志采集、聚合Agent，⽀持多Pipeline和组件热插拔，整体架构如图。
咱们增强了Agent的监控和稳定性，能够利用Monitor EventBus上报Agent运行状况，同时裸露了可调用的Restful API和Prometheus拉取监控数据的接口。配置管理方面，目前应用K8S进行配置下发和治理，后续会接入更多配置核心供用户治理配置。
Loggie提供了一栈式日志解决方案，新Agent不再离开保护Agent和中转折。作为一个可插拔组件，Agent既能够作为日志采集端应用，也能够作为中转折应用，同时反对日志直达、过滤、解析、切分、⽇志报警。Loggie同时提供了云原生日志采集残缺解决方案，比方通过CRD的模式利用K8s的能力下发配置、部署等。基于咱们长期的大规模运维日志收集服务的教训，Loggie积淀了全⽅位的可观测性、疾速排障、异样预警、⾃动化运维能⼒的性能。Loggie基于Golang开发，性能十分好，它资源占⽤小、吞吐性能优异、开发效率高保护成本低。
- ⼀栈式⽇志解决⽅案
Agent既能够作为日志采集客户端，也能够作为中转折应用。在日志直达方面，咱们通过实现Interceptor模块逻辑实现日志的分流、聚合、转存、解析、切分等。通过K8s的CRD能够下发日志采集Agent配置。新的日志采集架构整体保护老本更低。
在采纳Loggie之前咱们有两种报警计划：第一种是基于ElastAlert轮询Elasticsearch进行日志报警，该计划存在配置下发须要手动配置、告警接入不能自动化和高可用不欠缺等问题；第二种是基于Flink解析关键字或是对日志进行正则匹配进行报警，在后面咱们曾经介绍过，对于整体日志采集服务而言Flink是比拟重量级的。
在采纳Loggie后，咱们能够应用logAlert Interceptor，在日志采集过程中就能够通过关键字匹配辨认info或error进行报警。也能够通过独自部署Elasticsearch Source的Loggie Aggregator对Elasticsearch进行轮询，把信息发送到Prometheus进行报警。新版日志报警架构更轻量，保护起来也更简略。
在我的项目开发方面，咱们秉承微内核、插件化、组件化的准则，把所有组件形象为component。开发者通过实现生命周期接口，能够疾速开发数据发送端逻辑、数据源读取逻辑、解决逻辑和服务注册逻辑。这样的设计让需要能更快更灵便地实现，大大了日志采集侧的开发效率。
基于灵便高效的Agent数据源设计，咱们能够配置kubeEvent source采集K8S Event数据作为监控报警的补充。相比从新实现一个采集K8S Event我的项目，只须要在Loggie上实现对应的source，其余如队列缓存、解析日志、发送日志的逻辑都能够复用。
- 云原⽣的⽇志状态
用户通过配置LogConfig CRD，能够指定采集Pod、节点、集群日志信息。图中的例子是通过labelSelector匹配要采集的Pod，并配置容器内日志门路；通过Sink CRD和Interceptor CRD能够配置日志发送和日志解决、解析形式。
通过CRD的形式买通日志解决链路，用户能够通过配置CRD定义日志直达、聚合和发送的计划，能够配置日志的解析、限流、报警规定，在进行私有化部署和将日志服务平台化时大大降低了配置管理的复杂度，一旦有配置变更，k8s能够疾速地把配置同步到日志采集服务中。
在k8s中咱们提供了多种部署计划, 作为Agent部署时，咱们提供了DaemonSet或SideCar形式进行部署。作为直达节点部署时能够作为StatefulSet部署。日志采集的架构上更加灵便，能够间接发送到ES，也能够发送给Kafka再交给直达节点，部署不便。
- ⽣产级个性
咱们为日志采集Agent增加了欠缺的指标，包含日志采集进度、长期采集未实现、采集发送提早、FD数量、输入QPS和其余服务级别指标，提供了原生Prometheus格局的接口、RestAPI和指标发送Kafka等形式裸露指标。
日志采集服务大规模部署的稳定性和排障两方面有很大晋升。咱们通过独立各个采集工作Pipeline加强服务隔离性，还能够通过Interceptor提供了QPS限度，定时清理日志避免磁盘写满，减少了日志文件突发增长检测和正当的Fd保留机制等。
- 资源与性能
咱们利用Filebeat进行了基准测试，在解决单⾏、单⽂件、雷同发送并发度、⽆解析的场景下，发送日志⾄Kafka。
测试后果上看Loggie性能大幅度晋升，耗费CPU为Filebeat的1/4、吞吐量为Filebeat的1.6-2.6倍，且极限吞吐量与Filebeat的80MB/s瓶颈晋升到200MB/s以上。
04Loggie开源打算
Loggie曾经开源，上面是咱们我的项目推动的RoadMap和正在做的事，欢送感兴趣的开发者一起参加我的项目。
Loggie我的项目地址：https://github.com/loggie-io/...
分享嘉宾：傅轶 网易数帆 轻舟日志平台负责人、架构师
目前专一网易数帆轻舟云原生日志平台研发，致力于云原生技术及其生态体系建设和商业化落地，对Kubernetes、Serverless、可观测性等有较深入研究，具备丰盛的云原生分布式架构设计开发教训与我的项目实际。