---

什么是 Prometheus？一文带你快速入门，深入理解云原生监控核心

在当今复杂多变的 IT 环境中，无论是传统的物理机房、虚拟化平台，还是日益流行的容器化、微服务架构和云原生应用，监控都是确保系统稳定、可靠运行不可或缺的一环。想象一下，当你的服务出现延迟、错误率飙升，或者某个节点负载过高时，如果你没有一个有效的监控系统，就如同在黑暗中摸索，难以快速定位问题根源。

监控不仅仅是为了在事故发生时报警，它更是理解系统健康状况、性能瓶颈、容量规划以及优化决策的基石。一个强大的监控系统能够提供实时的洞察力，帮助我们防患于未然。

在众多监控解决方案中，Prometheus 近年来脱颖而出，尤其在云原生和容器化领域，它几乎成为了事实上的标准。那么，究竟什么是 Prometheus？它为何如此受欢迎？又该如何快速上手使用它呢？本文将带你一步步揭开 Prometheus 的神秘面纱。

第一部分：什么是 Prometheus？核心概念与起源

Prometheus 是一个开源的系统监控和报警工具包。它由 SoundCloud 在 2012 年创建，作为其内部监控系统的解决方案，并在 2015 年开源。自此以后，Prometheus 在社区的积极参与下迅速发展，并于 2016 年加入了云原生计算基金会（CNCF），成为继 Kubernetes 之后的第二个毕业项目，这充分证明了其在云原生生态中的重要地位和成熟度。

Prometheus 的核心是一款高性能的时序数据库 (Time Series Database – TSDB)，专门用于存储以时间为序的指标数据。但 Prometheus 不仅仅是一个数据库，它是一个完整的监控生态系统，包含数据采集、存储、查询、可视化和报警等多个功能模块。

Prometheus 的核心特性：

1. 多维度数据模型 (Multi-dimensional Data Model): 这是 Prometheus 最强大的特性之一。它存储的所有时间序列数据都由指标名称（metric name）和一组键值对标签（labels）唯一标识。这种多维度模型使得你可以非常灵活地通过这些标签对数据进行过滤、聚合和分组，从而深入分析不同维度下的系统行为。
2. 灵活的查询语言 PromQL (Prometheus Query Language): Prometheus 提供了一种强大且灵活的查询语言 PromQL。使用 PromQL，你可以轻松地选择、聚合、过滤、计算和组合时间序列数据，执行复杂的分析和生成有意义的图表或报警规则。
3. Pull 模型的数据采集 (Pull Model): Prometheus 主要采用拉取（Pull）的方式从目标服务（通常是运行着Exporter的服务）暴露的 HTTP 端点周期性地拉取（Scrape）指标数据。这种模型简化了目标服务的配置，只需要暴露一个接口即可，由 Prometheus 负责连接和采集。
4. 独立的服务端架构 (Standalone Server): Prometheus 服务器本身不依赖于分布式存储或外部网络存储，其数据存储在本地磁盘上（尽管可以通过扩展支持远程存储）。这使得 Prometheus 易于部署和管理。
5. 强大的报警机制 (Powerful Alerting): Prometheus 可以根据 PromQL 表达式定义报警规则，并在满足条件时将报警信息发送到 Alertmanager。
6. 丰富的集成生态 (Rich Ecosystem): Prometheus 拥有庞大的 Exporter 生态系统，可以轻松采集各种不同的系统和服务（如操作系统、数据库、消息队列、Web服务器等）的指标。同时，它与 Grafana 等可视化工具无缝集成，提供美观且功能强大的仪表盘。
7. 服务发现 (Service Discovery): Prometheus 支持多种服务发现机制（如 Kubernetes, Consul, EC2 等），可以动态发现需要监控的目标，这对于动态变化的云原生环境至关重要。

与传统监控系统的区别

传统的监控系统，如 Zabbix, Nagios 等，通常采用 Push 模型，即在被监控的主机上安装一个代理（Agent），由 Agent 主动将数据推送到中央服务器。它们的数据模型也相对简单，通常是主机-项（Item）的结构。

Prometheus 的区别在于：

• 数据模型: 从简单的扁平模型转向多维度的标签模型，提供了极大的查询灵活性。
• 数据采集: 主要采用 Pull 模型，简化了被监控端的部署（只需运行 Exporter）。
• 查询能力: PromQL 远比传统系统的简单表达式强大，能进行更复杂的聚合和计算。
• 架构: 更适合动态变化的云环境和微服务架构。

