一、Prometheus的基础知识

官网网站：https://prometheus.io/

下载地址：https://prometheus.io/download/

Github地址：https://github.com/prometheus/prometheus

1、Prometheus的故事背景

Prometheus 受启发于 Google 的Brogmon 监控系统（相似的 Kubernetes 是从 Google的 Brog 系统演变而来），从 2012 年开始由前 Google 工程师在 Soundcloud 以开源软件的形式进行研发，并且于 2015 年早期对外发布早期版本。

2016 年 5 月继 Kubernetes 之后成为第二个正式加入 CNCF 基金会的项目，同年 6 月正式发布 1.0 版本。2017 年底发布了基于全新存储层的 2.0 版本，能更好地与容器平台、云平台配合。

Prometheus 作为新一代的云原生监控系统，目前已经有超过 730+位贡献者参与到Prometheus 的研发工作上，并且超过 120+项的第三方集成。

2、Prometheus的特点（来源官方github）

• 强大的多维数据模型（命名最佳实践：https://prometheus.io/docs/practices/naming/）

http_request_status{
    code='200',
    content_path='/api/path',
    environment='produment'
} =>
[value1@timestamp1,value2@timestamp2...]

http_request_status{ # 指标名称
    code='200', # 维度的标签(键值对集合)
    content_path='/api/path2',
    environment='produment'
} =>
[value1@timestamp1,value2@timestamp2...] # 存储的样本值

• Prometheus采集的所有数据均以指标（metric）的形式，保存在内置的时序数据库TSDB中；

• 每一个时序数据由metric度量指标名称和它的标签labels(键值对集合)唯一确定;

• 样本形成了实际的时间序列数据列表。每个采样值包括：一个64位的浮点值 + 一个精确到毫秒级的时间戳；

• 强大灵活的查询语言PromQL

• 可以对采集的metrics指标进行加法，乘法，连接等操作；

• 可以直接在本地快速部署，不依赖于其它分布式存储服务

• 支持HTTP Pull的方式主动采集时序数据

• 支持借助中间网关pushgateway，通过push的方式把时序数据推送到Prometheus Server端

• 可以通过服务发现discovery或静态配置的方式发现目标服务对象（targets）

• 丰富的可视化界面支持，如自带的Prometheus UI，Grafana等，还可以基于提供的API实现自己的UI

• 高效的存储：大量的监控必然产生大量的数据，而Prometheus 可以高效地处理这些数据，

• 对于单一Prometheus Server 实例而言它可以处理：

  ➢ 数以百万的监控指标；

  ➢ 每秒处理数十万的数据点；

• 每个采样数据占3.5 bytes左右，300万的时间序列，30s间隔，保留60天，消耗磁盘大概200G；

• 可以在每个数据中心、每个团队运行独立的Prometheus Sevrer。Prometheus 对于联邦集群的支持，可以让多个 Prometheus 实例产生一个逻辑集群，当单实例 Prometheus Server 处理的任务量过大时，通过使用功能分区(sharding)+联邦集群(federation)可以对其进行扩展；

• 易于集成：使用Prometheus 可以快速搭建监控服务，并且可以非常方便地在应用程序中进行集成：

• 目前支持：Java，JMX，Python，Go，Ruby，.Net，Node.js 等等语言的客户端 SDK，基于这些 SDK 可以快速让应用程序纳入到 Prometheus 的监控当中，或者开发自己的监控数据收集程序；

• 同时这些客户端收集的监控数据，不仅仅支持 Prometheus，还能支持 Graphite 这些其他的监控工具；

• 同时Prometheus 还支持与其他的监控系统进行集成：Graphite，Statsd，Collected， Scollector， muini， Nagios 等。 Prometheus 社区还提供了大量第三方实现的监控数据采集支持：JMX，CloudWatch，EC2，MySQL，PostgresSQL，Haskell，Bash，SNMP， Consul，Haproxy，Mesos，Bind，CouchDB，Django，Memcached，RabbitMQ，Redis，RethinkDB，Rsyslog 等等。

3、Prometheus的架构

从上图可发现，Prometheus整个生态圈组成主要包括prometheus server，Exporter，pushgateway，alertmanager，grafana，Web ui界面，Prometheus server由三个部分组成，Retrieval，Storage，PromQL：

• Retrieval负责在活跃的target主机上抓取监控指标数据；

• Storage存储主要是把采集到的数据存储到磁盘中；

• PromQL是Prometheus提供的查询语言模块，为应用层提供数据查询能力。

4、Prometheus的生态组件

Prometheus虽然负责时序性数据的采集、存储、聚合查询，但是对数据的分析、直观展示、以及告警等功能并非由Prometheus直接负责；

