3. Prometheus入门：架构、核心概念与实战部署
大家好，欢迎来到Prometheus的世界。
说实话，监控系统我接触过不少，从早期的Zabbix、Nagios，到后来的Open-Falcon，再到现在的Prometheus。但Prometheus给我的感觉最不一样。它不只是一个工具，更像是一套设计哲学。今天，我们就来聊聊它的核心。
3.1 Prometheus架构与核心概念
先看整体架构。Prometheus的架构其实很简单，就几个核心组件：Prometheus Server、Exporter、Pushgateway、Alertmanager，以及一个Web UI。
它的工作流是这样的：
- Prometheus Server定期从各个Exporter或Pushgateway拉取（Pull）指标数据。
- 数据存储在本地时序数据库中。
- 通过PromQL查询语言进行数据检索和分析。
- 当触发告警规则时，发送给Alertmanager处理。
这里有几个核心概念，我建议你务必理解透彻：
| 概念 | 说明 |
|---|---|
| Metric（指标） | 监控的数据点，比如CPU使用率、内存占用、请求延迟等。 |
| Label（标签） | 指标的维度属性，比如instance="web-01"、method="GET"。标签是Prometheus灵活性的关键。 |
| Sample（样本） | 一个时间点的具体数值，包含时间戳和值。 |
| Job（任务） | 一组相同目标的采集任务，比如所有Web服务器。 |
| Instance（实例） | 一个具体的采集目标，比如192.168.1.10:9090。 |
我个人习惯：在设计指标时，尽量把业务相关的信息放在标签里，而不是指标名里。比如http_requests_total{method="POST", status="200"}，而不是http_requests_post_200_total。这样查询起来灵活得多。
3.2 Pull模型 vs Push模型
这是Prometheus最核心的设计决策之一。它默认采用Pull（拉取）模型，而不是传统的Push（推送）模型。
Pull模型：Prometheus Server主动去各个目标拉取数据。
- 优点：容易控制采集频率，目标宕机时能立刻发现，数据可靠性高。
- 缺点：目标必须能被Server网络访问到，不适合动态环境（比如短生命周期容器）。
Push模型：目标主动将数据推送到中央收集器。
- 优点：适合动态环境，目标无需暴露端口。
- 缺点：难以控制数据质量，容易造成收集器过载，目标宕机时不易察觉。
为什么会这样设计？说白了，Prometheus团队认为监控系统应该对目标有更强的控制力。Pull模型让Server成为主动方，而不是被动接收。这在故障排查时特别有用——你能明确知道是目标没响应，还是数据没推送。
避坑指南：我曾经在一个Kubernetes集群里，因为网络策略配置不当，导致Prometheus无法Pull到某些Pod的指标。排查了半天才发现是网络隔离问题。所以，如果你用Pull模型，一定要确保网络可达性。
当然，Prometheus也提供了Pushgateway来支持Push场景。比如批处理任务、短生命周期作业，它们无法等待Server来拉取，就可以主动推送到Pushgateway，再由Prometheus去Pull。
3.3 Prometheus安装与配置
安装Prometheus其实很简单。我一般用二进制包，因为最直接。
步骤1：下载并解压
wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz
tar -xzf prometheus-2.45.0.linux-amd64.tar.gz
cd prometheus-2.45.0.linux-amd64步骤2：配置prometheus.yml
这是核心配置文件。我贴一个最简配置：
global:
scrape_interval: 15s # 默认抓取间隔
evaluation_interval: 15s # 告警规则评估间隔
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090'] # 监控Prometheus自身步骤3：启动Prometheus
./prometheus --config.file=prometheus.yml启动后，访问http://localhost:9090就能看到Web UI了。嗯，这里要注意，默认端口是9090，别搞错了。
警告：生产环境中，scrape_interval不要设置得太短，比如1秒。这会给目标和服务端都带来压力。我一般建议15秒到30秒，除非你有特殊需求。
3.4 Exporter机制
Exporter是Prometheus生态里最巧妙的设计之一。说白了，它是一个适配器，把各种系统、中间件的指标转换成Prometheus能理解的格式。
常见的Exporter有：
- node_exporter：采集主机指标（CPU、内存、磁盘、网络等）。
- mysqld_exporter：采集MySQL指标。
- nginx_exporter：采集Nginx指标。
- blackbox_exporter：探测HTTP、TCP、ICMP等端点可用性。
以node_exporter为例，安装和配置非常简单：
# 下载并启动
wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz
tar -xzf node_exporter-1.6.0.linux-amd64.tar.gz
cd node_exporter-1.6.0.linux-amd64
./node_exporter默认监听在9100端口。然后，在Prometheus配置里加上这个目标：
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['192.168.1.10:9100']重启Prometheus，你就能在Web UI里看到主机指标了。
我的经验：Exporter的指标命名通常遵循命名空间_子系统_指标名的规范，比如node_cpu_seconds_total。这看起来有点长，但好处是自解释性强。你一看就知道是node_exporter采集的CPU指标。
另外，Exporter的指标暴露格式是纯文本的，你可以直接curl看看：
curl http://192.168.1.10:9100/metrics返回的内容类似这样：
# HELP node_cpu_seconds_total Seconds the cpus spent in each mode.
# TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu="0",mode="idle"} 123456.78
node_cpu_seconds_total{cpu="0",mode="system"} 2345.67嗯，这就是Prometheus的指标格式。每一行都是一个样本，包含指标名、标签和值。
最后，我想说一句：Exporter机制让Prometheus的生态变得极其丰富。几乎你能想到的任何系统，都能找到对应的Exporter。如果找不到，你甚至可以自己写一个——因为暴露格式就是简单的HTTP接口。
好了，这一章就到这里。下一章我们会深入PromQL查询语言，那才是真正玩转Prometheus的开始。