构建企业级监控平台系列（十二）：Prometheus 入门与安装

民工哥

发布于 2023-10-23 19:57:04

7510

发布于 2023-10-23 19:57:04

Prometheus 概述

Prometheus 是一个开源的服务监控系统和时序数据库，最初由SoundCloud开发的开源的系统监控和报警工具包。自2012年诞生以来，被许多公司和组织采用，该项目拥有非常活跃的社区和开发者。Prometheus 现在是一个独立的开源项目，独立于任何公司进行维护。为了证明这一点，Prometheus 于2016年加入了云原生计算基金会CNCF，成为了继Kubernetes之后的第二个CNCF托管项目。

Prometheus收集和存储metrics作为时间序列数据，也就是说，metrics与它被记录的时间戳以及称为标签的可选键值对一起被存储。

Prometheus 能够直接把API Server作为服务发现系统使用，进而动态发现和监控集群中的所有可被监控的对象。

官网地址：https://prometheus.io
github 地址：https://github.com/prometheus

更多关于企业级监控平台系列的学习文章，请参阅：构建企业级监控平台，本系列持续更新中。

Prometheus 主要特点

多维的数据模型(基于时间序列的Key、value键值对)
灵活的查询和聚合语言PromQL
提供本地存储和分布式存储
通过基于HTTP和HTTPS的Pull模型采集时间序列数据（pull数据的拉取，时间序列:每段时间点的数据值指标，持续性的产生。横轴标识时间，纵轴为数据值，一段时间内数值的动态变化，所有的点连线形成大盘式的折线图)
可利用Pushgateway (Prometheus的可选中间件）实现Push模式
可通过动态服务发现或静态配置发现目标机器（通过consul自动发现和收缩)
支持多种图表和数据大盘

Prometheus 原理及架构图

原理

Prometheus的基本原理是通过 HTTP 周期性抓取被监控组件的状态，任意组件只要提供对应的 HTTP 接口并且符合Prometheus定义的数据格式，就可以接入Prometheus监控。

Prometheus的实现架构并不复杂，原理其实就是收集数据、处理数据、可视化展示，再进行数据分析以及报警处理。但其珍贵之处在于提供了一整套可行的解决方案，并且形成了一整个生态，能够极大地降低我们的研发成本。

架构图（来自Prometheus官网）

适用场景

Prometheus适用于记录文本格式的时间序列数据。既适合以机器为中心的监控，也适合面向服务的体系结构的监控。在微服务的世界里，对多维数据收集和查询的支持是一个特别的优势。

Prometheus 是专为提高系统可靠性而设计的，可以在断电期间快速诊断问题，每个 Prometheus Server 都是相互独立的，不依赖于网络存储或其他远程服务。当基础架构出现故障时，可以通过 Prometheus 快速定位故障点，而且不会消耗大量的基础架构资源。

Prometheus 非常重视可靠性，即使在出现故障的情况下，也可以随时查看有关系统的可用统计信息。如果需要百分之百的准确度，例如按请求数量计费，那么 Prometheus 不太适合，因为它收集的数据可能不够详细完整。这种情况下，最好使用其他系统来收集和分析数据以进行计费，并使用 Prometheus 来监控系统的其余部分。

Prometheus 工作模式与流程

Prometheus的工作模式：

Prometheus Server 基于服务发现（Service Discovery）机制或静态配置获取要监视的目标（Target），并通过每个目标上的指标exporter来采集（Scrape）指标数据；
Prometheus Server 内置了一个基于文件的时间序列存储来持久存储指标数据，用户可使用PromQL接口来检索数据，也能够按需将告警需求发往A1ertmanager完成告警内容发送；
一些短期运行的作业的生命周期过短，难以有效地将必要的指标数据供给到Server端，它们一般会采用推送（Push）方式输出指标数据，Prometheus借助于Pushgateway 接收这些推送的数据，进而由server端进行抓取。

Prometheus的工作流程

Prometheus以prometheus Server 为核心，用于收集和存储时间序列数据。Prometheus Server从监控目标中通过pull方式拉取指标数据，或通过pushgateway 把采集的数据拉取到Prometheus server中。
Prometheus server 把采集到的监控指标数据通过TSDB存储到本地HDD/ssD中。
Prometheus 采集的监控指标数据按时间序列存储，通过配置报警规则，把触发的报警发送到Alertmanager。
Alertmanager 通过配置报警接收方，发送报警到邮件、钉钉或者企业微信等。
Prometheus 自带的Web UI 界面提供PromQL 查询语言，可查询监控数据。
Grafana 可接入Prometheus 数据源，把监控数据以图形化形式展示出。

时序数据介绍

