Log Parsing with OpenTelemetry Pipelines
Configure custom log transformations in groundcover using OpenTelemetry Transformation Language (OTTL). Tailor your logs with structured pipelines for parsing, filtering, and enriching data before ing
Overview
groundcover supports the configuration of log pipelines using OpenTelemetry Transformation Language (OTTL) to process and customize your logs. With OTTL, you gain full flexibility to transform data as it flows into the platform.

Transforming Data with OTTL
groundcover uses OTTL to enrich and shape log data inside your monitored environments. OTTL pipelines give you a structured way to parse, filter, and modify logs before ingestion.
Each pipeline is made up of transformation steps—each step defines a specific operation (like parsing JSON, extracting key-value pairs, or modifying attributes). You can configure these transformations directly in your groundcover deployment.
To test your logic before going live, we recommend using our Parsing Playground (click the top right corner when viewing a specific log).
Required Attributes
To define an OTTL pipeline, make sure to include the following fields:
statements
– List of transformations to apply.conditions
– Logic for when the rule should trigger.statementsErrorMode
– How to handle errors (e.g., skip, fail).conditionLogicOperator
– Used when you define multiple conditions.
Deploying OTTL in groundcover
Rules are defined as a list of steps which are executed one after another. The rules can be viewed and edited by admins in the settings tab, under "Pipelines".

The rules run in groundcover's sensors. This is ideal for cost savings, as the original logs are not sent to or stored in the backend. This is useful particularly when the pipeline is used to drop logs.
The pipeline is stored in yaml
format and can be edited in the UI. The result yaml
can be exported to be used with groundcover's terraform provider, if you prefer to use a version control system (e.g. git
). Notice that the pipeline is a singleton resource, so your terraform script must only define a single one.
The logs pipeline was previously editable using helm values. Rules that exist in the sensor's values are executed prior to the ones received via remoute configuration, and will not be visible in UI.
Editing the pipeline in sensor's values will be removed in the future, in favor of the UI and terraform.
Example Structure
ottlRules:
- ruleName: "rule1"
conditions:
- 'workload == "service1" or workload == "service2"'
statements:
- statement1
- statement2
- ruleName: "rule2"
conditions:
- 'level == "debug" or container_name == "test"'
statements:
- statement1
- statement2
Setting Conditions
Use conditions
to apply transformations only when specific attributes match. This ensures your pipeline runs efficiently and only on relevant logs.
Common fields you can use:
workload
– Name of the service or app.container_name
– Container where the log originated.level
– Log severity (e.g., info, error).format
– Log format (e.g., JSON, CLF, unknown).
Writing OTTL Statements
Some commonly used functions in groundcover:
ExtractGrokPatterns
ParseJSON
Replace_pattern
Delete_key
ToLowerCase
Concat
ParseKeyValue
Examples
Simple GROK Pattern Extraction
Log
{
"body": "2025-03-23 10:30:45 INFO User login attempt from 192.168.1.100"
}
Statements
- 'set(cache, ExtractGrokPatterns(body, "^%{TIMESTAMP_ISO8601:timestamp}%{SPACE}%{LOGLEVEL:level}%{SPACE}User login attempt from %{IP:source_ip}"))'
- 'merge_maps(attributes, cache, "insert")'
Results
{
"timestamp": "2025-03-23 10:30:45",
"level": "INFO",
"source_ip": "192.168.1.100"
}
Grok + Replace + ParseKeyValue
Log
{
"body": "2025-03-23 15:20:12,512 - EventProcessor - DEBUG - Completed event processing [analyzer_name=disk-space-check] [node_id=7f5e9aa8412d4c0003a7b2c5] [service_id=813dd10298f77700029d54e3] [sensor_id=3] [tracking_code=19fd5b6e72c7e94088a9ff3d] [log_id=b'67acfe0c92d43000'] [instance_id=microservice-7894563210]"
}
Statements
- 'set(cache, ExtractGrokPatterns(body, "^%{TIMESTAMP_ISO8601:timestamp}%{SPACE}-%{SPACE}%{NOTSPACE}%{SPACE}%{NOTSPACE}%{SPACE}%{LOGLEVEL:level}%{DATA}(?<kv>\\[%{GREEDYDATA})"))'
- 'replace_pattern(cache["kv"], "[\\[\\]]", "")'
- 'merge_maps(attributes, ParseKeyValue(cache["kv"]), "insert")'
- 'set(attributes["timestamp"], cache["timestamp"])'
Results
{
"instance_id": "microservice-7894563210",
"analyzer_name": "disk-space-check",
"node_id": "7f5e9aa8412d4c0003a7b2c5",
"service_id": "813dd10298f77700029d54e3",
"sensor_id": "3",
"tracking_code": "19fd5b6e72c7e94088a9ff3d",
"log_id": "b67acfe0c92d43000",
"timestamp": "2025-03-23 15:20:12,512"
}
Grok + ToLowerCase + ParseJSON
Log
{
"body": "2025-03-23 14:55:12,456 ERROR {\"event\":\"user_login\",\"user_id\":12345,\"status\":\"failed\",\"ip\":\"192.168.1.10\"}"
}
Statements
- 'set(cache, ExtractGrokPatterns(body, "^%{TIMESTAMP_ISO8601:timestamp}%{SPACE}%{LOGLEVEL:level}%{SPACE}(?<json_body>\\{.*\\})"))'
- 'set(attributes["timestamp"], cache["timestamp"])'
- 'set("level", ToLowerCase(cache["level"]))'
- 'set(cache["parsed_json"], ParseJSON(cache["json_body"]))'
- 'merge_maps(attributes, cache["parsed_json"], "insert")'
Results
{
"timestamp": "2025-03-23 14:55:12,456",
"level": "error",
"event": "user_login",
"user_id": 12345,
"status": "failed",
"ip": "192.168.1.10"
}
Last updated