Prometheus
简介
Prometheus是最初在SoundCloud上构建的开源系统监视和警报工具包。自2012年成立以来,许多公司和组织都采用了Prometheus,该项目拥有非常活跃的开发人员和用户社区。Prometheus 于2016年加入了 Cloud Native Computing Foundation,这是继Kubernetes之后的第二个托管项目。
官网:https://prometheus.io 最新版本: 2.31.1
Exporter是一个采集监控数据并通过Prometheus监控规范对外提供数据的组件,能为Prometheus提供监控的接口。
Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server,Prometheus Server通过访问该Exporter提供的Endpoint端点,即可获取到需要采集的监控数据。不同的Exporter负责不同的业务。
-
Prometheus 开源的系统监控和报警框架,灵感源自Google的Borgmon监控系统
-
AlertManager 处理由客户端应用程序(如Prometheus server)发送的警报。它负责将重复数据删除,分组和路由到正确的接收者集成,还负责沉默和抑制警报
-
Node_Exporter 用来监控各节点的资源信息的exporter,应部署到prometheus监控的所有节点
-
PushGateway 推送网关,用于接收各节点推送的数据并暴露给Prometheus server
Prometheus介绍
prometheus的特点:
- 多维的数据模型(基于时间序列的Key、Value键值对)
- 灵活的查询和聚合语言PromQL
- 提供本地存储和分布式存储
- 通过基于HTTP的Pull模型采集时间序列数据
- 可利用Pushgateway(Prometheus的可选中间件)实现Push模式
- 可通过动态服务发现或静态配置发现目标机器
- 支持多种图表和数据大盘
prometheus的组件:
- Prometheus server,负责拉取、存储时间序列数据
- 客户端库(client library),插入应用程序代码
- 推送网关(push gateway),支持短暂的任务
- 特殊类型的exporter,支持如HAProxy,StatsD,Graphite等服务
- 一个alertmanager处理告警
- 各种支持工具
prometheus的架构:
下图说明了Prometheus的体系结构及其某些生态系统组件:
prometheus的使用场景:
prometheus非常适合记录任何纯数字时间序列。它既适合以机器为中心的监视,也适合监视高度动态的面向服务的体系结构。在微服务世界中,它对多维数据收集和查询的支持是一种特别的优势。
prometheus的设计旨在提高可靠性,使其成为中断期间要使用的系统,从而使您能够快速诊断问题。每个prometheus服务器都是独立的,而不依赖于网络存储或其他远程服务,当基础设施部分出现问题时仍然可以使用它。
Prometheus概念
数据模型:
prometheus将所有数据存储为时间序列:属于相同 metric名称和相同标签组(键值对)的时间戳值流。
metric 和 标签:
每一个时间序列都是由其 metric名称和一组标签(键值对)组成唯一标识。
metric名称代表了被监控系统的一般特征(如 http_requests_total代表接收到的HTTP请求总数)。它可能包含ASCII字母和数字,以及下划线和冒号,它必须匹配正则表达式[a-zA-Z_:][a-zA-Z0-9_:]*。
注意:冒号是为用户定义的记录规则保留的,不应该被exporter使用。
标签给prometheus建立了多维度数据模型:对于相同的 metric名称,标签的任何组合都可以标识该 metric的特定维度实例(例如:所有使用POST方法到 /api/tracks 接口的HTTP请求)。查询语言会基于这些维度进行过滤和聚合。更改任何标签值,包括添加或删除标签,都会创建一个新的时间序列。
标签名称可能包含ASCII字母、数字和下划线,它必须匹配正则表达式[a-zA-Z_][a-zA-Z0-9_]*。另外,以双下划线__开头的标签名称仅供内部使用。
标签值可以包含任何Unicode字符。标签值为空的标签被认为是不存在的标签。
表示法:
给定 metric名称和一组标签,通常使用以下表示法标识时间序列:
<metric name>{<label name>=<label value>, ...}
例如,一个时间序列的 metric名称是 api_http_requests_total,标签是 method=“POST” 和 handler="/messages"。可以这样写:
api_http_requests_total{method="POST", handler="/messages"}
这和OpenTSDB的表示法是一样的。
metric类型:
Counter 值只能单调增加或重启时归零,可以用来表示处理的请求数、完成的任务数、出现的错误数量等
Gauge 值可以任意增加或减少,可以用来测量温度、当前内存使用等
Histogram 取样观测结果,一般用来请求持续时间或响应大小,并在一个可配置的分布区间(bucket)内计算这些结果,提供所有观测结果的总和
累加的 counter,代表观测区间:<basename>_bucket{le="<upper inclusive bound>"}
所有观测值的总数:<basename>_sum
观测的事件数量:<basenmae>_count
Summary 取样观测结果,一般用来请求持续时间或响应大小,提供观测次数及所有观测结果的总和,还可以通过一个滑动的时间窗口计算可分配的分位数
观测的事件流φ-quantiles (0 ≤ φ ≤ 1):<basename>{quantile="φ"}
所有观测值的总和:<basename>_sum
观测的事件数量:<basename>_count
实例与任务:
在prometheus中,一个可以拉取数据的端点叫做实例(instance),一般等同于一个进程。一组有着同样目标的实例(例如为弹性或可用性而复制的进程副本)叫做任务(job)。
当prometheus拉取目标时,它会自动添加一些标签到时间序列中,用于标识被拉取的目标:
job:目标所属的任务名称
instance:目标URL中的<host>:<port>部分
如果两个标签在被拉取的数据中已经存在,那么就要看配置选项 honor_labels 的值来决定行为了。
每次对实例的拉取,prometheus会在以下的时间序列中保存一个样本(样本指的是在一个时间序列中特定时间点的一个值):
up{job="<job-name>", instance="<instance-id>"}:如果实例健康(可达),则为 1 ,否则为 0
scrape_duration_seconds{job="<job-name>", instance="<instance-id>"}:拉取的时长
scrape_samples_post_metric_relabeling{job="<job-name>", instance="<instance-id>"}:在 metric relabeling 之后,留存的样本数量
scrape_samples_scraped{job="<job-name>", instance="<instance-id>"}:目标暴露出的样本数量
up 时间序列对于实例的可用性监控来说非常有用
Prometheus部署
- 下载prometheus:
[root@master ~]# cd /opt/
[root@master opt]# wget https://github.com/prometheus/prometheus/releases/download/v2.31.1/prometheus-2.31.1.linux-amd64.tar.gz
[root@master opt]# ls
prometheus-2.31.1.linux-amd64.tar.gz
[root@master opt]# tar xf prometheus-2.31.1.linux-amd64.tar.gz -C /usr/local/
[root@master opt]# ls /usr/local/
bin etc games include lib lib64 libexec prometheus-2.31.1.linux-amd64 sbin share src
[root@master opt]# mv /usr/local/prometheus-2.31.1.linux-amd64/ /usr/local/prometheus
[root@master opt]# ls /usr/local/
bin etc games include lib lib64 libexec prometheus sbin share src
- 安装prometheus:
[root@master ~]# useradd -r -M -s /sbin/nologin prometheus
[root@master ~]# mkdir -p /data/prometheus
[root@master ~]# chown -R prometheus:prometheus /usr/local/prometheus/ /data/prometheus/
[root@master ~]# cat /usr/lib/systemd/system/prometheus.service
[Unit]
Description=Prometheus
After=network.target
[Service]
Type=simple
Environment="GOMAXPROCS=4"
User=prometheus
Group=prometheus
ExecReload=/bin/kill -HUP $MAINPID
ExecStart=/usr/local/prometheus/prometheus \
--config.file=/usr/local/prometheus/prometheus.yml \
--storage.tsdb.path=/data/prometheus \
--storage.tsdb.retention=30d \
--web.console.libraries=/usr/local/prometheus/console_libraries \
--web.console.templates=/usr/local/prometheus/consoles \
--web.listen-address=0.0.0.0:9090 \
--web.read-timeout=5m \
--web.max-connections=10 \
--query.max-concurrency=20 \
--query.timeout=2m \
--web.enable-lifecycle
PrivateTmp=true
PrivateDevices=true
ProtectHome=true
NoNewPrivileges=true
LimitNOFILE=infinity
ReadWriteDirectories=/data/prometheus
ProtectSystem=full
SyslogIdentifier=prometheus
Restart=always
[Install]
WantedBy=multi-user.target
[root@master ~]# systemctl daemon-reload
- 启动prometheus:
[root@master ~]# systemctl start prometheus.service
[root@master ~]# ss -antl
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 128 *:9090 *:*
LISTEN 0 128 [::]:22 [::]:*
- 访问网页测试