说实话我刚开始接触运维那会儿最发愁的事情就是半夜被电话吵醒——业务挂了全靠用户反馈等登录服务器去看的时候日志都刷了好几屏了连个因果关系都对不上。后来慢慢搭起了自己的监控体系才算是把被动挨打变成了主动防御。这几年做过的监控方案不少但要说最顺手、社区最活跃、资料最好找的组合还得是Linux环境下这套Prometheus加Grafana的双人组。这篇文章我就把从零开始搭建这套可视化监控平台的完整过程捋一遍所有步骤都是我自己在生产环境实际跑过的参数怎么配、哪些坑不能踩都会交代清楚。不管你是刚入门的运维新人还是想把手头服务器纳入统一监控的老手这套流程都可以直接抄作业。1. 项目概述为什么偏偏是Prometheus和Grafana1.1 监控平台到底解决了什么问题服务器监控这件事往小了说是看一眼CPU高不高、磁盘满没满往大了说其实是两件事预警和追踪。预警好理解指标超过阈值提前报警别等用户发现才补救。追踪则更关键——当业务出现抖动你得能从历史曲线里往回倒推还原出当时系统到底发生了什么。没有监控这些问题都只能靠猜而运维工作一旦进入“猜测模式”效率和口碑基本就是零。我自己最早用的监控工具其实是脚本加定时任务写个shell脚本每五分钟跑一次记录一下负载和内存出问题再去翻文本日志。说实话这种方式在小规模场景下勉强能用但一旦机器数量超过十台脚本管理就变成一场灾难更别提需要临时去对比多台机器的同一时间点的状态了。后来转向集中式监控平台是必然选择而Prometheus加上Grafana这套组合恰好把数据采集、存储、查询和可视化这几块全部覆盖了。1.2 三件套的核心角色划分这套方案里有几个组件各自负责的活儿完全不同。Prometheus主监控服务器负责抓取指标数据、存储时间序列、执行告警规则。它本身是自带时序数据库的所以不需要额外再接MySQL或者PostgreSQL来存监控数据。Exporter被监控机器上的数据采集代理会把操作系统层面的各种状态CPU、内存、磁盘、网络等转化成Prometheus能识别的指标格式然后等在一旁让Prometheus来拉取。Grafana可视化前端连接Prometheus作为数据源把指标画成面板、仪表盘、折线图。告警功能它也能做但我通常把正式告警交给Prometheus的Alertmanager组件处理Grafana定位就是纯粹的展示和交互。你要理解这套架构的巧妙之处就记住一个词拉模式。Prometheus是主动去各台机器上拉取数据而不是各机器往上报送。这样主监控端完全掌控了采集节奏新增一台机器只需要改一下Prometheus的配置文件就行不用去那台机器上部署Agent端的上报脚本规模扩展非常顺滑。1.3 和别家方案的对比它强在哪很多刚接触监控的朋友会问Zabbix不是也挺火的吗为什么选Prometheus我用下来最大的感受是Prometheus的指标模型是多维度的。Zabbix的监控项定义比较复杂每条数据要想清楚是浮点数还是字符型预处理怎么搞。而Prometheus里每个指标就是一组带标签的数值序列比如说统计所有机器的CPU使用率条件是某台机器、某个CPU核心、某种模式用户态还是内核态直接在查询语句里动态筛选就行灵活度完全不在一个级别。另外Prometheus的查询语言PromQL上手之后是真的好用一条语句就能算出过去五分钟的CPU平均使用率还能按不同标签分组展示。再加上Grafana社区里现成的仪表盘模板特别多导入即用不用每次从空白画起。整体来说这套方案的学习曲线确实存在但过了那层窗户纸带来的收益绝对对得起投入的时间。2. 环境准备开始之前的必要功课2.1 最小硬件配置参考先说配置很多人一上来就担心Prometheus是不是特别吃资源。这里给一个我在实际部署中验证过的参考范围监控服务器跑Prometheus和Grafana2核CPU、4GB内存足够应付几百台节点的规模磁盘看你的数据保留周期按每天约2GB估算就行。如果监控的机器数量大或者指标特别密集再加配置也不迟。被监控的Linux服务器跑Node Exporter只需要很小的开销512MB内存的老机器也能轻松跑起来CPU占用通常连1%都不到。我自己在不少低配云主机上验证过完全不影响业务。有一说一如果你只是个人学习或者家里有几台服务器玩一下用一个普通的Linux虚拟机甚至树莓派都能扛住这套监控系统没必要过度配置。2.2 操作系统版本的选择这套方案对Linux发行版基本不挑CentOS系、Ubuntu系、Debian都行甚至国产Linux系统也可以正常跑因为Prometheus和Grafana都提供了通用的二进制包和systemd服务支持。不过有几个小差异点要留意在Ubuntu和Debian上二进制包直接扔到/usr/local/bin就能跑systemd服务文件路径在/etc/systemd/system/。在CentOS/RHEL系上如果开启了SELinux需要注意端口和目录权限的放行否则会出现服务起得来但数据写不进去的诡异情况。如果是国产Linux环境架构通常跟CentOS 7/8保持一致直接按CentOS那套来就好基本没有兼容性问题。我在后面的演示里统一以Linux系统的通用操作为准同时标注两边的差异。示例环境我用的是Ubuntu 22.04CentOS用户看差异说明就行。2.3 工具准备与前置条件在正式动手之前你需要保证下面这些是准备好的一台能联网的Linux服务器并且你拥有root权限或者能通过sudo切换。监控软件要写系统目录、注册服务、开端口这一步省不掉。控制台终端工具比如Windows自带的Terminal或者Mac上的iTerm2你用Xshell这类工具远程连接也行关键是能贴命令和看输出。了解一点基础的Linux常用命令tar解压、vi编辑、systemctl管理服务。如果你完全没碰过这些命令建议先去把Linux常用命令大全翻一遍再回来否则后面每一步都会卡壳。还有一点防火墙。很多朋友把软件装好了结果Prometheus启动正常但Grafana连不上数据源十有八九就是防火墙把9090端口挡住了。Ubuntu上要用ufw放行端口CentOS上要用firewall-cmd操作这个细节后面排查章节我会重点再提。3. 动手安装Prometheus服务器端3.1 获取安装包与目录规划Prometheus官方提供了预编译的二进制包里面包含了主程序和一个默认配置示例不需要自己编译源码。到Prometheus官网的下载页面找到linux-amd64的压缩包复制下载链接后用wget拉取到服务器上。这里我分享一下我的目录规划习惯按这个结构来后续升级和排查都方便# 创建专用目录结构 mkdir -p /opt/prometheus/{bin,conf,data}把二进制包解压后prometheus主程序和promtool工具都放到/opt/prometheus/bin/目录下配置文件统一放在/opt/prometheus/conf/监控数据落在/opt/prometheus/data/。这样做的核心好处是Prometheus、Grafana、Exporter等各类组件配置路径一目了然哪天要备份、要清理直接对着目录来就行不会出现安装包解压在哪就在哪的混乱局面。3.2 编写Prometheus主配置文件Prometheus的所有行为都靠一个YAML格式的配置来驱动。文件路径可以自己定但内容结构是固定的。下面这是一个最小可用的配置global: scrape_interval: 15s # 采集频率 evaluation_interval: 15s # 告警规则评估频率 scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090]这段配置的意思非常直白每15秒对localhost:9090这个地址发起一次抓取请求抓取到的数据就是Prometheus自身的运行指标比如它收到了多少请求、处理了多少采样点、内存用了多少。刚装完第一件事就是先把Prometheus自己管起来确认整个链路是通的再逐步扩展监控目标。这个配置文件的每个字段都不是随便写的scrape_interval决定了数据的时间颗粒度设得越小数据越密集但同时存储和查询的压力也会上去。对于绝大多数系统监控场景15秒足够了。告警规则的评估频率也同理不需要太激进否则会频繁产生无意义的重复告警。3.3 启动Prometheus服务为了方便管理我用systemd把它注册成系统服务这样开机自动启动挂了还能自动拉起。在/etc/systemd/system/prometheus.service写入以下内容[Unit] DescriptionPrometheus Server Afternetwork.target [Service] ExecStart/opt/prometheus/bin/prometheus \ --config.file/opt/prometheus/conf/prometheus.yml \ --storage.tsdb.path/opt/prometheus/data \ --web.listen-address0.0.0.0:9090 Restartalways Usernobody [Install] WantedBymulti-user.target有几个参数值得展开说说。--storage.tsdb.path是时序数据落盘位置我单独指定到data目录防止和程序目录混在一起默认情况下时序数据会保留15天这个是内置策略如果你想存更久后续需要用--storage.tsdb.retention.time参数来调整--web.listen-address如果不设置默认就是监听0.0.0.0:9090但我习惯写出来明确告诉别人这个服务端口是故意暴露出来的。保存文件后执行systemctl daemon-reload systemctl enable --now prometheus systemctl status prometheus看到active (running)的状态就说明Prometheus已经跑起来了。这时候用浏览器访问http://你的服务器IP:9090你会看到一个简约的查询界面这是Prometheus自带的简易Web UI。你可以在它的输入框里敲一个查询语句试试比如prometheus_tsdb_head_samples_appended_total回车就能看到实时数据。这个UI本身没法和Grafana比但胜在方便适合临时查数据用。4. 接入系统监控指标Node Exporter4.1 Node Exporter是什么角色Prometheus本身只管采集真正去操作系统内部读取各种状态数据的是Node Exporter。它是一个独立的小程序运行在被监控的机器上会自动收集内核暴露出来的各项指标CPU使用率、内存占用、磁盘空间、网络流量、文件系统inode耗尽情况、系统负载等然后统一放在/metrics接口里等Prometheus来抓。Node Exporter确实能往前端可视化页面传递数据这可行。但最常见的判断是监控基础资源用Node Exporter监控具体应用再上对应的exporter。比如MySQL数据库配MySQL ExporterRedis配Redis ExporterNginx配Nginx Exporter。安装Node Exporter的方式和Prometheus一模一样也是下载二进制包解压运行。为了管理方便我同样是注册成systemd服务。它的默认监听端口是9100启动命令非常简单# 同样下载node_exporter的二进制包放到/opt/node_exporter/ /opt/node_exporter/node_exporter --web.listen-address:9100如果你担心9100端口暴露在公网上不安全可以用--web.listen-address127.0.0.1:9100只监听本机回环地址然后让Prometheus通过SSH隧道或者内网地址来采集。不过一般情况下被监控机器和监控主机都在内网环境里直接监听内网IP即可。4.2 把节点加入Prometheus的抓取任务Node Exporter装好后回到Prometheus主配置文件的scrape_configs里增加一段新的job配置让它去抓取该机器的指标scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: linux-node static_configs: - targets: - 192.168.1.101:9100 # 替换为你需要监控的机器IP这里解释一下job_name的作用它是这批监控目标的逻辑分组名称后面在Grafana作图时经常要按job来筛选机器。同一个job下可以写很多台机器每行一个IP和端口Prometheus会并行去抓取。改完配置后重启服务Prometheus那边不需要任何额外的命令下次抓取周期到达时会自动发现新目标。重启后可以在Prometheus的Web UI里打开Status - Targets页面能看到每个job下的监控目标列表状态为UP就代表抓取成功。这个页面是我日常排查的首选入口只要哪个目标状态是DOWN多半就是网络不通、端口被防火墙堵了或者Exporter进程挂了。4.3 用动作和脚本验证采集链路确认Node Exporter的数据进了Prometheus之后可以在Prometheus查询框里试试这些基础指标判断链路是否正常# 查看所有节点的CPU使用率百分比 100 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100 # 查看内存使用率 (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 # 查看根分区磁盘使用率 100 - (node_filesystem_avail_bytes{mountpoint/} / node_filesystem_size_bytes{mountpoint/}) * 100这些查询语句看起来复杂但拆开看就不难了。rate函数是PromQL中最常用的专门用来计算计数器指标的变化速率比如CPU在5分钟内从累计值变成了每秒的使用率。换成人话说这条语句就是在算“过去五分钟CPU的空闲时间占比是多少然后拿100减掉得到实际使用率”。理解了这一层后面你写任何查询逻辑都会有思路。多提一嘴node_cpu_seconds_total这个名字它其实是一个累计值cgroup统计的是从开机到现在CPU在各种模式下总共消耗的秒数。直接查询这个数你会看到一个不断增长的大数值本身没有太大意义用一个rate()函数把它转成每秒速率再配合modeidle过滤出空闲模式才能算出来使用率。这是PromQL最重要的思维转换——监控的是速率不是累计值。5. 部署Grafana可视化展示的核心层5.1 安装与首次启动Grafana的安装包在官网可以找到支持rpm、deb和二进制压缩包几种形式。我用的是二进制包方式因为内部服务器经常与互联网物理隔离YUM或APT源不一定可用下载离线包分发是最常见的部署路径。下载后同样解压把主程序和辅助文件放到/opt/grafana目录wget https://dl.grafana.com/enterprise/release/grafana-enterprise-10.4.2.linux-amd64.tar.gz tar -zxvf grafana-enterprise-10.4.2.linux-amd64.tar.gz mv grafana-10.4.2 /opt/grafanaGrafana默认读取它自己目录下的conf/defaults.ini获取配置如果你需要自定义端口或数据目录可以复制一份defaults.ini改名为custom.ini再修改。不过对于大部分初始部署保持默认配置足够。启动方式同样用systemd托管好处是开机自启动进程崩溃能自动拉起。跳过这个直接跑二进制也没毛病但就没有守护进程了。启动后浏览器访问http://服务器IP:3000首次打开会看到登录页面默认用户名和密码都是admin。系统会强制你修改初始密码这里建议改成强密码并妥善记录因为Grafana账号有数据源的配置权限一旦泄露不仅监控数据暴露攻击者还能通过Grafana的接口去探测内网的IP和端口。5.2 配置Prometheus数据源登录后进入的是Grafana的主界面。现在服务端还是空壳必须先添加数据源告诉它往哪儿查数据。步骤如下鼠标移到左侧边栏的“齿轮”图标上点击“Connections”里的“Data sources”。点击“Add data source”按钮在列表里选择“Prometheus”。在“URL”栏填写Prometheus的地址例如http://192.168.1.100:9090。我这里特意说明一下如果你的浏览器和服务器不在同一台机器IP不要写localhost。点击页面底部的“Save test”看到绿色的“Successfully queried the Prometheus API”提示就代表连接成功。这一步是整套可视化链路中的胜负手我见过不少人卡在这里。最常见的坑是URL写成了localhost:9090但浏览器打开的Grafana页面来自远程它拿localhost去连Prometheus自然连不上。说白了这个URL是Grafana服务器进程去访问的地址不是你的浏览器去访问的地址必须写Grafana服务器能访问到的Prometheus地址。然后是端口放行问题很多环境下Linux防火墙默认禁止跨主机的9090端口互访测试数据源连接失败时先用telnet IP 9090检查一下网络通不通再怀疑配置问题。5.3 快速导入现成的仪表盘模板Grafana最吸引人的一个地方就是社区里的仪表盘模板极其丰富不需要从零开始画图表。在Grafana官网的Dashboard页面搜索“Node Exporter Full”或者“Linux Hosts”能找到很多现成的面板模板每个模板都有一个对应的ID编号。以我长期在用的模板1860为例操作步骤是在Grafana左侧边栏点击“”号选择“Import”。在“Import via dashboard ID”栏输入1860点击“Load”。下拉菜单里选择之前配好的Prometheus数据源点击“Import”。几秒钟后一个包含CPU、内存、磁盘、网络、进程等几十个面板的完整仪表盘就出现了。导入成功后页面展示的是一整套Linux主机状态总览从总览页能看到当前在线的主机数、平均负载、整体CPU趋势、内存使用柱状图等。需要注意这类模板默认可能只配置了一个主机变量如果你监控了多台机器右上角的下拉框里可以切换。模板毕竟是社区贡献的个别面板可能出现无数据的情况多半是模板作者用的查询语句里带了一些固定标签过滤条件你把查询语句改一下就能适配自己的环境。这块不想折腾的话也可以先学着自己从第一个空白面板画起练熟了再考虑套模板节省时间。6. 亲手配置第一个可视化面板6.1 从空白画布开始自己动手画面板是理解Grafana的核心环节。光会导入模板还不行模板是别人的思路出了诡异数据你根本不知道问题出在哪自己画过一遍就知道每个数字是怎么算出来的了。个人建议刚接触时一定要抽出半小时从空白面板开始做。新建面板的入口在左侧“”号然后选“Dashboard”进入Dashboard编辑界面后点击“Add”选“Visualization”。Grafana提供了丰富的图表类型监控场景下最常用的是时间序列图也就是折线图。面板右侧编辑区分为几个维度Data source选择PrometheusQuery Type保持默认的Metrics然后关键的就是在输入框里写PromQL查询语句。6.2 常用PromQL查询解析我们用一个监控CPU使用率的查询来做演示在查询编辑器里输入100 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100这时面板上应该立刻出现一条曲线横轴是时间纵轴是百分比。如果你监控了多台机器Prometheus返回的每个序列会带上机器实例的标签图表里就会显示多条不同颜色的线。面板右上角还可以设置数据刷新周期比如每15秒自动拉取新数据页面就像活的一样在跳动。关于CPU这个查询我再说一个容易忽略的点avg如果不加by(instance)会把所有CPU核心和所有机器混合求平均你看到的是一条总平均曲线。要区分开每台机器和每个核心可以这样写avg(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance)意思是按instance标签分组后分别求每台机器的平均使用率。同理如果你想看每个CPU核心的使用率by(cpu)就行。Grafana查询框支持直接调整PromQL语句改完立刻能看到图表变化多试几次就掌握标签筛选和聚合的玩法了。6.3 面板变量让Dashboard支持多台机器切换单台机器画好了接下来需要让面板演示更灵活。Grafana支持定义模板变量简单来说就是让你在Dashboard顶部加一个下拉框点击切换监控目标所有关联面板自动刷新展示对应数据。在Dashboard页面点击右上角的“Settings”图标进入“Variables”标签页点击“Add variable”。变量类型选择“查询”查询语句可以写成这样它会把所有出现在特定标签值里的机器名称列出来label_values(node_boot_time_seconds, instance)添加完成后在面板的查询语句里把原来写死的机器IP替换成变量100 - avg(rate(node_cpu_seconds_total{instance$host}[5m])) * 100这样切换变量值所有用到变量的面板会同时切换展示对象。这个功能用在几十台服务器组网监控时尤其好使每个业务组建一组机器清单变量整个Dashboard就变成了一套可交互的业务监控总览。7. 告警推送走出可视化的最后一步7.1 Prometheus告警规则怎么写监控的最终目的不是画图是故障时能第一时间通知到人。Prometheus的告警体系分两层规则层负责判断“指标是否越界”通知层由Alertmanager承担负责把告警发送到钉钉、邮件、企业微信等渠道。告警规则写在独立的规则文件里在Prometheus主配置文件中指定引用例如rule_files: - /opt/prometheus/rules/node_alerts.yml然后在node_alerts.yml里面定义具体的规则用一个最简单的示例groups: - name: node_alerts rules: - alert: InstanceDown expr: up 0 for: 2m labels: severity: critical annotations: summary: Instance {{ $labels.instance }} is down description: Host is unreachable for more than 2 minutesup这个指标非常特殊它是Prometheus在每次抓取目标时自动生成的一个指标1代表成功0代表失败。up 0的意思就是有监控目标抓取失败了。后面的for: 2m表示这个状态要持续2分钟才触发告警这样能有效防止偶发抖动造成的误报。我遇到过的最奇葩问题是告警规则写好了Prometheus的--alertmanager.url参数没配置导致告警状态能在UI上看到但根本不发送。告警状态从Inactive到Pending再到Firing只在Prometheus内部有记录不推送到Alertmanager就等于白搭。7.2 Alertmanager的部署与通知配置Alertmanager是Prometheus生态里的告警集中器负责接收Prometheus推送来的告警事件然后根据路由规则分发给不同渠道。它的安装包同样是预编译二进制下载解压后配置一个alertmanager.yml。下面是一个配置了钉钉机器人通知的简版配置route: group_by: [alertname] group_wait: 10s group_interval: 10s repeat_interval: 1h receiver: webhook receivers: - name: webhook webhook_configs: - url: http://127.0.0.1:8060/dingtalk/webhook1这套流程配置完成后告警链路变成Prometheus判断出InstanceDown状态为Firing推给AlertmanagerAlertmanager再根据路由规则把消息POST到钉钉机器人的Webhook地址钉钉群里立刻跳出一条红色告警。整个过程只需要记清楚规则层管“判断”服务层管“发送”。实际生产中钉钉和飞书这类办公软件的群机器人配置都很简单就是用自定义关键词加一个Webhook地址。通知信息会带着告警标题、级别、实例地址和触发时间。如果你需要更丰富的交互可以后续再接一个简单的中转服务去格式化消息让告警内容里附带当前的主机实时负载信息等。8. 生产环境的常见问题与排障手册8.1 服务起不来或端口不对表现是systemctl status prometheus显示服务未运行或者浏览器访问不了9090端口。排查分三步走先看服务日志journalctl -u prometheus -f配置文件路径写错了、目录没建、参数拼错日志里都会有明确提示。再确认端口占用ss -lntp | grep 9090如果端口被占用多半是之前启动过但没彻底关掉kill进程后重新启动即可。最后检查防火墙我处理过太多案例服务明明监听正常但外部就是不通换台机器telnet一下发现端口不通然后检查firewalld或ufw规则放行915端口才结束。很多人卡在“服务明明起来了为什么访问不了”就是防火墙这一关。拦路虎不是配置本身而是运维意识里总是默认防火墙没作用其实现在的发行版默认都开防火墙主动放行端口是标准动作换个思路能少踩很多坑。8.2 Grafana面板没有数据这一个问题能覆盖十个不同原因排查时要有顺序。先用Prometheus的查询界面验证数据源有没有数据。打开Prometheus的Graph页面输入up执行查询。如果这里就查不到数据说明Prometheus侧就有问题先检查Targets页面里监控目标的状态全部DOWN的话要么是Exporter没起要么是网络不通。如果Prometheus有数据但Grafana面板空白多半是查询语句里带了不存在的标签名或者面板用了模板变量但变量没有匹配到任何序列还有一种常见情况是面板时间范围设置得不对选的是最近三天而数据昨天才开始采集进Prometheus。我经历过一次特别隐蔽的问题Grafana面板里部分图表空着后来看到查询语句里写死了hostname~$host而我定义的主机名变量和节点上的hostname标签值不一致。这种问题在导入模板时特别常见模板作者的标签命名和你的环境不匹配需要检查一下实际数据里的标签列表对号入座。8.3 时间不同步导致数据错乱Prometheus对监控目标的时间戳非常敏感。如果被监控机器的系统时间和监控服务器差异过大常见表现为数据点丢失、突变、时好时坏。这是因为Prometheus在存储序列时会检测数据点的时间戳是否合理当前时间差超过一定范围的数据可能会被拒绝写入。这个问题的根治方案很简单所有服务器统一启用NTP时间同步。# Ubuntu timedatectl set-ntp true # CentOS yum install -y chrony systemctl enable --now chronyd时间同步之后定期用timedatectl status确认一下即可。我见过两台机器只差了五分钟监控曲线就开始出现奇怪的毛刺这个问题往往被忽视但它对数据可信度的影响极大。8.4 数据膨胀与磁盘用尽Prometheus存储时间序列数据是按采样点来算的指标越多、采集间隔越短、保留时间越长占用磁盘越多。尤其是Exporter侧带出了很多隐藏的高基数指标比如网络连接状态按客户端IP拆分这种数据量很容易失控。这里规划一个常规的容量预估假设你监控50台机器每台机器大约产生3000个时间序列Prometheus每秒大概会接收1500个采样点每天大约要消耗2GB磁盘空间。当然这只是个保守估算值真实情况取决于指标数量和数据基数。如果磁盘比较紧张可以在启动参数中按需缩短保留周期--storage.tsdb.retention.time7d保留7天的数据对于大多数系统监控场景够用因为查询历史趋势一般就看最近一周。结尾个人的一点实践经验整套平台从零到能用的过程如果操作顺利一个小时以内就能跑通。但想把它用出价值关键还在于日常的持续投入每接入一台新业务就顺手把对应的监控指标梳理一遍每次线上出问题时都去复盘一下监控数据里是否早就暴露出了蛛丝马迹。这也是我写这篇文章的主要愿望——帮大家把监控体系的基础打稳省下的时间可以花在更有价值的事情上。根据我个人的使用习惯最后还建议你养成一个“小操作”每次修改过Prometheus配置或者新增面板之后都导出一份当前配置文件的备份用Git管理起来。别小看这一步生产环境出问题时你做的第一件事一定是回看“上一次可用的配置是什么”而不是原地猜测。祝大家的监控曲线都长一条直线——平稳、健康、不用半夜爬起来接告警电话。 Linux环境下从零搭建Prometheus+Grafana可视化监控平台
说实话我刚开始接触运维那会儿最发愁的事情就是半夜被电话吵醒——业务挂了全靠用户反馈等登录服务器去看的时候日志都刷了好几屏了连个因果关系都对不上。后来慢慢搭起了自己的监控体系才算是把被动挨打变成了主动防御。这几年做过的监控方案不少但要说最顺手、社区最活跃、资料最好找的组合还得是Linux环境下这套Prometheus加Grafana的双人组。这篇文章我就把从零开始搭建这套可视化监控平台的完整过程捋一遍所有步骤都是我自己在生产环境实际跑过的参数怎么配、哪些坑不能踩都会交代清楚。不管你是刚入门的运维新人还是想把手头服务器纳入统一监控的老手这套流程都可以直接抄作业。1. 项目概述为什么偏偏是Prometheus和Grafana1.1 监控平台到底解决了什么问题服务器监控这件事往小了说是看一眼CPU高不高、磁盘满没满往大了说其实是两件事预警和追踪。预警好理解指标超过阈值提前报警别等用户发现才补救。追踪则更关键——当业务出现抖动你得能从历史曲线里往回倒推还原出当时系统到底发生了什么。没有监控这些问题都只能靠猜而运维工作一旦进入“猜测模式”效率和口碑基本就是零。我自己最早用的监控工具其实是脚本加定时任务写个shell脚本每五分钟跑一次记录一下负载和内存出问题再去翻文本日志。说实话这种方式在小规模场景下勉强能用但一旦机器数量超过十台脚本管理就变成一场灾难更别提需要临时去对比多台机器的同一时间点的状态了。后来转向集中式监控平台是必然选择而Prometheus加上Grafana这套组合恰好把数据采集、存储、查询和可视化这几块全部覆盖了。1.2 三件套的核心角色划分这套方案里有几个组件各自负责的活儿完全不同。Prometheus主监控服务器负责抓取指标数据、存储时间序列、执行告警规则。它本身是自带时序数据库的所以不需要额外再接MySQL或者PostgreSQL来存监控数据。Exporter被监控机器上的数据采集代理会把操作系统层面的各种状态CPU、内存、磁盘、网络等转化成Prometheus能识别的指标格式然后等在一旁让Prometheus来拉取。Grafana可视化前端连接Prometheus作为数据源把指标画成面板、仪表盘、折线图。告警功能它也能做但我通常把正式告警交给Prometheus的Alertmanager组件处理Grafana定位就是纯粹的展示和交互。你要理解这套架构的巧妙之处就记住一个词拉模式。Prometheus是主动去各台机器上拉取数据而不是各机器往上报送。这样主监控端完全掌控了采集节奏新增一台机器只需要改一下Prometheus的配置文件就行不用去那台机器上部署Agent端的上报脚本规模扩展非常顺滑。1.3 和别家方案的对比它强在哪很多刚接触监控的朋友会问Zabbix不是也挺火的吗为什么选Prometheus我用下来最大的感受是Prometheus的指标模型是多维度的。Zabbix的监控项定义比较复杂每条数据要想清楚是浮点数还是字符型预处理怎么搞。而Prometheus里每个指标就是一组带标签的数值序列比如说统计所有机器的CPU使用率条件是某台机器、某个CPU核心、某种模式用户态还是内核态直接在查询语句里动态筛选就行灵活度完全不在一个级别。另外Prometheus的查询语言PromQL上手之后是真的好用一条语句就能算出过去五分钟的CPU平均使用率还能按不同标签分组展示。再加上Grafana社区里现成的仪表盘模板特别多导入即用不用每次从空白画起。整体来说这套方案的学习曲线确实存在但过了那层窗户纸带来的收益绝对对得起投入的时间。2. 环境准备开始之前的必要功课2.1 最小硬件配置参考先说配置很多人一上来就担心Prometheus是不是特别吃资源。这里给一个我在实际部署中验证过的参考范围监控服务器跑Prometheus和Grafana2核CPU、4GB内存足够应付几百台节点的规模磁盘看你的数据保留周期按每天约2GB估算就行。如果监控的机器数量大或者指标特别密集再加配置也不迟。被监控的Linux服务器跑Node Exporter只需要很小的开销512MB内存的老机器也能轻松跑起来CPU占用通常连1%都不到。我自己在不少低配云主机上验证过完全不影响业务。有一说一如果你只是个人学习或者家里有几台服务器玩一下用一个普通的Linux虚拟机甚至树莓派都能扛住这套监控系统没必要过度配置。2.2 操作系统版本的选择这套方案对Linux发行版基本不挑CentOS系、Ubuntu系、Debian都行甚至国产Linux系统也可以正常跑因为Prometheus和Grafana都提供了通用的二进制包和systemd服务支持。不过有几个小差异点要留意在Ubuntu和Debian上二进制包直接扔到/usr/local/bin就能跑systemd服务文件路径在/etc/systemd/system/。在CentOS/RHEL系上如果开启了SELinux需要注意端口和目录权限的放行否则会出现服务起得来但数据写不进去的诡异情况。如果是国产Linux环境架构通常跟CentOS 7/8保持一致直接按CentOS那套来就好基本没有兼容性问题。我在后面的演示里统一以Linux系统的通用操作为准同时标注两边的差异。示例环境我用的是Ubuntu 22.04CentOS用户看差异说明就行。2.3 工具准备与前置条件在正式动手之前你需要保证下面这些是准备好的一台能联网的Linux服务器并且你拥有root权限或者能通过sudo切换。监控软件要写系统目录、注册服务、开端口这一步省不掉。控制台终端工具比如Windows自带的Terminal或者Mac上的iTerm2你用Xshell这类工具远程连接也行关键是能贴命令和看输出。了解一点基础的Linux常用命令tar解压、vi编辑、systemctl管理服务。如果你完全没碰过这些命令建议先去把Linux常用命令大全翻一遍再回来否则后面每一步都会卡壳。还有一点防火墙。很多朋友把软件装好了结果Prometheus启动正常但Grafana连不上数据源十有八九就是防火墙把9090端口挡住了。Ubuntu上要用ufw放行端口CentOS上要用firewall-cmd操作这个细节后面排查章节我会重点再提。3. 动手安装Prometheus服务器端3.1 获取安装包与目录规划Prometheus官方提供了预编译的二进制包里面包含了主程序和一个默认配置示例不需要自己编译源码。到Prometheus官网的下载页面找到linux-amd64的压缩包复制下载链接后用wget拉取到服务器上。这里我分享一下我的目录规划习惯按这个结构来后续升级和排查都方便# 创建专用目录结构 mkdir -p /opt/prometheus/{bin,conf,data}把二进制包解压后prometheus主程序和promtool工具都放到/opt/prometheus/bin/目录下配置文件统一放在/opt/prometheus/conf/监控数据落在/opt/prometheus/data/。这样做的核心好处是Prometheus、Grafana、Exporter等各类组件配置路径一目了然哪天要备份、要清理直接对着目录来就行不会出现安装包解压在哪就在哪的混乱局面。3.2 编写Prometheus主配置文件Prometheus的所有行为都靠一个YAML格式的配置来驱动。文件路径可以自己定但内容结构是固定的。下面这是一个最小可用的配置global: scrape_interval: 15s # 采集频率 evaluation_interval: 15s # 告警规则评估频率 scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090]这段配置的意思非常直白每15秒对localhost:9090这个地址发起一次抓取请求抓取到的数据就是Prometheus自身的运行指标比如它收到了多少请求、处理了多少采样点、内存用了多少。刚装完第一件事就是先把Prometheus自己管起来确认整个链路是通的再逐步扩展监控目标。这个配置文件的每个字段都不是随便写的scrape_interval决定了数据的时间颗粒度设得越小数据越密集但同时存储和查询的压力也会上去。对于绝大多数系统监控场景15秒足够了。告警规则的评估频率也同理不需要太激进否则会频繁产生无意义的重复告警。3.3 启动Prometheus服务为了方便管理我用systemd把它注册成系统服务这样开机自动启动挂了还能自动拉起。在/etc/systemd/system/prometheus.service写入以下内容[Unit] DescriptionPrometheus Server Afternetwork.target [Service] ExecStart/opt/prometheus/bin/prometheus \ --config.file/opt/prometheus/conf/prometheus.yml \ --storage.tsdb.path/opt/prometheus/data \ --web.listen-address0.0.0.0:9090 Restartalways Usernobody [Install] WantedBymulti-user.target有几个参数值得展开说说。--storage.tsdb.path是时序数据落盘位置我单独指定到data目录防止和程序目录混在一起默认情况下时序数据会保留15天这个是内置策略如果你想存更久后续需要用--storage.tsdb.retention.time参数来调整--web.listen-address如果不设置默认就是监听0.0.0.0:9090但我习惯写出来明确告诉别人这个服务端口是故意暴露出来的。保存文件后执行systemctl daemon-reload systemctl enable --now prometheus systemctl status prometheus看到active (running)的状态就说明Prometheus已经跑起来了。这时候用浏览器访问http://你的服务器IP:9090你会看到一个简约的查询界面这是Prometheus自带的简易Web UI。你可以在它的输入框里敲一个查询语句试试比如prometheus_tsdb_head_samples_appended_total回车就能看到实时数据。这个UI本身没法和Grafana比但胜在方便适合临时查数据用。4. 接入系统监控指标Node Exporter4.1 Node Exporter是什么角色Prometheus本身只管采集真正去操作系统内部读取各种状态数据的是Node Exporter。它是一个独立的小程序运行在被监控的机器上会自动收集内核暴露出来的各项指标CPU使用率、内存占用、磁盘空间、网络流量、文件系统inode耗尽情况、系统负载等然后统一放在/metrics接口里等Prometheus来抓。Node Exporter确实能往前端可视化页面传递数据这可行。但最常见的判断是监控基础资源用Node Exporter监控具体应用再上对应的exporter。比如MySQL数据库配MySQL ExporterRedis配Redis ExporterNginx配Nginx Exporter。安装Node Exporter的方式和Prometheus一模一样也是下载二进制包解压运行。为了管理方便我同样是注册成systemd服务。它的默认监听端口是9100启动命令非常简单# 同样下载node_exporter的二进制包放到/opt/node_exporter/ /opt/node_exporter/node_exporter --web.listen-address:9100如果你担心9100端口暴露在公网上不安全可以用--web.listen-address127.0.0.1:9100只监听本机回环地址然后让Prometheus通过SSH隧道或者内网地址来采集。不过一般情况下被监控机器和监控主机都在内网环境里直接监听内网IP即可。4.2 把节点加入Prometheus的抓取任务Node Exporter装好后回到Prometheus主配置文件的scrape_configs里增加一段新的job配置让它去抓取该机器的指标scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: linux-node static_configs: - targets: - 192.168.1.101:9100 # 替换为你需要监控的机器IP这里解释一下job_name的作用它是这批监控目标的逻辑分组名称后面在Grafana作图时经常要按job来筛选机器。同一个job下可以写很多台机器每行一个IP和端口Prometheus会并行去抓取。改完配置后重启服务Prometheus那边不需要任何额外的命令下次抓取周期到达时会自动发现新目标。重启后可以在Prometheus的Web UI里打开Status - Targets页面能看到每个job下的监控目标列表状态为UP就代表抓取成功。这个页面是我日常排查的首选入口只要哪个目标状态是DOWN多半就是网络不通、端口被防火墙堵了或者Exporter进程挂了。4.3 用动作和脚本验证采集链路确认Node Exporter的数据进了Prometheus之后可以在Prometheus查询框里试试这些基础指标判断链路是否正常# 查看所有节点的CPU使用率百分比 100 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100 # 查看内存使用率 (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 # 查看根分区磁盘使用率 100 - (node_filesystem_avail_bytes{mountpoint/} / node_filesystem_size_bytes{mountpoint/}) * 100这些查询语句看起来复杂但拆开看就不难了。rate函数是PromQL中最常用的专门用来计算计数器指标的变化速率比如CPU在5分钟内从累计值变成了每秒的使用率。换成人话说这条语句就是在算“过去五分钟CPU的空闲时间占比是多少然后拿100减掉得到实际使用率”。理解了这一层后面你写任何查询逻辑都会有思路。多提一嘴node_cpu_seconds_total这个名字它其实是一个累计值cgroup统计的是从开机到现在CPU在各种模式下总共消耗的秒数。直接查询这个数你会看到一个不断增长的大数值本身没有太大意义用一个rate()函数把它转成每秒速率再配合modeidle过滤出空闲模式才能算出来使用率。这是PromQL最重要的思维转换——监控的是速率不是累计值。5. 部署Grafana可视化展示的核心层5.1 安装与首次启动Grafana的安装包在官网可以找到支持rpm、deb和二进制压缩包几种形式。我用的是二进制包方式因为内部服务器经常与互联网物理隔离YUM或APT源不一定可用下载离线包分发是最常见的部署路径。下载后同样解压把主程序和辅助文件放到/opt/grafana目录wget https://dl.grafana.com/enterprise/release/grafana-enterprise-10.4.2.linux-amd64.tar.gz tar -zxvf grafana-enterprise-10.4.2.linux-amd64.tar.gz mv grafana-10.4.2 /opt/grafanaGrafana默认读取它自己目录下的conf/defaults.ini获取配置如果你需要自定义端口或数据目录可以复制一份defaults.ini改名为custom.ini再修改。不过对于大部分初始部署保持默认配置足够。启动方式同样用systemd托管好处是开机自启动进程崩溃能自动拉起。跳过这个直接跑二进制也没毛病但就没有守护进程了。启动后浏览器访问http://服务器IP:3000首次打开会看到登录页面默认用户名和密码都是admin。系统会强制你修改初始密码这里建议改成强密码并妥善记录因为Grafana账号有数据源的配置权限一旦泄露不仅监控数据暴露攻击者还能通过Grafana的接口去探测内网的IP和端口。5.2 配置Prometheus数据源登录后进入的是Grafana的主界面。现在服务端还是空壳必须先添加数据源告诉它往哪儿查数据。步骤如下鼠标移到左侧边栏的“齿轮”图标上点击“Connections”里的“Data sources”。点击“Add data source”按钮在列表里选择“Prometheus”。在“URL”栏填写Prometheus的地址例如http://192.168.1.100:9090。我这里特意说明一下如果你的浏览器和服务器不在同一台机器IP不要写localhost。点击页面底部的“Save test”看到绿色的“Successfully queried the Prometheus API”提示就代表连接成功。这一步是整套可视化链路中的胜负手我见过不少人卡在这里。最常见的坑是URL写成了localhost:9090但浏览器打开的Grafana页面来自远程它拿localhost去连Prometheus自然连不上。说白了这个URL是Grafana服务器进程去访问的地址不是你的浏览器去访问的地址必须写Grafana服务器能访问到的Prometheus地址。然后是端口放行问题很多环境下Linux防火墙默认禁止跨主机的9090端口互访测试数据源连接失败时先用telnet IP 9090检查一下网络通不通再怀疑配置问题。5.3 快速导入现成的仪表盘模板Grafana最吸引人的一个地方就是社区里的仪表盘模板极其丰富不需要从零开始画图表。在Grafana官网的Dashboard页面搜索“Node Exporter Full”或者“Linux Hosts”能找到很多现成的面板模板每个模板都有一个对应的ID编号。以我长期在用的模板1860为例操作步骤是在Grafana左侧边栏点击“”号选择“Import”。在“Import via dashboard ID”栏输入1860点击“Load”。下拉菜单里选择之前配好的Prometheus数据源点击“Import”。几秒钟后一个包含CPU、内存、磁盘、网络、进程等几十个面板的完整仪表盘就出现了。导入成功后页面展示的是一整套Linux主机状态总览从总览页能看到当前在线的主机数、平均负载、整体CPU趋势、内存使用柱状图等。需要注意这类模板默认可能只配置了一个主机变量如果你监控了多台机器右上角的下拉框里可以切换。模板毕竟是社区贡献的个别面板可能出现无数据的情况多半是模板作者用的查询语句里带了一些固定标签过滤条件你把查询语句改一下就能适配自己的环境。这块不想折腾的话也可以先学着自己从第一个空白面板画起练熟了再考虑套模板节省时间。6. 亲手配置第一个可视化面板6.1 从空白画布开始自己动手画面板是理解Grafana的核心环节。光会导入模板还不行模板是别人的思路出了诡异数据你根本不知道问题出在哪自己画过一遍就知道每个数字是怎么算出来的了。个人建议刚接触时一定要抽出半小时从空白面板开始做。新建面板的入口在左侧“”号然后选“Dashboard”进入Dashboard编辑界面后点击“Add”选“Visualization”。Grafana提供了丰富的图表类型监控场景下最常用的是时间序列图也就是折线图。面板右侧编辑区分为几个维度Data source选择PrometheusQuery Type保持默认的Metrics然后关键的就是在输入框里写PromQL查询语句。6.2 常用PromQL查询解析我们用一个监控CPU使用率的查询来做演示在查询编辑器里输入100 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100这时面板上应该立刻出现一条曲线横轴是时间纵轴是百分比。如果你监控了多台机器Prometheus返回的每个序列会带上机器实例的标签图表里就会显示多条不同颜色的线。面板右上角还可以设置数据刷新周期比如每15秒自动拉取新数据页面就像活的一样在跳动。关于CPU这个查询我再说一个容易忽略的点avg如果不加by(instance)会把所有CPU核心和所有机器混合求平均你看到的是一条总平均曲线。要区分开每台机器和每个核心可以这样写avg(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance)意思是按instance标签分组后分别求每台机器的平均使用率。同理如果你想看每个CPU核心的使用率by(cpu)就行。Grafana查询框支持直接调整PromQL语句改完立刻能看到图表变化多试几次就掌握标签筛选和聚合的玩法了。6.3 面板变量让Dashboard支持多台机器切换单台机器画好了接下来需要让面板演示更灵活。Grafana支持定义模板变量简单来说就是让你在Dashboard顶部加一个下拉框点击切换监控目标所有关联面板自动刷新展示对应数据。在Dashboard页面点击右上角的“Settings”图标进入“Variables”标签页点击“Add variable”。变量类型选择“查询”查询语句可以写成这样它会把所有出现在特定标签值里的机器名称列出来label_values(node_boot_time_seconds, instance)添加完成后在面板的查询语句里把原来写死的机器IP替换成变量100 - avg(rate(node_cpu_seconds_total{instance$host}[5m])) * 100这样切换变量值所有用到变量的面板会同时切换展示对象。这个功能用在几十台服务器组网监控时尤其好使每个业务组建一组机器清单变量整个Dashboard就变成了一套可交互的业务监控总览。7. 告警推送走出可视化的最后一步7.1 Prometheus告警规则怎么写监控的最终目的不是画图是故障时能第一时间通知到人。Prometheus的告警体系分两层规则层负责判断“指标是否越界”通知层由Alertmanager承担负责把告警发送到钉钉、邮件、企业微信等渠道。告警规则写在独立的规则文件里在Prometheus主配置文件中指定引用例如rule_files: - /opt/prometheus/rules/node_alerts.yml然后在node_alerts.yml里面定义具体的规则用一个最简单的示例groups: - name: node_alerts rules: - alert: InstanceDown expr: up 0 for: 2m labels: severity: critical annotations: summary: Instance {{ $labels.instance }} is down description: Host is unreachable for more than 2 minutesup这个指标非常特殊它是Prometheus在每次抓取目标时自动生成的一个指标1代表成功0代表失败。up 0的意思就是有监控目标抓取失败了。后面的for: 2m表示这个状态要持续2分钟才触发告警这样能有效防止偶发抖动造成的误报。我遇到过的最奇葩问题是告警规则写好了Prometheus的--alertmanager.url参数没配置导致告警状态能在UI上看到但根本不发送。告警状态从Inactive到Pending再到Firing只在Prometheus内部有记录不推送到Alertmanager就等于白搭。7.2 Alertmanager的部署与通知配置Alertmanager是Prometheus生态里的告警集中器负责接收Prometheus推送来的告警事件然后根据路由规则分发给不同渠道。它的安装包同样是预编译二进制下载解压后配置一个alertmanager.yml。下面是一个配置了钉钉机器人通知的简版配置route: group_by: [alertname] group_wait: 10s group_interval: 10s repeat_interval: 1h receiver: webhook receivers: - name: webhook webhook_configs: - url: http://127.0.0.1:8060/dingtalk/webhook1这套流程配置完成后告警链路变成Prometheus判断出InstanceDown状态为Firing推给AlertmanagerAlertmanager再根据路由规则把消息POST到钉钉机器人的Webhook地址钉钉群里立刻跳出一条红色告警。整个过程只需要记清楚规则层管“判断”服务层管“发送”。实际生产中钉钉和飞书这类办公软件的群机器人配置都很简单就是用自定义关键词加一个Webhook地址。通知信息会带着告警标题、级别、实例地址和触发时间。如果你需要更丰富的交互可以后续再接一个简单的中转服务去格式化消息让告警内容里附带当前的主机实时负载信息等。8. 生产环境的常见问题与排障手册8.1 服务起不来或端口不对表现是systemctl status prometheus显示服务未运行或者浏览器访问不了9090端口。排查分三步走先看服务日志journalctl -u prometheus -f配置文件路径写错了、目录没建、参数拼错日志里都会有明确提示。再确认端口占用ss -lntp | grep 9090如果端口被占用多半是之前启动过但没彻底关掉kill进程后重新启动即可。最后检查防火墙我处理过太多案例服务明明监听正常但外部就是不通换台机器telnet一下发现端口不通然后检查firewalld或ufw规则放行915端口才结束。很多人卡在“服务明明起来了为什么访问不了”就是防火墙这一关。拦路虎不是配置本身而是运维意识里总是默认防火墙没作用其实现在的发行版默认都开防火墙主动放行端口是标准动作换个思路能少踩很多坑。8.2 Grafana面板没有数据这一个问题能覆盖十个不同原因排查时要有顺序。先用Prometheus的查询界面验证数据源有没有数据。打开Prometheus的Graph页面输入up执行查询。如果这里就查不到数据说明Prometheus侧就有问题先检查Targets页面里监控目标的状态全部DOWN的话要么是Exporter没起要么是网络不通。如果Prometheus有数据但Grafana面板空白多半是查询语句里带了不存在的标签名或者面板用了模板变量但变量没有匹配到任何序列还有一种常见情况是面板时间范围设置得不对选的是最近三天而数据昨天才开始采集进Prometheus。我经历过一次特别隐蔽的问题Grafana面板里部分图表空着后来看到查询语句里写死了hostname~$host而我定义的主机名变量和节点上的hostname标签值不一致。这种问题在导入模板时特别常见模板作者的标签命名和你的环境不匹配需要检查一下实际数据里的标签列表对号入座。8.3 时间不同步导致数据错乱Prometheus对监控目标的时间戳非常敏感。如果被监控机器的系统时间和监控服务器差异过大常见表现为数据点丢失、突变、时好时坏。这是因为Prometheus在存储序列时会检测数据点的时间戳是否合理当前时间差超过一定范围的数据可能会被拒绝写入。这个问题的根治方案很简单所有服务器统一启用NTP时间同步。# Ubuntu timedatectl set-ntp true # CentOS yum install -y chrony systemctl enable --now chronyd时间同步之后定期用timedatectl status确认一下即可。我见过两台机器只差了五分钟监控曲线就开始出现奇怪的毛刺这个问题往往被忽视但它对数据可信度的影响极大。8.4 数据膨胀与磁盘用尽Prometheus存储时间序列数据是按采样点来算的指标越多、采集间隔越短、保留时间越长占用磁盘越多。尤其是Exporter侧带出了很多隐藏的高基数指标比如网络连接状态按客户端IP拆分这种数据量很容易失控。这里规划一个常规的容量预估假设你监控50台机器每台机器大约产生3000个时间序列Prometheus每秒大概会接收1500个采样点每天大约要消耗2GB磁盘空间。当然这只是个保守估算值真实情况取决于指标数量和数据基数。如果磁盘比较紧张可以在启动参数中按需缩短保留周期--storage.tsdb.retention.time7d保留7天的数据对于大多数系统监控场景够用因为查询历史趋势一般就看最近一周。结尾个人的一点实践经验整套平台从零到能用的过程如果操作顺利一个小时以内就能跑通。但想把它用出价值关键还在于日常的持续投入每接入一台新业务就顺手把对应的监控指标梳理一遍每次线上出问题时都去复盘一下监控数据里是否早就暴露出了蛛丝马迹。这也是我写这篇文章的主要愿望——帮大家把监控体系的基础打稳省下的时间可以花在更有价值的事情上。根据我个人的使用习惯最后还建议你养成一个“小操作”每次修改过Prometheus配置或者新增面板之后都导出一份当前配置文件的备份用Git管理起来。别小看这一步生产环境出问题时你做的第一件事一定是回看“上一次可用的配置是什么”而不是原地猜测。祝大家的监控曲线都长一条直线——平稳、健康、不用半夜爬起来接告警电话。