1 Introduction

In the real-time health monitoring and alarm of my cluster sites, I have always used the combination of uptime-kuma + bark server (for specific construction and configuration, see:Docker series builds a message push server based on bark serverandDocker series builds a real-time health monitoring and alarm system for applications based on uptime and bark).

However, to be honest, I mainly use the real-time alarm function of this combination, and rarely look at the real-time monitoring page of uptime-kuma. The reasons are as follows:
1. There is really no need to keep staring at the real-time monitoring page of uptime-kuma (unless you have dedicated operation and maintenance personnel like the real client)
2. The monitoring method of uptime-kuma is external detection, which has a single angle and you can't tell anything by just staring at it. For example: How much traffic does a certain device have? Is the resource consumption of a certain docker or a certain host abnormal? Which hosts have abnormal processes? How much CPU and memory does a process on a certain host occupy? Is there an error with a specified keyword in the log of a certain host? Has a key file on a certain host been tampered with? Does the content of a certain table in a certain database reach a certain threshold, etc.
3. The monitoring display page of uptime-server itself is also relatively monotonous and of low quality:

Based on the above reasons, I have always used the combination of uptime-kuma + bark server as a real-time alarm system, and I have never thought of its real-time monitoring function.

A few days ago, I suddenly had the urge to research (free) operation and maintenance monitoring systems. I didn't expect that I would find one that suits my taste: wgcloud. Although it has some flaws (the free version has an upper limit of 10 objects for each function), it generally meets my requirements: it can do what uptime-kuma mentioned above cannot do, and the display interface is much more tasteful. The final effect is as follows:

This article (Part 1) records the deployment process of wgcloud in detail, and the specific configuration is introduced in the next part.

2 Deploy wgcloud

2.1 Environmental Preparation

2.1.1 Installing the Java Environment

WGCLOUD server can run on JDK1.8, JDK11 or higher versions of JDK, and OpenJDK also supports
I use Debian 12, so I use the following steps:
1. Update software sources

apt update

2. Install the default OpenJDK 11

apt-get install default-jdk

3. Verify whether Java is installed successfully

java -version

For installation methods of other systems, please refer to the official instructions:https://www.wgstart.com/help/docs7.html.

Note: JDK needs to be deployed only on the server side, but not on the agent host.

2.1.2 Creating a Database (Optional)

wgcloud needs to use a database. Supported databases (data sources): MySQL (both MySQL 5.X and MySQL 8.X are acceptable), MariaDB, Oracle, PostgreSQL (version 10 or above is recommended). You can choose any of the above databases. Domestic databases such as openGauss and OceanBase are also supported. You can choose according to your usage habits. I use mariadb more often in other applications, so if it is available, I will directly choose mariadb (mysql is also acceptable, but mariadb is always preferred if there is a choice).

wgcloud needs to use the corresponding library in the existing database (mariadb in my case) and perform initial configuration. If there is no database yet, you need to create a new one.

---

The recommended process for creating a new mariadb database is as follows:
Create a directory on the host that needs to be mounted into the mariadb container

mkdir -p /docker/mariadb/db

Create mariadb container

docker run --name=mariadb01 -d --restart=always \ -p 3306:3306 \ #Map the host's port 3306 to the container's port 3306 -v /docker/mariadb/db:/var/lib/mysql \ #Mount the previously created host directory to the specified directory inside the container -e MARIADB_ROOT_PASSWORD=123 \ #Specify the password corresponding to the database root user, which you can modify by yourself mariadb:10.11

---

2.1.3 Create a new wgcloud library in mariadb

Please refer to my other article for details:Tips and tricks: Create a new empty database and grant permissions to corresponding usersIn the following text, it is assumed that the initialization database name, corresponding user name, and password are all "wgcloud".

2.2 Deploy wgcloud server and agent

2.2.1 Download the server and decompress it

The download link of wgcloud on GitHub is as follows:https://github.com/tianshiyeben/wgcloud/releasesWhen I installed it, the latest release was wgcloud-v3.5.1.tar.gz (I remember downloading the server version, which also included the agent). Also, the v3.x version is a free, non-open source commercial version, while the free, open source version I had at the time was v2.3.7.

