如果你觉得这篇文章对你有帮助，请不要吝惜你的“关注”、“点赞”、“评价”，你的支持永远是我前进的动力~~~
日志是在微服务的监控和问题排查中最重要的，数据量也最大
我们的微服务是运行在K8S环境中的，因此这里主要介绍下K8S下的采集方式。
日志（Logging）采集方式
在K8S中，日志采集有多种方式，每种方式都有其优点，也有缺点，下面官方推荐的三种方式
每台Node节点采用DaemonSet部署agent：
原理：每台节点采用DaemonSet部署一个采集日志的agent，从/var/log/containers/目录采集所有容器的日志，而容器中的日志需要遵循docker的日志规范，把日志打入stdout/stderr，这样k8s会自动在/var/log/containers/目录生成对应容器的日志。
优点：部署维护简单，且能收集所有容器的日志
缺点：需要应用程序日志支持stdout/stderr输出，如果每个节点的日志规模过多，单个采集日志的agent可能成为瓶颈，不太灵活
pod的SideCar方式
原理：每个Pod通过SideCar方式部署一个采集日志的agent
优点：每个Pod可单独配置agent，灵活性高
缺点：每个Pod都需要一个SideCar，资源损耗大
应用程序直接推送日志到日志存储
原理：部署在Pod的应用程序支持把日志直接推送到日志存储程序
优点：不用单独维护日志采集程序，运维简单
缺点：需要应用程序定制开发，开发成本大
整体的日志采集架构
为了维护方便，同时减少资源的使用量，通常会选择“每台Node节点采用DaemonSet部署agent”这种部署方式。
基于成本和日志服务的稳定性的考量，我们做了数据的冷热分离
- 冷数据放在了我们自己的IDC机房
- 线上服务的热数据存储在云上
- 测试环境的热数据存储在IDC机房
不规范问题自查、优化
- Kibana平台非常不好用。
日志不完整，一条日志被分成多条，或者被截断。通过日志格式规范化解决
搜索性能差。通过减少无关日志打印，以及采集架构优化解决
- 日志格式规范化
研发为了方便排查问题，无差别的打日志，导致无用日志的太多，日志采集延迟大
格式、级别等。如使用System.out.println() / e.printStackTrace() 输出日志，很难断句、解析，：
我们借鉴《阿里巴巴java开发手册》，自查、改进，减少了大量的日志。
- 搜索性能问题。一天内的数据搜索都会超时
为了应对采集的日志过多的问题，我们引入了Kafka，加快日志的收集
