Windows 下载、安装 Prometheus，开源监控与告警系统，多维时序数据采集与 PromQL 查询（附安装包prometheus-3.13.2.windows-amd64.zip）

1. Prometheus 简介

Prometheus 是一套开源的系统监控与告警工具包，由 SoundCloud 公司于 2012 年创建并开源，设计灵感源自 Google 内部的 Borgmon 监控系统。2016 年 5 月，Prometheus 加入云原生计算基金会（Cloud Native Computing Foundation，CNCF），成为继 Kubernetes 之后第二个加入 CNCF 的托管项目，也是继 Kubernetes 之后第二个从 CNCF 毕业的项目。历经十余年发展，Prometheus 已成为云原生领域事实上的监控标准，GitHub 星标超过 65,000，采用 Go 语言编写，单个静态二进制即可部署。

用大白话说，Prometheus 就是给"一堆服务器和服务的运行状态"装上的一双眼睛：它定期从你配置的机器或应用上"拉取"指标数据（CPU 使用率、内存、请求量、延迟等），存成带时间戳的时序数据；你可以用它的 PromQL 查询语言随时查看任意时间段、任意维度的数据走势，也可以设置告警规则，在指标异常时自动通知你。它既能监控传统服务器硬件，也天然适配 Kubernetes 这类微服务架构。

核心特点：

• 多维数据模型：时间序列由指标名称和一组键/值标签（label）定义，可按任意维度聚合
• PromQL 查询语言：功能强大且灵活，支持函数、聚合、子查询等复杂操作
• 自主自治：不依赖分布式存储，单个服务器节点即可独立运行，故障时易于定位
• 拉取模型：HTTP 主动拉取（pull）采集指标，也支持通过 Pushgateway 推送批任务指标
• 服务发现：通过服务发现或静态配置自动发现监控目标
• 告警与可视化：支持告警规则触发通知，提供原生 Web 界面，并常与 Grafana 搭配使用
• 联邦与水平扩展：支持分层和水平联邦，可按需扩展监控规模

2. v3.13.2 版本亮点

该版本汇集了 2 位贡献者 的 2 条 贡献。

安全更新：

• 将 golang.org/x/text 升级至 v0.39.0（修复 CVE-2026-56852），将 google.golang.org/grpc 升级至 v1.82.1（修复 GHSA-hrxh-6v49-42gf）

Bug 修复：

• PromQL：预先分配活跃查询跟踪（active query tracker）文件，避免数据磁盘写满时发生 SIGBUS 崩溃

v3.13 系列背景：

v3.13.0 是 Prometheus 的长期支持（LTS）版本，v3.13.2 是该系列的补丁版本。v3.13 系列引入的主要能力包括：修复 Web UI 跨站脚本漏洞（CVE-2026-44990）；凭据重定向保护——跨主机跳转时不再转发 Authorization 头、Basic 认证、Bearer 令牌、OAuth2 及自定义请求头；新增实验性 API 搜索端点（搜索指标名、标签名、标签值）；PromQL 新增实验性 min_of() / max_of() 函数；容器镜像同步发布到 GitHub Container Registry（ghcr.io）；时序数据库（TSDB）块填充减少每采样点开销，查询提速约 12%–15%。

3. 获取安装包

如果访问 GitHub 不便，安装包及中文文档：https://hanshuixin.org/go/225H（内含 prometheus-3.13.2.windows-amd64.zip、README 中英对照、发布说明中英对照和 LICENSE）。

Prometheus 其他版本：https://hanshuixin.org/resource/software_integrated_package/Windows/Prometheus

Windows安装prometheus-v3.13.2（prometheus-3.13.2.windows-amd64）.zip
├── prometheus-3.13.2.windows-amd64.zip
├── Windows安装prometheus-v3.13.2（prometheus-3.13.2.windows-amd64）.pdf
├── README/
│   ├── README.md
│   └── README-中文版.md
├── 发布说明/
│   ├── RELEASE-NOTES.md
│   └── RELEASE-NOTES-中文版.md
└── LICENSE

4. 安装

将整合包根目录中的 prometheus-3.13.2.windows-amd64.zip 解压到任意目录（如 C:\prometheus），解压后得到 prometheus.exe、promtool.exe、prometheus.yml（默认配置文件）以及 consoles/、console_libraries/ 等目录。命令行中进入该目录，运行 prometheus.exe 即可启动服务，默认监听 http://localhost:9090。

