Prometheus
Prometheus
基本概念#
Prometheus 概述#
Prometheus 是一个开源的服务监控系统和时序数据库,其提供了通用的数据模型和快捷数据采集、存储和查询接口。它的核心组件 Prometheus server 会定期从静态配置的监控目标或者基于服务发现自动配置的目标中进行拉取数据,新拉取到的数据会持久化到存储设备当中。 每个被监控的主机都可以通过专用的 exporter 程序提供输出监控数据的接口,它会在目标处收集监控数据,并暴露出一个 HTTP 接口供 Prometheus server 查询,Prometheus 通过基于 HTTP 的 pull 的方式来周期性的采集数据。 如果存在告警规则,则抓取到数据之后会根据规则进行计算,满足告警条件则会生成告警,并发送到 Alertmanager 完成告警的汇总和分发。 当被监控的目标有主动推送数据的需求时,可以以 Pushgateway 组件进行接收并临时存储数据,然后等待 Prometheus server 完成数据的采集。 任何被监控的目标都需要事先纳入到监控系统中才能进行时序数据采集、存储、告警和展示,监控目标可以通过配置信息以静态形式指定,也可以让 Prometheus 通过服务发现的机制进行动态管理。 Prometheus 能够直接把 API Server 作为服务发现系统使用,进而动态发现和监控集群中的所有可被监控的对象。 Prometheus 官网地址:https://prometheus.io Prometheus github 地址:https://github.com/prometheus
TSDB 作为 Prometheus 的存储引擎完美契合了监控数据的应用场景#
●存储的数据量级十分庞大
●大部分时间都是写入操作
●写入操作几乎是顺序添加,大多数时候数据都以时间排序
●很少更新数据,大多数情况在数据被采集到数秒或者数分钟后就会被写入数据库
●删除操作一般为区块删除,选定开始的历史时间并指定后续的区块。很少单独删除某个时间或者分开的随机时间的数据
●基本数据大,一般超过内存大小。一般选取的只是其一小部分且没有规律,缓存几乎不起任何作用
●读操作是十分典型的升序或者降序的顺序读
●高并发的读操作十分常见
Prometheus 的特点#
●多维数据模型:由度量名称和键值对标识的时间序列数据
时间序列数据:按照时间顺序记录系统、设备状态变化的数据,每个数据称为一个样本;服务器指标数据、应用程序性能监控数据、网络数据等都是时序数据
●内置时间序列(Time Series)数据库:Prometheus ;外置的远端存储通常会用:InfluxDB、OpenTSDB 等
●promQL 一种灵活的查询语言,可以利用多维数据完成复杂查询
●基于 HTTP 的 pull(拉取)方式采集时间序列数据
●同时支持 PushGateway 组件收集数据
●通过静态配置或服务发现发现目标
●支持作为数据源接入 Grafana
Prometheus 的生态组件#
Prometheus 负责时序型指标数据的采集及存储,但数据的分析、聚合及直观展示以及告警等功能并非由 Prometheus Server 所负责。 Prometheus 生态圈中包含了多个组件,其中部分组件可选: (1)Prometheus server:服务核心组件,采用 pull 方式采集监控数据,通过 http 协议传输;存储时间序列数据;基于“告警规则”生成告警通知。 Prometheus server 由三个部分组成:Retrieval,Storage,PromQL ●Retrieval:负责在活跃的 target 主机上抓取监控指标数据。 ●Storage:存储,主要是把采集到的数据存储到磁盘中。默认为 15 天。 ●PromQL:是 Prometheus 提供的查询语言模块。 (2)Client Library: 客户端库,目的在于为那些期望原生提供 Instrumentation 功能的应用程序提供便捷的开发途径,用于基于应用程序内建的测量系统。 (3)Exporters:指标暴露器,负责收集不支持内建 Instrumentation 的应用程序或服务的性能指标数据,并通过 HTTP 接口供 Prometheus Server 获取。 换句话说,Exporter 负责从目标应用程序上采集和聚合原始格式的数据,并转换或聚合为 Prometheus 格式的指标向外暴露。 常用的 Exporters: ●Node-Exporter:用于收集服务器节点的物理指标状态数据,如平均负载、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/O、磁盘I/O 。 ●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:是一个跨平台的开源的度量分析和可视化工具,可以将采集的数据可视化的展示,并及时通知给告警接收方。其官方库中具有丰富的仪表盘插件。
Prometheus 的工作模式#
●Prometheus Server 基于服务发现(Service Discovery)机制或静态配置获取要监视的目标(Target),并通过每个目标上的指标 exporter 来采集(Scrape)指标数据;
●Prometheus Server 内置了一个基于文件的时间序列存储来持久存储指标数据,用户可使用 PromQL 接口来检索数据,也能够按需将告警需求发往 Alertmanager 完成告警内容发送;
●一些短期运行的作业的生命周期过短,难以有效地将必要的指标数据供给到 Server 端,它们一般会采用推送(Push)方式输出指标数据, Prometheus 借助于 Pushgateway 接收这些推送的数据,进而由 Server 端进行抓取
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 数据源,把监控数据以图形化形式展示出。
Prometheus 的局限性#
●Prometheus 是一款指标监控系统,不适合存储事件及日志等;它更多地展示的是趋势性的监控,而非精准数据;
●Prometheus 认为只有最近的监控数据才有查询的需要,其本地存储的设计初衷只是保存短期(例如一个月)数据,因而不支持针对大量的历史数据进行存储;
若需要存储长期的历史数据,建议基于远端存储机制将数据保存于 InfluxDB 或 OpenTSDB 等系统中;
●Prometheus 的集群机制成熟度不高,可基于 Thanos 或 Cortex 实现 Prometheus 集群的高可用及联邦集群。
部署 Prometheus#
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' metrics_path: '/metrics' #指标数据采集路径,默认为 /metrics # scheme defaults to 'http'. static_configs: #静态目标配置,固定从某个target拉取数据 - targets: ["localhost:9090"]
配置系统启动文件,启动 Prometheust#
vim /usr/lib/systemd/system/prometheus.service
[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
部署 Exporters#
mv node_exporter-1.3.1.linux-amd64/node_exporter /usr/local/bin/
vim /usr/lib/systemd/system/node_exporter.service
[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
- job_name: "nodes" metrics_path: "/metrics" scheme: http static_configs: - targets: - 192.168.19.23:9100 - 192.168.19.30:9100 labels: from: node_exporter
#重启prometheus服务
常用的各指标: ●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
监控 MySQL 配置#
mv mysqld_exporter-0.14.0.linux-amd64/mysqld_exporter /usr/local/bin/
vim /usr/lib/systemd/system/mysqld_exporter.service
[Unit] Description=mysqld_exporter Documentation=https://prometheus.io/ After=network.target [Service] Type=simple ExecStart=/usr/local/bin/mysqld_exporter --config.my-cnf=/etc/my.cnf ExecReload=/bin/kill -HUP $MAINPID Restart=on-failure [Install] WantedBy=multi-user.target
host=localhost user=exporter password=abc123
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost' IDENTIFIED BY 'abc123';
vim /usr/local/prometheus/prometheus.yml - job_name: "mysqld" metrics_path: "/metrics" scheme: http static_configs: - targets: - 192.168.19.26:9104 labels: from: mysqld_exporter
curl -X POST http://192.168.19.24:9090/-/reload
监控 Nginx 配置#
yum -y install pcre-devel zlib-devel openssl-devel gcc gcc-c++ make
useradd -M -s /sbin/nologin nginx
./configure --prefix=/usr/local/nginx \ --user=nginx \ --group=nginx \ --with-http_stub_status_module \ --with-http_ssl_module \ --add-module=/usr/local/nginx-module-vts
make & make install
vhost_traffic_status_zone;
vhost_traffic_status_filter_by_host on;
server{ 84 vhost_traffic_status off; #在不想统计流量的 server 区域,可禁用 vhost_ traffic_status 85 listen 8080; 86 allow 127.0.0.1; 87 allow 192.168.19.24; #设置为 prometheus 的 ip 地址 88 89 location /nginx-status { 90 stub_status on; 91 access_log off; 92 } 93 94 location /status { 95 vhost_traffic_status_display; 96 vhost_traffic_status_display_format html; 97 } 98 }
假如 nginx 没有规范配置 server_name 或者无需进行监控的 server 上,那么建议在此 vhost 上禁用统计监控功能。否则会出现 127.0.0.1、hostname 等的域名监控信息。
ln -s /usr/local/nginx/sbin/nginx /usr/local/sbin/
[Unit] Description=nginx After=network.target [Service] Type=forking PIDFile=/usr/local/nginx/logs/nginx.pid ExecStart=/usr/local/nginx/sbin/nginx ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s QUIT $MAINPID PrivateTmp=true [Install] WantedBy=multi-user.target
http://192.168.19.29:8080/status
cat > /usr/lib/systemd/system/nginx-exporter.service <<'EOF' [Unit] Description=nginx-exporter Documentation=https://prometheus.io/ After=network.target [Service] Type=simple ExecStart=/usr/local/bin/nginx-vts-exporter -nginx.scrape_uri=http://localhost:8080/status/format/json ExecReload=/bin/kill -HUP $MAINPID Restart=on-failure [Install] WantedBy=multi-user.target EOF
- job_name: "nginx" metrics_path: "/metrics" scheme: http static_configs: - targets: - 192.168.19.29:9913 labels: from: nginx_exporter
部署 Grafana#
yum install -y grafana-7.4.0-1.x86_64.rpm
https://grafana.com/grafana/dashboards
总结#
市面上常用的监控系统有哪些? 老牌传统的:Zabbix Nagios Cacti 云原生时代的:Prometheus 夜莺 Zabbix和Prometheus的区别?如何选择? Zabbix:更适用于传统业务架构的物理机、虚拟机环境的监控,对容器的支持比较差;数据存储主要采用的是关系型数据库,会随着被监控节点数量的增加,关系型数据库的压力也会变大,监控数据的读写也会变慢;对大规模集群监控的性能比Prometheus要弱一些,可适用于单集群不超过2000台节点的场景。 Prometheus:还能支持云环境、K8S容器集群的监控,是目前容器监控最好的解决方案;数据存储采用的是时序数据库,大大的节省存储空间,还能提升查询效率;单集群能支持的节点规模更大,通常超过2000台节点、业务服务数量大于1000个的时候建议直接上Prometheus。 Prometheus 是一个开源的监控系统 + 时间序列数据库。数据模型是 时间序列数据,格式为 指标度量名称{键值对标签集} Prometheus的主要组件: prometheus server:是Prometheus服务的核心组件。通过http pull拉取的方式从监控目标采集监控指标数据(时序数据);作为时序数据库持久化存储监控指标数据; 根据告警规则生成告警统招推送给alertmanager;内建service discovery自动服务发现功能(支持基于文件、consul、K8S等自动发现方式) exporter:指标暴露器,用于对原生不支持prometheus直接采集监控指标数据的系统或应用收集监控指标数据并转换格式供给prometheus server拉取采集 node-exporter、kube-state-metrics、nginx/mysqld/redis-exporter、cADvisor、blackbox-exporter alertmanager:接收prometheus server发来的告警通知,负责对告警通知分组、去重,再路由发送给接收人(支持email、钉钉、企业微信等方式发送) pushgateway:作为临时中转站,接收一些短期任务或只能push推送数据的任务发送的监控指标数据,用于临时存储监控指标数据并统一供给prometheus server拉取采集 grafana:外置的监控数据展示平台,接入prometheus的数据源,通过promQL查询数据,以图形化形式展示监控数据 Prometheus工作流程: 1)prometheus server通过http pull拉取的方式从监控目标target(通过exporter或pushgateway暴露的http接口)拉取监控指标数据 2)prometheus server将采集到的监控指标数据通过时序数据库持久化存储在本地磁盘或外置存储中 3)prometheus server将采集到的监控指标数据与本地配置的额告警规则进行计算比对,如果触发告警则生成告警通知推送给alertmanager 4)alertmanager接收到prometheus server发来的告警通知后,对告警通知分组、去重,再通过email/钉钉/企业微信等方式发送给接收人 5)prometheus支持原生的web UI或grafana接入prometheus数据源,通过promQL查询数据,以图形化形式展示监控数据 prometheus支持使用influxdb等大型的时序数据库作为外置远端存储,实现长期存储历史数据。 可基于thanos实现prometheus集群的高可用(主要方式是在K8S上部署,通过边车模式与prometheus部署在同一个Pod里共享监控数据) 还可通过联邦集群实现将多个prometheus集群的数据进行聚合汇总,统一展示和管理 Prometheus数据采集设置 scrape_configs: - job_name: XXX #自定义监控任务的名称 metrics_path: "/metrics" #指定获取监控数据的URL路径,一般都是 /metrics scheme: http #指定拉取监控数据的协议,http(默认值) 或 https #定义静态配置的监控目标 static_configs: - targets: #指定监控目标节点的IP和exporter的端口 - IP1:exporter端口 .... labels: #自定义简历目标的标签 key: value
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· Docker 太简单,K8s 太复杂?w7panel 让容器管理更轻松!