GCP Cloud Monitoring ile Sunucu İzleme Rehberi

Tarafındankomut
0 Comments

Prodüksiyonda bir şeylerin patladığını öğrenmenin en kötü yolu, müşteri şikayetidir. “Siteniz çalışmıyor” diye gelen bir mesaj, herhangi bir gecenin en nahoş sürprizi olabilir. GCP Cloud Monitoring, tam da bu tür durumları önlemek için tasarlanmış kapsamlı bir gözlemlenebilirlik platformudur. Bugün bu aracı gerçek dünya senaryolarıyla birlikte ele alacağız; hem temel kurulumdan hem de ileri seviye konfigürasyonlardan bahsedeceğiz.

GCP Cloud Monitoring Nedir ve Neden Önemlidir

Google Cloud Monitoring (eski adıyla Stackdriver Monitoring), GCP üzerindeki kaynakları, uygulamaları ve altyapıyı izlemenizi sağlayan yönetilen bir hizmettir. Tek bir dashboard üzerinden yüzlerce sanal makineyi, veritabanını, uygulama servisini ve ağ bileşenini takip edebilirsiniz.

Bir e-ticaret şirketinde çalıştığınızı düşünün. Siyah Cuma döneminde trafik ani bir şekilde 10 katına çıkıyor. CPU’lar tepetaklak oluyor, bellek dolmaya başlıyor, disk I/O tavan yapıyor. Eğer önceden doğru izleme kurulumu yapmadıysanız, bu durumu öğrenmenin tek yolu sistemin çökmesidir. Cloud Monitoring ise bu senaryoda size şu avantajları sağlar:

  • Gerçek zamanlı metrik toplama ve görselleştirme
  • Özelleştirilebilir alert (uyarı) politikaları
  • Otomatik anomali tespiti
  • Çoklu GCP projesi üzerinden merkezi izleme
  • Uptime check ile dış kaynak erişilebilirlik kontrolü
  • Log tabanlı metrikler oluşturma

Ön Hazırlık ve Ops Agent Kurulumu

Cloud Monitoring’i tam anlamıyla kullanmak için, izlenecek VM’lere Ops Agent kurmanız gerekir. Bu ajan, sistem metriklerini ve logları Cloud Monitoring ile Cloud Logging’e aktarır. Eski Stackdriver Agent‘ın yerini almıştır ve şiddetle tavsiye edilir.

Ops Agent’ı Manuel Kurma

# Kurulum scriptini indirin
curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh

# Scripti çalıştırın ve ajanı başlatın
sudo bash add-google-cloud-ops-agent-repo.sh --also-install

# Servis durumunu kontrol edin
sudo systemctl status google-cloud-ops-agent

# Ajanın düzgün çalıştığını doğrulayın
sudo systemctl list-units --type=service | grep google-cloud

Birden Fazla VM’ye Toplu Kurulum

Tek tek VM’ye bağlanıp kurulum yapmak, onlarca sunucu varsa kabusa dönebilir. Bunun yerine gcloud komut satırı aracını ve başlatma scriptlerini kullanabilirsiniz.

# Mevcut bir VM'ye uzaktan Ops Agent kurulumu
gcloud compute ssh my-instance 
  --zone=europe-west1-b 
  --command="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"

# Ya da instance template ile yeni VM'lere otomatik kurulum için
# startup-script parametresi kullanın
gcloud compute instances create my-monitored-vm 
  --zone=europe-west1-b 
  --machine-type=e2-medium 
  --metadata=startup-script='#!/bin/bash
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' 
  --scopes=monitoring-write,logging-write

Dikkat etmeniz gereken önemli bir nokta: VM’nin monitoring-write ve logging-write scope’larına sahip olması gerekir. Bu scope’lar olmadan ajan metrik gönderemez.

Temel Metrik Sorgulama

GCP Cloud Monitoring, MQL (Monitoring Query Language) adında güçlü bir sorgu dili sunar. Bunu hem konsol üzerinde hem de API üzerinden kullanabilirsiniz.

