Servislerimi önce RED metrikleriyle mi yoksa USE metrikleriyle mi enstrümante etmeliyim?

Kısa cevap: Bu ya/ya da bir seçim değil.

Kısa cevap

RED istek-güdümlü yüzeyler için, USE kaynaklar için. Her iki fleet’in de sonunda ikisine ihtiyacı var; sadece ağırlık farklı ve başlangıç sırası farklı.

Neden

1. RED = Rate, Errors, Duration. İstek/servis bakış açısıdır. “Kullanıcılarıma iyi hizmet veriliyor mu?” sorusunu yanıtlar. Laravel API’nin HTTP endpoint’leri için birebir bu; oradan başlayın.

2. USE = Utilization, Saturation, Errors. Kaynak bakış açısıdır (CPU, bellek, kuyruk derinliği, connection pool). “Darboğaz hangi kaynakta?” sorusunu yanıtlar. Kapasite ve doygunluk kararlarınızı bu besler.

3. Worker fleet ikisinin karıştığı yerdir. Bir queue worker istek/cevap değildir, dolayısıyla saf RED garip durur. Çözüm: job’ı “istek” gibi modelleyin — rate = saniyedeki job sayısı, errors = başarısız job’lar, duration = işleme süresi. Böylece RED worker’a da uyar.

4. USE, özellikle kuyruk derinliği için, öncü göstergedir. Worker’larda kuyruk backlog’u (saturation), gecikme daha yükselmeden “yetersiz kapasitedesin” der. DB connection pool doygunluğu da klasik gizli katildir; USE olmadan onu geç fark edersiniz.

5. RED semptom, USE sebep alarmıdır. İkisi arasındaki asıl fark burada işe yarar: kullanıcıyı gerçekten etkileyen şey RED’dir, o yüzden sayfa çağıran (paging) alarmları RED üzerine kurun (hata oranı, p99 gecikme). USE metriklerini ise alarm için değil, “neden” sorusunu yanıtlayan teşhis panoları için kullanın — bir kaynak doygunluğa yaklaşıyorsa uyarı verir, ama gece sizi USE değil, bozulan RED aramalı.

   # RED (histogram) — hem API hem worker (job'ı istek gibi say)
   http_request_duration_seconds_bucket{route="/checkout", le="0.5"}
   job_processing_duration_seconds_bucket{queue="emails", le="2"}
   # USE (gauge) — kaynak doygunluğu
   queue_depth{queue="emails"}
   db_pool_in_use_connections{pool="primary"}

Ne yapmalı

1. API’de önce RED — çünkü SLO’lara birebir oturur. Kullanıcıya dönük SLO’larınız gecikme + hata oranıdır; bu doğrudan RED demektir. Önce bunu enstrümante edin, sizi gece arayan da budur.

2. Cardinality’yi patlatmayın. Endpoint başına label sorun değil, ama user_id gibi sınırsız bir label Prometheus’u şişirir. Label setlerini sınırlı tutun; yoksa metrik altyapısının kendisi sorun olur.

3. Duration’ı histogram olarak toplayın, ortalama tutmayın. RED’in “D”si ortalama gecikme değil, p95/p99 anlamına gelir; ortalama, kuyruğun en kötü kullanıcı deneyimini gizler. Prometheus’ta histogram kullanın ve panolarda histogram_quantile ile persentil çıkarın.

Sonuç: Ben olsam API’de RED ile başlar (SLO’ya en hızlı değer bu), worker’larda job’ı istek gibi modelleyip yine RED kurar, sonra her iki tarafa da USE’u (özellikle kuyruk derinliği ve pool doygunluğu) eklerdim. Sıra RED → USE; ama ikisi de olmadan resmin yarısını görürsünüz. Not: Google’ın “dört altın sinyali” (latency, traffic, errors, saturation) bu iki modeli birleştiren güzel bir köprüdür — takıldığınızda oradan da bakabilirsiniz.