vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Activity

otel: agents reach their hive's collector by a swarm-wide name

Browse source 
Agents are handed `http://hive-collector.<swarm domain>:<port>` as their
otel endpoint instead of `http://<bridge IP>:<port>`. Every hive running
its collector contributes the name to `gateway.localNames`, so its own
dnsmasq answers it with its bridge IP, the way the queue's name already
works. The rendered meta flake then carries no hive-specific address,
which a swarm-level render needs (#4857, operator ruling 100744: "b").

hive-c0re's own exporter keeps the bridge address: on the host the name
may resolve to loopback through `gateway.localHostsEntry`, where the
receiver does not listen.

The name sits under the swarm domain and starts with `hive`, a fragment
no hive name may contain, so no hive's default domain can take it.
This commit is contained in:
atlas 2026-10-16 02:26:04 +02:00 • committed by mara
commit d4e20803ec
6 changed files with 58 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

7
docs/networking/network.md
View file

@ -116,9 +116,10 @@ schemes pick their own.
dnsmasq is **authoritative** for the hive's own zone (`<hive-domain>`)
plus whatever swarm-service names this host contributes via
`gateway.localNames` — `forge.<swarm-domain>` and `chat.<swarm-domain>`
(matrix) when this host runs those services, and `auth.<swarm-domain>`
when it runs authelia — answering each with the bridge IP (where nginx
is reachable). Note forge and matrix are swarm-domain names, not
(matrix) when this host runs those services, `auth.<swarm-domain>`
when it runs authelia, and `hive-collector.<swarm-domain>` on every hive
with `otel.enable` — answering each with the bridge IP (where nginx
is reachable, and where the hive's own collector listens). Note forge and matrix are swarm-domain names, not
sub-domains of `<hive-domain>`: a swarm runs one forge and one
homeserver, so their names belong to the swarm rather than to whichever
hive happens to host them. dnsmasq forwards everything else to the host's

6
docs/scheduler/observability.md
View file

@ -42,8 +42,10 @@ destination in its own right. With both, telemetry goes to both. See
**Telemetry leaves a hive exactly one way: through the collector that
`enable` starts on the host.** Agents never talk to `endpoint` themselves —
they export unauthenticated to a bridge address only their own containers can
reach (`http://<bridgeIp>:<collector port>`; the otel module opens that port
on the bridge itself). That collector forwards to the swarm's
reach. They dial it as `http://hive-collector.<swarm domain>:<collector port>`,
a name identical on every hive, which each hive's own dnsmasq
answers with its bridge IP, so an agent's build carries no hive-specific
address. The otel module opens that port on the bridge itself. That collector forwards to the swarm's
([`swarm/services.md`](../swarm/services.md#telemetry-collector-otel)), the
single process holding the upstream credential and the only writer to the
swarm's stores. No agent holds a copy, and neither does the hive.