# gcloud ile CPU kullanımını sorgulama
gcloud monitoring metrics list 
  --filter="metric.type=starts_with('compute.googleapis.com/instance/cpu')"

# Belirli bir metrik için son 1 saatlik veriyi çekme
gcloud monitoring time-series list 
  --filter='metric.type="compute.googleapis.com/instance/cpu/utilization" AND resource.labels.instance_id="INSTANCE_ID"' 
  --interval-start-time=$(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) 
  --interval-end-time=$(date -u +%Y-%m-%dT%H:%M:%SZ)

Alert Policy Oluşturma

Gerçek dünya senaryosu: Bir SaaS ürününüz var ve API sunucularınızın CPU kullanımı %80’i geçtiğinde haberdar olmak istiyorsunuz. Bunu yapmak için alert policy oluşturmanız gerekir.

YAML ile Alert Policy Tanımlama

# cpu-alert-policy.yaml
displayName: "Yüksek CPU Kullanımı Uyarısı"
combiner: OR
conditions:
  - displayName: "CPU %80 üzerinde"
    conditionThreshold:
      filter: >
        resource.type = "gce_instance"
        AND metric.type = "compute.googleapis.com/instance/cpu/utilization"
      aggregations:
        - alignmentPeriod: 300s
          perSeriesAligner: ALIGN_MEAN
      comparison: COMPARISON_GT
      thresholdValue: 0.8
      duration: 120s
      trigger:
        count: 1
alertStrategy:
  notificationRateLimit:
    period: 3600s
  autoClose: 604800s
notificationChannels:
  - projects/MY_PROJECT/notificationChannels/CHANNEL_ID
documentation:
  content: >
    CPU kullanımı %80'i aştı. Lütfen aşağıdaki adımları izleyin:
    1. top komutu ile hangi process'lerin CPU tükettiğini belirleyin
    2. Gerekirse instance'ı scale up edin
    3. Auto-scaling grubunu kontrol edin
  mimeType: text/markdown
# YAML dosyasından alert policy oluşturma
gcloud alpha monitoring policies create 
  --policy-from-file=cpu-alert-policy.yaml

# Mevcut policy'leri listeleme
gcloud alpha monitoring policies list

# Policy'yi güncelleme
gcloud alpha monitoring policies update POLICY_ID 
  --policy-from-file=updated-policy.yaml

Notification Channel Ayarlama

Alert oluşturmak yetmez, nereye bildirileceğini de tanımlamanız gerekir. E-posta, Slack, PagerDuty veya webhook seçenekleriniz var.

# E-posta notification channel oluşturma
gcloud alpha monitoring channels create 
  --display-name="Ops Team Email" 
  --type=email 
  [email protected]

# Oluşturulan channel ID'yi öğrenme
gcloud alpha monitoring channels list 
  --filter="displayName='Ops Team Email'"

# Notification channel doğrulama (test bildirimi gönderme)
gcloud alpha monitoring channels verify CHANNEL_ID

Uptime Check ile Dış Erişilebilirlik İzleme

Sunucunuz çalışıyor olabilir ama kullanıcılar siteye erişemiyor olabilir. Ağ sorunları, yük dengeleyici hataları veya uygulama katmanı problemleri buna yol açabilir. Uptime check bu senaryolarda hayat kurtarır.

# HTTP uptime check oluşturma
gcloud monitoring uptime create 
  --display-name="Ana Sayfa Kontrolü" 
  --resource-type=uptime-url 
  --resource-labels=host=www.sirketim.com,project_id=MY_PROJECT 
  --protocol=HTTPS 
  --path=/ 
  --port=443 
  --check-interval=60 
  --timeout=10 
  --regions=europe-west1,us-central1,asia-east1

# Tüm uptime check'leri listeleme
gcloud monitoring uptime list

# Belirli bir check'in detaylarını görme
gcloud monitoring uptime describe CHECK_ID

Uptime check, dünya genelindeki farklı lokasyonlardan kontrol gerçekleştirir. Bir lokasyonda sorun olsa bile diğerlerinden kontrol yapılır ve gerçek bir kesinti mi yoksa bölgesel bir sorun mu olduğunu anlarsınız.

