[系统运维]prometheus--一些知识

1、安装

• prometheus安装较为简单，直接官网下载tar包，解压之后直接运行默认端口9090，添加path环境变量PATH=$PATH:/prometheus/prometheus-2.29.1.linux-amd64
  直接启动prometheus start或者使用程序入口启动

  bash ./prometheus --config.file=prometheus.yml
  由于prometheus前端启动，因此我们可以使用nohup与&一起让其后台运行

• export存在各种各样的，目前常用的为node-export和db-export，安装方式也是非常简单，和prometheus安装方式一样，端口默认9100，后台运行，安装之后可以检查一下是否运行，如 bash curl localhost:9100/metrics 来验证

• grafana安装更简单了，可以使用rpm包，wget rpm地址，在yum install rpm包

一些基本知识

prometheus对于采集过来对数据统一称之为metrics
metrics是数据形式有：

Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）、Summary（摘要）

counter

只增不减/reset归零，记录某些事件发生次数，系统运行时间，用户访问量，记录请求次数、任务完成数、错误发生次数,该指标的工作方式和计数器一样，只增不减（除非系统发生了重置）。通常来讲许多指标counter本身并没有什么意义，有意义的是counter随时间的变化率如采用rate函数能计算出每秒增长，通常配合各种函数使用

Gauge

瞬时状态，可增可减，侧重于反应系统的当前状态，比如cpu，磁盘，内存容量（这类数值采集多少就是多少，不会一直一个状态），客户端计算主要用于表示一段时间范围内对数据进行采样（通常是请求持续时间或响应大小），并能够对其指定区间以及总数进行统计

Histogram

Histogram统计数据分布情况，如中间值，最大最小值等，比较常用如http_response_time http响应时间等，或者求某些平均响应时间（有些响应快，有些慢请求混合），可以使用H，按照某段时间截取数据

summy

略

promQL常用的一些函数

sum(increase(node_cpu)[1m]) by(instance) 主机1分钟cpu的使用率
node_cpu 是key name
还想筛选，可以使用label{mode='idel'}

rate（）和increase（）都是计算某段增长量，不同的是rate比较精细，increase比较粗略

rate是某一段时间内每秒的增量 ,时间/60s
increase是某一段时间的增量

sum（）把所有东西加和，但是这样太笼统了，比如cpu使用，我们不关心每一核的具体使用量，但是我们把所有机器聚合起来显然也不是我们要的结果，可以使用by，by是按照sum加和的指标，按照某种方式进行拆分，例子是按照主机实例进行拆分，与之相反的without移除指定标签
count（）类似于求和。predict- linear（）可以预测未来变化

prometheus配置文件

prometheus的历史数据存放在/data/prometheus/data里面，如果断电可以从里面恢复数据（命名是一串较长的字符串）
配置文件指标说明

• global: 全局配置（如果有内部单独设定，会覆盖这个参数）
• alerting: 告警插件定义。这里会设定alertmanager这个报警插件。
• rule_files: 告警规则。
  按照设定参数进行扫描加载，用于自定义报警规则，其报警媒介和route路由由alertmanager插件实现。
• scrape_configs:采集配置。配置数据源，包含分组job_name以及具体target。又分为静态配置和服务发现

# my global config
global:
  scrape_interval:     15s # 全局每次数据收集的间隔 Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s #规则扫描时间间隔是15秒，默认不填写是 1分钟 Evaluate rules every 15 seconds. The default is every 1 minute.
  scrape_timeout: 5s    #超时时间 scrape_timeout is set to the global default (10s).
 
# 这里定义和prometheus集成的alertmanager插件，用于监控报警。Alertmanager configuration
alerting:
  alertmanagers:
 - static_configs:
    - targets:
      # - alertmanager:9093
 
#这个主要是用来设置告警规则，基于设定什么指标进行报警（类似触发器trigger）。这里设定好规则以后，prometheus会根据全局global设定的evaluation_interval参数进行扫描加载，规则改动后会自动加载。其报警媒介和route路由由alertmanager插件实现。
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"
  #支持正则
 
