Sorgenti log

Ogni comando accetta una o più sorgenti. Se non ne specifichi alcuna, lo strumento prova caddy-analyzer.json → pipe → rilevamento automatico. Di seguito: come connettersi a ogni sorgente e quali permessi richiede. Per la configurazione dello strumento (file di configurazione, ottimizzazione, ambiente), consulta Guida → Configurazione.

File e glob

caddy-analyze /var/log/caddy/access.log
caddy-analyze /var/log/caddy/*.log
caddy-analyze /var/log/caddy/access.log.1 /var/log/caddy/access.log.2.gz
# no args → tries ./access.log, ./caddy.log, ./caddy-access.log, /var/log/caddy/access.log, /var/log/caddy/caddy.log
caddy-analyze

Permessi per i file

Caddy spesso scrive come caddy:caddy 0600. Devi poter leggere il file ed eseguire nella directory.

sudo caddy-analyze /var/log/caddy/access.log
# persistent — add yourself to the group then re-login:
sudo usermod -aG caddy $USER

Stdin — -

cat /var/log/caddy/access.log | caddy-analyze -
zcat /var/log/caddy/access.log.*.gz | caddy-analyze - --detect -f json -o out.json
ssh app@prod "cat /var/log/caddy/access.log" | caddy-analyze - -t 25

Permessi per stdin

Nessuno sul lato locale. Il lato remoto richiede l'accesso in lettura come sopra, oltre all'accesso SSH. Stdin viene rilevato automaticamente anche quando i dati sono passati tramite pipe e non è fornito alcun argomento sorgente.

Docker — docker://<name|id>

caddy-analyze docker://caddy
caddy-analyze docker://a3f9c1e2d4b5
caddy-analyze tail docker://caddy          # live
caddy-analyze --follow docker://caddy      # same via root flag

In un terminale interattivo segue con docker logs -f <container>; nelle letture non interattive aggiunge --tail=all. In entrambi i casi unisce stdout e stderr.

Permessi per Docker

# docker.sock is root:docker 0660 by default
sudo usermod -aG docker $USER  # re-login
# or
sudo caddy-analyze docker://caddy
# if Caddy runs in Docker but guard must block host:
sudo caddy-analyze guard --firewall-backend hybrid docker://caddy

Kubernetes — k8s://<pod>

caddy-analyze k8s://caddy-7d9f8c9d4-abc12
caddy-analyze k8s://caddy-7d9f8c9d4-abc12 -n production
caddy-analyze tail k8s://caddy-7d9f8c9d4-abc12 -n prod --detect

Legge tramite kubectl logs --tail=-1 --follow -n <ns> <pod> usando il tuo contesto kubectl attivo.

Permessi per Kubernetes

kubectl auth can-i get pods/log -n production  # should be yes
kubectl config current-context
kubectl get pods -n production | grep caddy

Lo spazio dei nomi può essere anche persistito: caddy-analyze config k8s://caddy-xxx -n production (consulta Configurazione).

journalctl — journalctl://<unit>

caddy-analyze journalctl://caddy.service
caddy-analyze tail journalctl://caddy.service
caddy-analyze journalctl://caddy.service --follow

Legge tramite journalctl -u <unit> --output=cat [--follow].

Permessi per journalctl

sudo usermod -aG systemd-journal $USER  # re-login
# or
sudo caddy-analyze journalctl://caddy.service

Rilevamento automatico (nessun argomento sorgente)

Quando esegui caddy-analyze senza file/URI né pipe, prova nell'ordine:

1. caddy-analyzer.json (locale, poi globale — Configurazione)
2. pipe stdin se i dati sono passati tramite pipe
3. 5 candidati: ./access.log, ./caddy.log, ./caddy-access.log, /var/log/caddy/access.log, /var/log/caddy/caddy.log

caddy-analyze config /var/log/caddy/access.log  # remember for next time
caddy-analyze --detect                # now works with no arg

Fixture — prova senza un server

Il repository include due fixture deterministici in testdata/ (rigenera con python3 testdata/generate.py). Tutti gli IP sono TEST-NET RFC 5737.

caddy-analyze --detect testdata/sample.log
caddy-analyze tail -d testdata/sample.log
caddy-analyze -f html -o report.html --detect testdata/sample.log && open report.html
caddy-analyze diff testdata/sample.log testdata/large.log

↑