Özel Dashboard Oluşturma

Konsol üzerinde hazır dashboard’lar güzel ama özelleştirilmiş bir dashboard, ekibinizin neye ihtiyaç duyduğunu tam olarak yansıtır.

# Dashboard JSON şablonunu dosyaya aktarma
gcloud monitoring dashboards list --format=json > dashboards.json

# Belirli bir dashboard'u export etme
gcloud monitoring dashboards describe DASHBOARD_ID 
  --format=json > my-dashboard.json

# Yeni dashboard oluşturma (JSON ile)
gcloud monitoring dashboards create 
  --config-from-file=my-dashboard.json

Dashboard JSON yapısı karmaşık görünebilir ama mantığı anladıktan sonra oldukça esnek bir yapı sunar. Örneğin bir tile için temel yapı şu şekildedir:

{
  "displayName": "Altyapi Genel Bakis",
  "gridLayout": {
    "columns": "2",
    "widgets": [
      {
        "title": "CPU Kullanimi",
        "xyChart": {
          "dataSets": [{
            "timeSeriesQuery": {
              "timeSeriesFilter": {
                "filter": "metric.type="compute.googleapis.com/instance/cpu/utilization" resource.type="gce_instance"",
                "aggregation": {
                  "alignmentPeriod": "60s",
                  "perSeriesAligner": "ALIGN_MEAN",
                  "groupByFields": ["resource.labels.instance_id"]
                }
              }
            }
          }]
        }
      }
    ]
  }
}

Log Tabanlı Metrikler

Bazen standart sistem metrikleri yetmez. Uygulama loglarından metrik üretmek isteyebilirsiniz. Örneğin, uygulamanızın loglarında kaç tane “ERROR” satırı geçtiğini metrik olarak takip etmek istiyorsunuz.

# Log tabanlı metrik oluşturma
gcloud logging metrics create application-errors 
  --description="Uygulama hata sayisi" 
  --log-filter='resource.type="gce_instance" AND severity="ERROR" AND textPayload=~"Application Error"'

# Metrik listesini görme
gcloud logging metrics list

# Metriği güncelleme
gcloud logging metrics update application-errors 
  --log-filter='resource.type="gce_instance" AND severity="ERROR"'

Bu metriği oluşturduktan sonra, standart Cloud Monitoring metrikleri gibi kullanabilirsiniz. Alert policy’lerine ekleyebilir, dashboard’larınızda gösterebilirsiniz.

Hata Oranı Alert’i Oluşturma

# Log tabanlı metrik üzerinden alert oluşturma
cat > error-rate-alert.yaml << 'EOF'
displayName: "Yüksek Uygulama Hata Oranı"
combiner: OR
conditions:
  - displayName: "Dakikada 10'dan fazla hata"
    conditionThreshold:
      filter: >
        resource.type = "gce_instance"
        AND metric.type = "logging.googleapis.com/user/application-errors"
      aggregations:
        - alignmentPeriod: 60s
          perSeriesAligner: ALIGN_RATE
      comparison: COMPARISON_GT
      thresholdValue: 10
      duration: 0s
EOF

gcloud alpha monitoring policies create 
  --policy-from-file=error-rate-alert.yaml

Gerçek Dünya Senaryosu: Veritabanı Performans İzleme

Diyelim ki Cloud SQL kullanıyorsunuz ve veritabanı performansını yakından takip etmek istiyorsunuz. Disk kullanımı, bağlantı sayısı ve sorgu gecikmesi sizin için kritik metrikler.

# Cloud SQL için disk kullanımı alert'i
cat > cloudsql-disk-alert.yaml << 'EOF'
displayName: "Cloud SQL Disk Doluluk Uyarisi"
combiner: OR
conditions:
  - displayName: "Disk %85 üzerinde"
    conditionThreshold:
      filter: >
        resource.type = "cloudsql_database"
        AND metric.type = "cloudsql.googleapis.com/database/disk/utilization"
      aggregations:
        - alignmentPeriod: 300s
          perSeriesAligner: ALIGN_MEAN
      comparison: COMPARISON_GT
      thresholdValue: 0.85
      duration: 60s
      trigger:
        count: 1
