prometheus 监控测试服务器集群

Posted 2021-02-28 杭州铁锤

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了prometheus 监控测试服务器集群相关的知识，希望对你有一定的参考价值。

公司有几台测试服务器,由于公司运维也帮忙去做服务器报警,但是由于测试服务器本来性能和线上机器硬件就不一样,所以让运维老师去掉了测试服务器报警,我们自己使用prometheus监控几台测试服务器,当出现故障的时候把报警数据发送到企业微信中.

prometheus介绍

Prometheus（普罗米修斯）是一套开源的监控&报警&时间序列数据库的组合，起始是由SoundCloud公司开发的。随着发展，越来越多公司和组织接受采用Prometheus，社会也十分活跃，他们便将它独立成开源项目，并且有公司来运作。Google SRE的书内也曾提到跟他们BorgMon监控系统相似的实现是Prometheus。现在最常见的Kubernetes容器管理系统中，通常会搭配Prometheus进行监控。

Prometheus基本原理是通过HTTP协议周期性抓取被监控组件的状态，这样做的好处是任意组件只要提供HTTP接口就可以接入监控系统，不需要任何SDK或者其他的集成过程。这样做非常适合虚拟化环境比如VM或者Docker 。

Prometheus应该是为数不多的适合Docker、Mesos、Kubernetes环境的监控系统之一。

输出被监控组件信息的HTTP接口被叫做exporter 。目前互联网公司常用的组件大部分都有exporter可以直接使用，比如Varnish、Haproxy、nginx、mysql、Linux 系统信息 (包括磁盘、内存、CPU、网络等等)，具体支持的源看：https://github.com/prometheus。

与其他监控系统相比，Prometheus的主要特点是：

一个多维数据模型（时间序列由指标名称定义和设置键/值尺寸）。
非常高效的存储，平均一个采样数据占~3.5bytes左右，320万的时间序列，每30秒采样，保持60天，消耗磁盘大概228G。
一种灵活的查询语言。
不依赖分布式存储，单个服务器节点。
时间集合通过HTTP上的PULL模型进行。
通过中间网关支持推送时间。
通过服务发现或静态配置发现目标。
多种模式的图形和仪表板支持。

prometheus架构概览

它的服务过程是这样的Prometheus daemon负责定时去目标上抓取metrics(指标) 数据，每个抓取目标需要暴露一个http服务的接口给它定时抓取。

Prometheus

支持通过配置文件、文本文件、zookeeper、Consul、DNS SRV lookup等方式指定抓取目标。支持很多方式的图表可视化，例如十分精美的Grafana，自带的Promdash，以及自身提供的模版引擎等等，还提供HTTP API的查询方式，自定义所需要的输出。

Alertmanager

是独立于Prometheus的一个组件，可以支持Prometheus的查询语句，提供十分灵活的报警方式。

PushGateway：这个组件是支持Client主动推送metrics到PushGateway，而Prometheus只是定时去Gateway上抓取数据。

如果有使用过statsd的用户，则会觉得这十分相似，只是statsd是直接发送给服务器端，而Prometheus主要还是靠进程主动去抓取。

prometheus的数据模型

Prometheus从根本上所有的存储都是按时间序列去实现的，相同的metrics(指标名称) 和label(一个或多个标签) 组成一条时间序列，不同的label表示不同的时间序列。为了支持一些查询，有时还会临时产生一些时间序列存储。

metrics name&label指标名称和标签

每条时间序列是由唯一的”指标名称”和一组”标签（key=value）”的形式组成。

指标名称：一般是给监测对像起一名字，例如http_requests_total这样，它有一些命名规则，可以包字母数字之类的的。通常是以应用名称开头监测对像数值类型单位这样。例如：push_total、userlogin_mysql_duration_seconds、app_memory_usage_bytes。

标签：就是对一条时间序列不同维度的识别了，例如一个http请求用的是POST还是GET，它的endpoint是什么，这时候就要用标签去标记了。最终形成的标识便是这样了：http_requests_total{method=”POST”,endpoint=”/api/tracks”}。

记住，针对http_requests_total这个metrics name无论是增加标签还是删除标签都会形成一条新的时间序列。

查询语句就可以跟据上面标签的组合来查询聚合结果了。

如果以传统数据库的理解来看这条语句，则可以考虑http_requests_total是表名，标签是字段，而timestamp是主键，还有一个float64字段是值了。（Prometheus里面所有值都是按float64存储）。

prometheus四种数据类型

Counter

Counter用于累计值，例如记录请求次数、任务完成数、错误发生次数。一直增加，不会减少。重启进程后，会被重置。

例如：http_response_total{method=”GET”,endpoint=”/api/tracks”} 100，10秒后抓取http_response_total{method=”GET”,endpoint=”/api/tracks”} 100。

Gauge

Gauge常规数值，例如温度变化、内存使用变化。可变大，可变小。重启进程后，会被重置。

例如： memory_usage_bytes{host=”master-01″} 100 < 抓取值、memory_usage_bytes{host=”master-01″} 30、memory_usage_bytes{host=”master-01″} 50、memory_usage_bytes{host=”master-01″} 80 < 抓取值。

