prometheus 3.8.0-rc.1 / 2025-11-21¶

为什么要使用Prometheus¶

想象一下，你正驾驶着一艘巨轮在深夜的浓雾中穿行。仪表盘是空白的，雷达一片沉寂，你只能凭感觉和隐约传来的、不祥的摩擦声来判断是否触礁。这就是没有Prometheus的现代数字系统——一个在复杂性中盲目航行的庞然大物。

我们构建的应用程序从未如此强大，也从未如此脆弱。它们化作微小的服务，在容器间跳跃，于全球的云节点上生生不息。旧的监控工具在此刻哑然失声，它们是为静态的、缓慢的旧世界而生。当故障发生时，你听到的只有用户的怒吼与业务的哀鸣，而你却在成吨杂乱的日志与模糊的指标中，像无头苍蝇般寻找那一根导致雪崩的稻草。

矛盾就在这里：我们创造了动态、弹性的云原生世界，却试图用静态、僵化的思维去观察它。你需要的不再是简单的“是否宕机”警报，而是理解每秒数亿个事件背后故事的能力。你需要知道哪个API延迟正在悄悄腐蚀用户体验，哪项数据库查询正在耗尽整个集群的资源，以及业务指标如何随着每一次代码发布而脉动。

Prometheus，就是拨开这团迷雾的灯塔。它不是为了替代你所有的工具，而是为你提供在这个新世界中生存和洞察所必需的**第一性原理**——一种基于多维数据模型的、拉取式的、自主掌控的监控哲学。它让你从被动的“救火队员”，转变为主动的“系统预言家”。拒绝它，或许你仍在航行；但接纳它，你将绘制出海洋的地图。

Prometheus是什么¶

简单来说，Prometheus是一个开源的系统监控和警报工具包。它的核心设计思想是：主动去“抓取”被监控目标暴露出来的指标数据，并存储在一个强大的时间序列数据库中。

你可以把它理解为一个专注且不知疲倦的**记录员与侦探**。它定期向你的应用程序、服务器、数据库等“询问”健康状态和性能数据（如CPU使用率、请求次数、错误率等），并将这些带着时间戳的数据点记录下来。当数据积累成线，故事便浮现了——你可以轻松查询“过去5分钟的平均响应时间”，或设置规则：“当错误率超过1%时立即告警”。它不依赖复杂的中间件，直接通过HTTP拉取数据，架构简单而健壮，是云原生时代的监控基石。

入门示例¶

让我们从一个真实的场景开始：你有一个受欢迎的博客网站，最近用户抱怨页面加载时快时慢。

1. 场景与矛盾： 你的网站由前端Web服务器、后端API服务和数据库组成。当用户投诉变多时，你面临经典的“侦探难题”：是服务器负载太高？API接口变慢？还是数据库查询出了问题？传统的查看日志方式如同大海捞针，低效且滞后。

2. 引入Prometheus： 你在后端API服务（假设是一个Go应用）中，集成Prometheus的客户端库（github.com/prometheus/client_golang）。

package main

import (
    "net/http"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

func main() {
    // 注册默认的Go运行时指标和进程指标
    // 同时，你自定义一个计数器，用来统计API请求总数
    httpRequestsTotal := prometheus.NewCounterVec(
        prometheus.CounterOpts{
            Name: "http_requests_total",
            Help: "网站API请求总次数",
        },
        []string{"endpoint", "method", "status_code"}, // 通过接口路径、方法、状态码来区分
    )
    prometheus.MustRegister(httpRequestsTotal)

    // 模拟一个API处理函数
    http.HandleFunc("/api/article", func(w http.ResponseWriter, r *http.Request) {
        // 业务逻辑...
        // 在处理完成后，记录这次请求
        httpRequestsTotal.WithLabelValues("/api/article", r.Method, "200").Inc()
        w.Write([]byte("文章内容"))
    })

    // **关键一步：暴露一个/metrics端点，供Prometheus服务器抓取**
    http.Handle("/metrics", promhttp.Handler())

    http.ListenAndServe(":8080", nil)
}

3. 故事展开： 你部署了Prometheus服务器，并将其配置为每隔15秒抓取一次你的应用http://your-api:8080/metrics。数据开始流入。

现在，你可以： * 诊断：在Prometheus的查询界面，输入 rate(http_requests_total{endpoint="/api/article"}[5m])，立刻得到该接口最近5分钟每秒的请求速率曲线图。 * 洞察：结合另一个指标 http_request_duration_seconds_bucket（由客户端库自动提供），你可以用一句查询计算出API的**95分位延迟**，精准定位慢请求。 * 告警：设置一条警报规则：“当/api/article接口的延迟95分位数超过1秒持续2分钟时，向团队发送通知。”

于是，当下一次用户投诉袭来时，你不再猜测。你打开Grafana（一个常与Prometheus搭配的可视化工具），清晰的图表告诉你：是数据库连接池耗尽导致了连锁反应。你从一个疲于奔命的“救火员”，变成了掌控系统的“工程师”。

Prometheus 3.8.0-rc.1 / 2025-11-21版本更新了什么¶

对Remote Write 2.0接收端规范进行了更新，将“创建时间戳”统一更名为“开始时间戳”，标志着这一新规范进入发布候选阶段。
新增了对OAuth2的JWT持有者授权类型（RFC7523 3.1）的支持，增强了与需要此类认证的外部服务集成的安全性。
本次更新是一个**发布候选版本**，主要用于测试，不建议在生产环境中部署。
它侧重于协议的演进和安全功能的完善，为未来稳定版铺平道路。
用户应关注其与现有监控生态组件的兼容性。

更新日志¶

变更 Remote Write 2.0（接收端）：更新至 2.0-rc.4 规范。“创建时间戳” 现更名为 “开始时间戳”。
功能 OAuth2：支持 JWT持有者授权类型（RFC7523 3.1）。

总结¶

概括来说，Prometheus 3.8.0-rc.1 版本的更新日志主要包含两项关键内容：一是对远程写入新规范术语的调整，二是增加了更现代化的安全认证方式，体现了项目在协议标准化和安全强化方面的持续演进。