prometheus 监控概述(一)

1、监控系统概论

监控系统在这里特指对数据中心的监控，主要针对数据中心内的硬件和软件进行监控和告警。企业的 IT 架构逐步从传统的物理服务器，迁移到以虚拟机为主导的 IaaS 云。不管基础架构如何调整，都离不开监控系统的支持。

不只如此。愈来愈复杂的数据中心环境对监控系统提出了更愈来愈高的要求：须要监控不一样的对象，例如容器，分布式存储，SDN网络，分布式系统。各类应用程序等，种类繁多，还须要采集和存储大量的监控数据，例如天天数TB数据的采集汇总。以及基于这些监控数据的智能分析，告警及预警等。

在每一个企业的数据中心内，或多或少都会使用一些开源或者商业的监控系统。从监控对象的角度来看，能够将监控分为网络监控，存储监控，服务器监控和应用监控等，由于须要监控数据中心的各个方面。因此监控系统须要作到面面俱到，在数据中心中充当“天眼“角色。

2、基础资源监控

2.一、网络监控

网络性能监控：主要涉及网络监测，网络实时流量监控（网络延迟、访问量、成功率）和历史数据统计、汇总和历史数据分析等功能。

网络***检测：主要针对内网或者外网的网络***。如DDoS***的。经过分析异常流量来肯定网络***行为。

设备监控：主要针对数据中心内的多种网络设备进行监控。包括路由器，防火墙和交换机等硬件设备，能够经过snmp等协议收集数据。

2.二、存储监控

存储性能监控方面：存储一般监控块的读写速率，IOPS。读写延迟，磁盘用量等；文件存储一般监控文件系统inode。读写速度、目录权限等。

存储系统监控方面：不一样的存储系统有不一样的指标，例如，对于ceph存储须要监控OSD, MON的运行状态，各类状态pg的数量以及集群IOPS等信息。

存储设备监控方面：对于构建在x86服务器上的存储设备，设备监控经过每一个存储节点上的采集器统一收集磁盘、SSD、网卡等设备信息；存储厂商以黑盒方式提供商业存储设备，一般自带监控功能，可监控设备的运行状态，性能和容量的。

2.三、服务器监控

CPU：涉及整个 CPU 的使用量、用户态百分比、内核态百分比，每一个 CPU 的使用量、等待队列长度、I/O 等待百分比、CPU 消耗最多的进程、上下文切换次数、缓存命中率等。

内存：涉及内存的使用量、剩余量、内存占用最高的进程、交换分区大小、缺页异常等。

网络 I/O：涉及每一个网卡的上行流量、下行流量、网络延迟、丢包率等。

磁盘 I/O：涉及硬盘的读写速率、IOPS、磁盘用量、读写延迟等。

2.四、中间件监控

消息中间件： RabbitMQ、Kafka

Web 服务中间件：Tomcat、Jetty

缓存中间件：Redis、Memcached

数据库中间件：MySQL、PostgreSQL

2.五、应用程序监控（APM）

APM主要是针对应用程序的监控，包括应用程序的运行状态监控，性能监控，日志监控及调用链跟踪等。调用链跟踪是指追踪整个请求过程（从用户发送请求，一般指浏览器或者应用客户端）到后端API服务以及API服务和关联的中间件，或者其余组件之间的调用，构建出一个完整的调用拓扑结构，不只如此，APM 还能够监控组件内部方法的调用层次（Controller-->service-->Dao）获取每一个函数的执行耗时，从而为性能调优提供数据支撑。

应用程序监控工具除了有 Pinpoint，还有 Twitter 开源的 Zipkin，Apache SkyWalking，美团开源的 CAT等。

调用键监控

几款产品对比

Pinpoint

经过 APM 除了能够截获方法调用，还能够截获TCP、HTTP网络请求，从而得到执行耗时最长的方法和 SQL 语句、延迟最大的 API 的信息。

3、Prometheus 简介

3.一、什么是 Prometheus

Prometheus 是一套开源的系统监控报警框架。它启发于 Google 的 borgmon 监控系统，由工做在 SoundCloud 的 google 前员工在 2012 年建立，做为社区开源项目进行开发，并于 2015 年正式发布。2016 年，Prometheus 正式加入 Cloud Native Computing Foundation，成为受欢迎度仅次于 Kubernetes 的项目。

