在监控领域搞了这么多年基础设施问我在生产环境里最省心、最不容易出幺蛾子的开源方案是什么我的回答始终是Prometheus。这不光是情怀是被实战反复验证过的结论。Prometheus 2.53.1这个版本在指标采集性能、内存占用、配置校验和远程存储兼容性上都做了进一步打磨整体非常稳。这篇文章我会从零开始完整走一遍Prometheus 2.53.1的安装部署流程顺带把Grafana可视化、告警规则配置、交换机监控这几个大家问得最多的高频场景全部串起来。不管你是刚接触可观测性的新人还是准备把老集群升级到新版本的老手这套实操流程都可以直接参考。老规矩我不谈那些华而不实的理念直接讲落地。从环境规划到二进制文件落地从配置文件语法到systemd管理从Grafana联调到SNMP交换机监控每一段都是我踩过坑之后整理出来的。跟着做你不需要再额外去翻官方文档。1. 为什么是Prometheus为什么选2.53.1聊安装之前先把一个很多人会问的问题说清楚为什么监控系统这么多偏偏要选Prometheus。先说半句话的背景。Prometheus是开源的而且是那种真正意义上的完全开源托管在CNCF旗下Apache 2.0许可证源码全部公开社区活跃度常年排在可观测性领域的第一梯队。它是云原生监控的事实标准。如果你用过Zabbix、Nagios那套老牌监控再回头看Prometheus的设计思路你会明白什么叫“为动态环境而生”。传统监控默认基础设施是固定的IP不变、主机不挂、配置不换但Prometheus从底层就假设所有被监控对象都是动态的服务发现机制把这种假设变成了原生能力。那为什么我特别推荐2.53.1这个版本而不是随便抓一个最新版这就要说到我对版本选择的经验了。在监控系统这种核心基础设施上我向来遵循“新一版本稳定再上旧版本停止维护前必升”的原则。2.53.1作为2.53.x系列的一个补丁版本修复了一段时间内社区反馈的一些比较棘手的bug同时没有引入破坏性的配置格式变化兼容性做得很好。对于从2.4x、2.5x升级上来的老用户迁移成本很低。再往底层看Prometheus 2.53.1核心组件做了不少有价值的优化。首先是存储引擎——它是基于自研的TSDB时序数据库在数据压缩和写入吞吐方面表现非常亮眼。单个节点就能支撑数十万台设备的指标采集这对大多数中小团队来说完全够用了。其次从2.40版本之后Prometheus逐步用更高效的WAL和内存结构减少了长周期运行时的内存碎片问题。在2.53.1里你甚至可以通过调整几个参数就能让单节点扛住更极端的label基数。聊完版本优势还得帮一部分人打消疑虑Prometheus安装到底难不难实话实说如果是二进制包方式安装难度基本为零。它不像某些商业监控软件那样需要一堆依赖组件、数据库、License服务整个Prometheus就是一个单独的可执行文件解压完就能直接跑起来。它的配置文件是YAML格式语法规则清晰上手曲线非常平缓。真正的门槛反而不在安装而在于你怎么组织采集任务、怎么写告警规则、怎么设计监控面板。那都是安装之后的事本文后半部分我会逐个讲清楚。2. 安装前的环境规划与准备很多人装Prometheus翻车不是因为这个软件本身难搞而是环境准备不到位。别急着下载先花十分钟把下面的点过一遍会帮你省掉后面一大半麻烦。2.1 环境规划Prometheus对硬件的要求取决于你的采集规模。我先给一个可以直接照抄的参考标准。如果只是实验环境或者采集十几台服务器的指标那么2核CPU、4GB内存、50GB磁盘就够了。如果是要承担200台以上节点的生产监控我个人建议至少4核CPU、16GB内存、500GB SSD磁盘。磁盘方面我特别提醒一句千万别用机械硬盘来跑生产环境的Prometheus存储TSDB的写入模式是大量的随机小尺寸块写入机械盘在这里表现非常差延迟一高采集任务就会堆积最终把整个监控搞崩。操作系统方面Prometheus原生支持Linux、Windows和macOS。生产环境我强烈建议用Linux而且是systemd作为init系统的发行版比如Ubuntu 20.04及以上、CentOS 7.9及以上、Rocky Linux 8.x/9.x、Debian 11/12。我自己的主力服务器是Rocky Linux 9.2本文的操作流程在CentOS 7.9到Rocky Linux 9.x上都验证过。网络规划上Prometheus采用拉取模型它是主动去抓取exporter暴露出来的指标接口。所以你要提前规划好采集端和被采集端之间的网络访问策略。如果你用防火墙记得在Prometheus服务器上放行对外的TCP访问权限同时在被采集机器上放行对应的exporter端口。下面是我常用的端口规划表可以抄服务组件默认端口用途说明Prometheus Server9090Web界面、API、配置文件热加载Node Exporter9100采集主机CPU、内存、磁盘、网络等指标Grafana3000数据可视化面板Alertmanager9093告警消息接收与分发SNMP Exporter9116通过SNMP协议监控网络设备另外时间同步这事一定不能忽略。Prometheus对时间序列数据的处理极度依赖采集端的准确时间被监控端的时钟如果和服务器偏差超过一定阈值采集过来的数据时间戳就会错乱在图上看起来就像心电图一样抖来抖去告警触发时机也会出问题。部署前建议在所有被监控节点上统一配置chrony或ntp服务这是老手和新手之间最容易拉开差距的细节。2.2 下载与校验Prometheus官方下载渠道是GitHub Releases页面。你要去专门找2.53.1这个版本的发布记录里面会有对应不同操作系统和CPU架构的压缩包。以最常见的Linux x86_64环境为例下载命令是这样的cd /opt wget https://github.com/prometheus/prometheus/releases/download/v2.53.1/prometheus-2.53.1.linux-amd64.tar.gz如果你的服务器架构是ARM比如华为鲲鹏、树莓派或者部分云平台的ARM实例那要把文件名里的linux-amd64换成linux-arm64。不要在这上面想当然我见过不止一个同事在ARM服务器上下了amd64的包一跑就直接报非法指令。下载完成后强烈建议做一步文件完整性校验。官方在发布页提供了SHA256SUMS文件sha256sum prometheus-2.53.1.linux-amd64.tar.gz把这个命令输出的哈希值和官方SHA256SUMS文件里的值比对完全一致再继续。这步不是形式主义特别是当你从镜像站或非官方渠道下载时校验能有效避免下到篡改过的二进制文件。安全无小事监控系统又是掌握全公司基础设施数据的核心节点这一步值得做。解压并移动到标准目录tar -zxvf prometheus-2.53.1.linux-amd64.tar.gz mv prometheus-2.53.1.linux-amd64 /usr/local/prometheus我这里把安装目录定在/usr/local下这个路径是Linux系统约定俗成的软件安装位置。你也可以用自己的习惯目录但务必保持全局统一后面配置systemd服务文件时需要引用绝对路径。进入安装目录后看一下文件结构ls -la /usr/local/prometheus正常情况下你会看到prometheus可执行文件、promtool工具、consoles目录、console_libraries目录以及一个默认的prometheus.yml配置文件。看到这些文件之后就可以正式进入安装配置环节了。3. 手把手安装Prometheus 2.53.1按照上面的流程准备好之后安装其实就是以下几个动作的组合。别嫌步骤细我见过太多人在这一步图快结果配置里漏了个引号启动报错又回来排查半天。3.1 二进制文件安装与验证解压出来的prometheus可执行文件是免编译的这大大降低了部署门槛。不过为了将来管理方便我先创建一个专用的系统用户来运行Prometheus。用root用户启动服务有一个隐患一旦Prometheus的某个接口出现漏洞攻击者可能直接拿到root权限。创建一个无登录权限的系统账号是标准做法useradd --no-create-home --shell /bin/false prometheus这个命令创建了一个名为prometheus的用户它不能登录系统也没有home目录唯一用途就是运行服务进程最小权限原则。然后把下载目录的所有权交给这个用户chown -R prometheus:prometheus /usr/local/prometheus紧接着做一个快速验证看版本号是否正常输出/usr/local/prometheus/prometheus --version如果看到版本信息里包含prometheus, version 2.53.1就说明二进制文件本身没有问题。3.2 数据目录规划Prometheus的时序数据需要持久化存储所以单独建一个数据目录非常必要。我的习惯是放在/data/prometheus与程序目录分开。这样升级版本时只需要替换/usr/local/prometheus下的文件不会动到数据安全系数高得多。mkdir -p /data/prometheus chown -R prometheus:prometheus /data/prometheus这里多说一句存储容量的估算方法。Prometheus每个样本大约占1-2字节的磁盘空间压缩后。你可以先用这个公式粗略估算每天数据量约等于采集指标数量乘以采集频率再乘以24小时最后乘以1.5字节。假设你采集2000个指标每15秒采集一次即每分钟4次每小时240次一天5760次那么一天的数据量约为2000×5760×1.5≈17MB。如果指标数量上涨到20万个一天就是1.7GB左右。通过这个估算方式你可以心里有数地规划 --storage.tsdb.retention.time参数的保留周期。在2.53.1版本中我推荐的几个核心启动参数是--storage.tsdb.retention.time30d --storage.tsdb.path/data/prometheus --web.enable-lifecycle第一个参数含义是数据保留30天到期自动清理防止磁盘被写满。第二个是存储路径。第三个很关键它允许通过HTTP API热加载配置不用重启服务就能应用新的采集配置。后面调配置的时候你会体会到这个参数有多香。3.3 配置文件prometheus.yml详解启动之前我们需要对默认的prometheus.yml做定制。先看一个最基础、能在生产环境跑起来的完整配置global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090]global段落定义全局默认参数。scrape_interval是采集间隔也就是Prometheus每隔多久去拉取一次目标指标。evaluation_interval是告警规则评估间隔它决定了Prometheus每隔多久检查一次告警条件是否成立。这两个参数建议保持一致避免出现告警评估的频率和采集频率不同步导致规则计算依赖的数据还没更新就被评估一次。scrape_configs是整个配置的核心它定义了采集任务。上面这个配置里定义了一个名为prometheus的jobtargets指向Prometheus自身暴露的指标接口localhost:9090。这是最简单、最经典的“监控自监控”配置也是验证Prometheus是否正常工作的第一步。配置文件的缩进严格使用空格不要用TabYAML解析器对Tab零容忍。这个错误新手上线时几乎必犯连资深工程师偶尔也会手滑。修改完配置文件后用自带的promtool做语法校验/usr/local/prometheus/promtool check config /usr/local/prometheus/prometheus.yml输出了SUCCESS说明配置没有问题。promtool这个工具是Prometheus官方提供的瑞士军刀后面做规则检查、调试查询都要用它。3.4 使用systemd管理Prometheus服务生产环境里我不建议直接nohup跑进程那样的话进程意外退出后没人帮你拉起来开机自启动也得自己想办法。既然服务器是Linux交给systemd管理是最正确、最省心的方式。创建一个systemd服务文件vim /etc/systemd/system/prometheus.service内容如下这个服务文件我用了很久参数都验证过[Unit] DescriptionPrometheus Server Documentationhttps://prometheus.io Afternetwork-online.target [Service] Userprometheus Groupprometheus Typesimple ExecStart/usr/local/prometheus/prometheus \ --config.file/usr/local/prometheus/prometheus.yml \ --storage.tsdb.path/data/prometheus \ --storage.tsdb.retention.time30d \ --web.enable-lifecycle \ --web.listen-address:9090 Restarton-failure RestartSec15s [Install] WantedBymulti-user.target解释几个容易踩坑的参数。Typesimple表示这个服务就是启动ExecStart指定的那个进程不要使用forking因为Prometheus本身不会自动fork成后台进程。Restarton-failure表示进程非正常退出时自动拉起RestartSec15s是重启前的等待时间防止频繁重启打满系统日志。之后执行systemctl daemon-reload systemctl enable prometheus systemctl start prometheus systemctl status prometheus看到active (running)就说明服务起来了。如果状态是failed先别慌用journalctl -u prometheus查看日志定位问题是最常见最直接的排查手段。此时浏览器打开http://服务器IP:9090就能看到Prometheus自带的界面。在Status - Targets页面如果看到prometheus这个job处于UP状态恭喜你核心服务已经跑通了。4. 打通数据可视化Grafana安装部署Prometheus原生界面能查询数据、看目标状态但我们日常看监控大屏、做数据图表还是得靠Grafana。说实话Prometheus自带的表达式浏览器适合临时调试和验证数据真正生产环节的可视化Grafana才是主角。它不仅长得好看而且内置了大量Prometheus数据源支持配置非常简单。Grafana安装方式比较多官方推荐用yum或apt直接从官方仓库装。以Rocky Linux / CentOS为例cat EOF | sudo tee /etc/yum.repos.d/grafana.repo [grafana] namegrafana baseurlhttps://packages.grafana.com/oss/rpm repo_gpgcheck1 enabled1 gpgcheck1 gpgkeyhttps://packages.grafana.com/gpg.key sslverify1 sslcacert/etc/pki/tls/certs/ca-bundle.crt EOF yum install -y grafana systemctl daemon-reload systemctl enable --now grafana-serverGrafana默认监听3000端口首次访问会让你设置管理员账号密码默认账号是admin/admin登录后强制改密这个没什么好说的。关键步骤是添加Prometheus数据源。在Grafana左侧菜单进入Configuration - Data Sources - Add data source选择Prometheus在HTTP URL栏填写http://localhost:9090然后点击Save Test。如果提示Data source is working说明Grafana已经跟Prometheus成功对接。数据源连通之后Grafana提供了Grafana Cloud和社区维护的上千个现成仪表盘模板你只要在Dashboards - Import页面输入模板ID就能一键导入。监控Linux主机的推荐node_exporter的官方仪表盘模板ID是1860监控Prometheus自身的官方模板ID是3662。导入时选择你刚才创建好的Prometheus数据源图表就能自动画出数据。这里要提醒一个实战中特别常见的坑很多人把Grafana和Prometheus部署在不同机器上配置数据源时顺手就填了localhost:9090。Grafana机器上根本没有监听9090端口的服务自然连不上。跨机器部署时URL一定要写Prometheus服务器的实际IP比如http://192.168.1.100:9090。同时检查服务器防火墙是否放行了9090端口这类问题我远程帮人排查没有十次也有八次了。5. 自定义告警规则配置详解监控的目的不是为了画漂亮的图而是在系统出问题时第一时间通知到人。Prometheus的告警体系由指标采集、告警规则、Alertmanager三部分组成。本节重点讲告警规则规则写得好不好直接决定了你半夜会不会被一堆垃圾告警吵醒。5.1 告警规则文件的基本结构告警规则通常独立成一个文件然后在prometheus.yml里通过rule_files字段引入。我习惯把规则文件按业务模块拆分比如node-exporter-rules.yml专门放主机相关告警mysql-rules.yml专门放数据库相关告警。这样分类清晰多人协作时不会互相覆盖。在prometheus.yml中添加如下配置rule_files: - /usr/local/prometheus/rules/*.ymlPrometheus会在启动时和运行期间周期性加载规则文件。如果使用通配符新放进目录的规则文件会被自动读取。告警规则文件的语法如下groups: - name: node_alerts rules: - alert: NodeDiskUsageHigh expr: (1 - (node_filesystem_free_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay})) * 100 85 for: 10m labels: severity: warning annotations: summary: {{ $labels.instance }} 磁盘使用率超过85% description: 实例 {{ $labels.instance }} 的挂载点 {{ $labels.mountpoint }} 当前使用率已超过85%请及时清理或扩容。一个group就是一组规则的集合name不能重复。每条rule由五个部分构成alert告警规则的名字建议用大写驼峰命名方便在告警消息里区分。expr触发告警的PromQL表达式。这个表达式计算结果如果大于0就代表条件满足。这里我用了一个除法得到磁盘使用率百分比然后跟85比较。for持续时间。意思是条件满足后要持续多久才触发告警。这个参数是用来消除抖动和误报的。比如磁盘使用率瞬间冲到86%又掉下来for: 10m就要求它持续10分钟都保持86%以上才会告警。labels附加到告警上的自定义标签常用于标记告警级别severity后续Alertmanager可以根据标签路由到不同渠道。annotations描述信息支持模板语法可以引用当前样本的标签值。这里{{ $labels.instance }}会被替换成触发告警的实例地址。写完规则后用promtool校验/usr/local/prometheus/promtool check rules /usr/local/prometheus/rules/*.yml校验无误后因为我们在启动参数里加了--web.enable-lifecycle不需要重启Prometheus只需要执行curl -X POST http://localhost:9090/-/reload配置文件就被热加载了。这个功能在频繁调整规则时简直救命不用中断采集任务。5.2 生产环境必配的高频告警规则我来分享几个在线上环境使用频率极高、真出问题能救命的基础告警规则。第一个是节点存活告警这是最基础的它利用up指标来判断当前采集目标是否存在。expr写成up 0就能触发。第二个是CPU使用率告警第三个是内存使用率告警第四个是磁盘使用率告警第五个是磁盘读写的inode耗尽告警。这几个规则全部放在一个文件里你可以直接复制改阈值groups: - name: node-exporter rules: - alert: HostDown expr: up 0 for: 2m labels: severity: critical annotations: summary: 主机已宕机或exporter不可达 description: {{ $labels.instance }} 已连续2分钟无法采集到指标。 - alert: NodeCPUUsageHigh expr: (100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)) 90 for: 10m labels: severity: warning annotations: summary: CPU使用率过高 description: {{ $labels.instance }} CPU使用率已超过90%请检查是否存在异常进程。 - alert: NodeMemoryUsageHigh expr: ((1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100) 90 for: 10m labels: severity: warning annotations: summary: 内存使用率过高 description: {{ $labels.instance }} 内存使用率已超过90%。 - alert: NodeDiskUsageHigh expr: (1 - (node_filesystem_free_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay})) * 100 85 for: 10m labels: severity: warning annotations: summary: 磁盘使用率过高 description: {{ $labels.instance }} 挂载点 {{ $labels.mountpoint }} 使用率超过85%。 - alert: NodeInodeUsageHigh expr: (1 - (node_filesystem_files_free{fstype!~tmpfs|overlay} / node_filesystem_files{fstype!~tmpfs|overlay})) * 100 90 for: 5m labels: severity: warning annotations: summary: 磁盘inode耗尽 description: {{ $labels.instance }} 挂载点 {{ $labels.mountpoint }} inode使用率超过90%小文件数量过多。告警规则里有一个很容易忽略的技巧for时间越长告警越准确但也会稍稍延迟告警的发出时间。我的经验是针对“可以容忍几十分钟的暂时波动”的指标比如磁盘和内存for建议设置5到10分钟针对“宕机、服务不可用”等紧急状态for可以缩短到1到2分钟甚至直接不写for条件一满足就触发。阈值设置更是门艺术不要照搬我这里的数值你要结合自己业务的跑批周期和流量规律去调整避免高峰期正常波动触发一堆无效告警。规则配置完之后在Prometheus界面Status - Rules里能看到所有规则的加载和最近一次评估状态。如果发现了规则文件加载失败排查步骤是用promtool check rules校验语法检查文件权限最后确认prometheus.yml里的rule_files路径是否正确。6. 扩展监控场景监控交换机等网络设备硬盘、CPU、内存的监控大家都会做但很多团队的监控盲区恰恰在基础网络设备上。交换机、路由器、防火墙一旦出问题影响是全公司层面的却经常因为没有合适的监控手段而沦为黑盒。这里就得靠SNMP协议和snmp_exporter了。6.1 SNMP Exporter的工作原理只要你的交换机开启了SNMP协议Prometheus就能通过snmp_exporter来采集它。snmp_exporter本身不直接管理协议细节而是靠一个名为snmp.yml的配置文件来定义如何把SNMP的OID转换成Prometheus的指标。这个snmp.yml文件默认包含大量常见厂商的模板比如Cisco、Huawei、H3C、Juniper的设备都能覆盖。部署snmp_exporter的方式和Prometheus主服务类似同样是下载二进制、解压、用systemd托管。下载地址还是到Prometheus的GitHub仓库找到snmp_exporter的release页面。安装命令如下cd /opt wget https://github.com/prometheus/snmp_exporter/releases/download/v0.24.1/snmp_exporter-0.24.1.linux-amd64.tar.gz tar -zxvf snmp_exporter-0.24.1.linux-amd64.tar.gz mv snmp_exporter-0.24.1.linux-amd64 /usr/local/snmp_exporter这里我以0.24.1为例实际使用请去GitHub查看最新版本号。snmp_exporter默认监听9116端口。创建systemd服务文件[Unit] DescriptionPrometheus SNMP Exporter Afternetwork-online.target [Service] Userprometheus Groupprometheus Typesimple ExecStart/usr/local/snmp_exporter/snmp_exporter --config.file/usr/local/snmp_exporter/snmp.yml Restarton-failure [Install] WantedBymulti-user.target6.2 配置Prometheus抓取交换机指标完成了exporter部署后下一步是在Prometheus的scrape_configs里增加一个snmp相关的job。这里用到一个最重要的配置项params里的auth它对应SNMP认证组的名称。在prometheus.yml里增加如下内容scrape_configs: - job_name: snmp static_configs: - targets: - 192.168.1.1 - 192.168.1.2 metrics_path: /snmp params: auth: [public_v2] 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这段配置里包含一个新手非常容易犯迷糊的逻辑Prometheus去抓取的不是交换机的IP而是snmp_exporter的地址。整个过程可以理解成“申通快递代收点”模式——Prometheus把要采集的设备地址传递给snmp_exporter然后由snmp_exporter代替Prometheus去访问交换机。所以上面的relabel_configs的作用是先把targets里的交换机IP组装成一个参数__address再设置成snmp_exporter的地址和端口同时保留实例标签用于标识是哪台交换机。多说一句relabel_configs是Prometheus采集配置里非常强大的功能但也是学习曲线最陡峭的部分之一。它的核心作用是调整标签让采集到的数据更规范。上面这个用法是SNMP监控的标准做法照抄不会错但你要理解每一步的含义将来排查问题才能有思路。配置完成后热加载Prometheuscurl -X POST http://localhost:9090/-/reload然后在Prometheus界面用下面的PromQL验证数据是否入库snmp_scrape_duration_seconds如果返回了每个设备实例的抓取耗时就说明交换机数据已经进入Prometheus。接下来你可以从snmp.yml模板默认生成的指标里找到诸如snmp_interface_status、ifInOctets、ifOutOctets之类的网络流量和接口状态指标通过Grafana画流量曲线和接口通断面板。7. Prometheus界面使用与日常维护技巧到这里一套完整的监控体系已经初具规模了。不过很多人在Prometheus跑起来之后对界面的使用还停留在最基础的查询框敲PromQL上。本节我整理一些界面使用和日常维护的实操经验帮你把这套系统用好、用顺。7.1 Prometheus自带界面功能拆解Prometheus自带的Web界面虽然不如Grafana华丽但调试作用不可替代。主要功能区块有Alerts、Status、Targets、Service Discovery等。我的使用习惯是日常巡检先看Targets页面确认所有采集目标都是UP状态再看Alerts页面检查有没有触发的告警查数据时才切到Graph页面写PromQL做调试。Graph页面有几个实用小技巧。第一个是操作符和函数辅助提示表达式框在输入时会有自动补全对PromQL不熟悉的人可以先从补全列表里找函数名。第二个是切换表格模式默认显示的是图形但你也可以点Table模式看精确数值排查问题时看数值更直观。第三个是快速定位标签PromQL公式describe操作在2.53.1里依然可以辅助查看指标含义。另外在Status - Runtime Build Information页面你可以看到Prometheus启动时间、运行时的goroutine数量、内存使用情况等。这些信息在排查Prometheus自身性能问题时非常有用。如果内存占用持续上涨且没有下降趋势说明你的指标基数cardinality可能失控了常见原因是有太多高基数的标签比如URL上带随机ID的请求路径。这种问题得从exporter采集源头治理普通加内存只是治标不治本。7.2 Prometheus数据备份与恢复Prometheus的持久化存储是本地TSDB没有像数据库那样的主从复制、binlog机制备份策略得当与否直接决定灾难恢复能力。我这里是简化过的思路但实际线上完全够用。备份最简单可靠的方法是直接定时打包数据目录。因为TSDB在运行时会将最新数据缓存在内存中所以要在备份前先执行压缩推荐用Prometheus内置的snapshot APIcurl -X POST http://localhost:9090/api/v1/admin/tsdb/snapshot如果收到返回的信息中带有snapshot路径就说明快照已生成在/data/prometheus/snapshots目录下。此时可以用tar或rsync把数据目录拷贝到异地保存。恢复时把备份目录里的数据文件放回data目录然后重启Prometheus即可。这样一个流程走下来即使服务器硬盘完全损坏也能在几分钟内把监控拉起来。7.3 版本升级与回滚要点关于升级2.53.1之后如果出了新版本很多人会纠结要不要升。我的建议是读一下官方升级公告和CHANGELOG重点看有没有breaking changes也就是破坏性变更。从2.5x升到2.5x通常是平滑的。但如果是跨大版本升级比如从2.40直升2.53则要更加谨慎。先把新版本下载下来在测试环境部署一版运行一段时间验证没有数据异常再考虑生产环境灰度升级。升级操作很简单备份原二进制文件停服务替换新版本可执行文件重新启动systemctl stop prometheus mv /usr/local/prometheus/prometheus /usr/local/prometheus/prometheus.bak cp /usr/local/prometheus-new/prometheus /usr/local/prometheus/prometheus systemctl start prometheus启动失败第一时间看日志回滚journalctl -u prometheus -e mv /usr/local/prometheus/prometheus.bak /usr/local/prometheus/prometheus systemctl restart prometheus数据目录一般不需要动Prometheus的TSDB对版本兼容性做得很好只要不是跨好几个大版本旧数据基本都能被新版本正常读取。8. 高频踩坑实录与排查速查入门到进阶的过程中难免会踩坑。我把自己和周围同事在Prometheus部署运维过程中遇到频率最高的几个问题整理成了一张表按“现象—原因—解决方法”的格式列出方便你遇到问题时快速对号入座。现象常见原因排查与解决方法systemctl start后一直提示active (failed)配置文件YAML语法错误或启动参数路径不对运行journalctl -u prometheus -e查看详细报错再用promtool check config校验配置文件。Targets页面显示DOWN网络不通、防火墙未放行、exporter未启动先确认端口是否监听ss -lntup再确认Prometheus服务器到目标IP的连通性。查询有数据但Grafana图表为空Grafana数据源URL配置错误或数据源未选择正确检查Grafana数据源URL确保填的是Prometheus服务器实际IP进入Explore页面测试数据源连通性。告警一直Pending不触发for持续时间未到或PromQL表达式计算结果为0在Graph页面手动执行告警表达式确认值是否大于0确认for参数是否设置过长。内存使用率越来越高指标基数过大高基数标签失控用promtool tsdb analyze命令分析TSDB里面高基数的指标和标签从源头治理采集数据。磁盘空间迅速耗尽数据保留周期设置过长或指标量超出预期调整--storage.tsdb.retention.time参数扩展磁盘容量同时优化采集任务减少无用指标。除了表格这些常见问题我还要单独强调一个非常隐蔽的坑配置文件编码问题。如果你是在Windows上用记事本编辑了prometheus.yml然后直接传到Linux服务器上文件很可能带有Windows的CRLF换行符。这种文件在promtool check config时报错会非常诡异提示第1行第1列找不到字段。解决方式很简单用dos2unix或者vim把换行符转换一下然后重新校验。另一个值得提到的坑是Prometheus热加载失败。加了--web.enable-lifecycle之后虽然可以用/set/reload接口热加载但热加载不是万能的。如果你改了全局配置里的scrape_interval、rule_files等关键参数Prometheus有可能返回配置重载失败。这事在调试期很常见别慌查看9090/-/reload接口返回的响应体它会明确告诉你哪个字段出错了。最后补充一个实用工具。promtool不仅支持配置检查、规则检查还有个tsdb analyze子命令它可以分析数据的标签基数、样本数分布帮助你快速定位是不是有某些label组合爆炸导致存储膨胀。命令格式是/usr/local/prometheus/promtool tsdb analyze /data/prometheus这个命令在线上帮助我解决过很多次因为业务侧乱打标签导致的监控性能问题强烈建议大家掌握。在这套Prometheus 2.53.1部署、Grafana可视化、告警规则、交换机监控、界面维护的工作流全部落地之后你会发现整个可观测性体系的骨架其实非常简洁。它没有复杂的调度节点没有昂贵的许可证成本所有的核心能力都建立在清晰的数据模型和稳定的采集管道之上。我个人的建议是先把这个最小可用体系稳定运行起来再逐步往里面加服务发现、异地联邦、远程存储、快速告警分组这些进阶能力。监控这件事最怕的不是功能不够而是一上来就求大求全最后让垃圾告警和复杂拓扑拖垮了整个项目。打好安装配置的底子后面的事自然就顺了。
Prometheus 2.53.1完整部署指南：Grafana可视化与告警规则配置
在监控领域搞了这么多年基础设施问我在生产环境里最省心、最不容易出幺蛾子的开源方案是什么我的回答始终是Prometheus。这不光是情怀是被实战反复验证过的结论。Prometheus 2.53.1这个版本在指标采集性能、内存占用、配置校验和远程存储兼容性上都做了进一步打磨整体非常稳。这篇文章我会从零开始完整走一遍Prometheus 2.53.1的安装部署流程顺带把Grafana可视化、告警规则配置、交换机监控这几个大家问得最多的高频场景全部串起来。不管你是刚接触可观测性的新人还是准备把老集群升级到新版本的老手这套实操流程都可以直接参考。老规矩我不谈那些华而不实的理念直接讲落地。从环境规划到二进制文件落地从配置文件语法到systemd管理从Grafana联调到SNMP交换机监控每一段都是我踩过坑之后整理出来的。跟着做你不需要再额外去翻官方文档。1. 为什么是Prometheus为什么选2.53.1聊安装之前先把一个很多人会问的问题说清楚为什么监控系统这么多偏偏要选Prometheus。先说半句话的背景。Prometheus是开源的而且是那种真正意义上的完全开源托管在CNCF旗下Apache 2.0许可证源码全部公开社区活跃度常年排在可观测性领域的第一梯队。它是云原生监控的事实标准。如果你用过Zabbix、Nagios那套老牌监控再回头看Prometheus的设计思路你会明白什么叫“为动态环境而生”。传统监控默认基础设施是固定的IP不变、主机不挂、配置不换但Prometheus从底层就假设所有被监控对象都是动态的服务发现机制把这种假设变成了原生能力。那为什么我特别推荐2.53.1这个版本而不是随便抓一个最新版这就要说到我对版本选择的经验了。在监控系统这种核心基础设施上我向来遵循“新一版本稳定再上旧版本停止维护前必升”的原则。2.53.1作为2.53.x系列的一个补丁版本修复了一段时间内社区反馈的一些比较棘手的bug同时没有引入破坏性的配置格式变化兼容性做得很好。对于从2.4x、2.5x升级上来的老用户迁移成本很低。再往底层看Prometheus 2.53.1核心组件做了不少有价值的优化。首先是存储引擎——它是基于自研的TSDB时序数据库在数据压缩和写入吞吐方面表现非常亮眼。单个节点就能支撑数十万台设备的指标采集这对大多数中小团队来说完全够用了。其次从2.40版本之后Prometheus逐步用更高效的WAL和内存结构减少了长周期运行时的内存碎片问题。在2.53.1里你甚至可以通过调整几个参数就能让单节点扛住更极端的label基数。聊完版本优势还得帮一部分人打消疑虑Prometheus安装到底难不难实话实说如果是二进制包方式安装难度基本为零。它不像某些商业监控软件那样需要一堆依赖组件、数据库、License服务整个Prometheus就是一个单独的可执行文件解压完就能直接跑起来。它的配置文件是YAML格式语法规则清晰上手曲线非常平缓。真正的门槛反而不在安装而在于你怎么组织采集任务、怎么写告警规则、怎么设计监控面板。那都是安装之后的事本文后半部分我会逐个讲清楚。2. 安装前的环境规划与准备很多人装Prometheus翻车不是因为这个软件本身难搞而是环境准备不到位。别急着下载先花十分钟把下面的点过一遍会帮你省掉后面一大半麻烦。2.1 环境规划Prometheus对硬件的要求取决于你的采集规模。我先给一个可以直接照抄的参考标准。如果只是实验环境或者采集十几台服务器的指标那么2核CPU、4GB内存、50GB磁盘就够了。如果是要承担200台以上节点的生产监控我个人建议至少4核CPU、16GB内存、500GB SSD磁盘。磁盘方面我特别提醒一句千万别用机械硬盘来跑生产环境的Prometheus存储TSDB的写入模式是大量的随机小尺寸块写入机械盘在这里表现非常差延迟一高采集任务就会堆积最终把整个监控搞崩。操作系统方面Prometheus原生支持Linux、Windows和macOS。生产环境我强烈建议用Linux而且是systemd作为init系统的发行版比如Ubuntu 20.04及以上、CentOS 7.9及以上、Rocky Linux 8.x/9.x、Debian 11/12。我自己的主力服务器是Rocky Linux 9.2本文的操作流程在CentOS 7.9到Rocky Linux 9.x上都验证过。网络规划上Prometheus采用拉取模型它是主动去抓取exporter暴露出来的指标接口。所以你要提前规划好采集端和被采集端之间的网络访问策略。如果你用防火墙记得在Prometheus服务器上放行对外的TCP访问权限同时在被采集机器上放行对应的exporter端口。下面是我常用的端口规划表可以抄服务组件默认端口用途说明Prometheus Server9090Web界面、API、配置文件热加载Node Exporter9100采集主机CPU、内存、磁盘、网络等指标Grafana3000数据可视化面板Alertmanager9093告警消息接收与分发SNMP Exporter9116通过SNMP协议监控网络设备另外时间同步这事一定不能忽略。Prometheus对时间序列数据的处理极度依赖采集端的准确时间被监控端的时钟如果和服务器偏差超过一定阈值采集过来的数据时间戳就会错乱在图上看起来就像心电图一样抖来抖去告警触发时机也会出问题。部署前建议在所有被监控节点上统一配置chrony或ntp服务这是老手和新手之间最容易拉开差距的细节。2.2 下载与校验Prometheus官方下载渠道是GitHub Releases页面。你要去专门找2.53.1这个版本的发布记录里面会有对应不同操作系统和CPU架构的压缩包。以最常见的Linux x86_64环境为例下载命令是这样的cd /opt wget https://github.com/prometheus/prometheus/releases/download/v2.53.1/prometheus-2.53.1.linux-amd64.tar.gz如果你的服务器架构是ARM比如华为鲲鹏、树莓派或者部分云平台的ARM实例那要把文件名里的linux-amd64换成linux-arm64。不要在这上面想当然我见过不止一个同事在ARM服务器上下了amd64的包一跑就直接报非法指令。下载完成后强烈建议做一步文件完整性校验。官方在发布页提供了SHA256SUMS文件sha256sum prometheus-2.53.1.linux-amd64.tar.gz把这个命令输出的哈希值和官方SHA256SUMS文件里的值比对完全一致再继续。这步不是形式主义特别是当你从镜像站或非官方渠道下载时校验能有效避免下到篡改过的二进制文件。安全无小事监控系统又是掌握全公司基础设施数据的核心节点这一步值得做。解压并移动到标准目录tar -zxvf prometheus-2.53.1.linux-amd64.tar.gz mv prometheus-2.53.1.linux-amd64 /usr/local/prometheus我这里把安装目录定在/usr/local下这个路径是Linux系统约定俗成的软件安装位置。你也可以用自己的习惯目录但务必保持全局统一后面配置systemd服务文件时需要引用绝对路径。进入安装目录后看一下文件结构ls -la /usr/local/prometheus正常情况下你会看到prometheus可执行文件、promtool工具、consoles目录、console_libraries目录以及一个默认的prometheus.yml配置文件。看到这些文件之后就可以正式进入安装配置环节了。3. 手把手安装Prometheus 2.53.1按照上面的流程准备好之后安装其实就是以下几个动作的组合。别嫌步骤细我见过太多人在这一步图快结果配置里漏了个引号启动报错又回来排查半天。3.1 二进制文件安装与验证解压出来的prometheus可执行文件是免编译的这大大降低了部署门槛。不过为了将来管理方便我先创建一个专用的系统用户来运行Prometheus。用root用户启动服务有一个隐患一旦Prometheus的某个接口出现漏洞攻击者可能直接拿到root权限。创建一个无登录权限的系统账号是标准做法useradd --no-create-home --shell /bin/false prometheus这个命令创建了一个名为prometheus的用户它不能登录系统也没有home目录唯一用途就是运行服务进程最小权限原则。然后把下载目录的所有权交给这个用户chown -R prometheus:prometheus /usr/local/prometheus紧接着做一个快速验证看版本号是否正常输出/usr/local/prometheus/prometheus --version如果看到版本信息里包含prometheus, version 2.53.1就说明二进制文件本身没有问题。3.2 数据目录规划Prometheus的时序数据需要持久化存储所以单独建一个数据目录非常必要。我的习惯是放在/data/prometheus与程序目录分开。这样升级版本时只需要替换/usr/local/prometheus下的文件不会动到数据安全系数高得多。mkdir -p /data/prometheus chown -R prometheus:prometheus /data/prometheus这里多说一句存储容量的估算方法。Prometheus每个样本大约占1-2字节的磁盘空间压缩后。你可以先用这个公式粗略估算每天数据量约等于采集指标数量乘以采集频率再乘以24小时最后乘以1.5字节。假设你采集2000个指标每15秒采集一次即每分钟4次每小时240次一天5760次那么一天的数据量约为2000×5760×1.5≈17MB。如果指标数量上涨到20万个一天就是1.7GB左右。通过这个估算方式你可以心里有数地规划 --storage.tsdb.retention.time参数的保留周期。在2.53.1版本中我推荐的几个核心启动参数是--storage.tsdb.retention.time30d --storage.tsdb.path/data/prometheus --web.enable-lifecycle第一个参数含义是数据保留30天到期自动清理防止磁盘被写满。第二个是存储路径。第三个很关键它允许通过HTTP API热加载配置不用重启服务就能应用新的采集配置。后面调配置的时候你会体会到这个参数有多香。3.3 配置文件prometheus.yml详解启动之前我们需要对默认的prometheus.yml做定制。先看一个最基础、能在生产环境跑起来的完整配置global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090]global段落定义全局默认参数。scrape_interval是采集间隔也就是Prometheus每隔多久去拉取一次目标指标。evaluation_interval是告警规则评估间隔它决定了Prometheus每隔多久检查一次告警条件是否成立。这两个参数建议保持一致避免出现告警评估的频率和采集频率不同步导致规则计算依赖的数据还没更新就被评估一次。scrape_configs是整个配置的核心它定义了采集任务。上面这个配置里定义了一个名为prometheus的jobtargets指向Prometheus自身暴露的指标接口localhost:9090。这是最简单、最经典的“监控自监控”配置也是验证Prometheus是否正常工作的第一步。配置文件的缩进严格使用空格不要用TabYAML解析器对Tab零容忍。这个错误新手上线时几乎必犯连资深工程师偶尔也会手滑。修改完配置文件后用自带的promtool做语法校验/usr/local/prometheus/promtool check config /usr/local/prometheus/prometheus.yml输出了SUCCESS说明配置没有问题。promtool这个工具是Prometheus官方提供的瑞士军刀后面做规则检查、调试查询都要用它。3.4 使用systemd管理Prometheus服务生产环境里我不建议直接nohup跑进程那样的话进程意外退出后没人帮你拉起来开机自启动也得自己想办法。既然服务器是Linux交给systemd管理是最正确、最省心的方式。创建一个systemd服务文件vim /etc/systemd/system/prometheus.service内容如下这个服务文件我用了很久参数都验证过[Unit] DescriptionPrometheus Server Documentationhttps://prometheus.io Afternetwork-online.target [Service] Userprometheus Groupprometheus Typesimple ExecStart/usr/local/prometheus/prometheus \ --config.file/usr/local/prometheus/prometheus.yml \ --storage.tsdb.path/data/prometheus \ --storage.tsdb.retention.time30d \ --web.enable-lifecycle \ --web.listen-address:9090 Restarton-failure RestartSec15s [Install] WantedBymulti-user.target解释几个容易踩坑的参数。Typesimple表示这个服务就是启动ExecStart指定的那个进程不要使用forking因为Prometheus本身不会自动fork成后台进程。Restarton-failure表示进程非正常退出时自动拉起RestartSec15s是重启前的等待时间防止频繁重启打满系统日志。之后执行systemctl daemon-reload systemctl enable prometheus systemctl start prometheus systemctl status prometheus看到active (running)就说明服务起来了。如果状态是failed先别慌用journalctl -u prometheus查看日志定位问题是最常见最直接的排查手段。此时浏览器打开http://服务器IP:9090就能看到Prometheus自带的界面。在Status - Targets页面如果看到prometheus这个job处于UP状态恭喜你核心服务已经跑通了。4. 打通数据可视化Grafana安装部署Prometheus原生界面能查询数据、看目标状态但我们日常看监控大屏、做数据图表还是得靠Grafana。说实话Prometheus自带的表达式浏览器适合临时调试和验证数据真正生产环节的可视化Grafana才是主角。它不仅长得好看而且内置了大量Prometheus数据源支持配置非常简单。Grafana安装方式比较多官方推荐用yum或apt直接从官方仓库装。以Rocky Linux / CentOS为例cat EOF | sudo tee /etc/yum.repos.d/grafana.repo [grafana] namegrafana baseurlhttps://packages.grafana.com/oss/rpm repo_gpgcheck1 enabled1 gpgcheck1 gpgkeyhttps://packages.grafana.com/gpg.key sslverify1 sslcacert/etc/pki/tls/certs/ca-bundle.crt EOF yum install -y grafana systemctl daemon-reload systemctl enable --now grafana-serverGrafana默认监听3000端口首次访问会让你设置管理员账号密码默认账号是admin/admin登录后强制改密这个没什么好说的。关键步骤是添加Prometheus数据源。在Grafana左侧菜单进入Configuration - Data Sources - Add data source选择Prometheus在HTTP URL栏填写http://localhost:9090然后点击Save Test。如果提示Data source is working说明Grafana已经跟Prometheus成功对接。数据源连通之后Grafana提供了Grafana Cloud和社区维护的上千个现成仪表盘模板你只要在Dashboards - Import页面输入模板ID就能一键导入。监控Linux主机的推荐node_exporter的官方仪表盘模板ID是1860监控Prometheus自身的官方模板ID是3662。导入时选择你刚才创建好的Prometheus数据源图表就能自动画出数据。这里要提醒一个实战中特别常见的坑很多人把Grafana和Prometheus部署在不同机器上配置数据源时顺手就填了localhost:9090。Grafana机器上根本没有监听9090端口的服务自然连不上。跨机器部署时URL一定要写Prometheus服务器的实际IP比如http://192.168.1.100:9090。同时检查服务器防火墙是否放行了9090端口这类问题我远程帮人排查没有十次也有八次了。5. 自定义告警规则配置详解监控的目的不是为了画漂亮的图而是在系统出问题时第一时间通知到人。Prometheus的告警体系由指标采集、告警规则、Alertmanager三部分组成。本节重点讲告警规则规则写得好不好直接决定了你半夜会不会被一堆垃圾告警吵醒。5.1 告警规则文件的基本结构告警规则通常独立成一个文件然后在prometheus.yml里通过rule_files字段引入。我习惯把规则文件按业务模块拆分比如node-exporter-rules.yml专门放主机相关告警mysql-rules.yml专门放数据库相关告警。这样分类清晰多人协作时不会互相覆盖。在prometheus.yml中添加如下配置rule_files: - /usr/local/prometheus/rules/*.ymlPrometheus会在启动时和运行期间周期性加载规则文件。如果使用通配符新放进目录的规则文件会被自动读取。告警规则文件的语法如下groups: - name: node_alerts rules: - alert: NodeDiskUsageHigh expr: (1 - (node_filesystem_free_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay})) * 100 85 for: 10m labels: severity: warning annotations: summary: {{ $labels.instance }} 磁盘使用率超过85% description: 实例 {{ $labels.instance }} 的挂载点 {{ $labels.mountpoint }} 当前使用率已超过85%请及时清理或扩容。一个group就是一组规则的集合name不能重复。每条rule由五个部分构成alert告警规则的名字建议用大写驼峰命名方便在告警消息里区分。expr触发告警的PromQL表达式。这个表达式计算结果如果大于0就代表条件满足。这里我用了一个除法得到磁盘使用率百分比然后跟85比较。for持续时间。意思是条件满足后要持续多久才触发告警。这个参数是用来消除抖动和误报的。比如磁盘使用率瞬间冲到86%又掉下来for: 10m就要求它持续10分钟都保持86%以上才会告警。labels附加到告警上的自定义标签常用于标记告警级别severity后续Alertmanager可以根据标签路由到不同渠道。annotations描述信息支持模板语法可以引用当前样本的标签值。这里{{ $labels.instance }}会被替换成触发告警的实例地址。写完规则后用promtool校验/usr/local/prometheus/promtool check rules /usr/local/prometheus/rules/*.yml校验无误后因为我们在启动参数里加了--web.enable-lifecycle不需要重启Prometheus只需要执行curl -X POST http://localhost:9090/-/reload配置文件就被热加载了。这个功能在频繁调整规则时简直救命不用中断采集任务。5.2 生产环境必配的高频告警规则我来分享几个在线上环境使用频率极高、真出问题能救命的基础告警规则。第一个是节点存活告警这是最基础的它利用up指标来判断当前采集目标是否存在。expr写成up 0就能触发。第二个是CPU使用率告警第三个是内存使用率告警第四个是磁盘使用率告警第五个是磁盘读写的inode耗尽告警。这几个规则全部放在一个文件里你可以直接复制改阈值groups: - name: node-exporter rules: - alert: HostDown expr: up 0 for: 2m labels: severity: critical annotations: summary: 主机已宕机或exporter不可达 description: {{ $labels.instance }} 已连续2分钟无法采集到指标。 - alert: NodeCPUUsageHigh expr: (100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)) 90 for: 10m labels: severity: warning annotations: summary: CPU使用率过高 description: {{ $labels.instance }} CPU使用率已超过90%请检查是否存在异常进程。 - alert: NodeMemoryUsageHigh expr: ((1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100) 90 for: 10m labels: severity: warning annotations: summary: 内存使用率过高 description: {{ $labels.instance }} 内存使用率已超过90%。 - alert: NodeDiskUsageHigh expr: (1 - (node_filesystem_free_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay})) * 100 85 for: 10m labels: severity: warning annotations: summary: 磁盘使用率过高 description: {{ $labels.instance }} 挂载点 {{ $labels.mountpoint }} 使用率超过85%。 - alert: NodeInodeUsageHigh expr: (1 - (node_filesystem_files_free{fstype!~tmpfs|overlay} / node_filesystem_files{fstype!~tmpfs|overlay})) * 100 90 for: 5m labels: severity: warning annotations: summary: 磁盘inode耗尽 description: {{ $labels.instance }} 挂载点 {{ $labels.mountpoint }} inode使用率超过90%小文件数量过多。告警规则里有一个很容易忽略的技巧for时间越长告警越准确但也会稍稍延迟告警的发出时间。我的经验是针对“可以容忍几十分钟的暂时波动”的指标比如磁盘和内存for建议设置5到10分钟针对“宕机、服务不可用”等紧急状态for可以缩短到1到2分钟甚至直接不写for条件一满足就触发。阈值设置更是门艺术不要照搬我这里的数值你要结合自己业务的跑批周期和流量规律去调整避免高峰期正常波动触发一堆无效告警。规则配置完之后在Prometheus界面Status - Rules里能看到所有规则的加载和最近一次评估状态。如果发现了规则文件加载失败排查步骤是用promtool check rules校验语法检查文件权限最后确认prometheus.yml里的rule_files路径是否正确。6. 扩展监控场景监控交换机等网络设备硬盘、CPU、内存的监控大家都会做但很多团队的监控盲区恰恰在基础网络设备上。交换机、路由器、防火墙一旦出问题影响是全公司层面的却经常因为没有合适的监控手段而沦为黑盒。这里就得靠SNMP协议和snmp_exporter了。6.1 SNMP Exporter的工作原理只要你的交换机开启了SNMP协议Prometheus就能通过snmp_exporter来采集它。snmp_exporter本身不直接管理协议细节而是靠一个名为snmp.yml的配置文件来定义如何把SNMP的OID转换成Prometheus的指标。这个snmp.yml文件默认包含大量常见厂商的模板比如Cisco、Huawei、H3C、Juniper的设备都能覆盖。部署snmp_exporter的方式和Prometheus主服务类似同样是下载二进制、解压、用systemd托管。下载地址还是到Prometheus的GitHub仓库找到snmp_exporter的release页面。安装命令如下cd /opt wget https://github.com/prometheus/snmp_exporter/releases/download/v0.24.1/snmp_exporter-0.24.1.linux-amd64.tar.gz tar -zxvf snmp_exporter-0.24.1.linux-amd64.tar.gz mv snmp_exporter-0.24.1.linux-amd64 /usr/local/snmp_exporter这里我以0.24.1为例实际使用请去GitHub查看最新版本号。snmp_exporter默认监听9116端口。创建systemd服务文件[Unit] DescriptionPrometheus SNMP Exporter Afternetwork-online.target [Service] Userprometheus Groupprometheus Typesimple ExecStart/usr/local/snmp_exporter/snmp_exporter --config.file/usr/local/snmp_exporter/snmp.yml Restarton-failure [Install] WantedBymulti-user.target6.2 配置Prometheus抓取交换机指标完成了exporter部署后下一步是在Prometheus的scrape_configs里增加一个snmp相关的job。这里用到一个最重要的配置项params里的auth它对应SNMP认证组的名称。在prometheus.yml里增加如下内容scrape_configs: - job_name: snmp static_configs: - targets: - 192.168.1.1 - 192.168.1.2 metrics_path: /snmp params: auth: [public_v2] 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这段配置里包含一个新手非常容易犯迷糊的逻辑Prometheus去抓取的不是交换机的IP而是snmp_exporter的地址。整个过程可以理解成“申通快递代收点”模式——Prometheus把要采集的设备地址传递给snmp_exporter然后由snmp_exporter代替Prometheus去访问交换机。所以上面的relabel_configs的作用是先把targets里的交换机IP组装成一个参数__address再设置成snmp_exporter的地址和端口同时保留实例标签用于标识是哪台交换机。多说一句relabel_configs是Prometheus采集配置里非常强大的功能但也是学习曲线最陡峭的部分之一。它的核心作用是调整标签让采集到的数据更规范。上面这个用法是SNMP监控的标准做法照抄不会错但你要理解每一步的含义将来排查问题才能有思路。配置完成后热加载Prometheuscurl -X POST http://localhost:9090/-/reload然后在Prometheus界面用下面的PromQL验证数据是否入库snmp_scrape_duration_seconds如果返回了每个设备实例的抓取耗时就说明交换机数据已经进入Prometheus。接下来你可以从snmp.yml模板默认生成的指标里找到诸如snmp_interface_status、ifInOctets、ifOutOctets之类的网络流量和接口状态指标通过Grafana画流量曲线和接口通断面板。7. Prometheus界面使用与日常维护技巧到这里一套完整的监控体系已经初具规模了。不过很多人在Prometheus跑起来之后对界面的使用还停留在最基础的查询框敲PromQL上。本节我整理一些界面使用和日常维护的实操经验帮你把这套系统用好、用顺。7.1 Prometheus自带界面功能拆解Prometheus自带的Web界面虽然不如Grafana华丽但调试作用不可替代。主要功能区块有Alerts、Status、Targets、Service Discovery等。我的使用习惯是日常巡检先看Targets页面确认所有采集目标都是UP状态再看Alerts页面检查有没有触发的告警查数据时才切到Graph页面写PromQL做调试。Graph页面有几个实用小技巧。第一个是操作符和函数辅助提示表达式框在输入时会有自动补全对PromQL不熟悉的人可以先从补全列表里找函数名。第二个是切换表格模式默认显示的是图形但你也可以点Table模式看精确数值排查问题时看数值更直观。第三个是快速定位标签PromQL公式describe操作在2.53.1里依然可以辅助查看指标含义。另外在Status - Runtime Build Information页面你可以看到Prometheus启动时间、运行时的goroutine数量、内存使用情况等。这些信息在排查Prometheus自身性能问题时非常有用。如果内存占用持续上涨且没有下降趋势说明你的指标基数cardinality可能失控了常见原因是有太多高基数的标签比如URL上带随机ID的请求路径。这种问题得从exporter采集源头治理普通加内存只是治标不治本。7.2 Prometheus数据备份与恢复Prometheus的持久化存储是本地TSDB没有像数据库那样的主从复制、binlog机制备份策略得当与否直接决定灾难恢复能力。我这里是简化过的思路但实际线上完全够用。备份最简单可靠的方法是直接定时打包数据目录。因为TSDB在运行时会将最新数据缓存在内存中所以要在备份前先执行压缩推荐用Prometheus内置的snapshot APIcurl -X POST http://localhost:9090/api/v1/admin/tsdb/snapshot如果收到返回的信息中带有snapshot路径就说明快照已生成在/data/prometheus/snapshots目录下。此时可以用tar或rsync把数据目录拷贝到异地保存。恢复时把备份目录里的数据文件放回data目录然后重启Prometheus即可。这样一个流程走下来即使服务器硬盘完全损坏也能在几分钟内把监控拉起来。7.3 版本升级与回滚要点关于升级2.53.1之后如果出了新版本很多人会纠结要不要升。我的建议是读一下官方升级公告和CHANGELOG重点看有没有breaking changes也就是破坏性变更。从2.5x升到2.5x通常是平滑的。但如果是跨大版本升级比如从2.40直升2.53则要更加谨慎。先把新版本下载下来在测试环境部署一版运行一段时间验证没有数据异常再考虑生产环境灰度升级。升级操作很简单备份原二进制文件停服务替换新版本可执行文件重新启动systemctl stop prometheus mv /usr/local/prometheus/prometheus /usr/local/prometheus/prometheus.bak cp /usr/local/prometheus-new/prometheus /usr/local/prometheus/prometheus systemctl start prometheus启动失败第一时间看日志回滚journalctl -u prometheus -e mv /usr/local/prometheus/prometheus.bak /usr/local/prometheus/prometheus systemctl restart prometheus数据目录一般不需要动Prometheus的TSDB对版本兼容性做得很好只要不是跨好几个大版本旧数据基本都能被新版本正常读取。8. 高频踩坑实录与排查速查入门到进阶的过程中难免会踩坑。我把自己和周围同事在Prometheus部署运维过程中遇到频率最高的几个问题整理成了一张表按“现象—原因—解决方法”的格式列出方便你遇到问题时快速对号入座。现象常见原因排查与解决方法systemctl start后一直提示active (failed)配置文件YAML语法错误或启动参数路径不对运行journalctl -u prometheus -e查看详细报错再用promtool check config校验配置文件。Targets页面显示DOWN网络不通、防火墙未放行、exporter未启动先确认端口是否监听ss -lntup再确认Prometheus服务器到目标IP的连通性。查询有数据但Grafana图表为空Grafana数据源URL配置错误或数据源未选择正确检查Grafana数据源URL确保填的是Prometheus服务器实际IP进入Explore页面测试数据源连通性。告警一直Pending不触发for持续时间未到或PromQL表达式计算结果为0在Graph页面手动执行告警表达式确认值是否大于0确认for参数是否设置过长。内存使用率越来越高指标基数过大高基数标签失控用promtool tsdb analyze命令分析TSDB里面高基数的指标和标签从源头治理采集数据。磁盘空间迅速耗尽数据保留周期设置过长或指标量超出预期调整--storage.tsdb.retention.time参数扩展磁盘容量同时优化采集任务减少无用指标。除了表格这些常见问题我还要单独强调一个非常隐蔽的坑配置文件编码问题。如果你是在Windows上用记事本编辑了prometheus.yml然后直接传到Linux服务器上文件很可能带有Windows的CRLF换行符。这种文件在promtool check config时报错会非常诡异提示第1行第1列找不到字段。解决方式很简单用dos2unix或者vim把换行符转换一下然后重新校验。另一个值得提到的坑是Prometheus热加载失败。加了--web.enable-lifecycle之后虽然可以用/set/reload接口热加载但热加载不是万能的。如果你改了全局配置里的scrape_interval、rule_files等关键参数Prometheus有可能返回配置重载失败。这事在调试期很常见别慌查看9090/-/reload接口返回的响应体它会明确告诉你哪个字段出错了。最后补充一个实用工具。promtool不仅支持配置检查、规则检查还有个tsdb analyze子命令它可以分析数据的标签基数、样本数分布帮助你快速定位是不是有某些label组合爆炸导致存储膨胀。命令格式是/usr/local/prometheus/promtool tsdb analyze /data/prometheus这个命令在线上帮助我解决过很多次因为业务侧乱打标签导致的监控性能问题强烈建议大家掌握。在这套Prometheus 2.53.1部署、Grafana可视化、告警规则、交换机监控、界面维护的工作流全部落地之后你会发现整个可观测性体系的骨架其实非常简洁。它没有复杂的调度节点没有昂贵的许可证成本所有的核心能力都建立在清晰的数据模型和稳定的采集管道之上。我个人的建议是先把这个最小可用体系稳定运行起来再逐步往里面加服务发现、异地联邦、远程存储、快速告警分组这些进阶能力。监控这件事最怕的不是功能不够而是一上来就求大求全最后让垃圾告警和复杂拓扑拖垮了整个项目。打好安装配置的底子后面的事自然就顺了。