Collector

A collector is an OpenTelemetry runtime running on a host you operate. LinkMesh enrols it, delivers config to it, and watches its health.

Each collector owns:

• A set of active sources
• A set of routes wiring those sources through pipelines to destinations
• Health metrics flowing back to the server

The runtime is upstream

A collector runs one of two upstream runtimes — LinkMesh ships no collector distribution of its own. The runtime you pick determines how the collector receives its config from the LinkMesh server; see Add a collector for the onboarding flow:

• Grafana Alloy — config via remotecfg (the collector polls the LinkMesh server over Bearer-authenticated HTTPS and applies the config it fetches).
• otelcol-contrib + opampsupervisor — config via OpAMP (the LinkMesh server pushes remote config over WebSocket Secure and the supervisor applies it).

You install upstream Alloy or otelcol-contrib yourself and connect it directly; either way the component set is whatever the upstream runtime ships — Alloy’s full component catalogue, or otelcol-contrib’s.

Note

The optional linkmesh-agent is a separate onboarding helper, not part of the collector. It discovers services and log sources to pre-fill the onboarding wizard; it does not install, supervise, or configure the collector, and the collector runs fine without it.

What about Collector Groups

A Collector Group is a set of collectors sharing one config — used for redundancy or scale-out. Group-scoped sources, routes, and destinations materialise on every member at config-generation time, so a fleet stays in lockstep without copy-pasting per collector. See Manage collector groups for the step-by-step.

Versions and upgrades

LinkMesh records the version each collector runs and compares it to the version it has validated for that runtime. On the collectors list and each detail page you’ll see one of:

• Update available — a newer validated version exists (informational).
• Unvalidated — the collector runs a version LinkMesh hasn’t tested. Re-pin to a validated version; untested versions risk a supervisor/collector mismatch.

How an upgrade is carried out depends on the runtime:

• Alloy (remotecfg) collectors with a co-located agent are upgraded in place — the agent swaps the binary, health-checks it, and rolls back automatically if it’s unhealthy. Config is untouched.
• OpenTelemetry Collector (OpAMP) collectors are upgraded by re-running the installer pinned to the validated version, since the upstream supervisor doesn’t accept remote binary updates.

See Upgrade collectors for the steps.