3.二、优势

• 强大的多维度数据模型：

  1. 时间序列数据经过 metric 名和键值对来区分。
  2. 全部的 metrics 均可以设置任意的多维标签。
  3. 数据模型更随意，不须要刻意设置为以点分隔的字符串。
  4. 能够对数据模型进行聚合，切割和切片操做。
  5. 支持双精度浮点类型，标签能够设为全 unicode。
• 灵活而强大的查询语句（PromQL）：在同一个查询语句，能够对多个 metrics 进行乘法、加法、链接、取分数位等操做。
• 易于管理： Prometheus server 是一个单独的二进制文件，可直接在本地工做，不依赖于分布式存储。
• 高效：平均每一个采样点仅占 3.5 bytes，且一个 Prometheus server 能够处理数百万的 metrics。
• 使用 pull 模式采集时间序列数据，这样不只有利于本机测试并且能够避免有问题的服务器推送坏的 metrics。
• 能够采用 push gateway 的方式把时间序列数据推送至 Prometheus server 端。
• 能够经过服务发现或者静态配置去获取监控的 targets。
• 有多种可视化图形界面。
• 易于伸缩。

3.三、组件

Prometheus 生态圈中包含了多个组件，其中许多组件是可选的：

• Prometheus Server: 用于收集和存储时间序列数据。
• Client Library: 客户端库，为须要监控的服务生成相应的 metrics 并暴露给 Prometheus server。当 Prometheus server 来 pull 时，直接返回实时状态的 metrics。
• Push Gateway: 主要用于短时间的 jobs。因为这类 jobs 存在时间较短，可能在 Prometheus 来 pull 以前就消失了。为此，此次 jobs 能够直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，须要使用 node exporter。
• Exporters: 用于暴露已有的第三方服务的 metrics 给 Prometheus。
• Alertmanager: 从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对收的接受方式，发出报警。常见的接收方式有：电子邮件，pagerduty，OpsGenie, webhook 等。
• 一些其余的工具。

3.四、架构

从这个架构图，也能够看出 Prometheus 的主要模块包含， Server, Exporters, Pushgateway, PromQL, Alertmanager, WebUI 等。

它大体使用逻辑是这样：

1. Prometheus server 按期从静态配置的 targets 或者服务发现的 targets 拉取数据。
2. 当新拉取的数据大于配置内存缓存区的时候，Prometheus 会将数据持久化到磁盘（若是使用 remote storage 将持久化到云端）。
3. Prometheus 能够配置 rules，而后定时查询数据，当条件触发的时候，会将 alert 推送到配置的 Alertmanager。
4. Alertmanager 收到警告的时候，能够根据配置，聚合，去重，降噪，最后发送警告。
5. 可使用 API， Prometheus Console 或者 Grafana 查询和聚合数据。

3.五、适用于什么场景

Prometheus 适用于记录文本格式的时间序列，它既适用于以机器为中心的监控，也适用于高度动态的面向服务架构的监控。在微服务的世界中，它对多维数据收集和查询的支持有特殊优点。Prometheus 是专为提升系统可靠性而设计的，它能够在断电期间快速诊断问题，每一个 Prometheus Server 都是相互独立的，不依赖于网络存储或其余远程服务。当基础架构出现故障时，你能够经过 Prometheus 快速定位故障点，并且不会消耗大量的基础架构资源。

3.六、不适合什么场景

Prometheus 很是重视可靠性，即便在出现故障的状况下，你也能够随时查看有关系统的可用统计信息。若是你须要百分之百的准确度，例如按请求数量计费，那么 Prometheus 不太适合你，由于它收集的数据可能不够详细完整。这种状况下，你最好使用其余系统来收集和分析数据以进行计费，并使用 Prometheus 来监控系统的其他部分。

4、数据模型

4.一、数据模型

Prometheus 全部采集的监控数据均以指标（metric）的形式保存在内置的时间序列数据库当中（TSDB）：属于同一指标名称，同一标签集合的、有时间戳标记的数据流。除了存储的时间序列，Prometheus 还能够根据查询请求产生临时的、衍生的时间序列做为返回结果。

指标名称和标签

