Access mechanisms

Open in ChatGPTOpen in Claude

Note

Metadata fields ($m) aren't shown as structured key/value rows in the Log details panel. They appear only nested in the panel's raw JSON. Querying them with the $m.<field> mechanisms below is the most reliable way to read and inspect metadata values.

$m.<field> Schema

Field names below are listed as the schema stores them. Several of them have a second accepted spelling, and queries resolve either one. See Canonical names and accepted aliases.

`$m.<field>`

Metadata and runtime characteristics sourced from log and span records, used in enrichment and analytics contexts.

branchid

Branch identifier for the source system.
Type: string
Dataset: logs

cxEventId

Coralogix event identifier for a span.
Type: string
Dataset: spans

duration

Duration of the span in time units.
Type: number
Dataset: spans

endTime

Span end time.
Type: number
Dataset: spans

ingressTimestamp

Ingestion time into the logging system.
Type: timestamp
Dataset: logs

logid

Unique identifier for a log record.
Type: string
Dataset: logs

priorityclass

Log priority classification.
Type: string
Dataset: logs

processingOutputTimestampMicros

Processing timestamp in microseconds.
Type: number
Dataset: logs

processingOutputTimestampNanos

Processing timestamp in nanoseconds.
Type: number
Dataset: logs

severity

Severity level of the log.
Type: Severity
Dataset: logs

templateid

Template identifier for log parsing.
Type: string
Dataset: logs

timestamp

Timestamp of the log event or start time of the span.
Type: timestamp
Dataset: logs, spans

timestampMicros

Timestamp in microseconds.
Type: number
Dataset: logs

timestampMillis

Span start time in milliseconds.
Type: number
Dataset: spans

Possible $m keys

keypath	json_type	dataset
$m.branchid	string	logs
$m.cxEventId	string	spans
$m.duration	number	spans
$m.endTime	number	spans
$m.ingressTimestamp	timestamp	logs
$m.logid	string	logs
$m.priorityclass	string	logs
$m.processingOutputTimestampMicros	number	logs
$m.processingOutputTimestampNanos	number	logs
$m.severity	Severity	logs
$m.templateid	string	logs
$m.timestamp	timestamp	logs, spans
$m.timestampMicros	number	logs
$m.timestampMillis	number	spans

---

$l.<field> Schema

`$l.<field>`

Label metadata associated with the source or origin of a log or span.

applicationname

Name of the application that emitted the log or span.
Type: string
Dataset: logs, spans

category

Logical category or classification of the log source.
Type: string
Dataset: logs

computername

Hostname or identifier of the machine where the log originated.
Type: string
Dataset: logs

operationName

Span operation name representing the traced action.
Type: string
Dataset: spans

serviceName

Service name associated with the span's origin.
Type: string
Dataset: spans

subsystemname

Subsystem identifier within the application or service.
Type: string
Dataset: logs, spans

Possible $l keys

keypath	json_type	dataset
$l.applicationname	string	logs, spans
$l.category	string	logs
$l.computername	string	logs
$l.operationName	string	spans
$l.serviceName	string	spans
$l.subsystemname	string	logs, spans

---

Canonical names and accepted aliases

The same logical label or metadata field is spelled differently depending on which dataset holds it. A field written as $l.applicationName in one dataset is $l.applicationname in another, and $m.cxEventId is $m.logid for logs. Coralogix resolves both spellings, so a query written against one dataset returns the same records when it runs against another.

Reference either spelling and the query engine looks up both. You don't need firstNonNull, and there's nothing to enable.

Canonical name	Also accepted	Difference
$l.applicationName	$l.applicationname	casing
$l.className	$l.classname	casing
$l.computerName	$l.computername	casing
$l.ipAddress	$l.ipaddress	casing
$l.methodName	$l.methodname	casing
$l.subsystemName	$l.subsystemname	casing
$l.threadId	$l.thread, $l.threadid	name and casing
$m.branchId	$m.branchid	casing
$m.cxEventId	$m.logid	name
$m.priorityClass	$m.priorityclass	casing
$m.templateId	$m.templateid	casing

Resolution covers queries you run through the Coralogix query engine, which includes Explore, Custom Dashboards, and the query APIs. Alert matching is being aligned separately; for now, write alert conditions against the spelling the dataset actually stores. Prefer the canonical name in anything new. The aliases stay supported.

What resolution does and doesn't cover

• Only one spelling holds a value in any given record, so reading either one returns that value. In the rare case where a record carries both, the canonical name wins.
• Aliases apply to $l and $m only. User data under $d is passed through as written, so $d.applicationname and $d.applicationName stay two separate fields.
• Resolution changes how a query matches, not how your data is stored. default/logs is still written with the lowercase spelling and user-defined datasets with the canonical one. Records you export through the API or from Explore carry whichever spelling the producer wrote, so a script that reads $l.applicationname out of exported default/logs data keeps working unchanged.
• Resolution happens in the query engine, not in the editor. Query default/logs for $l.applicationName and the editor underlines the keypath and reports keypath does not exist, because the schema store still answers for the spelling stored in that dataset. The query itself runs and returns the right records. Autocomplete still offers the lowercase spelling for now; a later change makes it suggest the canonical name and flag the alias as deprecated but working.

Where the original semantics still apply

Alias resolution happens in the Coralogix query engine. Queries that reach your data without passing through it keep the field names and match semantics of the underlying store, so use the spelling that store expects:

• Querying Coralogix with SQL through the Coralogix JDBC driver.
• Tableau plugin, which connects through the same JDBC driver.
• Grafana plugin, when Coralogix is added as an OpenSearch data source in an external Grafana.
• OpenSearch API, and the hosted OpenSearch view built on it.

---

$p.<field> Schema

$p.\<field>

Parameter fields representing time window and resolution hints.

timeRange

Time bounding parameters and query resolution guidance.

startTime

The inclusive lower bound of the query time range.
Type: timestamp
Dataset: logs, spans

endTime

The exclusive upper bound of the query time range.
Type: timestamp
Dataset: logs, spans

suggestedInterval

Suggested resolution interval for aggregations (e.g. histogram buckets).
Type: interval
Dataset: logs, spans

Possible $p keys

keypath	json_type	dataset
$p.timeRange.endTime	timestamp	logs, spans
$p.timeRange.startTime	timestamp	logs, spans
$p.timeRange.suggestedInverval	interval	logs, spans