主流前沿的开源监控和报警系统Prometheus+Grafana入门之旅-上

Prometheus概述

定义

Prometheus 官网地址 https://prometheus.io/

Prometheus 官网文档地址 https://prometheus.io/docs/introduction/overview/

Prometheus GitHub地址 https://github.com/prometheus/prometheus

Prometheus是一个开源的系统监控和警报工具包，最初由SoundCloud开发的，社区活跃，2016年加入了云原生计算基金会成为继Kubernetes之后的第二个托管项目；普罗米修斯以时间序列数据的形式收集并存储度量值；大部分模块由Go语言编写的。最新版本v2.37.0

特性

• 多维数据模型，时间序列数据由指标名称和键/值对标识。
• PromQL灵活的查询语言。
• 不依赖于分布式存储，单个节点自治。
• 时间序列收集通过拉模型基于HTTP。
• 基于网关实现采集监控指标数据的推送。
• 目标通过服务发现或静态配置。
• 多种模式的图形化和仪表板支持。
• 支持分层和水平联合。

组件

• Prometheus服务器：用于抓取和存储时间序列数据。
  • Prometheus本身是一个以进程方式启动，之后多进程和多线程实现监控数据收集，计算，查询，更新，存储的咋样一个C/S模型运行模式。
  • Prometheus采用的是time-series（时间序列）的方式以一种自定义的格式存储在本地硬盘上。
  • Prometheus的本地T-S（time-series）数据库以每两小时为间隔来分block（块）存储，每一个块中又分为多个chunk文件，chunk文件是用来存放采集过来的T-S数据，metadata和索引文件（index）。
  • index文件，是对metrics（Prometheus中一次K/V采集数据，叫做一个metric）和labels（标签）进行索引，之后存储在chunk中，chuunk是作为存储的基本单位，index and metadata是作为子集。
  • Prometheus平时是将采集过来的数据，先都存放在内存之中（Prometheus对内存的消耗还是不小的），以类似缓存的方式，用于加快搜索和访问
    当出现宕机时，Prometheus有一种保护机制叫做WAL，可以将数据定期存入硬盘中，以chunk来表示，并在重新启动时，用以恢复进入内存。
• 客户端库：编写自定义收集器从其他系统提取指标，并将指标公开给普罗米修斯。
• Pushgateway：网关，支持短周期的监控指标推送。
• exporters：用于HAProxy, StatsD, Graphite等服务的特殊用途采集。
• alertmanager：处理各种警报支持工具。

架构

Prometheus可以通过exporters直接拉取监控指标，或者通过Pushgateway获取短期任务推送监控数据，数据存储在Prometheus服务端本地，基于存储时间序列的数据上运行分析、聚合、生成警报。可以使用Grafana或其他API消费者对收集的数据进行可视化。普罗米修斯可以很好地记录任何纯数字的时间序列，它既适合以机器为中心的监视，也适合高度动态的面向服务的体系结构的监视，特别擅长于微服务和容器下多维数据收集和查询。也适合对可靠性要求高场景，每个Prometheus服务器都是独立的，不依赖于网络存储或其他远程服务。

优势

• 相比其他老款监控的不可被替代的巨大优势，功能更加强大
• 监控数据的精细程度高，可以精确到1~5秒的采集精度，是其他监控系统无法企及的。
• 集群部署的速度，监控脚本的制作(指的是熟练之后)非常快速，大大缩短监控的搭建时间成本，周边插件很丰富大多数都不需要自己开发了。
• 本身基于数学计算模型，大量的实用函数可以实现很复杂规则的业务逻辑监控(例如QPs的曲线弯曲凸起下跌的比例等等模糊概念)。
• 可以嵌入很多开源工具的内部进行监控数据更准时更可信(其他监控很难做到这一点)。
• 本身是开源的，更新速度快，bug修复快·支持N多种语言做本身和插件的二次开发。
• 图形很高大上很美观老板特别喜欢看这种业务图(主要是指跟 Grafana的结合)。

对运维要求

• 要求对操作系统有很深入扎实的了解，不能只是浮在表面。
• 对数据思维有一定的要求，因为它基本的内核就是数学公式。
• 对监控的经验有很高的要求，很多时候，监控项需要很细的定制。

数据模型（DATA MODEL）

从根本上说，Prometheus将所有数据存储为时间序列:带有时间戳的数据流属于同一度量标准和同一组标记维度。除了存储的时间序列，Prometheus还可以生成临时的派生时间序列作为查询的结果。

• 度量名称和标签(Metric names and labels)：每个时间序列由其度量名称和可选的键值对(称为标签)唯一标识。
• 样本(Samples)：样本构成实际的时间序列数据。每个样本包括，float64值和毫秒精度的时间戳。
• 标记(Notation):给定一个度量名称和一组标签，时间序列经常使用以下符号来标识。

工作和实例（JOBS AND INSTANCES）

在Prometheus术语中，可以抓取的端点称为实例，通常对应于单个进程。具有相同目的的实例集合，例如为了可伸缩性或可靠性而复制的进程，称为作业。

例如一个有四个复制实例的API服务器作业

• 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抓取目标时，它会自动在抓取的时间序列上附加一些标签，用于识别被抓取的目标:

• job:配置的目标所属的作业名称。
• instance:被抓取的目标URL的:部分。

指标度量（metrics）

Prometheus监控中，对于采集过来的数据，统一成为metrics数据，metrics已经相信大家都已耳熟，当我们需要为某个系统某个服务做监控、做统计，就需要用到metrics。metrics是一种对采集数据的总称（metrics并不代表某一种具体的数据格式，是一种对于度量计算单位的抽象）