每一条时间序列由指标名称（Metrics Name）以及一组标签（键值对）惟一标识。其中指标的名称（metric name）能够反映被监控样本的含义（例如，http_requests_total — 表示当前系统接收到的 HTTP 请求总量），指标名称只能由 ASCII 字符、数字、下划线以及冒号组成，同时必须匹配正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]*。

[info] 注意

冒号用来表示用户自定义的记录规则，不能在 exporter 中或监控对象直接暴露的指标中使用冒号来定义指标名称。

经过使用标签，Prometheus 开启了强大的多维数据模型：对于相同的指标名称，经过不一样标签列表的集合，会造成特定的度量维度实例（例如：全部包含度量名称为 /api/tracks 的 http 请求，打上 method=POST 的标签，就会造成具体的 http 请求）。该查询语言在这些指标和标签列表的基础上进行过滤和聚合。改变任何度量指标上的任何标签值（包括添加或删除指标），都会建立新的时间序列。

标签的名称只能由 ASCII 字符、数字以及下划线组成并知足正则表达式 [a-zA-Z_][a-zA-Z0-9_]*。其中以 __ 做为前缀的标签，是系统保留的关键字，只能在系统内部使用。标签的值则能够包含任何 Unicode 编码的字符。

时序样本

在时间序列中的每个点称为一个样本（sample），样本由如下三部分组成：

• 指标（metric）：指标名称和描述当前样本特征的 labelsets；
• 时间戳（timestamp）：一个精确到毫秒的时间戳；
• 样本值（value）： 一个 folat64 的浮点型数据表示当前样本的值。

格式

经过以下表达方式表示指定指标名称和指定标签集合的时间序列：

<metric name>{<label name>=<label value>, ...}

例如，指标名称为 api_http_requests_total，标签为 method="POST" 和 handler="/messages" 的时间序列能够表示为：

api_http_requests_total{method="POST", handler="/messages"}

这与 OpenTSDB 中使用的标记法相同。

4.二、指标类型

Prometheus 的客户端库中提供了四种核心的指标类型。但这些类型只是在客户端库（客户端能够根据不一样的数据类型调用不一样的 API 接口）和在线协议中，实际在 Prometheus server 中并不对指标类型进行区分，而是简单地把这些指标统一视为无类型的时间序列。不过，未来咱们会努力改变这一现状的。

Counter

• 一种累加的 metric，典型的应用如：请求的个数，结束的任务数， 出现的错误数等等。

例如 Prometheus server 中 http_requests_total, 表示 Prometheus 处理的 http 请求总数，咱们可使用 delta, 很容易获得任意区间数据的增量，这个会在 PromQL 一节中细讲。

Gauge

• 一种常规的 metric，典型的应用如：温度，运行的 goroutines 的个数。
• 能够任意加减。

例如 Prometheus server 中 go_goroutines, 表示 Prometheus 当前 goroutines 的数量。

Histogram

• 能够理解为柱状图，典型的应用如：请求持续时间，响应大小。
• 能够对观察结果采样，分组及统计。

例如，查询 prometheus_http_request_duration_seconds_sum{handler="/api/v1/query",instance="localhost:9090",job="prometheus"}时，返回结果以下：

Summary

• 相似于 Histogram, 典型的应用如：请求持续时间，响应大小。
• 提供观测值的 count 和 sum 功能。
• 提供百分位的功能，便可以按百分比划分跟踪结果。

4.三、instance 和 jobs

Prometheus 中，将任意一个独立的数据源（target）称之为实例（instance）。包含相同类型的实例的集合称之为做业（job）。 以下是一个含有四个重复实例的做业：

- job: api-server
    - instance 1: 1.2.3.4:5670
    - instance 2: 1.2.3.4:5671
    - instance 3: 5.6.7.8:5670
    - instance 4: 5.6.7.8:5671

自生成标签和时序

Prometheus 在采集数据的同时，会自动在时序的基础上添加标签，做为数据源（target）的标识，以便区分：

• job: The configured job name that the target belongs to.
• instance: The <host>:<port> part of the target's URL that was scraped.

若是其中任一标签已经在此前采集的数据中存在，那么将会根据 honor_labels 设置选项来决定新标签。详见官网解释： scrape configuration documentation

对每个实例而言，Prometheus 按照如下时序来存储所采集的数据样本：

• up{job="<job-name>", instance="<instance-id>"}: 1 表示该实例正常工做