正因为这些特性，Prometheus 在云原生领域迅速崛起，成为监控基础设施和应用的优选方案。

第二部分：Prometheus 生态圈：核心组件介绍

Prometheus 不仅仅是一个单独的服务器，而是一个由多个组件组成的生态系统。理解这些组件及其之间的关系，对于理解 Prometheus 的工作原理至关重要。

(这是一个概念图，用于说明组件关系，实际部署可能有所不同)

核心组件包括：

1. Prometheus Server: 这是 Prometheus 的核心。它负责：
   • Scraping: 周期性地从配置的目标端点拉取指标数据。
   • TSDB: 将采集到的数据存储在本地的时间序列数据库中。
   • Rule Evaluation: 根据预定义的规则评估报警条件或生成新的时间序列（录制规则）。
   • Querying: 提供 HTTP API 供查询语言 PromQL 使用，以及内置的 Web UI。
2. Exporters: Exporter 是一个独立的应用程序，运行在需要被监控的服务或主机旁边。它的作用是将目标服务的内部指标转换为 Prometheus 可以理解和拉取的格式，并通过 HTTP 接口暴露出来（通常在 /metrics 路径）。Prometheus 社区提供了大量的官方和第三方 Exporters，覆盖了操作系统（Node Exporter）、各种数据库（MySQL Exporter, MongoDB Exporter）、消息队列（Kafka Exporter）、Web 服务器（Apache Exporter, Nginx Exporter）等。你也可以使用客户端库为自己的应用程序编写自定义 Exporter。
3. Pushgateway: Prometheus 推荐使用 Pull 模型采集数据。但对于一些生命周期短暂、无法长时间暴露 HTTP 端点的任务（例如批处理作业），Pushgateway 提供了一个折衷方案。短暂任务可以将指标推送（Push）到 Pushgateway，然后由 Prometheus 从 Pushgateway 拉取数据。注意： Pushgateway 不应用于持久性服务，因为它会掩盖实例的健康状况（即使实例挂了，Pushgateway 还会保留其最后一次推送的数据）。
4. Alertmanager: Alertmanager 负责接收 Prometheus Server 发送过来的报警信息。它处理报警的去重、分组、抑制以及路由到不同的通知接收器（如邮件、Slack、PagerDuty、Webhook 等）。Alertmanager 是一个独立的组件，与 Prometheus Server 解耦，以便于高可用部署和灵活的报警策略管理。
5. Client Libraries: Prometheus 提供了多种编程语言的客户端库（Go, Java, Python, Ruby 等）。这些库允许开发者轻松地在其应用程序中埋点（Instrument），暴露业务或应用层面的指标，从而创建自定义的 Exporter。
6. Web UI: Prometheus Server 内置了一个基本的 Web 用户界面，用于查看当前的采集目标状态、执行 PromQL 查询并查看图表。但对于复杂的仪表盘和可视化，通常会与 Grafana 集成。
7. Service Discovery: 为了适应动态环境，Prometheus 支持多种服务发现机制，如 DNS、文件、Consul、Kubernetes API、EC2 等。通过服务发现，Prometheus 可以自动发现需要监控的目标并更新其配置，而无需手动修改配置文件。

理解了这些组件，你就 grasp 了 Prometheus 生态的基本脉络：Prometheus Server 负责核心的采集、存储、查询和规则评估；Exporters 负责将被监控对象的数据暴露出来；Alertmanager 负责处理和分发报警；Pushgateway 是特殊场景下的推送代理；Client Libraries 帮助应用自身暴露指标；Web UI 和 Grafana 提供可视化；服务发现自动化目标管理。

第三部分：Prometheus 数据模型：指标与标签

Prometheus 的数据模型是其强大之处的基石。所有数据都被存储为时间序列（Time Series）。一个时间序列是某个特定指标在不同时间点的一系列带有时间戳的值。

每个时间序列都由以下两部分唯一标识：

1. 指标名称 (Metric Name): 一个描述被测量特征的字符串，例如 http_requests_total 表示 HTTP 请求的总数，node_cpu_usage_seconds_total 表示 CPU 使用的总秒数。指标名称通常包含被测量的是什么（如 http_requests）以及单位（如 total ）。
2. 一组标签 (Labels): 一组键值对，用于区分同一指标的不同维度。例如，http_requests_total 可以通过 method="POST" 和 handler="/users" 等标签来区分不同 HTTP 方法或不同处理器的请求。

完整的时间序列标识符看起来像这样：

