網站和伺服器如何在問題影響客戶前進行監察

Short answer

We monitor websites and servers on several levels: whether the site responds from the outside, how loaded the server is, what the logs say and whether backups exist. The goal is to learn about a problem from our own monitoring, not from a client calling to say the site won't load.
We use Uptime Kuma for external website checks, aaPanel's built-in monitoring for a quick look at the server, and Prometheus with Grafana for external service checks, metric history and alerts. None of them is enough on its own. Together they answer different questions.

What "before it reaches customers" means

When we say customers, we also mean our clients' customers. The person who can't complete an order. The enquiry that never reaches anyone. The page that takes 15 seconds to load, so the visitor closes the tab.
Some problems appear suddenly. Many others give warning signs. A disk fills up over weeks. An SSL certificate has an expiry date. Load grows gradually until one day the server can't keep up. If those signs are visible in time, there is room to react calmly instead of in a rush.

What we monitor

Does the site respond from the outside

This is the first level, and we handle it with Uptime Kuma. It checks websites at regular intervals from an external point in the network, not from the server itself, and raises a signal when one stops responding. That is not the same as a real visitor with a browser, but it shows whether the site is reachable from the outside.
There is one important detail here. A site can return an "everything is fine" response and still show an error page, a blank page or a hosting notice. So the check can also look for specific text on the page, not just whether the server answered.
Uptime Kuma also tracks SSL certificates. An expired certificate stops visitors just as effectively as a server outage, and it is completely predictable.

Mail and service certificates

The website is not the only service that has to work. Mail has certificates too, often on several ports at once. For those we use Blackbox Exporter together with Prometheus. It connects to the services from the outside and checks which certificate each one actually presents. The example further down shows why that matters.

How the server is doing

For a quick look at VPS servers we use aaPanel's built-in monitoring: load, CPU, memory, disk. It is the first place we open when something looks off. We wrote more about why we work with the panel in Why we use aaPanel for VPS servers.
A snapshot is not enough, though. That is why we also run Prometheus, which collects metrics at regular intervals and keeps their history, and Grafana, which shows them on dashboards.
History answers questions a snapshot can't:

• Is the disk filling up gradually, and when will it run out of space?- Is this load normal for this time of day, or is it new?- When exactly did the problem start, and what changed at that moment?### What the logs say A site can work for most visitors and still throw errors on specific pages or for specific actions. Web server and application logs often show the problem before anyone notices it. When there is a signal, they are the first place we look for the cause. ### Are there backups Backups are not monitoring in the narrow sense, but they are part of the same care. Having a backup job is not enough. It has to be clear what is backed up, where the copies are stored and whether a restore has been tested. A backup nobody has tried to restore is an assumption, not a safety net. ## Alerts worth reading Monitoring without alerts means someone has to watch the dashboards all the time. Alerts without restraint mean that a week later nobody reads them. So we set up alerts around a few principles:
• A signal for something that needs action. A short load spike that clears on its own is not a reason for concern.- Thresholds with duration. A site that fails one check may be network noise. A site that fails several checks in a row is a problem.- A warning before the failure. A disk at 85% is a warning. A disk at 100% is already an outage.- Checking the signal itself. Sometimes the problem is in the check, not the service, for example a DNS timeout during the check itself. Monitoring that raises false alarms often teaches people to ignore signals. So we also keep an eye on how reliable the monitoring is.Both Uptime Kuma and Grafana have their own alerts. Grafana Alerting lets you write rules on the same metrics you see on the dashboards. That way the alert and the chart you use to check it are talking about the same thing. ## Example: a certificate the checks caught In mid-October our external checks flagged a mail problem on one of the domains we look after. The ports used for sending mail (465 and 587) were failing the TLS check, while IMAP on port 993 worked normally. The cause was a wrong SNI configuration in Postfix. SNI is how the server tells which domain a connection is for and which certificate to present. The certificate itself was fine, but the service was presenting the wrong one. We corrected the configuration and the checks passed. This kind of problem stays invisible if you only watch whether the site loads, or only when the certificate expires. That is why we check from the outside which certificate each service actually presents. ## How we get to the cause An alert tells you there is a problem. It doesn't tell you why. When a signal comes in, we look at when it started, what the metrics show around that moment and what the logs say. The metric history we review in Grafana often gives the answer: a deployment, growing traffic, a process eating memory, a scheduled job that started at the wrong time. For part of the diagnosis we are building our own tool, WebComa Infrastructure MCP. It uses the Model Context Protocol to give an AI assistant a set of predefined tools: information about servers, system services, logs, network connectivity and Prometheus metrics. For example, when a service is reported as unreachable, it helps us bring together the state of the server and the relevant system service, the available logs and the related metrics in one place. Instead of a series of separate manual checks, we use predefined tools with limited access. What exactly is available depends on the permissions and the checks enabled for each environment. This is not open access to the servers. The tool works with limited permissions and approved sources. Operations that change anything are the exception, they are tightly scoped and require explicit approval. We are developing it step by step. New capabilities go through a test environment before we use them in real work. The roles stay clear: monitoring detects the deviation, the tool helps gather context, and a specialist decides what to do. ## What technical monitoring cannot see Every dashboard can be green while the business is losing money. The site responds, the server is calm, but:
• the enquiry form doesn't send emails;- card payments fail on the payment provider's side;- the integration with a courier or warehouse has stopped;- after a change on the site, tracking has stopped collecting data.Technical monitoring sees the infrastructure. It doesn't see whether orders and enquiries are coming in. For an online store or a site that generates enquiries, it makes sense to check business signals separately, for example whether orders have arrived within a normal period or whether a key event is still being recorded. That is a setup for the specific project and business, not something standard monitoring provides on its own. There are other limits too. When a site is hosted by the client and we have no access to the server, we can only monitor it from the outside. Monitoring also doesn't prevent problems. It shortens the time between when they appear and when someone reacts. ## What an owner can check You don't need to be technical to ask the right questions of whoever maintains your website:
• Who finds out first if the site goes down: you, your customer or someone who is watching it?- When do the SSL certificate and the domain registration expire, and who renews them?- Are there backups, where are they, and when was a restore last tested?- Is there a history of server load, or does anyone only look at the moment something happened?- Who checks that forms and orders actually reach you?If the answer to most of these is "I don't know", now is a good time to find out. Some of them are also covered in Before launch: technical foundation, SEO and maintenance. ## Conclusion Monitoring is not one program but several layers that answer different questions. Uptime Kuma tells you whether the site is reachable. aaPanel gives a quick view of the server. Blackbox Exporter checks services and their certificates from the outside, Prometheus keeps the results and metrics over time, and Grafana displays them and raises alerts when something drifts. Logs and our internal tools help us get to the cause. This monitoring is part of our website maintenance subscription and online store support. If you want to know where your website or server stands, we can start with a hosting and infrastructure review. Originally published on the WebComa blog.