notificationChannels:
  - projects/MY_PROJECT/notificationChannels/DBA_CHANNEL_ID
documentation:
  content: |
    Cloud SQL disk kapasitesi kritik seviyede.
    Hemen aksiyon alin:
    - Eski verileri arsivleyin
    - Storage kapasitesini artirin
    - Gereksiz index'leri temizleyin
  mimeType: text/markdown
EOF

gcloud alpha monitoring policies create 
  --policy-from-file=cloudsql-disk-alert.yaml

SLO (Service Level Objective) Tanımlama

Cloud Monitoring’in en güçlü özelliklerinden biri SLO yönetimidir. Bir servis için “kullanıcıların %99.9’u isteğe 200ms altında cevap almalı” gibi hedefler tanımlayabilirsiniz.

# Mevcut servisleri listeleme
gcloud monitoring services list

# Custom servis oluşturma
gcloud monitoring services create 
  --display-name="API Servisi" 
  --custom

# SLO tanımlama (request-based)
cat > api-slo.yaml << 'EOF'
displayName: "API Basari Orani SLO"
goal: 0.999
rollingPeriod: 2592000s
requestBased:
  goodTotalRatio:
    goodServiceFilter: >
      metric.type="loadbalancing.googleapis.com/https/request_count"
      resource.type="https_lb_rule"
      metric.labels.response_code_class="200"
    totalServiceFilter: >
      metric.type="loadbalancing.googleapis.com/https/request_count"
      resource.type="https_lb_rule"
EOF

SLO tanımladıktan sonra error budget otomatik hesaplanır. Bu ay kaç dakika kesinti yapabileceğinizi görsel olarak takip edebilirsiniz.

Terraform ile Infrastructure as Code Yaklaşımı

Monitoring konfigürasyonlarınızı manuel yapmak yerine Terraform ile kod olarak yönetmek, tekrar üretilebilirlik ve versiyon kontrolü açısından çok daha sağlıklıdır.

# Terraform ile Cloud Monitoring alert policy
cat > monitoring.tf << 'EOF'
resource "google_monitoring_alert_policy" "cpu_alert" {
  display_name = "Yüksek CPU Kullanımı"
  combiner     = "OR"

  conditions {
    display_name = "CPU %80 üzerinde"
    condition_threshold {
      filter          = "resource.type="gce_instance" AND metric.type="compute.googleapis.com/instance/cpu/utilization""
      duration        = "120s"
      comparison      = "COMPARISON_GT"
      threshold_value = 0.8

      aggregations {
        alignment_period   = "300s"
        per_series_aligner = "ALIGN_MEAN"
      }
    }
  }

  notification_channels = [
    google_monitoring_notification_channel.email.name
  ]

  documentation {
    content   = "CPU kullanımı kritik seviyede. Lütfen inceleyiniz."
    mime_type = "text/markdown"
  }
}

resource "google_monitoring_notification_channel" "email" {
  display_name = "Ops Team"
  type         = "email"

  labels = {
    email_address = "[email protected]"
  }
}
EOF

# Terraform plan ve apply
terraform init
terraform plan
terraform apply

Monitoring API ile Otomasyonlar

Bazen konsol veya gcloud yeterli olmaz, direkt API ile entegrasyon yapmanız gerekir. Python ile basit bir monitoring scripti:

# Python monitoring client kurulumu
pip install google-cloud-monitoring

# Basit metrik okuma scripti
cat > check_metrics.py << 'EOF'
from google.cloud import monitoring_v3
from datetime import datetime, timedelta
import time

client = monitoring_v3.MetricServiceClient()
project_name = "projects/MY_PROJECT"

interval = monitoring_v3.TimeInterval()
end_time = time.time()
interval.end_time.seconds = int(end_time)
interval.start_time.seconds = int(end_time - 3600)