metric_name{label_name="label_value", another_label="another_value"}

例如：

• http_requests_total{method="POST", handler="/users", status="200"}：表示所有针对 /users 路径、使用 POST 方法且返回状态码为 200 的 HTTP 请求总数。
• node_cpu_usage_seconds_total{cpu="0", mode="idle"}：表示第一个 CPU 核心（索引为 0）在空闲模式下花费的总秒数。

标签的重要性： 标签是 Prometheus 实现多维度分析的关键。你可以通过标签过滤数据（例如，只看某个特定实例或某个特定服务的指标），也可以通过标签进行聚合（例如，按 handler 标签聚合所有请求的总数）。这种灵活性使得 Prometheus 能够轻松应对微服务架构中服务实例的动态变化、不同版本的部署以及 A/B 测试等场景。

指标类型 (Metric Types)

Prometheus 定义了四种核心的指标类型：

1. Counter (计数器): 一个单调递增的累计指标，其值只能增加或在重启时归零。常用于统计请求总数、错误总数、任务完成总数等。例如：http_requests_total。通常使用 _total 后缀命名。
2. Gauge (仪表盘): 一个可以任意变化的数值指标，其值可增可减。常用于测量当前状态，如 CPU 使用率、内存使用量、队列长度、温度等。例如：node_cpu_usage_percent, memory_usage_bytes。
3. Histogram (直方图): 用于采样观测结果（如请求持续时间、响应大小），并将其分布在可配置的桶（Buckets）中。它提供了观测值的数量 (_count)、所有观测值的总和 (_sum)，以及每个桶中小于等于上边界的观测值数量 (_bucket)。通过这些数据，可以计算分位数（如 P95、P99），了解数据分布的统计特征。例如：http_request_duration_seconds。
4. Summary (摘要): 类似于 Histogram，也用于采样观测结果，提供观测值的总数 (_count) 和总和 (_sum)。但它在客户端直接计算分位数（例如，配置计算 P50, P95, P99）。相比 Histogram，Summary 不需要配置桶，但计算分位数更消耗客户端资源，且不适合在聚合后计算全局分位数。在 Prometheus 推荐优先使用 Histogram，并在 PromQL 中使用 histogram_quantile() 函数计算分位数。

理解这些指标类型有助于正确地对你的应用程序或服务进行埋点（instrumentation），选择合适的类型来暴露你关心的指标。

第四部分：数据采集：Pull 模型与配置

Prometheus 主要通过拉取（Pull）的方式采集数据。这意味着 Prometheus 服务器会主动连接配置的目标，获取指标数据。

工作流程：

1. 配置目标: 在 Prometheus 的配置文件 (prometheus.yml) 中定义需要监控的目标（Targets）。
2. 服务发现 (可选): 如果使用服务发现机制，Prometheus 会定期查询服务发现源，获取最新的目标列表。
3. 抓取 (Scraping): Prometheus 按照配置的抓取间隔 (scrape_interval)，周期性地向每个目标的 /metrics HTTP 端点发送请求。
4. 数据处理: 接收到目标的响应（通常是文本格式）后，Prometheus 解析数据，将指标名称、标签、值和当前时间戳组合成一个时间序列样本。
5. 存储: 将新的时间序列样本写入本地的时间序列数据库。

配置示例 (prometheus.yml)

Prometheus 的核心配置是 prometheus.yml 文件。以下是一个简单的示例：

“`yaml

全局配置

global:
# 默认的抓取间隔。每 15 秒抓取一次目标。
scrape_interval: 15s
# 默认的规则评估间隔。
evaluation_interval: 15s

Alertmanager 配置

如果需要发送报警，需要配置 Alertmanager 的地址

alerting:
alertmanagers:
– static_configs:
– targets: [‘localhost:9093’] # Alertmanager 的默认端口

规则文件配置

指定报警规则或录制规则的文件位置

rule_files:
# – “first_rules.yml”
# – “second_rules.yml”

抓取配置

scrape_configs:
# 监控 Prometheus 自身的 job
– job_name: ‘prometheus’

# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.

# 静态配置目标列表
static_configs:
  - targets: ['localhost:9090'] # Prometheus 服务器自身的默认端口

# 监控一个 Node Exporter 的 job
– job_name: ‘node_exporter’
static_configs:
– targets: [‘your_node_exporter_ip:9100’] # 替换为你的 Node Exporter 地址和端口

# 示例：使用文件服务发现监控其他服务
# – job_name: ‘my_service’
# file_sd_configs:
# – names:
# – ‘targets/my_service_targets.json’ # 指定服务发现文件

“`

