feat(monitoring): access logging on the monitoring Caddy (real client IPs, #100) #156
Inga granskare
Etiketter
Inga etiketter
area/backups
area/ci
area/control-panel
area/identity
area/infra
area/observability
area/payments
area/security
area/storage
area/web
blocked
needs-info
needs-triage
ready-for-implementation
type
bug
type
chore
type
docs
type
epic
type
feature
type
task
wontfix
Ingen milstolpe
Inget projekt
Inga tilldelade
1 deltagare
Notiser
Förfallodatum
Inget förfallodatum satt.
Beroenden
Inga beroenden satta
Referens
bitborg/bitborg-infra!156
Läser in…
Hänvisa till i nytt ärende
Ingen beskrivning angiven.
Ta bort grenen "fix/100-monitoring-caddy-access-log"
Borttagning av en gren är permanent. Även om den borttagna grenen kan fortsätta existera en kort tid innan den faktiskt tas bort, kan det INTE ångras i de flesta fall. Vill du fortsätta?
Follow-up to #154 (#100 socket activation). The monitoring Caddy had no access-log directive, so real client IPs — now that socket activation delivers them — weren't observable, and the "access logs" the issue referenced didn't actually exist.
Change
Add an
(access_log)snippet (JSON → stdout → container log → Loki) and import it in all three hosts (grafana/stats/ntfy).Verified live
Applied
--tags monitoring(clean restart — the socket already owns 80/443, noEADDRINUSE). Three external probes from a known public IP produced:plus other genuine external clients (
155.4.244.250,185.213.154.181) — and zero pasta10.xbridge addresses inremote_ip. That's the literal confirmation that #100's socket activation delivers real client IPs; request attribution + GoatCounter analytics are now correct.Refs #100.