Preface
As our internal applications become more numerous and complex, a problem that must be solved is how to monitor the running health of all applications in real time, and receive alerts at the first opportunity when applications encounter problems. To solve this problem, we need to build our own real-time application health monitoring and alerting system, which requires the cooperation of two applications: uptime-kuma and bark-server.
Deploy uptime-kuma
First, deploy uptime-kuma via Docker using the following command:
docker run --name uptime-kuma -d --restart=always \
-p 3001:3001 \
-v /docker/uptime-kuma/data:/app/data \
louislam/uptime-kuma Parameter explanation:
-p 3001:3001
This port specifies the host port mapped to the container, which you can modify according to your actual situation.
-v /docker/uptime-kuma/data:/app/data
This maps the host directory `/docker/uptime-kuma/data` to the container's internal directory `/app/data`. All application health monitoring configurations set up on uptime-kuma are stored in this directory. If you need to migrate the container in the future, you only need to copy this directory, and the configured data will not be lost.
Confirm container status
After the container is set up, you can check if it was successfully created via Portainer, or use the following command:
docker ps -f name=uptime-kumaIf the status shows "up" and "healthy", it means it has been successfully created and is running, as shown in the figure below:
Initialize uptime-kuma
After successfully setting up the Docker container, use a browser to access it via http://:3001. The first login will require you to create an administrator username and password. After logging in, the default page is in English. You can select “Simplified Chinese” from the top-right drop-down menu under Settings -> Appearance -> Language, as shown below:
After changing the language, the entire interface turns into Chinese, as shown below:
The content in the red box on the left of the image above shows the added monitoring items, and the right side shows the settings.
Add monitoring items
Let's take adding a newwww.example.comdomain name monitor as an example to demonstrate how to add a monitoring item.
First, click the "Add New Monitor" button in the top left corner of the image above, and the following interface will appear:
In the image above, you only need to fill in the "Friendly Name" and "URL", and keep the default values for the rest. Finally, click the green button at the bottom to save:
Key settings
Monitor Type:
uptime-kuma supports multiple monitor types, as shown in the figure below:
The default is the regular HTTP(S) type, and HTTP(S) also has two methods: Keyword and JSON Query. The Keyword method can determine whether the application is normal based on whether specific characters exist in the response page. There are many other types to choose from, which interested users can explore on their own.
Accepted Status Codes:
The regular HTTP(S) type simply judges whether the site is normal based on the site response code. The default accepted status codes are 200-299, which can be modified as needed.
Notification:
How to notify the administrator when uptime detects a change in site status is described in detail in another article of mine (see:Docker Series: Building a Message Push Server Based on Bark Server ), so I won't go into detail here.
Proxy:
If the website to be monitored needs to be accessed through a proxy server, configure it here.
HTTP Options:
The default is the GET method, but other methods can also be selected.
Authentication:
If the monitored webpage requires authentication and whether it can log in is also used as a basis for health judgment, it needs to be set here:
The most commonly used is actually the regular HTTP(S) method. If you have no special requirements, you can basically just use the default configuration.
In fact, to achieve the real-time alerting function, the key lies in the choice of notification method. Personally, I recommend the Bark method. You can install the app on mobile phones (iOS, Android) and tablets (iPadOS, Android), which is very convenient. The only trouble is that building a bark-server requires a public IP. If your home broadband does not have a public IP, it is recommended to buy a cheap cloud host. For the specific setup method of bark-server, see:Docker Series: Building a Message Push Server Based on Bark Server
Configure public network access
If you want to publish to the public network, you need to choose the most suitable publishing method based on your actual environment and the reverse proxy you use. You can refer to several of my previous articles:
1、Docker Series: Building Your Own Reverse Proxy Based on NPM Using Docker
2、Linux Panel Series: Configuring Reverse Proxy and Publishing Using Non-443 Ports
3、Home Data Center Series: Getting Cloudflare for Free via Domestic ICP-Filed Cloud Hosts to Achieve Fast Access to Domestic Sites from Abroad
4、Home Data Center Series: Getting Cloudflare for Free via Home Broadband Without Public IP to Achieve Fast Website Building (Universal)
Among them, the 1st and 2nd methods are suitable for environments with a public IP but without a legal 443 port (home broadband, non-filed cloud hosts), where non-standard ports need to be added after the URL (if using Cloudflare to build a website, no port needs to be added, but you need to customize the origin server port, which you can refer to:Home Data Center Series: Solving the Problem of Having a Public IP but No Legal 80 or 443 Ports for Website Building via Cloudflare's Origin Rules). The 3rd method is suitable for cloud hosts with ICP filing, and the 4th method is suitable for all environments (including environments without a public IP), which is also my recommended method (regardless of whether your environment has a public IP, because this method does not require running HTTPS traffic directly on the public network).