Histogram

Histogram（直方图）可以理解为柱状图的意思，常用于跟踪事件发生的规模，例如：请求耗时、响应大小。它特别之处是可以对记录的内容进行分组，提供count和sum全部值的功能。

例如：{小于10=5次，小于20=1次，小于30=2次}，count=7次，sum=7次的求和值。

Summary

Summary和Histogram十分相似，常用于跟踪事件发生的规模，例如：请求耗时、响应大小。同样提供 count 和 sum 全部值的功能。

例如：count=7次，sum=7次的值求值。

它提供一个quantiles的功能，可以按%比划分跟踪的结果。例如：quantile取值0.95，表示取采样值里面的95%数据。

依赖镜像

docker pull prom/node-exporter
docker pull prom/prometheus
docker pull grafana/grafana

部署prometheus

配置

mkdir /opt/prometheus
cd /opt/prometheus/
vim prometheus.yml

yml内容

yml中配置了一个prometheus自己和一台linux监控

global:
  scrape_interval:     60s
  evaluation_interval: 60s

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: [\'localhost:9090\']
        labels:
          instance: prometheus

  - job_name: linux
    static_configs:
      - targets: [\'192.168.91.132:9100\']
        labels:
          instance: localhost

启动prometheus

启动的时候挂载了prometheus.yml文件

docker run  -d \\
  -p 9090:9090 \\
  -v /Users/qamac/Documents/script/docker_prometheus/prometheus.yml:/etc/prometheus/prometheus.yml  \\
  prom/prometheus

查看目标机器

http://192.168.143.242:9090/targets

如果出现status是down的情况说明没有连接成功,需要检查对应服务是否启动成功及对应端口

出现下图,说明配置成功

查看采集metrics

点击下面这个接口,会跳转到metrics页面,通过轮训的方式更新数据

http://192.168.143.242:9090/metrics

部署node-exporter

node-exporter启动后会在服务器上启动一个进程采集数据,prometheus会每隔几秒通过接口获取服务器的metrics数据.

注意本地mac启动不能加--net="host"

docker run -d -p 9100:9100 \\
  -v "/proc:/host/proc:ro" \\
  -v "/sys:/host/sys:ro" \\
  -v "/:/rootfs:ro" \\
  --net="host" \\
  prom/node-exporter

部署grafana

启动grafana

docker run -d -p 3000:3000 grafana

grafana地址

登录账号密码:admin/admin

http://192.168.143.242:3000

grafana配置

prometheus配置

配置prometheus数据源

grafana模版

导入dashboards模版

https://grafana.com/grafana/dashboards/8919

展示

配置多个机器监控,需要在每一台机器部署node-exporter.

配置告警规则

报警规则配置

rules.yml中配置监控服务的内存、cpu、磁盘告警策略

Server: \'{{$labels.instance}}\'
    summary: "{{$labels.instance}}: High Memory usage detected"
    explain: "内存使用量超过90%，目前剩余量为：{{ $value }}M"
    description: "{{$labels.instance}}: Memory usage is above 90% (current value is: {{ $value }})"

- alert: CPU报警
  expr: (100 - (avg by (instance)(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 90
  for: 2m
  labels:
    team: node
  annotations:
    Alert_type: CPU报警
    Server: \'{{$labels.instance}}\'
    explain: "CPU使用量超过90%，目前剩余量为：{{ $value }}"
    summary: "{{$labels.instance}}: High CPU usage detected"
    description: "{{$labels.instance}}: CPU usage is above 90% (current value is: {{ $value }})"

- alert: 磁盘报警
  expr: 100.0 - 100 * ((node_filesystem_avail_bytes{mountpoint=~"/", device!="rootfs"} / 1000 / 1000 ) / (node_filesystem_size_bytes{mountpoint=~"/", device!="rootfs"} / 1024 / 1024)) > 90
  for: 2m
  labels:
    team: node
  annotations:
    Alert_type: 磁盘报警
    Server: \'{{$labels.instance}}\'
    explain: "磁盘使用量超过90%，目前剩余量为：{{ $value }}G"
    summary: "{{$labels.instance}}: High Disk usage detected"
    description: "{{$labels.instance}}: Disk usage is above 90% (current value is: {{ $value }})"

- alert: 服务器下线告警
    expr: up == 0
    for: 1m
    labels:
      user: admin
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minutes."

加载配置

prometheus.yml加载rule_files

# Alertmanager configuration
alerting:
   alertmanagers:
     - static_configs:
         - targets: ["192.168.1.232:9093"]
               # - alertmanager:9093


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

启动prometheus

docker run -d -p 9090:9090 --name=prometheus1 \\
-v /Users/qamac/Documents/script/docker_prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \\
-v /Users/qamac/Documents/script/docker_prometheus/memory_over.yml:/etc/prometheus/rules.yml \\
prom/prometheus

部署alertmanager

邮箱配置

可以通过邮件的形式发送告警邮件

global:
  smtp_smarthost: \'smtp.126.com:25\'　　#163服务器
  smtp_from: \'xxxxx@126.com\'　　　　　　　　#发邮件的邮箱
  smtp_auth_username: \'xxxxx@126.com\'　　#发邮件的邮箱用户名，也就是你的邮箱
  smtp_auth_password: \'xxxxx\'　　　　　　　　#发邮件的邮箱密码

route:
  group_by: [\'alertname\']

  repeat_interval: 1h

  receiver: live-monitoring

receivers:
- name: \'live-monitoring\'
  email_configs:
  - to: \'xxxxx@xxxxx.com\'　　　　　　　　#收邮件的邮箱

webhook配置

因为我司用企业微信比较多,再加上平时也不怎么看邮件.
所以想自定义一个webhook地址,把告警发到企业微信群中.

global:
  resolve_timeout: 5m

route:
  group_by: [\'alertname\']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: \'web.hook\'
receivers:
- name: \'web.hook\'
  webhook_configs:
  - url: \'http://127.0.0.1:5000/send\'
inhibit_rules:
  - source_match:
      severity: \'critical\'
    target_match:
      severity: \'warning\'
    equal: [\'alertname\', \'dev\', \'instance\']
~

启动alertmanager

docker run -d -p 9093:9093 -v /data/docker_alertmanager/simple.yml/:/etc/alertmanager/config.yml --name alertmanager1 prom/alertmanager

alertmanager的web页面

http://192.168.1.232:9093/#/status

下图是配置的告警方式

prometheus中报警模块

http://192.168.143.242:9090/alerts

访问上面的地址,可以看到已经加载了告警规则

报警的几个状态

Inactive: 既不是pending也不是firing的时候状态变为inactive
Pending:警报被激活，但是低于配置的持续时间。这里的持续时间即rule里的FOR字段设置的时间.改状态下不发送报警.
Firing: 警报已被激活，而且超出设置的持续时间。该状态下发送报警.

如下图的for字段是配置2分钟循环,第一次触发规则是Pending状态,如果超过2分钟就变成了Firing状态,才发送告警

webhook服务

我们需要一个webhook服务接受报警的消息然后在发给企业微信群中.

这里我使用python flask框架开发web服务.

报警消息的格式

{
    "status": "firing",
    "labels": {
        "instance": "localhost",
        "job": "linux",
        "user": "admin",
        "alertname": "NodeMemoryUsage"
    },
    "endsAt": "2020-01-06T08:38:59.334190464Z",
    "generatorURL": "http://13b226ded726:9090/graph?g0.expr=%28node_memory_MemTotal_bytes+-+%28node_memory_MemFree_bytes+%2B+node_memory_Buffers_bytes+%2B+node_memory_Cached_bytes%29%29+%2F+node_memory_MemTotal_bytes+%2A+100+%3E+5&g0.tab=1",
    "startsAt ": "2020-01-05T15:33:59.334190464Z",
    "annotations": {
        "description": "localhost: Memory usage is above 80% (current value is:22.168394749407362)",
        "summary": "localhost: High Memory usage detected"
    }
}

定义send接口

解析响应数据

dockerfile

这里使用docker把服务打包成镜像部署

FROM python3.7
RUN pip3 install requests && pip3 install flask && pip3 install logzero && pip3 install gunicorn && pip3 install flask_script
EXPOSE 5000

ENTRYPOINT ["/run.sh"]

企业微信报警

参考

基于docker 搭建Prometheus+Grafana

https://www.cnblogs.com/xiao987334176/p/9930517.html

【集群监控】Docker上部署Prometheus+Alertmanager+Grafana实现集群监控

https://www.cnblogs.com/caizhenghui/p/9184082.html

部署AlertManager

https://yunlzheng.gitbook.io/prometheus-book/parti-prometheus-ji-chu/alert/install-alert-manager

prometheus alertmanager webhook 配置教程

https://blog.csdn.net/shida_csdn/article/details/81980021

Alertmanager 部署配置

https://www.cnblogs.com/winstom/p/11940570.html#测试触发告警

https://yunlzheng.gitbook.io/prometheus-book/parti-prometheus-ji-chu/quickstart/why-monitor

监控指标以及prometheus规则-不断完善中

https://blog.51cto.com/1000682/2374417

BAT大厂都在用的Docker。学会这三招，面试、工作轻松hold住

https://mp.weixin.qq.com/s/DpC3mC8XqKgrneW1HwH4Bw

以上是关于prometheus 监控测试服务器集群的主要内容，如果未能解决你的问题，请参考以下文章

（二十）从零开始搭建k8s集群——使用KubeSphere管理平台搭建一套微服务的压力测试性能监控平台（Grafana8.5.2+Prometheus v2.35.0+Jmeter5.4.1）

云原生系列之使用prometheus监控redis集群实战

Linux集群监控部署: prometheus 普罗米修斯 + Grafana（超详细）

K8S部署Prometheus+Grafana监控集群

Clickhouse 集群监控(Prometheus+Grafana)