系列文章：云原生Kubernetes日志落地方案( 四 )_：系列文章：云原生Kubernetes日志落地

日志的形式变的更加复杂，不仅有物理机/虚拟机上的日志，还有容器的标准输出、容器内的文件、容器事件、Kubernetes事件等等信息需要采集。环境的动态性变强，在Kubernetes中，机器的宕机、下线、上线、Pod销毁、扩容/缩容等都是常态，这种情况下日志的存在是瞬时的（例如如果Pod销毁后该Pod日志就不可见了），所以日志数据必须实时采集到服务端。同时还需要保证日志的采集能够适应这种动态性极强的场景。日志的种类变多，上图是一个典型的Kubernetes架构，一个请求从客户端需要经过CDN、Ingress、Service Mesh、Pod等多个组件，涉及多种基础设施，其中的日志种类增加了很多，例如K8s各种系统组件日志、审计日志、ServiceMesh日志、Ingress等。业务架构变化，现在越来越多的公司开始在Kubernetes上落地微服务架构，在微服务体系中，服务的开发更加复杂，服务之间的依赖以及服务底层产品的依赖越来越多，这时的问题排查将更加复杂，如果关联各个维度的日志将是一个困难的问题。日志方案集成困难，通常我们都会在Kubernetes上搭建一套CICD系统，这套CICD系统需要尽可能的自动化的完成业务的集成和部署，其中日志的采集、存储、清洗等也需要集成到这套系统中，并和K8s的声明式部署方式尽可能一致。而现有的日志系统通常都是较独立的系统，集成到CICD中代价极大。日志规模问题，通常在系统初期的时候我们会选择自建开源的日志系统，这种方式在测试验证阶段或公司发展初期是没有什么问题的，但当业务逐渐增长，日志量增长到一定规模时，自建的开源系统很多时候都会遇到各种各样的问题，例如租户隔离、查询延迟、数据可靠性、系统可用性等。日志系统虽不是IT中最核心的路径，但一旦关键时刻出现这些问题都将是非常可怕的影响，例如大促的时候出现紧急问题，排查时多个工程师并发查询把日志系统打爆，导致故障恢复时间变长，大促收到影响。总结