Prometheus监控系列最佳实践

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Prometheus监控系列最佳实践相关的知识,希望对你有一定的参考价值。

Prometheus是继kubernetes第二个从CNCF中毕业的项目,个人也是非常的喜欢这款通过数据指标发现和预测告警的开源监控平台,官方的话就不多说了,根据官网的介绍有以下功能,但是有些简短的概括了你也不一定知道,所以加了一些个人的白话
官方截图

Prometheus之白话文一段

  • 实现高纬度的数据模型
    • 时间序列数据通过 metric 名和键值对来区分,这里你可以区分多(隔离)环境的监控指标。
    • 所有的 metrics 都可以设置任意的多维标签,可以自定义添加多个,比如这个服务的监控属于哪个团队的。
    • 数据模型更随意,不需要刻意设置为以点分隔的字符串;
    • 可以对数据模型进行聚合,切割和切片操作;
    • 支持双精度浮点类型,标签可以设为全 unicode;
      看到这可能你还是不知道啥意思,那就等接下来用到的时候就恍然大悟了...
  • 强大的PromQL语句
    • 支持查询语句,可以通过PromSQL进行数值之间的比较
    • 可以通过PromSQL内嵌的函数计算指标的变化,比如平均值,增长率等等...
  • 出色的可视化
    • 个人觉得一点都不咋出色,哈哈,还是结合Grafana使用吧,毕竟人家专业啊~
  • 高效的存储
    • 可以根据需求设置指标数据的存储天数,也可以持久化存储,比如通过remotestorageadapter
  • 使用简单
    • 部署简单
    • 支持动态发现
    • 支持热加载
    • 支持配置文件格式检查
  • 精准的告警
    • 告警指的不是Prometheus,而是Alertmanager
    • 可以设置沉默时间,可以对告警进行分组,可以对告警进行匹配从而决定告警邮件发给哪些负责人
    • 支持多种告警媒介,比如常用的slack,企业微信,钉钉,邮件还有一些国外常用的,你也可以自己定制;
  • 支持多语言客户端库
    • 对常见的编程语言都是支持的
  • 拥有丰富的exporter生态
    • 完美的支持常见的中间件,数据库,主机等等监控
    • 还有一些有时候会被忽略的监控对象比如:证书有效期,域名有效期等等
    • 比如还有jmx,snmp,vmi等等exporter,这些你可以在github.com搜索prometheus exporter看到

上面整那么多的意思就是除了Zabbix,Prometheus也是没有什么不能监控的,甚至做的更简单,更人性化,但是这里不会介绍太多Prometheus的指标类型,网上很多,就不想整了,大家可以看一下https://yunlzheng.gitbook.io/prometheus-book/introduction写的算是很走心了,大部分还是要自己实践中琢磨到底如何做。

Prometheus之少不了的部署篇

ServerName ServerVersion Functions 配置文件
Promethues v2.12.0 数据处理 prometheus.yaml
influxdb v1.7 监控指标的持久化存储 influxdb.conf
remotestorageadapter latest 数据远程转存适配器
alertmanager v0.19.0 告警管理 config.yml
pushgateway v0.10.0 实现push模式推送指标
grafana v6.0.0 数据的可视化展示平台 grafana.ini
cadvisor v0.32.0 分析正在运行容器的指标和性能数据
Docker v18.03.0-ce 容器运行时
docker-compose v1.11.2 容器编排工具

但是你可以直接拿来使用和测试,使用docker-compose管理的配置清单,对于还没有k8s环境的人来说,也算是福音了。docker-compose-monitor-platform.yml:

version: ‘3.4‘
services:
  influxdb:
    image: influxdb:1.7
    command: -config /etc/influxdb/influxdb.conf
    container_name: influxdb
    ports:
      - "8086:8086"
    restart: always
    volumes:
      - /data/influxdb:/var/lib/influxdb
    environment:
      - INFLUXDB_DB=prometheus
      - INFLUXDB_ADMIN_ENABLED=true
      - INFLUXDB_ADMIN_USER=admin
      - INFLUXDB_ADMIN_PASSWORD=admin
      - INFLUXDB_USER=prom
      - INFLUXDB_USER_PASSWORD=prom
    deploy:
      resources:
        limits:
          cpus: ‘0.5‘
          memory: 300M
        reservations:
          cpus: ‘0.25‘
          memory: 200M
  remotestorageadapter:
    image: gavind/prometheus-remote-storage-adapter:1.0
    container_name: prometheus-remote-storage-adapter
    ports:
      - 9201:9201
    environment:
      - INFLUXDB_PW=prom
    restart: always
    command: [‘-influxdb-url=http://192.168.0.112:8086‘, ‘-influxdb.database=prometheus‘, ‘-influxdb.retention-policy=autogen‘,‘-influxdb.username=prom‘]
  alertmanager:
    image: prom/alertmanager:latest
    container_name: alertmanager
    ports:
      - "9093:9093"
    restart: always
    volumes:
      - /opt/alertmanager/config.yml:/etc/alertmanager/config.yml
    command: [‘--config.file=/etc/alertmanager/config.yml‘]
  prometheus:
    image: prom/prometheus:v2.12.0
    container_name: prometheus
    restart: always
    volumes:
      - /opt/prometheus/conf/:/etc/prometheus/
    ports:
      - "9090:9090"
    command: [‘--web.external-url=http://192.168.0.112:9090‘,‘--config.file=/etc/prometheus/prometheus.yml‘,‘--storage.tsdb.path=/prometheus/data‘,‘--web.enable-lifecycle‘,‘--web.enable-admin-api‘,‘--web.console.templates=/prometheus/consoletest‘,‘--web.page-title=Prometheues监控平台‘,]
  pushgateway:
    container_name: pushgateway
    image: prom/pushgateway:v1.0.0
    restart: always
    ports:
      - "9091:9091"
    command: [‘--persistence.file="/pushgateway/data"‘,‘--persistence.interval=5m‘,‘--web.external-url=http://192.168.0.112:9091‘,‘--web.enable-admin-api‘,‘--log.format=json‘,‘--log.level=info‘,‘--web.enable-lifecycle‘]
    deploy:
      resources:
        limits:
          cpus: ‘0.5‘
          memory: 300M
        reservations:
          cpus: ‘0.25‘
          memory: 200M
  grafana:
    container_name: grafana
    image: grafana/grafana:6.4.0
    restart: always
    ports:
      - "3000:3000"
    volumes:
      - /data/grafana/grafana.ini:/etc/grafana/grafana.ini
      - /data/grafana:/var/lib/grafana
    deploy:
      resources:
        limits:
          cpus: ‘0.5‘
          memory: 300M
        reservations:
          cpus: ‘0.25‘
          memory: 200M
#    user: "104"
  cadvisor:
    image: google/cadvisor:latest
    container_name: cadvisor
    restart: always
    ports:
      - 8080:8080
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:rw
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro

要注意几点:

  1. docker-compose-monitor-platform.yml中需要的目录,你需要创建出来
  2. 配置文件格式我想你是有方法找到的,比如docker cp,比如去官网或者github找
  3. 下面是几个主要的配置文件,Alertmanager和Prometheus的配置文件

Prometheus之你可以自定义修改的配置文件

prometheus.yml

global:
  scrape_interval:     2m # 设置采集数据指标的时间为2m, 默认是每1分钟采集一次,采集的频率会影响存储和服务器性能
  evaluation_interval: 15s # 15秒钟评估一下告警规则,默认是每1分钟评估一次
  external_labels:
      monitor: ‘Prometheues监控平台‘
rule_files:
  - "prom.rules"

alerting:
  alertmanagers:
  - scheme: http
    static_configs:
    - targets: [‘192.168.0.112:9093‘]
scrape_configs:
  - job_name: ‘qa-prometheus‘
    # 默认的metrics_path标签值为: ‘/metrics‘
    # 默认的scheme值为: ‘http‘.
    static_configs:
      - targets: [‘192.168.0.112:9090‘]
  - job_name: pushgateway
    static_configs:
      - targets: [‘192.168.0.112:9091‘]
        labels:
          instances: pushgateway
          instanceserver: 192.168.0.112
          honor_labels: true

config.yaml

global:
  resolve_timeout: 1m #该参数定义了当Alertmanager持续多长时间未接收到告警后标记告警状态为resolved(已解决),该参数的定义可能会影响到告警恢复通知的接收时间,默认值是5分钟
  smtp_smarthost: smtp.163.net:465 # 邮箱服务器,注意需要加上端口
  smtp_from: xxx # 发送者邮箱
  smtp_auth_username: xxx # 使用发送者邮箱进行验证时使用的用户名
  smtp_auth_password: xxx # 使用发送者邮箱进行验证时使用的密码(客户端授权码)
  smtp_require_tls: false # 是否需要进行tls验证
  slack_api_url: ‘xxx‘

templates:
  - ‘/etc/alertmanager/template/*.tmpl‘
# 所有报警信息进入后的根路由,用来设置报警的分发策略
route: # 主要定义了告警的路由匹配规则,以及Alertmanager需要将匹配到的告警发送给哪一个receiver,【因此这里详细设置就能灵活实现通过匹配标签过滤告警发送到对应的开发owner】
  # 这里的标签列表是接收到报警信息后的重新分组标签,例如,接收到的报警信息里面有许多具有 cluster=A 和 alertname=LatncyHigh 这样的标签的报警信息将会批量被聚合到一个分组里面
  group_by: [‘alertname‘,‘cluster‘]
  # 当一个新的报警分组被创建后,需要等待至少group_wait时间来初始化通知,这种方式可以确保您能有足够的时间为同一分组来获取多个警报,然后一起触发这个报警信息。
  group_wait: 10s
  # 当第一个报警发送后,等待‘group_interval‘时间来发送新的一组报警信息。
  group_interval: 5m
  # 如果一个报警信息已经发送成功了,等待‘repeat_interval‘时间来重新发送他们
  repeat_interval: 4h
  # 默认的receiver:如果一个报警没有被一个route匹配,则发送给默认的接收器
  receiver: default
  # 上面所有的属性都由所有子路由继承,并且可以在每个子路由上进行覆盖。
  routes:
  - receiver: ‘default‘
    group_wait: 10s
    continue: true
  - receiver: ‘slack‘
    group_wait: 10s
    match:
      env: yourenv
    continue: true
inhibit_rules:
- source_match:
   env: yourenv
  target_match:
   env: yourenv
  equal: [‘alertname‘, ‘cluster‘]
receivers:
- name: ‘default‘
  email_configs:
  - to: ‘xxx‘ # 发送给谁
    send_resolved: true

到这里,Prometheus监控平台就基本上部署完成了,接下来就是要看看自己监控哪些服务了,根据自己的监控对象接入到Prometheus中
技术图片

以上是关于Prometheus监控系列最佳实践的主要内容,如果未能解决你的问题,请参考以下文章

最佳实践|从Producer 到 Consumer,如何有效监控 Kafka

开源监控系统 Prometheus 最佳实践

云上Prometheus监控运维最佳实践

Prometheus监控的最佳实践——关于监控的3项关键指标

Prometheus监控的最佳实践——关于监控的3项关键指标

在微服务架构下基于 Prometheus 构建一体化监控平台的最佳实践