解释：

• global: 定义全局参数，如默认抓取间隔 scrape_interval 和规则评估间隔 evaluation_interval。
• alerting: 配置 Alertmanager 的连接地址。
• rule_files: 指定包含报警规则和录制规则的文件。
• scrape_configs: 这是最重要的部分，定义了 Prometheus 要监控的所有目标。每个 scrape_config 定义一个 job。
  • job_name: 一个标识符，作为自动添加到所有从这个 job 抓取的时间序列上的 job 标签的值。
  • static_configs: 最简单的服务发现方式，直接列出固定的目标地址（host:port）。
  • targets: 一个列表，包含该 job 下的所有目标地址。
  • 每个抓取到的时间序列会自动添加 job 标签（值为 job_name）和 instance 标签（值为目标的 host:port）。

Prometheus 启动时会读取这个配置文件，并开始按照配置抓取数据。修改配置后，通常需要重启 Prometheus 或向其发送 SIGHUP 信号使其重新加载配置。

第五部分：查询数据：PromQL 详解

Prometheus Query Language (PromQL) 是 Prometheus 的灵魂，它是一种功能强大的函数式查询语言，用于对时间序列数据进行实时查询和分析。通过 PromQL，你可以从存储的大量指标数据中提取有意义的信息。

PromQL 查询返回的数据类型可以是：

• Instant Vector (瞬时向量): 在单个时间点上选定的所有时间序列。这是最常见的查询结果类型。
• Range Vector (范围向量): 在某个时间范围内选定的所有时间序列。通常用于计算时间序列的变化率或增量。
• Scalar (标量): 一个简单的数值浮点数。
• String (字符串): 一个简单的字符串（目前未使用）。

PromQL 基础语法：选择器

最基本的 PromQL 查询是选择时间序列。

• 通过指标名称选择:
  promql
http_requests_total
  这会返回所有名为 http_requests_total 的时间序列，以及它们在当前时间的最新值（瞬时向量）。

• 通过标签过滤:
  promql
http_requests_total{status="200"}
  选择 http_requests_total 指标中，标签 status 的值为 "200" 的所有时间序列。

• 更复杂的标签匹配:

  • = : 精确匹配标签值。
  • != : 不等于标签值。
  • =~ : 正则表达式匹配标签值。
  • !~ : 正则表达式不匹配标签值。

  “`promql

  选择所有方法是 POST 或 PUT 的请求

  http_requests_total{method=~”POST|PUT”}

  选择所有状态码不是 4xx 或 5xx 的请求

  http_requests_total{status!~”4..|5..”}
  “`

• 范围选择器 (Range Vector Selectors): 在标签选择器后面加上时间范围，用方括号 [] 表示，例如 [5m] 表示过去 5 分钟。
  promql
http_requests_total{status="200"}[5m]
  这会返回过去 5 分钟内，所有 status="200" 的 http_requests_total 时间序列的数据点集合（范围向量）。范围选择器不能直接绘图或作为报警规则，它们通常作为函数的参数。

PromQL 函数

PromQL 提供了丰富的函数来对时间序列数据进行处理和计算。

• rate(range_vector): 计算范围向量中时间序列的每秒平均增长率。常用于 Counter 类型指标，计算单位时间内的发生次数（例如，每秒请求数）。
  promql
# 计算过去 5 分钟内，每秒的 HTTP 请求数
rate(http_requests_total[5m])

• increase(range_vector): 计算范围向量中时间序列的增长总量。也常用于 Counter 类型指标，计算某个时间段内发生的总次数。
  promql
# 计算过去 5 分钟内，HTTP 请求的总增长量
increase(http_requests_total[5m])

• irate(range_vector): 计算范围向量中时间序列的瞬时增长率。它只看范围内的最后两个数据点。对 Counter 快速变化时更敏感，能更早反映变化趋势，但对短期波动更敏感。
  promql
# 计算过去 1 分钟内的瞬时每秒请求率
irate(http_requests_total[1m])

• sum(instant_vector): 对瞬时向量中的所有时间序列的值求和。

• avg(instant_vector): 对瞬时向量中的所有时间序列的值求平均。
• min(instant_vector): 对瞬时向量中的所有时间序列的值求最小值。
• max(instant_vector): 对瞬时向量中的所有时间序列的值求最大值。