生产环境建议遵循"先校验、再启动、后注册服务"的顺序：

# 1. 校验配置与告警规则
promtool.exe check config prometheus.yml
promtool.exe check rules rules.yml

# 2. 前台启动（先确认无报错）
prometheus.exe --config.file=prometheus.yml

确认运行正常后，再注册为系统服务长期运行。Windows 可选择用 NSSM 等工具托管。

启动参数要点：

• --web.listen-address=0.0.0.0:9090：监听所有网卡（默认只监听本机回环地址），配合反向代理对外提供 HTTPS 访问时很有用
• --storage.tsdb.retention.time=1y：时序数据保留时间，按磁盘容量与合规需求调整
• --storage.tsdb.path：时序数据存储目录，建议放到独立的数据盘
• Restart=on-failure：进程异常退出时自动拉起

4.1 关键配置（必须）

Prometheus 必须加载配置文件才能正常运行。默认从可执行文件同目录下的 prometheus.yml 加载，也可用 --config.file 参数指定。一个经过生产实践验证的 prometheus.yml 骨架：

global:
  scrape_interval: 15s          # 指标抓取间隔
  evaluation_interval: 15s      # 告警规则评估间隔

# 接入 Alertmanager，形成告警闭环（可选）
alerting:
  alertmanagers:
    - static_configs:
        - targets: ["localhost:9093"]

# 告警规则文件（可选）
rule_files:
  - "rules.yml"

scrape_configs:
  # 监控 Prometheus 自身
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
  # ... 其余抓取任务见下文"配置监控目标"

常用配置项：

5. 使用

5.1 启动服务

在解压目录下直接运行 prometheus.exe，即可用内置的默认配置启动。若自定义了配置文件，用 --config.file 指定：

prometheus.exe --config.file=prometheus.yml

5.2 访问 Web 界面

启动后浏览器访问 http://localhost:9090。Web 界面提供 PromQL 表达式查询（Graph 图表）、Targets（抓取目标状态）、Alerts（告警）等页面，默认配置下页面即可交互，无需额外账号。

5.3 配置监控目标（实战案例）

生产环境通常不是只监控一台机器，而是把服务器节点、应用服务、网站可用性分层纳入监控。下面给出几类最常用的 scrape 配置，按需取用：

监控服务器节点（node_exporter / windows_exporter）

- job_name: "node"
  static_configs:
    - targets: ["192.168.1.10:9100", "192.168.1.11:9100"]
      labels:
        env: "prod"            # 用 env 标签区分生产/测试环境

同一类 job 下可以用 instance 标签区分具体机器；Windows 主机用 windows_exporter（默认端口 9182）采集 CPU、内存、磁盘、网络等指标，配置方式与上面完全一致，仅端口不同：

- job_name: "windows"
  static_configs:
    - targets: ["192.168.1.20:9182"]
      labels:
        env: "prod"

监控 Java / Spring Boot 应用

- job_name: "springboot"
  metrics_path: "/actuator/prometheus"     # Spring Boot Actuator 的指标端点
  static_configs:
    - targets: ["192.168.1.30:8080", "192.168.1.31:8080"]
      labels:
        application: "order-service"        # 用 application 标签区分应用

应用侧需引入 micrometer 与 prometheus 依赖并暴露 /actuator/prometheus 端点，即可采集 JVM 堆内存、线程池、连接池、日志计数等指标。

监控网站可用性（Blackbox Exporter）

- job_name: "blackbox"
  metrics_path: /probe
  params:
    module: [http_2xx]
  static_configs:
    - targets:
        - "https://example.com/"
        - "https://www.example.com/"
  relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target          # 把真实目标传给 blackbox
    - source_labels: [__param_target]
      target_label: instance                # 用真实目标作为 instance 标签
    - target_label: __address__
      replacement: localhost:9115           # 实际请求发送到 blackbox 端口

配置完成后用 promtool check config 校验并热加载，再到 Web 界面的 Targets 页确认所有目标状态为 UP。

5.4 PromQL 查询

在 Web 界面 Expression 输入框即可输入 PromQL 查询。除基础查询外，下面几条是生产排障时最常用的实战查询：

up                                    # 查看所有抓取目标是否在线（1 为正常）
rate(node_cpu_seconds_total[5m])      # 各 CPU 核 5 分钟平均使用率

