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

otel: finish the agent collector name in option and network docs

Browse source 
The otel enable description and the exposeHostPorts example in network.md
still described agents dialing a bridge address. Rewrap the two long lines
the earlier edit left.
This commit is contained in:
atlas 2026-10-16 02:36:33 +02:00 • committed by mara
commit b66a09f65b
3 changed files with 18 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

14
docs/networking/network.md
View file

@ -119,10 +119,10 @@ plus whatever swarm-service names this host contributes via
(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
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
own resolvers: it runs on the host and reads the host's
`/etc/resolv.conf` directly. Containers don't need to know the
upstream — they query the bridge IP and dnsmasq does the right thing
@ -188,8 +188,10 @@ that `otel.endpoint` is the _upstream_, which no agent ever dials. See
`services.hyperhive.network.exposeHostPorts = [ 4318 ];` opens each
listed TCP port `P` on the bridge-interface `allowedTCPPorts`, so an
agent can connect to `<bridgeIp>:P` (point the collector endpoint at
`http://<bridgeIp>:4318`, default `http://10.42.0.1:4318`).
agent can connect to `<bridgeIp>:P` (for a dev OTLP collector, point its
endpoint at `http://<bridgeIp>:4318`, default `http://10.42.0.1:4318`).
The hive's own collector needs none of this: agents dial it by
`otel.collector.host`.
<!-- vale write-good.Passive = NO -->

11
docs/scheduler/observability.md
View file

@ -41,11 +41,12 @@ 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. 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
they export unauthenticated to a collector address only their own containers
can 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.