Argo Rollouts ile Prometheus Metrikleriyle Otomatik Canary Geri Alma

Canary dağıtımları sırasında metrik bazlı kararlar almak, beklenmedik davranışları erken yakalamak için kritik. Argo Rollouts, Prometheus entegrasyonu sayesinde canary analizini otomatikleştirebilir ve tanımlanan eşikler aşıldığında otomatik geri alma tetikleyebilir. Bu yazıda, deneyimimden çıktığım bir e-ticaret platformu ortamında nasıl bu entegrasyonu kurduğumu adım adım paylaşıyorum.

Canary Analizi için Prometheus Metrik Seçimi

İlk adım, canary sürümünün sağlığını yansıtacak doğru metrikleri seçmek. Ben genellikle request latency, error rate (5xx), ve throughput gibi temel SLO göstergecini kullanırım. Örneğin, canary pod'larının ortalama yanıt süresinin %20'nin üzerinde kalması veya hata oranının %1'i aşması geri alma koşulu olabilir.

Prometheus sorgularını Argo Rollouts'ta metricProvider ile tanımlıyorsunuz. Aşağıda latency için örnek bir sorgu:

metrics:
- name: request-latency
  interval: 30s
  provider:
    prometheus:
      address: http://prometheus.monitoring.svc:9090
      query: |
        histogram_quantile(0.95,
          sum(rate(http_request_duration_seconds_bucket{job="frontend"}[5m]))
          by (le)
        )

Bu sorgu, frontend hizmeti için 95. persentil latency'i hesaplar. Aynı mantıkla error rate için de rate(http_requests_total{status=~"5.."}[5m]) gibi sorgular kullanılır.

Argo Rollouts'ta Metrik Bazlı Rollback Tanımı

Metrikler hazırlandığında, AnalysisTemplate ve Experiment üzerinden rollback koşullarını tanımlarsınız. Ben genelde AnalysisRun içinde successCondition ve failureCondition ile net eşikler belirliyorum.

Örnek bir AnalysisTemplate:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: latency-check
spec:
  args:
  - name: latency-threshold
    value: "0.5"
  metrics:
  - name: latency
    interval: 30s
    provider:
      prometheus:
        address: http://prometheus.monitoring.svc:9090
        query: |
          histogram_quantile(0.95,
            sum(rate(http_request_duration_seconds_bucket{job="frontend"}[5m]))
            by (le)
          )
    successCondition: result < args.latency-threshold
    failureCondition: result >= args.latency-threshold

Bu şablon, latency 500ms'in üzerindeki her ölçümde analiz başarısız sayılır. failureCondition tetiklendiğinde, Rollout otomatik olarak canary adımını geri alır ve önceki stabil sürüme döner.

Rollout Manifestında Entegrasyon

Canary adımınızı tanımlarken steps altında analysis blokunu eklemeniz yeterli. Aşağıda basit bir canary stratejisi:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: frontend-rollout
spec:
  strategy:
    canary:
      steps:
      - setWeight: 20
      - analysis:
          templates:
          - templateName: latency-check
            args:
            - name: latency-threshold
              value: "0.5"
      - setWeight: 50
      - analysis:
          templates:
          - templateName: latency-check
      - setWeight: 100

Burada, her ağırlık artışından sonra metrik analizi yapılır. Eğer herhangi bir analiz adımı başarısız olursa, Rollout hemen önceki stabil adıma döner ve canary durur.

Gerçek Ortamda Dikkat Edilecek Pitfall'lar

Bu entegrasyonu yaparken karşılaştığım bazı zorluklar:

• Sorgu gecikmesi: Prometheus sorguları çok komplex ise, analiz aralıkları uzayıp canary süresi gereksiz uzar. Sorgularınızı rate() ve sum() ile ön-agregasyon yaparak tutun.

• Metrik titrezliği: Ani trafik dalgalanmaları yanlış tetiklemeye yol açabilir. Ben genellikle interval: 30s yerine interval: 1m kullanıp, failureCondition içinde birden fazla ardışık başarısızlığı zorunlu kılıyorum:

  failureCondition: |
    result >= args.latency-threshold &&
    consecutiveErrorCount >= 3

• Missing metrics: Canary pod'ları hâlâ warm-up aşamasında ise, metrik boş döneb ve analiz hatalı çıkar. Bu yüzden tolerance ekleyerek ilk 1-2 analizatlası yoksayabilirsiniz:

  tolerance:
    - maxFailed: 2

Not: Metrik Seçimi Önemli

Sadece teknik metriklerle sınırlı kalmayın. İş metrikleri (örn. checkout tamamlanma oranı, sepetteki ürün sayısı) de canary analizine eklenebilir. Ancak bu tür metrikler genellikle uygulama içinde özel endpoint'ler üzerinden çıkarılır ve Prometheus'tan çekilir. Bu konuda daha önce yazdığım [Prometheus'ta özel metrik çıkarma](https://furkanikkan.com/urun/prometheus-ile-ozel-metrik-cikarma-101) postumu da inceleyebilirsiniz.

Canary dağıtımlarında metrik bazlı otomatik geri alma, insansal müdahaleye bağımlılığı azaltır ve SLO ihlallerini minimize eder. Argo Rollouts ve Prometheus bu süreci deklaratif ve tekrarlanabilir hâle getirir. Ortamınızda önce tek bir hizmetle deneyin, metrik sorgularınızı doğrulayın, ardından ölçekleyin. Bu sayede hem güven hem de hız elde edersiniz.

Kapak görseli: HD Wallpapers · CC0 (Openverse / kamu malı) · https://stocksnap.io/photo/light-abstract-V9L6XXK3LB