Kubernetes业务日志收集与监控探析.docx

《Kubernetes业务日志收集与监控探析.docx》由会员分享，可在线阅读，更多相关《Kubernetes业务日志收集与监控探析.docx（15页珍藏版）》请在优知文库上搜索。

1、随着容器技术以及容器编排技术的成熟，越来越多的中小型企业也在将服务迁移到KUbenIeteS中，更智能，更便捷的管理服务，降低运维成本，而在迁移过程中，业务日志的收集以及业务服务的监控，集群状态的监控就变得很重要了。本问主要讲述在将服务迁移到Kubernetes中是如何收集业务日志以及监控集群、业务状态的。集群业务日志收集我司规模不大、运维人员较少，所以在业务迁移到Kubernetes中整体的日志收集流程并没有大改，只做出了部分调整。由于前期日志目录以及日志名称规范很好，所以调整起来也很方便。在业务迁移KUbenIeteS之前日志收集流程如下图图1旧E1.K架构旧的日志收集架构其实存在一些问题

2、：当1.ogstash挂了之后就存在丢失日志问题，之前跨大版本升级1.ogstash失败就丢失了一段时间日志。当1.ogStaSh后的消费程序挂了其一，例如ES挂了，会导致日志写文件和写InfluxDB都有问题并且由于Filebeat会不断推送日志给1.ogStaSh从而导致日志丢失。以上两个问题都说明组件之间耦合严重，所以在迁移Kubernetes时我们对架构做了一些调整，调整后的日志收集架构如下图2。图2新E1.K架构在Filebeat和1.ogstash之间增加Kafka用于临时缓存日志，并用于解耦日志消费者。启动多个1.ogStaSh实例分别处理写文件、连接ES、写InfIUXDB从而

