Cardinality reporting metrics
The Metric Data screen shows your cardinality in the UI, which is enough to investigate a spike after the fact. It is not enough to catch one as it happens, because you cannot alert on a screen.
Cardinality reporting metrics close that gap. Turn one on and Coralogix emits your cardinality as an ordinary metric in your account, so you can chart it on a dashboard, compare it across a deploy, and alert when it climbs toward a fair usage limit.
What you need
- The permission to manage Metric Data settings
- Metrics export enabled for your account. Enabling a cardinality metric without it fails and the error names the fix.
Turn a metric on or off
Both metrics are off by default. Turn on the ones you want:
- Go to Settings, then Metric Data.
- Open the settings panel and find Metric Data visibility.
- Use the toggle next to the metric you want. A metric that is on is marked Enabled.
Each metric is independent, so you can report per-metric cardinality without reporting per-service cardinality, or the other way around. There is no finer-grained switch: enabling a metric reports every metric name or every service in the account.
cx_unique_series_daily_per_metric
Today's unique series per metric name, as a cumulative counter.
| Label | metric_name |
| Series produced | One per metric name in your account |
Use it to find which metric is driving a cardinality increase. Broken down by metric_name, it turns "our cardinality jumped last night" into "http_request_duration_seconds tripled at 02:15", which is usually enough to point at the deploy or the label that caused it.
Example queries
Peak unique series per metric, the view to put on a dashboard:
max(cx_unique_series_daily_per_metric) by (metric_name)
New series appearing in the last 30 minutes, which surfaces a spike while it is still forming:
increase(cx_unique_series_daily_per_metric[30m])
A single metric you already suspect:
cx_unique_series_daily_per_metric{metric_name="http_request_duration_seconds"}
cx_unique_series_daily_per_service
Today's unique series per service, as a cumulative counter.
| Label | service_name |
| Series produced | One per service in your account |
Use it when cardinality is owned by teams rather than by individual metrics. A per-service view attributes growth to the service that produced it, which is what you want when the conversation is about who needs to act rather than which metric name changed.
Example queries
Unique series per service:
max(cx_unique_series_daily_per_service) by (service_name)
The five services contributing most, for a top-N dashboard panel:
topk(5, max(cx_unique_series_daily_per_service) by (service_name))
Alert before you hit a limit
The point of these metrics is the alert, not the chart. Create a metric threshold alert with one of the queries above, and set the threshold below your actual limit so the alert gives you time to act rather than telling you after the fact.
A worked example. If your Total Unique Series Per Metric limit is 1,000,000 and you want warning at 80%:
-
Create a metric threshold alert.
-
Use this query:
max(cx_unique_series_daily_per_metric) by (metric_name) -
Set the condition to more than
800000. -
Group by
metric_name, so the alert names the metric that crossed rather than telling you the account did.
Because the counter is cumulative across the day, an alert that fires in the morning is a stronger signal than one that fires late in the evening: the same value reached earlier means a faster rate of growth.
For the limits themselves and the violation logs that record a breach, see Monitor fair usage limits.
Cost
These metrics are written into your account like any other metric, so they count toward your metrics usage while enabled. The volume is small and predictable, because each one produces a single series per metric name or per service. An account with 500 metric names and 40 services adds 500 series and 40 series respectively, not a series per label combination.
For most accounts that is a minor cost against the ability to catch a cardinality problem before it starts dropping data. If you only need an occasional look, the Metric Data screen gives you that at no extra cost and you can leave these off.