prometheus 监控测试服务器集群

发表于:2020-2-18 10:34

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:xinxi    来源:网络

分享:
  背景
  公司有几台测试服务器,由于公司运维也帮忙去做服务器报警,但是由于测试服务器本来性能和线上机器硬件就不一样,所以让运维老师去掉了测试服务器报警,我们自己使用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、MySQLLinux 系统信息 (包括磁盘、内存、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"]
  企业微信报警

      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号