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中

原文地址：https://blog.51cto.com/bkmaster/2480687

时间： 2024-10-09 23:02:14

Prometheus监控系列最佳实践的相关文章

Zabbix企业级分布式监控系统最佳实践

[下载地址:https://pan.baidu.com/s/1VXBV7C3ULcwbdRtCbQ0xoQ ] <Zabbix企业级分布式监控系统>从运维(OPS)角度对Zabbix的各项功能进行了详细介绍,以自动化运维视角为出发点,对Zabbix的安装配置.自动化功能.监控告警.性能调优.Zabbix API.Zabbix协议.RPM安装包定制,结合saltstack实现自动化配置管理等内容进行了全方位的深入剖析.<Zabbix企业级分布式监控系统>分为初级内容.中级内容.高级内

京东前端：PhantomJS 和NodeJS在网站前端监控平台的最佳实践

1. 为什么需要一个前端监控系统 通常在一个大型的 Web 项目中有很多监控系统,比如后端的服务 API 监控,接口存活.调用.延迟等监控,这些一般都用来监控后台接口数据层面的信息.而且对于大型网站系统来说,从后端服务到前台展示会有很多层:内网 VIP.CDN 等. 但是这些监控并不能准确地反应用户看到的前端页面状态,比如:页面第三方系统数据调用失败,模块加载异常,数据不正确,空白开天窗等. 相关厂商内容 Native动态化最新技术解析 不可错过的智能时代的大前端 性能优化最佳实践经验谈 百度技

可视化最佳实践系列白皮书即将发布

最近一段时间到西北流浪了两周,最近在忙着跟FusionCharts原厂整理可视化最佳实践系列白皮书.这些白皮书估计一两周内就能跟大家见面,敬请期待. 整理的过程也是学习的过程,本以为在FusionCharts中浸淫了两年,对可视化这部分已经有了相当的认识,结果却发现真的是学无止境.与诸君共勉. 可视化最佳实践系列白皮书即将发布,布布扣,bubuko.com

基于ITIL的SCOM监控最佳实践

1.  按照系统类别进行监控 很多朋友在使用SCOM进行监控的时候,往往只是导入管理包,推送代理,并不会思考很多,那么在这种情况下,SCOM在进行监控的时候都是基于缺省的类对象进行监控,比如说Windows计算机,一次就只能以一台Windows计算机的维度去监控,点击一台Windows计算机,下面会是关于这台计算机的进一步信息,比如这台计算机上面的磁盘,CPU,内存,数据库状态. 但是,这种监视方式太狭隘了,而且不便于整体统计,如果企业有很多业务系统呢,每个业务系统下面有很多机器,当企业要统计业

OPEN(SAP) UI5 学习入门系列之二： 最佳实践练习之一

这篇博文难产了很久,原来是打算一周更新一篇的,上周原计划写MVC,但是写了一半,发现带入了太多的细节,不太符合这个入门系列的主题. 当我们学习一个新的技能的时候,如果一开始就面对大量的细节,很容易陷入其中而只见树木不见森林,所以最后我想我们还是先按照开发文档的节奏,一起来做UI5的最佳实践练习.在练习中对常用的一些控件以及API有一个直观的感受,如果需要细节的信息再去查文档. 这个最佳实践练习的子系列又会分为若干篇,但是不会完全按照Tutorial里面的章节来分,因为我希望每一篇都是都是一个完整

阿里云 CDN HTTPS 最佳实践系列——动态证书（一）

背景 了解阿里云 CDN 架构的朋友应该知道,阿里云 CDN 7层的接入组件是 Tengine,我们知道 Tengine 原生是支持 SSL 的,只需要在配置文件中配置证书和私钥即可.在 CDN HTTPS 产品化以前,要开通 HTTPS 的域名需要把证书私钥给我们,我们在 Tengine 静态配置中配置,然后再同步到所有 CDN 边缘节点,显然这种方式在越来越多的域名开通 HTTPS 后,Tengine 静态配置文件会越来越大,难以管理,同时也会导致 Tengine reload 变得很慢,这

Hadoop MapReduce开发最佳实践（上篇）

body{ font-family: "Microsoft YaHei UI","Microsoft YaHei",SimSun,"Segoe UI",Tahoma,Helvetica,Sans-Serif,"Microsoft YaHei", Georgia,Helvetica,Arial,sans-serif,宋体, PMingLiU,serif; font-size: 10.5pt; line-height: 1.5;}

何俊谈阿里巴巴前端性能优化最佳实践-笔记

网站页面前端优化对网站核心页面基于Wise load的原则做定点性能优化,减少HTTP请求,减少DNS请求时间,减少页面DOM的数量,做一些图片.JS压缩等.减少HTTP请求方案:阿里开发了自动合并CSS和JS静态文件的框架,对于减少页面DNS数方面采用前端延迟加载框架,主要负责页面加载时只加载首屏,用户滚动页面时才加载二屏或三屏,这样对网站的性能包括流量都是很大的提升和节约. Web I/O(高并发)方面的优化,使用高性能Web服务器,另外在冬天页面处理上,尽可能地减少冬天页面所占比例,采用一

用HAWQ轻松取代传统数据仓库（十七） —— 最佳实践

一.HAWQ参数配置最佳实践 (原文地址:http://hawq.incubator.apache.org/docs/userguide/2.1.0.0-incubating/bestpractices/config_hawq_bestpractices.html)        在$GPHOME/etc/hawq-site.xml文件中维护HAWQ的配置参数.该文件存在于所有HAWQ实例上,并可以通过Ambari或使用HAWQ命令行接口进行修改.使用一致的策略(Ambari或命令行接口)维护h