otel-ottl
Skill99 starsChanged 13 days agoApache-2.0View on GitHub
OpenTelemetry Transformation Language (OTTL) expert. Use when writing or debugging OTTL expressions for any OpenTelemetry Collector component that supports OTTL (processors, connectors, receivers, exporters). Triggers on tasks involving telemetry transformation, filtering, attribute manipulation, data redaction, sampling policies, routing, or Collector configuration. Covers syntax, contexts, functions, error handling, and performance.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- ollygarden/opentelemetry-agent-skillstheir own version, first seen Jul 13, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- ollygarden/opentelemetry-agent-skills★ 125same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository4 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- otel-collectorSkill
- otel-instrumentationSkill
- otel-semantic-conventionsSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 1 is distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 33
Use int64 constants for enumeration fields:
- Very specific: line 67
Use where to apply transformations conditionally:
- Very specific: line 76
Use nil for absence checking (not null):
- Very specific: line 136
Always set error_mode explicitly.
- Very specific: line 156
Use the object form with an explicit context: only when a statement group mixes paths that cannot be inferred to a single context, or when …
- Very specific: line 160
Use where clauses to skip items early.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
OpenTelemetry Transformation Language (OTTL)
Components that use OTTL
OTTL is not limited to the transform and filter processors. Processors (transform, filter, tailsampling, logdedup) and connectors (routing, count, sum, signaltometrics) accept OTTL expressions. See components for the full list with use cases.
OTTL syntax
Path expressions
Navigate telemetry data using dot notation:
span.name
span.attributes["http.method"]
resource.attributes["service.name"]Contexts (first path segment): resource, scope, span, spanevent, metric, datapoint, log.
Enumerations
Use int64 constants for enumeration fields:
span.status.code == STATUS_CODE_ERROR
span.kind == SPAN_KIND_SERVEROperators
Assignment: = — Comparison: ==, !=, >, <, >=, <= — Logical: and, or, not
Functions
Converters (uppercase, return values):
ToUpperCase(span.attributes["http.request.method"])
Substring(log.body.string, 0, 1024)
Concat(["prefix", span.attributes["request.id"]], "-")
IsMatch(metric.name, "^k8s\\..*$")Editors (lowercase, modify data in-place):
set(span.attributes["region"], "us-east-1")
delete_key(resource.attributes, "internal.key")
limit(log.attributes, 10, [])See function-reference for the full list of editors and converters.
Conditional statements
Use where to apply transformations conditionally:
<!-- eval:skip -->span.attributes["db.statement"] = "REDACTED" where resource.attributes["service.name"] == "accounting"Nil checks
Use nil for absence checking (not null):
resource.attributes["service.name"] != nilValidation workflow
- Validate config syntax — run
otelcol validate --config=config.yamlto catch compilation errors before starting the Collector. - Test with the debug exporter — route transformed telemetry to a
debugexporter and inspect the output:
exporters:
debug:
verbosity: detailed
service:
pipelines:
traces:
receivers: [otlp]
processors: [transform]
exporters: [debug] # swap in production exporter once validated- Set
error_mode: ignorein production — see Error handling. - Promote to production exporters — replace
debugwith the production exporter.
Common patterns
<!-- keep-in-sync: each entry must match a ## heading in ./rules/patterns.md -->- Set attributes
- Drop telemetry by pattern
- Drop stale data
- Backfill missing timestamps
- Filter processor example
- Transform processor example
- Defensive nil checks
- Redact sensitive data — strategies: replace, mask, hash, delete, and drop.
- Normalize high-cardinality attributes — path segments, IP masking, and attribute count/length limits.
- Enrich telemetry with static attributes
Error handling
Compilation errors
Occur during processor initialization and prevent Collector startup:
- Invalid syntax (missing quotes)
- Unknown functions
- Invalid path expressions
- Type mismatches
Runtime errors
Occur during telemetry processing:
- Accessing non-existent attributes
- Type conversion failures
- Function execution errors
Error mode configuration
Always set error_mode explicitly; the default differs by component.
The transform and filter processors default to ignore since Collector Contrib v0.153.0 and to propagate before it.
The routing and signaltometrics connectors default to propagate.
The count and sum connectors have no error_mode key and always propagate errors.
| Mode | Behavior | When to use |
ignore | Logs the error and continues to the next statement | Production and general use — the default for the transform and filter processors |
propagate | Returns the error up the pipeline, dropping the payload from the Collector | Development and strict environments where you want to catch every error |
silent | Ignores errors without logging | High-volume pipelines with known-safe transforms where error logs are noise |
processors:
transform:
error_mode: ignore
trace_statements:
- set(span.attributes["parsed"], ParseJSON(span.attributes["json_body"]))Statements are a flat list; the Collector infers the context (span, metric, datapoint, log, and so on) from the path prefixes.
Use the object form with an explicit context: only when a statement group mixes paths that cannot be inferred to a single context, or when you need a group-level condition or error_mode.
Performance
Use where clauses to skip items early.
# BAD — runs replace_pattern on every span
replace_pattern(span.attributes["url.path"], "/\\d+", "/{id}")
# GOOD — skips spans that lack the attribute
replace_pattern(span.attributes["url.path"], "/\\d+", "/{id}") where span.attributes["url.path"] != nilReferences
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

