Monitoring ve Alerting'e Öncelik Vermek: 3 Adımlı Pragmatik Rehberim

Sistemlerde neyi izleyeceğimiz ve neye alarm kuracağımız konusu, tecrübe ettikçe ne kadar kritik olduğunu gösteren bir alan. Başlangıçta her şeye alarm kurmaya çalıştım, sonra o gürültünün altında boğuldum. Neyi monitör edeceğime, neye alarm kuracağıma karar vermek, özellikle de kısıtlı kaynaklarla çalışırken önemli bir mühendislik kararı. Bir üretim ERP’sinin kritik anlarında veya kendi yan ürünümün arka planında, bu önceliklendirme, uykusuz gecelerin önüne geçti.

Bu yazıda, yıllar içinde edindiğim tecrübeyle monitoring ve alerting stratejimi nasıl oluşturduğumu, hangi adımları izlediğimi anlatacağım. Benim için bu, sadece teknik bir konu değil, aynı zamanda operasyonel olgunluk ve ekip verimliliğiyle de doğrudan ilgili. Her metrik ya da log satırı bir alarmı tetiklememeli; önemli olan, doğru sinyali doğru zamanda almak.

Adım 1: Ne Kırılırsa İş Durur? İş Kritik Metrikleri Tanımlama

İlk ve en önemli adım, işin can damarı olan metrikleri belirlemek. Bir sistemin performansını gösteren yüzlerce metrik olabilir, ama bunların hepsi aynı öneme sahip değildir. Ben her zaman “Bu kırılırsa para kaybederiz, müşteri kaybederiz veya operasyon durur mu?” sorusunu sorarak başlarım. Bir üretim firmasının ERP’sinde çalışırken, bu, sipariş alma, üretim planlama, sevkiyat ve faturalama gibi temel iş akışlarının kesintisizliğini sağlamak anlamına geliyordu.

Bir keresinde, büyük bir e-ticaret sitesinde, ödeme geçidi entegrasyonunda yaşanan anlık bir problem yüzünden kısa sürede ciddi miktarda potansiyel satışın kaçtığını gördüm. İşte o zaman, bu tip metriklerin sadece “izlenmesi” değil, anında “alarm” vermesi gerektiğini acı bir şekilde öğrendim. Bu tür durumlar için, sistemin genel sağlık göstergelerinden ziyade, doğrudan iş süreçlerinin çıktısını etkileyen metrikleri önceliklendiririm. Örneğin, bir veritabanı sunucusunun CPU kullanımı %80’e çıksa bile, eğer bu durum iş akışlarını etkilemiyorsa, belki bir uyarı (warning) yeterlidir. Ama ödeme API’mızın hata oranı %1’den %5’e çıkarsa, bu direkt PagerDuty çağrısı demektir.

Bu metrikleri belirlerken sadece teknik ekiple değil, iş birimleriyle de konuşurum. Onların “işin durması” tanımı ne, hangi iş akışları en kritik? Bu bana, teknik jargonun ötesine geçip gerçek iş etkisini anlamamda yardımcı olur. Deneyimimde, yazılım mimarisi çoğu zaman yazılım değil, organizasyonel akıştır. Bu yüzden monitoring mimarisi de organizasyonel akışın aynası olmalı.

Adım 2: Kırılmadan Önce Sinyal Verenleri İzle: Önleyici Metrikler

İş kritik metrikler “şimdi bir sorun var” derken, önleyici metrikler “yakında bir sorun olacak” sinyalini verir. Bunlar, sistemin gelecekteki davranışları hakkında ipuçları veren göstergelerdir. Disk doluluğu gibi bariz olanlar dışında, daha sinsi olabilecek başka önleyici metrikler de var. Bu metrikleri doğru okumak, proaktif olmayı ve büyük arızaları henüz küçükken önlemeyi sağlar.