• count(instant_vector): 统计瞬时向量中时间序列的数量。

  “`promql

  计算所有 Node Exporter 实例的 CPU 空闲率的平均值

  avg(node_cpu_usage_seconds_total{mode=”idle”})

  计算所有实例的总 HTTP 请求数

  sum(http_requests_total)
  “`

• histogram_quantile(phi, instant_vector): 计算 Histogram 指标的分位数。phi 是一个介于 0 和 1 之间的数值（如 0.99 表示 P99）。Instant vector 必须是 Histogram 的 _bucket 指标。
  promql
# 计算过去 5 分钟内 HTTP 请求延迟的 P99 分位数
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

PromQL 操作符

PromQL 支持各种算术、比较和逻辑运算符。

• 算术运算符: +, -, *, /, %, ^
• 比较运算符: ==, !=, >, <, >=, <=

• 逻辑运算符: and, or, unless (用于向量之间)

  “`promql

  计算 CPU 使用率 (非空闲模式的总和 / 总的 CPU 时间)

  1 – avg by (instance) (node_cpu_usage_seconds_total{mode=”idle”}) / avg by (instance) (node_cpu_usage_seconds_total)

  找出每秒请求数大于 100 的实例

  rate(http_requests_total[5m]) > 100
  “`

聚合操作符 (by 和 without)

聚合操作符用于在保留或移除特定标签的情况下对时间序列进行聚合。

• sum by (label1, label2): 按指定的标签分组后求和。结果时间序列只保留 label1 和 label2 标签。

• avg without (label1, label2): 按移除指定的标签后剩下的标签分组求平均。结果时间序列不包含 label1 和 label2 标签。

  “`promql

  按 handler 标签聚合，计算每个 handler 的总请求数

  sum by (handler) (http_requests_total)

  按实例和方法标签分组，计算每秒请求数

  rate(http_requests_total[5m]) by (instance, method)

  移除 status 标签后，按 job 和 instance 标签聚合计算每秒请求数

  sum without (status) (rate(http_requests_total[5m]))
  “`

PromQL 的强大之处在于你可以将这些选择器、函数、操作符和聚合器组合起来，构建复杂的查询来分析你的系统行为。

第六部分：可视化：Prometheus Web UI 与 Grafana

Prometheus Server 提供了内置的 Web UI（默认端口 9090），你可以通过 http://localhost:9090 访问。这个 UI 提供了：

• Status 页面: 查看目标（Targets）、服务发现状态、配置、规则、运行时信息等。
• Graph 页面: 在这里输入 PromQL 查询，并以表格或图表的形式查看结果。

Prometheus Web UI 的 Graph 功能虽然简单，但对于验证 PromQL 查询和快速查看指标非常有用。

然而，对于创建美观、功能丰富、可分享的仪表盘，以及从多个数据源获取数据进行联动展示，Prometheus 通常与 Grafana 集成。

Grafana 集成

Grafana 是一个流行的开源数据可视化和仪表盘工具，它支持多种数据源，包括 Prometheus。通过配置 Grafana 连接到 Prometheus 作为数据源，你可以：

• 创建高度定制化的仪表盘，将多个 PromQL 查询的结果展示在不同的面板中。
• 利用 Grafana 丰富的图表类型（折线图、柱状图、热力图、仪表盘等）。
• 使用模板变量，创建交互式仪表盘，可以动态切换实例、服务等。
• 将多个数据源（如 Prometheus、Elasticsearch、数据库）的数据组合在一个仪表盘中。
• 设置报警（虽然 Prometheus 本身也能报警，但 Grafana 提供了另一种报警方式）。

Grafana 社区提供了大量预制的 Prometheus 仪表盘模板（可以在 Grafana Labs 的官网上搜索并导入），可以快速地可视化 Node Exporter、Kubernetes、各种数据库等的指标。

因此，虽然 Prometheus UI 提供了基础可视化，但在生产环境中，将 Prometheus 与 Grafana 结合使用是标准实践，以获得更强大的可视化能力。

第七部分：报警：规则与 Alertmanager

监控的一个核心目的是在系统出现异常时及时得到通知。Prometheus 通过定义报警规则和结合 Alertmanager 来实现报警功能。

报警规则 (Alerting Rules)

报警规则定义在 Prometheus 的规则文件中（通常是 .rules 或 .yml 文件，并在 prometheus.yml 中通过 rule_files 引用）。一个报警规则由以下关键部分组成：