results = client.list_time_series(
    request={
        "name": project_name,
        "filter": 'metric.type="compute.googleapis.com/instance/cpu/utilization"',
        "interval": interval,
        "view": monitoring_v3.ListTimeSeriesRequest.TimeSeriesView.FULL,
    }
)

for result in results:
    instance_id = result.resource.labels["instance_id"]
    latest_point = result.points[0]
    cpu_value = latest_point.value.double_value * 100
    print(f"Instance: {instance_id} | CPU: {cpu_value:.1f}%")
    if cpu_value > 80:
        print(f"  UYARI: {instance_id} yüksek CPU!")
EOF

python3 check_metrics.py

Dikkat Edilmesi Gereken Noktalar

Monitoring kurulumu yaparken sık yapılan hatalar ve bunlardan kaçınma yolları:

  • Alert yorgunluğu: Çok hassas threshold’lar belirlerseniz, ekip sürekli uyarı alır ve bunları görmezden gelmeye başlar. %80 yerine %90 gibi daha gerçekçi eşikler seçin
  • Eksik scope: VM’ler monitoring-write scope’u olmadan ajan kuruluşunu tamamlasa bile metrik gönderemez. Instance oluştururken bu scope’u mutlaka ekleyin
  • Tek notification channel: Sadece bir kişiye veya bir kanala gönderim yapmayın. PagerDuty veya Slack gibi ekip kanallarını tercih edin
  • Downtime konfigürasyonu yapılmaması: Planlı bakım sırasında alert’leri susturmak için downtime windows oluşturun, aksi halde gereksiz panik yaşarsınız
  • Custom metrik sınırları: Ücretsiz kotta çok sayıda custom metrik oluşturmak maliyeti artırabilir, metrik sayısını kontrol altında tutun
  • Dashboard erişim yönetimi: Dashboard’ları gerektiğinde herkese açık yapabilirsiniz ama alert policy’lerin yönetimini IAM rolleri ile sınırlandırın

Maliyet Yönetimi

Cloud Monitoring’de bazı özellikler ücretlidir:

  • İlk 150 MB/ay log verisi ücretsizdir, sonrası ücretlidir
  • Custom metrikler belirli bir sınırın üzerinde ücretlendirilir
  • Premium tier özellikler ek maliyet getirir
# Mevcut monitoring maliyetlerini görme
gcloud billing accounts list

# Proje bazlı maliyet raporu için Cloud Billing API kullanabilirsiniz
gcloud services enable billingbudgets.googleapis.com

# Budget alert oluşturma (50 dolar eşiği için)
gcloud billing budgets create 
  --billing-account=BILLING_ACCOUNT_ID 
  --display-name="Monitoring Budget" 
  --budget-amount=50USD 
  --threshold-rules=percent=0.5 
  --threshold-rules=percent=0.9 
  --threshold-rules=percent=1.0

Sonuç

GCP Cloud Monitoring, doğru konfigüre edildiğinde prodüksiyondaki sorunları müşteri şikayetine dönüşmeden yakalamanızı sağlar. Ops Agent kurulumu ile başlayın, anlamlı alert’ler tanımlayın, uptime check’lerle dış erişilebilirliği izleyin ve log tabanlı metriklerle uygulama katmanını da görünür hale getirin.

En önemli tavsiye şu: Alert yorgunluğundan kaçının. Her şeyi izlemek yerine, iş açısından kritik olan metriklere odaklanın. CPU %95’te mi? Uyar. Disk %90’da mı? Uyar. Ama %50 CPU için alarm kurarsanız, ekibiniz bu bildirimleri hızla görmezden gelmeye başlar.

Terraform veya YAML tabanlı konfigürasyonlarınızı mutlaka versiyon kontrolüne alın. “Şu eski alert neden silinmiş?” sorusunun cevabını Git history’de bulabilmek, üç ay sonra paha biçilemez bir kolaylık sağlar. Monitoring bir kez kurup unutulan bir şey değildir; altyapınız büyüdükçe monitoring konfigürasyonunuz da büyümeli ve gelişmelidir.

Bir yanıt yazın

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