GCP Cloud Logging ile Log Yönetimi

Tarafındankomut
0 Comments

Üretim ortamında bir sorun çıktığında, ilk içgüdün logları karıştırmak olur. Ama loglar dağınık, format tutarsız ya da hiç toplanmıyorsa, o kritik anında kör uçuş yaparsın. GCP Cloud Logging, Google’ın bu problemi çözmek için sunduğu merkezi log yönetim platformu. Sadece bir log görüntüleyici değil; toplama, filtreleme, yönlendirme, arşivleme ve alarm üretme konularında uçtan uca bir çözüm. Bu yazıda, Cloud Logging’i gerçekten nasıl kullanman gerektiğini, hangi tuzaklardan kaçınman gerektiğini ve üretime hazır bir log altyapısını nasıl kuracağını detaylıca ele alacağız.

Cloud Logging Nedir ve Neden Önemlidir?

GCP’de çalışan her servis, varsayılan olarak loglarını Cloud Logging’e gönderir. Compute Engine instance’ların, GKE pod’ların, Cloud Functions’ların, Cloud Run servislerinin hepsi buraya bağlıdır. Buna otomatik log entegrasyonu deniyor ve bu gerçekten büyük bir kolaylık sağlıyor.

Ama mesele sırf log toplamaktan ibaret değil. Gerçek sysadmin işi şunları kapsar:

  • Log’ların nereye gittiğini kontrol etmek (sink yönetimi)
  • Gereksiz logları filtreleyerek maliyet düşürmek
  • Log tabanlı metrik ve alarm oluşturmak
  • Uyumluluk ve audit gereksinimleri için log arşivlemek
  • Uygulama loglarını yapılandırılmış (structured) formata çekmek

Cloud Logging’in temel bileşenlerini şöyle özetleyebilirim:

  • Log Explorer: Web tabanlı log sorgulama arayüzü
  • Log Sinks: Logları farklı hedeflere yönlendiren kurallar
  • Log Buckets: Logların saklandığı depolama birimleri
  • Log Router: Gelen logları kurallara göre yönlendiren motor
  • Log-Based Metrics: Log verilerinden türetilen metrikler

gcloud CLI ile Cloud Logging’e Başlamak

Her şeyden önce, gcloud CLI kurulu ve authenticate edilmiş olmalı. Log yönetimi işlemlerinin büyük çoğunluğunu terminal üzerinden yapacağız çünkü GUI’de tıklamak her seferinde aynı şeyi yapmak zorunda kaldığında çok yorucu olur.

# Mevcut projedeki log listesini çek
gcloud logging logs list

# Belirli bir servisin loglarını oku (son 1 saatin logları)
gcloud logging read "resource.type=gce_instance" 
  --freshness=1h 
  --project=my-production-project

# Spesifik bir instance'ın ERROR loglarını filtrele
gcloud logging read 
  'resource.type="gce_instance" AND severity>=ERROR AND resource.labels.instance_id="1234567890"' 
  --freshness=2h 
  --limit=50 
  --format=json

--freshness parametresi zaman aralığını belirtir, 1h, 6h, 1d gibi değerler alabilir. --limit ise kaç log satırı döneceğini kontrol eder. Production ortamında --limit olmadan sorgu çalıştırmak istemezsin, bazen yüz binlerce kayıt dönebilir.

Yapılandırılmış Log Yazmak

Uygulama loglarınızı düz metin olarak mı yazıyorsunuz? Lütfen durdurun. Yapılandırılmış (structured) loglar, Cloud Logging’in arama ve filtreleme özelliklerinden tam anlamıyla yararlanmanızı sağlar.

# Python uygulamasından structured log gönderme örneği
# (Cloud Logging client library kullanarak)
cat > /opt/myapp/logger_example.py << 'EOF'
import google.cloud.logging
import logging
import json

client = google.cloud.logging.Client()
client.setup_logging()

# Bu şekilde structured log yazabilirsiniz
logging.info("User login successful", extra={
    "json_fields": {
        "user_id": "usr_12345",
        "ip_address": "192.168.1.100",
        "auth_method": "oauth2",
        "session_duration": 3600
    }
})
EOF