3、解耦日志消费程序耦合。因为业务迁移要求快、时间短，没有时间将日志都打在容器StdOUt输出，所以采用将容器日志映射到宿主机上，再通过FiIebeat收集，实现KUbenleteS中业务日志收集。这里给出1、3点变化的配置变更：第1点带来的配置变化对比如下图3。变更股争-1.ogstashoutputoutput.IogstasK:9The1.09stashhostshosts：(,IP三5e44,j变更后：Kafkaoutputoutput.kafka:hosts:(MIP:9e92M)topic:*M!fields.topic*key:5044SJ三input(Skafka(bootstrp

4、.srvers=HIP:9092Mtopics三(xotgroup-ld三IogstashofilterJSonsource三FcsgeJJg二墨,皂/1#幽量延WflwQD些模处电星母tt取不到日志内容,没书之加注一行无法将慢敷却8式图3接入Kaflca后配置变更重点分享下第3点变化：最开始公司内部新增一个服务都需要将该服务的所有日志类型的收集规则直接写入filebeat.yml文件，然后使用Ansible下发到所有业务机上重启并Filebeat。这样导致filebeat.yml文件越来越长、难以维护并且一个配置不正确会导致Filebeat起不来，造成日志无法及时收集。后来我们将每个业务日志

5、收集规则拆分成一个个小yaml文件存放在etcf11ebeatinputs.d中，业务Filebeat收集规则则由一个自动生成配置脚本从Kubernetes集群获取业务namespace和服务日志路径来自动生成业务Filebeat配置再通过Ansible将配置下发到指定目录。第3点配置变化对比如下图4中3部分。图4FiIebeat收集变化通过以上几点修改我们快速的完成了业务日志在Kubernetes集群中的收集工作，并且提高了日志系统的稳定性，为以后常规化升级日志系统带来了便利。当然我们的系统也有不足之处,现在我们的Filebeat还是使用Systemd启动，每新增一个Node,都需要安装一次

6、FiIebea3并且需要让自动脚本检索到这个节点给节点下发配置，后期我们打算使用KubernetesDaemonSet模式来部署Filebeat并且当有新服务加入自动更新Filebeat配置、使用Kubernetes的方法来完成FiIebeat安装、配置更新。集群状态监控以及业务状态监控我们在集群状态监控以及业务状态监控方面，采用的是PrometheusOperator的一揽子开源工具解决方案。先介绍下各个组件作用：PrometheusOperator：PrometheUS是主动去拉取监控数据的，在KUbemeteS里Pod因为调度原因导致IP不断变化，人工不可能去维持，自动发现又是基于DNS

7、的，但是新增还是有点麻烦。PrometheusOperator的本职就是一组用户自定义的CRD资源以及Controller的实现，PrometheusOperator这个controller有RBAC权限、负责监听这些自定义资源的变化，并且根据这些资源的定义自动化的完成如PrometheusServer自身以及配置的自动化管理工作。Kube-state-metrics：能够采集绝大多数KUbenleteS内置资源相关数据，例如Pod、Deploy.SerViCe等。同时它也提供自己的数据，主要是资源采集个数和采集发生的异常次数统计。例如我调度了多少个RePliCas?现在可用的有几个？多少个P

8、od是running/stopped/terminated状态？Pod重启了多少次？等等这些状态值都可以通过添加Prometheusrule来产生报警，及时通知运维和开发人员。Prometheus：用于收集集群组件Metric和集群中各类资源状态Metric以及自定义实现的监控Metric数据。AlertManager:处理由PrOmetheUS服务器等客户端发来的警报。它负责删除重复数据、分组，并将警报通过路由发送到正确的接收器，比如电子邮件、Webhook等。在Kubernetes中部署业务前，监控系统和日志收集系统都需要提前安装好，因为业务分地区等原因我司内部存在多套集群环境，每套集群部

9、署地区都不一致，所以在部署监控服务时，我们采取的方案是在每个集群中都创建一套完整的监控系统，因为我们的业务不属于PV很大的业务且集群规模较小，所以每个集群一套监控系统是比较合理的。监控系统中的各组件服务存放在个单独的namespace中，直接采用YAM1.方式安装，没有使用helm安装。集群监控架构图如下图5。图5Kubernetes集群监控架构从图中可以看出我们主要收集了三个方面监控数据:集群组件:我们收集了API、ControllerSchedulerKubeletsCoreDNS五个组件的Metrics,由于我司集群采用二进制方式安装的，所以部分组件Metric(ControllerSc

10、heduler)数据的获取需要自己配置EndPOintS并配合SerViCe和ServiceMonitor完成Metric的收集。下面给出Controller的EndpointsServiceServiceMonitor配置如下图6。apiVersion:vlkind:Endpointsmetadata:labels:k8s-app:kube-controller-nanagername:kube-controller-managernanespace:kube-systemsubsets:-addresses:- ip:IPl- ip:IP2- ip:IP3ports:- name:http

11、-metricsport:10252protocol:TCP，SerViCe配置.apiVersion:vlkind:Servicemetadata:nanespace:kube-systePrometheusAIertmanager、kube-state-metrics的部署，网上教程也很多，大家自己搭建碰到问题自己解决也是很有乐趣的，也可以查看我的GitHUb仓库，参考安装。这里重点说下Prometheus存储，由于Prometheus部署在Kubernetes集群中而Pod是随时消亡的，所以直接本地存储是不合适的，当然也可以使用PV来存储，不过现在有很多很好也很完善的Prometheus

12、远程存储方案可供选择，建议使用远程存储方案。我司采用InfIUXDB作为Prometheus远程存储方案，单机InfklXDB性能已经很强基本满足日常需求，但由于他的集群方案是不开源的，存在单点故障问题。所以大家可以选择其他远程存储解决方案避免这个问题。Prometheus连接InfIUXDB配置如下图7。#在PrOfnetheUS的StatefUlSet.yaml中配置：apiVersion:baseimage:quay.io/prometheus/prometheus#baseimage:-UrI:http:IP:8086/api/vlpro11l/read?db=库名&u=用户名&p=密码readRecent:trueremoteWrite:#furl:http:1P:8086/api/vl/pro11write?db=库名&u=用户名&p=密码ServiceAccountNaine:prometheus-k8sServiceMonitorflamespaceSelectors冏ServiceMonitorSelector:ruleselector:match1.abels:prometheus:k8srole:alert-rulesresources:requests:memo