Skip to main content

Excessive Low-Severity Log Ratio

Important Signal: Logs

Problem

Almost everything a service logs is INFO or below. Routine chatter (“request handled”, “job started”, “cache refreshed”) makes up so much of the volume that the rare WARN or ERROR line arrives already buried in the noise.

Insights measures the severity mix per service over a 1-hour sliding window and flags the service when low-severity records (INFO and below) exceed 60% of volume, evaluated only once the window holds enough logs to be statistically meaningful.

Impact

  • Warnings and errors, the lines you search for during incidents, are needles in a haystack you’re paying to store.
  • Log-based alerting and anomaly detection degrade as baseline noise grows.
  • Most of the ingest bill buys records nobody will ever read.

Example

Drowned:

INFO request handled path=/health ← ~50/sec
INFO request handled path=/products ← ~200/sec
WARN payment retry exhausted order=8812 ← the line that mattered
INFO request handled path=/health

Balanced:

# routine request logging moved to metrics or sampled
WARN payment retry exhausted order=8812
ERROR payment failed order=8812 gateway=timeout

How to fix

  1. Find the top INFO producers, usually per-request access logging or framework chatter.
  2. Convert per-request lines into metrics (a counter and a histogram carry the same aggregate signal at a fraction of the cost), or sample them.
  3. Keep INFO for state changes worth reading later (startups, config loads, deploy markers), not for every request.

Expected gains

Warnings and errors stand out again, alerting regains its signal, and log spend shifts from routine chatter to records with diagnostic value.

See the Insights catalog for everything Insights can detect.