章节1-Prometheus基础(1)

时间 2019-11-18

标签章节 prometheus 基础繁體版

原文原文链接

目录html

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

1、Prometheus安装部署

1. 简介

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

监控的目的

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

与常见监控系统比较
对于经常使用的监控系统，如Nagios、Zabbix的用户而言，每每并不能很好的解决上述问题。ios

Prometheus的优点

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

易于管理github

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

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

监控服务的内部运行状态数据库

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

强大的数据模型

全部采集的监控数据均以指标(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. Prometheus工做流程：

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.3metrics主要数据类型

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

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

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

3. 安装部署Prometheus Server

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

4. 配置(more)

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标签删除不显示

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

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

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

1. 部署

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/能够看到如下页面：

2. 熟悉Node Exporter监控指标

访问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自身进程相关运行指标

3. 从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”则为异常。

3、使用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↓]