Professional Monitoring and Logging

01Monitoring and logging: the three pillars of observability

Monitoring tells you that something is wrong; logs and traces tell you why. The three kinds of data answer different questions and do not replace one another:

Even a single-server app benefits from logs and a few basic metrics. Distributed tracing becomes necessary once you have several services; for that situation see microservices architecture.

02Structured logs that are actually useful

Free text such as "User logged in" reads fine to a human but is painful to search and aggregate. JSON logs with fixed fields can be filtered, counted and charted:

{"time":"2026-10-27T03:12:08Z","level":"error","msg":"payment failed",
 "service":"checkout","request_id":"a1f9-77c2","user_id":7,
 "order_id":42,"duration_ms":2310,"error":"upstream timeout"}

The value of a request ID

Create a unique ID for every request (or read it from an incoming header), put it in every log line and pass it downstream. One search then shows the whole path of a request. A simple Node.js and Express example:

import { randomUUID } from "node:crypto";

app.use((req, res, next) => {
  req.id = req.headers["x-request-id"] || randomUUID();
  res.setHeader("x-request-id", req.id);
  const start = Date.now();
  res.on("finish", () => {
    console.log(JSON.stringify({
      time: new Date().toISOString(), level: "info", msg: "request",
      request_id: req.id, method: req.method, path: req.path,
      status: res.statusCode, duration_ms: Date.now() - start,
    }));
  });
  next();
});

Laravel also ships log channels such as stack and daily, and Log::withContext(['request_id' => ...]) adds the ID to every log line of that request; details are in the Laravel documentation.

03Log levels, volume and privacy

• error: something failed and someone should look. If it appears hundreds of times a day, nobody reads it any more.
• warn: something unusual that the system recovered from, such as a successful retry.
• info: significant business events and a summary line per request.
• debug: development detail; off or sampled by default in production.

Log volume costs money too. Drop or sample noisy, low-value lines such as a health check every ten seconds, and write logs to stdout so Docker or your platform collects them; this pattern is explained in deploying with Docker.

04Metrics worth measuring

The list of possible metrics is endless; start with the four "golden signals" that apply to any request-serving service:

1. Traffic: requests per second, per route.
2. Errors: the share of 5xx responses (and logically wrong ones) among all.
3. Latency: the 50th, 95th and 99th percentiles, not the mean; averages hide the slow tail.
4. Saturation: how full CPU, memory, disk, database connections and queues are.

Add business metrics to that list: orders placed per hour or failed logins. A sudden drop in orders sometimes reveals a problem before any technical graph does. The cache hit ratio is also one of the best health indicators if you use Redis.

05Alerting without the noise

An alert that wakes you every night without needing action will soon be ignored. A simple rule: alert on symptoms, not causes. Users do not know the CPU is high; they know about errors and slowness. An example in Prometheus rule format:

groups:
  - name: api
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
            / sum(rate(http_requests_total[5m])) > 0.05
        for: 10m
        labels:
          severity: page
        annotations:
          summary: "More than 5% of requests failed for 10 minutes"

• for: 10m stops alerts for momentary spikes.
• Every alert needs a clear action; link a short runbook in the annotation.
• Separate urgent alerts (wake a person) from informational ones (a chat message).

Before setting thresholds, collect a few weeks of real data so you know what is normal for your system; a threshold copied from the internet is almost always wrong. For tooling references, the Prometheus docs and OpenTelemetry are good starting points.

06Setup checklist

• All logs are JSON and carry a request ID and service name.
• A health endpoint (for example /health) exists and genuinely checks critical dependencies.
• The four golden signals are visible on a single dashboard.
• There are only a handful of urgent alerts and each has a runbook.
• Sensitive data is redacted and log retention is defined.
• Rehearse once: trigger an error on purpose and check that the alert arrives and the logs are enough to find the cause.

If part of your site feels slow, start with page load speed optimisation and put real-user data next to your server metrics. If you want help setting up monitoring on your own project, you can contact our team.