微服务架构下日志采集运维管理分析

直达最佳实践：【微服务架构日志采集运维管理最佳实践】
最佳实践频道：【最佳实践频道】
这里有丰富的企业上云最佳实践，从典型场景入门，提供一系列项目实践方案，降低企业上云门槛的同时满足您的需求！

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进行应用微服务改造过程中的日志采集与运维管理方案，限于篇幅，本文无法对具体实施建议以及更多特色功能进行一一介绍，请大家详细阅读阿里云官网最佳实践频道的微服务架构日志采集运维管理最佳实践