目录

• 一、Prometheus安装部署
  • 1. 简介
    • 监控的目的
    • Prometheus的优势
  • 2. Prometheus工作流程：
    • 2.1 服务端
    • 2.2 客户端
    • 2.3 metrics主要数据类型
  • 3. 安装部署Prometheus Server
  • 4. 配置(more)
    • 4.1 配置文件(mroe)
    • 4.2 prometheus.yml的样例
• 二、使用Node Exporter采集主机运行数据
  • 1. 部署
  • 2. 熟悉Node Exporter监控指标
  • 3. 从Node Exporter收集监控数据
• 三、使用PromQL查询监控数据

---

本文参考：

《Prometheus官方文档》，或网盘下载《Prometheus操作指南.pdf》(提取码：1l8m)

一、Prometheus安装部署

Prometheus受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从 2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。 2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布 了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。 Prometheus作为新一代的云原生监控系统，目前已经有超过650+位贡献者参与到Prometheus的研发工作上，并且 超过120+项的第三方集成。

监控的目的

• 长期趋势分析：通过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，通过对磁盘空间
• 增长率的判断，我们可以提前预测在未来什么时间节点上需要对资源进行扩容。
• 对照分析：两个版本的系统运行资源使用情况的差异如何？在不同容量情况下系统的并发和负载变化如何？通过 监控能够方便的对系统进行跟踪和比较。
• 告警：当系统出现或者即将出现故障时，监控系统需要迅速反应并通知管理员，从而能够对问题进行快速的处理 或者提前预防问题的发生，避免出现对业务的影响。
• 故障分析与定位：当问题发生后，需要对问题进行调查和处理。通过对不同监控监控以及历史数据的分析，能够 找到并解决根源问题。
• 数据可视化：通过可视化仪表盘能够直接获取系统的运行状态、资源使用情况、以及服务运行状态等直观的信息。

与常见监控系统比较

对于常用的监控系统，如Nagios、Zabbix的用户而言，往往并不能很好的解决上述问题。

Prometheus的优势

Prometheus是一个开源的完整监控解决方案，其对传统监控系统的测试和告警模型进行了彻底的颠覆，形成了基于 中央化的规则计算、统一分析和告警的新模型。 相比于传统监控系统Prometheus具有以下优点：

易于管理

Prometheus核心部分只有一个单独的二进制文件，不存在任何的第三方依赖(数据库，缓存等等)。唯一需要的就是 本地磁盘，因此不会有潜在级联故障的风险。

Prometheus基于Pull模型的架构方式，可以在任何地方（本地电脑，开发环境，测试环境）搭建我们的监控系统。 对于一些复杂的情况，还可以使用Prometheus服务发现(Service Discovery)的能力动态管理监控目标。

监控服务的内部运行状态

Pometheus鼓励用户监控服务的内部状态，基于Prometheus丰富的Client库，用户可以轻松的在应用程序中添加 对Prometheus的支持，从而让用户可以获取服务和应用内部真正的运行状态。

强大的数据模型

所有采集的监控数据均以指标(metric)的形式保存在内置的时间序列数据库当中(TSDB)。所有的样本除了基本的指 标名称以外，还包含一组用于描述该样本特征的标签。

如下所示：

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...]

每一条时间序列由指标名称(Metrics Name)以及一组标签(Labels)唯一标识。每条时间序列按照时间的先后顺序 存储一系列的样本值。

表示维度的标签可能来源于你的监控对象的状态，比如code=404或者content_path=/api/path。也可能来源于 的你的环境定义，比如environment=produment。基于这些Labels我们可以方便地对监控数据进行聚合，过滤， 裁剪。

强大的查询语言PromQL

Prometheus内置了一个强大的数据查询语言PromQL。 通过PromQL可以实现对监控数据的查询、聚合。同时 PromQL也被应用于数据可视化(如Grafana)以及告警当中。

通过PromQL可以轻松回答类似于以下问题：

• 在过去一段时间中95%应用延迟时间的分布范围？
• 预测在4小时后，磁盘空间占用大致会是什么情况？
• CPU占用率前5位的服务有哪些？(过滤)

