Docker部署Prometheus+Grafana+node-exporter监控三件套实战指南

1. 监控三件套的选型逻辑为什么这一套至今仍是标配先聊个真实经历。早些年我负责一台小规模业务服务器CPU、内存、磁盘全靠登录服务器敲命令去看。一开始机器少还能忍等到服务器数量超过三台这种“打地鼠”式巡检就彻底失效了——要么忘记看某台机器要么看完没记录出问题时根本说不清是哪一个时刻开始异常的。后来接触到Prometheus Grafana node-exporter这套组合用Docker一编排半小时就能跑起来一套完整的监控系统。数据采集、时序存储、可视化展示、告警通知全链路打通。最直观的感受是以前凌晨收到告警只能爬起来挨个看服务器现在直接在Grafana面板上扫一眼就能定位是哪台机器、哪个指标、从什么时候开始出问题。这一套方案能成为主流核心在于三个组件各司其职边界非常清晰node-exporter部署在被监控的宿主机上负责采集操作系统层面的指标包括CPU使用率、内存占用、磁盘读写、网络流量、文件系统状态、负载均衡等。它本身是一个HTTP服务默认监听在9100端口把指标以文本格式暴露出来。Prometheus承担“拉取”和“存储”两个职责。它按照配置的间隔时间默认15秒主动去各个exporter拉取指标数据落在自带的内存磁盘时序数据库里同时提供PromQL查询语言方便对历史数据做聚合、计算和对比。Grafana负责把Prometheus里的数据变成图表。它本身不存监控数据而是作为数据源的接入层。配置好Prometheus数据源之后就能通过图表面板、仪表盘文件快速搭建可视化界面还内置告警规则配置和通知渠道。对刚接触监控体系的人来说这套组合还有一个很友好的特点所有核心组件都有打包好的官方Docker镜像依赖关系简单不需要为每个组件单独编译安装。只要宿主机装好Docker三个容器一起跑起来监控系统的基本骨架就搭好了。选Docker部署而不是直接在宿主机上安装二进制我的理由是第一环境隔离Prometheus的配置文件、数据目录、Grafana的插件和数据库都可以通过数据卷映射到宿主机重装系统或迁移机器时只要把配置和卷目录一起搬走就行第二版本管理和回滚方便镜像Tag固定之后出问题可以快速切回上一个可用版本第三多人协作时一套docker-compose.yml就是环境标准不需要每个人手动装一遍依赖。当然Docker部署也有它自己的坑。比如Windows上Docker Desktop启动失败、Linux下权限报错、容器网络不通、镜像拉取超时等这些我在后面会一一展开。在动手之前建议先确认宿主机已经具备以下基础条件Docker Engine或Docker Desktop已安装并能正常运行Docker版本建议20.10以上宿主机可以访问外部网络至少能拉取镜像预留足够的磁盘空间Prometheus的时序数据会持续增长建议至少准备10GB以上磁盘空间端口没有被占用Prometheus默认9090Grafana默认3000node-exporter默认9100。2. 目录规划与docker-compose.yml的逐行拆解第一次部署这套监控栈时我把所有配置文件和命令直接丢在根目录结果三天后自己都找不到当初的启动脚本在哪更别提扩展新exporter了。所以我现在强烈建议在一开始就建立一个结构清晰的项目目录后续维护和扩展都会轻松很多。我的习惯是在宿主机上创建/opt/monitor作为监控栈的根目录目录结构如下/opt/monitor ├── docker-compose.yml ├── prometheus │ ├── prometheus.yml │ └── data/ └── grafana └── data/prometheus/prometheus.yml是Prometheus的配置文件后面单独展开prometheus/data用来存放Prometheus的时序数据挂载给容器持久化grafana/data用来存放Grafana的配置、数据库、插件和缓存同样做持久化。这样规划的好处是整个监控系统的所有状态都在/opt/monitor下面备份、迁移时直接打包这个目录即可不需要去容器内部想办法拷贝数据。在写docker-compose.yml之前先回答一个很多人会问的问题为什么用Docker Compose而不是直接docker run三个容器因为这套监控系统有三个服务它们之间需要网络互通。直接docker run当然可以跑起来但每次启动和停止都要维护三条长命令而且容器重启后IP地址可能变化Prometheus配置里的exporter地址就得跟着改。docker-compose.yml把服务编排、网络、数据卷、依赖关系集中到一个文件里一条docker-compose up -d全部搞定容器之间通过服务名互相访问IP变了也不影响。下面是我使用的docker-compose.yml文件已经加上注释YAML中注释不要直接粘贴进生产环境仅作说明version: 3.8 services: prometheus: image: prom/prometheus:v2.53.0 container_name: prometheus restart: unless-stopped volumes: - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml - ./prometheus/data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --storage.tsdb.retention.time30d ports: - 9090:9090 networks: - monitor-net grafana: image: grafana/grafana:11.1.0 container_name: grafana restart: unless-stopped environment: - GF_SECURITY_ADMIN_USERadmin - GF_SECURITY_ADMIN_PASSWORDadmin123 - GF_INSTALL_PLUGINSgrafana-clock-panel,grafana-simple-json-datasource volumes: - ./grafana/data:/var/lib/grafana ports: - 3000:3000 networks: - monitor-net depends_on: - prometheus node-exporter: image: prom/node-exporter:v1.8.2 container_name: node-exporter restart: unless-stopped pid: host volumes: - /proc:/host/proc:ro - /sys:/host/sys:ro - /:/rootfs:ro command: - --path.procfs/host/proc - --path.sysfs/host/sys - --path.rootfs/rootfs ports: - 9100:9100 networks: - monitor-net networks: monitor-net: driver: bridge有些细节需要展开解释关于Prometheus的存储配置。--storage.tsdb.retention.time30d表示数据保留30天这个参数可以根据磁盘容量调整。比如磁盘只有20GB监控目标又比较多建议保留7天就够了。时序数据占用的空间往往超出预期后面我会专门讲到这一点。没有设置存储上限的话Prometheus只会按照保留时间清理旧数据不会自动压缩所以在磁盘有限的环境里一定要主动规划。关于Grafana的环境变量配置。GF_SECURITY_ADMIN_USER和GF_SECURITY_ADMIN_PASSWORD用于指定初始管理员账号密码第一次打开Grafana登录界面时直接用这对账号登录不需要走初始化流程。注意这个写法只适合内网环境。如果Grafana要暴露到公网请务必使用环境变量注入或密钥管理工具不要直接把密码硬编码写在docker-compose.yml里。GF_INSTALL_PLUGINS是可选字段用于安装官方插件不需要的可以删掉。关于node-exporter的宿主机指标采集。node-exporter必须拿到宿主机真实的/proc、/sys和根目录数据才能反映宿主机状态。这就是为什么我把容器的PID命名空间设置为host并把宿主机的这三个目录只读挂载进容器。--path.procfs、--path.sysfs、--path.rootfs三个参数分别指定这些目录在容器内的挂载路径。第一次部署时最容易犯的错误是只映射端口、不映射目录结果Grafana上能看到数据源但所有指标都是容器本身而非宿主机的。3. 启动、联调与采集链路验证从容器状态到target全UP配置文件准备好之后在/opt/monitor目录下执行docker-compose up -d第一次执行会自动拉取镜像拉取时间取决于网络状况。如果长时间卡在拉取阶段大概率是镜像源的问题下面第五节会讲加速方案。启动完成后先检查容器状态docker-compose ps正常情况下三个容器的状态都应该是Up。如果某个容器异常退出用docker-compose logs 服务名查看日志排查方向一般是端口冲突、挂载目录不存在、镜像标签不对。比如prometheus容器启动后立刻退出多半是prometheus.yml配置里存在格式错误日志里会给出具体行号。容器全部起来之后验证链路的第一步是确认node-exporter是否正常暴露指标。在宿主机上直接访问curl http://127.0.0.1:9100/metrics | head -20看到一堆以# HELP和# TYPE开头、后面跟着格式为指标名{标签名值} 值的内容说明node-exporter工作正常。这些内容就是Prometheus需要抓取的指标数据。第二步是确认Prometheus能够访问到node-exporter。在宿主机上访问Prometheus的UI界面http://127.0.0.1:9090点击顶部导航栏的StatusTargets新版本叫 Service Discovery查看node-exporter对应的target状态。如果是UP说明采集链路已经打通如果是DOWN说明Prometheus无法连接到node-exporter的地址。最常见的排查点有两个一是在docker-compose.yml里配置的服务名和prometheus.yml中的target地址是否一致二是容器之间的网络是否互相连通。可以用下面的命令进入Prometheus容器做探测docker exec -it prometheus sh # 在容器内执行 wget -q -O- http://node-exporter:9100/metrics | head -5如果容器内wget能拿到数据而target依然DOWN那就要检查宿主机防火墙是否拦截了Prometheus到node-exporter的访问。我先给出prometheus.yml的完整配置再逐段说明global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: node static_configs: - targets: - node-exporter:9100 labels: instance: my-monitor-hostscrape_interval是全局抓取间隔默认15秒。对于常规的系统指标监控来说15秒足够不需要把间隔压到1秒——高频采集会显著增加存储开销而系统指标的突变往往不是秒级发生的。evaluation_interval是告警规则评估间隔如果后面要加告警规则这个值需要注意。targets里的地址写的是node-exporter:9100这是Docker Compose内部的服务名和端口。因为Prometheus容器和node-exporter容器在同一个网络下这个域名会被自动解析为node-exporter容器的IP。这也是我推荐使用Compose的核心原因之一服务名天然就是动态的容器发现机制。labels里的instance: my-monitor-host是可选的用于给指标打标签。当以后接入多台服务器时这个标签就非常有用——你可以在Grafana里按instance区分不同机器的曲线。如果省略这个标签Prometheus会以节点IP:端口作为默认的instance标签。第三步是验证Prometheus本身能响应查询。访问http://127.0.0.1:9090/graph在查询框中输入up回车后应该能看到指标结果其中up{jobnode, instancemy-monitor-host}的值为1。up指标代表Prometheus最后一次抓取某个target是否成功1表示成功抓取0表示失败。如果能看到值为1说明这套采集链路已经完整跑通——从node-exporter暴露指标到Prometheus拉取并存储再到查询接口返回数据整个流程没有问题。很多教程到这里就结束了但我建议多做一个验证步骤用PromQL查一个真实语义的指标。比如100 - (avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100)这是最常用的CPU使用率查询语句计算的是最近5分钟的CPU平均使用率。如果返回一个0到100之间的数值说明采集到的不只是空指标而是完整的宿主机数据。同样地可以查询内存和磁盘node_memory_MemTotal_bytes - node_memory_MemAvailable_bytesnode_filesystem_avail_bytes{mountpoint/, fstype!~tmpfs|overlay}这些查询如果在Prometheus的Graph页面能看到正常的数值变化就意味着监控数据是真实有效的。4. Grafana侧的数据源接入、仪表盘导入与面板微调Prometheus那边能够查到数据只完成了“采集”和“存储”。要让数据变得直观易读需要把Grafana接入进来。这一节我按“数据源接入—仪表盘导入—面板微调—变量配置”的顺序走一遍每一步都解释清楚为什么这样做。4.1 添加Prometheus数据源浏览器打开http://127.0.0.1:3000用docker-compose.yml里设置的admin账号登录之后会看到Grafana的主界面。Grafana 11.x默认带了一个Home Dashboard是官方准备的一个示例面板跟我们的监控数据没关系可以忽略。接下来的路径是左侧菜单ConnectionsData sourcesAdd data source选择Prometheus。在设置页面最关键的是URL字段。这里填写的是http://prometheus:9090。注意不能填127.0.0.1:9090因为Grafana是运行在Docker容器内部的容器内的127.0.0.1指向的是Grafana容器自己而不是宿主机上的Prometheus。通过Compose网络Grafana可以使用服务名prometheus访问到Prometheus容器这和prometheus.yml里用node-exporter作为目标地址是同样的原理。填好URL之后点击底部的Save test如果页面提示 “Successfully queried the Prometheus API”说明数据源已经连通。这一步失败的话基本可以确定是网络或URL配置问题可以先在Grafana容器里执行wget http://prometheus:9090验证。4.2 导入现成的仪表盘模板Grafana的强大生态在于有大量现成的dashboard模板社区通常叫“grafana模板”。导入模板是快速搭建可视化界面最高效的方式不需要从零开始一个个添加Panel。在Grafana左侧菜单依次进入DashboardsImport在 “Find and import dashboards” 输入框中填写模板ID点击Load即可。node-exporter最经典的模板ID是1860作者是Grafana官方团队的成员模板名为 “Node Exporter Full”覆盖了CPU、内存、磁盘、网络、文件系统等几乎全部node-exporter指标。另一个值得推荐的是16098它在1860的基础上调整了部分图表的布局对中文阅读也更友好不过模板的指标名称兼容性需要自己验证一遍。导入时有一个步骤容易忽略选择Prometheus数据源。如果Grafana里已经添加了多个数据源模板导入页会把“数据源选择”放在一个下拉框里务必选到你刚才创建的Prometheus数据源否则导入后面板会显示 “No data”。4.3 面板微调从“能看”到“好用”模板导入之后大部分场景下图表直接就能显示。但“能看”和“好用”之间还有距离我根据自己的使用经验总结几个最值得调整的地方。第一个是修改时间范围和刷新频率。模板默认的时间范围通常是一个小时对于看历史趋势来说完全不够。可以在仪表盘右上角的时钟图标里把时间范围改成“Last 24 hours”刷新频率改成30秒或1分钟。这样打开页面就能看到过去一天的变化曲线对定位“昨天什么时候开始异常”非常有帮助。第二个是调整磁盘使用率的fstype过滤条件。导入1860模板后磁盘面板的查询语句通常会包含类似fstype!~tmpfs|overlay|squashfs的过滤条件。在Docker环境下磁盘面板会显示一堆overlay、shm之类的虚拟文件系统这些是容器镜像层产生的临时挂载点并不代表真实的磁盘使用情况。可以打开编辑面板在查询语句中增加过滤条件或者在grafana模板编辑的变量设置中直接调整变量过滤值只保留ext4|xfs等真实文件系统类型图表会干净很多。第三个是让CPU指标区分“用户态”和“系统态”。node-exporter提供的是node_cpu_seconds_total模板中通常用rate(node_cpu_seconds_total{jobnode}[5m])求所有模式的CPU占比。如果你需要区分用户态和系统态可以在查询语句中加入modeuser或modesystem用不同的颜色区分。不过对大多数看板需求来说一个总体的使用率曲线已经足够在CPU异常时可以再深入查看各个mode的占比。4.4 添加主机名变量让一个仪表盘复用多台机器当你的宿主机不止一台时Grafana面板如果能通过下拉框切换查看不同主机的数据会方便很多。1860模板本身内置了instance和job两个变量但在新版模板中变量名可能不是这个建议手动检查一遍。路径是打开仪表盘右上角的Dashboard settingsVariables。如果instance变量不存在点击Add variable变量类型选择Query查询语句填label_values(node_uname_info, instance)这里的node_uname_info是node-exporter暴露的一个指标其中带有instance这个标签包含所有上报的主机标识。查询变量会自动列出所有Prometheus抓到的instance值下拉框里选择不同机器整个面板的数据就跟着切换了。默认值是All这样打开仪表盘时可以看到全部机器的汇总数据。有一点需要注意如果多台机器用相似的标签比如docker-compose里给每台机器的target都配了不同的instance标签下拉框就会显示这些标签值。为了方便识别推荐在prometheus.yml中给每个target配置清晰可读的instance标签比如instance: web-server-01而不是默认的ip:9100形式。5. 部署后最常见的几个稳定性问题与排查路径这套监控栈跑起来不难真正考验人的是部署之后的各种稳定性问题。这一节我按真实踩坑的频率从高到低列出几个问题并给出完整的排查思路。5.1 镜像拉取缓慢或超时国内网络环境下直接拉取Docker Hub镜像经常会出现长时间卡住、超时或下载速度极慢的情况。这是最普遍的问题也是很多新手卡在第一步的原因。先判断问题出在哪一步执行docker-compose up -d时如果卡在拉取镜像阶段观察终端输出确认进度。如果显示速度只有几十KB/s甚至卡住不动基本就是网络节点问题。稳定解决方案是配置镜像加速器。Docker Engine的镜像源可以通过修改/etc/docker/daemon.json来指定Linux和macOS路径相同Windows Docker Desktop则从Settings Docker Engine里直接编辑JSON配置。下面是一个参考配置{ registry-mirrors: [ https://docker.m.daocloud.io, https://dockerproxy.com ] }修改完成之后需要重启Docker服务sudo systemctl restart docker重启后重新执行拉取操作。加速器的作用是让Docker从距离更近、网络更稳的镜像源拉取层数据对prom/prometheus、grafana/grafana这些常用镜像都有明显的加速效果。但镜像加速器不是万能的有时仍然会遇到某个镜像层无法下载。一个更稳妥的思路是使用固定版本的镜像Tag并提前在“镜像搜索和下载”阶段把需要的镜像手动拉取一遍。比如在部署之前先执行docker pull prom/prometheus:v2.53.0 docker pull grafana/grafana:11.1.0 docker pull prom/node-exporter:v1.8.2如果某一条命令失败了就单独处理。确认三个镜像都拉取成功之后再执行docker-compose up -d就不会被临时网络问题打断整个编排流程。另外强烈建议docker-compose.yml里所有镜像Tag都写上明确的版本号不要用latest。latest看着省事但镜像更新频繁两个环境之间可能因为latest指向的版本不同出现行为差异到时候排查起来非常痛苦。5.2 node-exporter容器权限和数据缺失如果你按照我前面的配置部署node-exporter的pid: host和/proc、/sys、/挂载都非常关键。任何一个遗漏都会导致Grafana面板上出现大量空数据。典型症状是target状态是UP但CPU使用率面板显示 “No data”磁盘面板显示空。我先说明一下原理node-exporter在容器里默认只能看到容器自己的/proc和/sys目录看不到宿主机的真实内核指标。把宿主机的这三个目录只读挂载进去之后node-exporter仍然需要知道去哪里找这些目录所以必须加上--path.procfs/host/proc、--path.sysfs/host/sys、--path.rootfs/rootfs三个启动参数。挂载目录和启动参数必须成对出现少一个都会导致指标数据不完整。验证方式是在宿主机上查询node-exporter暴露的指标里是否有宿主机相关数据curl http://127.0.0.1:9100/metrics | grep node_uname_info这个指标包含内核版本、主机名、操作系统信息如果返回了真实宿主机的主机名和内核版本说明挂载正确。如果你看到的是容器ID之类的内容说明挂载或参数配置有问题。5.3 Prometheus容器无法服务配置文件格式与数据权限Prometheus对配置文件格式非常严格一个缩进错误、一个多余逗号都会导致容器启动后立即退出。排查步骤先看容器日志。docker-compose logs prometheus如果日志中出现类似Error parsing config file: yaml: line 3: mapping values are not allowed in this context的信息说明是YAML格式问题。这时候不要靠眼睛盯配置用工具检查更快docker run --rm -v /opt/monitor/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus:v2.53.0 promtool check config /etc/prometheus/prometheus.ymlpromtool是Prometheus镜像自带的配置检查工具输出SUCCESS表示配置正常否则会精确指出错误行。特别提示在Windows环境下编辑prometheus.yml时文本编辑器可能会在行尾添加\r\nCRLF而Linux容器内解析YAML时对\r比较敏感可能引发未知错误。用VS Code或Notepad把这些文件的换行符改成LFLine Feed即可。这是Windows用户最容易遇到的隐藏雷区。另一个常见问题是Prometheus数据目录权限。在docker-compose.yml中我把./prometheus/data挂载到容器/prometheus。如果宿主机上的这个目录权限或者属主不对容器内的prometheus进程可能无法写入数据容器启动后报 “open /prometheus/queries.active: permission denied” 之类的错误。简单处理办法是给目录放开写权限chmod -R 777 ./prometheus/data虽然777不是最安全的生产做法但对于内网监控环境来说可靠性优先。如果追求更好实践可以找到镜像内prometheus用户对应的UID通常是65534然后把目录属主改成这个UID。5.4 端口占用和服务冲突当9000、9090、3000这类端口被其他进程占用时Docker启动的端口映射会失败。排查方式sudo lsof -i :9090 sudo lsof -i :9100 sudo lsof -i :3000如果发现占用要么停掉旧的服务要么修改docker-compose.yml里的宿主机端口映射。比如9090:9090改成19090:9090前一个数字是宿主机端口后一个是容器内端口。容器内部端口不要动因为Prometheus默认监听9090改了内部端口还要同步修改启动命令无端增加复杂度。这个和我在生产环境部署时遇到的一个问题类似Grafana默认的3000端口常常被其他Web应用占用把它改成3001:3000之后只需在浏览器访问http://宿主机IP:3001对Grafana本身没有任何影响。5.5 DOCKER服务本身启动失败排查热词里频繁出现“virtualization support not detected docker desktop failed to start”这主要是Windows和macOS用户遇到的Docker Desktop启动问题。如果Docker Desktop提示虚拟化支持未检测到通常是以下原因之一BIOS/UEFI中没有开启虚拟化功能需要进入主板设置打开Intel VT-x或AMD-VWindows下「Hyper-V」或「虚拟机平台」功能没有启用可在“控制面板 程序 启用或关闭Windows功能”中勾选Windows家庭版对Hyper-V的支持有限Docker Desktop新版要求使用WSL2需要在管理员PowerShell中执行wsl --install装好WSL2并升级到较新的内核。排查顺序是先看Docker Desktop日志再看Windows功能状态最后检查BIOS设置。这类问题一旦解决通常在重启后生效Docker Desktop能正常启动接下来再处理容器编排问题。5.6 时区问题容器默认使用UTC时区如果你直接看Prometheus的告警时间或Grafana的图表时间轴会发现时间比北京时间慢8个小时。Grafana展示层会在浏览器端做本地时间转换所以前端看到的时间通常是正常的但Prometheus处理告警、计算时间范围时用的是容器内时间这会给排查造成困扰。在docker-compose.yml中给Prometheus和Grafana都加上时区环境变量即可environment: - TZAsia/Shanghai修改后重新创建容器docker-compose up -d。容器内部的日志时间、告警时间就会和北京时间保持一致。5.7 磁盘空间持续增长Prometheus的时序数据增长速度超出很多新手的预期。一个只监控单台宿主机、指标几百个的采集任务每天数据量通常在几百MB到1GB之间具体取决于抓取频率和指标数量。如果不设置保留时间数据会一直增长直到塞满磁盘。前面已经在启动命令里配置了--storage.tsdb.retention.time30d这是第一个保障。第二个保障是给Prometheus配置存储大小上限- --storage.tsdb.retention.size10GB这样写到10GB后Prometheus会清理最旧的数据。实际容量和保留天数需要根据磁盘空间来权衡。我自己的习惯是保留15天查询趋势足够用磁盘占用也可控。如果是生产环境建议给Prometheus挂载独立的数据盘避免系统和监控数据互相争抢磁盘空间。6. 告警规则配置与多业务机器扩展的思路监控系统如果没有告警本质上只是个“事后回看”工具。真正发挥监控价值的时刻是“出问题前或出问题当下”收到通知。Grafana本身就集成了告警功能可以直接基于Prometheus里的指标设置告警规则不需要额外引入Alertmanager当然如果有复杂路由和静默需求Alertmanager是更专门的方案。在Grafana中配置告警的路径是左侧AlertingAlert rulesNew alert rule。基于已有的Prometheus指标配置一条规则比如“CPU使用率大于85%持续5分钟”条件中使用PromQL查询比如100 - (avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 85设置评估间隔比如每1分钟评估一次设置告警标签比如severitywarning、teamops配置通知渠道比如钉钉告警、邮件或Webhook。Grafana内置了钉钉、Telegram、Slack等通道的集成在AlertingContact points里添加对应渠道即可。第一版告警建议只配置几条关键规则宿主机持续高CPU、内存可用率低于阈值、磁盘使用率大于85%、node-exporter目标掉线up{jobnode} 0。不要一上来就配置一大堆告警告警过多会导致运维人员对告警信息产生麻木反而漏掉真正重要的异常。当监控架构稳定之后下一步通常是扩展监控对象。比如再接入另一台服务器只需要在prometheus.yml的scrape_configs中多增加一个targetscrape_configs: - job_name: node static_configs: - targets: - node-exporter:9100 labels: instance: monitor-host-01 - targets: - 192.168.1.101:9100 labels: instance: web-server-01 - job_name: mysql static_configs: - targets: - 192.168.1.101:9104 labels: instance: mysql-01第二台机器上需要单独安装并运行node-exporter容器或二进制确保9100端口对Prometheus可达。新target接入后在Prometheus的Targets页能看到新增的节点Grafana中的instance变量下拉框也会自动出现新机器无需额外修改仪表盘。如果监控的是Docker容器本身容器数量、CPU、内存、网络可以部署cadvisor作为额外的exporter。如果监控的是MySQL、Redis、Nginx这类中间件官方或社区都有对应的exporter比如mysqld_exporter、redis_exporter、nginx-exporter。它们的指标格式兼容Prometheus的抓取协议接入方式和node-exporter基本一样启动exporter开放监听端口在prometheus.yml里增加job和target不需要改动Grafana端的数据源。我对扩展的思路建议是先满足“宿主机资源”这块再逐个接入业务中间件。每接入一个新exporter先在Prometheus的Graph页面验证指标出现再去做可视化否则你会在Grafana面板里对着空数据找半天是配置问题还是指标名问题。7. 部署过程中若干容易被忽略的细节汇总最后把我在多次部署和维护这套监控栈中积累的几个零散细节整理出来这些细节很多文档里不会写都是实战中实际踩过的。第一修改配置文件后的生效方式。prometheus.yml发生变化时Prometheus支持热加载配置不需要重启容器。在宿主机上执行docker kill -s SIGHUP prometheus或者直接访问Prometheus的重载接口需要开放--web.enable-lifecycle。重载后在Targets页面刷新即可看到最新的抓取配置。Grafana的仪表盘修改是即时保存的不需要额外操作。不过docker-compose.yml本身的改动比如端口映射、环境变量需要docker-compose up -d重建容器才生效这一点容易混淆。第二docker-compose日志的查看方式。部署阶段容器启动异常或运行中报错最直接的排查手段是看日志# 查看单个服务日志并持续输出 docker-compose logs -f prometheus # 查看最近100行 docker-compose logs --tail100 grafanaGrafana初次启动时需要初始化数据库默认SQLite如果./grafana/data目录没有正确挂载或者权限不对日志中会有mkdir /var/lib/grafana: permission denied之类的报错。给grafana/data目录放开写权限和Prometheus data目录的处理办法一样。第三数据持久化的边界。很多人以为docker-compose配置了volumes就万事大吉实际上如果挂载的是宿主机目录确实能持久化但如果你无意中用了命名卷而不知道卷的物理位置在哪里迁移时就会很被动。我在教程里特意用的是相对路径挂载./prometheus/data一切数据都在项目目录内备份时打包/opt/monitor即可。这种简单的文件级备份恢复虽然不如专业备份工具优雅但对于中小规模的监控部署非常实用。第四浏览器访问地址的常见误区。在宿主机上可以访问http://127.0.0.1:9090来看Prometheus但如果监控部署在远程服务器上需要访问http://服务器公网IP:9090。遇到无法访问的情况先确认云服务商的安全组或防火墙是否放行了入方向端口。很多新手在本地执行curl http://127.0.0.1:9090正常但远程死活连不上原因往往是安全组没有放行9090端口。排查顺序宿主机ss -lntp确认监听端口再检查防火墙再检查云安全组。第五浏览器证书和登录安全的提醒。Grafana默认HTTP明文访问内网环境问题不大。如果监控部署在公网环境最简单的安全加固方式是前置NGINX配置HTTPS反向代理并把Grafana的GF_SERVER_ROOT_URL设置为对应的域名。这个不属于基础部署必需项但至少把Grafana和Prometheus的默认账号密码改成强密码别用部署配置里的初始密码。第六node-exporter容器自身的重启策略。docker-compose.yml里写了restart: unless-stopped意味着宿主机重启后容器会自动拉起。这个设置对监控系统尤为重要——如果挂了监控系统本身不自动恢复就失去了监控的意义。写到这里整套Docker部署Prometheus Grafana node-exporter的流程和踩坑经验就分享得差不多了。我个人在实际维护这套监控栈的时候有一个很深的体会部署本身不难难的是建立对监控数据的信任——看到面板上有数据不算什么真正理解每个指标的含义、知道指标缺失时怎么排查、明白告警触发时该去哪里定位这些才是把监控系统用起来的关键。建议你部署完成之后先跑一两天让系统采集一轮完整的“周末负载”和“工作日负载”数据再结合Grafana里的曲线去观察自己服务器的真实运行节奏。看得多了你对自己服务器的了解会比任何教程都深刻。