guan000 2020-03-04
Kubernetes是目前最为流行、成为事实标准的容器集群管理平台,为容器化应用提供了集群化部署运行、自动资源调度,和动态水平伸缩等一系列完整功能。虽然Kubernetes平台本身已经实现了应用状态的实时监控,但是监控的指标和方式还是比较基础,难以满足各种复杂和个性化的监控管理需求。因此,我们需要在Kubernetes的基础上,增加独立的、不影响现有应用集群的架构和部署的,而且功能全面、易于部署、便于监视分析、能够及时告警的监控体系。
在当前应用与Kubernetes的监控体系当中,Prometheus得到了更为广泛的关注和应用。本文就结合JFrog在Kubernetes落地实践当中的积累,介绍如何在Kubernetes环境中快速部署Prometheus系统,实现对Kubernetes环境状态的实时监视和告警。
Prometheus是一套开源的系统监控报警框架。和Kubernetes类似,它也发源于Google的Borg体系,其原型为Borgmon,是一个几乎与Borg同时诞生的内部监控系统,由工作在SoundCloud的Google前员工在 2012年创建。之后作为社区开源项目进行开发,并于2015年正式发布。2016年,Prometheus正式加入CNCF(Cloud Native Computing Foundation),是仅次于Kubernetes的第二个项目,目前已经全面接管了 Kubernetes项目的整套监控体系。
Prometheus的监控是基于时序数据的,即通过采样数据(metrics),不断获取监控目标的状态信息,即时地记录与展示,并根据设定的门限和方式及时发布告警。
作为应用与Kubernetes的监控体系,Prometheus具备诸多的优势,如:
? Kubernetes默认支持,非常适合容器和微服务
? 无依赖,安装方便,上手容易
? 社区活跃,它不仅仅是个工具,而是生态
? 已有很多插件或者exporter,可以适应多种应用场景的数据收集需要
? Grafana默认支持,提供良好的可视化
? 高效,单一Prometheus可以处理百万级的监控指标,每秒处理数十万的数据点
而当前Prometheus最大的缺点就是暂时还不支持集群化。当然,在社区的支持和推动下,可以预期在不久的将来,Prometheus也将会推出完善的集群化方案。
Prometheus的基本架构如下图所示:
其中:
? Prometheus Server:是Prometheus架构中的核心部分,负责实现对监控数据的获取、存储及查询。Prometheus Server可以通过静态配置管理监控目标,也可以配合使用Service Discovery的方式动态管理监控目标,并从这些监控目标中获取数据。其次Prometheus Server本身也是一个时序数据库,将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。Prometheus Server对外提供了自定义的PromQL,实现对数据的查询以及分析。
? Exporter:是提供监控数据的来源。Exporter分为两类:一类Exporter直接内置了对Prometheus监控的支持,如Kubernetes、etcd等;另一类是因为原有监控目标并不直接支持Prometheus,需要通过Prometheus提供的Client Library编写该监控目标的监控采集程序,如Mysql、JMX等。对于Exporter,Prometheus Server采用pull的方式来采集数据。
? PushGateway:同样是监控数据的来源。对于由于特定原因,如网络环境不允许等,Prometheus Server不能直接与Exporter进行通信时,可以使用PushGateway来进行中转。内部网络的监控数据主动Push到Gateway中,而和对Exporter一样,Prometheus Server也利用pull的方式从PushGateway采集数据。
? Alertmanager:是Prometheus体系中的告警组件。在Prometheus Server中可以设定门限与警报规则。当采集到的数据满足相关规则后,就会产生一条告警。Alertmanager从 Prometheus Server接收到告警后,会根据事先设定的路径,向外发出告警。常见的告警发送路径有:电子邮件、PagerDuty、Webhook、Slack等。
? 数据展示与输出:Prometheus Server有内置的UI用于展示采集到的监控数据。在该UI上,可以通过各种内置的数学公式对原始数据进行加工,并通过图形化的方式展现出来。当然,Prometheus Server原生UI的展示方式还是比较基础和单薄,所以目前更多的是通过对接Grafana来进行数据的展示,可以得到更好的展示效果。此外,Prometheus Server也提供API的方式来实现对监控数据的访问。
本文就将参照上述架构,介绍如何在Kubernetes环境中,快速地部署和配置Prometheus的监控体系。
本节将基于JFrog在Kubernetes落地实践当中的积累,一步一步地介绍如何在Kubernetes环境中,从零开始搭建Prometheus系统,并实现监控数据的收集、展示与告警。本节所涉及的所有Kuberntes对象的yaml文件、kubectl命令,都可以在https://github.com/xingao0803/Prometheus上获得。该项目的README也详细记录的所有的操作步骤,供大家参考。(注:本文部署是基于Kubernetes 1.16.3版本的。)
1、创建命名空间
为管理需要,所有Prometheus组件都应运行在一个独立的命名空间当中。因此安装的第一步,就是要创建一个新的Namespace,此处为“monitoring”。
2、部署node-exporter
作为监控数据的来源,node-exporter用于提供*NIX内核的硬件以及系统指标,包括机器的loadavg、filesystem、meminfo等,类似于传统的主机监控数据。node-exporter由Prometheus官方提供维护,不会捆绑安装,但基本上是必备的exporter。
node-exporter是以DaemonSet对象的方式进行部署的,可以确保每个Kubernetes Node的数据都会被采集到Prometheus。
注意,node-exporter开放了hostPort:9100,所以可以通过直接访问<Node_IP>:9100来访问node-exporter采集到的数据。如下图所示:
除DaemonSet外,还需要部署对应的Service,供Prometheus Server对接使用。需要注意的是,该Service只开放了Cluster内部端口,不能直接从外部访问。
3、部署kube-state-metrics
除了node-exporter,还可以部署另一个数据来源,kube-state-metrics。kube-state-metrics关注于获取kubernetes各种资源的最新状态,如deployment或者daemonset等。kube-state-metrics轮询Kubernetes API,并将Kubernetes的结构化信息转换为metrics,将kubernetes的运行状况在内存中做个快照。
因为kube-state-metrics要访问API,所以要先创建ServiceAccount来提供权限。之后再部署相应的Deployment:
为了和Prometheus Server对接,也要部署对应的Service。和node-exporter一样,这个Service也只开放了Cluster内部端口,不能直接从外部访问。
4、部署Prometheus Server
部署Prometheus Server之前,同样首先要创建Service Account来提供权限。同时,需要通过创建两个ConfigMap来预先提供Prometheus Server的配置数据,和产生警报的门限和规则。Prometheus的各种配置可以到https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config查看相关详细定义。
之后,还需要创建一个Secret来设置Prometheus的缺省用户和密码。
一切就绪之后,就可以部署Prometheus Server的Deployment了:
注意,在参数当中预先设置了AlertManager的对接方式。
最后,再创建Prometheus的Service:
该Service开放了NodePort,但没有指定端口号,所以由Kubernetes自动分配。可以通过kubectl get service命令得到该端口,并通过<Node_IP>:<Node_Port>来访问Prometheus原生的UI界面:
在该界面上,可以直接看到所有采集上来的监控数据,并通过各种内置的数学公式进行加工,并以图形化的方式展示出来。
此外,根据设置的告警门限和规则,也会在UI上显示各种告警信息:
5、部署Grafana
Prometheus的原生UI,看起来还是有些基础和单薄,所以在日常应用当中,通常都会再对接Grafana来进行数据展示。
部署Grafana也首先要通过创建ConfigMap来设置Dashboard的模版设置。Grafana的模版设置参数可以参考https://grafana.com/grafana/dashboards。
模版参数设置好之后,就可以部署Grafana的Deployment和Service了:
Grafana的Service也是开放了NodePort,但没有指定端口号。可以通过Node_IP和自动分配的Port来访问Grafana的界面:
还需要再运行一些脚本来和Prometheus连接,即添加数据源,并根据ConfigMap的设置来创建Dashboard。这些脚本是通过创建一个Job对象来运行的。Job运行结束之后,就可以在Grafana上看到监控数据了:
这个界面看起来就更为丰富和美观了。
当然,为了更好地对外展示Grafana,还可以再创建一个Ingress来通过域名的方式对外开放:
6、部署Alertmanager
之前Prometheus根据预设的门限和规则,已经从采集到的监控数据中产生了告警信息,下一步就需要通过Alertmanager把告警信息发送出去。
首先,还是通过创建ConfigMap来设置Alermanager对接的信息发送路径,和发送的信息格式模版。Alertmanager的配置可以参考https://prometheus.io/docs/alerting/configuration/。 Alertmanager可以对接的发送路径很多,如邮件、PagerDuty、Slack、Webhook等。本文的例子中只提供了邮件方式的设置。
之后,再分别部署Alertmanager的Deployment和Service:
Alertmanager的Service也是没有指定端口号的Node_Port,可以通过自动分配的端口访问到Alertmanager的界面:
在Alertmanager的界面上,可以看到即时接收到的告警信息。
根据发送路径的设置,可以在邮箱中收到相应的告警邮件:
至此,我们在Kubernetes的环境中快速部署了Prometheus的系统,并采集了Node和Kubernetes组件的各种状态数据,可以通过Grafana进行展示;系统产生的告警信息也可以通过Alertmanager设置的方式,以邮件的方式发送出来。
Prometheus是Kubernetes体系中应用最为广泛的时序数据的监控系统。本文详细描述了如何从零开始,快速在Kubernetes环境中部署Prometheus系统,并实现监控数据的采集、展示,以及告警的全过程。本文安装的Prometheus系统架构如下图所示:
本文部署过程所涉及的所有Kuberntes对象的yaml文件、kubectl命令,都可以在https://github.com/xingao0803/Prometheus上获得。该项目的README也详细记录的所有的操作步骤,供大家参考。(注:本文部署是基于Kubernetes 1.16.3版本的。)
此外,本文中各种部署对象是基于Docker image的,因此过程中也需要本地Docker镜像中心的支持,保证部署过程的稳定、快速和可重复。本文在部署过程中采用了JFrog的JCR(JFrog Container Registry),只是一款免费的、功能强大的Docker镜像中心。具体信息请参见:https://www.jfrog.com/confluence/display/JCR/Overview。大家可以通过https://www.jfrog.com/confluence/display/JCR/Overview来下载免费使用。
更多精彩内容请微信搜索公众号: jfrogchina
更多技术分享可以关注3 月5 日在线课堂:《DevOps 实战之持续测试&安全扫描》
课程收益
1.了解持续测试的体系建设
2.了解各个阶段常见自动化测试工具
3.了解DevSecOps 第三方依赖引入安全监管机制
本期话题
1.持续测试介绍
2.使用代码扫描提高代码质量
3.API接口自动化测试管理
4.UI自动化测试工具及管理
5.DevSecOps 持续安全监管
课堂活动
本期课堂讲师会在结束前进行抽奖活动
第一名:小米蓝牙耳机
第二名:JFrog 新版T 恤