直达最佳实践：【微服务架构日志采集运维管理最佳实践】
最佳实践频道：【最佳实践频道】
这里有丰富的企业上云最佳实践，从典型场景入门，提供一系列项目实践方案，降低企业上云门槛的同时满足您的需求！
Kubernetes日志系统的重要性
云原生对于微服务可观测性的一项重要标准就是日志记录（logging)。日志的采集、存储和分析时构建现代系统平台的关键支柱之一，可以帮助团队进行问题的诊断、质量的回溯、系统运营效率监控等。在当今容器/Kubernetes技术大火的环境下，日志系统对于Kubernetes也起着非常关键的作用，对于Devops、运营、安全等方面都离不开完整多样有效的日志采集、存储管理和分析，从下图可见。
微服务架构下日志采集运维管理面临的挑战
众所周知，随着容器/Kubernetes技术在微服务落地过程中相对物理机、VM在应用部署、应用交付等环节给用户提供了更加简单轻量、高性价比等优势，而且用户在应用容器/Kubernetes技术做微服务改造过程中，也同时存在容器化应用/非容器化应用混合部署的形态。对于基于VM或者物理机部署的应用，日志采集相关技术都比较完善，有比较健全的Logstash、Fluentd、FileBeats等，但是在应用容器化特别是基于Kubenetes集群做微服务应用部署时，日志采集运维给用户带来了不小的挑战，主要的原因有：
- 日志采集目标多，需要采集宿主机日志、容器内日志、容器stdout,存在多种应用数据及多种日志格式，缺乏统一的一站式日志采集解决方案；
- 集群弹性伸缩、环境动态性强、服务动态迁移等都给日志采集带来了很大的困难，日志采集的动态性以及数据完整性都是非常大的挑战；
- 运维成本非常大，已有的一些方案只能使用多种软件组合采集，各个软件组装起来的系统稳定性难以保障，且缺乏中心化的管理、配置、监控手段，运维负担大；
- 日志采集Agent侵入性高，Docker Driver扩展需要修改底层引擎，一个Container对应采集一个日志采集Agent又会产生资源竞争和浪费
- 日志采集性能低，正常情况下一个Docker Engine会运行数十个甚至数百个Container，此时开源日志采集Agent采集性能及资源消耗十分不理想；
- 日志分析效率和手段缺乏，开源的日志分析展现工具对于日志的实时分析、智能分析等缺乏简单有效的可视化手段。
阿里云Kubernetes日志采集方案
基于以上分析，阿里云日志服务产品针对用户在基于Kubernetes做应用微服务改造落地过程中日志采集运维管理的需求和痛点，结合阿里云组合云产品的优势，提出了一站式的日志采集运维管理分析的解决方案，提供了强大的日志处理分析能力，如PB级日志实时查询、日志聚类分析、Ingress日志分析报表、日志分析函数、上下游生态对接等能力，提供用户在 容器/Kubernetes技术落地应用微服务改造过程中的日志采集运维管理一站式能力。
- Ingress日志解决方案
Kubernetes中Ingress是一种API资源的声明，具体的实现需要由Ingress Controller来接管Ingress定义，目前比较流行的Ingress Controller实现有Nginx、Traefik、listio、Kong等，在国内接受度最高的是Nginx Ingress Controller。
日志和监控是所有Ingress Controller都会提供的基础功能，日志一般包括访问日志(Access Log)、控制日志(Controller Log)和错误日志(Error Log)，监控主要从日志以及Controller中提取Metrics信息。这心数据中访问日志的量级最大、信息最多、价值也最高，一般七层的访问日志包括：URL、源IP、UserAgent、状态码、入流量、出流量、响应时间等，对于Ingress Controller这种转发型的日志，还包括转发的Service名、Service响应时间等额外信息。从这些信息中，我们能够分析出非常多的有用信息，例如：网站访问的PV、UV；访问的地域分布、设备端分布；网站访问的错误比例；后端服务的响应延迟；不同URL访问分布等。但是手动搭建并运维一整套的Ingress日志分析与监控系统非常复杂，系统需要非常多的模块，例如部署日志采集Angent并配置采集和解析规则，部署实时数据分析引擎例如Elastic Search、Clickhouse等，部署可视化组件并搭建报表例如Grafana、Kibana等，部署告警模块等配置告警规则例如ElastAlert等，而且由于Kubernetes集群的访问量相对较大，因此还需要搭建一个缓冲队列例如Redis、Kafka等。
为了简化用户对于Ingress日志分析与监控的门槛，阿里云容器服务和日志服务将Ingress打通，只需要应用一个yaml资源即可完成日志采集、分析、可视化等一整套Ingress日志方案的部署。
- Kubernetes 容器日志采集分析与监控
日志作为任一系统不可或缺的部分，Kubernetes的官方文档也介绍了多种日志采集形式，总结起来主要有下述三种：原生方式、DaemonSet方式和SideCar方式。
- 原生方式：使用kubectl logs直接查看本地保留的日志，或者通过docker engine的logging driver将日志重定向到文件、syslog、fluentd等系统中。
- DaemonSet方式：在Kubernetes集群的每个节点上部署日志agent，由agent采集所有容器的日志到服务端。
- SideCar方式：一个容器组(Pod)中运行一个SideCar的日志agent容器，用于采集该容器组(Pod)主容器产生的日志。SideCar模式的日志采集依赖Logtail和业务容器共享日志目录，业务容器将日志写入到共享目录中，Logtail通过监控共享目录中日志文件变化并采集日志。
采集方式对比见下表。
从上述表格可以看出，原生方式相对功能太弱，一般不建议在生产系统中使用；DameonSet方式相对资源占用要小很多，但扩展性、租户隔离性受限，比较适用于功能单一或者业务不是很多的集群；SideCar方式相对资源占用较多，但灵活性以及多租户隔离性较强，建议大型的Kubernetes集群或作为PAAS平台为多个业务方服务的集群使用该方式。通常我们可以这样进行采集部署建议：
- 核心应用：使用SideCar方式采集。
- 普通应用/系统日志：使用DaemonSet方式采集。
- 标准输出: 使用DaemonSet方式采集。
### 总结
本文介绍了基于Kubernetes进行应用微服务改造过程中的日志采集与运维管理方案，限于篇幅，本文无法对具体实施建议以及更多特色功能进行一一介绍，请大家详细阅读阿里云官网最佳实践频道的 微服务架构日志采集运维管理最佳实践
