Küçük ekiplerde gözlemlenebilirlik: log, metrik ve alarmı sade tutmak
Gözlemlenebilirlik bir araç kataloğu değil; bozulunca kim neyi nasıl fark eder sorusuna verilen cevaptır. 3–20 kişilik ekipler için log, metrik ve alarmı abartmadan kurmanın pratik sırası.
Canlıya yeni çıkmış bir ürün veya birkaç kritik servisi olan ekipte sık görülen iki uç var: ya hiç alarm yok (müşteri haber verir), ya da her şey kırmızı yanıyor (kimse bakmıyor).
TW Bilişim olarak yazılım ve DevOps işlerinde gördüğümüz tablo: küçük ekibin ihtiyacı genelde “üç ayrı APM + tam tracing + 40 dashboard” değil; birkaç güvenilir sinyal, anlaşılır eşikler ve kim ne yapacak netliği.
Bu rehber, kendi uygulamasını veya müşteri için özel yazılımı işleten küçük ekipler içindir. Araç adları örnek; önemli olan düzen.
Önce “bozulunca ne olur?” — üç soru
Araç seçmeden önce bir sayfalık cevap yeter:
- Kullanıcı ne yaşar? (giriş yapamaz, sipariş düşmez, sayfa yavaşlar…)
- Bunu kim, ne kadar sürede fark etmeli?
- İlk müdahale kimde, yedek kim?
Bu üç soru net değilse ekstra metrik toplamak gürültü üretir. Gözlemlenebilirlik, olay anında ekibi yönlendirmek içindir; arşiv doldurmak için değil.
Üç katman: log, metrik, iz (trace)
Küçük ekip için pratik öncelik sırası:
- Log: ne oldu, hangi istek / kullanıcı / hata kodu?
- Metrik: sistem sağ mı? (hata oranı, gecikme, kuyruk boyu, disk, bellek)
- Trace: isteğin parçaları nerede yavaşladı? (servis sayısı artınca veya “neredeyse her şey yavaş” şikâyetinde)
İlk ayda çoğu ekip log + birkaç metrik ile idare eder. Trace’i “her mikroserviste zorunlu” diye dayatmak, tek monolith veya 2–3 serviste gereksiz maliyet olabilir.
Alarm: az, net, sahipsiz olmasın
İyi alarm üç özelliği taşır:
- Eylem çağırır: “bakılabilir” değil, “şimdi müdahale”
- Gürültüsü düşük: bilinen bakım pencereleri ve staging hariç
- Sahibi var: kim alacak, kim yedek
Başlangıç seti (örnek, uyarlanabilir):
| Sinyal | Örnek eşik | Not |
|---|---|---|
| HTTP 5xx oranı | 5 dk içinde belirgin yükselme | Yanlış pozitif için kısa pencere + min istek sayısı |
| p95 gecikme | Normalin belirgin üstü | Absolute ms yerine kendi baseline’ınız |
| Kuyruk / job birikimi | Sürekli artan derinlik | Batch işlerde “gece birikmesi” ayrı değerlendirilir |
| Disk / sertifika bitişi | % veya gün sayısı | Sessiz ama pahalı kaçırılanlar |
| “İş metriği” | Sipariş / form / senkron sıfırlanması | Saf altyapı metriklerinden daha erken haber verir |
“CPU %80” tek başına çoğu zaman zayıf bir alarmdır; iş etkisi yoksa gündüz gürültüsü üretir.
Log düzeni: arama yapılabilir olsun
Ham stdout yeterli değildir; küçük bir sözleşme işe yarar:
- Yapılandırılmış alanlar:
level,service,request_id,user_id(kişisel veri minimizasyonu ile),error_code - Prod’da debug seviyesi varsayılan kapalı
- PII / şifre / token loglanmaz
- Saklama süresi bilinçli (maliyet + KVKK / sözleşme)
request_id (veya correlation id) tek başına “müşteri şikâyetinden hataya” giden süreyi kısaltır; pahalı bir APM’den önce çoğu zaman daha yüksek getiri verir.
Dashboard: bir “durum” sayfası yeter
İlk hafta hedefi 40 panel değil, tek operasyon sayfası:
- Servis ayakta mı?
- Hata ve gecikme trendi
- Kuyruk / kritik job’lar
- Altyapı asgari (disk, sertifika, DB bağlantı)
Derin analiz panelleri sonradan, gerçek olaylardan öğrenilerek eklenir. “Olur da bakarız” panelleri bakılmayan panellerdir.
Maliyet ve gürültü: bilerek sınır koyun
Tam paket observability platformları güçlüdür; küçük ekipte erken alınan geniş paket çoğu zaman:
- yüksek ingest faturası,
- ayarlanmamış alarm gürültüsü,
- kimsenin sahiplenmediği dashboard yığını
üretebilir. Sade yol: önce mevcut stack’te (bulut sağlayıcı metrikleri, basit uptime, merkezi log) minimumu kurun; boşluk netleşince araç ekleyin.
Pratik checklist
| Madde | Net mi? | Not |
|---|---|---|
| Bozulunca kullanıcı etkisi yazılı | ☐ | Tek cümle |
| On-call / ilk müdahale sahibi | ☐ | Yedek isim de |
| Log’da request_id + seviye politikası | ☐ | PII yok |
| 3–7 kritik alarm | ☐ | Sahipsiz alarm yok |
| Tek durum dashboard’u | ☐ | Staging ayrı |
| Sertifika / disk / yedek bitiş uyarıları | ☐ | Sessiz riskler |
| Haftalık 15 dk: yanlış alarm temizliği | ☐ | Eşik güncelle |
SSS
APM şart mı? Hayır. Hata oranı, gecikme ve iyi log ile çoğu küçük ürün uzun süre idare eder. APM, “neredeyse her şey yavaş / hangi span?” sorusu sık gelince değerlenir.
OpenTelemetry şimdi mi? Standart faydalıdır; ama önce neyi ölçüp kime alarm vereceğinizi netleştirin. Enstrümantasyon, sahibi olmayan bir standartla başlamamalı.
Staging’de de aynı alarmlar mı? Genelde hayır. Staging’de daha gevşek veya kapalı; prod’da sıkı. Aksi halde ekip alarmı görmezden gelmeyi öğrenir.
İş metriği neden önemli? CPU yeşilken sipariş akışı durmuş olabilir. Bir-iki iş sinyali (form gönderimi, senkron job başarısı, kuyruk tüketimi) altyapı metriklerini tamamlar.
TW Bilişim bu konuda ne yapıyor? Mevcut uygulamaya uygun, abartısız izleme ve alarm düzeni kuruyoruz: az sinyal, net sahip, sürdürülebilir fatura. Amaç gösterişli bir observability vitrini değil; ekibinizin gerçekten baktığı bir işletim modeli bırakmak.
Sonuç
Sırayı basit tutun: etki ve sahip → log + birkaç metrik → az alarm → tek durum sayfası → gerekirse derin araçlar. Bu sıra netse platform seçimi ikincil kalır.
Canlı sisteminizde şu an kimin, neyi, nasıl fark ettiğini birlikte sadeleştirmek isterseniz: iletişim veya [email protected].