Native remote config

LinkMesh-managed collectors fetch their configuration directly from the LinkMesh server using the collector’s native remote-config protocol — no proprietary middleware in between. Two protocols are supported, one per collector runtime:

• Grafana Alloy uses its built-in remotecfg component (HTTP poll over Connect-RPC, production-ready since Alloy 1.0).
• otelcol-contrib uses OpAMP over WebSocket via the bundled opampsupervisor.

Both paths fetch config straight from your LinkMesh server, apply it, and reload — no LinkMesh-specific code runs on the host’s data plane. This is the default install model: the collector is upstream and stays upstream, LinkMesh stays in the control plane.

Why this matters

A few practical consequences operators care about:

• No proprietary patches. You install whatever Alloy or otelcol-contrib version your security/compliance team blessed, straight from Grafana’s or OpenTelemetry’s official repos. LinkMesh doesn’t fork either.
• Standard observability. Alloy’s own prometheus.exporter.self and otelcol-contrib’s service.telemetry work normally. Your existing dashboards keep working; LinkMesh adds its own per-component throughput on top without replacing yours.
• No middleware to fail. Config flows directly between the collector and the LinkMesh server — Alloy polls via remotecfg, otelcol-contrib receives pushes via OpAMP. There’s no LinkMesh process sitting in the config path that could fail and cut the collector off; if the server is briefly unreachable, the collector keeps running with its last-applied config.

How it works

1. The host installs Alloy (or otelcol-contrib) from upstream repos — either directly from Grafana/OpenTelemetry’s package archives, or from LinkMesh’s air-gap mirror if the host can’t reach the public internet.
2. The collector is enrolled with a small bootstrap config that points it at your LinkMesh server — for Alloy a config.alloy with a remotecfg block, for otelcol-contrib the OpAMP supervisor’s supervisor.yaml. Both carry the server URL and the per-collector bearer token.
3. The collector then fetches its real pipeline configuration directly from the LinkMesh server over its native remote-config protocol — Alloy polls via remotecfg, otelcol-contrib receives a push via OpAMP. There’s no LinkMesh-specific middleware in the loop.
4. Subsequent edits in the LinkMesh UI propagate via the same channel — Alloy notices the new config hash on its next poll, fetches the new body, applies + reloads atomically; otelcol-contrib’s supervisor receives the new RemoteConfig over OpAMP and restarts the collector with it. Alloy’s default poll cadence is 60 seconds; an unchanged config returns not_modified so the poll costs effectively nothing.
5. The collector also pushes its own internal metrics (Alloy’s prometheus.exporter.self, otelcol-contrib’s otelcol_* metrics) to LinkMesh via standard OTLP. This is what powers the per-component throughput numbers on the topology canvas — same data the collector exposes locally, just shipped to the right place.

The bootstrap config

Each runtime is enrolled with a single, small bootstrap config file — typically /etc/alloy/config.alloy for Alloy or the OpAMP supervisor’s supervisor.yaml for otelcol-contrib.

The bootstrap has no customer pipelines in it. It only enables two things:

• A remote-config component pointing at your LinkMesh server (URL + per-collector bearer token).
• A self-telemetry exporter pointing at LinkMesh’s OTLP receiver with the same bearer.

The pipelines you build in the LinkMesh UI arrive over the native remote-config channel after the collector starts. The bootstrap itself never changes unless you rotate the bearer or move the LinkMesh server.

Editing the bootstrap

The bootstrap file starts with a // linkmesh-bootstrap comment that marks it as machine-managed so it can be safely regenerated on re-enrollment. If you want to take over the collector’s config manually — say, to pin a receiver block the LinkMesh UI doesn’t yet model — remove that comment line and the file is left alone from then on.

Air-gapped installs

For fleets that can’t reach apt.grafana.com / rpm.grafana.com directly, host the packages on your own internal mirror and install the runtime from there. Point your apt/yum sources at your mirror URL instead of the upstream default and proceed with a normal apt install / yum install:

# apt-family: write a sources.list snippet against your mirror
echo "deb https://<your-internal-mirror>/grafana stable main" \
  | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt update && sudo apt install alloy

Use whatever mirroring tool you already operate (Artifactory, Nexus, JFrog, a hand-rolled nginx proxy_cache against apt.grafana.com) — LinkMesh has no opinion on the mirror runtime, only that it serves bit-for-bit identical packages so the upstream Grafana signing key still verifies.

The same applies on the YUM/DNF path for RHEL-family hosts — write /etc/yum.repos.d/grafana.repo against https://<your-internal-mirror>/grafana and install from there. Follow the standard Grafana installation guides, substituting your internal mirror URL for the public archives.

Verifying the loop

After install, on the host:

# Alloy: confirm remote_cfg is configured + polling
sudo journalctl -u alloy -n 50 | grep -i remotecfg
# Expected: "remote configuration fetched, hash=… not_modified=false"

# otelcol-contrib: confirm the OpAMP supervisor is connected
sudo journalctl -u otelcol-contrib -n 50 | grep -i opamp
# Expected: "OpAMP connection established"

In the LinkMesh UI:

• The collector shows up in Collectors with status Online.
• The collector’s Events tab lists remotecfg_registered (Alloy) or registered (OpAMP) within a few seconds of install.
• Open any pipeline that’s wired to this collector — the topology canvas shows per-edge throughput numbers within ~60s of the first data point.

If any of those don’t happen, see Self-telemetry troubleshooting.

See also

• How the edge talks to the server — the full picture of every channel between a collector and LinkMesh
• Enrollment tokens — the credential a collector presents when it fetches its config
• Onboard Grafana Alloy (remotecfg) and Onboard otelcol-contrib (OpAMP) — the two protocols above, applied end to end

Further reading

• GitOps for OpenTelemetry collector config — why managing collector configuration as versioned, reviewed source pairs naturally with the native remote-config delivery described here.