时序数据，是在一段时间内通过重复测量(measurement）而获得的观测值的集合将这些观测值绘制于图形之上，它会有一个数据轴和一个时间轴，服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据。

数据来源

prometheus基于HTTP call (http/https请求），从配置文件中指定的网络端点(endpoint/IP:端口)上周期性获取指标数据
很多环境、被监控对象，本身是没有直接响应/处理http请求的功能，promethens-exporter则可以在被监控端收集所需的数据，收集过来之后，还会做标准化，把这些数据转化为prometheus可识别，可使用的数据（兼容格式）

收集数据

监控概念 : 白盒监控、黑盒监控
白盒监控 : 自省方式，被监控端内部，可以自己生成指标，只要等待监控系统来采集时提供出去即可
黑盒监控 : 对于被监控系统没有侵入性，对其没有直接"影响"，这种类似于基于探针机制进行监控（ snmp协议)

Prometheus支持通过三种类型的途径从目标上"抓取（Scrape)"指标数据（基于白盒监控)。

Exporters一>工作在被监控端，周期性的抓取数据并转换为pro兼容格式等待prometheus来收集，自己并不推送。
Instrumentation一>指被监控对象内部自身有数据收集、监控的功能，只需要prometheus直接去获取。
Pushgateway —>短周期5s-10s的数据收集脚本。

更多关于企业级监控平台系列的学习文章，请参阅：构建企业级监控平台，本系列持续更新中。

Prometheus(获取方式)

Prometheus同其它TSDB相比有一个非常典型的特性:它主动从各Target上拉取(pull)数据，而非等待被监控端的推送(push)

两个获取方式各有优劣，其中，Pull模型的优势在于:

集中控制:有利于将配置集在Prometheus server上完成，包括指标及采取速率等;
Prometheus的根本目标在于收集在target上预先完成聚合的聚合型数据，而非一款由事件驱动的存储系统通过targets(标识的是具体的被监控端)
比如配置文件中的targets : [ ‘localhost:9090’]

Prometheus的部署

下载地址：https://prometheus.io/download/

[root@localhost ~]# tar zxvf prometheus-2.27.1.linux-amd64.tar.gz -C /usr/local/
---
[root@localhost ~]# cd /usr/local/
[root@localhost local]# cd prometheus-2.27.1.linux-amd64/
[root@localhost prometheus-2.27.1.linux-amd64]# ./prometheus
---
#另开一台终端
[root@localhost ~]# netstat -natp | grep 9090
tcp6       0      0 :::9090                 :::*                    LISTEN      10161/./prometheus  
tcp6       0      0 ::1:9090                ::1:46988               ESTABLISHED 10161/./prometheus  
tcp6       0      0 ::1:46988               ::1:9090                ESTABLISHED 10161/./prometheus  
---

登录网址192.168.223.20：9090

#如果有warning报错的话：
[root@localhost ~]# ntpdate ntp1.aliyun.com
 7 Dec 22:53:32 ntpdate[21741]: adjust time server 120.25.115.20 offset 0.002993 sec
 [root@localhost ~]# init 6
 #进入网页再刷新一下即可

访问192.168.223.20:9090/metrics

Prometheus 配置文件介绍

Prometheus通过命令行标志和配置文件进行配置。虽然命令行标志配置了不可变的系统参数（例如存储位置，保留在磁盘和内存中的数据量等），但配置文件定义了与抓取作业及其实例相关的所有内容，以及哪些规则文件加载。要查看所有可用的命令行标志，请运行./prometheus -h。

Prometheus可以在运行时重新加载其配置。如果新配置格式不正确，则不会应用更改。通过向Prometheus进程发送 SIGHUP 信号或使用HTTP 发送reload的POST请求命令发送（ --web.enable-lifecycle 启用标志时）来触发配置重新加载。这也将重新加载任何已配置的规则文件。

配置文件中的占位符

该文件以YAML格式编写，由下面描述的方案定义。括号表示参数是可选的。对于非列表参数，该值设置为指定的默认值。

通用占位符定义如下：

<boolean>：一个可以取值true或的值的布尔值false
<duration>：与正则表达式匹配的持续时间 [0-9]+(ms|[smhdwy])
<labelname>：与正则表达式匹配的字符串 [a-zA-Z_][a-zA-Z0-9_]*
<labelvalue>：一串unicode字符
<filename>：当前工作目录中的有效路径
<host>：由主机名或IP后跟可选端口号组成的有效字符串
<path>：有效的URL路径
<scheme>：一个可以取值http或的字符串https
<string>：常规字符串
<secret>：一个秘密的常规字符串，例如密码
<tmpl_string>：使用前模板展开的字符串

其他占位符是单独指定的。

配置文件示例解析

