1 方案背景
云原生架构下的日志方案比基于物理机、虚拟机场景的日志架构设计有较大的差异，比如：
1）动态的日志环境，在 kubernetes 集群环境下，应用的弹性伸缩、Pod的销毁和漂移、working节点的上线和下线都是常态，这种情况下日志的存在是瞬间的，伴随着Pod的销毁和漂移日志会被动销毁，因此日志数据需要被实时采集到集中式的存储设备中，同时对于日志采集器在此动态和复杂环境下的扩展性和适配性有新的要求。
2）资源消耗，在原有的传统ELK架构中，基于 JDK 的 Logstash 和 Filebeat 预期分别会消耗500M、12M左右的内存，在微服务、云原生的架构下，服务通常都会拆的很小，因此数据采集对于服务自身的资源消耗要尽可能的少。
3）日志平台的运维代价，运维一套动态环境下的日志采集和日志管理平台是复杂和繁琐的，日志平台应该作为底层基础设施，随业务需要快速部署，并支持水平扩展。
4）便捷的日志分析、日志系统最核心的功能是问题排查，问题排查的速度直接决定了事故响应速度、损失大小。一套可视化、高性能、智能分析的功能可以帮助用户快速定位问题。
核心需求描述：
- 全局 grep
- 根据关键字，搜索系统中出现的所有地方
- 快速定位日志
- 根据机 器名、ip、服务名等条件快速定位日志
- 主机与云原生统一技术栈
- 减少使用学习成本，降低系统复杂性
2 方案选型
云原生架构下的日志采集解决方案
编号 | 方案 | 优点 | 缺点 |
1 | 每个app的镜像中都集成日志收集组件，如logback-redis-appender | 部署方便，kubernetes的yaml文件无须特别配置，可以灵活地为每个app自定义日志采集规则 | 强耦合，应用侵入式，不方便应用和日志收集组件升级和维护且会导致镜像过大 |
2 | app的Pod内单独创建一个日志采集容器跟app的容器一起运行 | 低耦合，扩展性强，方便维护和升级 | 需要对 kubernetes 的yaml文件进行单独配置，略显繁琐 |
3 | 以 DaemonSet 方式在每个工作节点上启动一个日志采集的Pod, 将所有的Pod的日志都挂载到宿主机上 | 完全解耦，性能最高，管理起来最方便 | 需要统一日志收集规则，目录和输出方式 |
图：方案1，应用内置采集组件，异步采集
方案1
图：方案2，Pod伴侣容器，Sidercar模式
方案2
图：方案3，宿主机统一采集方案
方案3
注：kibana vs graylog，主要考虑graylog在搜索易用性、账户集成、按角色授权、日志分组，以及水平扩展问题做的更好。附graylog高可用部署架构图如下：
graylog高可用部署架构图
3 痛点分析
常见方案：logback+filebeat+es+kibana
痛点分析：
- pod重启时日志覆盖问题
- kibana搜索语法需要较高的学习成本
- 日志分组保存设立期限，日志分组授权，账户集成等支持较弱
- exception日志换行导致内容缺失
- 当日志量较大时，filebeat需先写入kafka或redis，通过logstash取出日志写入es以避免es写入压力过大
- filebeat采集方式，要求接入项目将日志写入外部存储文件，需要在项目中添加多行配置，推广时需要项目方配合实施，难度较大。
4 推荐方案
注：protail+loki+grafana轻量级日志方案，promtail采集针对主机部分还不完善，需要二次开发，暂不考虑。
建议采用方案三，日志采集使用fluentd的DaemonSet方式，日志存储使用elasticsearch，日志检索使用graylog。 该方案对业务项目入侵影响低，整体实施难度低，运维配置及后期维护相对简单。
后续文章会介绍方案三的实施步骤情况，欢迎大家关注点赞评论，您的鼓励是我最大的动力！
版权声明：内容来源于互联网和用户投稿 如有侵权请联系删除