Eğer Python değil de shell script’lerden log atmanız gerekiyorsa, gcloud logging write komutunu kullanabilirsiniz:

# Shell script içinden structured log yazma
gcloud logging write my-app-log 
  '{"user_id": "usr_12345", "action": "file_upload", "file_size_mb": 150, "status": "success"}' 
  --severity=INFO 
  --payload-type=json 
  --project=my-production-project

# Basit text log yazma
gcloud logging write my-app-log 
  "Backup tamamlandi: $(date '+%Y-%m-%d %H:%M:%S')" 
  --severity=INFO

Log Sink’leri Yönetmek

Log sink’leri, Cloud Logging’in en kritik özelliklerinden biridir. Gelen logları BigQuery’ye, Cloud Storage’a, Pub/Sub’a ya da başka bir Cloud Logging bucket’ına yönlendirebilirsiniz.

Tipik bir senaryo: Audit loglarını compliance için Cloud Storage’a arşivleyin, uygulama hatalarını BigQuery’ye analiz için gönderin ve kritik alarmlar için Pub/Sub üzerinden notification pipeline kurun.

# Cloud Storage'a log sink oluşturma (audit logları için)
gcloud logging sinks create audit-logs-archive 
  storage.googleapis.com/my-audit-logs-bucket 
  --log-filter='logName:"cloudaudit.googleapis.com"' 
  --project=my-production-project

# BigQuery'ye log sink oluşturma (uygulama hataları için)
gcloud logging sinks create app-errors-bigquery 
  bigquery.googleapis.com/projects/my-production-project/datasets/app_logs 
  --log-filter='severity>=ERROR AND resource.type="gce_instance"' 
  --project=my-production-project

# Mevcut sink'leri listele
gcloud logging sinks list --project=my-production-project

# Sink detaylarını görüntüle
gcloud logging sinks describe audit-logs-archive --project=my-production-project

Sink oluşturduktan sonra mutlaka yapmanız gereken bir adım var: Sink’in kullandığı servis hesabına hedef kaynağa yazma yetkisi vermeniz gerekiyor. Bunu sık sık atlayan adminler olur ve sonra neden loglar gelmiyor diye saatlerce uğraşırlar.

# Sink'in servis hesabını öğren
SINK_SA=$(gcloud logging sinks describe audit-logs-archive 
  --project=my-production-project 
  --format='value(writerIdentity)')

echo "Sink service account: $SINK_SA"

# Cloud Storage bucket'a yazma yetkisi ver
gsutil iam ch ${SINK_SA}:objectCreator gs://my-audit-logs-bucket

Log Tabanlı Metrik ve Alarm Oluşturma

Cloud Logging sadece log depolamak için değil, loglardan metrik üretmek için de kullanılır. Bu özellik, özellikle uygulama seviyesindeki hataları izlemek için çok değerlidir.

Gerçek bir senaryo düşünelim: Production’da bir servisimizin belirli bir hata mesajı üretip üretmediğini izlemek istiyoruz. 5 dakika içinde 10’dan fazla bu hata görünürse alarm üretsin istiyoruz.

# Log tabanlı metrik oluşturma
gcloud logging metrics create payment-service-errors 
  --description="Payment service critical errors count" 
  --log-filter='resource.type="gce_instance" AND textPayload:"PAYMENT_FAILED" AND severity=ERROR' 
  --project=my-production-project

# Metrik listesini görüntüle
gcloud logging metrics list --project=my-production-project

# Metrik detayı
gcloud logging metrics describe payment-service-errors --project=my-production-project

Bu metriği oluşturduktan sonra Cloud Monitoring üzerinden alerting policy ekleyebilirsiniz. Ama log tabanlı metrik oluştururken şuna dikkat edin: Yüksek kardinaliteli label’lar kullanmaktan kaçının. Örneğin her request için unique bir ID’yi label olarak kullanırsanız, metrik sayısı patlar ve ciddi maliyet oluşur.

