Metrics
Effectively monitor and manage fair usage limits to prevent ingestion delays, performance degradation, or service interruptions.
Prerequisites
You can monitor limit violations in two ways:
Use the pre-aggregated violation logs in
default/logs.These logs are always emitted and let you detect when a limit is being breached without enabling any datasets.
Use diagnostic logs in the labs.limitViolations dataset.
These logs include additional context for each violation such as the specific metric or label involved. To capture this level of detail, you must enable diagnostic logging.
Diagnostic logs are written to the labs.limitViolations system dataset. Before you turn on diagnostic logs, enable this dataset to allow reads and writes.
- Go to Data Flow, then Dataset Management.
- Enable the system dataset labs.limitViolations.
By default, reads and writes are disabled on system datasets to prevent unnecessary quota usage. Enabling the dataset ensures that diagnostic violation logs are stored and available for querying.
Accessing limits
Navigate to Settings, select Metric Data, then Fair Usage Limits.
The Fair Usage Limits page displays all monitored limits grouped by category metric limits, ingestion limits, and query limits.
Each entry includes the limit name, description, threshold value, and a Diagnostic Log toggle that lets you enable or disable diagnostic logging for that specific limit.
When a fair usage limit is violated and diagnostic logging is enabled, a diagnostic (violation) log is emitted and saved in the labs.limitViolations dataset.
Note
Diagnostic logs from the 'labs.limitViolations' dataset appear only when you filter logs explorer to All Logs.The Frequent Search filter hides dataset-backed logs. In addition, datasets cannot be queried with Lucene, you must use DataPrime. Switch to All Logs and use DataPrime to view violation logs. 
These logs can be queried and visualized in Custom Dashboards for deeper analysis.
To set alerts for limit breaches, use violation alert logs, which are designed specifically for alerting.
Understand label-length enforcement
When a label value exceeds the allowed maximum length, Coralogix applies an enforcement action to keep the system stable and ensure fair usage.
Historically, Coralogix applied two internal backend behaviors:
- Drop sample (legacy): Coralogix discards the entire data sample (log, metric, or span). You do not configure this behavior, but you might notice missing data or violation logs that reference dropped samples.
- Truncate label (legacy): Coralogix cuts the value to fit within the allowed length. You cannot configure this behavior. You might notice truncated attribute values or related violation logs.
These behaviors prevent ingestion failures, but they introduce downsides such as data loss, loss of uniqueness, label collisions, and difficulty diagnosing ingestion behavior. Neither behavior preserves information about the truncated portion of the value.
To address these issues, Coralogix now uses append checksum to preserve traceability without exceeding system limits.
Append checksum enforcement
When a value exceeds its maximum allowed length, Coralogix:
- Keeps the first portion of the value
- Generates a deterministic 16-character checksum from the truncated remainder
- Appends this checksum to the preserved prefix
- Ensures the final value stays within the limit
Final format:
<first 496 characters>-<16_character_checksum>
````
**Example:**
```text
Original: a_very_large_string...................................(over limit)
Result: a_very_large_string...(truncated)...-a94f8f2e1bc91230
This provides:
- No dropped data
- No silent truncation
- Guaranteed uniqueness
- Predictable and reversible identification
- Compliance with fair usage limits
Append checksum gives users a more transparent, reliable, and deterministic enforcement method while eliminating the drawbacks of the previous internal mechanisms.
You can import following custom dashboard JSON to instantly have a dead simple custom dashboard on top of violation and violation diagnostic logs.
{
"id": "uhzvsq085jHITIFwwr9eD",
"name": "Violations Dashboard",
"layout": {
"sections": [
{
"id": {
"value": "3d0a620e-a11b-41c2-b74c-9a5818515213"
},
"rows": [
{
"id": {
"value": "6165ac70-fe33-45bc-b624-09a03f0c5eb2"
},
"appearance": {
"height": 19
},
"widgets": [
{
"id": {
"value": "27c77581-23f5-4a69-9bbf-b5f174ba279b"
},
"title": "New Markdown",
"definition": {
"markdown": {
"markdownText": "# Fair Usage Limits - Violations by Limit Name\n\nThis dashboard field displays real-time violations of Fair Usage Limits grouped by limit name, enabling you to monitor resource consumption patterns, generate targeted alerts, and investigate specific limit breaches.\nKey Metrics Shown\n\n| Name | Description |\n| -------- | ------- |\n| Limit Name | The identifier of the specific limit being tracked |\n| Violation Count | Number of times the limit has been breached within the selected time window. |\n\nIf you have fair usage limit violation diagnostic logs enabled, you can check additional context like metric_name, label_name etc in the details table.\n\n**Note:**\nFair Usage Limits protect system integrity while providing generous headroom for legitimate use. Regular monitoring of this dashboard helps maintain optimal performance and prevents unexpected disruptions."
}
}
}
]
}
],
"options": {
"internal": {}
}
},
{
"id": {
"value": "ad397842-9393-44a3-b8d7-96b3c368fac6"
},
"rows": [
{
"id": {
"value": "7009c454-c707-4653-aeb5-f3df8213edea"
},
"appearance": {
"height": 19
},
"widgets": [
{
"id": {
"value": "a00ad687-7711-4ecc-a25e-bbbb5bc5e589"
},
"title": "Metrics Violations",
"definition": {
"lineChart": {
"legend": {
"isVisible": true,
"columns": [],
"groupByQuery": true,
"placement": "LEGEND_PLACEMENT_AUTO"
},
"tooltip": {
"showLabels": false,
"type": "TOOLTIP_TYPE_ALL"
},
"queryDefinitions": [
{
"id": "c6efcbb5-4af0-42a5-bacf-d1376145d39c",
"query": {
"dataprime": {
"dataprimeQuery": {
"text": "source logs | filter $d.limit_event_type ~ 'breached' | groupby $d.limit_name, roundTime($m.timestamp, 15m) as timestamp aggregate count() as count"
},
"filters": []
}
},
"seriesCountLimit": "20",
"unit": "UNIT_UNSPECIFIED",
"scaleType": "SCALE_TYPE_LINEAR",
"name": "Query",
"isVisible": true,
"colorScheme": "classic",
"dataModeType": "DATA_MODE_TYPE_ARCHIVE",
"decimal": 2,
"hashColors": false,
"decimalPrecision": false
}
],
"stackedLine": "STACKED_LINE_UNSPECIFIED",
"connectNulls": false
}
}
}
]
},
{
"id": {
"value": "f7dd7df3-5a66-450d-a7e5-ff8d098957f8"
},
"appearance": {
"height": 35
},
"widgets": [
{
"id": {
"value": "2d457cfa-0198-4f72-9192-bea18db75c7b"
},
"title": "Violation Details",
"definition": {
"dataTable": {
"query": {
"dataprime": {
"dataprimeQuery": {
"text": "source system/labs.limitViolations | filter $d.limit_event_type ~ 'breached' | filter arrayContains($p.limit_name, $d.limit_name)"
},
"filters": []
}
},
"resultsPerPage": 100,
"rowStyle": "ROW_STYLE_ONE_LINE",
"columns": [
{
"field": "$m.timestamp",
"width": 200
},
{
"field": "$d.limit_name",
"width": 276
},
{
"field": "$m.severity",
"width": 200
},
{
"field": "$d.limit_threshold",
"width": 200
},
{
"field": "$d.violation_context.label_name",
"width": 200
},
{
"field": "$d.violation_context.label_value",
"width": 200
},
{
"field": "$d.violation_context.metric_name",
"width": 200
}
],
"orderBy": {
"field": "$m.timestamp",
"orderDirection": "ORDER_DIRECTION_DESC"
},
"dataModeType": "DATA_MODE_TYPE_ARCHIVE"
}
}
}
]
}
],
"options": {
"custom": {
"name": "Violations",
"collapsed": false,
"color": {
"predefined": "SECTION_PREDEFINED_COLOR_UNSPECIFIED"
}
}
}
}
]
},
"variables": [],
"variablesV2": [
{
"name": "limit_name",
"displayName": "limit_name",
"description": "Limit name to track",
"displayType": "VARIABLE_DISPLAY_TYPE_V2_LABEL_VALUE",
"source": {
"query": {
"dataprimeQuery": {
"type": {
"queryText": {
"query": {
"text": "filter $d.limit_event_type == 'breached' | choose $d.limit_name | distinct $d.limit_name"
},
"dataModeType": "DATA_MODE_TYPE_ARCHIVE"
}
}
},
"valuesOrderDirection": "ORDER_DIRECTION_ASC",
"refreshStrategy": "REFRESH_STRATEGY_UNSPECIFIED",
"valueDisplayOptions": {},
"allOption": {
"includeAll": false
}
}
},
"value": {
"multiString": {
"list": {
"values": [
{
"value": {
"value": "max_label_length",
"label": "max_label_length"
}
},
{
"value": {
"value": "unique_series_per_metric_per_day",
"label": "unique_series_per_metric_per_day"
}
},
{
"value": {
"value": "max_labels_per_metric",
"label": "max_labels_per_metric"
}
}
]
}
}
},
"displayFullRow": false
}
],
"filters": [],
"relativeTimeFrame": "7200s",
"annotations": [],
"off": {},
"actions": [
{
"id": "8cb30d5a-722e-4867-b968-c8bbb1cb3590",
"name": "Dataset Diagnosis",
"shouldOpenInNewWindow": true,
"widgetId": "a00ad687-7711-4ecc-a25e-bbbb5bc5e589",
"definition": {
"customAction": {
"url": "https://c4c.app.eu2.coralogix.com/#/query-new/archive-logs?id=9mgHfidrpgQv3v0vHYvVr&querySyntax=dataprime&time=from:now-30m,to:now&page=0&permalink=true"
}
},
"dataSource": "ACTION_DATA_SOURCE_TYPE_DATAPRIME"
},
{
"id": "b1a23601-4bed-4193-ac56-063cbb25ef77",
"name": "FUP & Enable Diagnostics",
"shouldOpenInNewWindow": false,
"widgetId": "a00ad687-7711-4ecc-a25e-bbbb5bc5e589",
"definition": {
"customAction": {
"url": "https://c4c.app.staging.coralogix.net/#/settings/metric-data/limits"
}
},
"dataSource": "ACTION_DATA_SOURCE_TYPE_DATAPRIME"
},
{
"id": "bbf6f6cb-daaf-48b4-9066-ac3b8d32caef",
"name": "Dataset Diagnosis",
"shouldOpenInNewWindow": true,
"widgetId": "eac85474-5c7f-4d52-8ac6-74501d15f173",
"definition": {
"customAction": {
"url": "https://c4c.app.eu2.coralogix.com/#/query-new/archive-logs?id=9mgHfidrpgQv3v0vHYvVr&querySyntax=dataprime&time=from:now-30m,to:now&page=0&permalink=true"
}
},
"dataSource": "ACTION_DATA_SOURCE_TYPE_DATAPRIME"
},
{
"id": "3507903a-fd8d-4860-873e-f54d6db75844",
"name": "FUP & Enable Diagnostics",
"shouldOpenInNewWindow": false,
"widgetId": "eac85474-5c7f-4d52-8ac6-74501d15f173",
"definition": {
"customAction": {
"url": "https://c4c.app.staging.coralogix.net/#/settings/monitoring-data"
}
},
"dataSource": "ACTION_DATA_SOURCE_TYPE_DATAPRIME"
}
]
}
Monitoring limits in Custom Dashboards
The primary way to monitor limits is to set alerts on top of violation logs. Violation logs are emitted whenever any limit is breached, and they work for all limits, including label length, value length, maximum labels, ingestion limits, and query limits.
In addition to alerts on violation logs, you can monitor certain limit types in Custom Dashboards. This applies only to limits that expose metrics, such as the Total Unique Series Per Metric limit.
For this limit, you can track usage trends with the unique_series_daily metric. For example:
max(unique_series_daily) by (metric_name)
Shows the peak number of unique time series per metric and helps you track cardinality growth.
increase(unique_series_daily[30m])
Shows how many new time series appeared in the last 30 minutes so you can identify spikes early.
Metric-based monitoring helps you understand trends before a limit is breached. For all other limits, violation logs remain the only monitoring method.
Monitoring limits with Alerts
The first and most important way to detect limit issues is to set alerts on violation logs. Violation logs are emitted whenever any limit is enforced, and they apply to all limit types.
You can also build alerts on metrics for the Total Unique Series Per Metric limit. For example, you might create a metrics-based threshold alert that monitors unique_series_daily:
max(unique_series_daily) by (metric_name)
When the metric crosses a threshold that matches your configured conditions, the alert triggers and gives you time to adjust before the limit is breached.
For all other limits, alerts should be created on violation logs, since they are the definitive signal for enforcement events.
Requesting limit adjustments
If your team consistently approaches or exceeds fair usage thresholds and requires additional capacity, Coralogix offers flexibility through managed adjustments.
To explore increasing your ingestion or query limits, contact Customer Support via our in-app chat or by email at support@coralogix.com.
Global limits are not adjustable.