• alert: 报警的名称。
• expr: 一个 PromQL 表达式，当其结果包含一个或多个时间序列时，表示报警条件满足。
• for: 一个持续时间。表示报警条件需要持续满足多长时间才被视为真正触发（进入 PENDING 状态后，持续 for 时长仍为 true 则进入 FIRING 状态）。这有助于避免瞬时问题导致的误报。
• labels (可选): 附加到报警上的额外标签。
• annotations (可选): 附加到报警上的信息，如报警描述、摘要、排查步骤等。这些信息通常在通知中显示。

报警规则示例：

“`yaml

filename: alerts.rules.yml

groups:
– name: system_alerts
rules:
– alert: HighCPUUsage
expr: 1 – avg by(instance) (node_cpu_usage_seconds_total{mode=”idle”}) > 0.8 # CPU使用率大于80%
for: 5m # 持续5分钟
labels:
severity: warning
annotations:
summary: “Instance {{ $labels.instance }} CPU usage is high”
description: “The average CPU usage on instance {{ $labels.instance }} has been over 80% for 5 minutes.”

• alert: ServiceDown
  expr: up == 0 # 抓取目标状态为 down
  for: 1m
  labels:
  severity: critical
  annotations:
  summary: “Service {{ $labels.job }}/{{ $labels.instance }} is down”
  description: “The service at {{ $labels.instance }} belonging to job {{ $labels.job }} is unreachable.”
  “`

Prometheus Server 会定期评估这些规则。当一个规则的 expr 表达式结果非空时，该报警进入 PENDING 状态。如果在 for 指定的时间后，表达式结果仍然非空，则该报警进入 FIRING 状态，并被发送到配置的 Alertmanager。

Alertmanager

Alertmanager 是一个独立的组件，用于处理由 Prometheus Server 发送的报警。它的主要功能包括：

• Grouping (分组): 将相似的报警（例如，同一个集群中多个实例的同一类型报警）分组，发送一条汇总的通知，避免报警风暴。
• Inhibition (抑制): 当某个高级别报警触发时，自动抑制相关的低级别报警。例如，当整个集群不可用报警触发时，抑制该集群内所有单个实例的报警。
• Silencing (静默): 手动静默在特定时间段内匹配特定标签的报警，常用于维护期间。
• Routing (路由): 根据报警的标签，将报警发送到不同的接收器（Receivers），如 Slack 频道、邮件列表、PagerDuty、Webhook 等。

Alertmanager 的配置 (alertmanager.yml) 定义了分组、抑制和路由策略，以及各种接收器的连接信息。

报警流程总结：

1. Prometheus Server 周期性地抓取指标。
2. Prometheus Server 周期性地评估报警规则 (rule_files)。
3. 当报警规则的 expr 满足条件并持续 for 时间后，Prometheus 将该报警状态标记为 FIRING。
4. Prometheus 将 FIRING 状态的报警发送给配置的 Alertmanager。
5. Alertmanager 接收报警，并根据其配置进行分组、抑制。
6. Alertmanager 将处理后的报警通过配置的路由发送到相应的接收器（邮件、Slack 等）。

这种分离的架构使得 Prometheus 专注于指标收集和规则评估，而 Alertmanager 专注于复杂的报警处理逻辑，提高了系统的灵活性和可维护性。

第八部分：快速入门：安装与基本使用

理论知识讲了不少，现在让我们来动手实践一下，快速搭建一个最简陋的 Prometheus 环境，并监控自身。

前提： 你需要一台可以执行命令的 Linux/macOS 环境。

步骤 1：下载 Prometheus

访问 Prometheus 官网的下载页面（https://prometheus.io/download/），选择适合你操作系统的最新稳定版。

例如，在 Linux 上使用 wget 下载：

“`bash

替换为最新的版本号和架构

wget https://github.com/prometheus/prometheus/releases/download/v2.50.1/prometheus-2.50.1.linux-amd64.tar.gz
“`

步骤 2：解压

解压下载的文件：

bash
tar -xzf prometheus-2.50.1.linux-amd64.tar.gz
cd prometheus-2.50.1.linux-amd64/

解压后，你会看到几个文件和目录：
* prometheus: Prometheus 主程序二进制文件。
* promtool: 用于检查规则和配置的工具。
* prometheus.yml: 默认配置文件。
* consoles/ 和 console_libraries/: Web UI 的文件。

步骤 3：理解默认配置

打开 prometheus.yml 文件，你会看到类似我们在第四部分介绍的结构。默认配置已经包含了监控 Prometheus 自身的 Job (job_name: 'prometheus')，目标地址是 localhost:9090。这意味着 Prometheus 启动后会尝试从自己的 /metrics 端点拉取指标。

