章节1-Prometheus基础(1)


本文参考:
《Prometheus官方文档》,或网盘下载《Prometheus操作指南.pdf》 (提取码:1l8m)

一、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+项的第三方集成。

监控的目的

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

与常见监控系统比较
对于常用的监控系统,如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. 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.3 metrics主要数据类型

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

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

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

3. 安装部署Prometheus Server

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

环境

安装

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

二、使用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/可以看到以下页面:

node_exporter

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

node_exporter_up1


三、使用PromQL查询监控数据

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

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

node_load1

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

 

posted @ 2019-10-25 17:53  孙红雷哔哔  阅读(1133)  评论(0编辑  收藏  举报