Örneğin, PostgreSQL’de WAL bloat dediğimiz bir durum vardır. Transaction log’ların gereğinden fazla büyümesi, disk kullanımını artırır ve IO performansını düşürür. Bunu izlemek için sadece disk doluluğuna bakmak yetmez; pg_wal_lsn_diff gibi fonksiyonlarla WAL boyutunu ve büyüme hızını takip ederim. Eğer WAL boyutu belirli bir eşiği (örneğin 1GB) aşarsa ve büyüme hızı anormalleşirse, bu benim için bir uyarıdır ve hemen VACUUM veya replikasyon ayarlarını kontrol etmem gerektiğini gösterir.

-- PostgreSQL WAL bloat takibi için basit bir sorgu
SELECT
    pg_size_pretty(pg_current_wal_lsn() - '0/0'::pg_lsn) AS current_wal_size,
    (pg_current_wal_lsn() - pg_stat_replication.write_lsn) AS replica_lag_bytes
FROM pg_stat_replication
WHERE client_addr IS NOT NULL;

Redis tarafında ise OOM eviction policy seçimi ve bellek kullanımı kritiktir. Eğer Redis’i maxmemory-policy noeviction ile çalıştırıyorsam ve belleği dolarsa, yeni veri yazamaz hale gelir. Bunu önlemek için used_memory metriğini ve evicted_keys sayısını izlerim. Evicted key sayısının artması, Redis’in sürekli veri atmaya çalıştığının ve belleğin yetersiz kaldığının bir işaretidir. Bu, hemen bellek artırımı veya veri modelinde optimizasyon gerektiren bir durumdur.

Bu adımda, sistemlerin iç işleyişine hakim olmak büyük avantaj sağlar. Linux’ta cgroup memory.high gibi yumuşak limitleri belirleyip, bu limitlere yaklaşıldığında uyarı almak, bir container’ın OOM-killed olmadan önce önlem almamı sağlar. Bu tür detaylı izlemeler, genellikle “sistem yöneticisi” şapkamı taktığımda daha çok ilgilendiğim kısımlardır ve bu ince ayarlar pratikte büyük fark yaratır.

Adım 3: Gürültüyü Ele, Sadece Eyleme Geçilmesi Gerekeni Alertle

Monitoring ve alerting arasındaki en temel fark, birinin bilgi toplamak (monitoring), diğerinin ise müdahale gerektiren bir durum olduğunda bildirimde bulunmak (alerting) olmasıdır. Her monitör ettiğimiz şeye alarm kurmaya kalkarsak, kısa sürede “alarm yorgunluğu” (alert fatigue) yaşarız. Ekip, sürekli çalan ama gerçek bir sorun bildirmeyen alarmları görmezden gelmeye başlar. Bu, asıl kritik bir durum olduğunda tepki süresini uzatır. Ben kendi operasyonlarımda bu hatayı defalarca yaptım ve dersimi çıkardım.

Alerting için temel prensibim şudur: “Eğer bir alarm beni gece yarısı uyandırıyorsa, bu gerçekten acil ve müdahale gerektiren bir sorun olmalı.” Bu felsefe ile, alarmların eşiklerini ve tetikleme mantıklarını çok dikkatli ayarlarım.

Örneğin, sunucularıma gelen kötü niyetli istekleri engellemek için fail2ban kullanırım. fail2ban kendi içinde belirli desenleri (patterns) yakalayıp IP’leri banlar. Normalde fail2ban’ın bir IP’yi banlaması bir alarm değildir; bu, onun işini yaptığı anlamına gelir. Ama eğer fail2ban loglarında, örneğin son 1 saat içinde 1000’den fazla banlama olduğunu görürsem, bu bir DDoS denemesi veya geniş çaplı bir tarama atağı olabilir. İşte bu bir alert seviyesidir. Bu senaryo için, journald üzerinden fail2ban loglarını takip eden bir systemd unit oluşturup, belirli bir eşiği aşan banlama sayısında bir bildirim gönderecek bir yapı kurdum.

