前言
我做运维监控时最怕一种状态：界面装好了、服务也启动了，看起来像是"已经能用了"，可数据库没真正连上、Agent 没有正常上报，或者页面里的监控项只是空壳。监控系统一旦进入长期运行，真正重要的不是功能列表有多长，而是服务端、数据库、Agent、告警入口和远程访问这几层能不能一层层对上。尤其碰到"命令行能登录 MySQL，Java 服务却一直报连接失败"这种问题时，如果只反复改密码，往往越改越乱。我也不太喜欢那种只看首页有图表就宣布部署完成的做法，真正出故障以后，最有用的还是知道数据从哪来、哪一段负责上报、哪一段负责展示，以及问题该从哪一层开始查。
这次我按现有环境部署 WGCLOUD v3.6.6，用 MySQL 初始化 wgcloud 数据库，启动 server 时实际遇到了 localhost / 127.0.0.1 对应账号权限不同导致的连接问题；解决后再加入本机和其他主机 Agent，继续查看端口、日志、Docker、数据库和拓扑等监控入口。最后安装 cpolar，把 WGCLOUD 的 9999 Web 页面提供到公网，先验证随机地址，再配置固定二级子域名 wgcloud。我更关心的是"哪里真的跑通了、哪里只是功能入口"，而不是因为它是国产开源项目，就把所有能力都提前写成已经验证完成。
1. WGCLOUD 适合放在什么位置？
WGCLOUD 是一套面向 IT 基础设施的监控平台。
它的功能列表里包括：
- 主机 CPU、内存、磁盘、网络、负载、进程、温度等指标；
- HTTP、Ping、端口存活；
- MySQL、PostgreSQL、Oracle、Redis、MongoDB 等服务；
- Nginx、Tomcat、Docker，以及部分 Kubernetes 场景；
- Shell 脚本、API 等自定义监控项；
- 邮件、钉钉、企业微信、飞书、Webhook 等告警方式。
同时还提到统信 UOS、麒麟等系统，以及鲲鹏、飞腾、龙芯等架构适配。
但这次真正动手验证的环境更具体：
Linux 服务端 + MySQL + WGCLOUD Server + Agent + Web 页面 + cpolar 公网访问。
我会把"平台支持哪些能力"和"这次到底跑过哪些链路"分开看，避免看到菜单就直接当成已经逐项验证。
2. 部署前先把环境和端口看清
这套部署里，服务端依赖 Java，要求中写的是：
- JDK 1.8；
- JDK 11。
数据库可以使用 H2，也可以连接 MySQL、MariaDB、PostgreSQL、Oracle。
被监控端方面，Linux Agent 需要 Java 1.8+，Windows Agent 按这里的说明直接运行 .exe 版本。
先安装基础工具：
shell
yum install -y vim wget检查 Java：
shell
java -version # 验证是否已安装这里有一处后面部署时需要特别留意的端口差异。
前面的端口表写的是：
- WGCLOUD Web：
8080 - Agent 注册通信：
9999
但 server 真正启动以后，后面的访问地址使用的是：
http://你的服务器IP:9999
所以实际部署时，我不会只靠前面的端口表判断，而会同时看配置文件、启动日志和实际监听端口。
3. 下载并解压 WGCLOUD v3.6.6
从官网获取安装包以后，上传到：
/usr/local
上传完成。
然后解压并进入目录：
shell
tar -zxvf wgcloud-v3.6.6.tar.gz
cd wgcloud-v3.6.6
查看目录结构。
后面的数据库脚本、server 和 agent 都围绕这个安装目录继续操作。
4. 给 WGCLOUD 准备 MySQL 数据库
先登录 MySQL：
shell
mysql -uroot -p【密码】创建数据库：
shell
create database wgcloud;切换到：
wgcloud
shell
use wgcloud;这里使用 MySQL，所以导入对应初始化脚本：
shell
source /usr/local/wgcloud-v3.6.6/sql/wgcloud-MySQL.sql
导入完成以后检查表：
shell
SHOW TABLES;
能够看到表以后，数据库初始化这一层才算完成。
5. 修改 server 配置文件
进入 WGCLOUD 的 server 目录：
shell
cd server/
ll再进入配置目录：
shell
cd config/
ll
修改：
application.yml
这里主要根据当前 MySQL 环境填写连接信息和密码。
继续往下还能看到 WGCLOUD Web 登录所用的账号密码配置。
配置完成以后，回到 server 目录启动：
shell
cd /usr/local/wgcloud-v3.6.6/server/
./start.sh
如果一次就起来当然最好，但我这次真正花时间的地方恰恰就在数据库连接。
6. MySQL 明明能登录，为什么 WGCLOUD 还是连不上？
我遇到的现象很典型：
命令行 mysql -u root -p 可以登录，但 WGCLOUD 启动后一直提示数据库连接失败。
一开始很容易怀疑是密码错了。
但真正需要看的，是 MySQL 用户和连接来源。
在这个环境里：
localhost登录会走 Unix Socket；- Java 应用通过 JDBC 走 TCP/IP；
- TCP 连接实际对应
127.0.0.1。
如果 MySQL 只有：
root@localhost
而没有：
root@127.0.0.1
就会出现"命令行登录成功，Java 服务连接失败"的情况。
这里采用的处理方式是：
shell
//创建 root@127.0.0.1 用户（密码和你现有的一致）
CREATE USER 'root'@'127.0.0.1' IDENTIFIED BY 'Sjixin520!';
//授予对 wgcloud 库的所有权限
GRANT ALL PRIVILEGES ON wgcloud.* TO 'root'@'127.0.0.1';
//刷新权限
FLUSH PRIVILEGES;
这段 SQL 里直接出现了明文密码：
Sjixin520!
命令按当前步骤保留，但长期环境里我不会把这类数据库凭据到处复制。
如果还想看得更直接，可以前台启动 server 看日志：
shell
java -jar wgcloud-server-release.jar
相比只看 start.sh 是否返回，前台日志更容易判断到底卡在数据库、端口还是其他初始化环节。
7. server 启动以后先确认 Web 页面
启动成功后，访问地址写成：
http://你的服务器IP:9999
默认登录账号密码为：
- 用户名：
admin - 密码：
111111
登录后进入首页。
到这里我只会确认：
WGCLOUD Server + MySQL + Web 页面
已经能正常工作。
这还不等于被监控主机已经开始上报数据。
8. 先把本机 Agent 跑起来
接下来进入 Agent 部分。
这里的目录文字出现了：
wgcloud-v3.5.7
但前面的安装版本一直是：
wgcloud-v3.6.6
两个版本号并不一致。
真正操作时应该以自己机器上的实际安装目录为准，不要因为这一处目录文字直接切到另一个版本。
启动 Agent 后刷新 WGCLOUD 页面。
新的监控主机已经显示。
这一层才真正形成：
Agent → Server → WGCLOUD 页面。
9. 再把 Agent 部署到其他主机
如果要增加其他服务器，可以把 server 同级目录下的 agent 打包，再复制到目标机器。
完整命令如下：
shell
#打包 agent 目录为 .tar 文件
tar -cvf agent.tar agent/
#远程上传到目标服务器root目录下面
scp agent.tar root@目标主机IP:/root
#解压上传的 .tar 文件
tar -xvf agent.tar
#cd 进入agent 目录
cd agent/
#进入config/ 目录
cd config/
#编辑application.properties 文件 把localhost 换成server主机IP
vim application.properties
#启动agent 服务
sh start.sh 
上传并解压。
修改：
application.properties
把：
localhost
替换成 server 主机 IP，再启动 Agent。
回到 WGCLOUD 页面刷新。
新的远程主机已经出现在监控列表里。
这一步对我来说比"支持多主机"四个字更有价值，因为它真正展示了第二台机器如何接入。
10. 页面里能继续配置哪些监控项？
进入 WGCLOUD 后，可以先看到主机基础监控。
10.1 端口监控
新增端口监控。
10.2 日志监控
添加日志监控信息。
10.3 Docker 监控
页面也提供 Docker 监控入口。
10.4 数据库与数据表
添加数据库之前，先测试连接是否正常。
后面还可以继续添加数据表。
页面里还有更多监控参数。
以及主机拓扑图。
这里我会把"页面提供配置入口"和"已经逐项验证"分开。
这次明确操作到的是主机 Agent 接入、端口、日志、Docker、数据库和数据表等配置页面；至于所有监控类型和告警通道是否都已经在这个环境完整跑通，这里没有继续逐项测试。
11. 为什么还要给 WGCLOUD 加公网入口？
局域网里打开 WGCLOUD 已经够做日常管理。
但如果监控服务放在公司、家庭服务器或没有公网 IP 的内网环境，而人又经常不在现场，Web 管理页面就会遇到跨网络访问问题。
这里再加入 cpolar。
需要先把职责说清楚：
这次 cpolar 只把 WGCLOUD 的 Web 管理页面
9999提供到公网。
它不采集 CPU、内存、日志或数据库指标，也不替 Agent 做数据上报。
功能介绍里还提到可以映射 Agent 通信端口，但这次真正创建的隧道是：
HTTP → 本地 9999。
所以后面的验证只围绕 Web 页面展开。
12. 安装 cpolar
执行：
shell
sudo curl https://get.cpolar.sh | sh
安装完成以后检查服务状态：
shell
sudo systemctl status cpolar
服务正常后，通过主机 IP + 9200 打开 cpolar Web 管理页面。
后面的公网访问都在这个界面完成。
13. 给 WGCLOUD 的 9999 创建随机公网地址
进入：
隧道管理 → 创建隧道
参数为：
- 隧道名称：
wgcloud - 协议：
http - 本地地址：
9999 - 域名类型：随机域名
- 地区：
China Top
创建成功以后进入在线隧道列表。
从其他电脑或移动设备打开公网地址。
页面可以正常访问。
这一层真正验证的是：
WGCLOUD Web 9999 → cpolar HTTP 公网地址 → 外部浏览器。
14. 长期远程查看，再配置固定二级子域名
随机地址适合先确认链路。
如果 WGCLOUD 准备长期作为监控入口使用，我更希望地址保持固定。
进入预留页面。
选择保留二级子域名。
这里使用：
- 地区：
china Top - 二级子域名：
wgcloud
接着回到 cpolar Web UI，找到需要修改的隧道。
把域名类型改成：
二级子域名
并填写：
Sub Domain：前面保留成功的名称- 地区：
China Top
更新以后到在线隧道列表查看。
最后使用固定公网地址访问。
页面可以正常打开。
到这里解决的是：
WGCLOUD Web 管理入口长期固定。
它不会改变 Agent、数据库和监控项本身的工作逻辑。
15. 我会怎么判断这套监控是不是已经跑通？
我不会只看"后台页面能登录"。
至少会按四层来确认：
第一层：MySQL → WGCLOUD Server
数据库初始化是否完成，JDBC 用户是否真的能通过 TCP 登录。
第二层：Server → Web 页面
服务是否真正启动，实际监听端口和当前配置是否对应。
第三层：Agent → Server
本机和其他主机 Agent 是否都能上报，并在页面出现。
第四层：cpolar → WGCLOUD Web
公网地址是否能打开 9999 管理页面，固定二级子域名是否切换成功。
这样哪一层出问题，就先查哪一层。
比起"国产监控平台功能很多"，我更在意的是这些基础链路是不是可验证、可排错。
总结
这次 WGCLOUD 部署里，真正让我印象最深的不是首页能展示多少图，而是数据库连接失败那一段。
命令行 MySQL 能登录，并不能直接证明 Java 服务就一定能连上；root@localhost 和 root@127.0.0.1 的差异，才是这次真正影响启动结果的关键。
整条实际流程是：
Linux → WGCLOUD v3.6.6 → MySQL wgcloud → 初始化 SQL → application.yml → JDBC / TCP 权限排错 → WGCLOUD Server → 9999 Web 页面 → 本机 Agent → 其他主机 Agent → 端口 / 日志 / Docker / 数据库监控入口 → cpolar → 随机公网 → 固定二级子域名 wgcloud。
还有几个细节需要继续留意：
- 前置端口表写 WGCLOUD Web 为
8080、Agent 通信为9999，但后面的实际 Web 访问使用9999，真正部署时应以当前配置和监听状态为准； - 安装部分使用
v3.6.6，添加监控主机说明里又出现wgcloud-v3.5.7，实际复制 Agent 时应以本机目录为准； - MySQL 修复命令里包含明文 root 密码，正式环境应单独管理凭据；
- 默认 Web 登录账号
admin / 111111属于这套步骤里的初始配置； - 页面展示了很多监控能力，但这次并没有把所有告警通道、数据库类型和国产环境逐项验证；
- cpolar 当前只验证了 WGCLOUD
9999Web 页面的公网访问，不参与 Agent 指标采集。
我更愿意把 WGCLOUD 看成一套需要认真把 Server、数据库和 Agent 对齐的监控系统，而不是"装上就什么都自动好了"的工具。真正稳定以后，它的价值才是少翻几次日志、少猜几次服务器到底哪里不对。