Alloy is delivering ~1.5% of the host journal

[Gerrrt]

Found while verifying #188, and not caused by it.

Alloy's loki.source.journal is delivering roughly 1.5% of what the host
journal produces.

Measured on prometheus on 2026-08-31:

host, journalctl --since -5min          561 entries   (~112/min)
Loki,  {job="/var/log/journal"}            6 entries   (~1.2/min)
loki_source_journal_target_lines_total    30 in ~10 min

What the host is actually writing in that window:

entries	unit
247	kernel
113	systemd-networkd.service
77	init.scope
76	containerd.service
43	docker.service

Almost none of it arrives.

It is not the capability change, and not the mount

• Before fix(observability): take every capability off Alloy (#188) #192: 82 lines/hr. After: 97 lines/hr. Unchanged.
• journald is writing to the store Alloy reads — journalctl --header shows the
  active file under /var/log/journal/, and from inside the container two
  journal files were modified in the last 5 minutes.
• discovery.relabel "journal" has no drop rules, only four label mappings, and
  loki.source.journal forwards straight to loki.write.grafana_loki without
  passing through loki.process.log_processor. So nothing in the config is
  obviously filtering it.

Why this matters

It is the #62 shape: the component is healthy, the dashboard has data, the
target is up, and the agent is reporting a small fraction of reality. Nothing
would tell you. docs/observability.md lists the journal as a collected source
without qualification, and the Logs dashboard will show journal lines — just
almost none of them.

There is also a second store on this host, /run/log/journal, which Alloy does
not mount. It does not appear to be the active one, but it should be ruled in or
out properly rather than by inspection.

Worth checking

• max_age = "24h0m0s" and the saved position in alloy-data — is the reader
  stuck behind a checkpoint rather than tailing?
• Whether the reader needs CAP_SYSLOG or a group beyond the one fix(observability): take every capability off Alloy (#188) #192 added
  (though it reads the files directly, and those are root-owned, so it should
  not).
• Whether Alloy's journal reader is filtering by priority somewhere not obvious
  from config.alloy.
• Whether the count method is comparing like with like — journalctl output
  lines versus Loki entries — before concluding the gap is real at this size.

Done when

• The gap is explained, and either fixed or written down as intended
• If the journal is genuinely under-collected, something detects it — a
  quiet source and a broken one currently look identical, which is the
  complaint Detect Suricata being dead — a quiet IDS and a stopped one look identical #90 makes about Suricata