Skip to main content
Fields that SDKs, agents, and collectors inject automatically. Fields the developer didn’t add and doesn’t want. telemetry.sdk.version, otel.library.name, collector build strings. Each one adds bytes to every log. Not all instrumentation fields are bloat. The test: did a developer add this, and would any engineer ever query it? Bloat is metadata about the instrumentation, not metadata about your system. telemetry.sdk.version is bloat. service.name is not.

​
Example

{
  "@timestamp": "2024-01-15T10:30:00Z",
  "severity_text": "ERROR",
  "service.name": "checkout-api",
  "telemetry.sdk.name": "opentelemetry",
  "telemetry.sdk.version": "1.24.0",
  "telemetry.sdk.language": "python",
  "message": "Connection timeout"
}

id: remove-otel-sdk-metadata
name: Remove OTel SDK metadata
description: Drop OpenTelemetry SDK version info. Only useful when debugging the SDK itself.
log:
  match:
    - resource_attribute: telemetry.sdk.name
      exists: true
  transform:
    remove:
      - resource_attribute: telemetry.sdk.name
      - resource_attribute: telemetry.sdk.version
      - resource_attribute: telemetry.sdk.language
      - resource_attribute: telemetry.auto.version

Enforce at edge

Strip bloat before data leaves your network. Immediate savings, no code changes.
 These fields come from tooling, not your application code. You often can’t fix at the source. The edge is where you have control.

​
How it works

Tero maps your dependencies and instrumentation stack. Fields like telemetry.sdk.version and otel.library.name are obviously bloat - no engineer added them, no engineer wants them. Tero flags them automatically.