监控利器Prometheus初探

导读：Kubernetes做为当下最煊赫一时的容器管理平台，在给应用部署运维带来便捷的同时，也给应用及性能监控带来了新的挑战。本文给你们分享一款十分火热的开源监控工具Prometheus，让咱们一块儿来看它是如何兼顾传统的应用监控、主机性能监控和Kubernetes监控的。

目录：

1、Prometheus简介

2、Prometheus架构图

3、Prometheus架构详解

4、Prometheus监控Kubernetes

1、Prometheus简介

什么是Prometheus？

Prometheus是一个开源的系统监控及告警工具，最初建设在SoundCloud。从2012 Prometheus推出以来，许多公司都采用它搭建监控及告警系统。同时，项目拥有很是活跃的开发者和用户社区。

它如今是一个独立于任何公司的开源项目，为了强调这一点并明确项目的管理结构，在2016年Prometheus加入CNCF基金会成为继Kubernetes以后的第二个托管项目。

 

Prometheus有什么特色？

• 多维的数据模型（基于时间序列的k/v键值对）。

• 灵活的查询及聚合语句（PromQL）。

• 不依赖分布式存储，节点自治。

• 基于HTTP的pull模式采集时间序列数据。

• 可使用pushgateway（prometheus的可选中间件）实现push模式。

• 可使用动态服务发现或静态配置采集的目标机器。

• 支持多种图形及仪表盘。

 

Prometheus适用场景

在选择Prometheus做为监控工具前，要明确它的适用范围，以及不适用的场景。

Prometheus在记录纯数值时间序列方面表现很是好。它既适用于以服务器为中心的监控，也适用于高动态的面向服务架构的监控。

在微服务的监控上，Prometheus对多维度数据采集及查询的支持也是特殊的优点。

Prometheus更强调可靠性，即便在故障的状况下也能查看系统的统计信息。权衡利弊，以可能丢失少许数据为代价确保整个系统的可用性。所以，它不适用于对数据准确率要求100%的系统，好比实时计费系统（涉及到钱）。

2、Prometheus构架图

上图是Prometheus的架构图，从图中能够看出Prometheus的架构设计理念，中心化的数据采集，分析。

1. Prometheus Server：Prometheus的核心，根据配置完成数据采集，  服务发现以及数据存储。

2. Pushgateway：为应对部分push场景提供的插件，监控数据先推送到pushgateway上，而后再由server端采集pull。（若server采集间隔期间，pushgateway上的数据没有变化，server将采集2次相同数据，仅时间戳不一样）

3. Prometheus targets：探针（exporter）提供采集接口，或应用自己提供的支持Prometheus数据模型的采集接口。

4. Service discovery：支持根据配置file_sd监控本地配置文件的方式实现服务发现（需配合其余工具修改本地配置文件），同时支持配置监听Kubernetes的API来动态发现服务。

5. Alertmanager：Prometheus告警插件，支持发送告警到邮件，Pagerduty，HipChat等。

3、Prometheus架构详解

接下来，让咱们一块儿了解rometheus架构中各个组件是如何协同工做来完成监控任务。

 

• Prometheus server and targets

  
  

利用Prometheus官方或第三方提供的探针，基本能够完成对全部经常使用中间件或第三方工具的监控。

以前讲到Prometheus是中心化的数据采集分析，那这里的探针（exporter）是作什么工做呢？

上图中硬件及系统监控探针node exporter经过getMemInfo()方法获取机器的内存信息，而后将机器总内存数据对应上指标node_memory_MemTotal。

Jenkins探针Jenkins Exporter经过访问Jenkins的api获取到Jenkins的job数量并对应指标Jenkins_job_count_value。

探针的做用就是经过调用应用或系统接口的方式采集监控数据并对应成指标返回给prometheus server。（探针不必定要和监控的应用部署在一台机器）

总的来讲Prometheus数据采集流程就是，在Prometheus server中配置探针暴露的端口地址以及采集的间隔时间，Prometheus按配置的时间间隔经过http的方式去访问探针，这时探针经过调用接口的方式获取监控数据并对应指标返回给Prometheus server进行存储。（若探针在Prometheus配置的采集间隔时间内没有完成采集数据，这部分数据就会丢失）

 

• Prometheus alerting

 

Prometheus serve又是如何根据采集到的监控数据配和alertmanager完成告警呢？

举一个常见的告警示例，在主机可用内存低于总内存的20%时发送告警。咱们能够根据Prometheus server采集的主机性能指标配置这样一条规则node_memory_Active/node_memory_MemTotal < 0.2，Prometheus server分析采集到的数据，当知足该条件时，发送告警信息到alertmanager，alertmanager根据本地配置处理告警信息并发送到第三方工具由相关的负责人接收。

Prometheus server在这里主要负责根据告警规则分析数据并发送告警信息到alertmanager，alertmanager则是根据配置处理告警信息并发送。

Alertmanager又有哪些处理告警信息的方式呢？

1. 分组：将监控目标相同的告警进行分组。如发生停电，收到的应该是单一信息，信息中包含全部受影响宕机的机器，而不是针对每台宕机的机器都发送一条告警信息。

2. 抑制：抑制是指当告警发出后，中止发送由此告警引起的其余告警的机制。如机器网络不可达，就再也不发送因网络问题形成的其余告警。