Prometheus生态圈中包含了多个组件，其中部分组件可选：

• Prometheus Server：主服务，收集和存储时序数据，负责实现对监控数据的获取；

• Client Library：客户端库，目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径；

• Push Gateway：接收那些通常由短期作业生成的指标数据的网关，并支持由Prometheus Server进行指标拉取操作；

• Exporters：用于暴露现有应用程序或服务（不支持Instrumentation）的指标给Prometheus Server；

• Alertmanager：从Prometheus Server接收到“告警通知”后，通过去重、分组、路由等预处理功能后以高效地向用户完成告警信息发送；

• Data Visualization：Prometheus Web UI（Prometheus自带），Grafana等；

• Service Discovery：动态发现待监控的Target，从而完成监控配置的重要组件，在容器化环境中尤为有用；该组件目前由Prometheus Server内建支持；

5、Prometheus的工作流程（参考上面的生态组件）

• （1）Prometheus server可定期从活跃的（up）目标主机上（target）拉取监控指标数据，目标主机的监控数据可通过配置静态job或者服务发现的方式被prometheus server采集到，这种方式默认采用pull方式拉取指标；也可通过pushgateway把采集的数据上报到prometheus server中；还可通过一些组件自带的exporter采集相应组件的数据；

• （2）Prometheus server把采集到的监控指标数据保存到本地磁盘或者时序数据库中；

• （3）Prometheus采集的监控指标数据按时间序列存储，通过配置报警规则，把触发的报警发送到alertmanager；

• （4）Alertmanager通过配置报警接收方，发送报警到邮件，微信或者钉钉等；

• （5）Prometheus 自带的web ui界面提供PromQL查询语言，可查询监控数据；

• （6）Grafana可接入prometheus数据源，把监控数据以图形化形式展示出；

6、Prometheus与Zabbix的对比分析

二、Prometheus的几种部署模式

1、基本HA(高可用)模式

基本的HA模式只能确保Promthues服务的可用性问题，但是不解决Prometheus Server之间的数据一致性问题以及持久化问题(数据丢失后无法恢复)，也无法进行动态的扩展。因此这种部署方式适合监控规模不大，Promthues Server也不会频繁发生迁移的情况，并且只需要保存短周期监控数据的场景。

2、基本HA(高可用) + 远程存储

在解决了Promthues服务可用性的基础上，同时确保了数据的持久化，当Promthues Server发生宕机或者数据丢失的情况下，可以快速的恢复。 同时Promthues Server可能很好的进行迁移。因此，该方案适用于用户监控规模不大，但是希望能够将监控数据持久化，同时能够确保Promthues Server的可迁移性的场景。

3、基本HA(高可用) + 远程存储 + 联邦集群方案

Promtheus的性能瓶颈主要在于大量的采集任务，因此用户需要利用Prometheus联邦集群的特性，将不同类型的采集任务划分到不同的Promthues子服务中，从而实现功能分区。例如一个Promthues Server负责采集基础设施相关的监控指标，另外一个Prometheus Server负责采集应用监控指标。再有上层Prometheus Server实现对数据的汇聚。

三、Prometheus对Kubernetes的监控

对于Kubernetes而言，我们可以把当中所有的资源分为几类：

• 基础设施层（Node）：集群节点，为整个集群和应用提供运行时资源；

• 容器基础设施（Container）：为应用提供运行时环境；

• 用户应用（Pod）：Pod中会包含一组容器，它们一起工作，并且对外提供一个（或者一组）功能；

• 内部服务负载均衡（Service）：在集群内，通过Service在集群暴露应用功能，集群内应用和应用之间访问时提供内部的负载均衡；

• 外部访问入口（Ingress）：通过Ingress提供集群外的访问入口，从而可以使外部客户端能够访问到部署在Kubernetes集群内的服务；

因此，如果要构建一个完整的监控体系，我们应该考虑，以下5个方面：

• 集群节点状态监控：从集群中各节点的kubelet服务获取节点的基本运行状态；

• 集群节点资源用量监控：通过Daemonset的形式在集群中各个节点部署Node Exporter采集节点的资源使用情况；

• 节点中运行的容器监控：通过各个节点中kubelet内置的cAdvisor中获取个节点中所有容器的运行状态和资源使用情况；

• 如果在集群中部署的应用程序本身内置了对Prometheus的监控支持，那么我们还应该找到相应的Pod实例，并从该Pod实例中获取其内部运行状态的监控指标；

• 对k8s本身的组件做监控：apiserver、scheduler、controller-manager、kubelet、kube-proxy。