前言
zabbix是传统的监控系统,出现比云原生早,使用的是SQL关系型数据库;而Prometheus基于谷歌的borgemon使用go语言开发,使用TSDB数据库,所以支持云原生。zabbix最新发布的6.0版本,知道自己处于生死存亡时刻,也支持了Prometheus使用的TSDB数据库。
一、Prometheus 概述
1.1 什么是Prometheus
Prometheus 是一个开源的服务监控系统和时序数据库,其提供了通用的数据模型和快捷数据采集、存储和查询接口。它的核心组件Prometheus server会定期从静态配置的监控目标或者基于服务发现自动配置的自标中进行拉取数据,当新拉取到的数据大于配置的内存缓存区时,数据就会持久化到存储设备当中。
每个被监控的主机都可以通过专用的exporter 程序提供输出监控数据的接口,它会在目标处收集监控数据,并暴露出一个HTTP接口供Prometheus server查询,Prometheus通过基于HTTP的pull的方式来周期性的采集数据。
任何被监控的目标都需要事先纳入到监控系统中才能进行时序数据采集、存储、告警和展示,监控目标可以通过配置信息以静态形式指定,也可以让Prometheus通过服务发现的机制进行动态管理。
Prometheus 能够直接把API Server作为服务发现系统使用,进而动态发现和监控集群中的所有可被监控的对象。
Prometheus 官网地址:https://prometheus.io
Prometheus github 地址:https://github.com/prometheus
1.2 prometheus 的特点:
- 多维数据模型:由度量名称和键值对标识的时间序列数据
时序数据,是在一段时间内通过重复测量(measurement)而获得的观测值的集合;将这些观测值绘制于图形之上,它会有一个数据轴和一个时间轴;
服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据;
- 内置时间序列(pime series)数据库:Prometheus;外置的远端存储通常会用:InfluxDB、openTsDB等
- promQL一种灵活的查询语言,可以利用多维数据完成复杂查询
- 基于HTTP的pull(拉取)方式采集时间序列数据
- 同时支持PushGateway组件收集数据
- 通过静态配置或服务发现发现目标
- 支持作为数据源接入Grafana
1.3 Prometheus的生态组件
Prometheus 负责时序型指标数据的采集及存储,但数据的分析、聚合及直观展示以及告警等功能并非由Prometheus Server所负责。
(1)Prometheus server:服务核心组件,采用pull方式收集监控数据,通过http协议传输。并存储时间序列数据。Prometheus server 由三个部分组成:Retrival,Storage,PromQL
- Retrieval:负责在活跃的target 主机上抓取监控指标数据。
- Storage:存储,主要是把采集到的数据存储到磁盘中。默认为15天(可修改)。
- PromQL:是Prometheus提供的查询语言模块。
(2)client Library:客户端库,目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径,用于基于应用程序内建的测量系统。
(3)Exporters:指标暴露器,负责收集不支持内建Instrumentation的应用程序或服务的性能指标数据,并通过HTTP接口供Prometheus Server获取。换句话说,Exporter 负责从目标应用程序上采集和聚合原始格式的数据,并转换或聚合为Prometheus格式的指标向外暴露。
常用的Exporters:
- Node-Exporter:用于收集服务器节点(例如k8s)的物理指标状态数据,如平均负载、CPU、内存、磁盘、网络等资源信息的指标数据,需要部署到所有运算节点。指标详细介绍:https://github.com/prometheus/node_exporter
- mysqld-exporter/nginx-exporter
- Kube-state-Metrics:为prometheus 采集k8s资源数据的exporter,通过监听APIServer 收集kubernetes集群内资源对象的状态指标数据,例如pod、deployment、service 等等。同时它也提供自己的数据,主要是资源采集个数和采集发生的异常次数统计。
需要注意的是kube-state-metrics 只是简单的提供一个metrics 数据,并不会存储这些指标数据,所以可以使用prometheus来抓取这些数据然后存储,主要关注的是业务相关的一些元数据,比如Deployment、Pod、副本状态等;调度了多少个replicas?现在可用的有几个?多少个Pod是running/stopped/terminated 状态?Pod 重启了多少次?有多少job在运行中。 - cAdvisor:用来监控容器内部使用资源的信息,比如CPU、内存、网络I/0、磁盘I/0。
- blackbox-exporter:监控业务容器存活性。
(4)Service Discovery:服务发现,用于动态发现待监控的Target,Prometheus支持多种服务发现机制:文件、DNS、Consul、Kubernetes等等。
服务发现可通过第三方提供的接口,Prometheus查询到需要监控的Target列表,然后轮询这些Target 获取监控数据。该组件目前由Prometheus Server内建支持
(5)Alertmanager:是一个独立的告警模块,从Prometheus server端接收到“告警通知”后,会进行去重、分组,并路由到相应的接收方,发出报警,常见的接收方式有:电子邮件、钉钉、企业微信等。
Prometheus Server 仅负责生成告警指示,具体的告警行为由另一个独立的应用程序AlertManager负责;告警指示由 Prometheus Server基于用户提供的告警规则周期性计算生成,Alertmanager 接收到Prometheus Server发来的告警指示后,基于用户定义的告警路由向告警接收人发送告警信息。
(6)Pushgateway:类似一个中转站,Prometheus的server端只会使用pull方式拉取数据,但是某些节点因为某些原因只能使用push方式推送数据,那么它就是用来接收push而来的数据并暴露给Prometheus的server拉取的中转站。可以理解成目标主机可以上报短期任务的数据到Pushgateway,然后Prometheus server 统一从Pushgateway拉取数据。
(7)Grafana:是一个跨平台的开源的度量分析和可视化工具,可以将采集的数据可视化的展示,并及时通知给告警接收方。其官方库中具有丰富的仪表盘插件。
1.4 Prometheus的工作模式:
- Prometheus Server 基于服务发现(Service Discovery)机制或静态配置获取要监视的目标(Target),并通过每个目标上的指标exporter来采集(Scrape)指标数据;
- Prometheus Server 内置了一个基于文件的时间序列存储来持久存储指标数据,用户可使用PromQL接口来检索数据,也能够按需将告警需求发往A1ertmanager完成告警内容发送;
- 一些短期运行的作业的生命周期过短,难以有效地将必要的指标数据供给到Server端,它们一般会采用推送(Push)方式输出指标数据,Prometheus借助于Pushgateway 接收这些推送的数据,进而由server端进行抓取
1.5 Prometheus的工作流程
(1)Prometheus以prometheus Server 为核心,用于收集和存储时间序列数据。Prometheus Server从监控目标中通过pull方式拉取指标数据,或通过pushgateway 把采集的数据拉取到Prometheus server中。
(2)Prometheus server 把采集到的监控指标数据通过TSDB存储到本地HDD/ssD中。
(3)Prometheus 采集的监控指标数据按时间序列存储,通过配置报警规则,把触发的报警发送到Alertmanager。
(4)Alertmanager 通过配置报警接收方,发送报警到邮件、钉钉或者企业微信等。
(5)Prometheus 自带的Web UI 界面提供PromQL 查询语言,可查询监控数据。
(6)Grafana 可接入Prometheus 数据源,把监控数据以图形化形式展示出。
1.6 Prometheus的局限性
Prometheus是一款指际监控系统,不适合存储事件及日志等;它更多地展示的是趋势性的监控,而非精准数据;
Prometheus认为只有最近的监控数据才有查询的需要,其本地存储的设计初衷只是保存短期(例如一个月)数据,因而不支持针对大量的历史数据进行存储;若需要存储长期的历史数据,建议基于远端存储机制将数据保存于InfluxDB或openTsDB等系统中;
Prometheus的集群机制成熟度不高,可基于Thanos(和灭霸是一个单词)实现Prometheus集群的高可用及联邦集群。
mysql、nginx、k8s等使用多个不同的Prometheus收集,形成联邦集群
二、二进制包部署Prometheus
2.1 环境准备工作
服务器类型 | IP地址 | 组件 |
---|---|---|
Prometheus服务器 | 192.168.109.138 | Prometheus、node_exporter |
grafana服务器 | 192.168.109.138 | Grafana |
被监控服务器 | 192.168.109.0/24 | node_exporter |
2.2 普罗米修斯的部署
(1)上传 prometheus-2.35.0.linux-amd64.tar.gz 到 /opt 目录中,并解压
#解压上传后的软件包
root@localhost opt]# tar xf prometheus-2.35.0.linux-amd64.tar.gz
#移动并命名
[root@localhost opt]# mv prometheus-2.35.0.linux-amd64 /usr/local/prometheus
[root@localhost opt]# cd /usr/local/prometheus
[root@localhost prometheus]# ls
console_libraries consoles LICENSE NOTICE prometheus prometheus.yml promtool
配置文件
cat /usr/local/prometheus/prometheus.yml | grep -v "^#"
global: #用于prometheus的全局配置,比如采集间隔,抓取超时时间等
scrape_interval: 15s #采集目标主机监控数据的时间间隔,默认为1m
evaluation_interval: 15s #触发告警生成alert的时间间隔,默认是1m
# scrape_timeout is set to the global default (10s).
scrape_timeout: 10s #数据采集超时时间,默认10s
alerting: #用于alertmanager实例的配置,支持静态配置和动态服务发现的机制
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
rule_files: #用于加载告警规则相关的文件路径的配置,可以使用文件名通配机制
# - "first_rules.yml"
# - "second_rules.yml"
scrape_configs: #用于采集时序数据源的配置
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: "prometheus" #每个被监控实例的集合用job_name命名,支持静态配置(static_configs)和动态服务发现的机制(*_sd_configs)
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs: #静态目标配置,固定从某个target拉取数据
- targets: ["localhost:9090"]
(2)配置系统启动文件,启动 Prometheust
cat > /usr/lib/systemd/system/prometheus.service <<'EOF'
[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/prometheus/prometheus \
--config.file=/usr/local/prometheus/prometheus.yml \
--storage.tsdb.path=/usr/local/prometheus/data/ \
--storage.tsdb.retention=15d \
--web.enable-lifecycle
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
---------------------------------------------------------------
[Unit] #服务单元
Description=Prometheus Server #描述
Documentation=https://prometheus.io
After=network.target #依赖关系
[Service]
Type=simple
ExecStart=/usr/local/prometheus/prometheus \
--config.file=/usr/local/prometheus/prometheus.yml \ #配置文件
--storage.tsdb.path=/usr/local/prometheus/data/ \ #数据目录
--storage.tsdb.retention=15d \ #保存时间
--web.enable-lifecycle #开启热加载
ExecReload=/bin/kill -HUP $MAINPID #重载
Restart=on-failure
[Install]
WantedBy=multi-user.target
(3)启动
systemctl start prometheus
systemctl enable prometheus
netstat -natp | grep :9090
浏览器访问:http://192.168.109.138:9090 ,访问到 Prometheus 的 Web UI 界面
点击页面的 Status -> Targets,如看到 Target 状态都为 UP,说明 Prometheus 能正常采集到数据
http://192.168.109.138:9090/metrics ,可以看到 Prometheus 采集到自己的指标数据
三、部署 Exporters
部署 Node Exporter 监控系统级指标
(1)上传 node_exporter-1.3.1.linux-amd64.tar.gz 到 /opt 目录中,并解压
cd /opt/
tar xf node_exporter-1.3.1.linux-amd64.tar.gz
mv node_exporter-1.3.1.linux-amd64/node_exporter /usr/local/bin
(2)配置启动文件
cat > /usr/lib/systemd/system/node_exporter.service <<'EOF'
[Unit]
Description=node_exporter
Documentation=https://prometheus.io/
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/node_exporter \
--collector.ntp \
--collector.mountstats \
--collector.systemd \
--collector.tcpstat
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
(3)启动
systemctl start node_exporter
systemctl enable node_exporter
netstat -natp | grep :9100
浏览器访问:http://192.168.109.138:9100/metrics ,可以看到 Node Exporter 采集到的指标数据
常用的各指标:
- node_cpu_seconds_total
- node_memory_MemTotal_bytes
- node_filesystem_size_bytes{mount_point=PATH}
- node_system_unit_state{name=}
- node_vmstat_pswpin:系统每秒从磁盘读到内存的字节数
- node_vmstat_pswpout:系统每秒钟从内存写到磁盘的字节数
更多指标介绍:https://github.com/prometheus/node_exporter
(4)修改 prometheus 配置文件,加入到 prometheus 监控中
vim /usr/local/prometheus/prometheus.yml
#在尾部增加如下内容
- job_name: nodes
metrics_path: "/metrics"
static_configs:
- targets:
- 192.168.109.138:9100
- 192.168.109.137:9100
- 192.168.109.136:9100
labels:
service: kubernetes
(5)重新载入配置
curl -X POST http://192.168.109.138:9090/-/reload #热加载
或systemctl reload prometheus
浏览器查看 Prometheus 页面的 Status -> Targets
四、部署Grafana进行展示
(1)下载和安装
下载地址:
https://grafana.com/grafana/download
https://mirrors.bfsu.edu.cn/grafana/yum/rpm/
#使用yum解决依赖关系 我这边直接上传软件包到opt
yum install -y grafana-7.4.0-1.x86_64.rpm
systemctl start grafana-server
systemctl enable grafana-server
netstat -natp | grep :3000
浏览器访问:http://192.168.109.138:3000 ,默认账号和密码为 admin/admin
(2)配置数据源
Configuration -> Data Sources -> Add data source -> 选择 Prometheus
HTTP -> URL 输入 http://192.168.109.138:9090
点击 Save & Test
点击 上方菜单 Dashboards,Import 所有默认模板
Dashboards -> Manage ,选择 Prometheus 2.0 Stats 或 Prometheus Stats 即可看到 Prometheus job 实例的监控图像
(3)导入 grafana 监控面板
浏览器访问:https://grafana.com/grafana/dashboards ,在页面中搜索 node exporter ,选择适合的面板,点击 Copy ID 或者 Download JSON
在 grafana 页面中,+ Create -> Import ,输入面板 ID 号或者上传 JSON 文件,点击 Load,即可导入监控面板
五、部署Prometheus服务发现
5.1 基于文件的服务发现
基于文件的服务发现是仅仅略优于静态配置的服务发现方式,它不依赖于任何平台或第三方服务,因而也是最为简单和通用的实现方式。
Prometheus Server 会定期从文件中加载 Target 信息,文件可使用 YAML 和 JSON 格式,它含有定义的 Target 列表,以及可选的标签信息。
(1)创建用于服务发现的文件,在文件中配置所需的 target
cd /usr/local/prometheus
mkdir targets
vim targets/node-exporter.yaml
- targets:
- 192.168.109.131:9100
- 192.168.109.132:9100
- 192.168.109.133:9100
labels:
app: node-exporter
job: node
#修改 prometheus 配置文件,发现 target 的配置,定义在配置文件的 job 之中
vim /usr/local/prometheus/prometheus.yml
......
scrape_configs:
- job_name: nodes
file_sd_configs: #指定使用文件服务发现
- files: #指定要加载的文件列表
- targets/node*.yaml #文件加载支持通配符
refresh_interval: 2m #每隔 2 分钟重新加载一次文件中定义的 Targets,默认为 5m
systemctl reload prometheus
浏览器查看 Prometheus 页面的 Status -> Targets
前提是该node节点装好node-exporter组件,这个步骤在前面就不展示了,可以使用scp命令从普罗米修斯机子传过去
5.2 基于 Consul 的服务发现
Consul 是一款基于 golang 开发的开源工具,主要面向分布式,服务化的系统提供服务注册、服务发现和配置管理的功能。
提供服务注册/发现、健康检查、Key/Value存储、多数据中心和分布式一致性保证等功能。
下载地址:https://www.consul.io/downloads/
(1)部署 Consul 服务
cd /opt/
unzip consul_1.9.2_linux_amd64.zip
mv consul /usr/local/bin/
#创建 Consul 服务的数据目录和配置目录
mkdir /var/lib/consul-data
mkdir /etc/consul/
#使用 server 模式启动 Consul 服务
consul agent \
-server \
-bootstrap \
-ui \
-data-dir=/var/lib/consul-data \
-config-dir=/etc/consul/ \
-bind=192.168.109.138 \
-client=0.0.0.0 \
-node=consul-server01 &> /var/log/consul.log &
#查看 consul 集群成员
consul members
(2)在 Consul 上注册 Services
#在配置目录中添加文件
vim /etc/consul/nodes.json
{
"services": [
{
"id": "node_exporter-node01",
"name": "node01",
"address": "192.168.109.138",
"port": 9100,
"tags": ["nodes"],
"checks": [{
"http": "http://192.168.109.138:9100/metrics",
"interval": "5s"
}]
},
{
"id": "node_exporter-node02",
"name": "node02",
"address": "192.168.109.134",
"port": 9100,
"tags": ["nodes"],
"checks": [{
"http": "http://192.168.109.134:9100/metrics",
"interval": "5s"
}]
}
]
}
#让 consul 重新加载配置信息
consul reload
浏览器访问:http://192.168.109.138:8500
同样134机子需要配置node-exporter,这边不展示
(3)修改 prometheus 配置文件
vim /usr/local/prometheus/prometheus.yml
......
- job_name: nodes
consul_sd_configs: #指定使用 consul 服务发现
- server: 192.168.109.138:8500 #指定 consul 服务的端点列表
tags: #指定 consul 服务发现的 services 中哪些 service 能够加入到 prometheus 监控的标签
- nodes
refresh_interval: 2m
systemctl reload prometheus
浏览器查看 Prometheus 页面的 Status -> Targets
#让 consul 注销 Service
consul services deregister -id="node_exporter-node02"
#重新注册
consul services register /etc/consul/nodes.json
5.3 基于 Kubernetes API 的服务发现
内容较多后期详细写一篇
总结
prometheus定义: 监控系统、时间序列数据库
prometheus生态组件:
- prometheus server(http PULL方式的数据采集,TSDB数据库存储,alter告警生成)
- client libray(客户端库,使应用服务原生支持prometheus监控数据采集)
- exporter(指标暴露器,用于收集原生不支持prometheus监控的系统和应用的数据暴露给 prometheus)
- altermanger(接收prometheus server推送的告警信息,负责发告警路由发送给接收人)
- pushgateway(接收一些短期任务推送的监控数据,并临时存储,再由prometheus server统一拉取)
- grafana(外置的监控数据展示平台,使用promQL查询 prometheus 数据源)
- service discovery(动态服务发现机制,支持文件、consul、K8S、DNS等方式)
exporter
Node-exporter、Nginx/Mysql/Redis-exporter、Kube-State-Metrics、cADvisor、blackbox-exporter
prometheus远程存储: InfluxDB、openTSDB文章来源:https://www.toymoban.com/news/detail-778471.html
文章来源地址https://www.toymoban.com/news/detail-778471.html
到了这里,关于【云原生监控系列第一篇】一文详解Prometheus普罗米修斯监控系统(山前前后各有风景,有风无风都很自由)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!