• up{job="<job-name>", instance="<instance-id>"}: 0 表示该实例故障

• scrape_duration_seconds{job="<job-name>", instance="<instance-id>"} 表示拉取数据的时间间隔

• scrape_samples_post_metric_relabeling{job="<job-name>", instance="<instance-id>"} 表示采用重定义标签（relabeling）操做后仍然剩余的样本数

• scrape_samples_scraped{job="<job-name>", instance="<instance-id>"} 表示从该数据源获取的样本数

其中 up 时序能够有效应用于监控该实例是否正常工做。

5、其余监控工具

在前言中，简单介绍了咱们选择 Prometheus 的理由，以及使用后给咱们带来的好处。

在这里主要和其余监控方案对比，方便你们更好的了解 Prometheus。

Prometheus vs Zabbix

• Zabbix 使用的是 C 和 PHP, Prometheus 使用 Golang, 总体而言 Prometheus 运行速度更快一点。
• Zabbix 属于传统主机监控，主要用于物理主机，交换机，网络等监控，Prometheus 不只适用主机监控，还适用于 Cloud, SaaS, Openstack，Container 监控。
• Zabbix 在传统主机监控方面，有更丰富的插件。
• Zabbix 能够在 WebGui 中配置不少事情，可是 Prometheus 须要手动修改文件配置。

Prometheus vs Graphite

• Graphite 功能较少，它专一于两件事，存储时序数据， 可视化数据，其余功能须要安装相关插件，而 Prometheus 属于一站式，提供告警和趋势分析的常见功能，它提供更强的数据存储和查询能力。
• 在水平扩展方案以及数据存储周期上，Graphite 作的更好。

Prometheus vs InfluxDB

• InfluxDB 是一个开源的时序数据库，主要用于存储数据，若是想搭建监控告警系统， 须要依赖其余系统。
• InfluxDB 在存储水平扩展以及高可用方面作的更好, 毕竟核心是数据库。

Prometheus vs OpenTSDB

• OpenTSDB 是一个分布式时序数据库，它依赖 Hadoop 和 HBase，能存储更长久数据， 若是你系统已经运行了 Hadoop 和 HBase, 它是个不错的选择。
• 若是想搭建监控告警系统，OpenTSDB 须要依赖其余系统。

Prometheus vs Nagios

• Nagios 数据不支持自定义 Labels, 不支持查询，告警也不支持去噪，分组, 没有数据存储，若是想查询历史状态，须要安装插件。
• Nagios 是上世纪 90 年代的监控系统，比较适合小集群或静态系统的监控，显然 Nagios 太古老了，不少特性都没有，相比之下Prometheus 要优秀不少。

Prometheus vs Sensu

• Sensu 广义上讲是 Nagios 的升级版本，它解决了不少 Nagios 的问题，若是你对 Nagios 很熟悉，使用 Sensu 是个不错的选择。
• Sensu 依赖 RabbitMQ 和 Redis，数据存储上扩展性更好。

总结

• Prometheus 属于一站式监控告警平台，依赖少，功能齐全。
• Prometheus 支持对云或容器的监控，其余系统主要对主机监控。
• Prometheus 数据查询语句表现力更强大，内置更强大的统计函数。
• Prometheus 在数据存储扩展性以及持久性上没有 InfluxDB，OpenTSDB，Sensu 好。

6、Export

6.一、文本格式

在讨论 Exporter 以前，有必要先介绍一下 Prometheus 文本数据格式，由于一个 Exporter 本质上就是将收集的数据，转化为对应的文本格式，并提供 http 请求。

Exporter 收集的数据转化的文本内容以行 (\n) 为单位，空行将被忽略, 文本内容最后一行为空行

注释

文本内容，若是以 # 开头一般表示注释。

• 以 # HELP 开头表示 metric 帮助说明。
• 以 # TYPE 开头表示定义 metric 类型，包含 counter, gauge, histogram, summary, 和 untyped 类型。
• 其余表示通常注释，供阅读使用，将被 Prometheus 忽略。

采样数据

内容若是不以 # 开头，表示采样数据。它一般紧挨着类型定义行，知足如下格式：

metric_name [
  "{" label_name "=" `"` label_value `"` { "," label_name "=" `"` label_value `"` } [ "," ] "}"
] value [ timestamp ]

