A modern monitoring agent can collect several thousand metrics from a single server. Most organisations switch everything on, and then for years nobody opens ninety percent of the charts. The cost is real: memory, disk, slow queries, dashboards where nothing is visible. The value comes from a small set of metrics chosen for the questions that need answering.

For services: four signals

For every user-facing service, regardless of technology, four metrics are enough:

  1. Latency: how long a request takes. Measured as a percentile (95th or 99th), not an average; the average hides that every twentieth user waits ten seconds.
  2. Traffic: requests per second, active sessions, messages in a queue. Context for the other signals.
  3. Errors: the share of requests that ended in an error, split into client and server errors.
  4. Saturation: how close to its limit the most constrained resource of the service is: the database connection pool, threads, a queue.

These four signals answer the question “is the service working well” without knowledge of its internals. Service-level alerts are built on them.

For infrastructure: three questions per resource

For every physical or virtual resource (processor, memory, disk, network interface), three questions:

  • Utilisation: what share of time or capacity is in use.
  • Saturation: how much work is waiting because the resource is busy. Processor run queue, disk I/O wait, dropped packets.
  • Errors: read and write errors, interface errors, retransmissions.

Utilisation at 100% is not a problem if saturation is zero. Saturation at low utilisation points to a misconfiguration. That pair says more than a CPU chart alone.

For Windows and the directory

A few metrics that do not fit the schemes above but are essential:

  • replication latency and errors between domain controllers,
  • failed authentications over time, split by reason,
  • domain controller response time for LDAP queries and ticket issuance,
  • time service health and clock skew,
  • age of the last successful backup of each system.

What not to collect

  • Metrics every second where decisions are made on a scale of minutes. A 15–60 second interval is almost always enough.
  • Per-process metrics for every process on every machine. Per process only for services that are monitored as services.
  • Values that belong in logs: identifiers, addresses, user names. A metric counts, a log describes. A metric with a high number of unique labels blows up the time series database.

Retention and aggregation

Raw data at a short interval is needed for a few days, for diagnosis. Trends are needed for a year, for capacity planning, but hourly resolution is enough for them. Two storage tiers: raw for 7–14 days, aggregated (hourly average, maximum, percentile) for a year or longer. The database grows linearly with the number of metrics, not with time.

Dashboards: one per audience

The dashboard for the person on call shows the four signals of every service on one screen, without scrolling. The capacity planning dashboard shows 90-day trends of utilisation and saturation. The diagnostic dashboard for a specific service shows its internals. One dashboard with everything is a dashboard for nobody.

Summary

Four signals per service, three questions per resource, a handful of metrics specific to the directory and backups, two retention tiers and dashboards matched to their audience. That set answers “is it working” and “what is running out” at a fraction of the cost of collecting everything. The rest is added when a question appears that the current metrics cannot answer, not in advance.