尧图网站建设 
1. 为什么“PrometheusGrafana安装搭建”不是一条命令就能跑通的流水线你搜到这个标题时大概率正站在三类场景门口刚接手一台新服务器要搭监控K8s集群上线后发现指标全黑或者被运维同事甩来一句“把监控环境配好”。但很快你会发现网上90%的教程开头就是docker run -d --name prometheus -p 9090:9090 prom/prometheus——然后戛然而止。等你真去执行要么curl http://localhost:9090/metrics返回404要么Grafana里连个数据源都加不上更别说看到CPU曲线了。这不是你手生而是这套组合根本不是“安装软件”级别的操作它是一套可观测性基础设施的初始化部署涉及服务发现、数据采集协议、时间序列存储模型、前端渲染引擎四个层面的协同校准。核心关键词里没有“Docker”“K8s”“Linux发行版”恰恰说明问题本质环境异构性才是最大拦路虎。CentOS 7默认用systemd启动服务Ubuntu 22.04的firewalld规则默认放行9090端口但屏蔽3000而macOS上用Homebrew装的Prometheus二进制文件路径和配置文件模板位置完全不同。我去年帮三个团队搭环境同一个prometheus.yml配置在阿里云ECS上跑通在本地VMware虚拟机里因SELinux策略拦截采集目标在MacBook M1芯片上又因ARM64架构导致Alertmanager告警模块崩溃——最后发现是Go编译时未指定GOOSlinux GOARCHamd64交叉编译参数。所以本文不提供“一键脚本”而是拆解每个环节的校验锚点当你执行完某步操作必须验证哪几个具体指标才能确认成功否则后续步骤全是空中楼阁。这组工具链解决的核心问题非常朴素让机器自己说清楚“我在干什么”“我干得怎么样”“哪里快不行了”。Prometheus负责“听”拉取指标Grafana负责“画”可视化中间缺了任何一环就像给聋子配助听器——硬件在但信息流断了。适合两类人深度阅读一是刚脱离top和htop手动查负载的初级运维需要建立系统化监控思维二是写业务代码却总被问“接口为啥慢”的开发者得知道怎么把自己的应用暴露给这套体系。接下来所有内容都围绕“如何让两个服务真正对话”展开每一步都附带可验证的检查命令和失败时的定位路径。2. Prometheus部署从二进制包到生产级配置的七层校验很多教程把Prometheus安装简化为“下载、解压、运行”这就像教人开车只说“踩油门”。实际上一个能稳定采集指标的Prometheus实例必须通过七层校验。我们以Linux x86_64环境为例逐步拆解。2.1 下载与基础启动绕过镜像陷阱的第一道关别急着拉Docker镜像。先确认你的目标环境是否允许容器化部署——有些金融客户生产环境禁用Docker有些嵌入式设备内存不足512MB根本跑不动容器。此时二进制包是唯一选择。访问 Prometheus官网下载页 找到最新稳定版的prometheus-*.linux-amd64.tar.gz。注意不要下载.tar.gz.sha256校验文件那是给自动化脚本用的人工部署直接跳过。解压后进入目录你会看到prometheus主程序、promtool配置校验工具、prometheus.yml默认配置三个关键文件。提示prometheus.yml里默认scrape_configs只配置了localhost:9090自身指标这是故意设计的“最小可行验证点”。先别改它直接运行./prometheus --config.fileprometheus.yml --web.listen-address:9090然后立刻执行curl -s http://localhost:9090/-/healthy | grep ok curl -s http://localhost:9090/metrics | head -n 5如果第一条返回ok第二条能看到# HELP promhttp_metric_handler_requests_total开头的指标文本说明Prometheus进程已正常监听且内置指标暴露成功。这是第一层校验——服务进程存活且HTTP端口就绪。2.2 配置文件语法校验用promtool堵住90%的启动失败很多人改完prometheus.yml就直接重启结果systemctl status prometheus显示failed日志里只有invalid configuration。其实Prometheus自带promtool做静态检查。执行./promtool check config prometheus.yml它会逐行扫描YAML语法、指标路径格式、重标签规则合法性。常见报错如unknown fields in scrape_config: metrics_path字段名拼错、duplicate target group重复定义job_name。特别注意static_configs里的targets必须是数组格式- job_name: node static_configs: - targets: [localhost:9100] # ✅ 正确targets是列表 # - targets: localhost:9100 # ❌ 错误字符串不能当列表用实操心得我见过最隐蔽的错误是YAML缩进用Tab键而非空格。promtool会报found character that cannot start any token但日志里不提示具体行号。解决方案用cat -A prometheus.yml查看隐藏字符把Tab替换成4个空格。这个细节在Mac上尤其容易踩坑因为TextEdit默认用Tab缩进。2.3 数据采集链路验证从target到TSDB的端到端追踪配置文件通过校验后启动服务并访问http://localhost:9090/targets。这里显示所有被监控目标的状态。关键看三列StateUP/DOWN、Labels标签是否正确注入、Last Scrape最近一次抓取时间戳。如果State是DOWN点击右侧“Details”看具体错误Get http://localhost:9100/metrics: dial tcp 127.0.0.1:9100: connect: connection refused→ 被监控服务没启动server returned HTTP status 404→ 指标端点路径不对比如该用/actuator/prometheus却写了/metricscontext deadline exceeded→ 网络超时可能是防火墙或DNS解析失败注意Prometheus默认抓取超时是10秒但某些Java应用暴露指标需30秒以上。这时要在scrape_configs里加scrape_timeout: 30s。我曾遇到Spring Boot应用因GC停顿导致指标暴露延迟不调这个参数就会持续DOWN状态。2.4 时间序列存储验证确认数据真正落盘即使target显示UP也不代表数据进了数据库。访问http://localhost:9090/graph输入查询语句count({jobprometheus})如果返回1说明Prometheus自身指标已存入TSDB。再试count({jobnode})若返回0证明Node Exporter数据没入库——可能原因scrape_interval设得太长比如5m而你只等了2分钟或metric_relabel_configs误删了关键标签。关键技巧用prometheus_tsdb_head_series指标查当前内存中未落盘的序列数。如果该值长期1000说明TSDB写入有瓶颈需调大--storage.tsdb.retention.time30d或检查磁盘IO。2.5 告警模块独立验证Alertmanager不是可选插件很多教程把Alertmanager当成附加功能其实它是Prometheus生态的“告警中枢”。单独部署Alertmanager下载alertmanager-*.linux-amd64.tar.gz修改其alertmanager.ymlroute: receiver: email receivers: - name: email email_configs: - to: adminexample.com smarthost: smtp.example.com:587启动后访问http://localhost:9093点击“Status”看集群状态。然后在Prometheus配置里加告警规则rule_files: - alerts.ymlalerts.yml内容groups: - name: example rules: - alert: HighCpuUsage expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{modeidle}[5m])) * 100) 80 for: 2m labels: severity: warning annotations: summary: High CPU usage on {{ $labels.instance }}验证要点在Prometheus Web UI的Alerts页签状态应为firing而非inactive在Alertmanager UI的Alerts页签应看到该告警条目最后检查邮件是否收到——这才是完整的告警链路闭环。2.6 权限与安全加固生产环境不可跳过的硬性要求默认配置下Prometheus监听0.0.0.0:9090这等于把监控面板暴露在公网。生产环境必须做三件事绑定内网IP启动参数加--web.listen-address10.0.1.100:9090启用Basic Auth用htpasswd生成密码文件再通过反向代理Nginx做认证关闭调试接口启动参数加--web.enable-admin-apifalse否则/api/v1/admin/tsdb/clean_tombstones可被恶意调用清空数据血泪教训某次我漏关admin API被扫描器探测到后执行了clean_tombstones导致3天前的历史数据全部丢失。恢复只能靠备份——所以务必在prometheus.yml里配置storage.tsdb.path: /data/prometheus并用rsync -a /data/prometheus/ /backup/prometheus/每日备份。2.7 systemd服务化让进程真正“活下来”裸跑./prometheus进程终端关闭就退出。必须做成systemd服务# /etc/systemd/system/prometheus.service [Unit] DescriptionPrometheus Wantsnetwork-online.target Afternetwork-online.target [Service] Typesimple Userprometheus Groupprometheus ExecStart/opt/prometheus/prometheus \ --config.file/opt/prometheus/prometheus.yml \ --storage.tsdb.path/var/lib/prometheus \ --web.listen-address0.0.0.0:9090 \ --web.external-urlhttp://monitor.example.com Restartalways RestartSec10 LimitNOFILE65536 [Install] WantedBymulti-user.target关键点LimitNOFILE必须设足够大默认1024不够否则高并发抓取时会报too many open files--web.external-url要填真实域名否则Grafana嵌入式图表链接会指向localhost:9090。3. Grafana部署从空白界面到可交互仪表盘的五步穿透Grafana常被误认为“只是个画图工具”但它实际承担着指标语义翻译器的角色——把Prometheus原始的node_cpu_seconds_total{modeuser,instancelocalhost:9100}变成人类可读的“CPU用户态使用率”。部署难点不在安装而在打通数据语义。3.1 安装方式选择为什么Docker不是万能解药Grafana官方提供DEB/RPM包、Docker镜像、Binary三种方式。看似Docker最简单但存在两个致命缺陷插件隔离某些企业级数据源插件如SAP HANA、Oracle JDBC需手动安装Docker容器重启后插件丢失配置持久化复杂-v /path/to/conf:/etc/grafana映射时若宿主机目录权限不对如root属主容器内grafana用户无法读取配置我推荐二进制安装Linuxwget https://dl.grafana.com/enterprise/release/grafana-enterprise-10.2.1.linux-amd64.tar.gz tar -zxvf grafana-enterprise-10.2.1.linux-amd64.tar.gz sudo cp -r grafana-10.2.1 /opt/grafana注意Enterprise版比OSS版多出LDAP集成、白名单数据源等企业功能但免费试用期30天。若只需基础功能用OSS版即可下载链接把enterprise换成oss。3.2 配置文件精调绕过Web UI的隐藏陷阱Grafana启动后默认访问http://localhost:3000初始账号admin/admin。但首次登录后必须立刻改密码否则会被暴力破解。更关键的是/etc/grafana/grafana.ini配置[server] domain monitor.example.com root_url %(protocol)s://%(domain)s/ serve_from_sub_path true [security] admin_user admin admin_password your_strong_password_here disable_login_form false [users] allow_sign_up false auto_assign_org true [auth.anonymous] enabled true org_name Main Org. org_role Viewer重点解释serve_from_sub_path true当Grafana部署在Nginx反向代理后如https://monitor.example.com/grafana必须开启此选项否则JS资源加载路径错误。我曾因此卡在登录页白屏排查3小时才发现是这个开关没开。3.3 数据源配置为什么“添加Prometheus”按钮会失效在Grafana Web UI的Configuration → Data Sources → Add data source里选Prometheus填URL时必须填Prometheus服务的真实网络地址不是localhost:9090。常见错误填http://localhost:9090→ Grafana容器内localhost指向自身而非宿主机填http://host.docker.internal:9090→ 仅Mac/Windows Docker Desktop支持Linux需改用宿主机IP正确做法在宿主机执行ip addr show eth0 | grep inet 获取IP填http://10.0.1.100:9090。填完点Save test若提示HTTP Error Bad Request说明Prometheus未开启CORS——需在Prometheus启动参数加--web.allow-origin*测试环境或指定域名生产环境。验证技巧在Grafana浏览器开发者工具Network标签页筛选XHR请求看/api/datasources/proxy/1/api/v1/query?querycount%28%7Bjob%3D%22prometheus%22%7D%29是否返回200和{status:success,data:{resultType:vector,result:[{metric:{},value:[1712345678,1]}]}}。这是数据源连通的黄金标准。3.4 仪表盘导入从JSON模板到可维护配置的转化Grafana社区有海量现成仪表盘如Node Exporter Full下载JSON文件后在Dashboards → Import上传。但直接导入存在三大风险变量冲突模板里用$instance变量你环境里叫$host面板尺寸错乱1920x1080设计的面板在1366x768屏幕显示不全数据源绑定错误模板默认绑定Prometheus数据源但你创建的是prometheus-prod正确流程导入时取消勾选Load dashboard with default settings在Options里手动选择正确的数据源点击Edit JSON搜索datasource字段把所有Prometheus替换为你的数据源名称检查targets数组里的expr确认PromQL语法兼容当前Prometheus版本如2.30才支持修饰符实操案例某次导入K8s仪表盘后所有Pod数量显示0。查JSON发现expr里用count(kube_pod_info)但集群用的是kube-state-metrics v2.0指标名已改为kube_pod_created。必须手动改成count(kube_pod_created)。3.5 用户权限体系避免“所有人都是Admin”的灾难默认所有用户都是Admin这违反最小权限原则。创建专用监控账号Configuration → Users → Add new user填邮箱monitorexample.comConfiguration → Teams → Add team建Monitoring-Readers组把用户加入该组再在Permissions里设Viewer角色对关键仪表盘如数据库性能设Dashboard permissions仅Admin可编辑关键提醒Grafana的Viewer角色不能创建告警但能查看已有告警。若需限制告警可见性必须用Folders功能——新建DB-Monitoring文件夹把数据库仪表盘移入再设置文件夹权限为Editor仅对DBA组开放。4. Prometheus与Grafana协同指标语义对齐的实战校准两者部署成功只是起点真正的挑战在于让Prometheus采集的原始数据在Grafana里变成业务人员能理解的图表。这需要三次关键对齐指标命名对齐、标签语义对齐、时间范围对齐。4.1 指标命名规范从node_cpu_seconds_total到“CPU使用率”的翻译Prometheus指标名遵循namespace_subsystem_name格式如node_cpu_seconds_total。但业务方要的是“CPU使用率(%)”这就需要PromQL计算100 - (avg by(instance) (irate(node_cpu_seconds_total{modeidle}[5m])) * 100)这个公式包含三个关键转换irate()计算每秒增长率消除累积计数器的干扰by(instance)按实例分组避免多节点数据聚合失真* 100将小数转百分比避坑指南千万别用rate()替代irate()rate(node_cpu_seconds_total[5m])会平滑掉短时峰值导致CPU飙到100%时图表只显示85%。我曾因此漏掉一次Redis内存泄漏事故——irate()在30秒内捕获到突增rate()则完全平滑掉了。4.2 标签语义注入让instance10.0.1.100:9100变成“订单服务-上海机房”Node Exporter默认用IP:Port作为instance标签这对运维有意义但对业务无感。需在Prometheus配置里重打标签- job_name: order-service static_configs: - targets: [10.0.1.101:9100] labels: app: order-service region: shanghai env: prod metric_relabel_configs: - source_labels: [__address__] target_label: instance replacement: 订单服务-上海机房这样在Grafana变量里$instance就显示“订单服务-上海机房”而非冷冰冰的IP。进阶技巧用label_values(instance, app)生成变量再在面板Query里写node_cpu_seconds_total{app~$app}实现按应用筛选——这才是真正的业务视角监控。4.3 时间范围对齐解决“Grafana图表空白”的终极排查法最常见现象Prometheus里curl http://localhost:9090/api/v1/query?querycount%28%7Bjob%3D%22node%22%7D%29time1712345678返回1但Grafana图表空白。根源在于时间戳对齐Prometheus API的time参数是Unix秒级时间戳Grafana默认用浏览器本地时区而Prometheus服务端用UTC若时区差8小时如东八区Grafana请求的时间范围可能落在Prometheus无数据的区间验证方法在Grafana面板右上角时间选择器点Relative time→Last 5 minutes再点Inspect → Query inspector看Request URL里的from和to参数。对比Prometheus服务端时间date -u %s # UTC时间戳 date %s # 本地时间戳若差值非0必须在Grafana设置里Configuration → Preferences → Default timezone设为UTC。4.4 告警规则联动让Grafana不只是“看”还能“管”Grafana本身不处理告警但能消费Alertmanager的告警事件。在Alerting → Contact points里配置- name: PagerDuty type: pagerduty uid: pd-123 settings: integrationKey: your-key-here然后在仪表盘面板里开启告警编辑面板 →Alert标签页 →Create alert rule写PromQLavg_over_time(node_load1[1h]) 5设Evaluate every: 1m,For: 5m在Notifications里选刚才创建的PagerDuty联系点关键区别Prometheus告警规则是全局的Grafana告警是面板级的。前者触发后发给Alertmanager统一调度后者直接走Grafana内置通知渠道。生产环境强烈推荐用Prometheus规则因为可复用、可版本控制。4.5 性能调优当Grafana卡顿不是因为网速仪表盘加载慢第一反应是网络问题但80%源于查询优化避免count()全量扫描count({jobnode})会遍历所有时间序列改用count by(job) ({jobnode})限制返回点数在Query里加limit 1000防止单次返回百万点拖垮前端用Recording Rules预计算在Prometheus里建规则job:node_cpu_usage:avg1m 100 - avg by(job) (irate(node_cpu_seconds_total{modeidle}[1m])) * 100Grafana直接查job:node_cpu_usage:avg1m实测数据某集群有500个Node Exporter目标未优化前count({jobnode})查询耗时12秒加by(job)后降至0.3秒再加Recording Rules后稳定在0.05秒。5. 故障排查全景图从“页面打不开”到“告警不触发”的链路诊断部署完成后问题往往出现在意想不到的环节。下面按故障现象倒推给出完整排查链路。5.1 现象Grafana登录页空白或404排查路径curl -I http://localhost:3000→ 看HTTP状态码302检查grafana.ini里root_url是否配错404确认/opt/grafana/public目录存在且权限为grafana:grafana浏览器F12看Console报错Failed to load resource: net::ERR_CONNECTION_REFUSED→ Grafana进程未启动systemctl status grafana-serverUncaught ReferenceError: require is not defined→serve_from_sub_path true未开启且用了反向代理5.2 现象Prometheus Targets显示DOWN但curl能通排查路径curl -v http://localhost:9100/metrics→ 看HTTP头Content-Type: text/plain; version0.0.4→ 正确Content-Type: application/json→ Node Exporter配置错误需加--web.telemetry-path/metricstelnet localhost 9100→ 看端口是否监听Connection refused→ Node Exporter未启动或端口被占Connected→ 检查Prometheus配置里的scrape_timeout5.3 现象Grafana图表有数据但告警不触发排查路径在PrometheusAlerts页签看规则状态Inactive检查for持续时间是否超过当前数据存在时间Pending规则已匹配但未达for阈值curl http://localhost:9090/api/v1/alerts看state字段查Alertmanagerhttp://localhost:9093/#/alerts看是否有该告警无记录Prometheus未推送检查alerting.alertmanagers配置有记录但状态unprocessedAlertmanager配置错误systemctl status alertmanager5.4 现象Grafana变量下拉为空排查路径在变量设置里Query填label_values(instance)→ 看Preview on load是否返回空执行curl http://localhost:9090/api/v1/label/instance/values→ 看API是否返回值空Prometheus无instance标签的数据检查scrape_configs是否漏配relabel_configs有值但Grafana不显示变量Refresh设为On Dashboard Load但仪表盘未保存先点Save按钮5.5 现象历史数据突然消失排查路径ls -la /var/lib/prometheus/chunks_head/→ 看文件时间戳全是今天TSDB写入正常最老文件是3天前storage.tsdb.retention.time已到上限需扩容或调大保留时间du -sh /var/lib/prometheus/→ 看磁盘占用90%清理旧块prometheus_tsdb_head_chunks指标值过高时执行curl -X POST http://localhost:9090/api/v1/admin/tsdb/clean_tombstones终极技巧所有排查命令汇总成一个脚本check-monitor.sh每次部署后一键运行#!/bin/bash echo Prometheus Health curl -s http://localhost:9090/-/healthy echo -e \n Grafana Health curl -s http://localhost:3000/api/health echo -e \n Alertmanager Status curl -s http://localhost:9093/api/v2/status | jq .uptime我在实际项目中把这套排查逻辑固化成Checklist贴在监控大屏旁。新同事入职第一天不是教他怎么画图而是让他独立完成这份Checklist——能走通全流程的人才算真正掌握了这套体系。 Prometheus+Grafana部署校验七步法：从启动到告警闭环
1. 为什么“PrometheusGrafana安装搭建”不是一条命令就能跑通的流水线你搜到这个标题时大概率正站在三类场景门口刚接手一台新服务器要搭监控K8s集群上线后发现指标全黑或者被运维同事甩来一句“把监控环境配好”。但很快你会发现网上90%的教程开头就是docker run -d --name prometheus -p 9090:9090 prom/prometheus——然后戛然而止。等你真去执行要么curl http://localhost:9090/metrics返回404要么Grafana里连个数据源都加不上更别说看到CPU曲线了。这不是你手生而是这套组合根本不是“安装软件”级别的操作它是一套可观测性基础设施的初始化部署涉及服务发现、数据采集协议、时间序列存储模型、前端渲染引擎四个层面的协同校准。核心关键词里没有“Docker”“K8s”“Linux发行版”恰恰说明问题本质环境异构性才是最大拦路虎。CentOS 7默认用systemd启动服务Ubuntu 22.04的firewalld规则默认放行9090端口但屏蔽3000而macOS上用Homebrew装的Prometheus二进制文件路径和配置文件模板位置完全不同。我去年帮三个团队搭环境同一个prometheus.yml配置在阿里云ECS上跑通在本地VMware虚拟机里因SELinux策略拦截采集目标在MacBook M1芯片上又因ARM64架构导致Alertmanager告警模块崩溃——最后发现是Go编译时未指定GOOSlinux GOARCHamd64交叉编译参数。所以本文不提供“一键脚本”而是拆解每个环节的校验锚点当你执行完某步操作必须验证哪几个具体指标才能确认成功否则后续步骤全是空中楼阁。这组工具链解决的核心问题非常朴素让机器自己说清楚“我在干什么”“我干得怎么样”“哪里快不行了”。Prometheus负责“听”拉取指标Grafana负责“画”可视化中间缺了任何一环就像给聋子配助听器——硬件在但信息流断了。适合两类人深度阅读一是刚脱离top和htop手动查负载的初级运维需要建立系统化监控思维二是写业务代码却总被问“接口为啥慢”的开发者得知道怎么把自己的应用暴露给这套体系。接下来所有内容都围绕“如何让两个服务真正对话”展开每一步都附带可验证的检查命令和失败时的定位路径。2. Prometheus部署从二进制包到生产级配置的七层校验很多教程把Prometheus安装简化为“下载、解压、运行”这就像教人开车只说“踩油门”。实际上一个能稳定采集指标的Prometheus实例必须通过七层校验。我们以Linux x86_64环境为例逐步拆解。2.1 下载与基础启动绕过镜像陷阱的第一道关别急着拉Docker镜像。先确认你的目标环境是否允许容器化部署——有些金融客户生产环境禁用Docker有些嵌入式设备内存不足512MB根本跑不动容器。此时二进制包是唯一选择。访问 Prometheus官网下载页 找到最新稳定版的prometheus-*.linux-amd64.tar.gz。注意不要下载.tar.gz.sha256校验文件那是给自动化脚本用的人工部署直接跳过。解压后进入目录你会看到prometheus主程序、promtool配置校验工具、prometheus.yml默认配置三个关键文件。提示prometheus.yml里默认scrape_configs只配置了localhost:9090自身指标这是故意设计的“最小可行验证点”。先别改它直接运行./prometheus --config.fileprometheus.yml --web.listen-address:9090然后立刻执行curl -s http://localhost:9090/-/healthy | grep ok curl -s http://localhost:9090/metrics | head -n 5如果第一条返回ok第二条能看到# HELP promhttp_metric_handler_requests_total开头的指标文本说明Prometheus进程已正常监听且内置指标暴露成功。这是第一层校验——服务进程存活且HTTP端口就绪。2.2 配置文件语法校验用promtool堵住90%的启动失败很多人改完prometheus.yml就直接重启结果systemctl status prometheus显示failed日志里只有invalid configuration。其实Prometheus自带promtool做静态检查。执行./promtool check config prometheus.yml它会逐行扫描YAML语法、指标路径格式、重标签规则合法性。常见报错如unknown fields in scrape_config: metrics_path字段名拼错、duplicate target group重复定义job_name。特别注意static_configs里的targets必须是数组格式- job_name: node static_configs: - targets: [localhost:9100] # ✅ 正确targets是列表 # - targets: localhost:9100 # ❌ 错误字符串不能当列表用实操心得我见过最隐蔽的错误是YAML缩进用Tab键而非空格。promtool会报found character that cannot start any token但日志里不提示具体行号。解决方案用cat -A prometheus.yml查看隐藏字符把Tab替换成4个空格。这个细节在Mac上尤其容易踩坑因为TextEdit默认用Tab缩进。2.3 数据采集链路验证从target到TSDB的端到端追踪配置文件通过校验后启动服务并访问http://localhost:9090/targets。这里显示所有被监控目标的状态。关键看三列StateUP/DOWN、Labels标签是否正确注入、Last Scrape最近一次抓取时间戳。如果State是DOWN点击右侧“Details”看具体错误Get http://localhost:9100/metrics: dial tcp 127.0.0.1:9100: connect: connection refused→ 被监控服务没启动server returned HTTP status 404→ 指标端点路径不对比如该用/actuator/prometheus却写了/metricscontext deadline exceeded→ 网络超时可能是防火墙或DNS解析失败注意Prometheus默认抓取超时是10秒但某些Java应用暴露指标需30秒以上。这时要在scrape_configs里加scrape_timeout: 30s。我曾遇到Spring Boot应用因GC停顿导致指标暴露延迟不调这个参数就会持续DOWN状态。2.4 时间序列存储验证确认数据真正落盘即使target显示UP也不代表数据进了数据库。访问http://localhost:9090/graph输入查询语句count({jobprometheus})如果返回1说明Prometheus自身指标已存入TSDB。再试count({jobnode})若返回0证明Node Exporter数据没入库——可能原因scrape_interval设得太长比如5m而你只等了2分钟或metric_relabel_configs误删了关键标签。关键技巧用prometheus_tsdb_head_series指标查当前内存中未落盘的序列数。如果该值长期1000说明TSDB写入有瓶颈需调大--storage.tsdb.retention.time30d或检查磁盘IO。2.5 告警模块独立验证Alertmanager不是可选插件很多教程把Alertmanager当成附加功能其实它是Prometheus生态的“告警中枢”。单独部署Alertmanager下载alertmanager-*.linux-amd64.tar.gz修改其alertmanager.ymlroute: receiver: email receivers: - name: email email_configs: - to: adminexample.com smarthost: smtp.example.com:587启动后访问http://localhost:9093点击“Status”看集群状态。然后在Prometheus配置里加告警规则rule_files: - alerts.ymlalerts.yml内容groups: - name: example rules: - alert: HighCpuUsage expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{modeidle}[5m])) * 100) 80 for: 2m labels: severity: warning annotations: summary: High CPU usage on {{ $labels.instance }}验证要点在Prometheus Web UI的Alerts页签状态应为firing而非inactive在Alertmanager UI的Alerts页签应看到该告警条目最后检查邮件是否收到——这才是完整的告警链路闭环。2.6 权限与安全加固生产环境不可跳过的硬性要求默认配置下Prometheus监听0.0.0.0:9090这等于把监控面板暴露在公网。生产环境必须做三件事绑定内网IP启动参数加--web.listen-address10.0.1.100:9090启用Basic Auth用htpasswd生成密码文件再通过反向代理Nginx做认证关闭调试接口启动参数加--web.enable-admin-apifalse否则/api/v1/admin/tsdb/clean_tombstones可被恶意调用清空数据血泪教训某次我漏关admin API被扫描器探测到后执行了clean_tombstones导致3天前的历史数据全部丢失。恢复只能靠备份——所以务必在prometheus.yml里配置storage.tsdb.path: /data/prometheus并用rsync -a /data/prometheus/ /backup/prometheus/每日备份。2.7 systemd服务化让进程真正“活下来”裸跑./prometheus进程终端关闭就退出。必须做成systemd服务# /etc/systemd/system/prometheus.service [Unit] DescriptionPrometheus Wantsnetwork-online.target Afternetwork-online.target [Service] Typesimple Userprometheus Groupprometheus ExecStart/opt/prometheus/prometheus \ --config.file/opt/prometheus/prometheus.yml \ --storage.tsdb.path/var/lib/prometheus \ --web.listen-address0.0.0.0:9090 \ --web.external-urlhttp://monitor.example.com Restartalways RestartSec10 LimitNOFILE65536 [Install] WantedBymulti-user.target关键点LimitNOFILE必须设足够大默认1024不够否则高并发抓取时会报too many open files--web.external-url要填真实域名否则Grafana嵌入式图表链接会指向localhost:9090。3. Grafana部署从空白界面到可交互仪表盘的五步穿透Grafana常被误认为“只是个画图工具”但它实际承担着指标语义翻译器的角色——把Prometheus原始的node_cpu_seconds_total{modeuser,instancelocalhost:9100}变成人类可读的“CPU用户态使用率”。部署难点不在安装而在打通数据语义。3.1 安装方式选择为什么Docker不是万能解药Grafana官方提供DEB/RPM包、Docker镜像、Binary三种方式。看似Docker最简单但存在两个致命缺陷插件隔离某些企业级数据源插件如SAP HANA、Oracle JDBC需手动安装Docker容器重启后插件丢失配置持久化复杂-v /path/to/conf:/etc/grafana映射时若宿主机目录权限不对如root属主容器内grafana用户无法读取配置我推荐二进制安装Linuxwget https://dl.grafana.com/enterprise/release/grafana-enterprise-10.2.1.linux-amd64.tar.gz tar -zxvf grafana-enterprise-10.2.1.linux-amd64.tar.gz sudo cp -r grafana-10.2.1 /opt/grafana注意Enterprise版比OSS版多出LDAP集成、白名单数据源等企业功能但免费试用期30天。若只需基础功能用OSS版即可下载链接把enterprise换成oss。3.2 配置文件精调绕过Web UI的隐藏陷阱Grafana启动后默认访问http://localhost:3000初始账号admin/admin。但首次登录后必须立刻改密码否则会被暴力破解。更关键的是/etc/grafana/grafana.ini配置[server] domain monitor.example.com root_url %(protocol)s://%(domain)s/ serve_from_sub_path true [security] admin_user admin admin_password your_strong_password_here disable_login_form false [users] allow_sign_up false auto_assign_org true [auth.anonymous] enabled true org_name Main Org. org_role Viewer重点解释serve_from_sub_path true当Grafana部署在Nginx反向代理后如https://monitor.example.com/grafana必须开启此选项否则JS资源加载路径错误。我曾因此卡在登录页白屏排查3小时才发现是这个开关没开。3.3 数据源配置为什么“添加Prometheus”按钮会失效在Grafana Web UI的Configuration → Data Sources → Add data source里选Prometheus填URL时必须填Prometheus服务的真实网络地址不是localhost:9090。常见错误填http://localhost:9090→ Grafana容器内localhost指向自身而非宿主机填http://host.docker.internal:9090→ 仅Mac/Windows Docker Desktop支持Linux需改用宿主机IP正确做法在宿主机执行ip addr show eth0 | grep inet 获取IP填http://10.0.1.100:9090。填完点Save test若提示HTTP Error Bad Request说明Prometheus未开启CORS——需在Prometheus启动参数加--web.allow-origin*测试环境或指定域名生产环境。验证技巧在Grafana浏览器开发者工具Network标签页筛选XHR请求看/api/datasources/proxy/1/api/v1/query?querycount%28%7Bjob%3D%22prometheus%22%7D%29是否返回200和{status:success,data:{resultType:vector,result:[{metric:{},value:[1712345678,1]}]}}。这是数据源连通的黄金标准。3.4 仪表盘导入从JSON模板到可维护配置的转化Grafana社区有海量现成仪表盘如Node Exporter Full下载JSON文件后在Dashboards → Import上传。但直接导入存在三大风险变量冲突模板里用$instance变量你环境里叫$host面板尺寸错乱1920x1080设计的面板在1366x768屏幕显示不全数据源绑定错误模板默认绑定Prometheus数据源但你创建的是prometheus-prod正确流程导入时取消勾选Load dashboard with default settings在Options里手动选择正确的数据源点击Edit JSON搜索datasource字段把所有Prometheus替换为你的数据源名称检查targets数组里的expr确认PromQL语法兼容当前Prometheus版本如2.30才支持修饰符实操案例某次导入K8s仪表盘后所有Pod数量显示0。查JSON发现expr里用count(kube_pod_info)但集群用的是kube-state-metrics v2.0指标名已改为kube_pod_created。必须手动改成count(kube_pod_created)。3.5 用户权限体系避免“所有人都是Admin”的灾难默认所有用户都是Admin这违反最小权限原则。创建专用监控账号Configuration → Users → Add new user填邮箱monitorexample.comConfiguration → Teams → Add team建Monitoring-Readers组把用户加入该组再在Permissions里设Viewer角色对关键仪表盘如数据库性能设Dashboard permissions仅Admin可编辑关键提醒Grafana的Viewer角色不能创建告警但能查看已有告警。若需限制告警可见性必须用Folders功能——新建DB-Monitoring文件夹把数据库仪表盘移入再设置文件夹权限为Editor仅对DBA组开放。4. Prometheus与Grafana协同指标语义对齐的实战校准两者部署成功只是起点真正的挑战在于让Prometheus采集的原始数据在Grafana里变成业务人员能理解的图表。这需要三次关键对齐指标命名对齐、标签语义对齐、时间范围对齐。4.1 指标命名规范从node_cpu_seconds_total到“CPU使用率”的翻译Prometheus指标名遵循namespace_subsystem_name格式如node_cpu_seconds_total。但业务方要的是“CPU使用率(%)”这就需要PromQL计算100 - (avg by(instance) (irate(node_cpu_seconds_total{modeidle}[5m])) * 100)这个公式包含三个关键转换irate()计算每秒增长率消除累积计数器的干扰by(instance)按实例分组避免多节点数据聚合失真* 100将小数转百分比避坑指南千万别用rate()替代irate()rate(node_cpu_seconds_total[5m])会平滑掉短时峰值导致CPU飙到100%时图表只显示85%。我曾因此漏掉一次Redis内存泄漏事故——irate()在30秒内捕获到突增rate()则完全平滑掉了。4.2 标签语义注入让instance10.0.1.100:9100变成“订单服务-上海机房”Node Exporter默认用IP:Port作为instance标签这对运维有意义但对业务无感。需在Prometheus配置里重打标签- job_name: order-service static_configs: - targets: [10.0.1.101:9100] labels: app: order-service region: shanghai env: prod metric_relabel_configs: - source_labels: [__address__] target_label: instance replacement: 订单服务-上海机房这样在Grafana变量里$instance就显示“订单服务-上海机房”而非冷冰冰的IP。进阶技巧用label_values(instance, app)生成变量再在面板Query里写node_cpu_seconds_total{app~$app}实现按应用筛选——这才是真正的业务视角监控。4.3 时间范围对齐解决“Grafana图表空白”的终极排查法最常见现象Prometheus里curl http://localhost:9090/api/v1/query?querycount%28%7Bjob%3D%22node%22%7D%29time1712345678返回1但Grafana图表空白。根源在于时间戳对齐Prometheus API的time参数是Unix秒级时间戳Grafana默认用浏览器本地时区而Prometheus服务端用UTC若时区差8小时如东八区Grafana请求的时间范围可能落在Prometheus无数据的区间验证方法在Grafana面板右上角时间选择器点Relative time→Last 5 minutes再点Inspect → Query inspector看Request URL里的from和to参数。对比Prometheus服务端时间date -u %s # UTC时间戳 date %s # 本地时间戳若差值非0必须在Grafana设置里Configuration → Preferences → Default timezone设为UTC。4.4 告警规则联动让Grafana不只是“看”还能“管”Grafana本身不处理告警但能消费Alertmanager的告警事件。在Alerting → Contact points里配置- name: PagerDuty type: pagerduty uid: pd-123 settings: integrationKey: your-key-here然后在仪表盘面板里开启告警编辑面板 →Alert标签页 →Create alert rule写PromQLavg_over_time(node_load1[1h]) 5设Evaluate every: 1m,For: 5m在Notifications里选刚才创建的PagerDuty联系点关键区别Prometheus告警规则是全局的Grafana告警是面板级的。前者触发后发给Alertmanager统一调度后者直接走Grafana内置通知渠道。生产环境强烈推荐用Prometheus规则因为可复用、可版本控制。4.5 性能调优当Grafana卡顿不是因为网速仪表盘加载慢第一反应是网络问题但80%源于查询优化避免count()全量扫描count({jobnode})会遍历所有时间序列改用count by(job) ({jobnode})限制返回点数在Query里加limit 1000防止单次返回百万点拖垮前端用Recording Rules预计算在Prometheus里建规则job:node_cpu_usage:avg1m 100 - avg by(job) (irate(node_cpu_seconds_total{modeidle}[1m])) * 100Grafana直接查job:node_cpu_usage:avg1m实测数据某集群有500个Node Exporter目标未优化前count({jobnode})查询耗时12秒加by(job)后降至0.3秒再加Recording Rules后稳定在0.05秒。5. 故障排查全景图从“页面打不开”到“告警不触发”的链路诊断部署完成后问题往往出现在意想不到的环节。下面按故障现象倒推给出完整排查链路。5.1 现象Grafana登录页空白或404排查路径curl -I http://localhost:3000→ 看HTTP状态码302检查grafana.ini里root_url是否配错404确认/opt/grafana/public目录存在且权限为grafana:grafana浏览器F12看Console报错Failed to load resource: net::ERR_CONNECTION_REFUSED→ Grafana进程未启动systemctl status grafana-serverUncaught ReferenceError: require is not defined→serve_from_sub_path true未开启且用了反向代理5.2 现象Prometheus Targets显示DOWN但curl能通排查路径curl -v http://localhost:9100/metrics→ 看HTTP头Content-Type: text/plain; version0.0.4→ 正确Content-Type: application/json→ Node Exporter配置错误需加--web.telemetry-path/metricstelnet localhost 9100→ 看端口是否监听Connection refused→ Node Exporter未启动或端口被占Connected→ 检查Prometheus配置里的scrape_timeout5.3 现象Grafana图表有数据但告警不触发排查路径在PrometheusAlerts页签看规则状态Inactive检查for持续时间是否超过当前数据存在时间Pending规则已匹配但未达for阈值curl http://localhost:9090/api/v1/alerts看state字段查Alertmanagerhttp://localhost:9093/#/alerts看是否有该告警无记录Prometheus未推送检查alerting.alertmanagers配置有记录但状态unprocessedAlertmanager配置错误systemctl status alertmanager5.4 现象Grafana变量下拉为空排查路径在变量设置里Query填label_values(instance)→ 看Preview on load是否返回空执行curl http://localhost:9090/api/v1/label/instance/values→ 看API是否返回值空Prometheus无instance标签的数据检查scrape_configs是否漏配relabel_configs有值但Grafana不显示变量Refresh设为On Dashboard Load但仪表盘未保存先点Save按钮5.5 现象历史数据突然消失排查路径ls -la /var/lib/prometheus/chunks_head/→ 看文件时间戳全是今天TSDB写入正常最老文件是3天前storage.tsdb.retention.time已到上限需扩容或调大保留时间du -sh /var/lib/prometheus/→ 看磁盘占用90%清理旧块prometheus_tsdb_head_chunks指标值过高时执行curl -X POST http://localhost:9090/api/v1/admin/tsdb/clean_tombstones终极技巧所有排查命令汇总成一个脚本check-monitor.sh每次部署后一键运行#!/bin/bash echo Prometheus Health curl -s http://localhost:9090/-/healthy echo -e \n Grafana Health curl -s http://localhost:3000/api/health echo -e \n Alertmanager Status curl -s http://localhost:9093/api/v2/status | jq .uptime我在实际项目中把这套排查逻辑固化成Checklist贴在监控大屏旁。新同事入职第一天不是教他怎么画图而是让他独立完成这份Checklist——能走通全流程的人才算真正掌握了这套体系。