步骤 4：启动 Prometheus

在解压后的目录中执行 Prometheus 二进制文件：

bash
./prometheus

如果一切正常，你会看到 Prometheus 启动日志，包括加载配置、监听端口（默认为 9090）等信息。

...
level=info ts=2024-02-28T10:00:00.000Z caller=main.go:728 msg="Server is listening on" address=0.0.0.0:9090
...

步骤 5：访问 Web UI

在浏览器中访问 http://localhost:9090。你应该能看到 Prometheus 的 Web UI。

• 点击顶部的 “Status” -> “Targets”，你应该能看到一个 job_name: 'prometheus' 的目标，状态应该是 UP。这表明 Prometheus 成功地从自身拉取到了指标。

步骤 6：执行 PromQL 查询

在 Web UI 顶部的搜索框旁边，有一个表达式输入框。

• 输入一个简单的查询，例如 prometheus_up，然后点击 “Execute”。这个指标表示 Prometheus 是否成功抓取了目标，值为 1 表示 UP，0 表示 DOWN。你应该会看到 prometheus_up{instance="localhost:9090", job="prometheus"} 结果为 1。
• 输入 prometheus_target_scrapes_total，点击 Execute。这个 Counter 指标表示 Prometheus 抓取目标的总次数。
• 切换到 “Graph” 标签页，输入 rate(prometheus_target_scrapes_total[5m])，选择时间范围（例如 “5m”），点击 Execute。你应该能看到一个简单的图表，显示 Prometheus 每秒抓取目标的速率（在默认配置下，应该是大约 1/15 = 0.066 次/秒）。

恭喜你！你已经成功安装并运行了 Prometheus，并且学会了如何使用 Web UI 进行简单的查询和验证。

步骤 7：监控外部服务 (Node Exporter 示例)

为了监控操作系统指标（CPU、内存、磁盘、网络等），我们需要运行一个 Node Exporter。

1. 下载 Node Exporter: 访问 Node Exporter 下载页面（https://prometheus.io/download/#node_exporter），下载适合你系统的版本。
2. 解压 Node Exporter:
   bash
tar -xzf node_exporter-1.7.0.linux-amd64.tar.gz # 替换版本号
cd node_exporter-1.7.0.linux-amd64/
3. 启动 Node Exporter:
   bash
./node_exporter
   Node Exporter 默认会在 9100 端口暴露 /metrics 端点。

4. 配置 Prometheus 抓取 Node Exporter:
   编辑之前解压的 prometheus.yml 文件，在 scrape_configs 部分添加一个新的 job：
   “`yaml
   # … (前面的配置) …

   scrape_configs:
   – job_name: ‘prometheus’
   static_configs:
   – targets: [‘localhost:9090’]

   # 添加 Node Exporter job
   – job_name: ‘node_exporter’
   static_configs:
   – targets: [‘localhost:9100’] # 如果 Node Exporter 运行在其他机器，替换 localhost 为其 IP/hostname
   ``
5. **重新加载 Prometheus 配置:**
如果你是通过./prometheus直接启动的，简单的方法是Ctrl+C停止，然后再次运行./prometheus。
更优雅的方式是向 Prometheus 进程发送 SIGHUP 信号。首先找到 Prometheus 进程 ID (ps aux | grep prometheus)，然后kill -HUP 。
6. **验证抓取:**
再次访问http://localhost:9090，进入 "Status" -> "Targets"。你应该能看到node_exporter的 job，并且目标localhost:9100（或你配置的地址）状态为UP。
7. **查询 Node Exporter 指标:**
在 Graph 页面尝试查询 Node Exporter 的指标，例如：
*node_cpu_usage_seconds_total: 查看 CPU 使用总秒数。
*node_memory_MemAvailable_bytes: 查看可用内存字节数。
*rate(node_network_transmit_bytes_total[5m])`: 计算过去 5 分钟内网络发送流量（字节/秒）。

至此，你已经成功搭建了 Prometheus 并监控了自身和一台主机的基本指标。

步骤 8：可视化 (Grafana 集成 – 简述)

安装 Grafana 并配置 Prometheus 数据源非常简单：