After the download is complete, unzip the server to a specific directory. I will put it directly in the /root directory and then unzip it:

cd ~ tar -zxvf wgcloud-v3.5.1.tar.gz

The file structure of the unzipped directory wgcloud-v3.5.1.tar.gz is as follows:

---

There are the following points to note:
1. The server directory comes with an agent client. If it is a single-agent host, it is recommended to put it in the same path for easy upgrade.
2. After decompressing the server and agent deployment, you can start running by making some necessary modifications to the configuration files without compiling.
3. Only one server needs to be deployed, and all agents report indicator data to this server unilaterally.
4. Deploy as many agents as the number of hosts that need to be monitored (even if the server host needs to be monitored, the agent must be started)
5. Server and agent need to maintain the same version
6. The monitoring host information is automatically collected and reported by the agent, so the host cannot be added on the server host list page. After the agent is deployed and started, you can see the monitoring host on the [Host Management] page
7. wgcloud-daemon-release is a daemon process. Executing server/start.sh will start wgcloud-server-release.jar and wgcloud-daemon-release at the same time. Do not shut down the daemon process. The server needs to communicate with the daemon process.
8. The system time of the host where the server and agent are located must be consistent. Even if there is a difference, the time difference should not exceed 15 hours (the agent will print the anti-tampering verification failure information during this time difference, please ignore it, it will not affect the monitoring collection)
9. Be careful not to edit/modify server/wgcloud-server-release.jar, otherwise the agent log will show information that the anti-tampering verification failed, and the data will no longer be reported after a certain period.
10. If the agent cannot directly access the server, you can use the proxy wgcloud-proxy to transfer the data to the server
11. If you are deploying and running the server on Windows, try not to have spaces in the directory path where the server is located (such as C:\Program Files (x86)\wgcloud). Sometimes, lower versions of Windows may fail to start due to spaces in the path.
12. Server and agent can be used interchangeably as long as they are of the same version. That is, if the server runs on Linux, the agent can run on Linux or Windows, and vice versa.

---

2.2.2 Initialize the wgcloud library

/root/wgcloud-v3.5.1There are 3 sql files in the directory:

Because I use mariadb, the initialization file selection is:wgcloud-MySQL.sql

There are many ways to apply the wgcloud-MySQL.sql file. Take phpmyadmin as an example:

Initialization completed:

Of course, you can also import it in command line format, as follows:

mysql -u root -p -h 127.0.0.1 # The database IP address can be modified according to the actual situation. If it is not the default 3306, use the -P parameter followed by the port. use wgcloud; source /root/wgcloud-v3.5.1/wgcloud-MySQL.sql

2.2.3 Configure the application.yml file

The database of wgcloud server points to/root/wgcloud-v3.5.1/server/config/application.ymlThe following contents of the file determine:

My actual configuration is as follows:

Other important parameters in the "application.yml" file are as follows, including the administrator's username and password, web SSH, cluster functions, etc. You can modify them according to your needs. Generally, except for the administrator's username and password, other parameters can be kept as default:

# core configuration parameters base: # administrator login account account: admin # administrator login account password accountPwd: 111111 # whether to enable password-free login, yes to enable, no to disable, this feature requires upgrading to the professional version openSSO: no # server and agent communication key, the wgToken value in the server and agent configuration files must be consistent wgToken: wgcloud # how many data items to display per page, it is recommended to be no less than 10 pageSize: 20 # whether to enable the web ssh client, yes to enable, no to disable webSsh: yes # web ssh client service port, if you want to use web ssh, then the server host's 9998 port must be allowed in the firewall, if you don't use web ssh, you don't need to enable webSshPort: 9998 # daemon access url, used by server service, not by agent. If the daemon port is modified, the port here must also be modified synchronously (usually keep the default) daemonUrl: http://localhost:9997 # Whether to open the public dashboard, yes to open, no to close. After opening, the dashboard page does not require login dashView: yes # Whether to open the data open interface, yes to open, no to close openDataAPI: yes # Whether to enable desensitized display of the host IP of the public dashboard page, yes to open, no to close dashViewIpHide: yes # Whether to open the large-screen display dashboard, yes to open, no to close. After opening, the dashboard page does not require login dapingView: yes # Whether to automatically close the left menu, yes, no sidebarCollapse: yes # Whether to display the number of alarms on the list page, yes, no, it is generally not recommended to enable it (at least not recommended to enable it for a long time) because it may affect performance showWarnCount: no #: Whether to enable command delivery (if closed, no new commands can be added or delivered), yes, no shellToRun: yes # command delivery cannot contain sensitive characters, lowercase, multiple separated by commas shellToRunBlock: 'rm ,mkfs, /dev/,:(){:|:&};:,mv ,wget , install ,del ,delete ,format ,ren ,rd ,rd/s/q ,rmdir ' # data monitoring sql statement, can not write sensitive characters (that is, sql may be injected keywords), lowercase, multiple separated by commas sqlInKeys: 'execute ,update ,delete ,insert ,create ,drop ,alter ,rename ,modify ' # data table monitoring interval, unit is seconds, default is 60 minutes dbTableTimes: 3600 # service interface monitoring interval, in seconds, default is 10 minutes heathTimes: 600 # ftp/sftp service monitoring interval, in seconds, default is 10 minutes ftpTimes: 600 # data communication equipment ping monitoring interval, in seconds, default is 15 minutes dceTimes: 900 # data communication equipment snmp monitoring interval, in seconds, default is 20 minutes snmpTimes: 1200 # alarm cache time (i.e., silent time) interval (the same alarm notification will not be sent repeatedly during this time period), in seconds, default is 120 minutes. During this period, only alerts will not be pushed to third parties (email, DingTalk, WeChat, etc.), and system monitoring and scanning work will continue normally. warnCacheTimes: 7200 # Monitoring data retention days, the default is 30 days historyDataOut: 30 # Monitoring data trend line chart, the maximum amount of data displayed in each chart each time it is queried, if the amount of data exceeds this value, the system will automatically balance the data, and the final amount of data retained will be equal to this value, mainly to prevent the chart from displaying too much data at a time and causing the browser to freeze. Configuring 0 means no compression and balanced processing of data chartDataMaxShowValue: 4000 # Node type, master or slave, a cluster can only have one master and N (up to 31) slaves, such as slave1, slave2 nodeType: master # Whether to enable the use of tags, yes to enable, no to disable hostGroup: no

2.2.4 Start the server

cd /root/wgcloud-v3.5.1/server ls -l

If you do not have execution permission, add it using the following command:

chmod +x start.sh chmod +x stop.sh

Start the wgcloud server:

sh start.sh # restart also uses this command. If you need to stop the process, use sh stop.sh

The results are as follows:

Note 1: When you start the server, the daemon process wgcloud-daemon-relese will also be started. Do not shut down the daemon process.
Note 2: If the host where wgcloud server is deployed has a firewall or security group, you need to open ports 9999 and 9998 (9998 is the web ssh port, which can be left open if not needed).

2.2.5 Start the agent

The agent also has a corresponding configuration file, the path is:

/root/wgcloud-v3.5.1/agent/config/application.properties

The only thing that needs to be modified in the agent configuration file is serverUrl, which needs to be changed to the address of the server. The only exception is the agent on the server itself, which does not need to be modified:

Note 1:wgTokenThe key for communication between agent and server, equivalent to the password, can be customized as your own configuration password (needs to be the same as the password in server/config/application.ymlwgTokenThe default value is consistent with the current value).
Note 2: The agent actively reports collected data to the server in a unidirectional manner. The agent host does not need to open any ports because the server will not access the agent.

Starting the agent is the same as starting the server in the previous section, except that the directory is different:

cd /root/wgcloud-v3.5.1/agent ls -l

Start the wgcloud agent:

sh start.sh # restart also uses this command. If you need to stop the process, use sh stop.sh

The results are as follows:

Please download other versions of the agent yourself, from the same release link downloaded on the server.

If you need to set the agent to start at boot, you can refer to my other article on Linux:3 common ways to set up commands or scripts for Debian series to start at boot, macos can add the script to the login item, the win version of the agent can register the agent as a service through the batch file regAgentService.bat, and then directly set the service to start at boot. I won’t say more here, it’s all very simple.

For the next part (function part), see:Home data center series deploys its own operation and maintenance monitoring system through wgcloud (Part 2): Functional part.