高效

对于监控系统而言，大量的监控任务必然导致有大量的数据产生。而Prometheus可以高效地处理这些数据，对于单 一Prometheus Server实例而言它可以处理：

• 数以百万的监控指标
• 每秒处理数十万的数据点。

可扩展

Prometheus是如此简单，因此你可以在每个数据中心、每个团队运行独立的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等等。

可视化

Prometheus Server中自带了一个Prometheus UI，通过这个UI可以方便地直接对数据进行查询，并且支持直接 以图形化的形式展示数据。同时Prometheus还提供了一个独立的基于Ruby On Rails的Dashboard解决方案 Promdash。最新的Grafana可视化工具也已经提供了完整的Prometheus支持，基于Grafana可以创建更加精美的 监控图标。基于Prometheus提供的API还可以实现自己的监控可视化UI。

开放性

通常来说当我们需要监控一个应用程序时，一般需要该应用程序提供对相应监控系统协议的支持。因此应用程序会与 所选择的监控系统进行绑定。为了减少这种绑定所带来的限制。对于决策者而言要么你就直接在应用中集成该监控系 统的支持，要么就在外部创建单独的服务来适配不同的监控系统。

而对于Prometheus来说，使用Prometheus的client library的输出格式不止支持Prometheus的格式化数据， 也可以输出支持其它监控系统的格式化数据，比如Graphite。

因此你甚至可以在不使用Prometheus的情况下，采用Prometheus的client library来让你的应用程序支持监控 数据采集。

Architecture

This diagram illustrates the architecture of Prometheus and some of its ecosystem components:

---

Prometheus是一个开放性的监控解决方案，用户可以非常方便的安装和使用Prometheus并且能够非常方便的对其 进行扩展。为了能够更加直观的了解Prometheus Server，接下来我们将在本地部署并运行一个Prometheus Server实例，通过Node Exporter采集当前主机的系统资源使用情况。 并通过Grafana创建一个简单的可视化仪 表盘。

---

2.1 服务端

Prometheus服务端以一个进程方式启动，如果不考虑参数和后台运行的话，只需要解压安装包之后运行./prometheus脚本即可启动，程序默认监听在9090端口。每次采集到的数据叫做metrics。这些采集到的数据会先存放在内存中，然后定期再写入硬盘，如果服务重新启动的话会将硬盘数据写回到内存中，所以对内存有一定消耗。Prometheus不需要重视历史数据，所以默认只会保留15天的数据。

2.2 客户端

Prometheus客户端分为pull和push两种方式。如果是pull形式的话则是服务端主动向客户端拉取数据，这样需要客户端上安装exporters（导出器）作为守护进程，官网上也提供了很多exporters可以下载使用，比如使用最多的node_exporters，几乎把系统自身相关数据全部采集了，非常全面，node_exporter默认监听9100端口。

如果是push形式的话客户端需要安装pushgateway插件，然后运需要运维人员用脚本把监控数据组织成键值形式提交给pushgateway，再由它提交给服务端。它适合于现有exporters无法满足需求时，自己灵活定制。

2.3 metrics主要数据类型

Gauges：最简单、使用最多的指标，获取一个返回值，这个返回值没有变化规律，不能肯定它一定是增长或是减少的状态，采集回来是多少就是多少。比如硬盘容量、CPU内存使用率都适合使用Gauges数据类型。

Counters：计数器。数据从0开始累计，理想状态下应该是永远增长或者是不变。适合统计机器开机时间、HTTP访问量

Histograms：和summary一样属于高级指标，用于统计数据的分布情况。比如最小值、最大值、中间值。这个类型不太好理解，比如说统计一天的日志，大部分用户响应时间都是正常的，只有少量用户异常，如果这个时候取平均值的话，这少量用户的异常情况就会被掩盖过去，而Histograms可以分别统计出全部用户的响应时间，比如0-1秒的用户有多少、1-2秒的用户有多少（其实有点像Kibana）