1. 下载并安装 Grafana (https://grafana.com/oss/download)。
2. 启动 Grafana (默认端口 3000)。
3. 访问 Grafana Web UI (http://localhost:3000)，使用默认用户名/密码 admin/admin 登录（首次登录会要求修改密码）。
4. 在左侧菜单选择 “Connections” -> “Data sources” -> “Add new data source”。
5. 选择 “Prometheus”。
6. 在 URL 字段输入 Prometheus Server 的地址，例如 http://localhost:9090。
7. 点击 “Save & test”。如果成功，你会看到 “Data source is working” 的提示。
8. 现在你可以创建新的仪表盘，添加 Panel，选择 Prometheus 数据源，并输入 PromQL 查询来构建丰富的可视化图表了。你也可以导入社区提供的 Node Exporter 仪表盘（例如 ID 为 1860 的模板）。

步骤 9：配置报警 (简述)

1. 下载并安装 Alertmanager (https://prometheus.io/download/#alertmanager)。
2. 编辑 alertmanager.yml 配置报警接收器（例如 email、slack 等）。
3. 启动 Alertmanager (默认端口 9093)。
4. 编辑 Prometheus 的 prometheus.yml 文件，在 alerting 部分配置 Alertmanager 的地址。
5. 创建报警规则文件（如 alerts.rules.yml），定义报警规则（参照上面的示例）。
6. 在 Prometheus 的 prometheus.yml 中通过 rule_files 引用你的规则文件。
7. 重新加载 Prometheus 配置。

当报警条件满足时，Prometheus 会将报警发送给 Alertmanager，然后由 Alertmanager 发送通知。

第九部分：进阶与最佳实践

当你对 Prometheus 有了基本了解并开始在更复杂的环境中使用时，可以考虑以下进阶话题和最佳实践：

• 高可用性 (HA): 单个 Prometheus Server 是单点的。可以通过运行多个 Prometheus 副本（它们独立抓取数据，可能会有轻微差异）或结合 Thanos/Cortex 等外部存储系统来实现高可用和长期存储。
• 长期存储 (Long-Term Storage – LTS): Prometheus 的本地存储主要针对短期数据（通常几周到几个月）。对于需要存储更长时间或需要全局查询多个 Prometheus 实例的数据，可以配置远程写入（remote_write）将数据发送到 Thanos、Cortex 或其他支持 Prometheus 远程写入协议的存储后端。
• 服务发现 (Service Discovery): 在动态环境中，手动配置 Targets 不可行。学习如何利用 Kubernetes、Consul、Eureka、文件等服务发现机制自动化目标管理。
• 自定义 Exporters 和应用程序埋点: 对于标准 Exporter 无法覆盖的应用或业务指标，学习如何使用 Prometheus 客户端库为你的应用程序添加监控埋点。
• PromQL 高级用法: 探索 PromQL 更高级的功能，如子查询（subqueries）、偏移量（offset）、join 操作等，以执行更复杂的分析。
• 容量规划: 了解 Prometheus 的资源需求（CPU、内存、磁盘 I/O），规划合适的存储空间和服务器资源。
• 标签设计: 合理的标签设计至关重要。避免创建高基数（High Cardinality）的标签（即具有非常多不同的值的标签，如用户 ID、请求 ID），因为这会极大地增加 Prometheus 的存储和处理负担。标签值应该是有限且离散的。
• 抓取间隔 (Scrape Interval): 根据指标的重要性、变化频率和 Prometheus 的负载来调整抓取间隔。关键指标可以设置较短间隔，非关键的可以设置较长间隔。
• 数据保留 (Retention): 配置 Prometheus 的数据保留时长，平衡存储成本和历史数据需求。

第十部分：总结

Prometheus 是一个强大、灵活且高度适应云原生环境的监控和报警系统。其核心的多维度数据模型、强大的 PromQL 查询语言和丰富的生态系统使其成为现代 IT 监控的基石。

通过本文，你已经了解了 Prometheus 的基本概念、核心组件、数据模型、工作原理以及如何进行数据采集、查询、可视化和报警。最重要的是，你通过快速入门实践，亲手运行了 Prometheus 并进行了基本的指标采集和查询。

这仅仅是 Prometheus 世界的冰山一角。要充分发挥其潜力，还需要深入学习 PromQL 的各种用法、掌握 Alertmanager 的配置、了解不同的服务发现机制以及如何有效地进行应用程序埋点和标签设计。

监控是一个持续优化的过程。随着你对 Prometheus 越来越熟悉，你将能够构建出更完善、更智能的监控体系，为你的应用和基础设施保驾护航。

希望本文能为你打开 Prometheus 大门，助你快速入门并在未来的云原生监控实践中游刃有余！

---