# 磁盘剩余空间低于 5GB 的节点（常与告警规则配合）
node_filesystem_avail_bytes{mountpoint="/"} < 5 * 1024 * 1024 * 1024

# JVM 堆内存使用率（按实例聚合）
sum by(instance)(jvm_memory_used_bytes{area="heap"})
  / sum by(instance)(jvm_memory_max_bytes{area="heap"})

# 应用 5 分钟内的 error 日志速率（定位故障爆发）
rate(logback_events_total{job="springboot", level="error"}[5m])

# 网站探测结果（1 正常 / 0 不可访问）
probe_success

PromQL 支持算术运算、比较运算、聚合函数（sum、avg、topk 等）以及范围向量查询，还可按标签过滤与分组，是排障与容量规划的核心工具。

5.5 告警规则（实战案例）

把告警规则写入独立的 rules.yml，再在 prometheus.yml 中用 rule_files 引入。下面是从生产实践中提炼的一组通用规则，覆盖主机、应用、网站三个层面的典型场景：

groups:
  - name: prod-alerts
    rules:
      # 服务器离线
      - alert: "服务器离线"
        expr: up{job="node"} == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "服务器离线"
          description: "{{ $labels.instance }} 无法访问，已持续 2 分钟"

      # 磁盘空间不足
      - alert: "磁盘空间不足"
        expr: node_filesystem_avail_bytes{mountpoint="/"} < 5 * 1024 * 1024 * 1024
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "磁盘空间不足"
          description: "{{ $labels.instance }} 剩余空间低于 5GB，已持续 10 分钟"

      # JVM 堆内存过高
      - alert: "JVM堆内存过高"
        expr: sum by(instance)(jvm_memory_used_bytes{area="heap"})
               / sum by(instance)(jvm_memory_max_bytes{area="heap"}) > 0.9
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "JVM堆内存过高"
          description: "{{ $labels.instance }} JVM 堆内存使用率超过 90%"

      # 应用错误日志爆发
      - alert: "错误日志爆发"
        expr: sum by(instance)(rate(logback_events_total{job="springboot", level="error"}[1m])) > 5
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "错误日志爆发"
          description: "{{ $labels.instance }} 1 分钟内 error 日志激增"

      # 官网首页不可访问
      - alert: "官网首页不可访问"
        expr: probe_success{instance=~".*/$"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "官网首页不可访问"
          description: "{{ $labels.instance }} 探测失败，已持续 1 分钟"

规则要点：

• for 表示条件持续多久才触发，用于过滤瞬时抖动（如网络偶发波动）
• {{ $labels.instance }} 在通知中动态填充具体实例名，便于快速定位故障对象
• severity 标签用于区分告警级别，可交给 Alertmanager 分流处理

5.6 配置校验与热加载

修改配置后先校验再生效，避免配置错误导致服务异常：

promtool.exe check config prometheus.yml
promtool.exe check rules rules.yml

校验通过后，无需重启即可让新配置生效——Linux 下发送 SIGHUP 信号，或直接访问 http://localhost:9090/-/reload 触发热加载。

5.7 接入 Alertmanager 告警闭环

Prometheus 只负责"发现异常"，真正把告警送到人手里的是 Alertmanager。在 prometheus.yml 的 alerting 段接入后，命中的告警会自动推送给 Alertmanager，由它负责去重、分组并通知：

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["localhost:9093"]

Alertmanager 的配置（alertmanager.yml）核心是路由和接收器，下面是最常用的邮件通知示例：

global:
  smtp_smarthost: 'smtp.example.com:465'
  smtp_from: 'alert@example.com'
  smtp_auth_username: 'alert@example.com'
  smtp_auth_password: '邮箱客户端授权码'

route:
  receiver: email
  group_by: ['alertname', 'instance']   # 相同告警+实例合并为一个通知
  group_wait: 5m                        # 首次发现后聚合同批告警再发送
  group_interval: 15m
  repeat_interval: 1h                   # 告警持续存在时的重复提醒间隔

receivers:
  - name: email
    email_configs:
      - to: 'ops@example.com'
        send_resolved: true             # 告警恢复时也发送通知

接入后，在 Web 界面的 Alerts 页可查看规则状态（inactive / pending / firing），并可在 Alertmanager 页面确认通知是否送达。至此，"采集 → 查询 → 告警"的完整监控链路就搭建完成了。