A common warning sign is a metric that becomes expensive to store but too noisy to act on. If every log field is turned into a dimension, counts fragment into tiny slices and trends become harder to read. Teams should watch for overly high cardinality, repeated repetitive values, and dashboards that add volume without improving decision-making.
What Broad Dimensioning Looks Like in Practice
Log-based metrics are usually too broad when they try to count too many values at once. A healthy metric has a small set of stable dimensions that help answer a real operational question. When dimensions are added just because the field exists in the log, the result is often fragmentation, duplicated labels, and a measure that is technically rich but practically weak.
One sign is that the metric no longer describes a pattern, it describes a pile of slices. Instead of showing how a system behaves over time, the metric creates thousands of tiny groups that rarely repeat. That makes trend detection harder, increases storage and query cost, and often hides the signal the team actually wanted to track.
Another warning sign is that the dashboard becomes harder to interpret as more dimensions are added. If the team needs to sort, filter, and explain every chart before it becomes useful, the metric is probably carrying too much detail for its job. The best dimensions are the ones that separate meaningful operational states, not every possible log attribute.
Signs the Metric Has Gone Past the Useful Cardinality Point
High cardinality is the clearest symptom, but the more useful test is whether the metric still supports a decision. If a count is split across user IDs, request IDs, hostnames, endpoints, regions, and error variants all at once, the output may look precise while becoming nearly impossible to compare. At that point, the metric is often broad enough to be expensive but not broad enough to be insightful.
Repeated repetitive values are another clue. When the same category keeps appearing across many logs without changing the decision you make, it is a sign that the dimension is not adding analytical value. Teams often notice this when a chart is dominated by long tails, one-off labels, or tiny buckets that never mature into stable operational segments.
Broad dimensioning also shows up when volume rises faster than usefulness. If ingestion, indexing, and dashboard load increase, but incident response, anomaly detection, or SLA review do not improve, the metric is probably capturing too much raw detail. In practice, that usually means the metric is closer to an exploratory query than a production-quality operational indicator.
Practitioner Guidance
What to prioritise: Keep only the dimensions that change the decision. If removing a dimension would not change how a team investigates, alerts, or reports on the system, it is a good candidate to drop or roll up.
What to verify: Check whether each dimension has enough repetition to form stable groups over time. If most slices have tiny counts, the metric is telling you about log structure rather than system behaviour.
Common mistake: Treating every log field as a useful metric dimension. That creates dashboards that look comprehensive but fail under real operational use because they are too granular to compare cleanly.
Practitioner takeaway: A well-sized log metric should reduce uncertainty, not simply expose more detail. When detail increases cost and noise without improving actionability, the metric is dimensioned too broadly.
Related resources from NHI Mgmt Group
- What are the signs that client side group based rendering is being used too broadly?
- What are the signs that VPC Flow Log ingestion is too noisy to be useful?
- What are the signs that Copilot is being misused or deployed too broadly?
- What are the signs that an SSO blocking policy is being applied too broadly?
