网易云原生日志平台的架构演进与实践

1. 网易云原生日志平台的架构演进与实践傅轶｜网易

2. 01 02 03 云原生最初的探索 Operator化的日志采集进入深水区大规模场景下的困境与挑战新的征程开源Loggie的现在与未来

3. 1. 云原生最初的探索 Operator化的日志采集

4. 混乱与秩序 ➤ 混乱的主机时代 ➤ 上云/云原生化云原生的日志是什么样❓ • 采集Agent: Filebeat/Logstash/Flume/Rsyslo • 中转：Kafka/Logstash/Flin • 存储：Elasticsearc • 配置下发：手动/各种配置中心公司内基于轻舟的容器化、云原生化进程不同部⻔日志选型、架构各异

5. Kubernetes下的日志采集难题 ➤ 和主机日志的差异动态迁移 Pod会主动或者被动的迁移，频繁的销毁、创建无法人为下发日志采集配置日志存储多样性容器的日志存储与表现方式有很多不同的类型例如stdout、hostPath、 emptyDir、pv等 Kubernetes元信息查询日志时，需要根据 namespace、pod、container、 node，甚至包括容器的环境变量、label等维度来检索、过滤

6. 容器日志采集常⻅思路 ➤ 只采集标准输出 • 挂载stdout路径、path通配 • 一些Agent实现了watch Kubernetes，注入 Namespace/Pod等元信息符合云原生12要素，但是不适合复杂业务，难以推广

