LinkMesh

Search docs, blog and changelog

ENDE

Snippets · Processors

Drop the collector's own metrics

A collector that scrapes or receives its own telemetry sends otelcol_* metrics down the same pipeline as your application metrics. If you monitor collectors elsewhere, they are cost without a reader. This filter drops every metric whose name starts with otelcol_.

Signals
Metrics
Category
Reduction
Source
OTLP
Components
otlpbatchfiltermemory_limiterotlphttp
Destination
OTLP/HTTP endpoint

OpenTelemetry Collector

OpenTelemetry Collector YAML
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 25
  # Drops the collector's own otelcol_* metrics when they arrive in the
  # same pipeline as application metrics.
  filter/drop-internal-metrics:
    error_mode: ignore
    metrics:
      metric:
        - IsMatch(name, "^otelcol_")
  batch:
    timeout: 5s

exporters:
  otlphttp:
    endpoint: https://your-backend:4318

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, filter/drop-internal-metrics, batch]
      exporters: [otlphttp]

LinkMesh

LinkMesh has no built-in template for this job. Add it as a custom processor in raw mode, with filter as the component type and this body - the same lines as under filter/drop-internal-metrics in the collector config:

Custom processor body (filter)
error_mode: ignore
metrics:
  metric:
    - IsMatch(name, "^otelcol_")

How custom components are validated and rolled out: create a custom processor.

Download config.yamlValidated with otelcol-contrib v0.161.0 on 2026-10-26

Complete config files, each checked with the collector's own validate command (otelcol-contrib v0.161.0). Replace https://your-backend:4318 with your own OTLP endpoint before you run it.

Before and after

Example telemetry in, and what this exact config sent out when we ran it in otelcol-contrib v0.161.0. CI re-runs it on every change and fails if the output differs. Changed values are highlighted.

3 metrics in, 1 metric out (4 data points in, 1 out)

  1. Before

    metric
    otelcol_exporter_sent_log_records
    point 1
    1200 {"exporter":"otlphttp"}
    point 2
    40 {"exporter":"debug"}
    resource.service.name
    checkout

    After

    Dropped

  2. Before

    metric
    otelcol_process_memory_rss
    point 1
    81234567
    resource.service.name
    checkout

    After

    Dropped

  3. Before

    metric
    http.server.request.count
    point 1
    120
    resource.service.name
    checkout

    After

    Dropped

  4. Before

    (not in the input)

    After

    metric
    http.server.request.count
    point 1
    120
    resource.service.name
    checkout

The gotcha

The metric context drops the whole metric with all its data points. In our test otelcol_exporter_sent_log_records went out of the pipeline with both of its points (one per exporter): 3 metrics in, 1 out. To drop only some points of a metric, use a datapoint condition instead.

Manage this across a fleet

LinkMesh manages collector configuration across a fleet from one self-hosted control plane, so a change like this is made once rather than host by host. The first 25 Collectors are free after a no-card registration in the OpenSight Customer Portal (5 without one).

Doing this in LinkMesh: Filter records on a route