网易云原生日志平台架构演进：Operator化采集与挑战

“8-9+网易云原生日志平台的架构演进与实践.pdf”讲述了网易在云原生日志平台构建过程中的经验与挑战，包括日志采集、处理和存储等多个方面，以及如何应对Kubernetes环境下的特殊问题。 云原生初期探索阶段，日志采集体系呈现出混乱的状态，各种不同的采集Agent（如Filebeat、Logstash、Flume、Rsyslog）和中转工具（如Kafka、Logstash、Flink）被使用，日志存储通常选择Elasticsearch。配置管理方式多样，既有手动配置，也有通过各种配置中心进行下发。这一阶段，不同部门的日志选型和架构各异，随着公司内部对轻舟容器化和云原生化的推进，日志管理面临着统一化的挑战。 在Kubernetes环境下，日志采集面临着新问题。由于Pod的动态迁移、销毁和创建，无法像传统主机那样人工配置日志采集。此外，容器的日志存储形式多样，如stdout、hostPath、emptyDir、pv等，这给日志检索和过滤带来了复杂性，需要结合namespace、pod、container、node以及容器的环境变量和label等元信息。 常见的容器日志采集策略包括只采集标准输出，但这种方式不适用于复杂业务；使用Agent全局挂载日志路径，但这可能造成资源占用和侵入性问题；以及使用Sidecar模式，每个业务Pod添加一个日志采集Agent，但这种方法对资源占用和稳定性有影响。还有其他解决方案，如将业务日志转换为stdout，通过采集stdout日志，但这同样具有一定的侵入性。 在Sidecar和DaemonSet之间选择时，需考虑资源占用、侵入性、稳定性和性能等因素。DaemonSet在每个节点上运行一个Agent，资源占用相对较小，且对业务Pod基本无侵入，但可能影响节点上的所有日志采集。而Sidecar模式能提供更好的隔离性，但可能会增加资源消耗。 网易云原生日志平台的演进过程中，逐步解决这些挑战，通过Operator化的方式优化日志采集，适应大规模场景，并关注开源项目Loggie的未来发展，旨在打造一个高效、灵活且易于管理的日志处理系统，以支持云原生环境下的业务需求。