📌 项目地址：prometheus/prometheus | ⭐ 67,449 颗星 | 🔧 Go
如果你在 Kubernetes 里做过监控，大概率已经在跟 Prometheus 打交道了。CNCF 毕业项目，Go 写的，star 数奔着七万去，云原生监控领域绕不开的名字。
先说它干什么：按你设定的时间间隔，从配置好的目标地址拉取指标，用规则表达式评估这些数据，把结果展示出来，观测到指定条件时触发告警。监控系统该做的事，它全包了。
为什么是 Pull，不是 Push
大部分老牌监控系统是推模式：应用程序主动把指标发给监控服务。Prometheus 反过来，它主动去拉你暴露好的 HTTP 端点。
这个设计初看别扭，实际好处很实在。目标挂了，Prometheus 立刻就知道，因为拉不到了。采样间隔由监控端统一控制，应用侧不用操心。随便用 curl 就能看某个目标吐出的指标，排查问题很方便。
拉模式也有覆盖不到的地方：短生命周期的批处理任务跑完就退出，Prometheus 没机会去拉。所以它留了个口子，通过 Pushgateway 这个中间组件支持推送，批任务把指标推给网关，Prometheus 再从网关拉走。
多维数据模型和 PromQL
这是 Prometheus 真正的核心竞争力。
时间序列由指标名加一组键值对标签定义。同一个 HTTP 请求指标，可以带上 job、instance、path、status_code 这些标签，查的时候想按哪个维度切就按哪个维度切。
配套的查询语言叫 PromQL，专门为这套维度模型设计。聚合、过滤、算速率都写得出来。“过去五分钟每个接口的平均 QPS”、“错误率最高的十个实例”，这类问题一条查询就能回答。Grafana 里的 Prometheus 面板，底层跑的就是 PromQL。
单节点自治
Prometheus 不依赖分布式存储，每个服务器节点自己就是完整的，自己存自己的数据。你不需要先搭一套复杂的分布式集群才能开始用，一个二进制加一份配置文件就能跑。
代价是本地存储不是为无限期保留数据设计的。要存几年的指标，得考虑联邦模式（多个 Prometheus 之间分层或横向汇聚数据）或者远端存储方案。这个取舍是刻意的，监控数据的价值通常集中在近期。
装一个试试
最快的体验方式是 Docker：
docker run --name prometheus -d -p 127.0.0.1:9090:9090 prom/prometheus
注意端口绑定的是 127.0.0.1，只有本机能访问，适合本地试用。跑起来后浏览器打开 9090 端口就行。镜像在 Quay.io 和 Docker Hub 上都有。
生产环境，官方推荐直接用 prometheus.io download 页面的预编译二进制，选最新生产版本。
从源码构建也可以，但比一般 Go 项目多两个依赖：NodeJS 和 npm（10 或更高），因为 Web UI 是前端技术栈写的。Go 版本以仓库里的 go.mod 为准，NodeJS 版本看 web/ui/.nvmrc。
git clone https://github.com/prometheus/prometheus.git
cd prometheus
go install github.com/prometheus/prometheus/cmd/...
prometheus --config.file=your_config.yml
这条命令会同时构建 prometheus 和 promtool 两个二进制，后者是官方的配置检查工具。
动态环境里的服务发现
静态配置目标列表在小规模下没问题，但在 Kubernetes 这种实例随时生灭的环境里就不够用了。Prometheus 支持通过服务发现自动跟上目标变化，也支持静态配置。这是它在容器编排场景里站住脚的重要原因。
该不该选它
适合的场景：长期运行的服务（API、数据库、中间件），指标通过 HTTP 端点暴露，Prometheus 定期来拉，模式天然匹配。配上 Exporter 生态、Alertmanager 和 Grafana，整套监控方案基本是现成的。
要掂量的地方：拉模式要求 Prometheus 网络能直达目标，跨网络边界时会麻烦；短任务多了就得部署 Pushgateway，架构多一层组件；长期存储前面说了，需要额外方案。
工程质量
这个项目的安全规范做得挺全：通过了 CII Best Practices，接入了 OpenSSF Scorecard 和 OSS-Fuzz 持续模糊测试，CI 里还跑 govulncheck。在开源项目里属于第一梯队的水平，拿来当 Go 大型项目的工程实践参考也值。
完整文档、示例和指南都在 prometheus.io，比 README 详细得多，入门直接去那边看。