# journalctl ile fail2ban loglarını filtreleme ve sayma örneği
# Son 1 saatteki banlama olaylarını sayar
journalctl -u fail2ban.service --since "1 hour ago" | grep "Ban" | wc -l

Aynı şekilde, journald’ın kendisinin rate limit’leri vardır. Eğer bir servis çok fazla log basıyorsa, journald bu logları düşürmeye (rate limit) başlayabilir. Bu da önemli logları kaçırmamıza neden olur. journald’ın systemd-journald servisi için RateLimitBurst ve RateLimitIntervalSec ayarlarına dikkat ederim. Eğer bu limitlere ulaşıldığına dair bir log görürsem, bu bana ilgili uygulamanın loglama davranışını optimize etmem gerektiği konusunda bir alarm verir. Bu gibi durumlar, genellikle cgroup ile process’lere atadığım memory.high veya CPUQuota gibi limitlerle de iç içe çalışır.

Monitoring Data’sını Eylem Planlarına Bağlamak

Bir alarm aldığımızda ne yapacağımızı bilmek, en az alarmın kendisi kadar önemlidir. Sadece “Disk dolu!” diye bir bildirim almak yeterli değildir. Hangi diskin dolu olduğu, hangi uygulamanın bu diski kullandığı, nasıl temizleneceği veya sorunun nasıl çözüleceği de bilinmelidir. Benim için her kritik alarmın arkasında bir “runbook” olmalı. Bu runbook, sorunun tespiti, ilk müdahale adımları, geçici çözümler ve nihai çözüm için yol haritasını içerir.

Bir üretim ERP’sinde, PostgreSQL’in yavaşlaması gibi durumlar için detaylı runbook’lar hazırladım. Bu runbook’lar, hangi metriklerin kontrol edileceğini (CPU, I/O, aktif bağlantılar), hangi sorguların çalıştırılacağını (yavaş sorgular, kilitli tablolar), EXPLAIN ANALYZE çıktılarını nasıl yorumlayacağımızı ve olası index stratejilerini içerir. Hatta bazen, temel sorun giderme komutlarını içeren basit shell script’leri de bu runbook’lara eklerim.

Observability kavramı da burada devreye giriyor. Sadece metrikler değil, loglar ve trace’ler de sorunun kök nedenini bulmamızda kritik rol oynar. Bir uygulamanın hata oranı yükseldiğinde, sadece sayıyı bilmek yetmez. Hangi isteklerin hata verdiğini, hatanın stack trace’ini, hangi kullanıcıların etkilendiğini de bilmeliyiz. Ben kendi sistemlerimde, metrikleri Prometheus ile toplarken, logları Loki veya Elasticsearch ile merkezi bir yerde toplarım. Trace’ler için ise OpenTelemetry’yi kullanarak, bir isteğin farklı servisler arasında nasıl gezdiğini ve nerede takıldığını görmeye çalışırım. Bu üçlüyü bir araya getirmek, “Bir sorun var!” diyen alarmın “Sorun burada ve şöyle çözebilirsin!” demesini sağlar.

Bu yaklaşım, özellikle monolith’ten microservice’lere geçiş gibi mimari değişimlerde daha da önemli hale geliyor. Dağıtık sistemlerde bir isteğin yolculuğunu takip etmek, tek bir monolith’e göre çok daha karmaşık olabilir. Bu yüzden, event-sourcing veya CQRS gibi mimarilerde idempotency sorunlarını izlemek için transaction outbox desenini kullanarak, event’lerin doğru bir şekilde işlendiğinden emin olmak zorundayım.

Gürültüyü Azaltma ve Alert Fatigue ile Mücadele Tekniklerim

Yıllar içinde, alert fatigue’in ne kadar yıkıcı olabileceğini bizzat deneyimledim. Sürekli çalan ama önemsiz alarmlar, zamanla gerçek acil durumların da gözden kaçmasına neden olur. Bu yüzden, gürültüyü azaltmak ve sadece eyleme geçilmesi gereken alarmları iletmek benim için bir operasyonel disiplin haline geldi.