3. 沉默：根据定义的规则过滤告警信息，匹配的告警信息不会发送。

 

• Service discovery

 

Prometheus支持多种服务发现的方式，这里主要介绍架构图中提到的file_sd的方式。以前提到Prometheus server的数据采集配置都是经过配置文件，那服务发现该怎么作？总不能每次要添加采集目标还要修改配置文件并重启服务吧。

这里使用file_sd_configs指定定义了采集目标的文件。Prometheus server会动态检测该配置文件的变化来更新采集目标信息。如今只要能更新这个配置文件就能动态的修改采集目标的配置了。

这里采用consul+consul template的方式。在新增或减小探针（增减采集目标）时在consul更新k/v，如新增一个探针，添加以下记录Prometheus/linux/node/10.15.15.132=10.15.15.132:9100，而后配置consul template监控consul的Prometheus/linux/node/目录下k/v的变化，根据k/v的值以及提早定义的discovery.ctmpl模板动态生成Prometheus server的配置文件discovery.yml。

 

• Web UI

 

至此，已经完成了数据采集和告警配置，是时候经过页面展现一波成果了。

Grafana已经对Prometheus作了很好的支撑，在Grafana中添加Prometheus数据源，而后就可使用PromQL查询语句结合grafana强大的图形化能力来配置咱们的性能监控页面了。

 

• 联邦模式

中心化的数据采集存储，分析，并且还不支持集群模式。带来的性能问题显而易见。Prometheus给出了一种联邦的部署方式，就是Prometheus server能够从其余的Prometheus server采集数据。

可能有人会问，这样最后的数据不是仍是要所有聚集到Prometheus的global节点吗？

并非这样的，咱们能够在shard节点就完成分析处理，而后global节点直接采集分析处理过的数据进行展现。

好比在shard节点定义指标可用内存占比job:memory_available:proportion的结果为(node_memory_MemFree + node_memory_Buffers + node_memory_Cached)/node_memory_MemTotal，这样在shard节点就能够完成聚合操做，而后global节点直接采集处理过的数据就能够了，而不用采集零散的如node_memory_MemFree这类指标。

4、Prometheus监控Kubernetes

Kubernetes官方以前推荐了一种性能监控的解决方案，heapster+influxdb，heapster根据定义的间隔时间从Advisor中获取的关于pod及container的性能数据并存储到时间序列数据库influxdb。

也可使用grafana配置influxdb的数据源并配置dashboard来作展示。并且Kubernetes中pod的自动伸缩的功能（Horizontal Pod Autoscaling）也是基于heapster，默认支持根据cpu的指标作动态伸缩，也能够自定义扩展使用其余指标。

可是Heapster没法作Kubernetes下应用的监控。如今，Heapster做为Kubernetes下的开源监控解决方案已经被其弃用（https://github.com/kubernetes/heapster），Prometheus成为Kubernetes官方推荐的监控解决方案。

Prometheus一样经过Kubernetes的cAdvisor接口（/api/v1/nodes/${1}/proxy/metrics/cadvisor）获取pod和container的性能监控数据，同时可使用Kubernetes的Kube-state-metrics插件来获取集群上Pod, DaemonSet, Deployment, Job, CronJob等各类资源对象的状态，这反应了使用这些资源的应用的状态。

同时经过Kubernetes api获取node，service，pod，endpoints，ingress等服务的信息，而后经过匹配注解中的值来获取采集目标。

 

上面提到了Prometheus能够经过Kubernetes的api接口实现服务发现，并将匹配定义了annotation参数的pod，service等配置成采集目标。那如今要解决的问题就是探针到应用部署配置问题了。

这里咱们使用了Kubernetes的pod部署的sidecar模式，单个应用pod部署2个容器，利用单个pod中仅共享网络的namespace的隔离特性，探针与应用一同运行，并可使用localhost直接访问应用的端口，而在pod的注解中仅暴露探针的端口（prometheus.io/port: “9104”）便可。

Prometheus server根据配置匹配定义注解prometheus.io/scrape: “true”的pod，并将pod ip和注解中定义的端口（prometheus.io/port: “9104”）和路径（prometheus.io/path: “/metrics”）拼接成采集目标http://10.244.3.123:9104/metrics。经过这种方式就能够完成动态添加须要采集的应用。

精选提问：

问1：Prometheus webui 和 Grafana的界面是独立分开的，仍是集成在一块儿的？

答：是独立页面。

问2：独立页面的话，那用户须要登陆两个界面系统？

答：Prometheus自带的界面比较简单，通常是用Grafana作页面展现。Prometheus的界面能够查看采集目标，指标，和作简单的页面展示。

问3：微课堂中提到的缺点，消耗资源偏大。（在Prometheus2.0版本有所改善)。这个偏大有量化的指标吗？

答：以前1.7版本的时候使用时，一台4C8G的机器，十多个采集目标，而后用Grafana作查询展示发现CPU会占用比较高。大概70%。

问4：Prometheus和传统zabbix有哪些优点？

答：zabbix在传统的监控中使用比较广泛，倒也说不上Prometheus有什么优点。Prometheus在Kubernetes的监控应该是有很大优点的。