Data access mechanisms

Goal

By the end of this guide, you should be able to:

• Understand the role of $d, $m, $l, and $p prefixes in DataPrime queries.
• Use each prefix to filter, group, or transform data in a meaningful way.
• Implement real-world queries that combine these access mechanisms to solve complex problems.

Why it matters

DataPrime queries operate on structured data with multiple layers—raw event content, system metadata, user-defined labels, and query-time parameters. These layers are organized using four access mechanisms: $d, $m, $l, and $p. Understanding how and when to use each of them is essential for building accurate and efficient queries.

Understanding each access mechanism

Use $d for actual event data

This is your actual log data and the default namespace. Using $d is optional.

source logs
| filter user_id == '123'         // equivalent to filter $d.user_id == '123'

To access deeply nested keys:

source logs
| filter http.request.code == 404

DataPrime supports both dot notation and bracket notation. An equivalent way to write this query is:

source logs
| filter $d['http']['request']['code'] == 404

Use whichever notation suits your needs and preferences the best though dot notation tends to be more concise and readble.

You saw in the previous section “Making your first DataPrime query” that the $d data access mechanism wasn’t being used. This is because $d is the optional default access mechanism. If you leave it out, in most cases, your data will still be queried, but not the other Coralogix generated information. See when $d is required.

Use $m to access system metadata

System metadata is automatically added to logs, traces, and other datasets, by Coralogix on ingestion. It contains important information like logid, severity, and timestamp. See the whole list here.

source logs
| filter $m.severity == ERROR

Use this to track error logs.

Use $l for labels and grouping

User-managed labels are ideal for aggregations and dashboards. See the whole list here.

source logs
| groupby $l.subsystemname

This groups all unique events by the subsystem label.

Use $p for query parameters

In dashboards or Explore, use $p to parametrize your queries. See the whole list here.

example: time-relative queries

source logs
| filter user_login_time < $p.timeRange.startTime

Use $p.timerange in dashboards to always reflect the selected time window.

Expected output

Here’s what each prefix helps you produce:

• $d: Clean access to raw values like user_id, ip, or duration.
• $m: System insights like log severity, time of event, and unique IDs.
• $l: Aggregation-ready fields like applicationname or threadid.
• $p: Dynamic filtering that respects dashboard variables and time windows.

Common pitfalls

• Special characters in keys: Use map notation: $d['my.key'].
• Mixing prefixes: Don’t forget that $m.timestamp is not the same as $d.timestamp.
• Null values: Comparing objects to null always returns null. Only use on scalar values.

Previous Making a query

Next Understanding types

Theme

Light

light

dark