What to Monitor: A Three-Layer Metrics Checklist for Servers, Applications, and Business
Once you install a monitoring tool and open the dashboard, a screen full of CPU, memory, and throughput numbers often leaves people unsure "what to watch and what counts as abnormal". This article gives you a framework: divide metrics into server, application, and business layers, and watch only a few key metrics per layer. Monitoring only becomes useful once you understand "what each number means and what level is dangerous".
1. The Three-Layer Monitoring Model: Inside Out
Think of your website as a restaurant:
- Server layer (the kitchen): whether the stove can cook and whether ingredients are enough — host resources such as CPU, memory, disk, and bandwidth;
- Application layer (the serving window): whether dishes are fast and correct — application performance such as rate, errors, and latency;
- Business layer (the cash register): whether guests buy and come back — business outcomes such as registration, conversion, and orders.
The layers build on each other: server anomalies usually show up first at the application layer, and application anomalies eventually show up at the business layer. The end goal of monitoring is the business, not "pretty numbers".
2. Server Layer: The Host Resource Quartet
| Metric | What it means | Typical alert threshold |
|---|---|---|
| CPU usage | How busy the processors are | Alert when sustained >80%, severe >95% |
| Memory usage | Whether physical RAM is enough | Alert >85%; distinguish "used" from "cache" |
| Disk usage | How much disk is left | Alert >80%, severe >90% (logs/databases fill up fastest) |
| Bandwidth/traffic | In/out NIC traffic | Alert near the cap; guards against flooding or saturating |
Tip: for metrics like CPU, memory, and disk that are only dangerous near 100%, do not set thresholds too high — leave headroom for traffic spikes. Alert on disk early in particular, because a full disk usually means the service cannot write data and dies outright. For full metric interpretation and commands, see Linux Server Basics Guide. Beyond the quartet, also watch: load average, process count, and TCP connection count (to prevent connection exhaustion).
3. Application Layer: Condense to Three Metrics with the RED Method
Application-layer metrics are too numerous to list. The industry uses a mnemonic called RED to condense them to three core ones:
- Rate: how many requests are handled per second/minute. Used to spot sudden spikes or drops (which may mean an outage).
- Errors: the share of failed requests, such as the 4xx/5xx ratio. A 5xx rate above 1% deserves attention; above 5% usually needs urgent handling.
- Duration: response latency. Watch P95/P99 rather than the average — averages are flattened by a few slow requests, while P99 is the real experience of "the slowest 1% of users".
Example: an endpoint averaging 200ms looks fine, but if P99 is 3 seconds, 1% of users are enduring obvious sluggishness. So always watch percentiles for latency. Slow database queries and slow third-party calls are the two common causes of rising latency; debugging methods are in Distributed Tracing. Frontend page performance (first paint, interaction) is a separate set of metrics — see Frontend Performance Monitoring.
4. Business Layer: Translate Technical Metrics into Business Language
Normal technical metrics do not mean a healthy business. Business-layer metrics vary by product, but common ones include:
- Registration/activation/conversion rates;
- Order volume, payment success rate, refund rate;
- Daily/monthly active users (DAU/MAU), retention;
- Average order value, revenue.
Business metrics usually come from databases or analytics platforms (such as Website Analytics Setup) and are harder to collect than technical metrics, but they carry the highest value: they are the final yardstick for "whether monitoring is useful". For example, if the conversion rate suddenly halves, technical metrics may look perfectly normal while the business is already in trouble.
5. Metrics Checklist: Copy Directly
| Layer | Metric | How to read | Alert suggestion |
|---|---|---|---|
| Server | CPU usage | >80% sustained | Alert |
| Server | Memory usage | >85% | Alert |
| Server | Disk usage | >80% | Alert, severe >90% |
| Server | Bandwidth usage | Near cap | Alert |
| Server | TCP connections | Near max | Alert |
| Application | Rate | Sudden spike/drop | Alert |
| Application | Errors | 5xx >1% | Alert |
| Application | Latency P95/P99 | P99 shift | Alert |
| Application | Queue backlog | Growing steadily | Alert |
| Business | Conversion/orders | Clear decline | Alert |
Pace of adoption: do not chase "all metrics" on day one. In the first week, wire up the server quartet plus the application RED five metrics, and get Prometheus + Grafana Basics or any solution in Website Monitoring Tools Comparison running; add business metrics and alerts in month two.
6. Frequently Asked Questions
Q1: Too many metrics — my dashboard is overflowing. What do I do?
Manage by layer: one dashboard each for server, application, and business; put only "actionable metrics" on each. A dashboard is for people, not data dumping. For tool choices, see Cloud Monitoring Services Comparison.
Q2: Should I watch averages or percentiles?
For "experience" metrics like latency and response time, watch percentiles (P95/P99); for capacity metrics like disk and memory, watch the current value and trend. Averages hide real problems — do not be "an averaged person".
Q3: Business metrics are hard to collect. Can I skip them?
Do at least one or two core ones (such as order volume or conversion rate). Monitoring without business metrics is like "the engine is fine, but you do not know whether the car reached its destination". Start with a simple scheduled query that counts records in the database.
Q4: Where can I find more monitoring content?
The Monitoring & Alerting category on this site covers monitoring setup, alert design, SLOs, and more — a complete learning path alongside this article.