先交代一下背景。我这边常年管着几十台虚拟机换来换去最容易翻车的往往是监控系统本身——业务还没迁过去监控先失联了。之前WGCLOUD监控系统的server端一直是拿jar包直接在宿主机上跑的虽然也能用但每次换机器、升版本都得跟Java环境、端口占用、残留进程较劲。后来干脆把server端塞进Docker容器整个迁移和回滚流程瞬间清爽了很多。这篇就把我用Docker部署WGCLOUD监控系统server端的完整过程和踩坑经验整理出来给同样打算容器化部署的朋友做个参考。1. 为什么我不用jar包硬跑而是把WGCLOUD server装进容器WGCLOUD这类开源监控系统服务端和客户端的关系就像渔网和鱼agent客户端撒到各台被监控主机上负责采集CPU、内存、磁盘、进程这些实时数据然后定时上报给server服务端server端把数据落库、出图、触发告警最后通过Web界面呈现给你。这里说的server端就是监控系统的“大脑”agent只是它的眼睛和耳朵。1.1 WGCLOUD服务端的部署形态jar包和容器哪个更适合你WGCLOUD的server端本质上是一个Java应用正式发布一般会提供打包好的jar包或者可执行安装包。传统做法是直接在宿主机上装JDK、跑jar包好处是结构简单坏处也明显宿主机环境一旦被其他业务搞乱了最常见的就是JDK版本被覆盖监控系统第一个遭殃。用Docker部署server端的核心价值在于环境隔离和状态可迁移。镜像把JDK、依赖、配置文件全部固化到一个层里宿主机上有Oracle JDK还是OpenJDK、有没有其他Java进程抢占9099端口跟容器完全无关。我实测下来从一台机器把整个监控server迁到另一台只需要把容器和数据目录搬过去五分钟能搞定的程度。1.2 什么情况下我建议你还是用jar包说实话Docker部署也不是没有代价。如果你只需要在固定一台机器上部署一次、之后极少折腾那直接跑jar包反而更直接省去学习Docker的精力。但如果你的环境是虚拟化集群、经常要扩缩容、想借这个机会把监控server的部署也纳入到通用的容器管理流程里那Docker部署就非常值得。我在切换过程中发现容器化之后最大的收益不是部署快其实第一次反而比jar包慢因为要先搞定镜像和数据卷而是回滚变得极其简单。jar包部署回滚要重新传包、停服务、换包、再启动容器部署回滚就一条命令换回旧镜像数据完全不受影响。这是我最看重的点。2. 部署前的三张底牌镜像来源、存储目录和端口规划动手敲docker run之前有三件事必须想清楚否则后面大概率要返工镜像从哪来、数据往哪存、端口怎么规划。2.1 镜像获取官方维护版本优先别乱用个人镜像WGCLOUD官方发布页会提供容器镜像的获取方式一般在Docker Hub的官方仓库下就能搜到。我个人的习惯是只认官方仓库维护的镜像尽量不用第三方个人打包的版本。因为监控系统里跑着的是关键业务数据来路不明的镜像里万一塞了点私货你的服务器数据就全暴露了。另外镜像标签选择上我建议避开latest这种滚动标签。WGCLOUD升级频率不低latest可能这段时间指代v3.x下个月就变成v4.x了你没法控制哪天pull下来的到底是什么版本。最好是固定到具体的版本号标签比如官方发布说明里标注的v3.x-rev数字这种格式方便后面做版本管理和回滚。2.2 存储目录容器可以被删数据目录必须焊死WGCLOUD server端默认使用自带的H2数据库所有监控历史数据、用户配置、告警记录都存在server安装目录下的data文件夹里。很多第一次用Docker部署的朋友会忽略这一点跑起来一个容器发现一切正常等到某天不小心删了容器重启监控数据全部清零那才叫欲哭无泪。所以部署之前你先规划好宿主机上的持久化目录。我一般习惯创建这样一个结构/opt/wgcloud/ └── server/ └── data/ # 映射容器内的数据目录需要说明一下不同版本的镜像容器内数据目录的具体路径可能会略有差异有的版本叫/data有的可能挂在/app/server/data下这个以官方镜像的说明为准。部署前建议先拉一次镜像用docker inspect看一眼镜像声明的VOLUME路径确认好再挂载避免数据卷映射到了一个空目录。2.3 端口规划9999是主端口别和别的服务打架WGCLOUD server端默认监听9999端口这个端口同时承担着两件事一是给浏览器访问Web控制台用二是接收所有agent上报的数据。也就是说只要这个端口通了agent的灵魂和Web的肉体现在就都绑在上面。我负责的环境里有不少旧系统喜欢用9999这种端口有的应用默认就用它部署前一定要先确认ss -lntp | grep 9999如果端口被占你有两个选择一是在宿主机映射时换一个外部端口比如-p 9527:9999但这样所有agent上传数据地址也要改成9527改动面变大二是直接换一个空闲端口映射我更推荐前者外部端口换一下内部容器端口保持默认agent那边照样配9999这样agent配置不用动。端口规划可以用下面这个表来提前记录项目默认值我的规划值说明Web控制台端口99999999浏览器访问http://宿主机IP:9999agent上报端口99999999agent主动连接server的9999端口数据目录挂载/data(视版本)/opt/wgcloud/server/data持久化H2数据库文件容器时区默认UTCAsia/Shanghai不设置的话告警时间会差8小时上面这个表格看着简单但每一条我都吃过亏端口冲突是第一坑时区是第二坑数据卷是第三坑。接下来逐个说。3. 我的完整部署命令与参数拆解一次跑通的记录当镜像、存储目录、端口这三件事都定了部署命令本身反而没什么玄学。我把自己实际用过的启动命令贴出来逐条解释为什么这么写你可以直接抄作业但要把路径和版本标签换成你自己的。3.1 启动命令逐行解析我的部署环境是一台四核8G内存的虚拟机宿主机系统是Ubuntu 20.04 LTSDocker版本是20.10.x。完整命令如下docker run -d \ --name wgcloud-server \ --restartalways \ -p 9999:9999 \ -v /opt/wgcloud/server/data:/data \ -e TZAsia/Shanghai \ --memory2g \ wgcloud官方仓库镜像:v3.x一行一行说。--restartalways这个必须加。监控server本身就是基础设施组件宿主机重启之后容器必须自己拉起来。如果不加哪天机房断电重启你的监控系统就忘了自己回来而且没人发现因为连告警都发不出来了。-p 9999:9999刚才说过这个端口同时服务Web和agent。-v /opt/wgcloud/server/data:/data宿主机数据目录映射到容器内数据目录。这里要注意的是宿主机上的data目录如果有旧数据WGCLOUD启动时会做一次数据兼容检查。从旧版本镜像升级时官方会提供数据库升级说明操作前多看一眼别直接用新版本容器启动旧数据不然可能引发数据库结构不匹配。-e TZAsia/Shanghai时区环境变量。国内服务器务必加这个。如果不加容器内Java虚拟机的默认时区是UTC你会发现监控图表里的时间比实际慢8个小时告警时间的判断也会出偏差明明9点发的机器显示凌晨1点。容器内时区的影响是全局性的不只是显示层问题。--memory2g限制容器最大内存为2G。WGCLOUD server端整体属于轻量级应用官方建议server最低1G内存但监控的主机数量多起来比如上百台agent上报、历史数据保留周期长的时候内存占用会往上走。限制2G是个比较稳的中间值避免单个容器把宿主机内存吃干。还有一个小细节如果你需要为JVM单独设置Heap大小可以留意镜像是否支持通过环境变量传入Java参数。我一般不在这个层面折腾让JVM自己根据容器内存限制去自适应实测更省心除非监控规模特别大否则不需要手动调-Xmx。3.2 第一次启动后的验证清单容器跑起来之后别急着登录Web页面先按下面的顺序做一轮验证能帮你第一时间发现隐藏问题查看容器状态和日志docker ps | grep wgcloud-server docker logs --tail100 wgcloud-server日志里应当能看到server启动完成的标志信息比如监听的端口号、初始化完成的提示等。检查宿主机端口监听ss -lntp | grep 9999浏览器访问http://宿主机IP:9999这一步正常能看到WGCLOUD的登录页。默认账号是admin初始密码是111111新版本第一次登录会强制要求改密码。这是WGCLOUD官方默认凭据如果你跑完登录不进去多半是镜像来源有问题或者数据目录里残留了旧数据。登录后先看系统概览页是否自动出现了server本机的监控数据。WGCLOUD有个特性server端会把自己当作一台被监控主机自动内置了一个agent来上报自身状态。如果你在Web界面能看到server自身的CPU、内存曲线在跳动说明整个数据链路从采集到入库到展示是通的这也说明server端部署成功了。顺便说一句我见过有人在宿主机防火墙里忘了放行9999端口然后折腾了半天Web页面打不开。Ubuntu上如果是ufw管理防火墙记得执行ufw allow 9999/tcp如果是云主机安全组规则里也要放行。这个问题实在太过常见排查顺序一定是从底往上先网络通不通再容器活没活最后才看应用配置。4. 接入agent才是部署闭环从server端验证整个监控链路server端起来了只是上半场监控系统的真正价值在于agent能不能稳定上报数据。接入agent有两件事需要注意一是agent配置的server地址IP或域名和端口要保持可达二是agent和server的版本要尽量保持在同一代。版本不一致在我实际运维中踩过不少次钉子后面展开说。4.1 agent下载、配置和启动的标准化流程WGCLOUD的agent一般不用安装解压即用依赖有一个Java运行环境。在目标主机上执行# 下载对应版本的agent包传到目标主机后解压 tar -zxf wgcloud-agent-xxx.tar.gz cd wgcloud-agentagent的核心配置在conf目录下我记不清具体配置文件名了但关键是改两处一是server端的IP或域名二是上报端口。默认端口9999跟server端一致。有的版本里配置文件还分“私有IP”和“公网IP”两个参数如果agent和server在同一个内网段填内网IP就行跨网段或走公网的话就填对应的地址这个看你的网络情况来定。改完配置后启动agent常见的方式是执行start.sh脚本。启动后可以先看agent的本地日志确认它有没有尝试连接server端、连接是否成功。如果日志里出现连接超时或连接被拒绝先别急着怀疑server端口按这个顺序排查在agent主机上ping server IP确认网络层通。用telnet测9999端口通不通timeout 5 bash -c cat /dev/null /dev/tcp/server-ip/9999 echo port open如果是从外部网络过来检查安全组、防火墙。最后确认server端的容器日志里有没有对应agent的连接记录。4.2 server端如何确认agent已经接入agent启动后间隔一小段时间WGCLOUD默认采集周期一般是一分钟以内server端Web界面左侧的“主机管理”列表里就会陆续出现新主机。每台新主机会带上agent的IP、主机名、操作系统版本这些基本信息。此时点击主机名能看到CPU、内存、磁盘、网络等监控大项开始出图。我每次接入新agent后都会做一次告警测试这比看图靠谱得多。比如手动触发一个“CPU占用率超阈值”的测试告警看server端能否在预期时间窗口内弹出告警并成功推送通知。如果告警链路不通那agent就算接了上千台也是白接等你服务器真宕机了才发现告警没响那才叫惨。这里分享一个非常实用的经验把server和agent的时钟校正做好。如果被监控主机的时间跟server端时间偏差太大尤其是一些内网机器常年不校时WGCLOUD部分版本会因为时间戳异常导致图标乱跳甚至收不到数据。建议所有agent和server都配置NTP同步这算是我在生产环境紧盯的一条底裤。4.3 agent版本等于server版本这条红线别破关于agent与server的版本匹配我再多写几行。WGCLOUD官方往往要求agent和server版本保持一致或者至少大版本号相同。具体原因大概是两边的通信协议和数据上报格式跟着版本走新版server可能加了新的资源监控项旧版agent不认识自然就上报不了对应数据反过来新版agent上报的数据格式旧版server解析不了日志里会各种异常。我在一次小版本混杂的场景中就遇到过server升到v3.xagent还是v2.x时代留下的包结果Web界面上主机状态显示正常但磁盘IO那一堆数据死活不出来。折腾半天才发现是agent版本太老字段对不上。从那之后我就定了一个规矩升级server的同时所有agent必须一并升级到配套版本哪怕麻烦一点也要统一否则一个环境里agent版本五花八门后面的坑只会越来越多。5. 升级、备份与起不来的旧坑容器部署运维笔记写完第一版部署总结之后我又在实际运维中陆陆续续遇到了一些问题专门开这一章把升级流程、数据备份方法以及三种常见的启动失败场景记录下来算是给前面的内容打个补丁。5.1 数据备份停容器再拷目录别图省事WGCLOUD的监控数据都落在H2数据库文件里保证数据备份的最佳实践是先停止容器再拷贝数据目录。直接对运行中的容器的数据目录执行cp表面上看文件拷出来了但H2数据库可能在落盘的瞬间有未写完的事务备下来的可能就是一份损坏的数据。咖啡还没煮完就把杯子拿走了杯里缺一口一回事。我的操作顺序如下docker stop wgcloud-server cp -a /opt/wgcloud/server/data /opt/wgcloud/server/backup/data_$(date %Y%m%d_%H%M%S) docker start wgcloud-server注意容器重启后Web页面要等几十秒才能访问别误以为又出故障了。备份文件建议保留最近两到三个版本周期覆盖掉到服务器上另外一个目录去归档。5.2 升级容器版本的操作流程WGCLOUD升级和普通容器服务升级略有不同因为除了镜像本身的更新还涉及数据目录里数据库文件的版本迁移。我一般按下面几步操作备份按上面5.1的方法完整备份data目录。拉新镜像docker pull 新版本标签先不急着停止旧容器。停旧起新停掉旧容器用完全相同的数据卷挂载和端口映射启动新容器。观察日志启动后立刻docker logs -f wgcloud-server重点看有没有数据库结构升级相关的日志输出。WGCLOUD在检测到旧版本数据时通常会自动做兼容性调整这一步可能需要一点时间期间不要随意重启容器。Web界面验证登录后确认历史监控数据还在、告警规则还在、主机列表没有丢失。这里一定要提醒不要跳过备份直接升级。数据库升级是不可逆操作一旦升级脚本执行到一半失败或者不兼容你手里又没有备份那全部历史监控数据会直接葬送。我见过有人在测试环境升级翻车然后因为没备份只能重头再采一遍数据前几个月的趋势图全没了。5.3 容器起不来的三种典型故障从日志里找真相故障一容器启动后立刻退出先看docker logs输出常见的提示包括端口被占用、数据目录权限不对、内存不足被OOM杀掉。端口被占用分两种情况宿主机上另一个进程占了9999或者有其他容器映射了同一端口。用docker ps -a检查有没有同名或同端口容器就行。数据目录权限不对也发生过宿主机的data目录如果属主和容器内进程不一致容器可能启动报错或写入失败。最简单的处理是把data目录属主改成普通用户或者根据官方镜像里声明的用户UID设置一致如果是root的镜像改属主为当前用户基本就能解决。内存不足方面我遇到过宿主机内存本来就紧巴巴的容器启动时分配不到足够内存直接被杀。建议优先查看docker logs里有没有OOM相关的关键字然后适当降低--memory限制或者给宿主机腾点内存出来。故障二容器活着Web页面却打不开大概率是防火墙或安全组问题前面已经给过排查顺序。少数情况是容器内启动时间太长server还在初始化数据库稍微等一会儿再刷页面。不要一打不开就直接重启容器重启只会让初始化过程从头再来。故障三容器活着部分监控图表却没有数据这类问题最常见的原因是agent与server版本不一致或者agent的采集项在较新版本里调整了字段名。另一个常见原因是宿主机时间与agent时间偏差过大。优先从这两条线排查基本能覆盖掉我遇到的大多数“有主机无数据”问题。最后再从我个人使用习惯的角度多嘴一句。容器化部署WGCLOUD server最爽的地方在于我可以随时把监控栈从一个宿主机平移到另一个宿主机中间不用关心JDK、环境变量这些琐碎事。但容器化也意味着你必须对数据卷和版本管理更上心——容器的生命是短暂的数据才是长久的。每次操作前备份、确认版本、看日志这三件事做足了WGCLOUD server跑起来真的是个省心的监控大管家。