下面是一个完整的例子：

# HELP http_requests_total The total number of HTTP requests.
# TYPE http_requests_total counter
http_requests_total{method="post",code="200"} 1027 1395066363000
http_requests_total{method="post",code="400"}    3 1395066363000

# Escaping in label values:
msdos_file_access_time_seconds{path="C:\\DIR\\FILE.TXT",error="Cannot find file:\n\"FILE.TXT\""} 1.458255915e9

# Minimalistic line:
metric_without_timestamp_and_labels 12.47

# A weird metric from before the epoch:
something_weird{problem="division by zero"} +Inf -3982045

# A histogram, which has a pretty complex representation in the text format:
# HELP http_request_duration_seconds A histogram of the request duration.
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.05"} 24054
http_request_duration_seconds_bucket{le="0.1"} 33444
http_request_duration_seconds_bucket{le="0.2"} 100392
http_request_duration_seconds_bucket{le="0.5"} 129389
http_request_duration_seconds_bucket{le="1"} 133988
http_request_duration_seconds_bucket{le="+Inf"} 144320
http_request_duration_seconds_sum 53423
http_request_duration_seconds_count 144320

# Finally a summary, which has a complex representation, too:
# HELP rpc_duration_seconds A summary of the RPC duration in seconds.
# TYPE rpc_duration_seconds summary
rpc_duration_seconds{quantile="0.01"} 3102
rpc_duration_seconds{quantile="0.05"} 3272
rpc_duration_seconds{quantile="0.5"} 4773
rpc_duration_seconds{quantile="0.9"} 9001
rpc_duration_seconds{quantile="0.99"} 76656
rpc_duration_seconds_sum 1.7560473e+07
rpc_duration_seconds_count 2693

须要特别注意的是，假设采样数据 metric 叫作 x, 若是 x 是 histogram 或 summary 类型必需知足如下条件：

• 采样数据的总和应表示为 x_sum。
• 采样数据的总量应表示为 x_count。
• summary 类型的采样数据的 quantile 应表示为 x{quantile="y"}。
• histogram 类型的采样分区统计数据将表示为 x_bucket{le="y"}。
• histogram 类型的采样必须包含 x_bucket{le="+Inf"}, 它的值等于 x_count 的值。
• summary 和 historam 中 quantile 和 le 必需按从小到大顺序排列。

6.二、经常使用查询

收集到 node_exporter 的数据后，咱们可使用 PromQL 进行一些业务查询和监控，下面是一些比较常见的查询。

注意：如下查询均以单个节点做为例子，若是你们想查看全部节点，将 instance="xxx" 去掉便可。

CPU 使用率

100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

CPU 各 mode 占比率

avg by (instance, mode) (irate(node_cpu_seconds_total[5m])) * 100

机器平均负载

node_load1{instance="xxx"} // 1分钟负载
node_load5{instance="xxx"} // 5分钟负载
node_load15{instance="xxx"} // 15分钟负载

内存使用率

100 - ((node_memory_MemFree_bytes+node_memory_Cached_bytes+node_memory_Buffers_bytes)/node_memory_MemTotal_bytes) * 100

磁盘使用率

100 - node_filesystem_free{instance="xxx",fstype!~"rootfs|selinuxfs|autofs|rpc_pipefs|tmpfs|udev|none|devpts|sysfs|debugfs|fuse.*"} / node_filesystem_size{instance="xxx",fstype!~"rootfs|selinuxfs|autofs|rpc_pipefs|tmpfs|udev|none|devpts|sysfs|debugfs|fuse.*"} * 100

或者你也能够直接使用 {fstype="xxx"} 来指定想查看的磁盘信息

网络 IO

// 上行带宽
sum by (instance) (irate(node_network_receive_bytes{instance="xxx",device!~"bond.*?|lo"}[5m])/128)

// 下行带宽
sum by (instance) (irate(node_network_transmit_bytes{instance="xxx",device!~"bond.*?|lo"}[5m])/128)

网卡出/入包

// 入包量
sum by (instance) (rate(node_network_receive_bytes{instance="xxx",device!="lo"}[5m]))

// 出包量
sum by (instance) (rate(node_network_transmit_bytes{instance="xxx",device!="lo"}[5m]))

欢迎你们扫码关注，获取更多信息