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

swarm-otel's own logs go only to the store, so an upstream export failure no longer feeds itself

Browse source 
The logs/self pipeline shipped the collector's own journal to the upstream
exporter too. When the upstream failed, the collector logged the failure,
journald/self read it, and logs/self sent it upstream again: ~8 lines/s.

logs/self now exports only to otlphttp/victorialogs, and a filter processor
drops the collector's failure lines that name that exporter, so the store
exporter cannot rebuild the loop one hop later. Other collector lines,
including upstream failures, still reach the store.

On deploy, swarm-otel's store rows drop from ~8/s of error spam to its real
output.
This commit is contained in:
atlas 2026-10-20 00:13:25 +02:00 • committed by mara
commit 8d70afd93e
3 changed files with 52 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

7
docs/swarm/services.md
View file

@ -351,7 +351,12 @@ authelia, forge and homeserver have a forwarder client of their own
The swarm collector's own container, `swarm-otel`, has no forwarder: its
collector reads the container's journal itself (receiver `journald/self`) and
exports it to the log store like the host's journal, stamped `service.name`
`swarm-otel` and with no `hive` label. The container mounts the host's journal
`swarm-otel` and with no `hive` label. Unlike the host's journal, it goes to the
log store only, never the upstream: the collector writes an upstream export failure to this
journal, and shipping it upstream would fail again. A `filter` processor also
drops the collector's own failure lines that name the store exporter
(`otlphttp/victorialogs`), which can't reach the store anyway; failures of
every other exporter still arrive. The container mounts the host's journal
read-only at `/run/host-journal`, not over its own
`/var/log/journal`.