LinkMesh

Search docs, blog and changelog

ENDE

Snippets · Processors

Detect host and cloud resource attributes

Telemetry needs to say where it comes from: host, environment, cloud account and region. The resourcedetection processor reads OTEL_RESOURCE_ATTRIBUTES, the host, and whichever cloud metadata endpoint answers, in that order: the first detector to set a key wins. With override: false a value the sender set itself is kept: in our test a record that arrived with host.name app-host-7 kept it, while one without got the collector's host.name from the environment.

Signals
LogsMetricsTraces
Category
Collection
Source
OTLP
Components
otlpbatchmemory_limiterresourcedetectionotlphttp
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
  # Fills in where the telemetry comes from: OTEL_RESOURCE_ATTRIBUTES first,
  # then the host, then whichever cloud's metadata endpoint answers. Values
  # the sender already set win (override: false).
  resourcedetection:
    detectors: [env, system, gcp, ec2, azure]
    timeout: 2s
    override: false
    system:
      hostname_sources: [os]
  batch:
    timeout: 5s

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

service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [memory_limiter, resourcedetection, batch]
      exporters: [otlphttp]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, resourcedetection, batch]
      exporters: [otlphttp]
    traces:
      receivers: [otlp]
      processors: [memory_limiter, resourcedetection, batch]
      exporters: [otlphttp]

LinkMesh

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

Custom processor body (resourcedetection)
detectors: [env, system, gcp, ec2, azure]
timeout: 2s
override: false
system:
  hostname_sources: [os]

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.

2 log records in, 2 log records out

  1. Before

    body
    sender set nothing
    resource.service.name
    checkout

    After

    body
    sender set nothing
    resource.service.name
    checkout
    resource.deployment.environment.name
    production
    resource.service.namespace
    shop
    resource.host.name
    collector-host-1
  2. Before

    body
    sender set host.name itself
    resource.service.name
    checkout
    resource.host.name
    app-host-7

    After

    body
    sender set host.name itself
    resource.service.name
    checkout
    resource.host.name
    app-host-7
    resource.deployment.environment.name
    production
    resource.service.namespace
    shop

The gotcha

On a host where no cloud metadata endpoint answers, each cloud detector waits for its timeout. In our test the detection took the full 2 s timeout once per pipeline, so this three-pipeline collector started about 6 s late. Keep the timeout short and list only the clouds you run on.

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: Processors