7. 容器日志采集常⻅思路 ➤ Agent日志路径全局挂载 • emptyDi • hostPath (K8s1.15以上可使用subPathExpr路径隔离 • pv 无Kubernetes元信息注入无法针对服务级别单独配置

8. 容器日志采集常⻅思路 ➤ Sidecar方式 • 每个业务Pod增加一个日志采集 Agent sideca • 挂载相同的empty/hostPath. • Agent挂载配置文件configMap 侵入性较强；资源占用较多 • eg: 增加一个sidecar将业务日志文件转换成自身容器的stdout，采集stdout日志 ➤ 其他

9. 轻舟日志服务v1.0 ➤ Sidecar方式和DaemonSet选择资源占用侵入性稳定性隔离性性能 DaemonSet 每个节点一个，较小基本无侵入不影响业务Pod 节点日志都由同一个 Agent采集，较差节点日志量大时可能出现瓶颈 Sidecar 每个Pod一个，较大 Pod部署侵入 Agent OOM等会影响业务Pod； Agent只采集所在Pod 只采集所在Pod，出现数量多影响下游组件日志，较好瓶颈概率较小 Tips 优先使用DaemonSet的方式采集日志，如果某个服务日志量特别大，可以单独使用Sidecar的方式采集日志

10. 轻舟日志服务v1.0 ➤ 适配云原生的核心架构设计自研Ripple + 开源日志采集Agent Filebeat 解决了开源Agent在Kubernetes环境下的不足： • 基于CRD日志配置指定Pod • 自动感知Pod生命周期 • 自动添加服务元信息 • 支持采集日志盘hostPath/emptyDir/ Pv/docker rootfs

11. 轻舟日志服务v1.0 ➤ 在严选 ➤ 被集团绝大多数部⻔使用 …

12. 2. 进入深水区大规模场景下的困境与挑战

13. 进入深水区，远比表面复杂采集查询人肉运维越来越多冰山一⻆ ETL 超大规模客户场景复杂排障痛苦功能开发难以扩展性能不足稳定性难以支撑更大规模

14. Filebeat单个队列问题 ➤ 在严选的隐患：隔离性不足问题 Flume中转机一个队列发生堵塞，会导致某节点发送到该中转机的Filebeat全部发送日志失败尝试将Filebeat改造成多队列，试图增强隔离机制隐患 Filebeat先天架构的不足，引入很多workaround的改动，导致代码不便维护，存在oom等隐患

15. Filebeat只支持一个Output ➤ 扩展受限需求客户需要发送日志到两个Kafka集群，存储不同类型的日志避免单个Kafka集群的性能瓶颈 ❓ 临时方案 Filebeat只支持单个output，只能一个节点部署多个Agent 后果引入大量运维维护成本，资源占用增多，水平扩展麻烦

16. Filebeat不适合做中转机 • • • • 中转聚合解析切分 … ➤ 目前方案 B. Flink A. Logstash Logstash性能较弱 ● 语言栈不统一，引入另外服务，增加维护成本 ● 手动配置 ● 大部分场景只需要简单的日志切分 ● 要求有配套的运维、监控、排障能力 ● 依赖流式处理平台 ●

17. 可观测性/稳定性不足排障痛苦 • 日志为什么没有采集? • 日志采集查询有延迟 • 日志为什么丢了？ metrics不足 ❓ 指标割裂，和服务无关联 • 快速增⻓的日志占据满了磁盘无Prometheus格式 … 突发预警不够

18. 可观测性/稳定性不足 ➤ 举例：幽灵文件现象传媒线上集群节点磁盘使用率一直在增⻓，90%+报警，但是文件实际占用不多原因日志滚动会删除文件，但是由于下游Kafka吞吐不够，导致Filebeat继续保持文件句柄fd，发送日志文件，确保日志文件不丢失；但被删除的文件仍然占据了磁盘空间；反思没有日志输入指标 ● 没有发送延迟指标 ● 没有堆积指标 … ● Filebeat核心监控指标不够，影响稳定性

19. 性能不够问题网关节点单台审计日志量大，Filebeat无法及时发送，导致消费端无法实时处理和展示数据尝试优化配置调优，换独立SSD Kafka集群，仍然无法超过80MB/ 如果配置发送数据压缩，会导致CPU 1000%+

20. 其他的开源项目能否解决这些问题？ ➤ 对比基于Golang，资源占用较小，性能优异，语言栈匹配基于JRuby，比较消耗资源，性能较差基于Java，比较消耗资源，性能一般基于Ruby，性能一般技术语言栈：部分性能差，部分开发效率低 ● 容器化场景支持：部分不支持，部分只支持容器标准输出 ● 完整日志解决方案：均未提供 ● 基于C，资源占用小，性能好，开发效率低

21. 3. 新的征程开源Loggie的现在和未来

22. 自研新版Agent 基于Golang的轻量级、高性能、云原生日志采集、聚合Agent，支持多Pipeline和组件热插拔

23. 核心概念 • Source：输入源，一个Pipeline可以有多个不同的输入源 • Sink：输出源，一个Pipeline仅能配置一种类型的输入源，但是可以有多个并行实例 • Interceptor：拦截器，数据流经过多个Interceptor被链式处理 • Queue：队列，目前有内存队列 • Pipeline：管道，sources/interceptors/queue/sink共同组成了一个Pipeline，不同的Pipeline数据隔离 • Discovery：配置下发，目前支持Kubernete • Monitor EventBus：各组件监控数据的暴露或发送 • Reloader：配置的动态更新

24. 特性一栈式日志解决方案可插拔组件，可扩展性大大增强，可同时支持日志中转、过滤、解析、切分、日志报警等生产级特性吸收了我们⻓期的大规模运维经验，形成了全方位的可观测性、快速排障、异常预警、自动化运维能力云原生的日志形态快速便捷的容器日志采集方式，原生的Kubernetes动态配置下发资源与性能基于Golang，较小的资源占用，优异的吞吐性能，较高的开发效率

25. ➤ 中转、聚合、解析、处理 01 ➤ 日志报警一栈式日志解决方案 ➤ 快速研发不仅仅是日志采集优异的可扩展性 ➤ 更多扩展

26. 中转、聚合、解析、处理 ➤ 基于各类Interceptor 流处理/SQL/Function 解析、切分分流、聚合、转存 • 统一技术栈，无需引入Flume或者 Logstash等第三方中转，便于维护 • CRD里写解析规则等，实时生效，自动reload，易于使用

27. 日志报警 ➤ 之前 ➤ 现在使用logAlert Interceptor即可基于ElastAlert 使用ElastAlert轮询Elasticsearch （存在配置下发、告警接入、自身高可用等问题） ● 基于采集链路 ● 单独部署，使用Elasticsearch Source 基于Flink 在Flink里解析关键字或者正则匹配（存在重量级、依赖配套的运维、监控报警、排障等问题）

28. 快速研发 ➤ 微内核，插件化，组件化 • 所有插件均抽象为component，通过实现生命周期接口，可快速开发一个sink/source/ interceptor/discovery Everything is component

29. 更多扩展 ➤ 采集K8s Event ● 组件复用（缓存、性能、重拾、配置等等） ➤ 定时冷备 ● 只需研发特定场景的功能组件 ● 效率提升/可扩展性强

30. 02 ➤ 基于CRD的使用方式 ➤ Kubernetes下多架构支持云原生的日志形态

31. 基于CRD的使用方式只需create/update CRD实例即可： • 采集指定Pods/Node节点/集群日志 • 日志流如何中转、聚合 • 转发到哪些下游 • 解析处理日志 • 限流/日志报警检测 … 部署一键化配置自动化动态reload

32. Kubernetes下多架构支持 • 多形态： • Agen • Aggregato • 多架构： • 直接发送 • 中转、处理 • 多输出端

33. 03 生产级特性 ➤ 完善的监控指标 ➤ 解决大规模场景下的痛点

34. 完善的监控指标根据⻓期运维、排障需求归纳提炼 ● ● 完善的指标 ● 采集进度 ● ⻓期采集未完成 ● 采集发送延迟 ● Fd情况 ● 输出Qp ● 服务级别指标多种暴露方式 ● 原生Prometheus格式 ● Rest AP ● 可发送Kafk ● 日志输出

35. 解决大规模场景下的痛点吸收大规模生产实践总结的经验教训，完善功能 ➤ 稳定性 ➤ 运维排障 ● 独立Pipeline增强服务隔离性 ● 检测⻓时间未采集完成的日志文件 ● 采集Qps限制 ● 各类参数均支持全局默认配置 ● 可配置定时清理日志 ● 无采集情况的日志查询、下载 ● 检测突发增⻓的日志文件 ● 提供常⻅排障运维接口 ● 合理的Fd保留机制 … …

36. 04 ➤ 基准测试 ➤ 性能对比资源与性能

37. 基准测试 ➤ Filebeat ● ➤ Loggie 865% 217% 73.3MB/s 120MB/s 同等情况下，发送至Kafka（单行、单文件、相同发送并发度、无解析场景）

38. 性能对比 ● Loggie和Filebeat消耗的CPU相比，大概仅为后者的1/4，同时发送吞吐量为后者的1.6～2.6倍 ● Filebeat的极限吞吐量存在瓶颈，80MB/s后很难提升，而Loggie的极限值更高，多文件采集下甚至达到了200MB/s+

39. 开源计划 12月份正式开源敬请期待

40. RoadMap&Doing ● ● 更多组件与功能扩展 ● Source: htt ● Sink: file, clickhouse, pulsar, influxdb等 ● 持久化Queu ● 轻量级的流处理能力 ● WASM形态支持自定义日志解析处理 ● 支持接入Knative/KEDA等Serverless形态扩缩容指标服务发现与配置中心 ● 云原生与Kubernete ● 主机模式的配置下发：支持Consul, Apollo等 ● 自动注入Loggie sidecar形态支持 ● Opentelemetry兼容与支持参与贡献共同建设

41.