#crape_configs配置采集目标endpoints， A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=` to any timeseries scraped from this config.
 - job_name: 'prometheus'
 
    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.
 
    static_configs:
    - targets: ['localhost:9090']

• job_name: 任务目标名，可以理解成分组，每个分组包含具体的target组员。

• scrape_interval: 5s #这里如果单独设定的话，会覆盖global设定的参数，拉取时间间隔为5s

• metrics_path #
  监控项访问的url路径,https://prometheus.21yunwei.com/metrics【通过前端web做了反向代理到后端】

• targets: Endpoint # 监控目标访问地址，[‘service1:9091’]需要在/etc/hosts做域名解析或者local dns server

  说明：上述为静态规则，没有设置自动发现。这种情况下增加主机需要自行修改规则，通过supervisor reload 对应任务，也是缺点：每次静态规则添加都要重启prometheus服务，不利于运维自动化。

prometheus支持服务发现（也是运维最佳实践经常采用的）：

文件服务发现
基于文件的服务发现方式不需要依赖其他平台与第三方服务，用户只需将 要新的target信息以yaml或json文件格式添加到target文件中 ，prometheus会定期从指定文件中读取target信息并更新
好处：
（1）不需要一个一个的手工去添加到主配置文件，只需要提交到要加载目录里边的json或yaml文件就可以了；
（2）方便维护，且不需要每次都重启prometheus服务端。
例子：

- job_name: 'cn-hz-21yunwei-other'
    file_sd_configs:
    - files:
      - file_config/test/host.json

cat host.json  
[
  {
    "targets": [
      "1.1.1.1:9010"
    ],
    "labels": {
      "group": "test1",
      "app": "web",
      "hostname": "test"
    }
  }，
  XXX

后期再有job_name或者target改动的时候，直接修改规则文件即可，不再需要重启prometheus服务守护进程进行重载。
如果要使用pushgateway模块提取监控数据，也是将信息配置在scrape_configs

使用pushgateway模块及自定义监控

pushgateway可以安装在任何机器上，使用这个模块我们可以自定义监控数据，拿到我们想要监控的数据，但是pushgateway的缺点是，所有机器都会先pushgateway模块push数据（export定义一个脚本，在将数据推送过去curl --data-binary），容易造成机器负担过大，一旦宕机，数据将无法推送

# 修改prometheus.yml 加入如下片段 
 - job_name: "custom-memory-pushgateway"
    #honor_labels: true
    static_configs:
    - targets: ["192.168.100.11:9091"]

一个自定义脚本

vim push_memory.sh
#!/bin/bash 
# desc push memory info 

total_memory=$(free  |awk '/Mem/{print $2}')
used_memory=$(free  |awk '/Mem/{print $3}')

job_name="custom_memory"
instance_name="192.168.100.12"

cat <<EOF | curl --data-binary @- http://192.168.100.11:9091/metrics/job/$job_name/instance/$instance_name
#TYPE custom_memory_total  gauge
custom_memory_total $total_memory
#TYPE custom_memory_used  gauge
custom_memory_used $used_memory
EOF

我们监控数据的脚步需要反复执行，可以使用定时任务，但是定时任务最短一分钟，如果我们要求小于一分钟，可以使用sleep 20…
推送URL ：pushgateway默认采用9091端口，路径： /metrics/job/<JOBNAME>{/<LABEL_NAME>/<LABEL_VALUE>}
推送数据：http://192.168.100.11:9091/metrics/job/$ job_name/instance/$instance_name，意思是将数据推送给pushgateway的url，job/$job_name第一个标签，推送到哪一个prometheus.yaml里面定义的job，$job_name/instance第二个标签，推送后显示的机器名叫什么，总而言之

  <JOBNAME> 是必填项，为 job 标签值，后边可以跟任意数量的标签对，一般我们会添加一个
instance/<INSTANCE_NAME> 实例名称标签，来方便区分各个指标。