
Cx Telemetry Querying
Write and debug Coralogix DataPrime queries against logs and spans when triaging production telemetry from the cx CLI.
Overview
cx-telemetry-querying is an agent skill for the Operate phase that teaches Coralogix DataPrime pipeline queries for logs and spans via the cx CLI.
Install
npx skills add https://github.com/coralogix/cx-cli --skill cx-telemetry-queryingWhat is this skill?
- Pipeline syntax for DataPrime queries chained with | across filter, groupby, and aggregate commands
- Field namespaces $m (metadata), $l (labels), and $d (payload) with examples for severity, subsystems, and trace IDs
- Source handling for logs vs spans via cx logs, cx spans, or cx dataprime query with explicit source
- Inline # and // comment support inside query strings for saved investigations
- Reference-oriented examples omit CLI prefix so agents can focus on query language correctness
- Three data prefixes: $m metadata, $l labels, $d user payload
Adoption & trust: 539 installs on skills.sh; 104 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have Coralogix telemetry in production but keep writing invalid DataPrime pipelines or mis-prefixing metadata, label, and payload fields during an incident.
Who is it for?
Solo builders on-call who already use Coralogix and want copy-paste-correct query structure while debugging errors and latency in logs or spans.
Skip if: Teams with no Coralogix deployment yet, or builders who only need generic OpenTelemetry theory without cx-specific DataPrime syntax.
When should I use this skill?
You need to author or fix Coralogix DataPrime queries for logs or spans using the cx CLI during production investigation.
What do I get? / Deliverables
After using the skill, your agent emits valid DataPrime pipelines with correct $m, $l, and $d references and source handling for cx logs, spans, or dataprime query.
- Valid DataPrime query strings for filter, groupby, and limit pipelines
- Commented query snippets ready to run via cx logs, cx spans, or dataprime query
Recommended Skills
Journey fit
Telemetry querying is a day-two operations task for investigating live systems after ship, not for greenfield build or launch work. Monitoring is the canonical shelf because the skill documents filter, groupby, and aggregation pipelines over logs and spans—not deploy automation or incident runbooks alone.
How it compares
Use as a query-language cheat sheet alongside your observability MCP or dashboard UI—not as a substitute for provisioning Coralogix or writing application instrumentation.
Common Questions / FAQ
Who is cx-telemetry-querying for?
It is for solo and indie operators and full-stack developers who ship services monitored with Coralogix and need agent help writing DataPrime filters and aggregations during investigations.
When should I use cx-telemetry-querying?
Use it in Operate when triaging production errors, tracing requests across spans, or building ad-hoc counts by subsystem; also when validating queries before saving them in cx dataprime query during infra hardening.
Is cx-telemetry-querying safe to install?
Review the Security Audits panel on this Prism page for install risk and permissions; the skill is documentation for querying telemetry and may imply network and shell access when agents run cx commands against your environment.
SKILL.md
READMESKILL.md - Cx Telemetry Querying
# DataPrime Query Language Reference ## Query Structure A DataPrime query is a pipeline of commands separated by `|`. Each command transforms the output of the previous one: ```dataprime filter $m.severity == ERROR | groupby $l.subsystemname aggregate count() as errors ``` ### Source Handling Every query targets a **source** (`logs`, `spans`, etc.). The source is set by whichever `cx` command you use. A full query with an explicit source looks like: ```dataprime source <logs|spans> | filter ... | groupby ... ``` When running via a source-specific command (e.g. `cx logs`, `cx spans`), the source is injected automatically - omit it from the query. When running via `cx dataprime query`, use the `--source` flag or include `source` in the query itself. The examples below focus on the DataPrime query language and omit the source and CLI command prefix. ### Comments Comments are supported with `#` or `//`: ```dataprime filter $m.severity == ERROR # only errors | limit 10 // cap results ``` ## Data Prefixes All fields are accessed through three namespaces: | Prefix | Description | Examples | |--------|-------------|----------| | `$m` | Metadata (system-managed) | `$m.timestamp`, `$m.severity`, `$m.duration` | | `$l` | Labels (indexed key-value pairs) | `$l.applicationname`, `$l.subsystemname`, `$l.serviceName` | | `$d` | User data (application payload) | `$d.message`, `$d.user_id`, `$d.traceID` | `$d` is the default prefix and can sometimes be omitted, but being explicit avoids ambiguity. ## Data Types | Type | Description | Example | |------|-------------|---------| | `string` | Text, enclosed in **single quotes** | `'some_text'` | | `number` | Numeric value | `123`, `3.14` | | `boolean` | True or false | `true`, `false` | | `timestamp` | Date and time (nanoseconds since epoch) | `1714636800000000000` | | `interval` | Time duration | `1h`, `1d`, `1w` | | `array` | List of values | `[1, 2, 3]` | | `object` | Key-value pairs | `{"name": "John"}` | | `null` | Missing value or key | `null` | ## Commands ### Filtering and Selection | Command | Description | Example | |---------|-------------|---------| | `filter` | Keep rows matching a condition | `filter $m.severity == ERROR` | | `choose` | Select specific fields | `choose $m.timestamp, $d.message` | | `limit` | Cap the number of results | `limit 10` | | `wildfind` | Search all fields for a string (see note below) | `wildfind 'connection refused'` | | `lucene` | Filter using Lucene syntax | `lucene 'key:field:"value"'` | > **Note on `wildfind`:** It is a standalone command, not a condition within `filter`. You cannot combine it with other filter expressions - use it as its own pipeline stage. ### Aggregation | Command | Description | Example | |---------|-------------|---------| | `groupby` | Group rows and apply aggregations | `groupby $l.subsystemname aggregate count() as n` | | `multigroupby` | Group by multiple field sets | `multigroupby a, b aggregate count()` | | `count` | Count all rows | `count` | | `countby` | Count rows grouped by a field | `countby $l.applicationname` | | `distinct` | Return unique values of a field | `distinct $l.subsystemname` | ### Transformation | Command | Description | Example | |---------|-------------|---------| | `create` | Add a computed field | `create latency_ms from $m.duration / 1000` | | `orderby` | Sort results | `orderby $d.timestamp desc` | | `extract` | Parse fields with regex or JSON | See [Text Extraction](#text-extraction) | | `dedupeby` | Remove duplicates by a field | `dedupeby $m.templateid` | ## Operators | Operator | Description | Example | |----------|-------------|---------| | `==` | Equals | `filter $m.severity == ERROR` | | `!=` | Not equals | `filter $l.subsystemname != 'test'` | | `>`, `<`, `>=`, `<=` | Comparison | `filter $d.response_time > 1000` | | `~` | Contains (substring match) | `filter $d.message ~ 'timeout'` | | `&&` | AND | `filter $m.severity == ERROR && $l.applicationna