Prometheus客户端库提供了四种核心度量类型；目前仅在客户端库(以支持针对特定类型的使用进行定制的api)和连接协议中区分这些类型。Prometheus服务器还没有使用类型信息，并将所有数据扁平化为无类型的时间序列；常见使用的就是counter、gauges和histogram

• Gauges
  • 最简单的度量指标，只有一个简单的返回值，或者叫瞬间状态，举个例子：要监控硬盘容量或者内存的使用量，那么就应该使用Gauges的metrics格式来度量。
  • 因为硬盘的容量或者内存的使用量是随着时间的推移，不过的瞬时变化这种变化没有规律，当前是多少采集回来就是多少，既不能肯定是一直持续增长，也不能肯定是一直降低，这种就是Gauges使用类型的代表。
• Counter
  • Counter计数器，从数据量0开始累积计算，在理想状态下，只能是永远的增长，不会降低（一些特殊情况另说）.举个例子：比如对用户访问量的采样数据，产品被用户访问一次就是1，过了10分钟后，累积到100过一天后，累积到20000一周后，积累到100000。
• Histograms
  • Histogram统计数据的分布情况，比如最小值，最大值，中间值，还有中位数，75百分位，90百分位，95百分位，98百分位，99百分位，和99.9百分位的值（percentiles）。这是一种特殊的Metrics数据类型，代表的是一种近似的百分比估算数值。
  • 可以通过Histogram类型（prometheus中，其实提供了一个基于histogram算法的函数，可以直接使用）可以分别统计出，全部用户的响应时间中~=0.05秒的量有多少 0 ~ 0.05秒的有多少， > 2秒的有多少 > 10 秒的有多少 = 1%多少处于速度极快的用户，多少处于慢请求或者有问题的请求。
• Summary
  • 与直方图类似，摘要采样观察结果(通常是像请求持续时间和响应大小这样的东西)。虽然它还提供了观测的总数和所有观测值的总和，但它在滑动时间窗口中计算可配置的分位数。

函数

Prometheus的查询提供很多内置的函数，这些函数后续在实战使用到再说，可以在使用查阅官网文档说明，比如

• rate() 函数：就是是专门搭配counter类型数据使⽤的函数，它的功能是按照设置⼀个时间段，取counter在这个时间段中的平均每秒的增量。
• increase()：increase 函数 在promethes中，是⽤来 针对Counter 这种持续增长的数值，截取其中⼀段时间的增量。

Prometheus部署

Docker部署

# 挂载配置文件方式部署，准备prometheus.yml文件，可以从二进制文件拷贝，默认配置无需修改，或者从github中获取，这里暴露端口我改为9080，本机已有9090的服务
docker run \
    -p 9080:9090 \
    -v /home/commons/prometheus/config/prometheus.yml:/etc/prometheus/prometheus.yml \
    prom/prometheus
# 挂载配置目录方式部署    
docker run \
    -p 9090:9090 \
    -v //home/commons/prometheus/config:/etc/prometheus \
    prom/prometheus

查看docker容器进程

访问http://192.168.50.95:9080/ 出现prometheus的控制台页面

二进制部署

# 下载最新版本v2.37.0的prometheus server
wget https://github.com/prometheus/prometheus/releases/download/v2.37.0/prometheus-2.37.0.linux-amd64.tar.gz
# 解压文件
tar -xvf prometheus-2.37.0.linux-amd64.tar.gz
# 进入目录
cd prometheus-2.37.0.linux-amd64
# 后台运行prometheus server，可通过nohup &之类或后台运行管理工具如daemonize、screen
nohup ./prometheus > prometheus.log 2>&1 &

默认情况下无需修改prometheus根目录下的prometheus.yml配置文件就可启动

# my global config
global:
  scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).
  
# scrape_interval. 抓取采详数据的时间间隔，默认每15秒去被监控机上采详一次,这个就是我们所说的Prometheus的自定义数据采集频率
# evaluation_interval. 监控数据规则的评估频率,默认为15秒，这个参数是Prometheus多长时间会进行一次监控规则的评估，假如设置当内存使用量 > 70%时，发出报警，这么一条rule（规则），那么Prometheus会默认每15秒来执行一次这个规则，检查内存的情况。

# Alertmanager configuration 这个是Alertmanager是Prometheus的一个用于管理和发出报警的插件
alerting:
  alertmanagers:
    - static_configs:
        - targets:
          # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
# 在这个Jobs 的名字下面，具体来定义，要被监控的节点，以及节点上具体的端口信息等等，如果Prometheus配合，例如consul这种服务发现软件，Prometheus的配置文件，就不在需要人工去手工定义出来，而是能自动发现集群中，有哪些新机器以及新机器上出现了哪些新服务可以被监控
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: "prometheus"

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
      - targets: ["localhost:9090"]

访问http://192.168.5.52:9090/ 出现prometheus的控制台页面，无账号密码验证（如果希望加上验证，可以使用apache httpass方式添加）

访问http://192.168.5.52:9090/ 出现prometheus的控制台页面，无账号密码验证（如果希望加上验证，可以使用apache httpass方式添加）

命令行支持参数可以查阅控制台页面http://192.168.5.52:9090/flags ，也可以直接通过控制台页面查询prometheus.yml的配置内容

通过上面scrape_configs配置可以知道默认情况下配置了对prometheus的监控，查询控制台页面prometheus的实例节点也是UP状态

prometheus数据存放在data目录下，其中长串字母的是历史数据保留，⽽当前近期数据实际上保留在内存中，并且按照⼀定间隔存放在 wal / ⽬录中防⽌突然断电或者重启以⽤来恢复内存中的数据。

**本人博客网站 **IT小神 www.itxiaoshen.com