Kazanimlar:
- Gözlemlenebilirliğin üç direğini (metrik, log, trace) ve dört altın sinyali kavrayıp yapay zekaya PromQL sorguları, alarm kuralları ve pano ürettirebilme
- Alarmları eyleme dönük ve doğru aciliyette tutup eşikleri kendi sistemin geçmiş verisiyle sınayarak alarm yorgunluğunu önleyebilme
- Log'ları yapay zekaya vermeden önce hassas alanları maskeleyerek gizlilik ve secret sızıntısını engelleyebilme
Bir sistem çalışıyor gibi görünürken içten içe ölüyor olabilir: bellek yavaşça doluyor, yanıt süreleri uzuyor, hata oranı sinsice tırmanıyor. Bunu fark etmenin tek yolu, sistemi sürekli izlemektir (monitoring). Daha ileri bir kavram gözlemlenebilirlik (observability): sistemin dış işaretlerine bakarak içeride ne olduğunu anlayabilme yeteneği. Gözlemlenebilirliğin üç direği vardır ve DevOps profesyoneli üçünü de kullanır:
- Metrik (metric): Zaman içinde ölçülen sayısal değerler — CPU kullanımı, istek sayısı, yanıt süresi, hata oranı. "Ne kadar?" sorusunu yanıtlar.
- Log (kayıt): Sistemin ürettiği metin olay kayıtları — "kullanıcı giriş yaptı", "veritabanı bağlantısı koptu". "Tam olarak ne oldu?" sorusunu yanıtlar.
- Trace (iz): Bir isteğin sistemin içinde servisten servise geçerken izlediği yol ve her adımın süresi. "Yavaşlık nerede?" sorusunu yanıtlar.
En yaygın araçlar: metrik için Prometheus, görselleştirme için Grafana, log için Loki/ELK, trace için Jaeger/OpenTelemetry. YZ, bu araçların sorgu dillerini (özellikle Prometheus'un PromQL'i), alarm kurallarını ve gösterge panosu (dashboard) yapılandırmalarını yazmakta çok yeteneklidir. Ayrıca YZ'nin en güçlü olduğu yer: büyük log ve metrik yığınlarını özetleyip anormalliği işaretlemek.
İzleme ile gözlemlenebilirlik arasındaki farkı bir cümleyle netleştirelim: izleme, önceden bildiğiniz soruları sormaktır ("CPU %90'ı geçti mi?"); gözlemlenebilirlik ise önceden bilmediğiniz soruları sorabilmektir ("bu garip yavaşlık neden yalnızca belirli bir müşteride, belirli bir saatte oluyor?"). Modern sistemler o kadar karmaşıktır ki tüm arıza biçimlerini önceden tahmin edemezsiniz; bu yüzden zengin metrik, log ve trace toplayıp sonradan derinlemesine sorgulayabilmek — yani gözlemlenebilirlik — kritik hale gelir. YZ tam da burada, "önceden bilinmeyen soruyu" yanıtlarken devreye girer: elinizdeki ham veriyi hızla tarayıp örüntü ve anormallik önerir, siz de bu ipuçlarını doğrulayarak kök nedene inersiniz.
Adım adım: neyi, nasıl izlemeli?
- Doğru metrikleri seç. Sektörde "dört altın sinyal" (four golden signals) esas alınır: gecikme (latency), trafik (traffic), hata (errors), doygunluk (saturation — kaynağın ne kadar dolu olduğu). Bunlar çoğu servisin sağlığını özetler.
- Metrikleri topla. Uygulama Prometheus'un okuyabileceği bir uç nokta (endpoint) sunsun.
- Panolar kur. Grafana'da bu metrikleri görselleştir.
- Alarm kuralları yaz. Bir eşik aşılınca kim, nasıl uyarılacak?
- Log'ları merkezileştir. Tüm servislerin logu tek yerde aranabilir olsun.
- Gürültüyü azalt. Çok fazla alarm, "alarm yorgunluğu" (alert fatigue) yaratır; önemli alarm kaybolur.
İpucu: İyi bir alarm iki şeyi karşılar: eyleme dönük (actionable) ve aciliyeti doğru. Gece 03:00'te birini uyandıran bir alarm, gerçekten gece müdahale gerektiren bir şey olmalı. "CPU %70" gibi tek başına eylem gerektirmeyen bir şey için kimseyi uyandırmayın; onu panoda gösterin.
Alarm kuralı nasıl yazılır?
Bir alarm üç bileşenden oluşur: koşul (hangi metrik hangi eşiği ne kadar süre aşarsa), süre (anlık dalgalanmalar tetiklemesin diye "5 dakika boyunca"), ve önem/aksiyon (kime, hangi kanaldan). YZ bu üçünü doğru bağlamla ustaca kurar. Örneğin "hata oranı 5 dakika boyunca %5'i aşarsa kritik alarm" gibi bir kuralı PromQL'e çevirmek YZ için saniyelik iştir — ama eşiğin sizin sisteminiz için doğru olup olmadığına siz karar verirsiniz.
Dikkat: YZ'nin önerdiği alarm eşikleri genel varsayımlardır. Sizin sisteminizin normal yükü, toleransı ve iş etkisi farklıdır. Bir eşiği doğrudan prod'a koymadan önce geçmiş verinize bakıp "bu eşik geçmişte kaç kez tetiklenirdi, bunların kaçı gerçek sorundu?" sorusunu yanıtlayın.
Log gizliliği: kritik uyarı
Log'lar en sık gözden kaçan sızıntı kaynağıdır. Bir log satırı yanlışlıkla bir parolayı, bir kredi kartı numarasını, bir kişisel veriyi (KVKK/GDPR kapsamında) içerebilir. Bir YZ'ye analiz için log yapıştırırken:
- Hassas alanları maskeleyin. Token, parola, e-posta, kimlik numarası gibi değerleri <REDACTED> ile değiştirin.
- Örnek verin, tümünü değil. Bir milyon satır yerine temsili birkaç yüz satır çoğu zaman yeter.
- Kurum onaylı aracı tercih edin. Özellikle üretim log'ları için verisi eğitime gitmeyen araç kullanın.
Dört altın sinyal ve alarm tablosu
Sinyal
Ölçtüğü
Örnek alarm eşiği
Aciliyet
Gecikme (latency)
Yanıt süresi
p95 > 800 ms, 5 dk
Yüksek
Trafik (traffic)
İstek/sn
Ani %300 artış/düşüş
Orta
Hata (errors)
Başarısız istek oranı
> %5, 5 dk
Kritik
Doygunluk (saturation)
Kaynak doluluğu
Disk > %85
Yüksek
Üç mini vaka
Vaka 1 — 400 satır log 30 saniyede özetlendi. Bir servis yavaşlamıştı. Mühendis, maskelenmiş 400 satır log'u YZ'ye verip "tekrar eden hata örüntülerini ve zaman yoğunluğunu özetle" dedi. YZ, belirli bir dış API çağrısının her 30 saniyede zaman aşımına düştüğünü gösterdi. Kök neden 30 saniyede bulundu; elle log taramak yarım saat sürerdi.
Vaka 2 — alarm yorgunluğu çözüldü. Bir ekip günde 200 alarm alıyor, hepsini görmezden gelmeye başlamıştı — ta ki gerçek bir kesinti alarmı da gözden kaçana dek. YZ'ye tüm alarm kurallarını verip "hangileri eyleme dönük değil, hangileri birleştirilebilir?" diye sordular. Alarm sayısı günde 12'ye indi; artık her alarm ciddiye alınıyordu.
Vaka 3 — yanlış eşik erken yakalandı. YZ, disk için "%95 dolunca uyar" önerdi. Mühendis geçmiş veriye baktı: disk %95'e ulaştığında müdahale için çok az zaman kalıyordu. Eşiği %80'e çekip "büyüme hızına" dayalı ikinci bir alarm ekledi. Doğrulama, gerçek bir gece yarısı kesintisini önledi.
Dört kopyalanabilir şablon
1) Log özetleme (maskelenmiş):
Aşağıdaki log örneğini analiz et (hassas değerleri <REDACTED>ile maskeledim). Bana: (1) tekrar eden hata örüntülerini,(2) zaman içindeki yoğunlaşmayı, (3) en olası kök nedeni ve(4) doğrulamak için bakacağım 3 metriği ver. Log: [SATIRLAR]
2) Alarm kuralı üretme:
Prometheus/Alertmanager için bir alarm kuralı yaz: [METRİK][SÜRE] boyunca [EŞİK] aşarsa [ÖNEM] alarm üret. Kural eylemedönük olsun, açıklama (annotation) ve runbook bağlantısı alanıiçersin. PromQL'i açıkla ve bu eşiğin neden makul olduğunu yaz.
3) PromQL sorgusu yazma/açıklama:
Şunu ölçen bir PromQL sorgusu yaz: [ÖRN. son 5 dakikadaki 5xxhata oranı yüzdesi]. Sorguyu adım adım açıkla. Ardından budeğerin sağlıklı aralığının ne olması gerektiğini söyle.
4) Pano (dashboard) tasarımı:
[SERVİS] için bir Grafana panosu tasarla: dört altın sinyali(gecikme, trafik, hata, doygunluk) hangi panellerle göstermeliyim?Her panel için metrik, görselleştirme türü ve makul eşik çizgisiniöner. Amaç: bir nöbetçinin 10 saniyede sağlık durumunu görmesi.
Zayıf prompt / Güçlü prompt
Zayıf: "Şu logda ne var?" (ardından 5000 satır ham log, içinde token'lar)
Sonuç: hem secret sızdırırsınız hem de YZ hedefsiz, yüzeysel bir özet verir.
Güçlü: "Aşağıdaki 300 satırlık maskelenmiş log örneğinde tekrar eden hata örüntülerini ve zaman yoğunluğunu bul; en olası kök nedeni ve doğrulamak için bakacağım metrikleri söyle. Token'ları <REDACTED> yaptım."
Fark: ikinci istem maskelenmiş ve odaklı bir örnek verir, net bir analiz çıktısı ister; hem güvenli hem işe yarar.
Sık yapılan hatalar
- Log'u maskelemeden YZ'ye yapıştırmak. En sık secret/kişisel veri sızıntısı.
- Her şeye alarm kurmak. Alarm yorgunluğu, gerçek alarmı gömer.
- Eyleme dönük olmayan alarm. Kimsenin bir şey yapamayacağı uyarı gürültüdür.
- YZ'nin eşiğini sorgusuz kabul etmek. Eşik sizin sisteminizin geçmişine göre ayarlanmalı.
- Sadece metriğe bakmak. Log ve trace olmadan kök neden çoğu zaman bulunamaz.
- Alarm süresi (for) koymamak. Anlık dalgalanmalar yanlış alarm üretir.
Özetle
Gözlemlenebilirlik; metrik, log ve trace ile sistemin içini dışarıdan anlama yeteneğidir. Dört altın sinyal (gecikme, trafik, hata, doygunluk) çoğu servisin sağlığını özetler. YZ, PromQL sorgularını, alarm kurallarını ve panoları yazmakta ve büyük log yığınlarını özetleyip anormallik bulmakta çok güçlüdür. Ama alarm eşiklerini kendi sisteminizin geçmişine göre doğrulamak, alarmları eyleme dönük tutmak ve log'ları maskelemeden asla paylaşmamak sizin sorumluluğunuzdadır.
Uygulama görevi
Bir servisiniz (veya örnek bir servis) için: (1) "Alarm kuralı üretme" şablonuyla hata oranı için bir alarm kuralı ürettirin ve önerilen eşiği "geçmişte kaç kez tetiklenirdi?" sorusuyla sınayın; (2) elinizdeki bir log örneğini maskeleyip "Log özetleme" şablonuyla analiz ettirin; (3) çıkan en olası kök nedeni doğrulamak için hangi metriğe bakacağınızı not edin.
Kontrol listesi
- [ ] İzleyeceğim metrikleri dört altın sinyale göre seçtim.
- [ ] YZ'ye verdiğim tüm log'ları hassas alanlar açısından maskeledim.
- [ ] Her alarmın eyleme dönük ve doğru aciliyette olduğunu doğruladım.
- [ ] Alarm eşiklerini sistemimin geçmiş verisine göre sınadım.
- [ ] Alarmlara for (süre) ekleyerek anlık dalgalanmaları filtreledim.
- [ ] Kök neden için metrik + log + trace'i birlikte kullandım.