Container İzleme ve Loglama: docker stats’tan Prometheus + Grafana’ya

Bir uygulamayı production’a taşımak işin sadece yarısıdır — asıl mesele, orada sağlıklı çalıştığından emin olmak ve bir şeyler ters gittiğinde bunu hızlıca fark edebilmektir. Bu yazıda, tek container’da docker stats ile başlayıp, ölçeklenebilir bir izleme (monitoring) kurulumuna, Prometheus ve Grafana’ya kadar ilerliyoruz.

En basit hali: docker stats ve docker logs

Küçük kurulumlarda, container’ların anlık kaynak kullanımını görmek için yerleşik komutlar yeterlidir:

# Tüm çalışan container'ların CPU/RAM/ağ kullanımını canlı izle
docker stats

# Belirli bir container'ın loglarını canlı takip et
docker logs -f --tail 100 benim-api

# Son 1 saatteki logları göster
docker logs --since 1h benim-api

Bu yaklaşımın sınırı bellidir: bir sunucuda birkaç container varken işe yarar, ama onlarca container ve birden fazla sunucu olduğunda terminalde tek tek bakmak sürdürülemez hale gelir.

Health check: bir container’ın gerçekten sağlıklı olduğunu bilmek

Bir container’ın “çalışıyor” (running) durumda olması, içindeki uygulamanın sağlıklı olduğu anlamına gelmez — process ayakta olabilir ama uygulama takılmış (hang) olabilir. HEALTHCHECK talimatı, Docker’a periyodik olarak bir kontrol komutu çalıştırmasını söyler:

# Dockerfile içinde
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost:3000/saglik || exit 1

# Container'ın sağlık durumunu gör
docker ps   # STATUS sütununda "healthy" / "unhealthy" görünür
docker inspect --format='{{.State.Health.Status}}' benim-api

Orkestratörler (Kubernetes, Swarm) bu health check’i kullanarak “unhealthy” duruma düşen container’ları otomatik olarak yeniden başlatabilir veya trafiği o kopyadan uzaklaştırabilir.

Ölçeklenebilir izleme: Prometheus + Grafana

Birden fazla sunucu ve onlarca container olduğunda, standart yaklaşım Prometheus (metrik toplama ve saklama) ile Grafana‘yı (görselleştirme ve alarm) bir arada kullanmaktır. Docker container’larının metriklerini toplamak için genellikle cAdvisor araya girer:

services:
  cadvisor:
    image: gcr.io/cadvisor/cadvisor:v0.49.1
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
    ports:
      - "8081:8080"

  prometheus:
    image: prom/prometheus:v2.53.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:11.1.0
    ports:
      - "3001:3000"

Bu üçlü şu akışla çalışır: cAdvisor her container’ın CPU, bellek, ağ ve disk metriklerini toplar → Prometheus bu metrikleri düzenli aralıklarla çekip zaman serisi veritabanında saklar → Grafana bu veriyi okuyup grafiklere ve panolara (dashboard) dönüştürür, eşik aşıldığında (örneğin CPU %90’ı geçtiğinde) alarm gönderir.

Merkezi loglama: dağınık logları tek yerde toplamak

Birden fazla sunucuda çalışan container’ların loglarını tek tek docker logs ile takip etmek pratik değildir. Docker’ın logging driver mekanizması, log çıktısını doğrudan merkezi bir sisteme yönlendirmenizi sağlar:

# Container loglarını doğrudan bir syslog sunucusuna yönlendir
docker run -d --log-driver syslog \
  --log-opt syslog-address=udp://log-sunucusu:514 \
  benim-api:1.0

Daha büyük kurulumlarda genellikle Grafana Loki, Elastic Stack (ELK) veya bulut sağlayıcının kendi log servisi (CloudWatch Logs, Google Cloud Logging gibi) tercih edilir — bu araçlar logları aranabilir, filtrelenebilir hale getirir ve genellikle aynı Grafana panosunda metriklerle yan yana gösterilebilir.

Basitten karmaşığa: hangi seviyede kalmalı?

Ölçek	Önerilen yaklaşım
Tek sunucu, birkaç container	docker stats + docker logs + HEALTHCHECK yeterli
Birkaç sunucu, orta ölçek	cAdvisor + Prometheus + Grafana; merkezi log toplama
Kubernetes kümesi	Prometheus Operator + Grafana (kube-prometheus-stack), liveness/readiness probe’lar

Sağlıklı çalıştığından emin olduğunuz production ortamınızı, farklı donanım mimarilerinde (Intel/AMD sunuculardan ARM tabanlı bulut örneklerine) de aynı imajla çalıştırmak isteyebilirsiniz — bunu bir sonraki yazıda, multi-arch build başlığı altında ele alıyoruz.