Prometheus基于Golang编写，编译后的软件包，不依赖于任何的第三方依赖。用户只需要下载对应平台的二进制 包，解压并且添加基本的配置即可正常启动Prometheus Server。

环境

• 系统环境：Centos 7.2
• 软件版本：prometheus-2.13.1.linux-amd64.tar.gz
• 下载地址：https://prometheus.io/download/

安装

tar -xzvf prometheus-2.13.1.linux-amd64.tar.gz
mkdir /usr/local/prometheus
mv prometheus-2.13.1.linux-amd64 /usr/local/prometheus

创建数据目录

mkdir -p /data/prometheus/data

用户授权

useradd prometheus -s /sbin/nologin
chown -R prometheus:prometheus /usr/local/prometheus /data/prometheus

添加启动服务

编辑/usr/lib/systemd/system/prometheus.service，配置如下：

[Unit]
Description=prometheus
After=network.target

[Service]
Type=simple
User=prometheus
ExecStart=/usr/local/prometheus/prometheus --config.file=/usr/local/prometheus/prometheus.yml --storage.tsdb.path=/data/prometheus/data
Restart=on-failure
ExecReload=/bin/kill -HUP $MAINPID
[Install]
WantedBy=multi-user.target

启动

systemctl daemon-reload
systemctl enable prometheus.service
systemctl start prometheus.service

验证

WEB地址：http://ip:9090

Prometheus可以在运行时重新加载其配置。如果新配置格式不正确，则更改将不会应用。通过向Prometheus进程发送SIGHUP或向/-/reload端点发送HTTP POST请求来触发配置重新加载（--web.enable-lifecycle启用该标志时）。这还将重新加载所有已配置的规则文件。

yaml文件书写的要求如下：

• 大小写敏感
• 使用缩进表示层级关系
• 缩进时不允许使用Tab键，只允许使用空格。
• 缩进的空格数目不重要，只要相同层级的元素左侧对齐即可

4.1 配置文件(mroe)

要指定要加载的配置文件，请使用该--config.file标志。

该文件以YAML格式写入，由以下所述的方案定义。方括号表示参数是可选的。对于非列表参数，该值设置为指定的默认值。

通用占位符定义如下：

• <boolean>：可以接受值的布尔值true或false
• <duration>：与正则表达式匹配的持续时间 [0-9]+(ms|[smhdwy])
• <labelname>：与正则表达式匹配的字符串 [a-zA-Z_][a-zA-Z0-9_]*
• <labelvalue>：一串unicode字符
• <filename>：当前工作目录中的有效路径
• <host>：由主机名或IP后跟可选端口号组成的有效字符串
• <path>：有效的网址路径
• <scheme>：可以采用值http或https
• <string>：常规字符串
• <secret>：是秘密的常规字符串，例如密码
• <tmpl_string>：使用前已模板扩展的字符串

其他占位符分别指定。

在这里可以找到有效的示例文件。

全局配置指定在所有其他配置上下文中有效的参数。它们还用作其他配置部分的默认设置。

global:
  # 默认情况下抓取目标的频率.
  [ scrape_interval: <duration> | default = 1m ]

  # 抓取超时时间.
  [ scrape_timeout: <duration> | default = 10s ]

  # 评估规则的频率.
  [ evaluation_interval: <duration> | default = 1m ]

  # 与外部系统通信时添加到任何时间序列或警报的标签
  #（联合，远程存储，Alertma# nager）.
  external_labels:
    [ <labelname>: <labelvalue> ... ]

# 规则文件指定了一个globs列表.
# 从所有匹配的文件中读取规则和警报.
rule_files:
  [ - <filepath_glob> ... ]

# 抓取配置列表.
scrape_configs:
  [ - <scrape_config> ... ]

# 警报指定与Alertmanager相关的设置.
alerting:
  alert_relabel_configs:
    [ - <relabel_config> ... ]
  alertmanagers:
    [ - <alertmanager_config> ... ]

# 与远程写入功能相关的设置.
remote_write:
  [ - <remote_write> ... ]

