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

简介：阿里云日志服务(SLS)结合Kubernetes日志特色以及应用场景，提供全方位的容器微服务应用环境下的日志采集、处理以及分析的实践。

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

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

本文内容由阿里云实名注册用户自发贡献，版权归原做者全部，阿里云开发者社区不拥有其著做权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将马上删除涉嫌侵权内容。