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. The default Unique series per metric limit is 24,000,000 per metric name per day. To be warned at 80% of it:
-
Create a metric threshold alert.
-
Use this query:
max(cx_unique_series_daily_per_metric) by (metric_name) -
Set the condition to more than
19200000. -
Group by
metric_name, so the alert names the metric that crossed rather than telling you the account did.
Your account may have a different value. Check Unique series per metric on the Fair usage limits page and take 80% of the number shown there rather than reusing the figure above.
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.
If you already use unique_series_daily
unique_series_daily is the earlier per-metric cardinality metric, enabled per account by Coralogix on request. It still works and is not charged, so an account already using it keeps the alerts and dashboards built on it. No end-of-life date is set.
The two metrics are not interchangeable:
unique_series_daily | cx_unique_series_daily_per_metric | |
|---|---|---|
| Scope | Per metric name | Per metric name |
| Per service | Not available | Use cx_unique_series_daily_per_service |
| Enabled by | Coralogix, on request | You, in the Metric Data visibility card |
| Cost | Not charged | Counts toward metrics usage while enabled |
If you move across, the query shape is the same, so swap the metric name and keep the rest:
max(cx_unique_series_daily_per_metric) by (metric_name)
Turning the new metric on does not turn the old one off. Running both reports the same cardinality twice and charges you for one of them, so switch the alert over first, confirm it fires as expected, and then ask Support to disable unique_series_daily.