共计 3021 个字符,预计需要花费 8 分钟才能阅读完成。
简介:阿里云日志服务 (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 进行利用微服务革新过程中的日志采集与运维治理计划,限于篇幅,本文无奈对具体实施倡议以及更多特色性能进行一一介绍,请大家具体浏览阿里云官网最佳实际频道的微服务架构日志采集运维治理最佳实际
版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。