要说现在 IT 运维圈子里哪个监控系统最绕不开Prometheus 一定排得上号。这个由 SoundCloud 开源、后来捐给 CNCF 孵化的项目凭着一套干净利落的数据模型和能打能查的 PromQL 查询语言硬是从 Zabbix、Nagios 这些老牌监控工具手里抢下了一大块市场。很多人问 Prometheus 是开源的吗答案是肯定的而且社区非常活跃版本迭代很快。今天我想聊的就是 Prometheus 最新稳定线里的 2.53.1 版本从零开始把安装部署、基础配置、告警规则、接 Grafana 可视化到日常排障这一整套流程完整走一遍。这篇文章适合刚接触 Prometheus 监控部署的运维新手也适合那些已经用过旧版本、想平滑升级的老手——反正实操层面的坑我都帮你踩过一遍了照着做基本能少走不少弯路。1. 环境准备与版本选型思路1.1 为什么选择 2.53.1 这个版本很多朋友一上来就问“Prometheus 装哪个版本好”。说实话只要不是从远古版本直接跳过来选最新的稳定 release 基本不会错。2.53.1 是 2.53 系列的一个补丁版本修了几处稳定性问题整体行为跟 2.53.0 保持一致。对于生产环境来说我个人的习惯是挑一个已经发布了一段时间、社区反馈稳定的小版本不要追最新的大版本也不要死守老版本。2.53.x 作为当前的稳定线原生支持 OTLP 写入、Agent 模式、TSDB 各项优化都已经很成熟PromQL 引擎的查询性能也比早期版本强了不少。另外要提一下 Prometheus 的版本号规律奇数 minor 版本往往是功能预览版偶数 minor 版本更偏稳定。2.53 这个数字在社区里本来讨论度就高2.53.1 作为它的首个补丁版修复了一些已知问题至少在我实际使用中没有遇到明显回归。如果你想从 2.4x 或者更早的版本升级直接替换二进制文件即可配置文件基本兼容但建议升级前用promtool check config做一次完整性校验再小范围灰度验证。1.2 服务器基础环境准备Prometheus 本身是用 Go 写的编译产物是单个二进制文件部署起来非常轻量。它对硬件的要求其实很低官方建议最低 1 核 1G 内存就能跑起来但生产环境我建议至少 2 核 4G磁盘根据数据量规划默认保留 15 天数据。操作系统我这边以 CentOS 7.9 为例Ubuntu 22.04 的操作基本一致只是包管理器命令略有差异。第一步关闭 SELinux 或者放行对应规则否则后面访问 9090 端口会被拦。然后确认防火墙状态如果开着 firewalld需要把 Prometheus 端口加进去firewall-cmd --zonepublic --add-port9090/tcp --permanent firewall-cmd --reload如果是在内网环境也可以直接关掉防火墙或者用安全组规则控制访问来源。这里有一个经常被忽略的点Prometheus 默认监听在所有网卡地址上如果你不想让任意主机都能访问监控数据一定要在前面加一层防火墙或反向代理鉴权不然后面会很被动。创建专用的系统用户也是个好习惯。用 root 跑 Prometheus 不是不行但万一进程被入侵权限太大了。规范做法是创建 prometheus 用户并且不允许登录groupadd --system prometheus useradd --system --no-create-home --shell /sbin/nologin prometheus这一步做完再建目录顺序别反了不然 chown 的时候会把用户弄丢。1.3 获取 Prometheus 安装包的方式Prometheus 官方安装包托管在 GitHub Releases 页面文件名一般是prometheus-2.53.1.linux-amd64.tar.gz。如果你的服务器能正常访问 GitHub直接 wget 就行如果下载速度不理想可以找一下国内的开源镜像站同步的安装包。注意下载后一定要校验一下 SHA256 哈希官方页面会同时给出 checksum 文件养成核对习惯能避免不少安全风险。cd /opt wget https://github.com/prometheus/prometheus/releases/download/v2.53.1/prometheus-2.53.1.linux-amd64.tar.gz sha256sum prometheus-2.53.1.linux-amd64.tar.gz解压之后你会发现里面除了prometheus主程序还带了promtool工具、两个内置的 UI 资源目录consoles和console_libraries以及一个默认的prometheus.yml配置文件。promtool是个很有用的命令行工具后面做配置校验和规则检查都靠它建议同步放到系统的 PATH 里。这套安装包体积很小部署逻辑也就三步放好二进制、放好配置、写好启动服务。但正因为简单很多人才会在细节上栽跟头。2. 二进制方式部署 Prometheus 2.53.12.1 下载、解压与目录规范我习惯把二进制文件放到/usr/local/bin配置放到/etc/prometheus数据目录单独用一个/var/lib/prometheus。这样做的理由是配置文件和数据目录分离备份配置和扩容数据盘都可以独立操作不用每次都在压缩包目录里找东西。具体操作如下cd /opt tar -xzf prometheus-2.53.1.linux-amd64.tar.gz cd prometheus-2.53.1.linux-amd64 cp prometheus promtool /usr/local/bin/ mkdir -p /etc/prometheus cp prometheus.yml /etc/prometheus/ cp -r consoles console_libraries /etc/prometheus/接着创建数据目录并授权给 prometheus 用户mkdir -p /var/lib/prometheus chown -R prometheus:prometheus /var/lib/prometheus chown -R prometheus:prometheus /etc/prometheus这里给新手提个醒很多人解压完之后直接./prometheus --config.fileprometheus.yml就跑结果发现控制台能输出日志但重启之后就找不到原来的数据了。原因很简单你没有指定固定的--storage.tsdb.path它默认写到当前目录下的data/换个目录启动就变成一个新的空库。所以我强烈建议把数据目录固定下来并且明确授权。2.2 编写 systemd 服务文件二进制方式部署最大的一块工作就是把 Prometheus 注册成系统服务。CentOS 7 之后都用 systemd 管理写一个 unit 文件就行了。[Unit] DescriptionPrometheus Server Documentationhttps://prometheus.io/docs/introduction/overview/ Afternetwork-online.target [Service] Userprometheus Groupprometheus Typesimple ExecStart/usr/local/bin/prometheus \ --config.file/etc/prometheus/prometheus.yml \ --storage.tsdb.path/var/lib/prometheus/ \ --web.listen-address0.0.0.0:9090 \ --web.enable-lifecycle Restarton-failure RestartSec5s [Install] WantedBymulti-user.target这里有几个参数值得细说。--web.enable-lifecycle可以让你通过 HTTP API 热加载配置不需要重启进程--storage.tsdb.path指定数据存储目录--web.listen-address控制监听地址和端口。如果有多块磁盘强烈建议把数据目录放到单独的数据盘上避免日志或系统盘写满拖垮整个服务。文件写好之后执行cp /opt/prometheus-2.53.1.linux-amd64/prometheus.service /etc/systemd/system/ # 或者自己用 vim 创建 systemctl daemon-reload systemctl start prometheus systemctl enable prometheus启动后用systemctl status prometheus检查状态看到active (running)就说明服务正常起来了。2.3 验证服务启动与基础功能服务起来之后先不要急着配置一堆采集任务先把基础功能跑通。用浏览器访问http://服务器IP:9090能看到 Prometheus 自带的 Web UI。这个界面虽然简单但是信息量不小Status菜单下的Runtime Build Information能看版本信息Command-Line Flags能看到当前所有启动参数Targets页面后面用来检查采集目标状态。另外别忘了检查两个内置指标打开 Graph 页面输入up点 Execute。这个up指标是 Prometheus 抓取目标是否成功的风向标值为 1 表示抓取正常值为 0 表示目标挂了。默认配置里 Prometheus 会采集自身你至少能看到一个值为 1 的序列。我习惯在部署完成后顺手跑一下promtool check health和curl localhost:9090/-/healthy确认健康检查通过了再进入下一步。3. 核心配置解析与告警规则初探3.1 prometheus.yml 主配置逐项拆解Prometheus 的配置是 YAML 格式核心逻辑其实不复杂但如果你对着默认配置一头雾水后面排查问题会非常痛苦。我先把最常用的一段配置文件拆开讲明白global: scrape_interval: 15s evaluation_interval: 15s external_labels: monitor: my-monitor rule_files: - /etc/prometheus/rules/*.yml scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090]global是全局默认值。scrape_interval表示多长时间抓取一次指标15 秒是默认值evaluation_interval表示 Prometheus 多久计算一次告警规则同样默认 15 秒。这两个值不是越小越好太密会增加目标服务器和存储的负担。external_labels是在多套 Prometheus 或联邦场景下用来区分数据来源的标签单机部署用不用都行。rule_files是告警规则文件的路径支持通配符。这里有个小坑很多人把规则直接写在主配置文件里其实 Prometheus 推荐单独建rules目录方便用 promtool 单独校验。scrape_configs是采集任务列表每个job_name对应一组采集目标。上面的配置只采集 Prometheus 自身所以targets写的是localhost:9090。3.2 配置第一个采集目标服务器节点监控装好 Prometheus 只完成了第一步真正要落地监控的是你的业务服务器。最常用的方式是部署 Node Exporter 采集主机指标然后在 Prometheus 里增加一个 job。Node Exporter 是 Prometheus 官方提供的 agent 程序端口默认 9100会暴露 CPU、内存、磁盘、网络等丰富指标。在目标机器上安装 Node Exporter 的步骤跟 Prometheus 类似下载解压后直接运行nohup ./node_exporter --web.listen-address:9100 然后在 Prometheus 主配置里加一段- job_name: linux-node static_configs: - targets: - 192.168.1.101:9100 - 192.168.1.102:9100配置更新后如果你在启动时加了--web.enable-lifecycle直接在 Web UI 里点 Status - Configuration 旁边的/-/reload请求或者用curl -X POST http://localhost:9090/-/reload热加载不需要重启进程。这个操作我在线上用了很多次确实比重启香得多不会中断采集。打开 Targets 页面能看到linux-node这个 job 以及对应的 endpointState 是 UP 就代表采集正常。3.3 告警规则配置详解Prometheus 的告警规则写起来比较直白难点在于表达式的构造和语义理解。我从一个最简单的节点宕机告警说起groups: - name: node_alerts rules: - alert: InstanceDown expr: up 0 for: 1m labels: severity: critical annotations: summary: Instance {{ $labels.instance }} down description: {{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minute.alert是规则名expr是 PromQL 表达式for表示持续时间。很多人不理解for的作用它不是“延迟告警”而是“持续多久才算告警”。比如up 0 for 1m意思是目标掉线状态持续 1 分钟后才触发告警短暂抖动不会轰炸你。再举几个生产环境常用的规则- alert: HighCPUUsage expr: 100 - (avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 85 for: 10m labels: severity: warning annotations: summary: CPU usage on {{ $labels.instance }} is too high- alert: DiskSpaceLow expr: (1 - (node_filesystem_avail_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay})) * 100 90 for: 5m labels: severity: warning annotations: summary: Disk usage on {{ $labels.instance }} {{ $labels.mountpoint }} is above 90%规则写完放在/etc/prometheus/rules/下主配置里rule_files已经加载了这个目录。修改后同样用/-/reload热加载。每次改完规则我强烈建议先用promtool check rules /etc/prometheus/rules/*.yml校验一遍格式这个工具会像编译检查一样报出语法问题能省下大量排查告警不触发的时间。4. 接入 Grafana 与可视化面板配置4.1 安装 Grafana 并完成基础配置Prometheus 自带的 Web UI 适合查数据和简单调试但要做成团队都能看懂的可视化大屏还是得靠 Grafana。Grafana 是另一个开源项目专门做指标可视化对 Prometheus 数据源的支持非常完善。Grafana 安装很简单官方提供 deb 和 rpm 包。CentOS 上执行sudo yum install -y https://dl.grafana.com/oss/release/grafana-11.1.0-1.x86_64.rpm systemctl daemon-reload systemctl start grafana-server systemctl enable grafana-server启动后访问 3000 端口默认账号密码都是 admin第一次登录会强制改密码。如果服务器上没有图形界面你用本地浏览器直接访问http://IP:3000就能打开。生产环境建议改掉默认密码并配置 HTTPS 代理。4.2 添加 Prometheus 数据源登录 Grafana 后进入 Configuration - Data Sources - Add data source选择 Prometheus。这里最关键的一项是 URLGrafana 服务器要能访问到 Prometheus 的 9090 端口。如果 Grafana 和 Prometheus 装在同一台机器填http://localhost:9090/即可如果分开部署就填 Prometheus 的实际地址。填完点击 Save Test提示成功就说明数据通路没有问题了。等数据源添加完成你在 Grafana 的 Explore 页面里直接写 PromQL 查询会即时返回图表结果平时排查问题比在 Prometheus 原生 UI 里切来切去舒服得多。4.3 导入现成监控面板如果不想从零拖拽图表Grafana 社区有很多现成的 dashboard 可以直接导入。以主机监控为例最经典的 Node Exporter Full 面板 ID 是 1860。进入 Dashboards - Import输入面板 ID选择对应的 Prometheus 数据源导入即可看到 CPU、内存、磁盘、网络等一整套图表。不过这里要提醒一句社区面板不一定跟你当前的指标版本完全匹配尤其 Node Exporter 升级后部分指标名可能有变化导入后如果某些图是空的可以去 Explore 里查一下实际指标名再回面板里修改查询语句。如果想要更精细的可视化比如监控交换机和网络设备就得靠 SNMP Exporter 了。Prometheus 本身不直接采集 SNMP需要部署独立的snmp_exporter。下载解压后用官方默认的snmp.yml配置在 Prometheus 主配置里新增一个 job- job_name: snmp static_configs: - targets: - 192.168.1.1 metrics_path: /snmp params: module: [if_mib] relabel_configs: - source_labels: [__address__] target_label: __param_target - source_labels: [__param_target] target_label: instance - target_label: __address__ replacement: 127.0.0.1:9116这段配置是利用 relabel 机制把目标地址传给 snmp_exporter最终由本机 9116 端口去代理抓取交换机的 SNMP 指标。这个套路在监控网络设备时非常实用交换机本身不用装任何 agent。5. 常见问题与排查技巧实录5.1 服务启动失败实例分析我见过最多的问题是服务启动直接报错退出。如果你执行systemctl start prometheus后发现状态不是 active先看日志journalctl -u prometheus -f常见错误之一是levelerror msgError opening TSDB erropen /var/lib/prometheus/... permission denied这类问题十有八九是目录权限没设置好执行chown -R prometheus:prometheus /var/lib/prometheus就能解决。另一个常见问题就是端口被占用。日志里会出现bind: address already in use这时候用ss -lntp | grep 9090查看是谁占用了端口要么停掉冲突进程要么换个监听端口改--web.listen-address0.0.0.0:9091。还有一个比较隐蔽的问题配置文件 YAML 格式错误。Prometheus 启动时会先解析配置文件任何格式错误都会直接导致进程退出。解决办法是养成先校验再启动的习惯promtool check config /etc/prometheus/prometheus.yml这个命令会把配置文件的语法错误、未知字段、target 格式问题一次性都报出来比对着日志猜半天高效太多。5.2 指标采集不到的处理思路如果 Targets 页面显示某个 endpoint 状态是 DOWNup指标为 0那么从这几个方向排查第一网络连通性。在 Prometheus 服务器上用telnet 目标IP 端口或curl -v http://目标IP:端口/metrics测试先确认基础连通没问题。很多时候是云平台安全组或者本地防火墙没放行端口数据链路根本就没通。第二路径是否正确。有些 exporter 的 metrics 路径不是默认的/metrics比如 SNMP exporter 是/snmpBlackbox exporter 是/probe。如果你需要用自定义路径在 job 里加metrics_path: /custom_metrics第三relabel 配置导致 target 地址被改坏了。relabel 是 Prometheus 里面最灵活也最容易出错的部分如果你在 job 里写了复杂的 relabel_configs建议先把它们注释掉用最简单的static_configs验证目标能不能抓到再逐步恢复逻辑。5.3 告警不触发或重复告警的排查套路告警规则写好了但就是不触发或者偶尔触发后疯狂重复这是很多人被劝退的环节。判断逻辑很简单先用promtool check rules做语法校验再在 Prometheus UI 的 Alerts 页面看规则状态。有几个常见坑需要特别留意。第一个是for参数的单位和取值。Prometheus 里的时间单位支持s、m、h比如1m和1min都是合法的但如果你写成了1这种不带单位的值校验会直接报错。第二个坑是 PromQL 表达式本身没匹配到任何序列。在 Graph 页面手动执行一下表达式如果返回No datapoints说明条件根本没触发或者指标名写错了。告警规则里的表达式必须在当前数据源下能查到数据否则永远不可能触发。第三个坑是evaluation_interval太短或太长导致告警延迟。规则评估是周期性进行的如果全局评估间隔是 15 秒你的for设置了 1 分钟那从指标异常到真正告警至少有一个评估周期加上持续时间的时间窗。有时候你以为规则没生效其实只是还没到触发条件。关于重复告警那是 Alertmanager 的职责范围。Prometheus 只负责把告警发给 Alertmanager去重、沉默、分组这些都在 Alertmanager 端配置。如果你只装了 Prometheus没有部署 Alertmanager告警默认不会发到任何渠道这一点经常被新手忽略。写在最后的一点实践经验我在生产环境里跑 Prometheus 2.53.1 已经有几个月整体感受是稳定、省心、查询速度快。相比以前用的老版本新版本在 TSDB 压缩和 PromQL 执行效率上的优化能明显感知到尤其在仪表盘加载大范围时间序列时响应快了不少。安装部署这件事本身没有太多花活但每个细节——目录规划、权限设置、systemd 参数、配置文件校验——都藏着实实在在的坑。最后再分享一个小习惯每次部署完我一定会在脚本里固化这三个动作——promtool check config、promtool check rules、以及验证/-/healthy健康检查接口。别看它们不起眼往后的排障时间能被省下不少。如果你也是刚入门 Prometheus 监控体系建议先别急着堆一堆 exporter老老实实把这套基础环境跑扎实了再逐步扩展采集面和告警链路这条路走起来会顺很多。