一、简介
Prometheus是最初在SoundCloud上构建的开源系统监视和警报工具包 。自2012年成立以来,许多公司和组织都采用了Prometheus,该项目拥有非常活跃的开发人员和用户社区。现在,它是一个独立的开源项目,并且独立于任何公司进行维护。为了强调这一点并阐明项目的治理结构,Prometheus 在2016年加入了 Cloud Native Computing Foundation,这是继Kubernetes之后的第二个托管项目
Prometheus是一个开源的完整监控解决方案,其对传统监控系统的测试和告警模型进行了彻底的颠覆,形成了基于中央化的规则计算、统一分析和告警的新模型。 相比于传统监控系统Prometheus具有以下优点:
易于管理
Prometheus核心部分只有一个单独的二进制文件,不存在任何的第三方依赖(数据库,缓存等等)。唯一需要的就是本地磁盘,因此不会有潜在级联故障的风险
监控服务的内部运行状态
Prometheus鼓励用户监控服务的内部状态,基于Prometheus丰富的Client库,用户可以轻松的在应用程序中添加对Prometheus的支持,从而让用户可以获取服务和应用内部真正的运行状态
强大的数据模型
所有采集的监控数据均以指标(metric)的形式保存在内置的时间序列数据库当中(TSDB)。所有的样本除了基本的指标名称以外,还包含一组用于描述该样本特征的标签
每一条时间序列由指标名称(Metrics Name)以及一组标签(Labels)唯一标识。每条时间序列按照时间的先后顺序存储一系列的样本值。
表示维度的标签可能来源于你的监控对象的状态,比如code=404或者content_path=/api/path。也可能来源于的你的环境定义,比如environment=produment。基于这些Labels我们可以方便地对监控数据进行聚合,过滤,裁剪
强大的查询语言PromQL
Prometheus内置了一个强大的数据查询语言PromQL。 通过PromQL可以实现对监控数据的查询、聚合。同时PromQL也被应用于数据可视化(如Grafana)以及告警当中
高效
对于监控系统而言,大量的监控任务必然导致有大量的数据产生。而Prometheus可以高效地处理这些数据,对于单一Prometheus Server实例而言它可以处理:数以百万的监控指标、每秒处理数十万的数据点
可扩展
Prometheus是如此简单,因此你可以在每个数据中心、每个团队运行独立的Prometheus Sevrer。Prometheus对于联邦集群的支持,可以让多个Prometheus实例产生一个逻辑集群,当单实例Prometheus Server处理的任务量过大时,通过使用功能分区(sharding)+联邦集群(federation)可以对其进行扩展
易于集成
使用Prometheus可以快速搭建监控服务,并且可以非常方便地在应用程序中进行集成。目前支持: Java, JMX, Python, Go,Ruby, .Net, Node.js等等语言的客户端SDK,基于这些SDK可以快速让应用程序纳入到Prometheus的监控当中,或者开发自己的监控数据收集程序。同时这些客户端收集的监控数据,不仅仅支持Prometheus,还能支持Graphite这些其他的监控工具
同时Prometheus还支持与其他的监控系统进行集成:Graphite, Statsd, Collected, Scollector, muini, Nagios等
Prometheus社区还提供了大量第三方实现的监控数据采集支持:JMX, CloudWatch, EC2, MySQL, PostgresSQL, Haskell, Bash, SNMP, Consul, Haproxy, Mesos, Bind, CouchDB, Django, Memcached, RabbitMQ, Redis, RethinkDB, Rsyslog等等
可视化
Prometheus Server中自带了一个Prometheus UI,通过这个UI可以方便地直接对数据进行查询,并且支持直接以图形化的形式展示数据。同时Prometheus还提供了一个独立的基于Ruby On Rails的Dashboard解决方案Promdash。最新的Grafana可视化工具也已经提供了完整的Prometheus支持,基于Grafana可以创建更加精美的监控图标。基于Prometheus提供的API还可以实现自己的监控可视化UI
开放性
通常来说当我们需要监控一个应用程序时,一般需要该应用程序提供对相应监控系统协议的支持。因此应用程序会与所选择的监控系统进行绑定。为了减少这种绑定所带来的限制。对于决策者而言要么你就直接在应用中集成该监控系统的支持,要么就在外部创建单独的服务来适配不同的监控系统
而对于Prometheus来说,使用Prometheus的client library的输出格式不止支持Prometheus的格式化数据,也可以输出支持其它监控系统的格式化数据,比如Graphite
因此你甚至可以在不使用Prometheus的情况下,采用Prometheus的client library来让你的应用程序支持监控数据采集
架构图
Prometheus通过直接或者短时jobs中介网关收集监控数据,在本地存储所有收集到的数据,并且通过定义好的rules产生新的时间顺序数据,或者发送警报。Promdash或者其他使用API的clients可以将采集到的数据可视化
组件
Prometheus Server 用于收集和存储时间序列数据
Client Library 客户端库,为需要监控的服务生成相应的 metrics 并暴露给 Prometheus server。当 Prometheus server 来 pull 时,直接返回实时状态的 metrics
Push Gateway 主要用于短期的 jobs。由于这类 jobs 存在时间较短,可能在 Prometheus 来 pull 之前就消失了。为此,这次 jobs 可以直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics,对于机器层面的 metrices,需要使用 node exporter
Exporters 用于暴露已有的第三方服务的 metrics 给 Prometheus
Alertmanager 从 Prometheus server 端接收到 alerts 后,会进行去除重复数据,分组,并路由到对收的接受方式,发出报警。常见的接收方式有:电子邮件,pagerduty,OpsGenie, webhook 等
场景
适用场景:Prometheus 适用于记录文本格式的时间序列,它既适用于以机器为中心的监控,也适用于高度动态的面向服务架构的监控。在微服务的世界中,它对多维数据收集和查询的支持有特殊优势。Prometheus 是专为提高系统可靠性而设计的,它可以在断电期间快速诊断问题,每个 Prometheus Server 都是相互独立的,不依赖于网络存储或其他远程服务。当基础架构出现故障时,你可以通过 Prometheus 快速定位故障点,而且不会消耗大量的基础架构资源
不适用场景:Prometheus 非常重视可靠性,即使在出现故障的情况下,你也可以随时查看有关系统的可用统计信息。如果你需要百分之百的准确度,例如按请求数量计费,那么 Prometheus 不太适合你,因为它收集的数据可能不够详细完整。这种情况下,你最好使用其他系统来收集和分析数据以进行计费,并使用 Prometheus 来监控系统的其余部分
二、安装Prometheus
环境
主机名称 | IP地址 | 安装软件 |
prometheus | 192.168.10.207 | prometheus |
node1 | 192.168.10.208 | node-exporter |
node2 | 192.168.10.205 | node-exporter |
上传软件
1、安装部署prometheus
[root@poromethes ~]# ls
anaconda-ks.cfg prometheus-2.32.1.linux-amd64.tar.gz
[root@poromethes ~]# tar xf prometheus-2.32.1.linux-amd64.tar.gz
[root@poromethes ~]# mv prometheus-2.32.1.linux-amd64 /usr/local/prometheus
[root@poromethes ~]# cd /usr/local/prometheus/
启动
[root@poromethes ~]# ./prometheus
[root@poromethes ~]# netstat -anptu | grep prometheus
tcp6 0 0 :::9090 :::* LISTEN 1204/prometheus
2、配置prometheus
添加一个网卡连接外网
[root@poromethes ~]# cat <<EOF | sudo tee /etc/yum.repos.d/influxdb.repo
[influxdb]
name = InfluxDB Repository - RHEL \$releasever
baseurl = https://repos.influxdata.com/rhel/\$releasever/\$basearch/stable
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdb.key
EOF
[root@poromethes ~]# sudo yum install influxdb2
[root@poromethes ~]# systemctl start influxdb
[root@poromethes ~]# netstat -anptu | grep 8086
tcp6 0 0 :::8086 :::* LISTEN 15566/influxd
测试访问192.168.10.207:8086
另存为仪表单元格
prometheus配置文件
指标说明
1、Prometheus以scrape_interval规则周期性从监控目标上收集数据,然后将数据存储到本地存储上
2、scrape_interval可以设定全局也可以设定单个metrics
3、Prometheus以evaluation_interval规则周期性对告警规则做计算,然后更新告警状态
4、evaluation_interval只有设定在全局
配置块 | |
global | 全局配置 |
alerting | 告警配置 |
rule_files | 规则文件配置 |
scrape_configs | 拉取配置 |
remote_read、remote_write | 远程读写配置/2.2.1 |
注意: 不做配置
global全局配置
[ scrape_interval: <duration> | default = 1m ] #默认抓取周期,单位ms、smhdwy;每15s采集一次数据,默认1分钟
[ scrape_timeout: <duration> | default = 10s ] #拉取超时时间
[ evaluation_interval: <duration> | default = 1m ] #估算规则的默认周期;每15秒计算一次规则,默认1分钟
# external systems (federation, remote storage, Alertmanager).
external_labels: #和外部系统通信时为时间序列或警情(Alert)强制添加的标签列表
[ <labelname>: <labelvalue> ... ]
[ query_log_file: <string> ] # 记录PromQL查询的日志文件
alerting告警配置
alerting: # Alertmanager相关配置
alert_relabel_configs:
[ - <relabel_config> ... ]
alertmanagers:
[ - <alertmanager_config> ... ]
2.1.3、rule_files规则文件配置
指定prometheus加载的任何规则的位置,从所有匹配的文件中读取规则和告警。目前没有规则
rule_files: # 规则文件列表
[ - <filepath_glob> ... ]
scrape_configs拉取配置
指定prometheus监控哪些资源。默认会拉取prometheus本身的时间序列数据,通过http://localhost:9090/metrics进行拉取
一个scrape_config指定一组目标和参数,描述如何拉取它们。在一般情况下,一个拉取配置指定一个作业。在高级配置中,这可能会改变
可以通过static_configs参数静态配置目标,也可以使用支持的服务发现机制之一动态发现目标。
此外,relabel_configs在拉取之前,可以对任何目标及其标签进行修改
scrape_configs:
job_name: <job_name>
[ scrape_interval: <duration> | default = <global_config.scrape_interval> ] #拉取频率
[ scrape_timeout: <duration> | default = <global_config.scrape_timeout> ] #拉取超时时间
[ metrics_path: <path> | default = /metrics ] #拉取的http路径
#honor_labels 控制prometheus处理已存在于收集数据中的标签与prometheus将附加在服务器端的标签("作业"和"实例"标签、手动配置的目标标签和由服务发现实现生成的标签)之间的冲突
#如果 honor_labels 设置为 "true",则通过保持从拉取数据获得的标签值并忽略冲突的服务器端标签来解决标签冲突
#如果 honor_labels 设置为 "false",则通过将拉取数据中冲突的标签重命名为"exported_<original-label>"来解决标签冲突(例如"exported_instance"、"exported_job"),然后附加服务器端标签
#注意,任何全局配置的 "external_labels"都不受此设置的影响。在与外部系统的通信中,只有当时间序列还没有给定的标签时,它们才被应用,否则就会被忽略
[ honor_labels: <boolean> | default = false ]
#honor_timestamps 控制prometheus是否遵守拉取数据中的时间戳
#如果 honor_timestamps 设置为 "true",将使用目标公开的metrics的时间戳
#如果 honor_timestamps 设置为 "false",目标公开的metrics的时间戳将被忽略
[ honor_timestamps: <boolean> | default = true ]
[ scheme: <scheme> | default = http ] #配置用于请求的协议
params: #可选的http url参数
[ <string>: [<string>, ...] ]
basic_auth: #在每个拉取请求上配置 username 和 password 来设置 Authorization 头部,password 和 password_file 二选一
[ username: <string> ]
[ password: <secret> ]
[ password_file: <string> ]
[ bearer_token: <secret> ] #在每个拉取请求上配置 bearer token 来设置 Authorization 头部,bearer_token 和 bearer_token_file 二选一
[ bearer_token_file: /path/to/bearer/token/file ] #在每个拉取请求上配置 bearer_token_file 来设置 Authorization 头部,bearer_token_file 和 bearer_token 二选一
tls_config: #配置拉取请求的TLS设置
[ <tls_config> ]
[ proxy_url: <string> ] #可选的代理URL
azure_sd_configs: #Azure服务发现配置列表
[ - <azure_sd_config> ... ]
consul_sd_configs: #Consul服务发现配置列表
[ - <consul_sd_config> ... ]
dns_sd_configs: #DNS服务发现配置列表
[ - <dns_sd_config> ... ]
ec2_sd_configs: #EC2服务发现配置列表
[ - <ec2_sd_config> ... ]
openstack_sd_configs: #OpenStack服务发现配置列表
[ - <openstack_sd_config> ... ]
file_sd_configs: #file服务发现配置列表
[ - <file_sd_config> ... ]
gce_sd_configs: #GCE服务发现配置列表
[ - <gce_sd_config> ... ]
kubernetes_sd_configs: #Kubernetes服务发现配置列表
[ - <kubernetes_sd_config> ... ]
marathon_sd_configs: #Marathon服务发现配置列表
[ - <marathon_sd_config> ... ]
nerve_sd_configs: #AirBnB's Nerve服务发现配置列表
[ - <nerve_sd_config> ... ]
serverset_sd_configs:
[ - <serverset_sd_config> ... ] #Zookeeper Serverset服务发现配置列表
triton_sd_configs:
[ - <triton_sd_config> ... ] #Triton服务发现配置列表
static_configs:
[ - <static_config> ... ] #静态配置目标列表
relabel_configs:
[ - <relabel_config> ... ] #目标relabel配置列表
metric_relabel_configs: #metric relabel配置列表
[ - <relabel_config> ... ]
#每次拉取样品的数量限制
#metric relabelling之后,如果有超过这个数量的样品,整个拉取将被视为失效。0表示没有限制
[ sample_limit: <int> | default = 0 ]
remote_read/remote_write远程读写配置
将数据源与prometheus分离
remote_write: #与远程写功能相关的设置
[ - <remote_write> ... ]
remote_read: #与远程读功能相关的设置
[ - <remote_read> ... ]
3、在全部服务器上部署Node Exporter
上传node_exporter
[root@node1 ~]# tar xf node_exporter-1.3.1.linux-amd64.tar.gz
[root@node1 ~]# mv node_exporter-1.3.1.linux-amd64 /usr/local/node_exporter
[root@node1 ~]# useradd -M -s /sbin/nologin prometheus
[root@node1 ~]# chown -R prometheus:prometheus /usr/local/node_exporter/
[root@node1 ~]# cd /usr/local/node_exporter/
[root@node1 node_exporter]# ls
LICENSE node_exporter NOTICE
[root@node1 node_exporter]# ./node_exporter &
访问192.168.10.208:9100
查看方法一:[root@node1 ~]# curl http://localhost:9100/metrics | head
查看方法二:http://192.168.10.207:9100/metrics
4、修改prometheus配置文件进行采集node信息
[root@poromethes ~]# vim /usr/local/prometheus/prometheus.yml
.....
..
scrape_configs:
- job_name: "prometheus"
static_configs:
- targets: ['localhost:9090']
- job_name: "node"
static_configs:
- targets: ['192.168.2.4:9100','192.168.2.5:9100','192.168.2.6:9100']
保存
[root@poromethes ~]# systemctl restart prometheus
部署的 node exporter 状态是 UP,说明运行正常
显示绿色是已经安装了node exporter,其他未安装的显示为红色
5、使用promql查询监控数据
Prometheus UI 是 Prometheus 内置的一个可视化管理界面,通过 Prometheus UI 用户可以轻松的了解 Prometheus 当前的配置,监控任务运行状态。通过Graph面板,用户还能直接使用PromQL实时查询监控数据
promQL 是Prometheus自定义的一套强大的数据查询语言,除了使用监控指标作为查询关键字以外,还内置了大量的函数,帮助用户进一步对时序数据进行处理
例:使用 rate()函数,可以计算在单位时间内样本数据的变化情况即增长率,因此通过函数我们可以近似的通过CPU使用时间的利用率
忽略是哪一个CPU的,使用without表达式,将标签CPU去除后聚合数据
6、实例和任务
Prometheus 中,将任意一个独立的数据源(target)称之为实例(instance)。包含相同类型的实例的集合称之为任务(job)
当前在每一个Job中主要使用了静态配置(static_configs)的方式定义监控目标。除了静态配置每一个Job的采集Instance地址以外,Prometheus还支持与DNS、Consul、E2C、Kubernetes 等进行集成实现自动发现Instance实例,并从这些Instance上获取监控数据
prometheus的数据模型
Prometheus 所有采集的监控数据均以指标(metric)的形式保存在内置时间序列的数据库当中(TSDB):属于同一指标名称,同一标签集合的、有时间戳标记的数据流。除了存储的时间序列,Prometheus 还可以根据查询请求产生临时的、衍生的时间序列作为返回结果
在时间序列中的每一个点称为一个样本(sample),样本由三部分组成
指标(metric) | 指标名称和描述当前样本特征的 labelsets |
时间戳(timestamp) | 一个精确到毫秒的时间戳 |
样本值(value) | 一个 folat64 的浮点型数据表示当前样本的值 |
每一条时间序列由指标名称(Metrics Name)以及一组标签(键值对)唯一标识。其中指标的名称(metric name)可以反映被监控样本的含义
avg without(cpu,mode)
prometheus中,将任意一个独立的数据源(target)称之为实例(instance)。包含相同实例的集合称之为任务(job)
当前在每一个Job中主要使用了静态配置(static_configs)的方式定义监控目标。除了静态配置每一个Job的采集Instance地址以外,Prometheus还支持与DNS、Consul、E2C、Kubernetes 等进行集成实现自动发现Instance实例,并从这些Instance上获取监控数据
prometheus的数据模型
Prometheus 所有采集的监控数据均以指标(metric)的形式保存在内置时间序列的数据库当中(TSDB):属于同一指标名称,同一标签集合的、有时间戳标记的数据流。除了存储的时间序列,Prometheus 还可以根据查询请求产生临时的、衍生的时间序列作为返回结果
在时间序列中的每一个点称为一个样本(sample),样本由三部分组成
指标(metric) 指标名称和描述当前样本特征的 labelsets
时间戳(timestamp) 一个精确到毫秒的时间戳
样本值(value) 一个 folat64 的浮点型数据表示当前样本的值
每一条时间序列由指标名称(Metrics Name)以及一组标签(键值对)唯一标识。其中指标的名称(metric name)可以反映被监控样本的含义
指标类型
Prometheus 的客户端库中提供了四种核心的指标类型。但这些类型只是在客户端库(客户端可以根据不同的数据类型调用不同的 API 接口)和在线协议中,实际在 Prometheus server 中并不对指标类型进行区分,而是简单地把这些指标统一视为无类型的时间序列
Counter
一种累加的 metric,典型的应用如:请求的个数,结束的任务数, 出现的错误数等等
Gauge
一种常规的 metric,典型的应用如:温度,运行的 goroutines 的个数,可以任意加减
Histogram
柱状图类型,典型的应用如:请求持续时间,响应大小,可以对观察结果采样,分组及统计
Summary
类似于 Histogram, 典型的应用如:请求持续时间,响应大小,提供观测值的 count 和 sum 功能,提供百分位的功能,即可以按百分比划分跟踪结果
7、配置文件案例
给target添加标签
[root@poromethes ~]# vim /usr/local/prometheus/prometheus.yml
static_configs:
- targets: ['localhost:9090']
labels:
name: linux
UUID: 7.4
保存
[root@poromethes ~]# systemctl restart prometheus
file_sd_configs
[root@poromethes prometheus]# vim prometheus.yml
scrape_configs:
- job_name: "prometheus"
static_configs:
- targets: ['localhost:9090']
labels:
name: linux
UUID: 7.4
- job_name: "node"
file_sd_configs:
- refresh_interval: 1m
files:
- "/usr/local/prometheus/conf/node-dis.yml"
独立文件配置
[root@poromethes prometheus]# mkdir /usr/local/prometheus/conf
[root@poromethes prometheus]# vim /usr/local/prometheus/conf/node-dis.yml
- targets: ["192.168.10.205:9100","192.168.10.207:9100","192.168.10.208:9100"]
[root@poromethes ~]# systemctl restart prometheus
consul_sd_file
由于consul的配置需要有consul的服务提供, 这里简单部署下consul的服务
[root@poromethes ~]# unzip consul_1.11.1_linux_amd64.zip
Archive: consul_1.11.1_linux_amd64.zip
inflating: consul
[root@poromethes ~]# mv consul /usr/local/bin/
[root@poromethes ~]# mkdir /etc/consul.d
[root@poromethes ~]# vim /etc/consul.d/prometheus-node.json
{
"addresses": {
"http": "0.0.0.0",
"https": "0.0.0.0"
},
"services": [{
"name": "prometheus-node",
"tags": ["prometheus","node"],
"port": 9100
}]
}
保存
[root@poromethes ~]# consul agent -dev -config-dir=/etc/consul.d 启动
打开web管理界面 192.169.2.4:8500,查看相应的服务信息
可以看到有2个service , 其中prometheus-node是我们定义的service
relabel_config
重新标记是一个功能强大的工具,可以在目标的标签集被抓取之前重写它,每个采集配置可以配置多个重写标签设置,并按照配置的顺序来应用于每个目标的标签集
目标重新标签之后,以 _ 开头的标签将从标签集中删除的
如果使用只需要临时的存储临时标签值的,可以使用 _tmp 作为前缀标识
relabel的action 类型 | |
replace | 对标签和标签值进行替换 |
keep | 满足特定条件的实例进行采集,其他的不采集 |
drop | 满足特定条件的实例不采集,其他的采集 |
labeldrop | 对抓取的实例特定标签进行删除 |
labelkeep | 对抓取的实例特定标签进行保留,其他的标签删除 |
测试action
测试前同步一下配置文件
[root@poromethes ~]# vim /usr/local/prometheus/prometheus.yml
.........
........
static_configs:
- targets: ["localhost:9090"]
- job_name: "node"
file_sd_configs:
- refresh_interval: 1m
files:
- "/usr/local/prometheus/conf/node-dis.yml"
保存
[root@poromethes ~]# vim /usr/local/prometheus/conf/node-dis.yml
- targets:
- "192.168.10.207:9100"
labels:
__hostname__: node
__businees_line__: "line_A"
__region_id__: "cn-beijing"
__availability_zone__: "123"
- targets:
- "192.168.10.208:9100"
labels:
__hostname__: node1
__businees_line__: "line_B"
__region_id__: "cn-beijing"
__availability_zone__: "123"
- targets:
- "192.168.10.205:9100"
labels:
__hostname__: node2
__businees_line__: "line_C"
__region_id__: "cn-beijing"
__availability_zone__: "123"
保存退出
因我们的 label 都是以 __ 开头的,目标重新标签之后,以 __ 开头的标签将从标签集中删除的
三、prometheus promql查询语言
Prometheus提供了一种名为PromQL (Prometheus查询语言)的函数式查询语言,允许用户实时选择和聚合时间序列数据。表达式的结果既可以显示为图形,也可以在Prometheus的表达式浏览器中作为表格数据查看,或者通过HTTP API由外部系统使用
修改配置文件
[root@poromethes ~]# vim /usr/local/prometheus/prometheus.yml
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
scrape_configs:
- job_name: "prometheus"
static_configs:
- targets: ['localhost:9090']
labels:
name: linux
UUID: 7.4
- job_name: "node"
file_sd_configs:
- refresh_interval: 1m
files:
- "/usr/local/prometheus/conf/node-dis.yml"
static_configs:
- targets: ['192.168.10.207:9100','192.168.10.208:9100','192.168.10.205:9100']
remote_write:
- url: "http://localhost:8086/api/v1/prom/write?db=prometheus"
remote_read:
- url: "http://localhost:8086/api/v1/prom/read?db=prometheus"
[root@poromethes ~]# vim /usr/local/prometheus/conf/node-dis.yml
- targets:
- "192.168.2.4:9100"
labels:
__datacenter__: data
__hostname__: node
__businees_line__: "line1"
__region_id__: "cn-beijing"
__availability_zone__: "A"
- targets:
- "192.168.2.5:9100"
labels:
__datacenter__: data2
__hostname__: node1
__businees_line__: "line2"
__region_id__: "cn-beijing"
__availability_zone__: "B"
- targets:
- "192.168.2.6:9100"
labels:
__datacenter__: data3
__hostname__: node2
__businees_line__: "line3"
__region_id__: "cn-beijing"
__availability_zone__: "C"
保存
[root@poromethes ~]# systemctl restart prometheus
时序查询
1、查询特定metric_name
node_forks_total #节点forks的总次数
2、带标签的查询
node_forks_total{instance="192.168.10.205:9100"}
3、多标签查询
node_forks_total{instance="192.168.10.205:9100",job="node"}
4、查询2分钟的时序数值
node_forks_total{instance="192.168.10.205:9100",job="node"}[2m]
5、正则匹配
node_forks_total{instance=~"192.168.10.*:9100",job="node"}
6、子查询
rate(node_cpu_seconds_total{cpu="0",instance="192.168.10.205:9100",job="node",mode="idle"}[5m])[10m:1m]
复杂查询
1、计算内存使用百分比
node_memory_MemFree_bytes / node_memory_MemTotal_bytes * 100
2、获取所有实例使用百分比前3个
实用查询案例
获取cpu核心个数
count by (instance) ( count by (instance,cpu) (node_cpu_seconds_total{mode="system"}) )
count by (instance) ( count by (instance,cpu) (node_cpu_seconds_total{mode="system",instance="192.168.10.207:9100"})) 计算单个实例
计算内存使用率
(1 - (node_memory_MemAvailable_bytes{instance=~"192.168.10.205:9100"} / (node_memory_MemTotal_bytes{instance=~"192.168.10.205:9100"})))* 100
预测磁盘空间
(1- node_filesystem_avail_bytes{fstype=~"ext4|xfs",mountpoint="/"}
/ node_filesystem_size_bytes{fstype=~"ext4|xfs",mountpoint="/"}) * 100 >= 85 and (predict_linear(node_filesystem_avail_bytes[6h],3600 * 24) < 0)
整体分为 2个部分, 中间用and分割, 前面部分计算根分区使用率大于85的, 后面计算根据近6小时的数据预测接下来24小时的磁盘可用空间是否小于0
prometheus常见表达式
常见函数
rate函数(速率函数)
rate() 函数是专门搭配counter数据类型使用函数,功能是取counter在这个时间段中平均每秒的增量
获取网卡1m每秒流量平均
rate(node_network_receive_bytes_total[1m])
只看ens33网卡1m每秒流量平均(所有服务器的ens33)
rate(node_network_receive_bytes_total{device='ens33'}[1m])
只看某一台服务器ens33网卡1m每秒流量平均(可以通过,instance,job等修饰)
rate(node_network_receive_bytes_total{device='ens33',instance='192.168.10.207:9100',job='node'}[1m])
irate函数
irate(v range-vector)计算范围向量中时间序列的每秒即使增长率。这局域最后两个数据点单调性中断(例如由于目标重启而导致的计数器重置)会自动调整
简单说irate用于计算速率
irate(node_cpu_seconds_total{cpu="0",instance="192.168.10.207:9100",job='node',mode='idle'}[1m])
increase函数
increase() 函数表示某段时间内数据的增量;获取数据比较粗糙的时候 类似于5m,10m甚至更长时间取样推荐使用increase()
rate() 函数则表示某段时间内数据的平均值;获取数据比较精细的时候 类似于1m取样推荐使用rate()
sum函数
sum()函数就是求和函数;当使用sum后是将所有的监控的服务器的值进行取和,所以在看某一台时需要进行拆分
拆分常用方法
1、by increase()
2、by (cluster_name) 属于自定义标签不是标准标签,我们可以手动将不痛功能的服务器进行分组展示
sum(rate(node_network_receive_bytes_total{device='ens33'}[1m]))
topk函数
topk() 函数的定义是:取前面x位的最高值
Gauge类型使用方式
topk(5,node_cpu_seconds_total)
Counter类型使用方式(必须加rate/increase才有意义)
count函数
count() 是找出当前或者历史数据中某个key的数值大于或小于某个值的统计count(node_netstat_Tcp_CurrEstab > 20)
配合grafana使用
安装Grafana
wget https://dl.grafana.com/enterprise/release/grafana-enterprise-8.3.3-1.x86_64.rpm
[root@poromethes ~]# rm -rf /etc/yum.repos.d/influxdb.repo
[root@poromethes ~]# yum localinstall grafana-enterprise-8.3.3-1.x86_64.rpm
...................
.........
[root@poromethes ~]# find / -iname 'grafana' #查看配置文件
/etc/grafana
/var/lib/grafana
/var/log/grafana
/usr/share/grafana
/usr/share/grafana/public/app/plugins/datasource/grafana
[root@poromethes ~]# find / -iname 'grafana-server.service' #查看启动脚本
/usr/lib/systemd/system/grafana-server.service
[root@poromethes ~]# systemctl restart grafana-server
[root@poromethes ~]# netstat -anput|grep 3000
tcp6 0 0 :::3000 :::* LISTEN 3471/grafana-serve
访问网页
把模板复制进去
进入后会显示以下内容