Log Exclusion ile Maliyet Optimizasyonu

Cloud Logging’in en can sıkıcı taraflarından biri maliyetidir. Özellikle yüksek trafikli sistemlerde, debug log’ları tutmak astronomik maliyetlere yol açabilir. Log exclusion kuralları ile gereksiz logları filtreleyip maliyetleri düşürebilirsiniz.

# Debug ve Info seviyeli GKE loglarını hariç tut
gcloud logging exclusions create exclude-gke-debug-logs 
  --description="GKE debug ve info loglarini filtrele" 
  --log-filter='resource.type="k8s_container" AND severity<=INFO' 
  --project=my-production-project

# Belirli bir namespace'in loglarını tamamen hariç tut
gcloud logging exclusions create exclude-monitoring-ns 
  --description="Monitoring namespace loglarini filtrele" 
  --log-filter='resource.type="k8s_container" AND resource.labels.namespace_name="monitoring"' 
  --project=my-production-project

# Mevcut exclusion'ları listele
gcloud logging exclusions list --project=my-production-project

# Exclusion'ı güncelle (disable et)
gcloud logging exclusions update exclude-gke-debug-logs 
  --disabled 
  --project=my-production-project

Exclusion kuralları yazarken dikkatli olun. Bir exclusion kuraldı hariç tutulan log, hiçbir sink’e gitmez ve geri getirilemez. Bu yüzden kritik olabilecek logları exclusion’a dahil etmeden önce iki kez düşünün.

Pratikte benim önerdiğim yaklaşım: Önce exclusion olmadan bir hafta çalışın ve hangi log tiplerinin en fazla hacim oluşturduğunu analiz edin. Sonra güvenle hariç tutulabilecekleri belirleyin.

Log Bucket Yönetimi ve Retention Politikaları

Varsayılan olarak Cloud Logging, logları _Default bucket’ında 30 gün tutar. Ama compliance gereksinimleriniz daha uzun saklama süreleri gerektirebilir ya da maliyet açısından bazı logları daha kısa süre tutmak isteyebilirsiniz.

# Özel log bucket oluşturma
gcloud logging buckets create long-term-logs 
  --location=europe-west1 
  --retention-days=365 
  --description="Compliance icin uzun donemli log saklama" 
  --project=my-production-project

# Mevcut bucket'ların listesi
gcloud logging buckets list --project=my-production-project

# Varsayılan bucket'ın retention süresini değiştirme
gcloud logging buckets update _Default 
  --location=global 
  --retention-days=60 
  --project=my-production-project

# Bucket detaylarını görüntüle
gcloud logging buckets describe long-term-logs 
  --location=europe-west1 
  --project=my-production-project

Bir log bucket’ı oluşturduktan sonra, bu bucket’a yönlendirecek sink’i de oluşturmanız gerekiyor:

# Özel bucket'a yönlendiren sink oluşturma
gcloud logging sinks create compliance-sink 
  logging.googleapis.com/projects/my-production-project/locations/europe-west1/buckets/long-term-logs 
  --log-filter='logName:"cloudaudit.googleapis.com" OR logName:"data_access"' 
  --project=my-production-project

Ops Agent ile VM Log Toplama

GCP’de Compute Engine instance’lar çalıştırıyorsanız ve uygulama loglarınızı otomatik olarak Cloud Logging’e göndermek istiyorsanız, Ops Agent kurmanız gerekiyor. Bu agent, hem metrik hem de log toplama işini yapıyor.

# Ops Agent kurulum scripti (Debian/Ubuntu için)
curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install

# Ops Agent durumunu kontrol et
sudo systemctl status google-cloud-ops-agent

# Ops Agent konfigürasyon dosyası
sudo cat /etc/google-cloud-ops-agent/config.yaml

Özel uygulama loglarınızı toplamak için Ops Agent’ı konfigüre etmeniz gerekiyor:

