Prometheus
Prometheues概述
Prometheus是什么
prometheus最初是在SoundCloud上构建的监控系统,在2016年加入CNCF,成为继Kubernetes之后的第二个托管项目
特点:
- 多维数据模型:由度量名称和键值对标识的时间序列数据
- PromSQL:一种灵活的查询语言,可以利用多维数据完成复杂查询
- 不依赖分布式存储,单个服务器节点可直接工作
- 基于HTTP方式采集时间序列数据(主动get去查询数据)
- 推送时间序列数据通过PushGateway组件支持(短期任务如定时任务,需要定时任务直接push数据过来)
- 通过服务发现或静态配置发现目标
- 多种图形模式及仪表盘支持(grafana)
Prometheus组成及架构
- Promethues Server:收集指标和存储时间序列数据,并提供查询接口
- Retrieval:检索拉去到的数据分发给TSDB进行存储。
- TSDB:当新拉取的数据大于配置内存缓存区的时候,Prometheus会将数据持久化到磁盘(HHD/SSD)(如果使用 remote storage 将持久化到云端)。
- HTTP server:用于接受外界的HTTP请求。
- Client Libraries:用于对接Prometheues Server,可以查询和上报数据
- Push Gateway :允许短暂和批量作业将其指标暴露给普罗米修斯。由于这些类型的作业可能存在时间不足而被删除,因此他们可以将其指标推送到Pushgateway。然后,Pushgateway将这些指标暴露给普罗米修斯,主要用于业务数据汇报等。
- Exporters :采集已有的第三方服务监控指标并暴露metrics
- Alertmanager:告警通知
- WebUI:简单的web控制台
数据模型
Prometheus将所有数据存储为时间序列:相同时序(相同的名字和标签)。每个时间序列都由度量标准名称和一组键值对(标签kv的形式)
时间序列格式:
<metric name\>{<label name\>=<label value\>,...}
如:api_http_requests_total{method="POST",handler="/message"}
指标类型(client library需要使用)
-
Counter
Counter 表示收集的数据是按照某个趋势(增加/减少)一直变化的,我们往往用它记录服务请求总量、错误总数等。
例如 Prometheus server 中 http_requests_total, 表示 Prometheus 处理的 http 请求总数,我们可以使用 delta, 很容易得到任意区间数据的增量 -
Gauge
Gauge 表示搜集的数据是一个瞬时的值,与时间没有关系,可以任意变高变低,往往可以用来记录内存使用率、磁盘使用率等。
例如 Prometheus server 中 go_goroutines, 表示 Prometheus 当前 goroutines 的数量。 -
Histogram
主要用于表示一段时间范围内对数据进行采样(通常是请求持续时间或响应大小),
并能够对其指定区间以及总数进行统计,通常它采集的数据展示为直方图。Histogram 由 <basename>_bucket{le="<upper inclusive bound>"}, <basename>_bucket{le="+Inf"}, <basename>_sum,<basename>_count组成, 例如 Prometheus server中prometheus_local_storage_series_chunks_persisted, 表示 Prometheus 中每个时序需要存储的 chunks 数量,我们可以用它计算待持久化的数据的分位数。 1234
-
Summary
主要用于表示一段时间内数据采样结果(通常是请求持续时间或响
应大小),它直接存储了 quantile 数据,而不是根据统计区间计算出来的。Summary 和 Histogram 类似,由 <basename>{quantile="<φ>"},<basename>_sum, <basename>_count 组成, 例如 Prometheus server 中 prometheus_target_interval_length_seconds。 123
-
Histogram vs Summary
都包含 <basename>_sum,<basename>_count Histogram 需要通过 <basename>_bucket 计算 quantile, 而 Summary 直接存储了 quantile 的值。
实例和作业
Prometheus 中,将任意一个独立的数据源(target)称之为实例(instance)。包含相同类型的实例的集合称之为作业(job)。
实例:如一台linux服务器
作业:多台linux服务器
scrape_config:
- job_name: 'prometheues'
static_configs:
- targets:['localhost:9200']
- job_name: 'node'
static_configs:
- targets:['192.168.1.10:909 0']
Prometheus部署
二进制部署
官网下载
配置systemd启动prometheus
docker部署
配置文件:
global:
scrape_interval: 15s # By default, scrape targets every 15 seconds.
# Attach these labels to any time series or alerts when communicating with
# external systems (federation, remote storage, Alertmanager).
external_labels:
monitor: 'codelab-monitor'
# 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=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'
# Override the global default and scrape targets from this job every 5 seconds.
scrape_interval: 5s
static_configs:
- targets: ['localhost:9090']
启动:
docker run \
-p 9090:9090 \
-v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \
prom/prometheus
检查配置
./promtool config file prometheus.yml
配置文件与核心功能
Prometheus配置文件热更新
1. 添加--web.enable-lifecycle参数
docker run \
-d -p 9090:9090 \
-v /usr/local/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \
prom/prometheus --restart --config.file=/etc/prometheus/prometheus.yml --web.enable-lifecycle
2. 发送http请求:curl -v -X POST http://127.0.0.1:9090/-/reload
注意:使用docker来实现热更新有问题,挂载的文件只有第一次生效,后面修改后都不生效
使用二进制的OK
替换标签
relabel_configs:
- action: replace
source_labels: ['job']
regex: (.*)
replacement: $1
target_label: ibc
job标签为默认标签,会重新复制一个ibc的标签
服务发现
-
file_sd_configs
# prometheus.yml - job_name: '222' file_sd_configs: - files: ['/usr/local/prometheus/sd_config/*.yml'] refresh_interval: 5s # sd_config/test.yml - targets: ['localhost:9090','gaodongfei.com:9090'] labels: ibc: asd
监控案例
监控Linux服务器
安装Node Exporter
- 二进制安装
- docker安装
计算CPU使用率
100 - irate(node_cpu_seconds_total{instance="gaodongfei.com:9100",job="job",mode="idle"}[5m]) * 100
计算内存使用率
100 - (node_memory_MemFree_bytes + node_memory_Cached_bytes + node_memory_Buffers_bytes) /node_memory_MemTotal_bytes * 100
磁盘使用率
100 - node_filesystem_free_bytes{mountpoint="/"}/node_filesystem_size_bytes * 100
服务状态
node_exporter --collector.systemd --collector.systemd.unit-whitelist=(docker|sshd).service
Grafana
9276 导入Linux基础监控
193 导入docker
151导入mysql
Alertmanager
- 部署Alertmanager
- 配置Prometheus与Alertmanager通信
- 在Prometheus中创建告警规则
alertmanager.yml
global:
resolve_timeout: 5m
smtp_smarthost: 'smtp.qq.com:465'
smtp_from: '1076800796@qq.com'
smtp_auth_username: '1076800796@qq.com'
# qq邮箱授权码
smtp_auth_password: 'mxhqgcynzbarhgbb'
smtp_require_tls: false
smtp_hello: 'qq.com'
route:
group_by: ['alertname'] # 根据标签进行分组
group_wait: 10s # 发送告警等待时间
group_interval: 10s # 发送告警间隔时间
repeat_interval: 20m # 重复告警发送时间
receiver: 'email'
receivers:
- name: 'email'
email_configs:
- to: 'dongfei_gao@intsig.net'
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['id','instance']
1.消除冗余的告警
prometheus.yml
alerting:
alertmanagers:
- static_configs:
- targets:
- 127.0.0.1:9093
rule_files:
- "rules/*.yml"
rules/test.yml
groups:
- name: general.rules
rules:
# Alert for any instance that is unreachable for >5 minutes.
- alert: InstanceDown
expr: up == 0
for: 1m
labels:
severity: error
annotations:
summary: "Instance {{ $labels.instance }} down"
description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."
告警状态
- Inactive: 这里什么都没有发生
- Pending: 已触发阈值,但未满足告警持续时间
- alertmanager: group_wait: 10s
- rules: for
- Firing: 已触发阈值且满足告警持续时间。警报发送给接收者
告警收敛
分组:将类似性质的警报分类为单个通知
抑制:当警报发出后,停止重复发送由此警报引发的其他警报
静默:是一种简单的特定时间静音提醒的机制
9093端口配置静默规则,在服务调试阶段可以暂时关闭告警