Kullandığım bazı teknikler şunlar:

• Deduplication (Tekrar Eden Alarmları Gruplama): Aynı hatanın art arda gelmesi durumunda her seferinde yeni bir bildirim göndermek yerine, ilk bildirimi gönderip sonraki aynı hataları o bildirimin altına gruplarım. Böylece “100 tane disk dolu alarmı” yerine “Disk dolu (100 kez tekrar etti)” gibi bir bildirim alırım.
• Silencing (Sessize Alma): Planlı bakım pencerelerinde veya bilinen geçici sorunlarda alarmları geçici olarak sessize alırım. Örneğin, bir VPS migration sürecinde, yeni sunucu ayağa kalkana kadar eski sunucunun network alarmlarını sessize alırım.
• Escalation Policies (Yükseltme Politikaları): Bir alarmı ilk başta sadece bir ekibe gönderirim. Eğer belirli bir süre içinde müdahale edilmezse, daha üst seviye bir ekibe veya farklı bir kanala (SMS, telefon araması) iletilmesini sağlarım.
• Baselines ve Anomali Tespiti: Statik eşik değerleri her zaman yeterli değildir. Bir uygulamanın normal çalışma zamanındaki trafik paternleri, CPU kullanımı gibi metrikleri izleyip, bu baseline’dan sapan durumları anomali olarak işaretleyen sistemler kullanırım. Bu, özellikle yeni bir feature flag açtığımda veya canary deployment yaptığımda çok işime yarıyor.
• Alert Review (Alarm İncelemesi): Düzenli olarak (ayda bir veya her büyük incident sonrası) mevcut alarmları gözden geçiririm. Artık geçerli olmayan, yanlış pozitif üreten veya gereksiz yere bildirim yapan alarmları ayıklarım. Bu, systemd unit’lerinin başarısız olmasına dair alarmlar için de geçerlidir. Bazen bir systemd timer beklediğim gibi çalışmaz ya da process OOM-killed olur. Bu durumda, alarmı genel “fail” yerine daha spesifik bir nedene (örneğin OOM, timeout, exit code) bağlayarak iyileştiririm; böylece bildirim geldiğinde sebep en baştan belli olur.

Bu yaklaşımlar, özellikle karmaşık bare-metal + container hibrit dağıtım ortamlarında kritik öneme sahip. Docker Compose ile yönettiğim bir ortamda disk yangınlarını veya build OOM durumlarını izlerken, bu filtreleme teknikleri sayesinde sadece gerçekten müdahale edilmesi gereken durumlarda aksiyon alabiliyorum. Aksi takdirde, sürekli çalan telefonlar ve gelen bildirimler altında boğulmak kaçınılmaz olurdu. Bu, kariyerimin ilk yıllarından beri öğrendiğim en değerli derslerden biri.

Sonuç

Monitoring ve alerting, bir sistemin sağlıklı çalışmasını sağlamanın temel taşlarıdır. Ancak bu ikisi arasındaki dengeyi doğru kurmak, yılların tecrübesiyle oturuyor. Bu yazıda anlattığım 3 adım – iş kritik metrikleri tanımlama, önleyici sinyalleri izleme ve gürültüyü eleyerek sadece eyleme geçilmesi gerekeni alertle – benim için operasyonel olgunluğun bir yol haritası oldu.

Unutmayalım ki bu süreç, bir kere yapıp biten bir şey değildir. Sistemler geliştikçe, iş ihtiyaçları değiştikçe, bu öncelikler de sürekli gözden geçirilmeli ve güncellenmelidir. Her yeni özellik, her yeni entegrasyon, monitoring ve alerting stratejimize yeni bir katman ekleyebilir. Pragmatik bir yaklaşımla, hatalardan ders çıkararak ve sürekli iyileştirme yaparak daha dirençli sistemler kurabiliriz. Bir sonraki yazımda, PostgreSQL’de index stratejileri ve performans regresyonlarını nasıl izlediğimi anlatacağım.