# Özel uygulama logu için Ops Agent konfigürasyonu
sudo cat > /etc/google-cloud-ops-agent/config.yaml << 'EOF'
logging:
  receivers:
    my-app-log:
      type: files
      include_paths:
        - /var/log/myapp/*.log
      record_log_file_path: true
  processors:
    my-app-log-json:
      type: parse_json
      field: message
      time_key: timestamp
      time_format: "%Y-%m-%dT%H:%M:%S%z"
  service:
    pipelines:
      my-app-pipeline:
        receivers: [my-app-log]
        processors: [my-app-log-json]
EOF

# Konfigürasyonu doğrula ve agent'ı yeniden başlat
sudo google-cloud-ops-agent-diagnostics
sudo systemctl restart google-cloud-ops-agent

Log Explorer’da Gelişmiş Sorgular

Cloud Logging’in web arayüzü olan Log Explorer, özellikle üretim sorunlarını araştırırken çok işe yarar. Ama CLI’dan da aynı sorguları çalıştırabilirsiniz. İyi bir log query dili bilgisi, sorun giderme sürenizi dramatik olarak kısaltır.

# Son 24 saatte kritik hataları olan instance'ları bul
gcloud logging read 
  'severity=CRITICAL AND timestamp>="2024-01-15T00:00:00Z"' 
  --freshness=24h 
  --project=my-production-project 
  --format="table(timestamp,resource.labels.instance_id,textPayload)"

# HTTP 5xx hatalarını filtrele (Cloud Run veya App Engine için)
gcloud logging read 
  'resource.type="cloud_run_revision" AND httpRequest.status>=500' 
  --freshness=6h 
  --project=my-production-project 
  --format=json | jq '.[] | {time: .timestamp, status: .httpRequest.status, url: .httpRequest.requestUrl}'

# Belirli bir kullanıcının audit loglarını çek
gcloud logging read 
  'logName="projects/my-production-project/logs/cloudaudit.googleapis.com%2Factivity" AND protoPayload.authenticationInfo.principalEmail="[email protected]"' 
  --freshness=7d 
  --project=my-production-project

Sorgu yazarken sık kullandığım birkaç ipucu:

  • timestamp filtresi her zaman kullanın, aksi takdirde çok büyük veri taranır
  • resource.type ile hedefleyen kaynağı daraltın
  • severity>=ERROR ile sadece hata ve üstü seviyeleri filtreleyin
  • String aramalarında =~ operatörü regex destekler

Gerçek Dünya Senaryosu: Güvenlik İncelemesi Pipeline’ı

Şimdi gerçek bir örnek kuralım: Başarısız SSH girişimlerini izleyen ve alarm üreten bir sistem.

#!/bin/bash
# security-monitoring-setup.sh

PROJECT_ID="my-production-project"
ALERT_EMAIL="[email protected]"

# 1. Failed SSH attempts için log tabanlı metrik oluştur
gcloud logging metrics create failed-ssh-attempts 
  --description="Failed SSH login attempts on GCE instances" 
  --log-filter='resource.type="gce_instance" AND logName:"syslog" AND textPayload:"Failed password" OR textPayload:"Invalid user"' 
  --project=$PROJECT_ID

echo "Log metric olusturuldu: failed-ssh-attempts"

# 2. Pub/Sub topic oluştur (alarm bildirimleri için)
gcloud pubsub topics create security-alerts 
  --project=$PROJECT_ID

# 3. Security eventleri için Pub/Sub sink oluştur
gcloud logging sinks create security-events-sink 
  pubsub.googleapis.com/projects/$PROJECT_ID/topics/security-alerts 
  --log-filter='resource.type="gce_instance" AND (textPayload:"Failed password" OR textPayload:"Invalid user" OR textPayload:"BREAK-IN ATTEMPT")' 
  --project=$PROJECT_ID

# 4. Sink service account'a Pub/Sub publisher yetkisi ver
SINK_SA=$(gcloud logging sinks describe security-events-sink 
  --project=$PROJECT_ID 
  --format='value(writerIdentity)')

gcloud pubsub topics add-iam-policy-binding security-alerts 
  --member=$SINK_SA 
  --role=roles/pubsub.publisher 
  --project=$PROJECT_ID

echo "Security monitoring pipeline kuruldu!"
echo "Pub/Sub topic: security-alerts"
echo "Log metric: failed-ssh-attempts"

Bu script’i çalıştırdıktan sonra, Cloud Monitoring’de bu metriğe dayalı bir alerting policy oluşturabilirsiniz. 5 dakika içinde 20’den fazla başarısız giriş denemesi varsa, güvenlik ekibine mail gönderilsin gibi kurallar kolayca tanımlanabilir.

Maliyet Takibi ve Optimizasyon İpuçları

Cloud Logging maliyetleri fark edilmeden artabilir. Özellikle büyük GKE cluster’ları çalıştırıyorsanız log hacmi çok hızlı büyür. Bazı pratik öneriler:

  • Verbose uygulama loglarını production’da kapatın: DEBUG seviyesindeki logları production ortamında tutmak hem güvenlik riski hem de maliyet problemidir.
  • Kısa ömürlü workload loglarını hariç tutun: Batch job’lar, test pipeline’ları gibi kısa ömürlü iş yüklerinin logları genellikle saklanmaya değmez.
  • Log sampling uygulayın: Çok yüksek frekanslı INFO loglarınız varsa, yüzde 10 veya yüzde 1 sampling yaparak hacmi düşürebilirsiniz.
  • BigQuery’ye export edip Cloud Logging’den silin: Uzun süreli analiz için logları BigQuery’de tutmak Cloud Logging’de tutmaktan çok daha ucuzdur.
  • Log bazlı maliyet analizi yapın: Her ay hangi kaynakların ne kadar log ürettiğini inceleyip buna göre exclusion kuralları yazın.
# Proje bazında aylık log hacmini öğrenme
gcloud logging read 
  'timestamp>="2024-01-01T00:00:00Z"' 
  --freshness=30d 
  --project=my-production-project 
  --format=json | wc -l

# En fazla log üreten resource type'ları bul
gcloud logging read "" 
  --freshness=24h 
  --project=my-production-project 
  --format=json | 
  jq -r '.[].resource.type' | 
  sort | uniq -c | sort -rn | head -20

Log Görünürlüğü için IAM Yetkilendirmesi

Takımdaki herkesin tüm loglara erişmesini istemeyebilirsiniz. Özellikle audit logları veya güvenlik logları hassas bilgiler içerebilir. Cloud Logging, granular IAM yetkilendirmesi destekler.

  • roles/logging.viewer: Tüm logları okuma yetkisi
  • roles/logging.privateLogViewer: Private loglar dahil okuma yetkisi
  • roles/logging.logWriter: Sadece log yazma yetkisi
  • roles/logging.configWriter: Sink, metrik ve exclusion yönetimi
  • roles/logging.admin: Tam yönetim yetkisi

Developer’lara genellikle roles/logging.viewer, uygulamalara ise roles/logging.logWriter vermek mantıklıdır.

Sonuç

Cloud Logging, yüzeysel bakıldığında basit bir log görüntüleme aracı gibi durur. Ama derine inince, log yönetiminin her katmanını kapsayan oldukça güçlü bir platform olduğunu görürsünüz. Doğru sink konfigürasyonları ile hem maliyet optimizasyonu yapabilir hem de compliance gereksinimlerinizi karşılayabilirsiniz. Structured logging alışkanlığını geliştirmek, sorun giderme sürelerinizi yarıya indirir. Log tabanlı metrikler ile monitoring sisteminizi zenginleştirir, loglardan doğrudan alarm üretebilirsiniz.

En önemli tavsiyem şu: Log mimarinizi proaktif olarak kurun, reaktif olmayın. Bir production krizi sırasında sink kurmaya, retention policy ayarlamaya ya da hangi logu nerede bulacağınızı çözmeye çalışmak gereksiz stres yaratır. Şimdi bir saatinizi bu yapıyı kurmaya harcayın, ileride kendinize teşekkür edersiniz.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir