Tech Handbook Null Yard

Logi, monitoring i troubleshooting

Troubleshooting zaczyna się od obserwacji, nie od zmian konfiguracji. Logi mówią, co wydarzyło się w systemie, monitoring pokazuje stan i trendy, a alerty powinny wskazywać sytuacje wymagające reakcji.

Powiązane tematy: Troubleshooting aplikacji webowej end-to-end, systemd, cron i schedulery, HTTP, HTTPS i TLS oraz Docker.

1. Zasada

Nie zgaduj. Zbieraj fakty.

Typowa kolejność:

objaw
 ↓
status usługi
 ↓
logi
 ↓
porty
 ↓
sieć
 ↓
konfiguracja
 ↓
zasoby

2. systemctl

systemctl status nginx
systemctl status myapp

3. journalctl

Usługa:

journalctl -u myapp

Od bieżącego bootu:

journalctl -u myapp -b

Na żywo:

journalctl -u myapp -f

Ostatnie 100:

journalctl -u myapp -n 100

4. Pliki logów

/var/log/

Przykłady:

/var/log/nginx/access.log
/var/log/nginx/error.log

5. tail

tail -f /var/log/nginx/error.log

6. grep

grep ERROR app.log
grep -i timeout app.log

Kontekst:

grep -C 3 ERROR app.log

7. CPU i RAM

top
htop
free -h

8. Dysk

df -h
du -sh *

Największe katalogi:

sudo du -xhd1 / | sort -h

9. Inodes

Dysk może mieć wolne GB, ale brak inode:

df -i

10. Procesy

ps aux
pgrep nginx
pgrep -af myapp

11. Porty

ss -lntup

12. lsof

sudo lsof -i :443
sudo lsof /path/to/file

13. Test localhost

curl -v http://127.0.0.1:8080/health

Jeśli localhost działa, szukaj dalej w proxy/firewall/DNS.

14. Health endpoint

Dobry backend może mieć:

GET /health

odpowiadający:

{"status":"ok"}

15. Docker logs

docker logs CONTAINER
docker logs -f CONTAINER
docker logs --tail 100 CONTAINER

Compose:

docker compose logs -f

16. dmesg

Problemy kernela/sprzętu:

dmesg
dmesg -T

17. uptime i load

uptime

Load average to nie to samo co procent CPU.

18. iostat

Po instalacji sysstat:

iostat -xz 1

Pomaga diagnozować problem z I/O.

19. vmstat

vmstat 1

20. Sieć

ping
dig
curl
nc
ss
traceroute
tcpdump

21. Schemat diagnozy 502

  1. nginx działa?
systemctl status nginx
  1. backend działa?
systemctl status myapp
  1. backend słucha?
ss -lntp
  1. działa lokalnie?
curl http://127.0.0.1:8080
  1. nginx error log:
tail -f /var/log/nginx/error.log

22. Schemat diagnozy „strona nie działa”

  1. DNS,
  2. port 443,
  3. certyfikat,
  4. nginx,
  5. backend,
  6. baza,
  7. zasoby.

23. Monitoring

Minimum: - uptime, - CPU, - RAM, - disk, - health endpoint, - status kontenerów/usług, - ważne błędy w logach.

24. Alerty

Alert powinien mówić: - co nie działa, - gdzie, - od kiedy, - jaka jest metryka, - najlepiej link do dashboardu/logów.

25. Nie alertuj wszystkiego

Zbyt wiele alertów powoduje ignorowanie wszystkich.

Alert powinien odpowiadać na problem wymagający reakcji.

26. Rotacja logów

Logi muszą mieć rotację.

Linux często używa logrotate lub journald retention.

27. Co trzeba umieć

  • czytać journalctl,
  • znaleźć proces i port,
  • ocenić CPU/RAM/dysk,
  • diagnozować 502,
  • odróżnić problem aplikacji od proxy/sieci,
  • tworzyć prosty healthcheck.

Oficjalne źródła

  • systemd journalctl: https://www.freedesktop.org/software/systemd/man/latest/journalctl.html
  • OpenTelemetry documentation: https://opentelemetry.io/docs/