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.
• Smaller blast radius on agent upgrades. The agent (the host-side control plane that does install/lifecycle management) is a much smaller surface than a collector + agent combo. If the agent fails, 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. linkmesh-agent is installed alongside — it handles enrollment, writes a small bootstrap config that points the collector at your LinkMesh server, and supervises lifecycle (start, restart, upgrade).
3. The collector reads the bootstrap config, then polls the LinkMesh server directly for its real pipeline configuration over its native remote-config protocol. There’s no LinkMesh-specific gRPC in the loop.
4. Subsequent edits in the LinkMesh UI propagate via the same poll — Alloy notices the new config hash, fetches the new body, applies + reloads atomically. Default 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

linkmesh-agent writes a single, small bootstrap config file when it first sets up the collector — 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 via the remote-config poll 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 so the agent knows it can safely overwrite the file on upgrades. 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. The agent will leave the file 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 point the agent at it:

linkmesh-agent install alloy --mirror=https://<your-internal-mirror>/grafana

The agent writes the appropriate apt/yum sources.list snippet using your mirror URL instead of the upstream default and proceeds with a normal apt install / yum install. 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 flag works for the YUM/DNF path on RHEL-family hosts — point at https://<your-internal-mirror>/grafana and the agent writes /etc/yum.repos.d/grafana.repo against your URL.

For collectors that don’t use the LinkMesh agent (Standards path), operators configure apt.grafana.com / rpm.grafana.com directly, or substitute their internal mirror URL by hand using the standard Grafana installation guides.

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.