# 与远程读取功能相关的设置.
remote_read:
  [ - <remote_read> ... ]

4.2 prometheus.yml的样例

(标签部分内容不是必须的，可以了解)

global:
  scrape_interval: 15s #抓取数据的频率，默认15秒。该配置也可配置在每个job_name中
  evaluation_interval: 15s #监控规则评估频率，比如设置了当内存使用大于70%发出报警的规则，然后每15秒来执行一次这个规则

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

scrape_configs:
  - job_name: 'prometheus-server' #作业名，可以理解为组名，其下可以有多个实例配置
    static_configs:
    - targets: ['localhost:9090'] #节点的地址，可以写多个地址
# params: #过滤器
# collect[]:
# - cpu #只采集CPU数据
  - job_name: 'www'
    static_configs:
    - targets: ['ip:9100','ip:9100']
      labels: #自定义标签，可以通过标签进行统一管理
        idc:beijing #增加一个idc标签，内容为beijing
#使用正则替换标签
  - job_name: 'node'
    static_configs:
    - targets: ['ip:9100','ip:9100']
    metric_relable_configs: #通过正则重命名标签
    - action: replace #replace替换是默认动作。此外还有keep（只参加匹配标签的实例）、drop（不采集匹配正则的实例）、labelkeep\labeldrop(对标签进行过滤处理而非实例)等动作
      source_labels: ['job'] #原标签，job是默认就会产生的标签，这里job标签的值是node
      regex: (.*) #正则匹配，这里匹配job标签内的内容，也就是node
      replacement: beijing #替换成什么内容，如果写$1就是将正则里的内容拿过来
      target_label: idc #把替换到的内容赋值给idc标签
    - action: labeldrop #删除标签
      regex: job #把原有的job标签删除不显示

---

二、使用Node Exporter采集主机运行数据

在Prometheus的架构设计中，Prometheus Server并不直接服务监控特定的目标，其主要任务负责数据的收集， 存储并且对外提供数据查询支持。因此为了能够能够监控到某些东西，如主机的CPU使用率，我们需要使用到 Exporter。Prometheus周期性的从Exporter暴露的HTTP服务地址（通常是/metrics）拉取监控样本数据。 从上面的描述中可以看出Exporter可以是一个相对开放的概念，其可以是一个独立运行的程序独立于监控目标以外， 也可以是直接内置在监控目标中。只要能够向Prometheus提供标准格式的监控样本数据即可。

这里为了能够采集到主机的运行指标如CPU, 内存，磁盘等信息。我们可以使用Node Exporter(prometheus客户端)。

Node Exporter同样采用Golang编写，并且不存在任何的第三方依赖，只需要下载，解压即可运行。可以从 https://prometheus.io/download/，获取最新的node exporter版本的二进制包。

curl -OL https://github.com/prometheus/node_exporter/releases/download/v0.18.1/node_exporter-0.18.1.linux-amd64.tar.gz
tar -zxf node_exporter-0.18.1.linux-amd64.tar.gz

配置system启动

mv node_exporter-0.18.1.linux-amd64 /usr/local/node_exporter
ln -s /usr/local/node_exporter/node_exporter /usr/local/bin/node_exporter

编辑/usr/lib/systemd/system/node_exporter.service，配置如下：

[Unit]
Description=Prometheus node_exporter
Wants=network-online.target
After=network-online.target

[Service]
User=nobody
ExecStart=/usr/local/bin/node_exporter --log.level=error
ExecStop=/usr/bin/killall node_exporter
MemoryLimit=300M #限制内存使用最多300M
CPUQuota=100% #限制CPU使用最多一个核

[Install]
WantedBy=default.target



# 现在重新加载systemd系统。
systemctl daemon-reload
# 然后启动node_exporter服务并使其在系统启动时每次启动。
systemctl start node_exporter
systemctl enable node_exporter

启动成功后，可以看到以下输出：

INFO[0000] Listening on :9100 source="node_exporter.go:170"

访问http://localhost:9100/可以看到以下页面：