#配置文件中的全局配置
global:
  scrape_interval:     15s   #多久 收集 一次数据
  evaluation_interval: 30s   #多久评估一次 规则
  scrape_timeout:      10s   #每次 收集数据的 超时时间
  #当Prometheus和外部系统(联邦, 远程存储, Alertmanager)通信的时候，添加标签到任意的时间序列或者报警
  external_labels:
    monitor: codelab
    foo:     bar
 
#加载规则文件, 可以使用通配符
#规则文件指定全局变量列表。从所有匹配的文件中读取规则和警报。
rule_files:
- "first.rules"
- "my/*.rules"
 
#远程写入功能相关的设置
remote_write:
  - url: http://remote1/push
    write_relabel_configs:
    - source_labels: [__name__]
      regex:         expensive.*
      action:        drop
  - url: http://remote2/push
 
#远程读取相关功能的设置
remote_read:
  - url: http://remote1/read
    read_recent: true
  - url: http://remote3/read
    read_recent: false
    required_matchers:
      job: special
 
#收集数据-配置列表
#scrape_config部分指定了一组目标和参数，描述了如何抓取它们。
#在一般情况下，一个抓取资源配置指定一个作业。在高级配置中，这可能会改变。
#可以通过static_configs参数静态配置目标，也可以使用支持的服务发现机制之一动态发现目标。
#此外，relabel_configs 允许在抓取之前对任何目标及其标签进行高级修改。
 
