前言
随着容器技术这几年的迅速发展，Kubernetes已经逐渐成为云生态圈CNCF（Cloud Native Computing Foundation）当之无愧的老大。而Prometheus稳坐CNCF基金会的“第二把交椅”，已然成为Kubernetes群集监控系统的必要组成部分。
现在有越来越多的企业，有意向或正在由传统技术基础架构向云环境迁移。在开源监控系统方面，企业有Zabbix、Prometheus等系统可以选择。不可否认，Zabbix的产品成熟度很高，同时也与时俱进，且仍然占据整个市场的很大比例，但它随着云生态的发展暴露出一些问题。
与之相对的，Prometheus不仅更加适配云生态，而且具有了很多无可比拟的特性，如具备多维的数据模型，支持灵活的查询及聚合语句，不依赖分布式存储运行，各节点自治等。在使用场景上，它既适用于以服务器为中心的监控，也适用于高动态的面向服务架构的监控。在部署方式上， Prometheus不仅支持云环境部署，同时也支持非云环境部署。现在它已经成为企业部署开源监控系统中的重要选择。
技术中台采用Prometheus作为其监控系统，对其下管控的各节点机及服务进行监控。那么，Prometheus到底有哪些优势呢？又是如何与技术中台结合的呢？
本文将带着这些问题，带您深入剖析Prometheus监控系统，并带您领略其在技术中台发出的光彩。
- 应用监控的三板斧？
我们先考虑一个问题：为什么企业需要一套应用监控系统？
可以想象，如果一个互联网企业，不知道网站运行时的服务器的CPU、内存、存储空间等实时指标，也不知道涉及业务访问的应用相应时间（RT）、吞吐量（TPS）、并发用户数或每秒查询率（QPS）指标，还不知道中间件、应用服务调用状态，甚至不知道用户访问时应用的健康状态是否正常，那无异于在刀尖上跳舞。
所以我们可以说，一套好的监控系统可以帮助企业在出现系统故障时及时通知和快速定位问题，是保障互联网企业应用健康稳定运行的系统中不可或缺的重要组成。
在一套完整的监控系统中，需要考虑监控手段、监控指标、获取监控数据的方法等与监控相关的具体实现方式。每一项技术实现方式均有其独特的功能特点。
监控手段的选择：黑盒监控vs白盒监控
从监控手段上说，监控分为黑盒监控和白盒监控两种模式。
所谓黑盒监控，即注重业务表现，从外部探测应用系统发现哪些功能故障，通过模拟访问请求的方式快速发现故障。
所谓白盒监控，即注重问题产生的原因，从内部系统检测运行指标，比如用“埋点”等方式将应用访问时的错误率等信息暴露出来，以便在出现故障和即将出现故障时，可以快速定位故障原因。
监控指标的选择：USE原则vs RED原则
监控系统中可监控的指标众多，指导监控系统选择指标的原则主要有两个，分别是USE原则和RED原则。
USE原则侧重以下监控指标：
利用率（Utilization）：资源被有效利用起来提供服务的平均时间占比；
饱和度（Saturation）：资源拥挤的程度，比如工作队列的长度；
错误率（Errors）：错误的数量，单位时间内访问错误数的比率。
而RED原则，侧重以下监控指标：
每秒请求数量（Rate）：服务每秒请求数量；
每秒错误数量（Errors）：应用服务每秒错误数量；
服务响应时间（Duration）：服务完成相应请求的时间数。
获取监控的选择：pull vs push
获取监控数据的方法很重要，这直接决定了监控系统架构的特点。在实际中，监控系统需要在功能实现、数据获取速度、稳定性、安全性等层面做架构设计，并在各关键功能点上做出最大平衡。
一般来说，监控数据可以分为Pull方法和Push方法。
Pull方法：服务端主动拉取监控指标数据。优势能够完成水平监控，对于被监控端无感知，架构复杂性相对小，降低耦合。缺点是直接暴露监控数据存在一定的安全风险。
Push方法：被监控端主动上传监控指标数据。优势不需要服务端发起，可以实时接受监控数据，缺点是如果上传监控数据并发过大，会造成服务端阻塞。
- Prometheus技术架构特点
Prometheus的技术架构
在架构上，Prometheus监控系统由以下组件组成。
Prometheus Server： 服务端，用于收集监控数据，包含时间序列数据库TSDB；
Push Gateway： 客户端使用push的方式上报监控数据到Push Gateway，Prometheus会定期从Push Gateway拉取数据；
Exporters： 用于暴露监控信息metrics 给 Prometheus Server；
Alertmanager： 从 Prometheus server 端接收到 alerts 后，会进行去除重复数据和分组，并路由到对收的接受方式，发出报警。常见的接收方式有：电子邮件、企业微信、webhook 等；
Grafana：设置数据源为prmetheus将监控数据做前端展示。
Prometheus的功能特点
在功能上，与其他监控系统相比，Prometheus有如下重要的不同之处：
1）Prometheus的数据库使用的是时序型数据库TSDB，而一些其他监控系统使用的是关系型数据库MySQL.如果监控集群规模很大，传统关系型数据库可能存在性能瓶颈，同时扩展难度也随之增加；
2）在监控指标聚合上，Prometheus使用的是时序类数据库的查询语言PromQL，可以非常灵活的完成监控数据聚合等操作；
3）Prometheus整个生态非常热火，官网上提供多种类型的exporter，用于负责监控指标采集工作，同时也可以根据不同的业务场景自行编写exporter，监控指标采集的灵活度非常高；
4）Prometheus与Kubernetes结合度很高。通过标准的kubernetes API可以将Pod中的metric监控数据暴露出来。这样，Prometheus就可以通过访问对应Kubernetes API接口，收集群集中Pod、Node、Service等监控信息。
将Prometheus与kubernetes结合
在Kubernetes集群中，Prometheus获取Metrics数据的方式大概有两类：
1） 检测获取node节点的监控信息
一般会在node节点上安装node_exporter，该Pod的种类会是以DaemonSet的方式运行，保证每台Node节点有对应的node_exporter运行，Prometheus会收集每一台Node上的CPU、内存、磁盘、网络带宽等监控信息。
2） 检测kubernetes集群中运行的Pod、Service等种类的监控信息
这类metrics信息主要来自于cAdvisor所提供，可以监控到Pod的CPU负载、所使用内存和网络开销等信息。
其中监控数据可以结合Metrics Server通过kubernetes API将监控数据暴露出来。这样，用户就可以通过标准的API接口访问Pod、Service等监控信息。
- Prometheus在开发者中心的落地与实践
在开发者中心部署Prometheus
在开发者中心将主机接入资源池的时候，部署脚本会自动安装Prometheus、node_exporter、cAdvisor等组件。因此，直接按提示执行开发者中心提供的脚本，就可以监控每一台Node节点的主机资源情况和每个应用Pod上的资源使用情况。
查看主机监控
在开发者中心将节点机接入资源池后，就可以依次点击菜单“容器服务”、“资源池”、“查看监控”、“资源池监控”，在页面中就可以查看接入主机的CPU使用率、TCP连接数、磁盘IO使用情况、根分区容量、网络负载等信息。
查看应用监控
在开发者中心部署好业务应用后，依次点击“容器服务”、“资源池”、“查看监控”、“应用监控”，在页面中即可查看接入应用程序的CPU负载、内存负载、网络负载等信息。
实现应用自动水平扩展功能
点击 “应用管理”菜单，进入部署应用的详情页面后，可以在“自动扩缩”中配置应用的最大、最小实例数。开发者中心会根据设置的CPU、内存百分比，获取MetricsServer中的监控信息，实现Kubernetes的HPA自动水平扩展功能，在业务访问量突增时，自动完成应用集群的扩展操作。
- 总结与展望
Prometheus在云环境中地位越来越重要，其系统监控功能强大而完善。与Kubernetes的搭配也对企业实现对业务的监控等功能有重要意义。现在的用友开发者中心已经在采用Kubernetes容器调度系统的基础上，将Promethesus与自身完美融合，实现了对节点机、业务应用Pod等各项Metric指标的采集和监控，并用于报警和自动扩容缩容等场景。
但是我们知道，“行百里者半九十”，我们要走的路仍然很远。比如对自定义Metric指标的检测，并根据企业中应用场景来完成自动容缩；比如收集当网站的RPS（Requests Per Second）指标，当RPS到达极限值时对业务Pod的自动扩容等。
在用友云提出的“大技术中台”战略中，业务数据的监控与收集是其中重要环节之一。让我们为技术中台目标继续努力前进。
套用一句广告语做总结：“我听说，Prometheus与技术中台更配哦！”
原文地址：https://blog.51cto.com/14084875/2414307