访问http://localhost:9100/metrics，可以看到当前node exporter获取到的当前主机的所有监控数据，如 下所示：

每一个监控指标之前都会有一段类似于如下形式的信息：

# HELP node_cpu_seconds_total Seconds the cpus spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 4.13190739e+06
# HELP node_load1 1m load average.
# TYPE node_load1 gauge
 node_load1 0.0103125

变更：0.15版本node_cpu在0.18版本中变更命名为node_cpu_seconds_total

其中HELP用于解释当前指标的含义，TYPE则说明当前指标的数据类型。在上面的例子中node_cpu的注释表明当前指 标是cpu0上idle进程占用CPU的总时间，CPU占用时间是一个只增不减的度量指标，从类型中也可以看出node_cpu 的数据类型是计数器(counter)，与该指标的实际含义一致。又例如node_load1该指标反映了当前主机在最近一分 钟以内的负载情况，系统的负载情况会随系统资源的使用而变化，因此node_load1反映的是当前状态，数据可能增 加也可能减少，从注释中可以看出当前指标类型为仪表盘(gauge)，与指标反映的实际含义一致。

除了这些以外，在当前页面中根据物理主机系统的不同，你还可能看到如下监控指标：

• node_boot_time：系统启动时间
• node_cpu：系统CPU使用量
• nodedisk*：磁盘IO
• nodefilesystem*：文件系统用量
• node_load1：系统负载
• nodememeory*：内存使用量
• nodenetwork*：网络带宽
• node_time：当前系统时间
• go_*：node exporter中go相关指标
• process_*：node exporter自身进程相关运行指标

为了能够让Prometheus Server能够从当前node exporter获取到监控数据，这里需要修改Prometheus配置文 件。编辑prometheus.yml并在scrape_configs节点下添加以下内容:

scrape_configs:
  - job_name: 'prometheus_97'
    static_configs:
      - targets: ['localhost:9090']
  # 采集node_exporter监控数据
  - job_name: 'node_97'
    static_configs:
      - targets: ['localhost:9100']

重新启动Prometheus Server

访问http://localhost:9090，进入到Prometheus Server。如果输入"up"并且点击执行按钮以后，并且Prometheus能够正常从node_exporter获取数据，则会看到以下结果：

up{instance="localhost:9090",job="prometheus"} 1
up{instance="localhost:9100",job="node"} 1

其中“1”表示正常，反之“0”则为异常。

---

三、使用PromQL查询监控数据

Prometheus UI是Prometheus内置的一个可视化管理界面，通过Prometheus UI用户能够轻松的了解 Prometheus当前的配置，监控任务运行状态等。 通过 Graph 面板，用户还能直接使用 PromQL 实时查询监控数据。

切换到 Graph 面板，用户可以使用PromQL表达式查询特定监控指标的监控数据。如下所示，查询主机负载变化情 况，可以使用关键字 node_load1 可以查询出Prometheus采集到的主机负载的样本数据，这些样本数据按照时间先 后顺序展示，形成了主机负载随时间变化的趋势图表：

PromQL是Prometheus自定义的一套强大的数据查询语言，除了使用监控指标作为查询关键字以为，还内置了大量的 函数，帮助用户进一步对时序数据进行处理。例如使用 rate() 函数，可以计算在单位时间内样本数据的变化情况即 增长率，因此通过该函数我们可以近似的通过CPU使用时间计算CPU的利用率：

// before v0.15
rate(node_cpu[2m])
// after v0.18
rate(node_cpu_seconds_total[2m])

这时如果要忽略是哪一个CPU的，只需要使用without表达式，将标签CPU去除后聚合数据即可：

avg without(cpu) (rate(node_cpu_seconds_total[2m]))

那如果需要计算系统CPU的总体使用率，通过排除系统闲置的CPU使用率即可获得:

通过PromQL我们可以非常方便的对数据进行查询，过滤，以及聚合，计算等操作。通过这些丰富的表达书语句，监控 指标不再是一个单独存在的个体，而是一个个能够表达出正式业务含义的语言。

---

[sleepy↓]