scrape_configs:
- job_name: prometheus  #必须配置, 自动附加的job labels, 必须唯一
  honor_labels: true   #标签冲突, true 为以抓取的数据为准并忽略服务器中的,false 为通过重命名来解决冲突。
  
  # scrape_interval is defined by the configured global (15s).
  # scrape_timeout is defined by the global default (10s).
  metrics_path:     '/metrics'
  # scheme defaults to 'http'.
 
  #文件服务发现配置列表
  #基于文件的服务发现提供了一种更通用的方法来配置静态目标，并用作插入自定义服务发现机制的接口。
  #它读取一组包含零个或多个<static_config>列表的文件。
  #对所有定义文件的更改都会通过磁盘监视检测到并立即应用。
  #文件可以yaml或json格式提供。仅应用形成良好目标组的更改。
  file_sd_configs:
    - files:  # 从这些文件中提取目标
      - foo/*.slow.json
      - single/file.yml
      refresh_interval: 10m  #刷新文件的时间间隔
  #使用job名作为label的静态配置目录的列表
 
  static_configs:
  - targets: ['localhost:9090', 'localhost:9191']
    labels:
      my:   label
      your: label
  #目标节点 重新打标签的配置列表。
  #重新标记是一个功能强大的工具，可以在抓取目标之前动态重写目标的标签集。
  #可以配置多个，按照先后顺序应用
  relabel_configs:
  - source_labels: [job, __meta_dns_name]   
   #从现有的标签中选择源标签, 最后会被替换，保持，丢弃
    regex:         (.*)some-[regex]  
   #正则表达式, 将会提取source_labels中匹配的值
    target_label:  job   #在替换动作中将结果值写入的标签.
    replacement:   foo-${1}  
   #如果正则表达匹配, 那么替换值. 可以使用正则表达中的 捕获组
    #action defaults to 'replace'
  - source_labels: [abc]  #将abc标签的内容复制到cde标签中
    target_label:  cde
  - replacement:   static
    target_label:  abc
  - regex:
    replacement:   static
    target_label:  abc
  bearer_token_file: valid_token_file  #可选的, bearer token 文件的信息
 
#Alertmanager相关的配置
alerting:
  alertmanagers:
  - scheme: https
    static_configs:
    - targets:
      - "1.2.3.4:9093"
      - "1.2.3.5:9093"

更多关于企业级监控平台系列的学习文章，请参阅：构建企业级监控平台，本系列持续更新中。

Prometheus生态组件

prometheus-server

服务核心组件，采用pull方式收集监控数据，通过http协议传输。并存储时间序列数据。Prometheus server 由三个部分组成：Retrival，Storage，PromQL。

Retrieval：负责在活跃的target 主机上抓取监控指标数据。
Storage：存储，主要是把采集到的数据存储到磁盘中。默认为15天（可修改）。
PromQL：是Prometheus提供的查询语言模块。

client Library

客户端库，目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径，用于基于应用程序内建的测量系统。

Exporters

指标暴露器，负责收集不支持内建Instrumentation的应用程序或服务的性能指标数据，并通过HTTP接口供Prometheus Server获取。换句话说，Exporter 负责从目标应用程序上采集和聚合原始格式的数据，并转换或聚合为Prometheus格式的指标向外暴露。

常用的 Exporters

Node-Exporter：用于收集服务器节点（例如k8s）的物理指标状态数据，如平均负载、CPU、内存、磁盘、网络等资源信息的指标数据，需要部署到所有运算节点。
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：监控业务容器存活性。

Service Discovery

服务发现，用于动态发现待监控的Target，Prometheus支持多种服务发现机制：文件、DNS、Consul、Kubernetes等等。

服务发现可通过第三方提供的接口，Prometheus查询到需要监控的Target列表，然后轮询这些Target 获取监控数据。该组件目前由Prometheus Server内建支持

Alertmanager

是一个独立的告警模块，从Prometheus server端接收到“告警通知”后，会进行去重、分组，并路由到相应的接收方，发出报警，常见的接收方式有：电子邮件、钉钉、企业微信等。

Prometheus Server 仅负责生成告警指示，具体的告警行为由另一个独立的应用程序AlertManager负责；告警指示由 Prometheus Server基于用户提供的告警规则周期性计算生成，Alertmanager 接收到Prometheus Server发来的告警指示后，基于用户定义的告警路由向告警接收人发送告警信息。

Pushgateway

类似一个中转站，Prometheus的server端只会使用pull方式拉取数据，但是某些节点因为某些原因只能使用push方式推送数据，那么它就是用来接收push而来的数据并暴露给Prometheus的server拉取的中转站。可以理解成目标主机可以上报短期任务的数据到Pushgateway，然后Prometheus server 统一从Pushgateway拉取数据。

Grafana

是一个跨平台的开源的度量分析和可视化工具，可以将采集的数据可视化的展示，并及时通知给告警接收方。其官方库中具有丰富的仪表盘插件。

Prometheus监控体系

系统层监控（需要监控的数据)

CPU、Load、Memory、swap、disk i/o、process等
网络监控：网络设备、工作负载、网络延迟、丢包率等

存储监控

存储性能监控方面：存储通常监控块的读写速率，IOPS。读写延迟，磁盘用量等；文件存储通常监控文件系统inode。读写速度、目录权限等。
存储系统监控方面：不同的存储系统有不同的指标，例如，对于ceph存储需要监控OSD, MON的运行状态，各种状态pg的数量以及集群IOPS等信息。
存储设备监控方面：对于构建在x86服务器上的存储设备，设备监控通过每个存储节点上的采集器统一收集磁盘、SSD、网卡等设备信息；存储厂商以黑盒方式提供商业存储设备，通常自带监控功能，可监控设备的运行状态，性能和容量的。

服务器监控

CPU：涉及整个 CPU 的使用量、用户态百分比、内核态百分比，每个 CPU 的使用量、等待队列长度、I/O 等待百分比、CPU 消耗最多的进程、上下文切换次数、缓存命中率等。
内存：涉及内存的使用量、剩余量、内存占用最高的进程、交换分区大小、缺页异常等。
网络 I/O：涉及每个网卡的上行流量、下行流量、网络延迟、丢包率等。
磁盘 I/O：涉及硬盘的读写速率、IOPS、磁盘用量、读写延迟等。

中间件及基础设施类监控端监控（移动APP、特定程序等)

消息中间件:kafka、RocketMQ、等消息代理
WEB服务器容器:tomcat、weblogic/apache/php/spring系列
数据库/缓存数据库:MysQL、PostgresQL、MogoDB、es、redis

应用层监控

用于衡量应用程序代码状态和性能
监控的分类:黑盒监控，白盒监控( promtheus)
- 白盒监控：自省指标，等待被下载（只需要去拿就行）
- 黑盒指标：基于探针的监控方式，不会主动干预、影响数据（摄像头这种）

业务层监控

用于衡量应用程序的价值，如电商业务的销售量，ops、dau日活、转化率等，业务接口:登入数量，注册数、订单量、搜索量和支付量。

Prometheus的局限性

Prometheus是一款指际监控系统，不适合存储事件及日志等；它更多地展示的是趋势性的监控，而非精准数据；

Prometheus认为只有最近的监控数据才有查询的需要，其本地存储的设计初衷只是保存短期（例如一个月）数据，因而不支持针对大量的历史数据进行存储；若需要存储长期的历史数据，建议基于远端存储机制将数据保存于InfluxDB或openTsDB等系统中；

Prometheus的集群机制成熟度不高，可基于Thanos（和灭霸是一个单词）实现Prometheus集群的高可用及联邦集群。

mysql、nginx、k8s等使用多个不同的Prometheus收集，形成联邦集群。更多关于企业级监控平台系列的学习文章，请参阅：构建企业级监控平台，本系列持续更新中。

参考：https://blog.csdn.net/weixin_67470255/article/ details/126258467 https://stevelu.blog.csdn.net/article /details/126080391

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2023-10-15，如有侵权请联系 cloudcommunity@tencent.com 删除

存储

本文分享自民工哥技术之路微信公众号，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！

登录后参与评论

0 条评论

热度