Sunucu İzleme (Monitoring) ve Alarm Mekanizmaları

Bir sunucunun çalışıyor görünmesi, gerçekten sağlıklı olduğu anlamına gelmez. CPU normal olabilirken disk gecikmesi kullanıcıları bekletebilir, bellek yeterli görünürken bir süreç sürekli yeniden başlayabilir veya uygulama ayakta olmasına rağmen dışarıdan erişilemeyebilir. Yaklaşık 10 yıldır sunucu, uygulama ve production operasyonlarıyla çalışırken en sık gördüğüm sorunlardan biri, ekiplerin çok sayıda grafik üretmesine rağmen doğru anda doğru alarmı alamamasıdır. Bu nedenle Sunucu İzleme (Monitoring) ve Alarm Mekanizmaları yalnızca CPU, RAM ve disk yüzdesine bakmaktan çok daha geniş bir reliability yaklaşımı olarak ele alınmalıdır. Bu rehberde hangi verilerin toplanması gerektiğini, bu verilerin nasıl yorumlanacağını, alarm eşiklerinin nasıl belirlenebileceğini ve gerçek bir production ortamında monitoring mimarisinin nasıl kurulabileceğini adım adım ele alacağız.

Özellikle sunucu monitoring ve alarm sistemi nasıl kurulur, Linux sunucu CPU RAM disk ve ağ kullanımı nasıl izlenir, Prometheus Grafana Zabbix sunucu izleme araçları karşılaştırması nasıl yapılır ve sunucu monitoring sisteminde threshold alert notification ve uptime takibi nasıl yapılır gibi soruların pratik karşılığını bulacaksınız. Amacımız yalnızca araç isimlerini sıralamak değildir. Bir alarmın neden oluştuğunu, kime gitmesi gerektiğini, hangi durumda gece on-call ekibini uyandırmasının mantıklı olduğunu ve hangi durumda yalnızca dashboard üzerinde kalmasının daha doğru olduğunu da konuşacağız. Ayrıca kurumsal sunucu izleme ve alarm sistemi kurulum hizmeti planlayan ekipler için mimari karar noktalarına değineceğiz. Sunucu monitoring ve sistem yönetimi danışmanlığı yakınımda şeklinde araştırma yapan ekiplerin de hizmet alırken hangi teknik kriterleri sorgulaması gerektiğini açıklayacağız.

Sunucu İzleme (Server Monitoring) Nedir?

Sunucu monitoring, bir sistemin durumunu düzenli olarak ölçmek, kaydetmek, yorumlamak ve anlamlı değişikliklerde ilgili kişilere haber vermek için kurulan teknik süreçlerin bütünüdür. Buradaki önemli nokta yalnızca veri toplamamaktır. Toplanan verinin bir davranışa, karara veya aksiyona dönüşmesi gerekir. Örneğin CPU kullanımının yüzde 92 olduğunu bilmek tek başına yeterli değildir. Bunun ne kadar sürdüğünü, kullanıcı yanıt sürelerini etkileyip etkilemediğini ve sistem kapasitesinin gerçekten tükendiğini anlamak gerekir. Sağlıklı monitoring, sunucuyu sayıların bulunduğu bir ekrandan çıkarıp anlaşılabilir bir operasyon sinyaline dönüştürür.

Monitoring Ne Anlama Gelir?

Monitoring, belirlediğiniz sistem göstergelerini sürekli veya periyodik olarak gözlemlemek anlamına gelir. Bu göstergeler CPU kullanımı, boş disk alanı, ağ trafiği, HTTP hata oranı veya veritabanı bağlantı sayısı olabilir. Ölçüm tek başına hedef değildir, çünkü ölçümün değeri karşılaştırma ve yorumlama ile ortaya çıkar. Bir metriğin normal davranışını bilirseniz sapmaları daha erken fark edebilirsiniz. İyi monitoring bu nedenle veri toplama, saklama, sorgulama, görselleştirme ve alarm üretme adımlarının birlikte çalışmasını gerektirir.

Sunucu Sağlığı Nasıl Ölçülür?

Sunucu sağlığını tek bir metrik üzerinden ölçmek sağlıklı değildir. CPU düşükken disk I/O darboğazı oluşabilir veya RAM boşken dış servis bağlantıları başarısız olabilir. Bu nedenle kaynak kullanımı, işletim sistemi davranışı, uygulama performansı, bağımlılıklar ve kullanıcı deneyimi birlikte incelenmelidir. Ben production sistemlerinde önce kullanıcının sistemi kullanıp kullanamadığını, ardından uygulama ve altyapı sinyallerini kontrol etmeyi tercih ederim. Böylece teknik bir dalgalanma ile gerçek kullanıcı etkisi arasındaki fark çok daha kolay anlaşılır.

Monitoring'in Temel Amaçları

Monitoring'in temel amacı ekiplerin sorunları kullanıcı bildiriminden önce fark edebilmesini sağlamaktır. Bunun yanında kapasite planlamak, performans darboğazlarını bulmak ve tekrarlanan incident'ların nedenlerini anlamak için de monitoring verileri kullanılır. İyi bir sistem yalnızca arıza sırasında değil, normal günlerde de değer üretir. Örneğin üç aylık disk büyüme trendi yeni kapasite ihtiyacını önceden gösterebilir. Monitoring bu yönüyle operasyonun hem erken uyarı sistemi hem de geçmiş davranış kaydıdır.

Availability

Availability, bir servisin beklenen zamanda erişilebilir olup olmadığını gösterir. Sunucu ping'e cevap veriyor olsa bile HTTP servisi cevap vermiyorsa kullanıcı açısından availability sorunu devam eder. Bu nedenle erişilebilirlik ölçümü kullanıcıya sunulan gerçek servise mümkün olduğunca yakın yapılmalıdır. HTTP status, response body ve bağlantı süresi birlikte kontrol edilebilir. Böyle bir yaklaşım yalnızca makinenin değil, sunulan hizmetin ayakta olup olmadığını gösterir.

Performance

Performance, sistemin taleplere ne kadar hızlı ve verimli cevap verdiğini ifade eder. Bir servis erişilebilir olabilir ancak kullanıcı her istek için sekiz saniye bekliyorsa teknik olarak ciddi bir sorun vardır. Response time, throughput, queue length ve resource saturation bu nedenle birlikte değerlendirilmelidir. Performans ölçümlerinde yalnızca ortalama değer kullanmak uç kullanıcıların yaşadığı yavaşlığı gizleyebilir. p95 ve p99 gibi percentile değerleri özellikle yoğun servislerde çok daha açıklayıcıdır.

Reliability

Reliability, sistemin beklenen davranışı ne kadar tutarlı biçimde sürdürebildiğini gösterir. Sürekli yeniden başlayan fakat sonunda cevap veren bir servis kısa süreli testlerde sağlıklı görünebilir. Ancak restart sayısı, hata oranı ve zaman içindeki kesintiler incelendiğinde güvenilirlik problemi fark edilir. Reliability yalnızca uptime yüzdesi değildir. Sistemin öngörülebilir davranması ve hata durumlarından kontrollü biçimde toparlanması da aynı ölçüde önemlidir.

Capacity

Capacity monitoring, mevcut kaynakların gelecek yük için yeterli olup olmadığını anlamaya yardımcı olur. Diskin bugün yüzde 65 dolu olması tek başına karar vermek için yeterli değildir. Son bir haftada her gün yüzde 3 büyüyorsa birkaç gün içinde kritik seviyeye ulaşabilir. CPU, bellek, disk, bağlantı havuzu ve network kapasitesi için trend analizi yapılabilir. Bu yaklaşım acil kaynak artırımlarının ve beklenmedik production kesintilerinin azaltılmasına yardımcı olur.

Security

Monitoring doğrudan güvenlik sistemi değildir ancak birçok güvenlik sinyalini erken fark etmeye yardımcı olabilir. Beklenmeyen bağlantı artışları, olağan dışı işlem sayısı veya bilinmeyen dış bağlantılar incelenmeye değer davranışlardır. Aynı şekilde disk alanının aniden tükenmesi kontrolsüz log üretimi veya istenmeyen bir süreç nedeniyle oluşabilir. Monitoring verileri güvenlik kontrollerini destekleyen operasyonel bağlam sağlar. Yine de erişim kontrolü, güvenlik kayıtları ve ilgili koruma mekanizmaları ayrı olarak tasarlanmalıdır.

Proaktif ve Reaktif Monitoring Arasındaki Fark

Reaktif monitoring, problem ortaya çıktıktan sonra durumu anlamaya odaklanır. Proaktif monitoring ise problem kullanıcıyı ciddi biçimde etkilemeden önce erken sinyalleri yakalamaya çalışır. Örneğin disk yüzde 100 olduğunda alarm almak reaktif, büyüme hızına göre üç gün içinde dolacağını tahmin etmek proaktif bir yaklaşımdır. Production ortamlarında iki yaklaşımın da yeri vardır. En iyi sonuç geçmiş verileri, kullanıcı etkisini ve kapasite trendlerini aynı monitoring tasarımında birleştirdiğinizde ortaya çıkar.

Monitoring ve Observability Arasındaki Fark

Monitoring ile observability çoğu zaman aynı anlamda kullanılsa da odakları farklıdır. Monitoring daha önce tanımlanmış ölçümler ve koşullar üzerinden sistemin durumunu takip eder. Observability ise beklemediğiniz bir davranış ortaya çıktığında elinizdeki telemetry verileriyle sistem içinde ne olduğunu araştırabilmenizi sağlar. Başka bir ifadeyle monitoring bildiğiniz sorunlar için güçlüdür, observability ise sebebi henüz bilinmeyen davranışları çözmenize yardım eder. İyi tasarlanmış production ortamlarında bu iki yaklaşım birbirinin alternatifi değil, tamamlayıcısıdır.

Monitoring Hangi Soruyu Cevaplar?

Monitoring çoğunlukla "Sistem beklediğimiz sınırlar içinde çalışıyor mu?" sorusunu cevaplar. CPU yüzde 90'ın üzerinde mi, disk kapasitesi kritik seviyeye yaklaştı mı veya HTTP hata oranı belirlenen eşiği geçti mi gibi sorular önceden tanımlıdır. Bunun avantajı hızlı karar alınabilmesidir. Dezavantajı ise yalnızca önceden düşündüğünüz koşulları güçlü biçimde yakalayabilmesidir. Beklenmeyen problemlerde daha geniş telemetry verisine ihtiyaç duyabilirsiniz.

Observability Hangi Soruyu Cevaplar?

Observability, "Bu sistem neden bu şekilde davranıyor?" sorusuna cevap üretmeyi amaçlar. Sorunun sebebi daha önce tanımlanmamış olsa bile metrics, logs ve traces üzerinden ilişki kurulabilir. Örneğin belirli bir deployment sonrasında yalnızca tek bölgedeki kullanıcıların gecikme yaşaması klasik bir threshold alarmında görünmeyebilir. Etiketler, trace verileri ve log korelasyonu sorunun belirli bir dependency üzerinde yoğunlaştığını gösterebilir. Böylece ekip yalnızca belirtileri değil, olayın teknik yolculuğunu da inceleyebilir.

Known Unknown ve Unknown Unknown Kavramları

Known unknown, oluşabileceğini bildiğiniz ancak ne zaman gerçekleşeceğini bilmediğiniz problemleri ifade eder. Disk dolması, CPU saturation veya certificate expiration buna iyi örneklerdir. Unknown unknown ise daha önce tahmin etmediğiniz hata biçimlerini anlatır. Bu durumlarda sabit alarm kuralları yetersiz kalabilir. Geniş telemetry, doğru etiketleme ve korelasyon yeteneği beklenmeyen problemlerin araştırılmasını kolaylaştırır.

Metrics, Logs ve Traces

Metrics sistem davranışını sayısal ve zaman serisi biçiminde gösterir. Logs belirli olayların ayrıntılı kayıtlarını sunar, traces ise tek bir isteğin servisler arasındaki yolculuğunu takip etmeye yardımcı olur. Bu üç veri türü tek başına faydalıdır ancak birlikte kullanıldığında çok daha güçlüdür. Örneğin p99 latency arttığında metric problemi gösterir, trace hangi serviste zaman kaybedildiğini gösterebilir ve log gerçek hata mesajını sağlayabilir. Production troubleshooting süresini azaltan en önemli alışkanlıklardan biri bu sinyaller arasında geçişi kolaylaştırmaktır.

Monitoring'den Observability'ye Geçiş

Monitoring'den observability'ye geçiş daha fazla grafik eklemek anlamına gelmez. Öncelikle telemetry verisinin anlamlı etiketlerle üretilmesi, servislerin birbirleriyle ilişkilendirilebilmesi ve deployment gibi değişikliklerin kayda alınması gerekir. Ardından metrics, logs ve traces arasında ortak resource bilgileri kullanılmalıdır. Her metriği toplamak yerine araştırma sırasında soruları cevaplayabilecek veri üretmek daha değerlidir. Bu geçiş operasyon kültürünü de etkiler, çünkü ekipler yalnızca alarm kapatmak yerine sistem davranışını anlamaya başlar.

Sunucu Monitoring Mimarisi Nasıl Çalışır?

Tipik bir monitoring mimarisinde sunuculardan veya uygulamalardan telemetry üretilir, merkezi bir sistem tarafından toplanır ve zaman serisi olarak saklanır. Daha sonra query katmanı bu verilerin sorgulanmasını sağlar. Dashboard bileşeni insanlara görsel görünürlük sunarken alert engine belirlenen kuralları değerlendirir. Alarm oluştuğunda notification manager doğru kanal ve ekibe yönlendirme yapar. Production seviyesinde bunun devamında incident management ve on-call süreçleri devreye girer.

Monitoring Agent / Exporter

Agent veya exporter, sunucu üzerindeki metrikleri monitoring sisteminin okuyabileceği biçime dönüştürür. Linux sistemlerinde CPU, memory, filesystem ve network verileri bu katmandan alınabilir. Exporter yaklaşımında veri çoğunlukla bir endpoint üzerinden sunulur. Agent yaklaşımında ise merkezi sunucuya aktif veri gönderimi de yapılabilir. Seçim güvenlik modeli, ağ erişimi ve kullanılan monitoring platformuna göre yapılmalıdır.

Metric Collector

Metric collector, farklı kaynaklarda üretilen metrikleri düzenli aralıklarla toplar. Bu katmanın çalışmaması yalnızca dashboard'un boş kalmasına değil, alarm sisteminin de körleşmesine neden olabilir. Bu nedenle collector'un kendisinin de izlenmesi gerekir. Scrape failure, latency ve target availability önemli monitoring sinyalleridir. Büyük yapılarda collector katmanı bölgesel veya servis bazlı dağıtılabilir.

Time-Series Database

Time-series database, zamana bağlı metriklerin saklandığı veri katmanıdır. Her ölçüm zaman damgası ve ilgili label bilgileriyle birlikte kaydedilir. Bu yapı "son 15 dakikadaki CPU kullanımı" veya "son 30 gündeki disk büyümesi" gibi sorguları mümkün kılar. Retention süresi storage ihtiyacını doğrudan etkiler. Yüksek cardinality ve gereksiz metrik toplama maliyeti hızla artırabileceği için veri modeli baştan planlanmalıdır.

Query Katmanı

Query katmanı, toplanan verinin anlamlı sorulara dönüştürülmesini sağlar. Örneğin tek bir CPU değerine bakmak yerine son beş dakikalık ortalamayı, belirli host grubunu veya belirli environment'ı sorgulayabilirsiniz. Prometheus tarafında PromQL bu ihtiyacı karşılar. İyi query tasarımı dashboard ve alarm doğruluğunu doğrudan etkiler. Bu nedenle sorgular mümkün olduğunca anlaşılır, test edilebilir ve tekrar kullanılabilir olmalıdır.

Dashboard

Dashboard, monitoring verilerinin insanlar tarafından hızlı yorumlanabilmesi için kullanılan görsel katmandır. İyi bir dashboard çok sayıda grafik göstermek yerine önemli soruları hızlı cevaplamalıdır. Kullanıcı etkisi, error rate, latency, saturation ve temel dependency durumları üst bölümlerde görülebilir. Ayrıntılı altyapı grafikleri troubleshooting sırasında alt seviyelerde kullanılabilir. Dashboard tasarımında ekranı doldurmak yerine karar vermeyi hızlandırmak hedeflenmelidir.

Alert Engine

Alert engine, belirlenen koşulların monitoring verisi üzerinde gerçekleşip gerçekleşmediğini değerlendirir. Bir koşul tek ölçümde aşılmış olabilir ancak hemen alarm üretmek her zaman doğru değildir. Bu nedenle belirli süre devam etme şartı kullanılabilir. Böylece kısa spike'ların oluşturduğu gereksiz bildirimler azaltılır. Alarm kuralları version control altında tutulduğunda değişikliklerin izlenmesi ve test edilmesi de kolaylaşır.

Notification Manager

Notification manager, oluşan alarmları doğru kişiye ve doğru kanala gönderen katmandır. Aynı incident nedeniyle yüzlerce alarm oluşursa grouping ve deduplication burada önemli hale gelir. Severity, service, team veya environment bilgisine göre farklı routing uygulanabilir. Bakım zamanlarında silence ve root cause durumlarında inhibition kullanılabilir. Bu katmanın hatalı yapılandırılması teknik olarak doğru bir alarmın yanlış kişiye gitmesine veya hiç ulaşmamasına yol açabilir.

Incident Management

Incident management, alarm üretildikten sonra problemin kontrollü biçimde yönetilmesini sağlayan süreçtir. Alarmın acknowledge edilmesi, sorumlunun belirlenmesi, kullanıcı etkisinin değerlendirilmesi ve iletişimin yürütülmesi bu kapsamdadır. Monitoring yalnızca incident başlangıcındaki detect aşamasını desteklemez. Mitigation ve recovery sırasında da sistem davranışının normale dönüp dönmediğini gösterir. Incident sonrası inceleme ise monitoring kurallarının geliştirilmesi için yeni veri üretir.

On-Call

On-call modeli, kritik production olaylarında müdahale sorumluluğunun belirli kişiler arasında planlı biçimde paylaşılmasını sağlar. Her alarmın on-call kişisine gönderilmesi doğru değildir. Yalnızca acil, önemli ve aksiyon alınabilir olayların page üretmesi gerekir. Diğer konular ticket veya mesai saatindeki bildirim kanallarına yönlendirilebilir. İyi on-call deneyimi kaliteli alarm tasarımının doğrudan sonucudur.

Pull ve Push Monitoring Modelleri

Monitoring sistemlerinde veri iki temel modelle taşınabilir. Pull modelinde merkezi sistem hedef endpoint'lere giderek veriyi kendisi çeker. Push modelinde agent veya uygulama veriyi merkezi sisteme gönderir. Her modelin ağ erişimi, discovery, kısa süreli işler ve güvenlik açısından farklı avantajları vardır. Production ortamında tek bir yaklaşımı her yere uygulamak yerine workload yapısına göre seçim yapmak daha sağlıklıdır.

Pull-Based Monitoring

Pull-based modelde monitoring sistemi belirli aralıklarla target endpoint'lerine istek gönderir. Böylece hangi target'ın ne zaman scrape edildiği merkezi tarafta kontrol edilir. Target erişilemiyorsa collector bunu ayrıca failure olarak görebilir. Bu model service discovery ile birleştiğinde dinamik altyapılarda güçlü bir yapı oluşturur. Ancak merkezi collector'un target'a ağ erişimi olması gerekir.

Prometheus Scrape Modeli

Prometheus scrape modelinde target'lar çoğunlukla HTTP üzerinden metrics endpoint'i sunar. Prometheus belirlenen scrape interval doğrultusunda bu endpoint'leri düzenli olarak okur. Başarısız scrape denemeleri de izlenebilir bir sinyal haline gelir. Service discovery sayesinde target listesi manuel olarak yönetilmek zorunda değildir. Bu yaklaşım özellikle cloud-native ve dinamik servis ortamlarında yaygın biçimde kullanılır.

Push-Based Monitoring

Push-based modelde telemetry kaynağı veriyi monitoring sistemine aktif olarak gönderir. Ağ topolojisinin merkezi sistemden sunucuya erişime izin vermediği senaryolarda bu model faydalı olabilir. Kısa ömürlü işler de tamamlanmadan önce sonuçlarını push ederek görünürlük sağlayabilir. Buna karşılık kaynak ortadan kaybolduğunda veri gelmemesi her zaman kolay yorumlanmayabilir. Bu nedenle heartbeat veya son başarılı veri zamanı gibi ek mekanizmalar kullanılmalıdır.

Pushgateway

Pushgateway özellikle kısa ömürlü batch job metriklerini Prometheus ekosistemine aktarmak için kullanılabilir. Job tamamlanmadan önce metriklerini Pushgateway'e gönderir ve Prometheus daha sonra buradan scrape eder. Uzun süre yaşayan servisleri doğrudan Pushgateway üzerinden izlemek genellikle doğru model değildir. Çünkü stale veri ve lifecycle yönetimi zorlaşabilir. Kullanım alanı job yapısı ve veri yaşam döngüsü dikkate alınarak seçilmelidir.

Agent-Based Telemetry

Agent-based telemetry modelinde sunucuya kurulan agent sistem verilerini toplayıp merkezi platforma iletebilir. Bu yaklaşım host discovery, log toplama ve özel kontroller gibi ek yetenekler sunabilir. Buna karşılık agent'ın güncellenmesi, konfigürasyonu ve güvenliği yönetilmelidir. Çok sayıda sunucuda merkezi configuration management süreçleri bu operasyon yükünü azaltır. Agent seçerken veri formatı kadar bakım modeli de değerlendirilmelidir.

Hangi Senaryoda Hangisi Kullanılmalı?

Uzun ömürlü servislerde ve merkezi collector'un target'lara erişebildiği ortamlarda pull modeli oldukça pratiktir. Kısa süreli job'larda veya belirli ağ kısıtlarında push modeli daha uygun olabilir. Hybrid mimari kullanmak da mümkündür. Ben seçim yaparken önce workload yaşam süresine, ardından network topolojisine ve failure tespit yöntemine bakarım. Model tercihi araç alışkanlığından ziyade operasyon ihtiyacına göre verilmelidir.

Whitebox ve Blackbox Monitoring

Whitebox monitoring sistemin içinden gelen metriklere bakarken blackbox monitoring sistemi dışarıdan bir kullanıcı gibi test eder. Bir sunucuda CPU, memory ve process durumunu görmek whitebox yaklaşımıdır. Dışarıdan HTTP isteği gönderip cevap alınıp alınmadığını kontrol etmek ise blackbox yaklaşımıdır. Bu iki yöntem farklı soruları cevaplar. Production güvenilirliği için ikisini birlikte kullanmak daha doğru sonuç verir.

Whitebox Monitoring Nedir?

Whitebox monitoring sistemin iç durumunu ayrıntılı biçimde izler. CPU zamanları, memory pressure, disk queue ve process bilgileri buna örnektir. Problem oluştuğunda neden araştırması için değerli veri sağlar. Ancak kullanıcı gerçekten sisteme erişebiliyor mu sorusunu tek başına cevaplayamaz. Bu nedenle iç sağlık sinyalleri dış erişim kontrolleriyle tamamlanmalıdır.

Blackbox Monitoring Nedir?

Blackbox monitoring servisin iç yapısını bilmeden dışarıdan test yapılmasını ifade eder. Bir web sitesine HTTP isteği göndermek, DNS çözümlemek veya belirli TCP portuna bağlantı kurmak örnek verilebilir. Bu yaklaşım gerçek kullanıcının karşılaşabileceği erişim problemlerini yakalamakta güçlüdür. Sunucu içindeki sebebi her zaman göstermez. Bu yüzden blackbox alarmından sonra whitebox verileri troubleshooting için kullanılır.

İç Sistem Sağlığı ile Kullanıcı Deneyimi Arasındaki Fark

İç sistem metriklerinin normal olması kullanıcı deneyiminin de normal olduğu anlamına gelmez. Firewall kuralı, DNS problemi veya load balancer hatası nedeniyle dış erişim kesilebilir. Tersine CPU yüksekliği görülmesine rağmen kullanıcı yanıt süreleri tamamen normal olabilir. Bu nedenle page kararlarında mümkün olduğunca kullanıcı etkisine yakın sinyaller tercih edilmelidir. İç kaynak metrikleri neden araştırmasında güçlü destek sağlar.

HTTP Probe

HTTP probe belirli bir endpoint'e istek göndererek status code, response time ve gerektiğinde response içeriğini doğrular. Yalnızca 200 status almak her zaman yeterli değildir. Uygulama hata sayfasını da 200 ile döndürebilir. Bu nedenle beklenen içerikten küçük bir doğrulama yapılması faydalı olabilir. Login gerektirmeyen kritik endpoint'ler uptime kontrolü için iyi başlangıç noktalarıdır.

TCP Probe

TCP probe belirli bir host ve porta bağlantı kurulup kurulamadığını test eder. HTTP olmayan servislerde erişilebilirliği kontrol etmek için kullanılabilir. Bağlantı kurulması uygulamanın tamamen sağlıklı olduğu anlamına gelmez. Yine de network path ve port erişimi hakkında hızlı bilgi verir. Daha yüksek seviye protokol testleriyle birlikte kullanıldığında daha anlamlıdır.

ICMP/Ping

Ping host'un ağ seviyesinde cevap verip vermediğini anlamaya yardımcı olur. Ancak birçok production ortamında ICMP engellenebilir veya düşük öncelikli işlenebilir. Ping başarısızlığı her zaman servis kesintisi anlamına gelmez. Aynı şekilde ping başarılı olsa bile uygulama erişilemez olabilir. Bu nedenle ping tek başına uptime ölçümü olarak kullanılmamalıdır.

DNS Probe

DNS probe alan adının doğru ve yeterince hızlı çözümlenip çözümlenmediğini kontrol eder. DNS hataları uygulama tamamen sağlıklı olsa bile kullanıcı erişimini engelleyebilir. Resolution time, failure rate ve beklenen kayıt değerleri izlenebilir. Birden fazla resolver üzerinden test yapmak bazı bölgesel problemleri ortaya çıkarabilir. DNS bağımlılığı kullanıcı yolculuğunun önemli bir parçası olarak ele alınmalıdır.

TLS Probe

TLS probe sertifikanın geçerlilik süresini, hostname uyumunu ve bağlantının başarılı kurulup kurulmadığını kontrol eder. Certificate expiration son derece öngörülebilir bir olaydır. Bu nedenle production kesintisine dönüşmeden haftalar önce alarm üretilebilir. Certificate chain problemleri de dış erişimi etkileyebilir. TLS kontrollerini blackbox monitoring akışına eklemek basit fakat etkili bir uygulamadır.

Neden İkisi Birlikte Kullanılmalı?

Blackbox monitoring kullanıcıya yakın semptomu, whitebox monitoring ise içerideki olası nedeni gösterir. Yalnızca blackbox kullanırsanız problem oluştuğunu bilir ancak nedenini hızlı bulamayabilirsiniz. Yalnızca whitebox kullanırsanız tüm kaynaklar normal görünürken kullanıcı erişim problemi yaşayabilir. Birlikte kullanıldıklarında incident triage süresi ciddi biçimde kısalır. Production monitoring tasarımında bu iki yaklaşımı ayrı katmanlar olarak düşünmek faydalıdır.

Hangi Sunucu Metrikleri İzlenmeli?

Linux sunucu CPU RAM disk ve ağ kullanımı nasıl izlenir sorusunun cevabı yalnızca dört grafik eklemek değildir. Kaynakların kullanım düzeyi, saturation belirtileri ve error sinyalleri birlikte değerlendirilmelidir. CPU, memory, disk ve network yanında process, file descriptor, uptime, clock ve fiziksel donanım durumu da önemlidir. Hangi metriklerin kritik olduğu sunucunun göreviyle değişebilir. Veritabanı sunucusuyla statik dosya servis eden bir makinenin alarm öncelikleri aynı olmak zorunda değildir.

CPU

CPU monitoring toplam kullanımın yanında user, system, idle, iowait ve steal gibi farklı zaman türlerini takip etmeyi gerektirir. Yüzde 90 CPU tek başına kötü bir durum değildir. Sistem bu yük altında beklenen latency ve throughput değerlerini sürdürebiliyorsa kaynak verimli kullanılıyor olabilir. Asıl sorun sürekli saturation, queue oluşumu veya kullanıcı etkisidir. CPU alarmı süre ve hizmet etkisiyle birlikte değerlendirilmelidir.

Memory

Memory monitoring yalnızca used yüzdesine bakılarak yapılmamalıdır. Linux kullanılmayan belleği page cache için değerlendirdiği için yüksek kullanım çoğu zaman normaldir. Available memory, swap activity, major page fault ve OOM sinyalleri daha anlamlı olabilir. Process bazlı memory büyümesi de leak tespitinde yardımcı olur. Alarm tasarımında gerçek memory pressure hedeflenmelidir.

Disk

Disk monitoring capacity ve performance olmak üzere iki ayrı açıdan yapılmalıdır. Filesystem doluluğu, inode kullanımı ve büyüme trendi kapasite tarafını gösterir. IOPS, throughput, latency, queue ve utilization ise performans tarafını açıklar. Diskte boş alan olması hızlı çalıştığı anlamına gelmez. Yoğun I/O altında yüksek latency uygulama performansını ciddi biçimde etkileyebilir.

Network

Network monitoring bandwidth kullanımından daha geniştir. Packet loss, latency, interface error, drop, retransmission ve connection count birlikte değerlendirilebilir. Network kapasitesi düşük kullanılmasına rağmen packet loss nedeniyle uygulama yavaşlayabilir. TCP retransmission artışı özellikle dependency erişim sorunlarında değerli bir sinyaldir. Servisin network davranışı trafik profiline göre izlenmelidir.

Load

Linux load average çalışan veya CPU ve bazı I/O kaynakları için bekleyen işlerin yoğunluğunu anlamaya yardımcı olur. Değer tek başına CPU yüzdesi değildir. Core sayısı yorumlama sırasında dikkate alınmalıdır. Load yükselirken CPU düşükse I/O bekleyen process'ler incelenebilir. Alarm yalnızca sabit bir load değerine değil, süre ve sistem kapasitesine göre tasarlanmalıdır.

Process

Kritik process'lerin varlığı, kaynak kullanımı ve restart davranışı izlenmelidir. Bir process çalışıyor görünebilir ancak gerçek işlevini yerine getiremeyebilir. Bu nedenle process monitoring servis seviyesindeki health check ile tamamlanmalıdır. Sürekli restart sayısı configuration veya dependency problemine işaret edebilir. Process metriği özellikle incident sırasında altyapı ile uygulama arasında bağ kurar.

File Descriptor

File descriptor limitlerinin tükenmesi bağlantı kabul edememe gibi ciddi problemlere yol açabilir. Açık dosya ve socket sayısı özellikle yoğun network servislerinde izlenmelidir. Mevcut kullanımın sistem veya process limitine oranı takip edilebilir. Sürekli yükselen kullanım leak belirtisi olabilir. Limit aşılmadan önce trend üzerinden warning üretmek mümkündür.

System Uptime

System uptime beklenmeyen reboot olaylarını tespit etmek için kullanılabilir. Tek başına yüksek uptime bir kalite göstergesi değildir. Ancak kısa sürede tekrarlanan reboot veya beklenmeyen uptime sıfırlanması önemlidir. Deployment ve maintenance kayıtlarıyla korele edildiğinde anlamlı hale gelir. Uptime verisi incident timeline oluştururken de yardımcı olur.

Clock/Time

Sistem saatinin doğru olması dağıtık sistemler için oldukça önemlidir. Büyük clock drift authentication, certificate ve log correlation problemleri oluşturabilir. NTP veya benzeri time synchronization durumunun izlenmesi faydalıdır. Saat kayması traces ve olay zaman çizelgesini de yanıltabilir. Özellikle birçok servis arasında veri ilişkilendirilen ortamlarda time health ayrı metrik olarak düşünülmelidir.

Hardware Health

Fiziksel sunucularda işletim sistemi metrikleri donanımın tamamını göstermez. Disk SMART, RAID, power supply, fan, temperature ve ECC memory durumları ayrıca izlenmelidir. Bazı arızalar işletim sisteminde performans sorunu oluşmadan önce donanım yönetim katmanında görülebilir. IPMI veya Redfish gibi arayüzler bu noktada değerlidir. Fiziksel altyapı kullanan ekipler hardware monitoring'i ana mimarinin parçası yapmalıdır.

CPU Monitoring

CPU monitoring doğru yorumlanmadığında gereksiz alarmın en büyük kaynaklarından biri olabilir. Yüksek CPU her zaman problem değildir ve düşük CPU da sistemin sağlıklı olduğunu kanıtlamaz. CPU zamanının hangi iş türlerinde harcandığını ve taleplerin kuyrukta bekleyip beklemediğini anlamak gerekir. Özellikle sanal makinelerde steal time, storage ağırlıklı işlerde ise iowait dikkatle izlenmelidir. Alarm kararını kullanıcı latency ve error rate gibi üst seviye göstergelerle ilişkilendirmek daha güvenilir sonuç verir.

CPU Utilization

CPU utilization işlemcinin belirli zaman aralığında ne kadar meşgul olduğunu gösterir. Kısa süreli yüzde 100 kullanımlar birçok sistemde normal olabilir. Sorun değerin uzun süre yüksek kalması ve işlerin beklemeye başlamasıdır. Core sayısı ve workload türü yorumlamayı etkiler. Alarm için tek snapshot yerine birkaç dakikalık pencere kullanılmalıdır.

User CPU

User CPU uygulamaların user space içinde harcadığı işlemci zamanını gösterir. Ani artış yoğun trafik veya hesaplama ağırlıklı işlerden kaynaklanabilir. Deployment sonrası kalıcı artış kod değişikliğini incelemek için işaret olabilir. Kullanıcı yanıt süreleri normalse yüksek user CPU doğrudan page gerektirmeyebilir. Capacity planning açısından trend olarak izlenmesi yine de değerlidir.

System CPU

System CPU kernel işlemlerine harcanan zamanı gösterir. Network, disk ve yoğun system call kullanan işlerde artabilir. Beklenmedik artışlarda interrupt, context switch ve I/O davranışları birlikte incelenmelidir. Uygulama CPU'su düşük olduğu halde system CPU yüksekse altyapı tarafına bakmak gerekir. Normal baseline servis türüne göre farklılık gösterebilir.

Idle CPU

Idle CPU işlemcinin iş yapmadan geçirdiği zaman oranını gösterir. Düşük idle değeri CPU'nun yoğun olduğunu anlatır ancak tek başına problem kanıtı değildir. Sistem talepleri beklemeden işleyebiliyorsa CPU kapasitesi verimli kullanılıyor olabilir. Sürekli sıfıra yakın idle ile artan queue birlikte görülüyorsa saturation olasılığı yükselir. Bu nedenle idle değeri latency ve load ile birlikte yorumlanmalıdır.

I/O Wait

I/O wait CPU'nun I/O işlemlerinin tamamlanmasını beklediği zamanı gösterir. Yüksek değer genellikle storage veya bazı network filesystem problemlerini araştırmayı gerektirir. CPU düşük göründüğü halde uygulama yavaşsa iowait önemli bir ipucu olabilir. Disk latency ve queue metrikleriyle korelasyon yapılmalıdır. Böylece problemi işlemci kapasitesi sanıp yanlış kaynak artırımı yapılması önlenebilir.

CPU Steal

CPU steal sanal makinenin çalışmak istediği ancak hypervisor'un CPU zamanını başka workload'lara ayırdığı süreyi gösterir. Yüksek steal değeri uygulamanın kendi CPU kullanımından bağımsız performans kaybı oluşturabilir. Özellikle yoğun paylaşımlı sanallaştırma ortamlarında takip edilmelidir. Kullanıcı latency artarken guest içindeki CPU metrikleri normal görünüyorsa steal incelenebilir. Kalıcı yüksek değer altyapı kapasitesi veya yerleşim sorununa işaret edebilir.

Context Switch

Context switch işletim sisteminin CPU üzerinde çalışan thread veya process arasında geçiş yapmasını ifade eder. Yüksek sayılar tek başına hata değildir. Ancak baseline'a göre ani ve kalıcı artış concurrency veya scheduling problemini gösterebilir. CPU saturation ve system CPU ile birlikte değerlendirilmelidir. Uygulama değişiklikleri sonrasındaki context switch değişimi troubleshooting açısından faydalı olabilir.

CPU Saturation

CPU saturation, yapılacak işin mevcut CPU kapasitesini aşıp beklemeye başlamasıdır. Bu durumda utilization yüksekliği yanında run queue artışı görülebilir. Kullanıcı taleplerinde latency yükselmesi saturation etkisini doğrulayabilir. Sadece yüzde kullanıma göre alarm üretmek bu ayrımı yakalayamaz. USE Method kapsamında utilization ve saturation birlikte izlenmelidir.

Yüksek CPU Ne Zaman Gerçek Bir Problemdir?

Yüksek CPU uzun süre devam ediyor, run queue büyüyor ve kullanıcı latency artıyorsa gerçek problem olma ihtimali yüksektir. Error rate veya timeout artışı da etkilenmenin güçlendiğini gösterir. Buna karşılık kısa süreli batch işlemleri sırasında yüzde 100 CPU beklenen davranış olabilir. Ben alarm tasarlarken yüzde değerinden önce sistemin iş hedefini ve kullanıcı etkisini düşünürüm. Bu yaklaşım gereksiz page sayısını ciddi biçimde azaltır.

Linux Load Average Nasıl Yorumlanır?

Load average Linux sistemlerinde sık görülen fakat sık yanlış yorumlanan göstergelerden biridir. Değer CPU kullanım yüzdesini göstermez. Çalışmaya hazır olan ve belirli kaynakları bekleyen görevlerin yoğunluğu hakkında bilgi verir. Yorum yaparken CPU core sayısı ve sistemin I/O davranışı mutlaka dikkate alınmalıdır. Tek bir threshold yerine tarihsel baseline ve kullanıcı etkisiyle birlikte değerlendirmek daha sağlıklıdır.

1, 5 ve 15 Dakikalık Load Average

Load average genellikle 1, 5 ve 15 dakikalık ortalamalar halinde gösterilir. Bir dakikalık değer güncel değişimlere daha hızlı tepki verir. On beş dakikalık değer ise trend hakkında daha stabil fikir sunar. Bir dakikalık değer yüksek, on beş dakikalık değer düşükse yeni başlayan kısa yük artışı olabilir. Üç değerin birlikte yükselmesi daha kalıcı baskıya işaret edebilir.

CPU Core Sayısı ile İlişkisi

Load değerini yorumlarken logical CPU veya core kapasitesi göz önünde bulundurulmalıdır. Tek core sistemde load 4 ile sekiz core sistemde load 4 aynı anlama gelmez. Çok çekirdekli sistem daha fazla işi paralel işleyebilir. Bu nedenle threshold tasarımında normalize edilmiş load kullanmak faydalı olabilir. Sabit load değeri tüm sunuculara uygulanmamalıdır.

Load Average = CPU Kullanımı mı?

Load average CPU kullanım yüzdesi değildir. Çalışan ve bazı bekleme durumundaki görevlerin sayısını temsil eden farklı bir göstergedir. CPU yüzde 30 iken yüksek load görülebilir. Böyle bir durumda I/O bekleyen process'ler araştırılabilir. CPU metriğiyle load metriğini birbirinin yerine kullanmak yanlış teşhise neden olabilir.

I/O Bekleyen Process'lerin Etkisi

Disk veya diğer I/O kaynaklarını bekleyen process'ler load değerini yükseltebilir. Bu nedenle yüksek load görüldüğünde CPU utilization düşükse storage metrikleri incelenmelidir. Disk latency, queue ve iowait burada değerli ipuçlarıdır. Uygulamanın kendi CPU kullanımı normal olabilir. Sorun bekleme süresinden kaynaklanıyorsa CPU artırmak problemi çözmez.

Load Alarmı Nasıl Tasarlanmalı?

Load alarmı core sayısı, duration ve sistem baseline'ı dikkate alınarak tasarlanmalıdır. Tek bir saniyelik veya kısa spike için page göndermek gereksiz gürültü yaratır. Normalize edilmiş load belirli süre yüksek kalıyorsa warning üretilebilir. Kullanıcı latency veya saturation sinyali de varsa severity yükseltilebilir. Alarm metninde mevcut load, core sayısı ve ilgili dashboard bağlantısı bulunması müdahaleyi hızlandırır.

Memory Monitoring

Linux bellek yönetimi cache kullanımını aktif biçimde değerlendirdiği için memory monitoring yüzdelik değerlerle sınırlanmamalıdır. Sistem RAM'i boş bırakmak yerine filesystem verilerini cache içinde tutabilir. Bu davranış performans açısından faydalıdır ve ihtiyaç olduğunda cache alanı uygulamalara geri verilebilir. Asıl takip edilmesi gereken available memory, swap activity, memory pressure ve OOM riskidir. Process bazındaki uzun süreli büyüme de memory leak araştırmasında önemlidir.

Total Memory

Total memory sistemin erişebildiği toplam fiziksel belleği gösterir. Tek başına performans göstergesi değildir. Capacity planning ve diğer bellek oranlarının hesaplanması için temel referans sağlar. Sanal makinelerde tahsis edilen miktar workload ihtiyacıyla karşılaştırılmalıdır. Uzun vadeli kapasite trendleri total değer bağlamında değerlendirilmelidir.

Used Memory

Used memory Linux üzerinde dikkatli yorumlanmalıdır. Page cache nedeniyle yüksek görünmesi normal olabilir. Yüzde 90 used değerini doğrudan kritik alarm yapmak sık rastlanan hatalardan biridir. Available memory ve swap davranışı daha fazla bağlam sağlar. Kullanıcının yaşadığı performans etkisiyle ilişkilendirilmediğinde gereksiz bildirim üretebilir.

Available Memory

Available memory sistemin yeni uygulama talepleri için kullanabileceği belleğe daha yakın bir göstergedir. Reclaim edilebilecek cache alanını da hesaba kattığı için used değerinden daha anlamlı olabilir. Sürekli azalması memory pressure riskine işaret edebilir. Swap ve page fault metrikleriyle birlikte izlenmesi gerekir. Alarm threshold'u workload'un normal davranışına göre belirlenmelidir.

Page Cache

Linux page cache sık erişilen dosya verilerini bellekte tutarak disk erişimini azaltır. Bu nedenle cache'in yüksek olması çoğu zaman iyi bir davranıştır. Uygulama belleğe ihtiyaç duyduğunda işletim sistemi cache'in bir bölümünü serbest bırakabilir. Monitoring sırasında cache'i gereksiz bellek tüketimi olarak yorumlamak hatalıdır. Available memory yaklaşımı bu nedenle daha güvenilir bağlam sunar.

Buffer

Buffer alanları işletim sisteminin I/O işlemlerini yönetmesine yardımcı olur. Sistem davranışına göre miktarı zaman içinde değişebilir. Tek başına buffer yüksekliği alarm nedeni değildir. Memory pressure değerlendirilirken daha geniş bellek dağılımının parçası olarak incelenmelidir. İş yükünün I/O profili bu değerin normal seviyesini etkileyebilir.

Swap

Swap kullanımı fiziksel bellek yetersizliğinde veya kernel bellek yönetimi tercihlerinde devreye girebilir. Bir miktar swap kullanımı her zaman kritik problem değildir. Daha önemli sinyal yoğun swap in ve swap out aktivitesidir. Bu davranış latency artışıyla birlikte görülüyorsa memory pressure ciddi hale gelmiş olabilir. Alarm tasarımında swap yüzdesinden çok aktivite ve kullanıcı etkisi değerlendirilmelidir.

Memory Pressure

Memory pressure sistemin mevcut bellek ihtiyacını karşılamakta zorlandığını ifade eder. Available memory azalması, swap aktivitesi ve reclaim davranışları birlikte incelenebilir. Uzun süreli pressure performans sorunlarına ve OOM riskine dönüşebilir. Uygulama latency artışı etkilenmenin kullanıcı tarafındaki karşılığını gösterir. Memory alarmı yalnızca doluluk yerine bu baskıyı hedeflemelidir.

OOM Killer

OOM Killer sistem kullanılabilir belleği ciddi biçimde tükendiğinde bazı process'leri sonlandırabilir. Production servisinin OOM nedeniyle kapanması çoğu durumda kritik incident olarak ele alınmalıdır. Kernel logları ve process restart metrikleri bu olayı doğrulayabilir. Alarmda etkilenen process ve host bilgisi bulunmalıdır. Sonrasında memory limitleri, leak ihtimali ve workload büyümesi araştırılmalıdır.

Memory Leak

Memory leak bir process'in zamanla sürekli bellek biriktirip geri bırakmaması durumudur. Anlık kullanım değerinden çok uzun süreli trend burada daha değerlidir. Deployment sonrası başlayan doğrusal büyüme önemli bir işaret olabilir. Restart problemi geçici olarak gizlese de kök nedeni çözmez. Process memory metriğini deployment annotation ile birlikte izlemek araştırmayı kolaylaştırır.

Neden "RAM %80 Dolu" Tek Başına İyi Bir Alarm Değildir?

RAM yüzde 80 dolu alarmı Linux sistemlerinin bellek yönetim biçimini yeterince dikkate almaz. Page cache nedeniyle bellek bilinçli biçimde dolu tutulabilir. Kullanılabilir bellek yeterliyse ve swap baskısı yoksa yüksek used değeri normal olabilir. Buna karşılık used yüzde 70 görünürken yoğun swap veya OOM riski yaşanabilir. Bu nedenle alarmın hedefi doluluk değil, gerçek memory pressure ve kullanıcı etkisi olmalıdır.

Linux Page Cache

Page cache disk verisini RAM üzerinde tutarak erişimi hızlandırır. Bu alan ihtiyaç halinde reclaim edilebilir. Yüksek cache kullanımı bu yüzden tek başına problem sayılmamalıdır. Monitoring panelinde used ve cache değerlerini ayrı görmek yorumlamayı kolaylaştırır. Alarm tasarımında reclaim edilebilir belleği yok saymak false positive üretir.

Available Memory

Available memory yeni workload için ne kadar alan bulunduğu konusunda daha anlamlı bilgi sağlar. Sistem cache'in bir kısmını serbest bırakabileceği için gerçek kullanılabilir kapasiteyi daha iyi temsil eder. Değer sürekli kritik seviyede kalıyorsa pressure riski artar. Swap activity ile birlikte yorumlanmalıdır. Alarm süresi birkaç dakikalık pencere ile doğrulanabilir.

Swap Activity

Swap alanının doluluk oranından çok aktif kullanım hızı önemlidir. Sürekli page'lerin disk ile RAM arasında taşınması ciddi performans kaybı yaratabilir. Swap in ve swap out metrikleri bu davranışı gösterir. Uygulama latency ile korelasyon yapılması faydalıdır. Yoğun swap trafiği memory sizing veya application davranışının incelenmesini gerektirir.

Major Page Fault

Major page fault gereken verinin bellekte bulunmayıp storage üzerinden okunmasını gerektirir. Oranın artması bazı workload'larda performans etkisi oluşturabilir. Tek başına alarm nedeni olmadan önce baseline ile karşılaştırılmalıdır. Memory pressure ve disk latency ile birlikte değerlendirilmesi daha anlamlıdır. Ani artış deployment veya workload değişikliğine bağlanabilir.

OOM Riski

OOM riski available memory, pressure, swap ve process büyümesinin birlikte değerlendirilmesiyle daha iyi anlaşılır. Geçmişte yaşanan OOM olayları threshold tasarımına referans olabilir. Kritik service OOM'a yaklaşırken warning yerine doğrudan yüksek severity gerekebilir. Ancak alarmın gerçekten aksiyon alınabilir olması gerekir. Runbook içinde hangi process'lerin kontrol edileceği ve güvenli mitigation adımları belirtilmelidir.

Kullanıcı Etkisini Ölçmek

Memory baskısının kullanıcı tarafındaki karşılığı latency, error rate, timeout veya restart şeklinde görülebilir. Bu sinyaller memory metriğiyle birlikte olduğunda alarmın önemi daha net anlaşılır. Bir kullanıcı etkisi yoksa kaynak alarmı ticket seviyesinde tutulabilir. Etki belirginleşirse page severity yükseltilebilir. Böylece on-call ekibine giden alarmlar daha anlamlı hale gelir.

Disk Monitoring

Disk monitoring yalnızca boş alan grafiği değildir. Capacity, inode, throughput, IOPS, latency, queue ve utilization birlikte ele alınmalıdır. Uygulama disk alanı bol olduğu halde storage latency nedeniyle yavaşlayabilir. Tersine disk performansı iyi olsa bile filesystem birkaç saat içinde dolabilir. Bu nedenle kapasite ve performans sinyalleri ayrı alarm mantıklarıyla izlenmelidir.

Disk Space

Disk space filesystem üzerinde kullanılan ve boş kapasiteyi gösterir. Kritik bölümlerin ayrı ayrı izlenmesi gerekir. Root filesystem ile application data diskinin risk profili farklı olabilir. Log büyümesi kısa sürede alan tüketebilir. Alarmda kalan GB bilgisi yüzde değerle birlikte verilmelidir.

Filesystem Usage

Filesystem usage mount point bazında takip edilmelidir. Toplam disk alanına bakmak farklı filesystem sınırlarını gizleyebilir. Bir bölüm dolarken başka bölüm boş olabilir. Read-only mount durumu da ayrıca kontrol edilmelidir. Kritik mount point'ler owner ve service bilgileriyle eşleştirilmelidir.

Inode Kullanımı

Filesystem boş alanı yeterli olsa bile inode tükenmesi yeni dosya oluşturulmasını engelleyebilir. Çok sayıda küçük dosya üreten sistemlerde bu risk daha yüksektir. Inode kullanım oranı ayrı metric olarak izlenmelidir. Yüzde ve remaining inode birlikte gösterilebilir. Log veya cache dizinlerinde beklenmeyen dosya artışı erken fark edilebilir.

Disk Read/Write Throughput

Throughput disk üzerinden saniyede taşınan veri miktarını gösterir. Workload'un normal I/O profiliyle karşılaştırıldığında değer kazanır. Yüksek throughput tek başına sorun değildir. Storage limitine yaklaşma veya latency artışıyla birlikte değerlendirilmelidir. Capacity planlama sırasında peak değerler ayrıca analiz edilmelidir.

IOPS

IOPS saniyedeki I/O operasyon sayısını ifade eder. Küçük random I/O kullanan workload'larda throughput'tan daha açıklayıcı olabilir. Storage platformunun desteklediği kapasite ile mevcut kullanım karşılaştırılmalıdır. IOPS limite yaklaşırken latency artabilir. Alarm yalnızca nominal limit değil gerçek saturation sinyali üzerinden tasarlanmalıdır.

Disk Latency

Disk latency I/O işlemlerinin tamamlanma süresini gösterir. Kullanıcı response time üzerinde doğrudan etkisi olabilir. Normal değer storage türüne ve workload'a göre değişir. Bu nedenle tüm diskler için aynı threshold kullanmak doğru değildir. Baseline'dan kalıcı sapmalar daha anlamlı alarm üretebilir.

I/O Queue

I/O queue disk işlemlerinin kaynak bekleyip beklemediğini anlamaya yardımcı olur. Kuyruğun sürekli büyümesi storage saturation göstergesi olabilir. Latency ve utilization ile birlikte incelenmelidir. Kısa burst'ler bazı workload'larda normaldir. Uzun süreli queue artışı kullanıcı gecikmesiyle birleşiyorsa müdahale gerekir.

Disk Utilization

Disk utilization cihazın ne kadar meşgul olduğunu gösterir. Yüzde 100 değer modern storage yapılarında tek başına yorumlanmamalıdır. Paralellik ve device tipi önemlidir. Latency, queue ve throughput ile birlikte bakılmalıdır. Alarm kararında uygulamanın gerçekten yavaşlayıp yavaşlamadığı da değerlendirilmelidir.

Disk Doluluk Alarmı Nasıl Tasarlanmalı?

Disk alarmında yalnızca yüzde 85 gibi sabit bir eşik kullanmak çoğu ortamda yeterli değildir. Yüzde 15 boş alan 100 GB disk ile 20 TB disk üzerinde çok farklı miktarlara karşılık gelir. Ayrıca büyüme hızı kritik seviyeye ne zaman ulaşılacağını belirler. Bu nedenle remaining capacity ve time-to-full hesaplamaları alarm kalitesini artırır. Warning ve critical seviyeleri müdahale süresi dikkate alınarak ayrılmalıdır.

Sabit Yüzde Threshold Problemi

Sabit yüzde threshold yönetimi kolaydır fakat her kapasite için aynı anlamı taşımaz. Büyük disklerde yüzde 10 boş alan günlerce veya aylarca yeterli olabilir. Küçük disklerde aynı oran birkaç dakika içinde tükenebilir. Growth rate dikkate alınmadan yapılan alarm gerçek riski göstermez. Threshold tasarımına kalan kapasite ve tüketim hızı eklenmelidir.

Remaining Capacity

Remaining capacity gerçekte kaç GB veya TB alan kaldığını gösterir. Operasyon ekibi için yüzde değerinden daha somut olabilir. Özellikle büyük storage sistemlerinde mutlak kapasite kritik bir sinyaldir. Alarm mesajında kalan alan bilgisi yer almalıdır. Böylece müdahale eden kişi risk seviyesini daha hızlı değerlendirebilir.

Growth Rate

Growth rate belirli süre boyunca disk kullanımının ne hızla arttığını gösterir. Ani log patlamalarını veya veri büyümesini erken fark etmeye yardımcı olur. Günlük, saatlik veya haftalık trend workload'a göre seçilebilir. Tek seferlik spike ile kalıcı büyüme birbirinden ayrılmalıdır. Forecasting için yeterli geçmiş veri tutulması faydalıdır.

Time-to-Full Tahmini

Time-to-full mevcut büyüme hızına göre diskin ne zaman dolabileceğini tahmin eder. Yüzde düşük görünse bile hızlı büyüyen filesystem için erken alarm üretebilir. Tahmin çok dalgalı workload'larda dikkatli yorumlanmalıdır. Belirli minimum veri penceresi kullanılabilir. Operasyon açısından "48 saat içinde dolacak" bilgisi yüzde 82 kullanımından daha aksiyon odaklıdır.

Warning ve Critical Threshold

Warning seviyesi ekibin mesai içinde plan yapabilmesi için yeterli süre bırakmalıdır. Critical ise gerçek hizmet riskinin yakın olduğunu göstermelidir. İki threshold arasındaki fark yalnızca yüzde olmak zorunda değildir. Time-to-full ve remaining capacity birlikte kullanılabilir. Böylece alarm seviyesi gerçek müdahale aciliyetine daha yakın olur.

Büyük Disklerde Yüzde Bazlı Alarm Riski

Büyük disklerde küçük bir yüzde bile çok yüksek mutlak kapasiteye karşılık gelebilir. Bu nedenle yüzde 90 alarmı gereksiz erken çalışabilir. Ters durumda hızla büyüyen bir volume yüzde 70 seviyesindeyken daha ciddi risk taşıyabilir. Remaining GB ve growth rate birlikte değerlendirilmelidir. Capacity alarmını gerçek operasyon süresine göre tasarlamak daha mantıklıdır.

Donanım ve Fiziksel Sunucu Monitoring

Fiziksel sunucu kullanan ortamlarda işletim sistemi telemetry'si donanım sağlığının tamamını kapsamaz. Disk, RAID controller, PSU, fan, sıcaklık ve ECC memory gibi bileşenler ayrı izlenmelidir. Bazı donanım arızaları performansa yansımadan önce management interface üzerinden görülebilir. IPMI ve Redfish bu tür verileri merkezi monitoring sistemine taşımak için kullanılabilir. Donanım sinyalleri özellikle veri merkezi ve on-prem ortamlarında incident öncesi erken uyarı sağlar.

SMART Disk Health

SMART disklerin belirli sağlık göstergelerini sunar. Reallocated sector, pending sector veya benzeri değerler disk problemlerine işaret edebilir. Her SMART metriğini doğrudan page'e çevirmek yerine gerçek failure riskini değerlendirmek gerekir. RAID yapısı varsa controller durumu da ayrıca incelenmelidir. Disk değişim prosedürü runbook içinde tanımlı olmalıdır.

RAID Status

RAID degraded durumda çalışmaya devam edebilir ancak redundancy seviyesi düşmüş olabilir. Bu nedenle degraded array önemli alarm üretmelidir. Rebuild süreci ve rebuild ilerlemesi de izlenebilir. İkinci disk arızası veri kaybı riskini artırabilir. Alarm mesajında array ve disk bilgileri bulunması müdahaleyi hızlandırır.

Power Supply

Redundant power supply bulunan sistemlerde tek PSU arızası sunucuyu hemen kapatmayabilir. Ancak redundancy kaybolduğu için risk yükselir. PSU status management interface üzerinden izlenebilir. Planned maintenance sırasında doğru silence uygulanmalıdır. Sürekli görmezden gelinen PSU alarmı gerçek arıza anında ciddi kesintiye dönüşebilir.

Fan

Fan problemleri sıcaklık artışına ve donanımın kendini korumak için performans azaltmasına yol açabilir. Fan speed ve health bilgileri izlenebilir. Tek fan arızası bazı sistemlerde redundancy ile tolere edilir. Buna rağmen bakım ihtiyacı oluşturur. Alarm severity donanım mimarisine ve kalan cooling kapasitesine göre belirlenmelidir.

Temperature

Sıcaklık CPU ve diğer bileşenlerin güvenli çalışma aralığını etkiler. Anlık küçük değişikliklerden çok sürekli yükseliş önemlidir. Data center ortam sıcaklığı ve fan davranışıyla birlikte değerlendirilmelidir. Kritik seviyelerde hardware throttling veya shutdown görülebilir. Bu nedenle temperature alarmı fiziksel müdahale süresini dikkate almalıdır.

ECC Memory

ECC memory bazı bellek hatalarını algılayıp düzeltebilir. Correctable error sayısının artması donanım bozulmasının erken sinyali olabilir. Uncorrectable error daha yüksek öneme sahiptir. İşletim sistemi ve hardware management katmanından veri toplanabilir. Tekrarlanan hata oranı bakım planına dönüştürülmelidir.

IPMI / Redfish

IPMI ve Redfish işletim sisteminden bağımsız donanım yönetim bilgilerine erişim sağlayabilir. Power, temperature, fan, PSU ve hardware status gibi veriler buradan alınabilir. Yönetim ağı internete doğrudan açılmamalıdır. Erişim kontrolü ve network segmentation uygulanmalıdır. Monitoring sistemi bu veriyi merkezi dashboard ve alarm akışına dahil edebilir.

Donanım Arızasını İşletim Sisteminden Bağımsız İzlemek

İşletim sistemi tamamen çöktüğünde normal host agent'ları veri gönderemez. Donanım management interface'i ise bazı durumlarda çalışmaya devam eder. Bu nedenle out-of-band monitoring kritik fiziksel sunucularda değerlidir. Power state ve hardware error bilgileri OS'den bağımsız görülebilir. Blackbox network kontrolleriyle birleştirildiğinde arızanın katmanı daha hızlı anlaşılır.

Network Monitoring

Network monitoring yalnızca interface üzerinden geçen Mbps değerine bakmak değildir. Paket kaybı, gecikme, jitter, hata, drop, retransmission ve bağlantı sayısı uygulama davranışını ciddi biçimde etkileyebilir. Özellikle dağıtık sistemlerde küçük network problemleri birçok serviste zincirleme latency oluşturabilir. Baseline ve kullanıcı etkisi burada da önemlidir. Network alarmı ilgili interface, region, dependency ve service bilgileriyle ilişkilendirilmelidir.

Bandwidth

Bandwidth teorik veya tahsis edilmiş ağ kapasitesini ifade eder. Gerçek kullanımın bu kapasiteye yaklaşması saturation riskini artırabilir. Ancak yüzde kullanım tek başına paket kaybını göstermez. Peak dönemler ve burst davranışı ayrıca incelenmelidir. Capacity planning için uzun vadeli trend tutulması faydalıdır.

Throughput

Throughput belirli zamanda gerçekten taşınan veri miktarını gösterir. Inbound ve outbound trafik ayrı takip edilmelidir. Uygulama workload'u büyüdükçe throughput trendi kapasite ihtiyacını gösterebilir. Ani düşüş trafik kaybı veya upstream sorununa işaret edebilir. Beklenen trafik modeliyle birlikte yorumlanmalıdır.

Packet Loss

Packet loss gönderilen paketlerin bir bölümünün hedefe ulaşmamasıdır. Küçük oranlar bile latency hassas uygulamalarda sorun oluşturabilir. TCP retransmission artışıyla birlikte görülebilir. Network cihazı, link veya upstream dependency kaynaklı olabilir. Multi-location probe sonuçları problemin bölgesel olup olmadığını anlamaya yardımcı olur.

Latency

Network latency paketlerin kaynak ve hedef arasındaki yolculuk süresini etkiler. Uygulama response time ile karıştırılmamalıdır. Yüksek network latency servisler arası çağrılarda birikerek kullanıcı gecikmesini artırabilir. Region veya dependency bazında izlemek faydalıdır. Ortalama yerine percentile veya dağılım kullanımı bazı senaryolarda daha açıklayıcı olabilir.

Jitter

Jitter latency değerinin zaman içindeki değişkenliğini ifade eder. Gerçek zamanlı ses ve video gibi uygulamalarda önemlidir. Ortalama latency kabul edilebilir görünürken yüksek jitter kullanıcı deneyimini bozabilir. Baseline'a göre sapma takip edilebilir. Network path değişiklikleri jitter davranışını etkileyebilir.

Interface Error

Interface error fiziksel bağlantı, kablo, transceiver veya network cihazı problemlerine işaret edebilir. Error counter'ların artış hızı izlenmelidir. Toplam sayaç değeri reboot olmadığı sürece sürekli birikebilir. Bu nedenle rate hesaplamak daha anlamlıdır. Alarmda ilgili interface ve cihaz bilgisi bulunmalıdır.

Packet Drop

Packet drop cihazın paketleri çeşitli sebeplerle işleyemeyip düşürmesini ifade eder. Queue saturation, buffer problemi veya policy etkisi olabilir. Drop oranı trafik miktarıyla birlikte değerlendirilmelidir. Kullanıcı error ve latency sinyalleriyle korelasyon yapılabilir. Sürekli drop kapasite veya configuration incelemesi gerektirir.

Retransmission

TCP retransmission kaybolan veya onaylanmayan paketlerin yeniden gönderilmesini ifade eder. Artışı network kalitesi veya karşı uç davranışı hakkında önemli ipucu verebilir. Connection latency ve timeout artışıyla birlikte görülmesi anlamlıdır. Host ve destination bazında inceleme yapılabilir. Tek bir genel sayı kök neden bulmak için yeterli değildir.

Connection Count

Aktif bağlantı sayısı servis yükü ve connection pool davranışı hakkında bilgi verir. Ani artış trafik yükselişi veya bağlantı leak'i nedeniyle oluşabilir. Connection limitine yaklaşma saturation riski yaratır. State dağılımı ayrıca incelenmelidir. Kullanıcı hata oranıyla birlikte değerlendirildiğinde exhaustion problemleri daha kolay anlaşılır.

TCP Bağlantı Monitoring

TCP bağlantı state'leri servis davranışını anlamak için oldukça değerlidir. ESTABLISHED, TIME_WAIT, CLOSE_WAIT ve SYN_RECV sayılarındaki olağan dışı değişiklikler farklı problemlere işaret eder. Tek bir state için sabit alarm kullanmak yerine bağlantı profili ve limitler değerlendirilmelidir. Ephemeral port kapasitesi ve retransmission da bu analizin parçasıdır. Network yoğun servislerde TCP metrikleri application monitoring ile birlikte incelenmelidir.

ESTABLISHED

ESTABLISHED aktif TCP bağlantılarını gösterir. Sayı normal trafik artışıyla doğal olarak yükselebilir. Connection limitine yaklaşması durumunda kapasite riski oluşabilir. Traffic ve request rate ile birlikte değerlendirilmelidir. Beklenmeyen uzun süreli artış connection leak ihtimalini düşündürebilir.

TIME_WAIT

TIME_WAIT kapanan TCP bağlantılarının belirli süre tutulduğu normal bir state'tir. Yüksek sayılar kısa bağlantıların yoğun olduğu servislerde beklenebilir. Tek başına hata değildir. Ancak ephemeral port kullanımıyla birlikte limit riski oluşturabilir. Connection reuse ve uygulama davranışı gerektiğinde incelenmelidir.

CLOSE_WAIT

CLOSE_WAIT karşı taraf bağlantıyı kapattığı halde local uygulamanın socket'i henüz kapatmadığını gösterir. Sürekli artış application tarafında connection cleanup problemine işaret edebilir. Process bazında socket sayıları incelenmelidir. File descriptor kullanımıyla birlikte takip etmek faydalıdır. Kalıcı büyüme restart yerine uygulama kodunun araştırılmasını gerektirir.

SYN_RECV

SYN_RECV bağlantı kurulumunun ara aşamasındaki socket'leri gösterir. Trafik artışı sırasında yükselmesi normal olabilir. Aşırı artış backlog saturation veya anormal bağlantı girişimleriyle ilişkili olabilir. Accept queue ve error metrikleriyle birlikte incelenmelidir. Uygulama kapasitesi ve network davranışı birlikte değerlendirilmelidir.

Connection Exhaustion

Connection exhaustion servis veya işletim sistemi bağlantı limitlerinin tükenmesi durumudur. Kullanıcılar yeni bağlantı kuramadığında error ve timeout görebilir. Active connection, limit ve queue metrikleri birlikte takip edilmelidir. Alarm limit dolmadan önce warning üretmelidir. Runbook içinde güvenli mitigation ve kök neden kontrol adımları bulunmalıdır.

Ephemeral Port Exhaustion

Ephemeral port tükenmesi özellikle çok sayıda outbound connection açan sistemlerde görülebilir. TIME_WAIT yoğunluğu riski artırabilir. Available port range ve connection churn izlenmelidir. Problem oluştuğunda dış servislere yeni bağlantı kurulamayabilir. Connection pooling ve keep-alive davranışı inceleme konusu olabilir.

TCP Retransmission

TCP retransmission oranı connection kalitesini değerlendirmek için güçlü sinyaldir. Ani artış packet loss veya network path sorununu gösterebilir. Application timeout ve latency ile birlikte incelenmelidir. Destination veya interface bazında kırılım kök nedeni daraltır. Normal trafik artışından kaynaklanan mutlak sayaç değişimi yerine rate kullanılması daha anlamlıdır.

DNS ve Network Dependency Monitoring

Bir servis kendi sunucusunda tamamen sağlıklı olsa bile DNS, gateway, firewall, load balancer veya dış API problemleri nedeniyle kullanılamaz hale gelebilir. Bu nedenle dependency monitoring sistemin gerçek çalışma zincirini kapsamalıdır. Özellikle dış API kullanan uygulamalarda bağlantı başarısı ve latency ayrı ölçülmelidir. DNS failure ve resolution time kullanıcıya yansıyan gecikmenin önemli bir parçası olabilir. Dependency-aware dashboard ve alarm tasarımı incident triage süresini azaltır.

DNS Resolution Time

DNS resolution time isim çözümlemenin ne kadar sürdüğünü gösterir. Ani yükseliş uygulama response time'ına doğrudan eklenebilir. Birden fazla resolver kullanılıyorsa ayrı ayrı takip edilebilir. Cache davranışı sonuçları etkileyebilir. Kullanıcıya yakın blackbox probe ile ölçüm yapmak değerli bağlam sağlar.

DNS Failure Rate

DNS failure rate başarısız çözümleme isteklerinin oranını gösterir. Küçük oranlar bile yoğun trafikte çok sayıda kullanıcıyı etkileyebilir. Servis error rate ile korele edilmelidir. Upstream resolver problemleri ayrı monitor edilmelidir. Alarm mesajında etkilenen domain ve resolver bilgisi bulunması faydalıdır.

Upstream DNS Health

Upstream DNS sağlığı yalnızca local resolver durumundan ibaret değildir. Recursive resolver veya dış dependency problemi birçok servisi aynı anda etkileyebilir. Query latency ve failure rate takip edilebilir. Root cause alarmı oluştuğunda downstream servis alarmları inhibition ile bastırılabilir. Böylece tek incident için yüzlerce notification oluşması önlenir.

Gateway

Gateway problemi aynı network segmentindeki birçok servisi etkileyebilir. Reachability, latency ve packet loss ölçümleri yardımcı olur. Yalnızca ping yerine gerçek trafik yoluna yakın kontroller tercih edilmelidir. Gateway alarmı dependency ilişkisiyle modellenebilir. Downstream servislerde oluşan semptomlar root cause analizinde bu bilgiyle ilişkilendirilmelidir.

Load Balancer

Load balancer backend'ler sağlıklı olsa bile kullanıcı erişiminin merkezi noktası olabilir. Frontend availability, backend health, connection count ve error rate izlenmelidir. Configuration değişiklikleri annotation olarak dashboard'a eklenebilir. Backend dağılımındaki dengesizlik de performansı etkileyebilir. Kullanıcı odaklı blackbox check load balancer üzerinden yapılmalıdır.

Firewall

Firewall configuration değişiklikleri bağlantı problemlerine yol açabilir. Monitoring sistemi doğrudan firewall policy doğrulaması yapmasa bile connection failure ve drop sinyalleri üretebilir. Change kayıtları incident timeline ile ilişkilendirilmelidir. Belirli portlara blackbox probe faydalı olabilir. Ağ güvenliği nedeniyle monitoring endpoint'leri gereksiz yere dışarı açılmamalıdır.

External API Connectivity

Dış API bağımlılıkları servisinizin kullanıcı deneyimini etkileyebilir. Connectivity, latency, error rate ve timeout oranı izlenmelidir. Vendor kaynaklı kesintiler ile kendi network probleminizi ayırmak için birden fazla sinyal gerekir. Circuit breaker veya fallback davranışı varsa onun metrikleri de takip edilmelidir. Alarm doğrudan dependency owner'ına değil, öncelikle kendi servis etkisine göre sınıflandırılmalıdır.

Process ve Service Monitoring

Bir process'in çalışıyor olması servis fonksiyonunun sağlıklı olduğu anlamına gelmez. Process varlığı temel bir sinyaldir fakat CPU, memory, restart sayısı, thread ve open file kullanımıyla birlikte değerlendirilmelidir. systemd servisi active görünürken uygulama endpoint'i hata döndürebilir. Bu nedenle process monitoring health check ve blackbox testlerle tamamlanmalıdır. Kritik process'ler service ownership bilgisiyle eşleştirilmelidir.

Process Çalışıyor mu?

Kritik process'in varlığı en temel monitoring kontrollerinden biridir. Beklenmedik şekilde kapanması servis kesintisine yol açabilir. Ancak process'in yeniden başlatma mekanizması varsa kısa kesintiler gözden kaçabilir. Restart counter bu nedenle ayrıca takip edilmelidir. Process kontrolü functional health check ile desteklenmelidir.

Process CPU

Process CPU hangi uygulamanın işlemci kaynağını tükettiğini anlamaya yardımcı olur. Host CPU yüksek olduğunda sorunlu process'i bulmak için önemlidir. Deployment öncesi ve sonrası trend karşılaştırılabilir. Kısa spike'lar normal workload davranışı olabilir. Kalıcı artış kullanıcı latency veya throughput değişimiyle birlikte incelenmelidir.

Process Memory

Process memory leak ve kapasite sorunlarını araştırmak için değerlidir. Resident memory zaman içinde takip edilebilir. Restart olduğunda trend sıfırlanabileceği için restart bilgisiyle birlikte yorumlanmalıdır. Container limitleri varsa limit oranı ayrıca izlenmelidir. OOM olayları process ve host seviyesinde ilişkilendirilmelidir.

Thread Sayısı

Thread sayısı uygulamanın concurrency davranışı hakkında bilgi verir. Sürekli artış thread leak belirtisi olabilir. Normal değer uygulama mimarisine göre büyük farklılık gösterebilir. Limitlere yaklaşma durumunda warning üretilebilir. CPU ve connection count ile birlikte değerlendirme daha anlamlıdır.

Open File Sayısı

Open file sayısı dosya ve socket kullanımını içerir. Limit tükenirse uygulama yeni dosya veya bağlantı açamayabilir. Mevcut kullanım ile process limit oranı birlikte takip edilmelidir. Sürekli büyüme leak ihtimalini gösterebilir. Alarm oluştuğunda hangi dosya veya socket türünün arttığı araştırılmalıdır.

Restart Count

Restart count servis stabilitesini anlamak için güçlü bir sinyaldir. Servis her restart sonrası hızlı döndüğü için uptime kontrolü problemi kaçırabilir. Belirli pencere içinde artan restart sayısı alarm üretebilir. OOM, crash veya health check failure nedenleri ayrıştırılmalıdır. Deployment sonrası artış ayrıca incelenmelidir.

systemd Service Monitoring

systemd managed servislerin active, failed ve restarting durumları takip edilebilir. Beklenmeyen failed state hızlı biçimde görünür olmalıdır. Ancak active state uygulamanın işlevsel olduğunu garanti etmez. HTTP veya protokol seviyesinde health check eklenmelidir. Restart ve exit code bilgileri incident araştırmasına yardımcı olur.

Service Çalışıyor Ama İşlevsel Değilse Ne Olur?

Bir process çalışıyor fakat dependency bağlantısı kuramıyor olabilir. Port açık olabilir ancak istekler sürekli hata döndürebilir. Bu nedenle yalnızca process veya port kontrolü yetersizdir. Functional health endpoint veya synthetic request gerçek servis davranışını ölçmelidir. Production monitoring mümkün olduğunca kullanıcı akışına yakın doğrulama yapmalıdır.

Application Monitoring

Sunucu kaynakları uygulamanın neden yavaşladığını anlamak için değerlidir ancak kullanıcı deneyimini doğrudan göstermez. Application monitoring request rate, error rate, response time, throughput, queue ve connection pool davranışını ölçer. Domain-specific business metrics ise teknik sağlık ile gerçek iş sonucunu birleştirir. Örneğin ödeme servisi HTTP 200 döndürürken başarılı işlem sayısı sıfıra düşebilir. Bu nedenle infrastructure ve application telemetry aynı dashboard içinde ilişkilendirilebilir.

Request Rate

Request rate servise belirli sürede gelen istek sayısını gösterir. Trafik artışı normal büyüme veya beklenmeyen yük olabilir. Ani düşüş upstream problemine de işaret edebilir. Capacity planlama için uzun vadeli trend önemlidir. Error ve latency metrikleri request rate bağlamında yorumlanmalıdır.

Error Rate

Error rate başarısız isteklerin toplam trafiğe oranını gösterir. Mutlak hata sayısından daha anlamlı olabilir. Yüksek trafik sırasında küçük oran çok sayıda kullanıcıyı etkileyebilir. User-facing hata oranı page için güçlü semptom sinyalidir. SLO hesaplamalarında da doğrudan kullanılabilir.

Response Time

Response time kullanıcının isteğe ne kadar sürede cevap aldığını gösterir. Ortalama değer tail latency problemlerini gizleyebilir. p95 ve p99 gibi percentile değerleri birlikte izlenmelidir. Endpoint sınıfları arasında normal değerler farklı olabilir. Alarm baseline ve SLO hedefleriyle uyumlu olmalıdır.

Throughput

Application throughput sistemin başarıyla işleyebildiği iş miktarını gösterir. Request rate ile aynı olmak zorunda değildir. Queue veya downstream bottleneck throughput'u sınırlayabilir. Capacity testleriyle production trendleri karşılaştırılabilir. Beklenen trafik artarken throughput sabit kalıyorsa saturation araştırılmalıdır.

Concurrent Requests

Concurrent request aynı anda işlenen talep miktarını gösterir. Worker veya thread limitlerine yaklaşma saturation oluşturabilir. Response time arttıkça concurrency de artabilir. Bu nedenle iki metrik birbirini etkileyebilir. Limit ve queue bilgileriyle birlikte izlemek daha anlamlıdır.

Queue Length

Queue length işlenmeyi bekleyen taleplerin miktarını gösterir. Sürekli büyüyen kuyruk kapasitenin gelen yükü karşılayamadığını gösterebilir. Worker utilization ve processing duration ile birlikte izlenmelidir. Kısa burst'ler normal olabilir. Mesaj yaşı kuyruk uzunluğundan daha kullanıcı odaklı bir sinyal sunabilir.

Connection Pool

Connection pool veritabanı veya dış servis bağlantılarının yeniden kullanılmasını sağlar. Pool exhaustion yeni isteklerin beklemesine veya hata almasına neden olabilir. Active, idle, waiting ve max connection değerleri izlenebilir. Yüksek waiting sayısı kullanıcı latency ile ilişkili olabilir. Pool boyutu altyapı kapasitesiyle birlikte ayarlanmalıdır.

Domain-Specific Business Metrics

Business metric uygulamanın teknik olarak çalışmasının ötesinde gerçek işlevi yerine getirip getirmediğini gösterir. Başarılı sipariş, tamamlanan ödeme veya oluşturulan kayıt sayısı örnek verilebilir. Teknik endpoint 200 döndürse bile business işlem başarısız olabilir. Bu metrikler kritik kullanıcı akışlarını daha iyi temsil eder. Alarm tasarımında kişisel veya hassas verilerin metric label olarak kullanılmamasına dikkat edilmelidir.

Four Golden Signals

Four Golden Signals servis sağlığını latency, traffic, errors ve saturation üzerinden değerlendiren pratik bir çerçevedir. Çok sayıda altyapı metriği arasında kaybolmak yerine kullanıcı etkisine yakın temel soruları cevaplamaya yardımcı olur. Sunucu seviyesindeki CPU veya disk sinyalleri saturation altında konumlandırılabilir. Application response time ve error rate ise doğrudan kullanıcı deneyimine yaklaşır. Dashboard tasarımında bu dört sinyal güçlü bir başlangıç sağlar.

Latency

Latency isteklerin tamamlanma süresini ölçer. Başarılı ve başarısız isteklerin latency davranışı farklı olabilir. Percentile değerleri tail problemlerini göstermeye yardımcı olur. Endpoint veya request class bazında ayrım yapılabilir. SLO hedefleriyle ilişkilendirildiğinde alarm kararına dönüşebilir.

Traffic

Traffic sisteme gelen iş yükünün miktarını ifade eder. HTTP request rate, message rate veya transaction count şeklinde ölçülebilir. Sistem davranışını yorumlamak için trafik bağlamı gereklidir. CPU artışı trafik artışıyla tamamen uyumlu olabilir. Beklenmeyen trafik düşüşü de incident sinyali olabilir.

Errors

Errors başarısız kullanıcı işlemlerini ölçer. HTTP 5xx, failed transaction veya domain-specific failure kullanılabilir. Oran bazlı ölçüm trafik değişimlerinden daha az etkilenir. SLO ve error budget yaklaşımında önemli rol oynar. Kullanıcı etkisi yüksekse güçlü page kriteri olabilir.

Saturation

Saturation sistem kaynağının kapasite sınırına ne kadar yaklaştığını gösterir. CPU run queue, disk queue veya connection pool waiting buna örnek olabilir. Utilization ile aynı şey değildir. Kaynak yüksek kullanılsa bile iş beklemiyorsa saturation oluşmamış olabilir. Alarm için bekleme sinyalleri daha değerlidir.

Sunucu Monitoring ile Nasıl Birleştirilir?

Golden Signals üst seviyede kullanıcı etkisini gösterirken host metrikleri kök neden araştırmasında kullanılır. Örneğin latency artınca CPU saturation, disk latency ve network loss kontrol edilebilir. Böylece her altyapı metriği için ayrı page oluşturmak gerekmez. Dashboard katmanlı biçimde tasarlanabilir. Üstte kullanıcı sinyalleri, altta service ve infrastructure detayları yer alabilir.

RED Method

RED Method özellikle request tabanlı servislerde Rate, Errors ve Duration metriklerine odaklanır. Mikroservis ve API izleme için anlaşılır bir başlangıç çerçevesidir. Her servisin ne kadar trafik aldığı, kaç isteğin başarısız olduğu ve ne kadar sürdüğü hızlı biçimde görülebilir. Infrastructure metrikleri bu üç temel sinyalden sonra troubleshooting amacıyla incelenebilir. Böylece dashboard servis davranışını kullanıcı isteği perspektifinden gösterir.

Rate

Rate belirli sürede alınan istek miktarını gösterir. Trafik değişimini ve workload büyümesini anlamaya yardımcı olur. Ani düşüş upstream veya routing problemine işaret edebilir. Ani artış kapasite üzerindeki baskıyı yükseltebilir. Error ve duration değerleri rate bağlamında yorumlanmalıdır.

Errors

Errors başarısız request oranını gösterir. HTTP status code tek kaynak olmak zorunda değildir. Domain-specific failure sonuçları da eklenebilir. Error rate belirli süre boyunca SLO hedefini aşıyorsa alarm anlamlı hale gelir. Mutlak hata sayısı düşük trafikli servislerde ayrıca değerlendirilebilir.

Duration

Duration request tamamlanma süresidir. Ortalama yerine histogram ve percentile kullanımı daha doğru görünürlük sağlar. p50 normal iken p99 ciddi biçimde bozulabilir. Endpoint bazında normal latency değerleri farklı olabilir. Alarm tasarımı user-facing hedeflere göre yapılmalıdır.

API ve Mikroservis Monitoring'de RED Kullanımı

Her servis için standart RED paneli oluşturmak ekiplerin ortak dil kullanmasını sağlar. Deployment sonrası rate, error ve duration değişimleri hızlı görülebilir. Service-to-service trace verisi eklenirse dependency kaynaklı gecikmeler daha kolay araştırılır. RED dashboard'u host metric'lerinden önce incelenebilir. Bu yaklaşım incident sırasında sorunun hangi serviste başladığını daraltmaya yardımcı olur.

USE Method

USE Method altyapı kaynaklarını Utilization, Saturation ve Errors üzerinden incelemeyi önerir. CPU, disk ve network gibi kaynaklar için oldukça pratiktir. Bir kaynağın yüksek kullanılması tek başına sorun olmayabilir. İşlerin beklemesi veya error oluşması gerçek baskıyı daha iyi gösterir. Bu nedenle USE yaklaşımı klasik yüzde threshold alarmından daha güçlü bir teşhis çerçevesi sağlar.

Utilization

Utilization kaynağın ne kadar kullanıldığını gösterir. CPU yüzdesi veya interface bandwidth kullanımı buna örnektir. Yüksek utilization kapasite sınırına yaklaşıldığını gösterebilir. Ancak mutlaka kullanıcı problemi olduğu anlamına gelmez. Saturation ve errors birlikte incelenmelidir.

Saturation

Saturation kaynağı kullanmak isteyen işlerin bekleyip beklemediğini gösterir. CPU run queue veya disk queue iyi örneklerdir. Saturation genellikle kullanıcı latency üzerinde daha doğrudan etki yaratır. Limit ve workload yapısı bağlamında yorumlanmalıdır. Kalıcı saturation kapasite planı gerektirebilir.

Errors

Resource errors altyapı seviyesindeki başarısızlıkları gösterir. Disk I/O error, network interface error veya packet drop örnek verilebilir. Sayaçların toplam değerinden çok artış hızı önemlidir. Error sinyali kullanıcı etkisiyle ilişkilendirilmelidir. Donanım veya configuration problemi için erken uyarı oluşturabilir.

CPU İçin USE

CPU utilization toplam işlemci kullanımını gösterir. Saturation run queue üzerinden takip edilebilir. Error kavramı CPU için diğer kaynaklar kadar doğrudan olmayabilir. Steal time veya scheduling problemleri ek bağlam sağlar. Kullanıcı latency ile korelasyon gerçek etkiyi gösterir.

Disk İçin USE

Disk utilization cihazın meşguliyetini gösterir. Saturation queue ve latency üzerinden anlaşılabilir. Error metrikleri device veya filesystem hatalarını gösterebilir. IOPS ve throughput kapasite bağlamı sağlar. Birlikte kullanıldığında storage darboğazı daha doğru teşhis edilir.

Network İçin USE

Network utilization interface kapasitesine göre trafik oranını gösterir. Saturation queue, drop veya gecikme davranışıyla ortaya çıkabilir. Error counter'ları fiziksel veya bağlantı problemleri için ipucu verir. Retransmission ayrıca uygulama seviyesindeki etkileri gösterebilir. Trafik yönleri ayrı değerlendirilmelidir.

Database Monitoring

Veritabanı birçok uygulamanın kritik dependency'sidir ve yalnızca process durumuyla izlenmemelidir. Connection, query latency, slow query, transaction, lock, replication ve storage büyümesi birlikte takip edilmelidir. Veritabanı problemi çoğu zaman application latency artışı olarak kullanıcıya yansır. Bu nedenle database dashboard'u service dashboard'larıyla ilişkilendirilmelidir. Alarm severity gerçek kullanıcı etkisine ve veri güvenliği riskine göre belirlenmelidir.

Active Connections

Active connection sayısı veritabanı yükünü anlamaya yardımcı olur. Limitlere yaklaşma yeni bağlantıların reddedilmesine yol açabilir. Uygulama connection pool davranışıyla birlikte takip edilmelidir. Ani artış connection leak veya trafik artışından kaynaklanabilir. Waiting connection sayısı ayrıca önemli sinyaldir.

Connection Pool

Connection pool uygulamanın veritabanı bağlantılarını verimli kullanmasını sağlar. Active, idle, waiting ve maximum değerleri izlenebilir. Waiting artışı kullanıcı response time'ını yükseltebilir. Çok büyük pool veritabanını aşırı yükleyebilir. Boyutlandırma uygulama ve database kapasitesi birlikte düşünülerek yapılmalıdır.

Query Latency

Query latency sorguların tamamlanma süresini gösterir. Ortalama değer yavaş sorguları gizleyebilir. Percentile dağılımı daha iyi görünürlük sunabilir. Query class veya operation türüne göre ayrım yapılabilir. Deployment ve schema değişiklikleriyle korelasyon faydalıdır.

Slow Query

Slow query belirlenen performans beklentisini aşan sorguları ifade eder. Sürekli aynı sorgunun yavaşlaması index veya query plan problemine işaret edebilir. Kullanıcı etkisi sorgunun ne kadar kritik olduğuna bağlıdır. Slow query logları hassas veri içermeyecek şekilde yönetilmelidir. Monitoring sonucu optimizasyon çalışmasına dönüşmelidir.

Transaction Rate

Transaction rate veritabanının birim zamanda işlediği transaction miktarını gösterir. Trafik ve application request rate ile ilişkilendirilebilir. Ani düşüş servis problemi olabilir. Ani artış kapasiteyi zorlayabilir. Error ve latency değerleriyle birlikte izlenmelidir.

Lock

Lock contention transaction'ların birbirini beklemesine yol açabilir. Kullanıcı latency artarken CPU düşük kalabilir. Waiting lock sayısı ve süreleri bu nedenle değerlidir. Problemli query veya transaction araştırılmalıdır. Uzun transaction'lar ayrı sinyal olarak takip edilebilir.

Deadlock

Deadlock birbirini bekleyen transaction'ların ilerleyememesi durumudur. Veritabanı çoğu zaman taraflardan birini sonlandırarak durumu çözer. Tekrarlanan deadlock uygulama hatalarına dönüşebilir. Rate olarak izlenmesi faydalıdır. İlgili query ve transaction akışları incelenmelidir.

Replication Lag

Replication lag replica'nın primary kaynağın ne kadar gerisinde olduğunu gösterir. Read replica kullanan sistemlerde stale data oluşturabilir. Failover senaryolarında yüksek lag veri kaybı riskini etkileyebilir. Threshold workload ve RPO beklentilerine göre ayarlanmalıdır. Ani artış network veya storage sorunuyla ilişkili olabilir.

Cache Hit Ratio

Cache hit ratio sorguların ne kadarının cache üzerinden karşılandığını gösterir. Düşüş daha fazla disk I/O ve latency oluşturabilir. Tek başına evrensel bir ideal değer yoktur. Workload'un normal davranışıyla karşılaştırılmalıdır. Cache sizing ve query pattern değişiklikleri birlikte değerlendirilmelidir.

Disk Growth

Database disk büyümesi capacity planning için kritik metriktir. Günlük veri artışı ve index büyümesi ayrı izlenebilir. Backup alanı da aynı growth trendinden etkilenebilir. Time-to-full tahmini yapılmalıdır. Ani büyüme uygulama hatası veya kontrolsüz log üretimi nedeniyle oluşabilir.

Redis ve Cache Monitoring

Cache katmanı hızlı olsa da memory kapasitesi ve eviction davranışı kullanıcı performansını ciddi biçimde etkileyebilir. Hit/miss oranı, client bağlantıları, command latency, replication ve persistence durumları birlikte takip edilmelidir. Memory limitine yaklaşmak otomatik olarak problem değildir, çünkü cache tasarımı kapasiteyi kullanmak üzere kurulmuş olabilir. Asıl soru eviction'ın uygulama performansını nasıl etkilediğidir. Cache monitoring application latency ve database load ile ilişkilendirilmelidir.

Memory Usage

Cache memory kullanımı configured limit bağlamında değerlendirilmelidir. Yüksek kullanım tek başına incident anlamına gelmez. Eviction policy ve workload davranışı önemlidir. Ani büyüme key pattern değişimini gösterebilir. Memory fragmentation gibi ek sinyaller de gerektiğinde incelenebilir.

Hit/Miss Ratio

Hit/miss ratio cache'in beklenen faydayı sağlayıp sağlamadığını gösterir. Miss artışı backend database yükünü yükseltebilir. Deployment veya cache invalidation sonrası değişim görülebilir. Tek bir evrensel ideal oran yoktur. Uygulama response time ile birlikte yorumlanmalıdır.

Eviction

Eviction memory limitine ulaşıldığında key'lerin policy doğrultusunda çıkarılmasıdır. Bazı cache workload'larında normal davranıştır. Eviction rate artışı hit ratio ve database load üzerinde etkili olabilir. Kullanıcı latency yükseliyorsa önem artar. Alarm yalnızca eviction varlığına değil etkisine göre tasarlanmalıdır.

Connected Clients

Connected client sayısı cache üzerindeki bağlantı yükünü gösterir. Limitlere yaklaşma connection failure oluşturabilir. Application pool ayarlarıyla birlikte değerlendirilmelidir. Ani artış leak veya trafik yükselişine işaret edebilir. Blocked client sayısı ayrıca kritik bağlam sağlayabilir.

Command Latency

Command latency cache işlemlerinin ne kadar sürdüğünü gösterir. Cache sisteminden düşük latency beklendiği için artış uygulama üzerinde hızlı etkilenme oluşturabilir. Command türüne göre ayrım yapılabilir. CPU, network ve persistence aktiviteleriyle korele edilmelidir. Percentile değerleri tail problemlerini gösterebilir.

Replication

Replication durumu replica sağlığı ve lag üzerinden izlenmelidir. Replica kopması redundancy kaybına yol açabilir. Failover tasarımında replication health kritik sinyaldir. Network sorunları lag artışına neden olabilir. Alarm severity hizmet mimarisine göre belirlenmelidir.

Persistence

Persistence kullanılan cache modeline göre veri dayanıklılığını etkileyebilir. Snapshot veya append log süreçlerinin başarısı izlenmelidir. Disk alanı ve I/O performansı persistence davranışını etkileyebilir. Başarısız persistence işlemi silent risk oluşturabilir. Recovery beklentileriyle uyumlu alarm tasarlanmalıdır.

Queue ve Message Broker Monitoring

Queue tabanlı sistemlerde yalnızca broker process'inin ayakta olması yeterli değildir. Queue length, producer ve consumer rate, message age, dead letter queue ve consumer lag gerçek işleme kapasitesini gösterir. Kuyruk uzunluğu sabit kalırken eski mesajların beklemesi kullanıcı etkisi oluşturabilir. Bu nedenle message age çoğu zaman güçlü bir semptom sinyalidir. Alarm tasarımı normal trafik döngülerini ve batch paternlerini dikkate almalıdır.

Queue Length

Queue length bekleyen mesaj miktarını gösterir. Kısa trafik burst'lerinde geçici artış normal olabilir. Sürekli büyüme consumer kapasitesinin producer hızını karşılayamadığını gösterebilir. Message age ile birlikte değerlendirilmelidir. Tek threshold yerine trend ve duration kullanmak daha sağlıklıdır.

Consumer Count

Consumer count mesajları işleyen aktif worker sayısını gösterir. Beklenmedik düşüş processing kapasitesini azaltabilir. Autoscaling kullanılıyorsa workload ile birlikte değişmesi normaldir. Sıfıra düşmesi kritik queue'larda hızlı alarm gerektirebilir. Consumer health application error verileriyle birlikte izlenmelidir.

Producer Rate

Producer rate queue'ya eklenen mesaj miktarını gösterir. Trafik artışı kapasite baskısını artırabilir. Ani sıfırlanma upstream uygulama problemini gösterebilir. Consumer rate ile karşılaştırmak backlog trendini anlamayı kolaylaştırır. Business metric ile ilişki kurulması faydalıdır.

Consumer Rate

Consumer rate birim zamanda işlenen mesaj sayısını gösterir. Producer rate'in uzun süre altında kalması backlog oluşmasına yol açar. Worker sayısı ve processing duration ile birlikte değerlendirilmelidir. Ani düşüş dependency veya application problemine işaret edebilir. Capacity planning için peak değerler önemlidir.

Message Age

Message age en eski bekleyen mesajın ne kadar süredir kuyrukta olduğunu gösterir. Kullanıcı gecikmesine queue length'ten daha yakın bir sinyal olabilir. Çok sayıda hızlı işlenen mesaj kuyrukta olabilir fakat yaş düşük kalabilir. Buna karşılık küçük queue içinde tek eski mesaj ciddi problem gösterebilir. SLO hedefiyle ilişkilendirilmesi mümkündür.

Dead Letter Queue

Dead letter queue işlenemeyen mesajların ayrıldığı alandır. Mesaj sayısının artması uygulama veya veri problemi olduğunu gösterebilir. Her tek mesaj page gerektirmeyebilir. Rate, age ve business impact birlikte değerlendirilmelidir. Runbook içinde replay ve veri güvenliği adımları bulunmalıdır.

Consumer Lag

Consumer lag consumer'ın mevcut stream veya queue pozisyonunun ne kadar gerisinde olduğunu gösterir. Artış processing kapasitesinin yetersiz kaldığını gösterebilir. Trafik paterni ve consumer throughput ile birlikte değerlendirilmelidir. Sürekli lag kullanıcıların eski veri görmesine neden olabilir. Alarm gerçek gecikme hedeflerine göre ayarlanmalıdır.

Cron Job ve Batch Job Monitoring

Batch job monitoring yalnızca process'in çalışıp çalışmadığını kontrol etmekten farklıdır. Job'ın zamanında başlaması, başarıyla bitmesi, beklenen sürede tamamlanması ve son başarılı çalışma zamanı izlenmelidir. Kısa ömürlü job'larda heartbeat veya push tabanlı metric kullanılabilir. Tek başarısız deneme her zaman gece page gerektirmez. İşin kritikliği ve tekrar çalışma penceresi alarm severity kararını belirlemelidir.

Job Başladı mı?

Planlanan zamanda başlamayan job görünmez bir problem oluşturabilir. Scheduler health ve expected start window izlenmelidir. Job hiç başlamazsa failure logu üretmeyebilir. Bu nedenle absence monitoring önemlidir. Beklenen zaman geçmesine rağmen heartbeat gelmemesi alarm üretebilir.

Job Başarılı Bitti mi?

Job process olarak başlayıp business işlemini tamamlayamadan bitebilir. Exit code ve domain-specific success metric birlikte kullanılmalıdır. Son başarılı tamamlanma zamanı saklanmalıdır. Tek başarısızlık retry mekanizmasına göre değerlendirilebilir. Kritik veri işlemlerinde başarı alarmı daha yüksek öneme sahiptir.

Çalışma Süresi

Job duration normalden uzadığında dependency veya data volume problemi olabilir. Historical baseline ile karşılaştırma yapılabilir. Çok kısa duration bile beklenen işi yapmadan çıktığını gösterebilir. Success state ile birlikte izlenmelidir. p95 job duration gibi trendler capacity planlamada yardımcı olabilir.

Son Başarılı Çalışma Zamanı

Last success timestamp job monitoring için güçlü bir metriktir. Tek tek failure olaylarından bağımsız olarak işin ne kadar süredir başarıyla tamamlanmadığını gösterir. Retry mekanizması olan sistemlerde özellikle faydalıdır. Kritik pencere aşıldığında alarm üretilebilir. Alarm metninde son başarı zamanı açık biçimde yazılmalıdır.

Heartbeat

Heartbeat job'ın beklenen zamanda çalıştığını doğrulayan basit bir sinyaldir. Job başarıyla tamamlandığında dış monitoring endpoint'ine heartbeat gönderebilir. Heartbeat gelmezse job veya scheduler problemi olabilir. Monitoring sisteminin kendisi dışarıdan kontrol ediliyorsa bağımsız heartbeat daha da değerlidir. Expiration süresi normal çalışma penceresine göre ayarlanmalıdır.

Job Bir Kez Başarısız Olduğunda Page Gönderilmeli mi?

Bu karar işin kritikliği ve retry imkanına bağlıdır. Otomatik retry birkaç dakika içinde başarıyla tamamlayabiliyorsa ilk failure için gece page gereksiz olabilir. Buna karşılık ödeme settlement gibi zaman kritik süreçlerde ilk hata bile yüksek önem taşıyabilir. Alarm severity kullanıcı veya business etkisine göre belirlenmelidir. Amaç her failure'ı bildirmek değil, insan müdahalesi gereken failure'ı doğru zamanda bildirmektir.

Backup Monitoring

Backup job'ın "success" vermesi tek başına veri korumasının tamamlandığını göstermez. Backup age, size, storage kapasitesi, replication ve düzenli restore testi birlikte izlenmelidir. Boş veya eksik backup dosyası teknik olarak başarılı job sonucuyla üretilebilir. Restore edilemeyen backup production felaketinde işe yaramaz. Bu nedenle backup monitoring recovery hedefleriyle doğrudan ilişkilendirilmelidir.

Backup Job Success

Backup job success işlemin planlandığı gibi tamamlanıp tamamlanmadığını gösterir. Exit code veya backup platform status bilgisi kullanılabilir. Failure oluştuğunda retry davranışı değerlendirilmelidir. Kritik veri için başarısızlık yüksek severity taşıyabilir. Alarmda hangi dataset ve job'ın etkilendiği açık olmalıdır.

Backup Age

Backup age son geçerli backup'ın ne kadar eski olduğunu gösterir. Job event'lerinden daha güçlü bir risk göstergesi olabilir. Birden fazla retry başarısız olduğunda age sürekli büyür. RPO beklentisine göre threshold belirlenmelidir. Örneğin günlük backup için son başarılı kopyanın iki günden eski olması ciddi uyarı olabilir.

Backup Size

Backup size önceki çalışmalara göre karşılaştırılmalıdır. Beklenmedik şekilde çok küçük backup eksik veri anlamına gelebilir. Ani büyüme storage planını etkileyebilir. Trend analizi capacity planning için faydalıdır. Tek başına sabit size threshold yerine geçmiş davranışla karşılaştırma yapılabilir.

Storage Capacity

Backup storage dolarsa yeni backup'lar tamamlanamayabilir. Remaining capacity ve growth rate izlenmelidir. Retention policy ile kapasite planı birlikte düşünülmelidir. Time-to-full alarmı erken müdahale sağlar. Production diskinden ayrı olsa bile backup storage kritik altyapı olarak ele alınmalıdır.

Replication

Backup kopyalarının başka location veya storage'a replike edilmesi disaster recovery açısından önemlidir. Replication lag ve failure metrikleri takip edilmelidir. Local backup başarılı olsa bile remote copy başarısız olabilir. RPO beklentisi iki katman için ayrı değerlendirilebilir. Alarm yalnızca job success'e bağlı bırakılmamalıdır.

Restore Testi

Restore testi backup'ın gerçekten kullanılabilir olup olmadığını doğrular. Düzenli otomatik veya kontrollü restore senaryoları planlanabilir. Test yalnızca dosyanın açılmasını değil uygulama açısından kullanılabilirliğini kontrol etmelidir. Son başarılı restore test zamanı monitoring metriği haline getirilebilir. Bu yaklaşım backup stratejisinin gerçek değerini ölçer.

Backup Var Ama Restore Edilemiyor Problemi

Backup dosyasının varlığı recovery garantisi değildir. Bozuk arşiv, eksik dependency, yanlış encryption key veya uyumsuz prosedür restore'u engelleyebilir. Bu nedenle runbook teoride kalmamalı, test edilmelidir. Restore test failure yüksek önem taşımalıdır. Recovery hedefi backup oluşturmak değil, gerektiğinde veriyi geri getirebilmektir.

SSL/TLS Certificate Monitoring

TLS certificate expiration tamamen öngörülebilir olmasına rağmen production kesintilerinde sık görülen nedenlerden biridir. Sertifikanın son kullanma tarihi, chain durumu ve hostname doğruluğu dışarıdan test edilebilir. Renewal otomasyonu kullanılıyor olsa bile otomasyonun başarısız olabileceği kabul edilmelidir. Bu nedenle 30, 14 ve 7 günlük kademeli alarm modeli pratiktir. Kritik eşikte doğrudan page yerine ownership ve müdahale zamanı dikkate alınmalıdır.

Certificate Expiration

Certificate expiration kalan gün sayısı üzerinden izlenebilir. Otomatik yenileme kullanılan sistemlerde bile alarm gereklidir. İlk warning erken planlama için yeterli süre bırakmalıdır. Süre azaldıkça severity yükseltilebilir. Alarmda hostname ve expiration tarihi açık biçimde bulunmalıdır.

Certificate Chain

Certificate chain problemi istemcilerin güven ilişkisini kuramamasına neden olabilir. Sertifika tarihi geçerli olsa bile eksik intermediate certificate erişim hatası oluşturabilir. Blackbox TLS probe chain doğrulaması yapmalıdır. Birden fazla client türü davranışı farklı olabilir. Production endpoint'lerinde dışarıdan doğrulama tercih edilmelidir.

Hostname Validation

Sertifika belirtilen hostname ile uyumlu olmalıdır. Yanlış certificate deployment erişim hatası oluşturabilir. Wildcard ve SAN alanları doğru değerlendirilmelidir. Blackbox monitoring gerçek kullanıcı hostname'i üzerinden test yapmalıdır. Configuration değişiklikleri sonrası otomatik probe hızlı geri bildirim sağlar.

30/14/7 Gün Alarm Stratejisi

Otuz günlük alarm planlama ve renewal problemini araştırmak için erken warning sağlayabilir. On dört gün seviyesi ownership ve aksiyon takibini güçlendirebilir. Yedi gün kaldığında severity kritik hizmetlerde yükseltilebilir. Her üç alarmın aynı kanala aynı şekilde gitmesi gerekmez. İlk aşamalar ticket, son aşama daha acil notification olabilir.

Certificate Renewal Failure

Otomatik renewal job'ın başarısızlığı expiration tarihinden daha erken sinyal sağlayabilir. Job status ve certificate kalan gün birlikte izlenmelidir. İlk failure retry mekanizmasına göre page gerektirmeyebilir. Tekrarlanan failure ve azalan kalan süre severity'yi artırmalıdır. Runbook DNS, challenge ve erişim kontrollerini içerebilir.

Prometheus Nedir?

Prometheus zaman serisi metriklerini toplamak, saklamak ve sorgulamak için kullanılan açık kaynak bir monitoring yaklaşımıdır. Pull-based scraping, label tabanlı veri modeli, PromQL ve alerting rules güçlü özellikleri arasındadır. Cloud-native ortamlarda service discovery ile dinamik target yönetimi yapılabilir. Prometheus tek başına görsel dashboard sistemi değildir ve notification yönlendirmesi için Alertmanager gibi bileşenlerle birlikte kullanılır. Production tasarımında retention, HA ve long-term storage ihtiyaçları ayrıca planlanmalıdır.

Time-Series Database

Prometheus topladığı metrikleri local time-series database içinde saklar. Veriler timestamp ve label seti üzerinden organize edilir. Bu yapı zaman penceresi tabanlı sorgular için uygundur. Local disk kapasitesi retention süresini etkiler. Uzun dönem ihtiyaçlarda remote write veya farklı storage katmanları kullanılabilir.

Pull-Based Scraping

Prometheus target endpoint'lerine düzenli aralıklarla giderek metric toplar. Bu model scrape success bilgisini de görünür hale getirir. Target erişilemiyorsa Prometheus bunu fark edebilir. Service discovery dinamik altyapılarda target yönetimini kolaylaştırır. Scrape interval metric ihtiyacına ve maliyete göre ayarlanmalıdır.

Labels

Labels metric'lere environment, service veya instance gibi boyutlar ekler. Sorgulama ve aggregation açısından güçlüdür. Ancak kontrolsüz label kullanımı cardinality patlamasına neden olabilir. User ID veya sürekli değişen request değerleri label olmamalıdır. Label governance production maliyetini doğrudan etkiler.

PromQL

PromQL Prometheus metriklerini sorgulamak için kullanılan dildir. Rate, aggregation ve zaman aralığı hesapları yapılabilir. Dashboard ve alert rule'ların temelini oluşturur. Yanlış sorgu yanlış alarm davranışına yol açabilir. Kritik query'ler test edilip version control altında tutulmalıdır.

Service Discovery

Service discovery target listesinin dinamik olarak bulunmasını sağlar. Özellikle container ve orchestrator ortamlarında manuel target yönetimi zorlaşır. Discovery metadata'sı relabeling ile metric label'larına dönüştürülebilir. Gereksiz target'lar filtrelenmelidir. Discovery failure monitoring sisteminin görünürlüğünü etkileyebilir.

Recording Rules

Recording rules sık kullanılan veya hesaplama maliyeti yüksek sorguların önceden hesaplanmasını sağlar. Dashboard performansını artırabilir. SLO ve aggregate metriklerde faydalıdır. Rule isimlendirmesi ortak standartla yapılmalıdır. Yanlış rule sonucu birçok dashboard ve alarmı aynı anda etkileyebilir.

Alerting Rules

Alerting rules belirli PromQL koşullarının alarm durumuna dönüşmesini sağlar. Koşul yanında duration kullanılabilir. Label ve annotation alanları routing ve alarm içeriği için önemlidir. Rule syntax ve logic CI içinde test edilebilir. Alarm yalnızca metric threshold değil kullanıcı etkisi ve actionability dikkate alınarak yazılmalıdır.

Node Exporter ile Linux Sunucu Monitoring

Node Exporter Linux host metriklerini Prometheus formatında sunmak için yaygın kullanılan exporter'lardan biridir. CPU, memory, filesystem ve network gibi temel işletim sistemi verilerini sağlar. Linux sunucu CPU RAM disk ve ağ kullanımı nasıl izlenir sorusuna Prometheus ekosisteminde pratik başlangıç noktası sunar. Ancak metric toplamak alarm tasarımının yalnızca ilk adımıdır. Bu verilerin service ve kullanıcı metrikleriyle ilişkilendirilmesi gerekir.

Node Exporter Nedir?

Node Exporter Linux işletim sistemi ve donanım katmanına yakın metrikleri dışarı sunar. Prometheus bu endpoint'i scrape eder. Çok sayıda collector farklı sistem kaynaklarını kapsar. Gereksiz collector'lar kapatılarak veri miktarı azaltılabilir. Exporter endpoint güvenli network içinde tutulmalıdır.

/metrics Endpoint

Node Exporter metrikleri HTTP üzerinden /metrics endpoint'inde yayınlar. Prometheus scrape işlemini bu endpoint üzerinden gerçekleştirir. Endpoint'i doğrudan internete açmak doğru değildir. Network policy veya firewall ile erişim sınırlandırılmalıdır. Gerekli durumlarda TLS ve authentication katmanı eklenebilir.

CPU Metrikleri

CPU metrikleri farklı mode değerlerindeki işlemci zamanlarını içerir. User, system, idle, iowait ve steal hesaplanabilir. Counter yapısındaki veriler rate fonksiyonlarıyla kullanılır. Core bazında ve aggregate görünüm oluşturulabilir. Alarm için utilization yanında saturation göstergeleri de eklenmelidir.

Memory Metrikleri

Memory metrikleri total, available, cache, buffer ve swap gibi bilgileri sunar. Used yüzdesi tek başına kullanılmamalıdır. Available memory gerçek pressure için daha güçlü bağlam sağlar. Swap activity ve OOM olayları ayrıca izlenmelidir. Process seviyesindeki leak için farklı exporter veya application telemetry gerekebilir.

Filesystem Metrikleri

Filesystem metrikleri size, available space ve inode kullanımını içerir. Temporary veya irrelevant mount point'ler sorgularda filtrelenebilir. Read-only state ayrıca izlenebilir. Kalan kapasite ve growth rate hesapları yapılabilir. Alarm mount point türüne göre özelleştirilebilir.

Network Metrikleri

Network metrikleri interface başına byte, packet, error ve drop sayaçlarını sunar. Rate hesaplanarak saniyelik trafik görülebilir. Loopback gibi interface'ler gerektiğinde filtrelenebilir. Error ve drop oranı throughput ile birlikte yorumlanmalıdır. Application seviyesindeki latency için ek telemetry gerekir.

Textfile Collector

Textfile collector özel host metriklerini Node Exporter üzerinden sunmayı sağlar. Cron job sonucu, backup zamanı veya local script çıktıları metric'e dönüştürülebilir. Dosyanın atomik biçimde güncellenmesi önemlidir. Kullanılmayan eski metric dosyaları temizlenmelidir. Hassas bilgi metric value veya label içine yazılmamalıdır.

Prometheus Metric Tipleri

Prometheus metric tipini doğru seçmek sorgulama ve alarm davranışını etkiler. Counter sürekli artan olay sayıları için, gauge yükselip azalabilen değerler için kullanılır. Histogram ve summary latency gibi dağılımları ölçmek için tasarlanmıştır. Yanlış metric tipi sorguları gereksiz zorlaştırabilir. Application instrumentation sırasında metric semantics açık biçimde tanımlanmalıdır.

Counter

Counter restart dışında sürekli artması beklenen değerdir. Request count ve error count tipik örneklerdir. Anlık değerden çok rate veya increase hesaplanır. Reset davranışı sorgularda dikkate alınmalıdır. Kullanım sayacı veya event toplamı için uygundur.

Gauge

Gauge yükselip azalabilen anlık değeri temsil eder. Memory usage, queue length veya active connection örnek verilebilir. Doğrudan mevcut state'i gösterebilir. Historical trend de incelenebilir. Sürekli artan olay sayaçları için gauge yerine counter tercih edilmelidir.

Histogram

Histogram gözlemleri tanımlı bucket'lara dağıtır. Request duration ve response size için kullanılabilir. Server-side aggregation ve percentile tahmini açısından güçlüdür. Bucket sınırları beklenen SLO hedeflerine göre seçilmelidir. Yanlış bucket seçimi p95 veya p99 görünürlüğünü azaltabilir.

Summary

Summary gözlemlerden quantile hesaplayabilir. Hesaplama client tarafında yapılır. Birden fazla instance arasında quantile aggregation kolay değildir. Kullanım senaryosu histogramdan farklıdır. Dağıtık servislerde percentile ihtiyacı için histogram çoğu durumda daha esnek olabilir.

Hangi Metric Tipi Ne Zaman Kullanılır?

Toplam olay sayısı için counter iyi seçimdir. Anlık state veya kapasite değeri için gauge uygundur. Latency dağılımı ve aggregate percentile ihtiyacında histogram değerlidir. Summary belirli client-side quantile ihtiyaçlarında kullanılabilir. Seçim yaparken metric'in matematiksel davranışı ve gelecekteki sorgular düşünülmelidir.

Percentile ve Latency Monitoring

Latency monitoring yalnızca ortalama değer üzerinden yapılırsa kullanıcıların yaşadığı en kötü deneyimler gizlenebilir. Örneğin isteklerin yüzde 99'u 100 ms, yüzde 1'i 10 saniyede tamamlanıyorsa ortalama değer sorunu yeterince açık göstermeyebilir. p50 tipik kullanıcıyı, p95 ve p99 ise dağılımın kuyruğunu anlamaya yardımcı olur. Production servislerinde SLO hedefiyle uyumlu percentile seçimi yapılmalıdır. Histogram bu hesapları ölçeklenebilir biçimde yapmaya yardımcı olabilir.

Ortalama Latency Neden Yanıltıcıdır?

Ortalama tüm istekleri tek bir değere indirger. Az sayıdaki çok yavaş request bu değeri etkileyebilir veya tam tersine büyük çoğunluğun hızlı olması problemi gizleyebilir. Dağılım bilgisini kaybettiği için tail davranışını göstermez. Kullanıcı deneyiminde en yavaş yüzde birkaç önem taşıyabilir. Percentile bu nedenle daha fazla bağlam sunar.

p50

p50 median latency değeridir. İsteklerin yarısı bu değerin altında tamamlanır. Tipik kullanıcı deneyimi hakkında fikir verir. Ancak tail problemlerini göstermez. p95 ve p99 ile birlikte değerlendirilmelidir.

p90

p90 isteklerin yüzde 90'ının belirtilen sürenin altında tamamlandığını gösterir. Genel performans trendini izlemek için kullanılabilir. Kritik servislerde tek başına yeterli olmayabilir. Tail kullanıcılarını daha iyi görmek için daha yüksek percentile eklenebilir. SLO hedefleri servis ihtiyacına göre seçilmelidir.

p95

p95 en yavaş yüzde 5'lik gruba yaklaşan kullanıcı deneyimini gösterir. Birçok web servisi için pratik performans göstergesidir. Deployment sonrası bozulmalar burada erken görülebilir. Request volume yeterli olmalıdır. Düşük trafikte percentile değerleri dalgalı olabilir.

p99

p99 tail latency problemlerini daha net gösterir. Yüksek trafik alan servislerde küçük yüzde bile çok sayıda kullanıcı demektir. Dependency timeout veya GC gibi problemler burada görünür olabilir. Aşırı hassas alarm tasarımı gürültü üretebilir. Duration ve request volume ile birlikte değerlendirilmelidir.

Tail Latency

Tail latency dağılımın en yavaş bölümündeki istekleri ifade eder. Kullanıcıların küçük bir kısmını etkiliyor görünse de büyük trafik hacminde ciddi sayı ortaya çıkabilir. Dağıtık servis zincirlerinde birden fazla çağrının tail etkisi birleşebilir. Trace verileri kök nedeni araştırmak için değerlidir. Percentile dashboard ve SLO tasarımında dikkate alınmalıdır.

Histogram Kullanımı

Histogram latency gözlemlerini bucket'lara ayırır. Prometheus tarafında histogram_quantile gibi fonksiyonlarla percentile tahmini yapılabilir. Bucket sınırları gerçek latency hedeflerine uygun seçilmelidir. Gereğinden fazla bucket cardinality ve storage maliyetini artırır. Uygulama standardı belirlenerek servisler arasında tutarlı histogram tasarımı yapılabilir.

Prometheus Label ve Cardinality Yönetimi

Prometheus sistemlerinde cardinality kontrol edilmezse memory ve storage ihtiyacı hızla büyüyebilir. Her benzersiz label kombinasyonu yeni time series oluşturur. Service ve environment gibi sınırlı değerler genellikle faydalıdır. User ID, request ID veya sınırsız URL path gibi değerler ciddi maliyet oluşturabilir. Label governance monitoring platformunun uzun vadeli sürdürülebilirliği için temel kurallardan biridir.

Cardinality Nedir?

Cardinality bir metric'in kaç farklı label kombinasyonu ürettiğini ifade eder. Her kombinasyon ayrı time series olarak saklanır. Label sayısı az olsa bile değer çeşitliliği yüksekse cardinality büyüyebilir. Memory ve query performansı bundan etkilenir. Metric tasarımında potansiyel seri sayısı önceden düşünülmelidir.

High-Cardinality Label

High-cardinality label çok sayıda farklı değer üreten label'dır. Request ID, email veya dinamik identifier örnek verilebilir. Bu değerler log veya trace içinde daha uygun olabilir. Metric label olarak kullanıldığında storage ve memory maliyeti hızla artar. Production öncesi instrumentation review yapılmalıdır.

User ID Neden Label Olmamalı?

User ID kullanıcı sayısı arttıkça sürekli yeni seri oluşturabilir. Ayrıca kişisel veri riski taşıyabilir. Metric'ler aggregate analiz için daha uygundur. Kullanıcı bazlı troubleshooting gerekiyorsa log veya trace yaklaşımı tercih edilebilir. Telemetry içinde hassas veri minimizasyonu uygulanmalıdır.

URL Path Problemi

Dinamik URL path değerleri her resource ID için yeni seri oluşturabilir. Örneğin /user/123 ve /user/456 ayrı label değeri olmamalıdır. Route template kullanmak cardinality'yi sınırlar. /user/:id gibi normalleştirilmiş değer tercih edilebilir. Instrumentation katmanında bu dönüşüm standardize edilmelidir.

Memory ve Storage Etkisi

Her time series metadata ve sample storage tüketir. Cardinality arttıkça memory ihtiyacı ve query maliyeti yükselir. Retention süresi storage etkisini daha da büyütür. Gereksiz label'lar yalnızca maliyet değil operasyon problemi oluşturur. Cardinality dashboard ve budget takibi yapılabilir.

Label Governance

Label governance hangi isimlerin ve değer tiplerinin kullanılabileceğini tanımlar. Service, environment, region ve instance gibi ortak standartlar belirlenebilir. High-cardinality label'lar code review sırasında engellenebilir. Metric naming ve ownership kuralları belgelenmelidir. Bu disiplin monitoring-as-code yaklaşımıyla birlikte yönetilebilir.

Grafana ile Monitoring Dashboard

Grafana farklı veri kaynaklarından gelen monitoring verilerini dashboard üzerinde görselleştirmek için kullanılır. Prometheus data source bağlandıktan sonra PromQL sorguları panel seviyesinde kullanılabilir. Variable ve annotation özellikleri dashboard'u farklı environment ve deployment bağlamlarında daha kullanışlı hale getirir. Production dashboard'ları manuel tıklamalarla oluşturmak yerine provisioning yöntemiyle yönetilebilir. Böylece dashboard değişiklikleri version control ve review süreçlerine dahil edilir.

Prometheus Data Source

Grafana Prometheus'u data source olarak kullanabilir. Sorgular panel içinde PromQL ile tanımlanır. Data source erişimi güvenli network ve authentication kurallarıyla korunmalıdır. Birden fazla environment için ayrı data source veya label tabanlı ayrım yapılabilir. Query timeout ve performance değerleri izlenmelidir.

Dashboard

Dashboard ilgili servis veya sistem hakkında hızlı genel görünüm sunmalıdır. En üstte kullanıcı etkisi ve kritik health sinyalleri yer alabilir. Detaylı altyapı metrikleri alt bölümlerde tutulabilir. Tek dashboard'a yüzlerce panel doldurmak araştırmayı zorlaştırır. Her dashboard belirli operasyon sorularını cevaplamalıdır.

Panel

Panel tek veya ilişkili birkaç metriği görselleştirir. Grafik tipi verinin yapısına göre seçilmelidir. Time series, stat ve table farklı amaçlara hizmet eder. Threshold çizgileri gerektiğinde kullanılabilir. Panel başlığı metriğin ne anlattığını açık biçimde ifade etmelidir.

Variable

Variable aynı dashboard'u farklı service, instance veya environment için kullanılabilir hale getirir. Kullanıcı seçimleri query'lere uygulanabilir. Çok fazla variable dashboard kullanımını zorlaştırabilir. Default değerler anlamlı seçilmelidir. High-cardinality seçimler query performansını etkileyebilir.

Annotation

Annotation deployment, configuration change veya incident başlangıcı gibi olayları grafik zaman çizelgesine ekler. Metric değişiminin bir değişiklikle ilişkisini hızlı gösterir. Deployment sonrası latency artışı kolayca fark edilebilir. Otomatik CI/CD entegrasyonu faydalıdır. Manual annotation ihtiyacı minimumda tutulabilir.

Dashboard Provisioning

Provisioning dashboard tanımlarının dosya veya kod üzerinden yönetilmesini sağlar. Değişiklikler Git history içinde izlenebilir. Review ve rollback kolaylaşır. Ortamlar arasında tutarlılık artar. Monitoring-as-code kültürünün önemli parçalarından biridir.

Etkili Monitoring Dashboard Nasıl Tasarlanır?

Etkili dashboard en fazla metriği gösteren dashboard değildir. Kullanıcının ilk bakışta "Servis sağlıklı mı, kullanıcı etkileniyor mu, problem nerede yoğunlaşıyor?" sorularını cevaplamasını sağlamalıdır. Golden Signals üst bölümde güçlü bir temel oluşturur. Infrastructure ve dependency metrikleri neden araştırması için alt seviyelerde sunulabilir. Deployment annotation gibi değişiklik işaretleri incident timeline'ı anlamayı kolaylaştırır.

En Üste Kullanıcı Etkisini Koymak

Dashboard açıldığında ilk görülen bilgi kullanıcı deneyimi olmalıdır. Availability, error rate ve latency bu amaç için uygundur. CPU veya RAM değerleri daha aşağıda yer alabilir. Böylece mühendis problemi altyapı sinyalinden değil hizmet etkisinden okumaya başlar. Bu düzen incident triage kararlarını hızlandırır.

Golden Signals

Latency, traffic, errors ve saturation servis dashboard'unun temel çerçevesi olabilir. Dört sinyal birçok incident için hızlı ilk değerlendirme sağlar. Trafik değişimi diğer metrikleri yorumlamak için bağlam verir. Error ve latency doğrudan kullanıcı etkisine yaklaşır. Saturation olası kaynak sınırlarını gösterir.

Infrastructure Kaynakları

CPU, memory, disk ve network detayları troubleshooting sırasında gereklidir. Ancak bunları dashboard'un en üstüne koymak kullanıcı etkisini geri plana atabilir. Kaynak metrikleri USE yaklaşımıyla gruplanabilir. Utilization yanında saturation ve errors gösterilmelidir. Host seçimi için variable kullanılabilir.

Dependency Sağlığı

Database, cache, queue, DNS ve external API gibi dependency'ler ayrı bölümde gösterilebilir. Hangi dependency'nin latency veya error ürettiği hızlı görülebilir. Service map veya trace bağlantısı ek değer sağlar. Dependency alarmı downstream semptomlarla korele edilmelidir. Root cause bulunduğunda gereksiz alarmlar inhibition ile azaltılabilir.

Deployment Annotation

Deployment zamanları grafik üzerinde işaretlendiğinde metric değişimleri çok daha hızlı yorumlanır. Error rate artışının deploy ile aynı dakikada başlaması güçlü ipucudur. Rollback kararı daha hızlı verilebilir. Configuration change ve feature rollout da annotation olarak eklenebilir. Bu bilgi otomasyonla gönderildiğinde manuel kayıt ihtiyacı azalır.

Gereksiz Grafiklerden Kaçınmak

Her metric dashboard paneline dönüşmek zorunda değildir. Kullanılmayan grafikler dikkat dağıtır ve bakım maliyeti oluşturur. Panelin hangi soruyu cevapladığı bilinmiyorsa kaldırılması düşünülebilir. Ayrıntılı troubleshooting verileri ayrı dashboard'a taşınabilir. Daha az fakat anlamlı panel operasyonda daha hızlı karar sağlar.

Dashboard mı Alert mi?

Dashboard ile alert farklı ihtiyaçlara hizmet eder. Dashboard araştırma, karşılaştırma ve bağlam için kullanılır. Alert ise insan aksiyonu gerektiren koşulları doğru zamanda bildirmelidir. Her dashboard metriğini alarma çevirmek alert fatigue oluşturur. Özellikle production ortamında alarm sayısından çok alarm kalitesi önemlidir.

Dashboard Araştırma İçindir

Dashboard incident sırasında sisteme dair farklı sinyalleri karşılaştırmak için kullanılır. Mühendis metric trendlerini ve dependency davranışını burada inceleyebilir. Her panel sürekli izlenmek zorunda değildir. Historical analiz ve capacity planning de dashboard üzerinden yapılabilir. Bu nedenle dashboard bilgi yoğun olabilir ancak anlaşılır düzenlenmelidir.

Alert Aksiyon İçindir

Alert insanın bir şey yapmasını gerektiren durumu bildirmelidir. Aksiyon yoksa alert yerine dashboard metriği veya rapor daha uygun olabilir. Page alarmı acil ve önemli olmalıdır. Alarm mesajında owner ve runbook yer almalıdır. Bu yaklaşım on-call güvenini artırır.

Bilgilendirme Metriklerini Page'e Dönüştürmemek

CPU'nun kısa süre yüksek olması bilgilendirici olabilir ancak page gerektirmeyebilir. Benzer şekilde bir cache eviction olayı normal sistem davranışı olabilir. Her değişikliği gece bildirime çevirmek ekibin alarm duyarlılığını azaltır. Bilgilendirme sinyalleri dashboard veya ticket düzeyinde tutulabilir. Page yalnızca hızlı insan müdahalesi gereken olaylar için ayrılmalıdır.

Her Grafik İçin Alarm Gerekmemesi

Grafik troubleshooting sırasında değerli olduğu için otomatik olarak alarm kriteri olmak zorunda değildir. Disk IOPS grafiği sorunu araştırmak için gereklidir ancak doğrudan kullanıcı etkisi yoksa page oluşturmayabilir. Üst seviye latency veya error alarmı incident'i başlatabilir. Alt metrikler root cause bulmaya yardımcı olur. Bu ayrım alert volume'u ciddi biçimde azaltır.

Alarm (Alert) Mekanizması Nasıl Çalışır?

Sunucu monitoring sisteminde threshold alert notification ve uptime takibi nasıl yapılır sorusunun merkezinde alarm yaşam döngüsü vardır. Metric önce toplanır, ardından rule engine koşulu değerlendirir. Koşul belirli süre devam ederse pending durumundan firing durumuna geçebilir. Notification manager alarmı gruplar ve doğru kişiye yollar. Mühendis acknowledge edip müdahale eder, koşul normale döndüğünde alarm resolve edilir.

Metric Collection

Alarmın doğru çalışması için metric'in düzenli ve güvenilir biçimde toplanması gerekir. Scrape failure durumunda veri eksikliği alarmı yanlış etkileyebilir. Metric freshness izlenmelidir. Collector'un kendisi metamonitoring kapsamında kontrol edilmelidir. Veri yokluğu bazı alarmlarda ayrıca koşul olarak ele alınabilir.

Rule Evaluation

Rule engine PromQL veya ilgili sorguyu belirli aralıklarla değerlendirir. Evaluation interval alarmın tepki hızını etkiler. Çok kısa interval gereksiz hesaplama oluşturabilir. Query'nin doğru label setini üretmesi gerekir. Rule değişiklikleri test edilmeden production'a alınmamalıdır.

Pending

Pending koşulun sağlandığı ancak gerekli süre henüz tamamlanmadığı durumu ifade eder. Bu aşama kısa spike'ları filtrelemek için kullanılır. Örneğin CPU beş dakika yüksek kalmadan firing yapılmayabilir. Süre servis davranışına göre seçilmelidir. Fazla uzun süre gerçek incident tespitini geciktirebilir.

Firing

Firing alarm koşulunun gerekli süre boyunca devam ettiğini gösterir. Bu noktada notification manager devreye girebilir. Severity ve routing label'ları önem kazanır. Alarmın gerçekten aksiyon alınabilir olması gerekir. Firing olayı incident sistemine aktarılabilir.

Notification

Notification firing alarmının ilgili kanala iletilmesidir. E-posta, chat, SMS, telefon veya on-call platformu kullanılabilir. Kanal severity'ye göre değişebilir. Grouping ve deduplication aynı olayın tekrar tekrar bildirilmesini azaltır. Mesaj içinde yeterli bağlam bulunmalıdır.

Acknowledgement

Acknowledgement bir mühendisin alarmı gördüğünü ve sorumluluk aldığını gösterir. MTTA metriği bu süreyi ölçebilir. Acknowledge edilmemiş kritik alarm escalation tetikleyebilir. Ownership belirsizliği bu aşamada ciddi zaman kaybı yaratır. On-call policy açık olmalıdır.

Resolution

Resolution alarm koşulunun normale dönmesini ifade eder. Recovery threshold yanlış tasarlanırsa alarm tekrar tekrar firing ve resolved arasında geçebilir. Hysteresis bu davranışı azaltabilir. Resolve notification gerektiğinde ilgili kanala gönderilebilir. Incident tamamlandıktan sonra alarm kalitesi review edilmelidir.

İyi Bir Alarmın Özellikleri Nelerdir?

İyi alarm yalnızca doğru metric threshold'una sahip değildir. Acil, önemli, aksiyon alınabilir ve gerçek bir durumu temsil etmelidir. Kimin sorumlu olduğu ve kullanıcı etkisinin ne olduğu açık olmalıdır. Müdahale için runbook bağlantısı bulunmalıdır. Bu özelliklerden biri eksikse alarmın page yerine farklı kanalda tutulması daha doğru olabilir.

Urgent

Urgent alarm hızlı müdahale gerektirir. Birkaç saat beklemek kullanıcı etkisini ciddi biçimde artıracaksa page mantıklıdır. Gece on-call kişisini uyandırmak için urgency yüksek olmalıdır. Aksi durum ticket ile yönetilebilir. Urgency severity ile aynı kavram değildir.

Important

Important alarm gerçek hizmet veya business etkisine sahip olmalıdır. Kullanılmayan test sunucusundaki küçük disk problemi aynı önemde değildir. Production kritik servisinin erişilememesi yüksek önem taşır. Service tier alarm politikasında kullanılabilir. Böylece tüm kaynaklar aynı şekilde değerlendirilmez.

Actionable

Actionable alarm alındığında mühendisin yapabileceği somut bir işlem bulunmalıdır. Hiçbir aksiyon mümkün değilse page değeri düşer. Alarm mesajı ilk kontrol adımlarını göstermelidir. Runbook bu noktada yardımcı olur. Tek çözüm beklemekse notification kanalı yeniden düşünülmelidir.

Real

Alarm gerçek bir problemi yansıtmalıdır. False positive oranı yüksek alarm zamanla görmezden gelinir. Threshold, duration ve data quality düzenli gözden geçirilmelidir. Test alarmı ile gerçek firing davranışı doğrulanabilir. Alert review süreçleri gereksiz kuralları temizlemelidir.

Owner'ı Belli

Her alarmın kimin tarafından yönetileceği açık olmalıdır. Team ve service ownership label olarak taşınabilir. Owner değiştiğinde alarm config güncellenmelidir. Sahipsiz alarm kimsenin müdahale etmediği gürültüye dönüşür. Routing doğrudan ownership modelinden üretilebilir.

Kullanıcı Etkisi Anlaşılır

Alarm mesajı teknik metric dışında kullanıcı etkisini de açıklamalıdır. "CPU yüzde 95" yerine "checkout latency yükseliyor ve CPU saturation gözleniyor" daha anlamlıdır. Böylece severity daha hızlı değerlendirilir. Business impact biliniyorsa eklenebilir. Teknik ekip ile incident yöneticisi aynı bağlamı paylaşır.

Runbook İçerir

Runbook alarm sonrası ilk adımları standartlaştırır. Dashboard, log query ve safe mitigation adımları yer alabilir. Yeni on-call üyelerinin müdahalesini kolaylaştırır. Runbook güncel değilse yanlış yönlendirme yapabilir. Bu nedenle alarm review sırasında runbook da kontrol edilmelidir.

Symptom-Based ve Cause-Based Alerting

Symptom-based alert kullanıcı tarafından görülen problemi hedefler. Cause-based alert ise CPU, disk veya dependency gibi olası teknik nedeni hedefler. Page alarmında semptom sinyalleri çoğu zaman daha değerlidir. Çünkü neden sinyali kullanıcıyı etkilemeden geçici olarak oluşabilir. Cause-based metrikler dashboard ve troubleshooting için güçlü destek sağlar.

Kullanıcı Semptomuna Alarm Vermek

Availability düşüşü, error rate artışı veya latency bozulması doğrudan kullanıcı etkisine yakındır. Bu sinyaller page kararını daha güvenilir hale getirir. Teknik neden daha sonra araştırılabilir. SLO tabanlı alarm bu yaklaşımı güçlendirir. Böylece on-call ekibi gerçek etkisi olan olaylara odaklanır.

CPU Yüksekliğinin Her Zaman Page Gerektirmemesi

CPU yüzde 95 olabilir ancak servis latency hedeflerini koruyabilir. Bu durumda sistem kaynaklarını verimli kullanıyor olabilir. Sürekli saturation ve user-facing problem yoksa gece page gerekmeyebilir. Capacity ticket oluşturmak daha uygun olabilir. CPU metriği troubleshooting sırasında yine değerlidir.

Error Rate

User-facing error rate doğrudan semptom sinyalidir. Total request içinde oran olarak izlenmelidir. Kısa transient hatalar duration ile filtrelenebilir. SLO budget tüketimiyle birlikte daha akıllı alarm üretilebilir. Error sınıfları gerektiğinde ayrıştırılmalıdır.

Latency

Latency kullanıcıların hizmete ulaşma süresini doğrudan etkiler. Percentile bazlı ölçüm tail kullanıcılarını gösterir. Baseline ve SLO hedefi alarm threshold'unu belirleyebilir. Trafik çok düşükken percentile dikkatli yorumlanmalıdır. Dependency latency kök neden araştırmasında kullanılabilir.

Availability

Availability kullanıcıların servise erişip erişemediğini gösterir. Blackbox check ve successful request oranı birlikte kullanılabilir. Ping bu ölçüm için yeterli değildir. Multi-location test bölgesel problemleri ayırmaya yardım eder. Kritik availability düşüşü doğrudan page kriteri olabilir.

Cause-Based Sinyalleri Dashboard'da Kullanmak

CPU, memory, disk ve dependency metrikleri incident root cause araştırmasında çok değerlidir. Ancak her biri ayrı page oluşturursa alarm fırtınası yaşanabilir. Üst seviye semptom alarmı incident'i başlatabilir. Mühendis dashboard üzerinden cause sinyallerine geçer. Inhibition ile bilinen root cause durumlarında downstream alarm sayısı azaltılabilir.

Alert Severity Seviyeleri

Severity teknik problemin etkisini sınıflandırmak için kullanılır. Info, warning ve critical gibi basit seviyeler veya P1, P2, P3, P4 modeli tercih edilebilir. Burada önemli olan her seviyenin ekip içinde net anlam taşımasıdır. Severity otomatik olarak notification urgency belirlemek zorunda değildir. Business impact, kullanıcı sayısı ve müdahale süresi birlikte değerlendirilmelidir.

Info

Info seviyesi bilgi amaçlı olayları temsil eder. İnsan müdahalesi gerektirmeyebilir. Dashboard veya event stream içinde tutulabilir. Page kanallarına gönderilmesi gereksiz gürültü yaratır. Operasyon analizi için yine de kayıt değeri taşıyabilir.

Warning

Warning henüz kritik kesinti olmayan fakat takip gerektiren durumu gösterir. Mesai içinde ticket veya chat notification uygun olabilir. Capacity riski veya yaklaşan certificate expiration örnek verilebilir. Hemen gece müdahalesi gerekmiyorsa page yapılmamalıdır. Warning'den critical'a geçiş kriteri açık olmalıdır.

Critical

Critical kullanıcı veya business etkisinin ciddi olduğunu ifade eder. Hızlı müdahale gerekebilir. Ancak her critical alarm otomatik olarak telefon araması olmak zorunda değildir. Urgency ayrıca değerlendirilmelidir. Kritik alarmın owner ve runbook bilgisi mutlaka bulunmalıdır.

P1 / P2 / P3 / P4

P1 en yüksek etki ve aciliyeti temsil edecek biçimde tanımlanabilir. P2 önemli ancak daha sınırlı incident'lar için kullanılabilir. P3 ve P4 çoğunlukla düşük aciliyetli operasyon sorunlarına ayrılır. Tanımlar organizasyon tarafından açık biçimde yazılmalıdır. Her seviye için response expectation belirlenmelidir.

Severity ile Urgency Arasındaki Fark

Severity olayın etkisini, urgency ise ne kadar hızlı müdahale gerektiğini ifade eder. Büyük etkili ancak otomatik olarak toparlanan olayın urgency seviyesi farklı olabilir. Küçük fakat kısa süre içinde veri kaybına dönüşecek problem daha acil olabilir. Notification routing bu iki boyutu birlikte kullanabilir. Bu ayrım gece page sayısını azaltır.

Page, Ticket ve Notification Ayrımı

Her monitoring olayı aynı kanal üzerinden yönetilmemelidir. Gece uyandırması gereken kritik olaylar page, planlı müdahale gerektiren konular ticket ve bilgi amaçlı değişiklikler dashboard veya düşük öncelikli notification olarak ele alınabilir. Bu sınıflandırma on-call sürdürülebilirliğini artırır. Kullanıcı etkisi güçlü page kriteridir. Bir alarmın hangi kanala gitmesi gerektiği rule tanımında açıkça belirlenmelidir.

Gece Uyandırması Gereken Olaylar

Gece page yalnızca bekleyemeyecek olaylar için kullanılmalıdır. Geniş kullanıcı kesintisi, veri kaybı riski veya kritik servis availability problemi örnek verilebilir. Mühendis uyanınca gerçekten yapabileceği aksiyon olmalıdır. Otomatik recovery varsa kısa bekleme süresi uygulanabilir. Her gece page olayından sonra alarm kalitesi incelenmelidir.

Mesai Saatinde Müdahale Edilecek Olaylar

Capacity warning, certificate süresi veya düşük öncelikli hardware redundancy kaybı mesai içi müdahaleye uygun olabilir. Bu olaylar ticket sistemine yönlendirilebilir. SLA veya internal response süresi tanımlanabilir. Gece page yapılmaması sorunların unutulacağı anlamına gelmemelidir. Ownership ve takip mekanizması gereklidir.

Dashboard'da Kalması Gereken Olaylar

Bazı metrikler yalnızca araştırma bağlamı için gereklidir. CPU spike, cache eviction veya transient connection artışı otomatik aksiyon gerektirmeyebilir. Bu sinyaller dashboard'da görünür tutulabilir. Incident oluştuğunda kök neden bulmaya yardımcı olurlar. Page üretmemeleri monitoring değerlerini azaltmaz.

Kullanıcı Etkisini Page Kriteri Yapmak

Kullanıcı etkisi page alarmını teknik kaynak alarmından ayıran güçlü kriterdir. Error rate, availability ve latency doğrudan hizmet kalitesini temsil eder. SLO burn rate de bu yaklaşımı matematiksel hale getirebilir. Altyapı metrikleri kullanıcı sinyaliyle birlikte olduğunda severity yükseltilebilir. Böylece ekibin dikkati gerçek incident'lara gider.

Static Threshold Nasıl Belirlenir?

Static threshold belirli metriğin sabit bir seviyeyi aşmasına göre alarm üretir. Basit ve anlaşılırdır ancak her workload için aynı değer uygun değildir. CPU yüzde 90 veya disk yüzde 85 gibi rakamlar başlangıç noktası olabilir, otomatik doğru cevap değildir. Baseline, capacity ve kullanıcı etkisi dikkate alınmalıdır. Threshold belirli süre koşuluyla birlikte kullanılmalıdır.

CPU %90

CPU yüzde 90 yüksek kullanım gösterir fakat tek başına incident değildir. Workload bu seviyede normal çalışıyor olabilir. Run queue ve latency artışı gerçek saturation'ı doğrular. Beş veya on dakikalık duration kısa spike'ları filtreleyebilir. Host türüne göre threshold farklılaştırılabilir.

Disk %85

Disk yüzde 85 uyarısı birçok sistemde kullanılır fakat capacity boyutunu göz ardı eder. Büyük disklerde kalan alan çok yüksek olabilir. Hızlı büyüyen küçük disklerde yüzde 70 bile daha riskli olabilir. Remaining capacity ve time-to-full eklenmelidir. Warning ve critical seviyeleri farklı müdahale sürelerine göre ayarlanmalıdır.

Error Rate

Error rate threshold'u kullanıcı trafiğine göre belirlenmelidir. Yüzde 1 hata bazı servislerde kabul edilemez olabilir. Düşük trafikte tek hata oranı aşırı oynaklık oluşturabilir. Minimum request volume koşulu eklenebilir. SLO ve error budget alarm tasarımını daha anlamlı hale getirebilir.

Latency

Latency threshold'u endpoint veya servis beklentisine göre değişir. Bir API için 300 ms yüksek olabilirken batch endpoint için tamamen normal olabilir. Percentile değerleri tercih edilmelidir. Traffic volume düşükse sonuç dikkatli yorumlanmalıdır. Baseline ve SLO hedefleri birlikte kullanılabilir.

Threshold'ların Baseline'a Göre Ayarlanması

Historical baseline sistemin normal davranışını anlamaya yardımcı olur. Günün belirli saatlerinde CPU veya trafik düzenli yükseliyor olabilir. Bu davranış bilinmeden sabit threshold gereksiz alarmlar üretir. Baseline review yeni capacity ve workload değişimlerinde yenilenmelidir. Threshold hiçbir zaman ayarla ve unut yaklaşımıyla bırakılmamalıdır.

Her Sunucu İçin Aynı Threshold Kullanmanın Riski

Farklı sunucular farklı görev ve kaynak profiline sahiptir. Database host ile düşük trafikli utility server aynı CPU davranışını göstermez. Disk boyutu ve büyüme hızı da farklıdır. Tek threshold yönetimi basitleştirir fakat doğruluğu azaltabilir. Service tier veya workload class bazlı alarm politikası daha esnektir.

Dynamic Threshold ve Anomaly Detection

Dynamic threshold sabit değer yerine geçmiş davranış ve seasonality gibi faktörlerden yararlanır. Düzenli trafik paterni olan sistemlerde olağan dışı değişimleri bulmaya yardımcı olabilir. Ancak anomaly her zaman incident anlamına gelmez. Yeni deployment veya kampanya gibi beklenen değişiklikler modeli yanıltabilir. Bu nedenle dynamic threshold kullanıcı etkisi ve diğer sinyallerle desteklenmelidir.

Historical Baseline

Historical baseline geçmiş dönemlerin normal metric aralığını temsil eder. Günün saati veya haftanın günü gibi paternler dikkate alınabilir. Yeni sistemlerde yeterli veri olmadığı için baseline zayıf olabilir. Büyük mimari değişiklikler sonrası eski veri anlamını kaybedebilir. Model düzenli gözden geçirilmelidir.

Seasonality

Seasonality metric'in belirli periyotlarda tekrar eden davranışıdır. Hafta içi trafik artışı veya gece batch yükü örnek verilebilir. Static threshold bu düzenli değişimleri yanlış alarm olarak görebilir. Dynamic model pattern'i hesaba katabilir. Beklenmeyen business event'ler yine anomaly oluşturabilir.

Standard Deviation

Standard deviation değerlerin ortalama çevresindeki dağılımını ölçmek için kullanılabilir. Basit anomaly modeli belirli standart sapma sınırlarını kullanabilir. Ancak metric dağılımı normal değilse sonuç yanıltıcı olabilir. Outlier değerler modeli etkileyebilir. Teknik yöntem alarmın gerçek kullanıcı etkisiyle birlikte değerlendirilmelidir.

Anomaly Detection

Anomaly detection normal davranıştan farklı metric hareketlerini belirlemeye çalışır. Traffic, latency veya resource pattern'lerinde faydalı olabilir. Her anomaly insan müdahalesi gerektirmez. False positive oranı yakından izlenmelidir. Model çıktısı kritik page yerine ilk aşamada dashboard veya warning olarak kullanılabilir.

Dynamic Threshold Ne Zaman Kullanılmalı?

Normal değerin zaman içinde düzenli değiştiği metriklerde dynamic threshold faydalıdır. Sabit eşik sürekli false positive üretiyorsa alternatif olabilir. Yeterli historical data bulunmalıdır. Model açıklanabilir olmalı ve ekip neden alarm oluştuğunu anlayabilmelidir. Kritik user-facing sinyallerde SLO yaklaşımı çoğu zaman daha anlaşılır olabilir.

False Positive Riski

Dynamic model yanlış veya gereksiz anomaly üretebilir. İş değişiklikleri ve özel kampanyalar normal davranışı geçici olarak değiştirebilir. False positive oranı yüksekse ekip alarmı görmezden gelmeye başlar. Model output düzenli review edilmelidir. Her anomaly'nin page olması gerekmemelidir.

Alert Flapping Nasıl Önlenir?

Alert flapping metric threshold çevresinde gidip geldikçe alarmın sürekli firing ve resolved olmasıdır. Bu davranış notification gürültüsü oluşturur ve incident takibini zorlaştırır. Pending period, recovery threshold ve hysteresis çözüm için kullanılabilir. Keep-firing süresi de kısa recovery dalgalanmalarını filtreleyebilir. Alarm koşulu gerçek sistem davranışına göre tasarlanmalıdır.

Alert Flapping Nedir?

Metric değerinin threshold'un hemen üstü ve altı arasında sık değişmesi flapping oluşturur. Örneğin CPU yüzde 89 ile yüzde 91 arasında gidip gelebilir. Her geçiş notification üretirse ekip gereksiz mesaj alır. Sorun threshold'un hassasiyeti veya kısa evaluation penceresi olabilir. Recovery logic ayrı tasarlanmalıdır.

Pending Period

Pending period koşulun firing olmadan önce ne kadar sürmesi gerektiğini belirler. Kısa spike'ları filtreler. Çok uzun süre gerçek incident tespitini geciktirebilir. Metric davranışına göre uygun değer seçilmelidir. User-facing availability alarmında süre resource alarmından farklı olabilir.

for Süresi

Prometheus alerting rule içindeki for süresi koşulun kesintisiz ne kadar devam etmesi gerektiğini tanımlar. CPU veya disk latency spike'larında faydalıdır. Tamamen down olan kritik servislerde daha kısa tutulabilir. Historical incident verileri doğru süreyi seçmeye yardım eder. Alert review sırasında düzenli güncellenebilir.

Recovery Threshold

Recovery threshold alarmın hangi seviyede resolved olacağını ayrı tanımlamaya yarar. Firing threshold ile aynı değer kullanıldığında flapping riski artabilir. Örneğin yüksek alarm yüzde 90'da açılıp yüzde 80 altına inince kapanabilir. Aradaki fark stability sağlar. Metric'in normal varyasyonu dikkate alınmalıdır.

Hysteresis

Hysteresis alarmın açılma ve kapanma sınırlarını birbirinden ayırır. Elektronik ve kontrol sistemlerindeki benzer prensip monitoring için de faydalıdır. Threshold çevresindeki küçük dalgalanmaların notification üretmesini azaltır. Recovery condition açıkça tanımlanmalıdır. Dashboard üzerinde mevcut state yine görünür kalabilir.

Keep-Firing Süresi

Keep-firing davranışı koşul kısa süre normale dönse bile alarmın belirli süre aktif tutulmasını sağlayabilir. Çok dalgalı sinyallerde incident'ın parçalanmasını azaltır. Aşırı uzun süre yanlış alarm state'i gösterebilir. Kullanılan monitoring platformunun davranışı anlaşılmalıdır. Notification policy ile birlikte test edilmelidir.

Alertmanager Nedir?

Alertmanager Prometheus tarafından üretilen alarmların notification süreçlerini yönetir. Prometheus koşulun firing olup olmadığını belirlerken Alertmanager grouping, deduplication, routing, silencing ve inhibition görevlerini üstlenir. Bu görev ayrımı production alarm mimarisini daha yönetilebilir hale getirir. Doğru yapılandırıldığında yüzlerce benzer alarm tek anlamlı notification'a indirilebilir. Alertmanager'ın kendisi de high availability ve metamonitoring kapsamında izlenmelidir.

Prometheus ile Alertmanager Arasındaki Görev Ayrımı

Prometheus metric toplar ve alert rule değerlendirir. Alertmanager firing alarmları alıp notification politikasını uygular. Bu ayrım rule logic ile insan iletişim logic'ini birbirinden ayırır. Team routing değiştiğinde metric rule'u değiştirmek gerekmeyebilir. Mimari bakım açısından bu ayrım oldukça faydalıdır.

Grouping

Grouping ilişkili alarmları tek notification içinde birleştirir. Aynı service veya cluster için yüzlerce alarm çıkabilir. Grup anahtarları dikkatli seçilmelidir. Fazla geniş grouping farklı incident'ları birleştirebilir. Fazla dar grouping ise notification sayısını azaltmaz.

Deduplication

Deduplication aynı alarmın tekrarlanan kopyalarını azaltır. HA Prometheus replica'ları aynı alarmı üretebilir. Alertmanager bunları tek notification gibi yönetebilir. Fingerprint davranışı label setine bağlıdır. Gereksiz dinamik label'lar deduplication'ı bozabilir.

Routing

Routing alarmı doğru ekip ve kanala göndermeyi sağlar. Team, service, severity, environment veya region label'ları kullanılabilir. Kritik production alarmı on-call kanalına giderken warning ticket kanalına gönderilebilir. Route ağacı code review ile yönetilmelidir. Default route sahipsiz alarmı yakalayacak biçimde tasarlanmalıdır.

Silencing

Silencing belirli label eşleşmelerine sahip alarmları geçici süre notification dışı bırakır. Planned maintenance sırasında kullanışlıdır. Silence'ın owner ve expiration bilgisi olmalıdır. Süresiz silence gerçek problemleri gizleyebilir. Bakım bittikten sonra otomatik sona ermesi tercih edilmelidir.

Inhibition

Inhibition belirli bir root cause alarmı aktifken ilişkili diğer alarmları bastırır. Server down olduğunda üzerindeki her process için ayrı notification gönderilmesini önleyebilir. Dependency-aware alerting için güçlüdür. Matcher koşulları dikkatli tasarlanmalıdır. Yanlış inhibition gerçek bağımsız incident'ı gizleyebilir.

Notification

Alertmanager alarmı e-posta, chat, webhook veya on-call sistemine gönderebilir. Mesaj template'i yeterli teknik bağlam sağlamalıdır. Dashboard ve runbook linkleri eklenebilir. Notification failure ayrıca izlenmelidir. Test alarmı ile zincirin uçtan uca çalıştığı düzenli doğrulanmalıdır.

Alert Grouping

Alert grouping büyük incident'larda notification fırtınasını azaltmak için en etkili yöntemlerden biridir. Aynı root cause yüzlerce host ve service alarmı üretebilir. group_by, group_wait, group_interval ve repeat_interval ayarları notification davranışını kontrol eder. Doğru değerler incident bağlamına göre seçilmelidir. Service bazlı gruplama çoğu ekip için anlaşılır başlangıç sunar.

Aynı Incident İçin Yüzlerce Notification Problemi

Tek network problemi onlarca service ve host alarmını tetikleyebilir. Her alarm ayrı notification olduğunda gerçek root cause mesajlar arasında kaybolur. On-call kişi aynı incident için tekrar tekrar uyarılır. Grouping bu alarmları anlamlı paketler halinde sunar. Inhibition ile birlikte daha da güçlü hale gelir.

group_by

group_by hangi label'ların aynı notification grubunu oluşturacağını belirler. Service, alertname veya cluster kullanılabilir. Çok fazla label eklemek grupları parçalayabilir. Çok az label farklı incident'ları birleştirebilir. Gerçek incident örnekleri üzerinden test yapılmalıdır.

group_wait

group_wait ilk alarm geldikten sonra ilgili diğer alarmları toplamak için kısa bekleme süresidir. Çok kısa olursa grouping avantajı azalabilir. Çok uzun olursa kritik notification gecikir. Severity bazında farklı davranış gerekebilir. Production incident verileri süre seçimine yardımcı olur.

group_interval

group_interval mevcut gruba yeni alarm eklendiğinde notification güncellemesinin ne sıklıkla yapılacağını belirler. Çok kısa değer gürültü oluşturabilir. Çok uzun değer önemli yeni bilgiyi geciktirebilir. Servis türüne göre ayarlanabilir. Notification kanalı kapasitesi de göz önünde bulundurulmalıdır.

repeat_interval

repeat_interval çözülmemiş alarmın tekrar ne zaman hatırlatılacağını belirler. Çok sık tekrar on-call kişisini rahatsız eder. Çok uzun süre unresolved kritik incident'ın unutulmasına yol açabilir. Acknowledgement sistemi varsa tekrar davranışı farklı tasarlanabilir. Severity ve incident süresine göre karar verilmelidir.

Service Bazlı Gruplama

Service bazlı grouping kullanıcı etkisini aynı bağlam altında toplar. Aynı servisteki host ve component alarmları tek grup içinde görülebilir. Çok büyük servislerde component ayrımı eklenebilir. Ownership modeliyle uyumlu olması routing'i kolaylaştırır. Group label'ları dashboard filtreleriyle de eşleştirilebilir.

Alert Inhibition

Inhibition bilinen bir üst seviye problem aktifken onun doğal sonucu olarak oluşan alt seviye alarmları bastırır. Amaç gerçek bilgiyi gizlemek değil, duplicate notification yükünü azaltmaktır. Server down alarmı varken üzerindeki process, exporter ve application probe alarmları ayrı ayrı page gerektirmeyebilir. Dependency modeli bu nedenle önemlidir. Inhibition kuralları yanlış bağımsız alarmı bastırmamak için test edilmelidir.

Inhibition Nedir?

Inhibition source ve target alarm ilişkisine göre notification bastırma mekanizmasıdır. Source alarm aktifken matching target alarmlar gönderilmez. Alarm state sistemde var olmaya devam edebilir. Böylece dashboard visibility korunur. Sadece notification gürültüsü azaltılır.

Root Cause Alert

Root cause alert incident'ın temel nedenine en yakın alarmdır. Network gateway down veya server unreachable örnek olabilir. Bu alarm aktifken downstream semptomlar beklenen sonuç haline gelir. Root cause doğru seçilmezse inhibition zararlı olabilir. Dependency ilişkileri belgelenmelidir.

Downstream Alert'ları Bastırmak

Upstream dependency kesildiğinde birçok downstream servis hata üretebilir. Her biri ayrı page oluşturursa incident yönetimi zorlaşır. Inhibition aynı dependency'ye bağlı alarmları geçici olarak bastırabilir. User-facing ana semptom alarmı görünür kalmalıdır. Böylece ekip gerçek etkiye odaklanır.

Server Down İken Process Down Alarmlarını Bastırmak

Server erişilemiyorsa üzerindeki process'lerden metric alınamaması beklenen durumdur. Her process için ayrı alert göndermek ek bilgi sağlamaz. Host down alarmı source olarak kullanılabilir. Process alarm state'i dashboard'da yine görülebilir. Host geri döndüğünde inhibition otomatik olarak kalkmalıdır.

Dependency-Aware Alerting

Dependency-aware alerting servisler arasındaki bağımlılığı alarm mantığına taşır. Database down olduğunda ona bağlı uygulamaların error alması beklenebilir. Root cause sinyali ilgili downstream bildirimleri bastırabilir. Bu model için service dependency bilgisi güncel tutulmalıdır. Yanlış bağımlılık modeli önemli alarmın gizlenmesine yol açabilir.

Alert Silencing ve Maintenance Window

Planlı bakım sırasında beklenen alarmların on-call ekibine ulaşması gereksiz gürültü oluşturur. Silence belirli label'lar ve süre için notification'ı geçici olarak durdurur. Bu işlem kontrollü ve süreli yapılmalıdır. Owner bilgisi ve maintenance nedeni kayıt altına alınmalıdır. Bakım bittiğinde monitoring'in tekrar normal notification üretmesi doğrulanmalıdır.

Planned Maintenance

Planlı bakım alarm sisteminden bağımsız yürütülmemelidir. Etkilenecek service ve host'lar önceden belirlenebilir. Silence bakım penceresine göre zamanlanabilir. User-facing kritik blackbox check bazı durumlarda görünür bırakılabilir. Bakım sonrası health doğrulaması yapılmalıdır.

Silence Matcher

Silence matcher hangi alarmların notification dışı kalacağını label üzerinden belirler. Çok geniş matcher gereksiz alarmları da susturabilir. Environment ve service gibi label'lar dikkatli seçilmelidir. Matcher production öncesi gözden geçirilmelidir. Kritik global silence kullanımından kaçınılmalıdır.

Expiration

Her silence için bitiş zamanı bulunmalıdır. Süresiz veya çok uzun silence unutulabilir. Gerçek incident oluştuğunda notification gelmeyebilir. Bakım süresine küçük güvenlik payı eklemek yeterlidir. Uzatma gerekiyorsa bilinçli olarak yeniden yapılmalıdır.

Silence Sahipliği

Silence'ı kimin oluşturduğu açık biçimde kayıt altına alınmalıdır. Owner bakım sonunda doğrulama yapmalıdır. Ekip değişimlerinde sahipsiz silence risklidir. Açıklama alanına maintenance nedeni eklenebilir. Düzenli silence audit yapılması faydalıdır.

Sonsuz Silence Kullanmanın Riski

Süresiz silence alarm sisteminde kalıcı kör nokta oluşturabilir. Problem aylar sonra gerçek kullanıcı etkisine dönüşse bile notification gelmeyebilir. Bu nedenle expiration zorunlu politika haline getirilebilir. Uzun süre problem üreten alarm silinmeli veya düzeltilmelidir. Silence teknik borcu gizlemek için kullanılmamalıdır.

Alert Routing

Alert routing doğru alarmın doğru kişiye ulaşmasını sağlar. Team, service, severity, environment ve region gibi bilgiler routing kararında kullanılabilir. Tek bir global notification kanalı büyüyen ekiplerde hızla verimsiz hale gelir. Ownership modeli routing config ile uyumlu olmalıdır. Escalation kuralları kritik alarm acknowledge edilmediğinde devreye girebilir.

Team Bazlı Routing

Team label alarmı sorumlu ekibe yönlendirir. Ownership değiştiğinde config güncellenmelidir. Ortak altyapı alarmları platform ekibine giderken application alarmı servis ekibine gidebilir. Default route sahipsiz alarmı yakalamalıdır. Yanlış routing MTTA süresini uzatır.

Service Bazlı Routing

Service bazlı routing alarmı doğrudan ilgili servisin owner'ına gönderebilir. Microservice ortamlarında oldukça faydalıdır. Service catalog ile otomatik ilişki kurulabilir. Ortak dependency problemleri farklı route gerektirebilir. Service isimleri standart olmalıdır.

Severity Bazlı Routing

Critical alarm on-call platformuna, warning ticket sistemine yönlendirilebilir. Info dashboard veya düşük öncelikli stream içinde tutulabilir. Severity tanımlarının ekip içinde ortak anlamı olmalıdır. Her critical olayın aynı urgency'ye sahip olmadığı unutulmamalıdır. Ek routing label'ları kullanılabilir.

Environment Bazlı Routing

Production ve test ortamlarının alarm davranışı aynı olmak zorunda değildir. Production critical alarmı page üretirken staging alarmı chat kanalına gidebilir. Environment label standardize edilmelidir. Yanlış label production alarmının düşük öncelikli route'a düşmesine neden olabilir. Config testleri bu riski azaltır.

Region Bazlı Routing

Global sistemlerde region bilgisi yerel owner veya follow-the-sun modeline yardımcı olabilir. Bölgesel incident yalnızca ilgili ekip tarafından ele alınabilir. Aynı zamanda global outage durumunda merkezi escalation gerekir. Region label routing ve dashboard için ortak kullanılabilir. Eksik region metadata sorun yaratabilir.

Escalation

Escalation kritik alarm belirli sürede acknowledge edilmediğinde ikincil kişiye veya ekibe yönlendirilmesini sağlar. Primary ve secondary roller açık olmalıdır. Süre service tier'a göre değişebilir. Gereksiz hızlı escalation birden fazla kişiyi aynı anda rahatsız edebilir. Test senaryolarıyla süreç düzenli doğrulanmalıdır.

Notification Kanalları

Alarm kanalı seçimi severity ve urgency ile uyumlu olmalıdır. E-posta düşük aciliyetli bildirimler için yeterli olabilirken kritik production incident'ında telefon veya on-call platformu tercih edilebilir. Slack ve Microsoft Teams ekip koordinasyonu için kullanılabilir. Webhook otomasyon veya incident sistemi entegrasyonunda faydalıdır. Birden fazla kanal kullanırken duplicate notification ve ownership karışıklığı önlenmelidir.

E-posta

E-posta düşük ve orta öncelikli alarmlar için kullanılabilir. Gece kritik incident'larda fark edilme garantisi sınırlıdır. Mesaj subject ve body içinde service, severity ve mevcut durum bulunmalıdır. Thread yapısı incident güncellemelerini takip etmeyi kolaylaştırabilir. Spam yoğunluğu alarm güvenilirliğini azaltmamalıdır.

Slack

Slack ekip içi operasyon koordinasyonunda hızlı görünürlük sağlar. Alarm mesajı ilgili kanala route edilebilir. Critical alarm yalnızca Slack'e bırakılmamalı, gerekiyorsa on-call sistemiyle desteklenmelidir. Thread kullanımı incident konuşmalarını düzenli tutabilir. Hassas telemetry verileri mesaj içine eklenmemelidir.

Microsoft Teams

Microsoft Teams benzer biçimde ekip notification kanalı olarak kullanılabilir. Incoming webhook veya ilgili entegrasyonlar üzerinden alarm mesajları gönderilebilir. Mesaj içinde severity, service ve runbook bağlantısı bulunmalıdır. Kritik olaylarda acknowledgement mekanizması ayrıca düşünülmelidir. Kanal sahipliği operasyon modeline göre tanımlanmalıdır.

SMS

SMS internet tabanlı uygulama bildirimlerinin sorun yaşadığı durumlarda alternatif olabilir. Mesaj uzunluğu sınırlı olduğu için kritik bilgiler önceliklendirilmelidir. Çok fazla SMS alarm fatigue yaratabilir. Yalnızca yüksek urgency olaylar için kullanılması daha uygundur. Kişisel telefon bilgilerinin güvenli yönetimi gerekir.

Telefon

Telefon araması yüksek urgency incident'larda güçlü notification yöntemidir. Gece uyandırma maliyeti yüksek olduğu için yalnızca gerçek kritik olaylarda kullanılmalıdır. Yanlış alarm oranı düşük tutulmalıdır. Escalation zinciri tanımlanabilir. Düzenli test ile arama zincirinin çalıştığı doğrulanmalıdır.

Push Notification

Push notification mobil on-call uygulamalarında hızlı uyarı sağlar. Acknowledge özelliği operasyon sürecini kolaylaştırabilir. İnternet bağlantısı problemi olabileceği için kritik sistemlerde yedek kanal düşünülebilir. Notification permission durumu kontrol edilmelidir. Alarm içeriği kilit ekranında hassas veri göstermemelidir.

Pager / On-Call Platform

On-call platformu rotation, escalation ve acknowledgement süreçlerini merkezi biçimde yönetebilir. Kritik alert lifecycle için chat kanalından daha uygundur. Primary ve secondary kişiler otomatik belirlenebilir. MTTA ve alert volume gibi metrikler ölçülebilir. Platformun kendisi de dependency olarak değerlendirilmelidir.

Webhook

Webhook alarm verisini farklı sistemlere programatik olarak aktarır. Incident management, otomasyon veya custom notification akışlarında kullanılabilir. Endpoint failure ve timeout davranışı izlenmelidir. Authentication ve TLS kullanılmalıdır. Payload içinde gereksiz hassas bilgi gönderilmemelidir.

Her Alarm Mesajında Hangi Bilgiler Olmalı?

İyi alarm mesajı mühendisin farklı sistemlerde bilgi aramasını minimuma indirir. Alert name, severity, service, environment, başlangıç zamanı, mevcut değer ve threshold temel bağlamı oluşturur. Kullanıcı etkisi alarmın neden önemli olduğunu açıklar. Dashboard ve runbook bağlantıları ilk müdahaleyi hızlandırır. Owner bilgisi alarmın kimin sorumluluğunda olduğunu netleştirir.

Alert Name

Alert name kısa ve anlamlı olmalıdır. Teknik metric adından daha anlaşılır bir olay ismi tercih edilebilir. İsim rule değişse bile operasyon dilinde tutarlı kalmalıdır. Service bilgisi gerektiğinde label olarak ayrı tutulabilir. Çok genel isimler incident aramasını zorlaştırır.

Severity

Severity alarmın etki seviyesini hızlı gösterir. Tanımı organizasyon içinde standart olmalıdır. Critical, warning veya P seviyeleri kullanılabilir. Renk tek başına bilgi taşımamalıdır. Notification routing severity'yi kullanabilir.

Service

Service alarmın hangi kullanıcı veya teknik hizmeti etkilediğini gösterir. Ownership ve routing için temel bilgidir. Standardize edilmiş service adı kullanılmalıdır. Host adıyla service adı karıştırılmamalıdır. Bir host birden fazla servis taşıyabilir.

Environment

Environment production, staging veya development ayrımını gösterir. Aynı alarm farklı environment'larda farklı severity'ye sahip olabilir. Routing kararında kullanılabilir. Mesaj içinde görünür olması yanlış müdahaleyi önler. Label standardı önemlidir.

Başlangıç Zamanı

Alarmın ne zaman başladığı incident timeline için temel bilgidir. Deployment veya configuration değişikliğiyle korelasyon yapılabilir. Timezone standardı belirlenmelidir. On-call kişi problemin ne kadar süredir devam ettiğini anlar. Duration ayrıca hesaplanabilir.

Mevcut Değer

Current value alarm koşulunun gerçek ölçümünü gösterir. "Disk yüksek" yerine "kalan alan 8 GB" daha açıklayıcıdır. Metric unit mutlaka belirtilmelidir. Percentile veya rate kullanılıyorsa açık yazılmalıdır. Mühendis threshold ile farkı hızlı değerlendirebilir.

Threshold

Threshold alarmın hangi sınır nedeniyle oluştuğunu gösterir. Süre koşulu varsa ayrıca belirtilmelidir. Dynamic threshold kullanılıyorsa baseline bilgisi faydalı olabilir. Recovery threshold farklıysa runbook içinde açıklanabilir. Alarm mantığı gizemli olmamalıdır.

Kullanıcı Etkisi

User impact alarmın teknik önemini iş sonucuna bağlar. Kaç kullanıcının veya hangi akışın etkilendiği biliniyorsa belirtilmelidir. Kesin veri yoksa abartılı tahmin yapılmamalıdır. Error rate ve availability gibi ölçümler kullanılabilir. Incident severity kararını hızlandırır.

Dashboard Linki

Dashboard linki mühendisi doğrudan ilgili zaman aralığı ve servise götürmelidir. Genel ana sayfa yerine filtreli görünüm daha faydalıdır. Link mümkünse alarm timestamp bağlamını korumalıdır. Erişim yetkileri on-call ekibinde hazır olmalıdır. Kırık dashboard linkleri düzenli kontrol edilmelidir.

Runbook

Runbook ilk kontrol ve recovery adımlarını içerir. Alarm mesajından tek tıklamayla erişilebilir olmalıdır. Kısa ve uygulanabilir yazılmalıdır. Servis değişiklikleriyle güncel tutulmalıdır. Incident sonrası öğrenilen yeni adımlar eklenebilir.

Owner

Owner alarmın hangi ekip veya kişi grubuna ait olduğunu gösterir. Routing ile tutarlı olmalıdır. Service catalog kullanılıyorsa otomatik üretilebilir. Sahipsiz alarm uzun MTTA oluşturabilir. Ownership değişiklikleri code review ile güncellenmelidir.

Alert Ownership

Alarm sisteminin kalitesi yalnızca teknik rule doğruluğuna bağlı değildir. Her alarmın belirli owner'ı olmalıdır. Team ve service ownership route config, runbook ve dashboard ile eşleştirilmelidir. Owner değişiklikleri organizasyon yapısıyla birlikte güncellenmezse alarmlar yanlış kişilere gitmeye başlar. Sahipsiz alarm zaman içinde monitoring technical debt'e dönüşür.

Her Alarmın Sahibi Olmalı

Bir alarm oluştuğunda kimin bakacağı önceden bilinmelidir. Incident sırasında owner aramak gereksiz zaman kaybettirir. Label üzerinden ownership tanımlanabilir. Default routing sahipsiz alarmı merkezi ekibe yönlendirebilir. Ancak bu yalnızca geçici güvenlik ağı olmalıdır.

Team Ownership

Team ownership ilgili alarmın bir ekip tarafından yönetilmesini sağlar. Ekip rotation ve escalation politikasını belirleyebilir. Shared service'lerde ortak ownership açıkça tanımlanmalıdır. Team adı reorganizasyon sonrası güncellenmelidir. Eski route'lar düzenli audit edilmelidir.

Service Ownership

Service ownership alarmı teknik hizmet sorumluluğuyla eşleştirir. Microservice ortamlarında service catalog faydalı olabilir. Dashboard, repository ve runbook bilgileri aynı kayıt altında tutulabilir. Alarm routing otomatik türetilebilir. Bu yaklaşım metadata tutarlılığını artırır.

Owner Olmayan Alarmın Riski

Sahipsiz alarm notification kanalına düşer ancak kimse aksiyon almayabilir. Tekrarlandıkça ekip mesajı görmezden gelmeye başlar. MTTA artar ve gerçek incident riski büyür. Sahipsiz rule belirli süre içinde owner atanmıyorsa kaldırılabilir. Alert review bu kontrolleri içermelidir.

Ownership Değişikliklerini Güncel Tutmak

Ekip yapıları ve servis sorumlulukları zaman içinde değişir. Monitoring config bu değişiklikleri takip etmelidir. Code owner veya service catalog entegrasyonu yardımcı olabilir. Offboarding sonrası kişisel notification route bırakılmamalıdır. Düzenli audit operasyon güvenilirliğini artırır.

Runbook Nedir?

Runbook belirli alarm veya incident için uygulanabilecek doğrulama, diagnosis ve recovery adımlarını açıklayan operasyon dokümanıdır. Amaç on-call mühendisine hızlı başlangıç noktası sağlamaktır. Alarmın anlamı, olası nedenler, ilk kontroller, escalation ve rollback adımları yer alabilir. Runbook otomasyon komutu listesi değil, güvenli karar rehberi olmalıdır. Incident sonrası öğrenilen yeni bilgilerle güncellenmelidir.

Alarmın Anlamı

Runbook alarmın hangi koşulda oluştuğunu açıklar. Metric ve threshold bilgisi anlaşılır biçimde yazılmalıdır. Kullanıcı etkisi belirtilmelidir. False positive olabilecek bilinen durumlar eklenebilir. Böylece mühendis alarmın bağlamını hızlı kavrar.

Olası Nedenler

Bilinen yaygın nedenler kısa biçimde sıralanabilir. CPU alarmı için trafik artışı, runaway process veya dependency retry örnek olabilir. Kesin neden gibi sunulmamalıdır. Incident sırasında yeni ihtimaller araştırılabilir. Liste geçmiş postmortem'lerden beslenebilir.

İlk Kontroller

İlk kontroller birkaç dakikada incident'ın kapsamını anlamayı sağlamalıdır. Dashboard, recent deployment ve dependency health kontrol edilebilir. Kullanıcı etkisi doğrulanmalıdır. Gerekli log veya trace bağlantıları verilebilir. En hızlı bilgi sağlayan adımlar üstte yer almalıdır.

Diagnosis Adımları

Diagnosis adımları problemi katmanlar halinde daraltmalıdır. Application, dependency ve infrastructure sinyalleri karşılaştırılabilir. Gerekli query örnekleri verilebilir. Tehlikeli production komutlarından kaçınılmalıdır. Her adımın hangi soruyu cevapladığı açıklanmalıdır.

Recovery Adımları

Recovery adımları hizmeti güvenli biçimde normale döndürmeyi hedefler. Restart tek refleks olmamalıdır. Capacity artırma, failover veya rollback seçenekleri riskleriyle birlikte yazılabilir. Veri kaybı ihtimali varsa ekstra onay gerekebilir. Recovery sonrası metric normalleşmesi doğrulanmalıdır.

Escalation

Runbook hangi durumda başka ekibe veya daha kıdemli kişiye escalation yapılacağını belirtmelidir. Belirli süre içinde root cause bulunamaması kriter olabilir. Security veya data loss riski ayrı escalation gerektirebilir. İletişim kanalı açık yazılmalıdır. Sahipsiz escalation noktalarından kaçınılmalıdır.

Rollback

Deployment kaynaklı problemde rollback hızlı mitigation olabilir. Runbook güvenli rollback prosedürünü gösterebilir. Database migration gibi geri dönüşü zor değişiklikler ayrıca belirtilmelidir. Rollback sonrası health check yapılmalıdır. Deployment annotation incident timeline içinde kontrol edilmelidir.

Alert Fatigue Nedir?

Alert fatigue ekiplerin çok fazla, gereksiz veya tekrarlanan alarm nedeniyle bildirimlere duyarlılığını kaybetmesidir. Bu durum gerçek kritik incident'ın gözden kaçma riskini artırır. False positive, non-actionable ve duplicate alarmlar en sık nedenler arasındadır. Eski servislerden kalan outdated rule'lar da gürültü üretir. Alert volume ve notification-to-action rate gibi metrikler sorunu ölçmeye yardımcı olur.

False Positive

False positive alarm gerçek problem olmadığı halde firing olur. Yanlış threshold veya kısa spike buna neden olabilir. Sürekli false positive üreten rule güven kaybı oluşturur. Duration ve baseline iyileştirilebilir. Çözülmüyorsa alarm kaldırılmalıdır.

Non-Actionable Alert

Non-actionable alarm mühendis müdahale edemediği veya etmesine gerek olmayan durumu bildirir. Bu tip alarm page kanalında olmamalıdır. Dashboard veya ticket daha uygun olabilir. Her alarm için "Bu mesaj geldiğinde ne yapacağız?" sorusu sorulmalıdır. Cevap yoksa rule yeniden tasarlanmalıdır.

Duplicate Alert

Duplicate alarm aynı incident için tekrarlanan bildirimler üretir. HA replica veya downstream effect buna neden olabilir. Deduplication ve grouping kullanılmalıdır. Root cause ilişkisi varsa inhibition eklenebilir. Duplicate volume incident sırasında dikkati dağıtır.

Outdated Alert

Servis mimarisi değiştiğinde eski alarm anlamını kaybedebilir. Artık kullanılmayan endpoint veya host için rule kalabilir. Düzenli alert review bu kuralları temizlemelidir. Ownership değişiklikleri de kontrol edilmelidir. Monitoring config yaşayan bir sistem olarak yönetilmelidir.

Poorly Configured Alert

Yanlış label, threshold veya duration alarm davranışını bozabilir. Çok geniş query gereksiz host'ları kapsayabilir. Eksik environment filtresi test sistemini production gibi page edebilir. Rule review ve unit test bu riski azaltır. Production değişiklikleri version control üzerinden yapılmalıdır.

Alert Fatigue'in On-Call Ekibine Etkisi

Sık gece alarmı on-call yorgunluğu ve stres oluşturur. Mühendisler bildirimlerin çoğunun önemsiz olduğuna inanırsa gerçek alarma tepki süresi uzayabilir. MTTA ve acknowledge davranışı bunu gösterebilir. Alert quality operasyon sağlığının parçasıdır. Daha az fakat güvenilir page hedeflenmelidir.

Alert Fatigue Nasıl Azaltılır?

Alert fatigue'i azaltmanın en etkili yolu alarm sayısını kör biçimde düşürmek değil, aksiyon değeri olmayan alarmları temizlemektir. Kullanıcı etkisini önceliklendirmek, pending süreleri eklemek ve grouping kullanmak temel adımlardır. Deduplication ve inhibition aynı incident kaynaklı gürültüyü azaltır. Maintenance sırasında kontrollü silence kullanılmalıdır. Düzenli alert review hangi rule'ların gerçekten işe yaradığını gösterir.

Daha Az Ama Daha Kaliteli Alarm

Page kanalı yalnızca acil ve aksiyon alınabilir olaylara ayrılmalıdır. Her metric için alarm oluşturmak kaliteyi artırmaz. User-facing semptomlar önceliklendirilmelidir. Kök neden metrikleri dashboard'da tutulabilir. On-call ekibinin her page'e güvenmesi hedeflenmelidir.

Kullanıcı Etkisini Önceliklendirmek

Error rate, availability ve latency kullanıcı deneyimine yakın sinyallerdir. CPU veya RAM yüksekliği tek başına page üretmek zorunda değildir. SLO burn rate kullanıcı etkisini daha sistematik ölçebilir. Business impact biliniyorsa severity belirlemede kullanılabilir. Bu yaklaşım alarm hacmini doğal biçimde azaltır.

Pending Süresi

Pending period kısa ve geçici metric spike'larını filtreler. Süre her alarm için aynı olmamalıdır. Critical availability kaybı hızlı firing gerektirebilir. Resource threshold daha uzun süre doğrulanabilir. Historical incident verisi doğru süreyi seçmeye yardımcı olur.

Grouping

Grouping aynı incident'a ait alarmları tek mesaj altında toplar. Notification sayısını düşürür ve bağlamı artırır. Service veya cluster bazlı grouping kullanılabilir. group_wait kritik alarmı gereksiz geciktirmemelidir. Gerçek incident örnekleri üzerinden ayarlar test edilmelidir.

Deduplication

Deduplication aynı alarmın kopyalarını tek notification'a indirir. HA sistemlerinde özellikle önemlidir. Label seti gereksiz değişkenlik içerirse deduplication bozulabilir. Alarm identity standardı belirlenmelidir. Notification manager health ayrıca izlenmelidir.

Inhibition

Inhibition root cause aktifken beklenen downstream alarmları bastırır. Host down olduğunda process down notification'larını engellemek tipik örnektir. Rule'lar dependency modeline dayanmalıdır. Çok geniş inhibition gerçek problemi gizleyebilir. Test senaryoları oluşturulmalıdır.

Maintenance Silence

Planlı bakım sırasında beklenen alarmlar silence ile bastırılabilir. Silence süresi bakım penceresiyle sınırlı olmalıdır. Owner bilgisi bulunmalıdır. Sonsuz silence kullanılmamalıdır. Bakım sonrası notification zinciri gerektiğinde test edilmelidir.

Düzenli Alert Review

Alert review geçmiş dönemde firing olan alarmların kalitesini değerlendirir. Kaçı gerçek incident üretti, kaçı aksiyon aldı ve kaçı false positive oldu sorulabilir. Kullanılmayan rule'lar silinebilir. Threshold ve runbook güncellenebilir. Bu çalışma monitoring sisteminin zaman içinde bozulmasını önler.

Alarm Ne Zaman Silinmelidir?

Bir monitoring kuralı yıllardır var diye sonsuza kadar kalmak zorunda değildir. Kimsenin aksiyon almadığı, artık bulunmayan servise ait veya sürekli false positive üreten alarm silinmelidir. Daha iyi bir üst seviye semptom alarmı aynı riski kapsıyorsa alt seviye page kaldırılabilir. Gereksiz rule'lar monitoring technical debt oluşturur. Silme kararı geçmiş incident verisi ve owner görüşüyle alınabilir.

Kimse Aksiyon Almıyorsa

Bir alarm firing olduğunda sürekli ignore ediliyorsa alarmın değeri sorgulanmalıdır. Belki notification kanalı yanlıştır veya rule gereksizdir. Aksiyon tanımlanabiliyorsa runbook eklenebilir. Aksiyon yoksa page kaldırılmalıdır. Dashboard metriği olarak kalabilir.

Artık Var Olmayan Servise Aitse

Decommission edilen servislerin rule ve dashboard'ları temizlenmelidir. Eski target absence alarmları gereksiz notification oluşturabilir. Service lifecycle süreçlerine monitoring cleanup adımı eklenebilir. Ownership kayıtları da silinmelidir. Böylece config zamanla gereksiz büyümez.

Her Zaman False Positive Üretiyorsa

Bir rule sürekli yanlış alarm veriyorsa önce threshold ve duration düzeltilmelidir. Baseline yanlış olabilir. Metric kalitesi düşük olabilir. Sorun çözülemiyorsa alarmı tutmak faydadan çok zarar verir. Silinmesi on-call güvenilirliğini artırabilir.

Daha İyi Bir Üst Seviye Alarm Tarafından Kapsanıyorsa

User-facing availability alarmı incident'ı güvenilir biçimde yakalıyorsa her host metriğinin page olması gerekmeyebilir. Alt seviye sinyaller dashboard'da tutulabilir. Böylece kök neden araştırma verisi kaybolmaz. Notification sayısı azalır. Üst seviye alarmın gerçekten tüm önemli olayları yakaladığı incident geçmişiyle doğrulanmalıdır.

Monitoring Technical Debt

Eski rule, kırık dashboard, yanlış owner ve kullanılmayan metric monitoring technical debt oluşturur. Sistem büyüdükçe bakım maliyeti artar. Düzenli cleanup sprint'i planlanabilir. Alert volume ve unused dashboard raporları yardımcı olabilir. Monitoring ürün gibi sürekli yönetilmelidir.

SLI, SLO ve SLA Nedir?

SLI, SLO ve SLA hizmet kalitesini kullanıcı açısından ölçmek için kullanılan ilişkili kavramlardır. SLI ölçülen göstergedir, SLO hedeflenen seviyedir ve SLA taraflar arasındaki resmi hizmet taahhüdünü ifade edebilir. Monitoring sistemi SLI ölçümlerinin güvenilir kaynağı olmalıdır. SLO alarm tasarımını altyapı threshold'larından kullanıcı hedeflerine taşıyabilir. Error budget yaklaşımı reliability ile değişiklik hızını dengelemek için kullanılır.

Service Level Indicator

SLI hizmet kalitesini sayısal olarak ölçen göstergedir. Availability, latency veya successful request oranı örnek olabilir. Kullanıcı deneyimine yakın seçilmelidir. Ölçüm kaynağı güvenilir olmalıdır. SLI tanımı service dokümantasyonunda açıkça belirtilmelidir.

Service Level Objective

SLO belirli pencere içinde SLI için hedeflenen seviyedir. Örneğin başarılı request oranının 30 gün içinde yüzde 99,9 olması hedeflenebilir. Hedef gerçek business ihtiyacına göre seçilmelidir. Gereksiz yüksek SLO operasyon maliyetini artırabilir. Error budget SLO'dan türetilir.

Service Level Agreement

SLA müşteri veya taraflar arasında tanımlanan hizmet taahhüdüdür. SLO ile aynı olmak zorunda değildir. Finansal veya sözleşmesel sonuçlar içerebilir. Monitoring ölçümlerinin SLA hesaplamasıyla uyumu önemlidir. Tanımlar hukuk ve iş ekipleriyle birlikte netleştirilmelidir.

Monitoring ile İlişkileri

Monitoring SLI verisini üretir ve SLO performansını hesaplamaya yardımcı olur. Alarm yalnızca CPU değil SLO ihlali riski üzerinden tasarlanabilir. Error budget tüketimi release kararlarını etkileyebilir. Dashboard üzerinde mevcut SLO durumu gösterilebilir. Veri kalitesi düşükse tüm hesaplamalar güvenilirliğini kaybeder.

Availability SLI Nasıl Hesaplanır?

Basit availability SLI başarılı isteklerin toplam geçerli isteklere oranı olarak hesaplanabilir. Ancak hangi request'lerin good veya bad sayılacağı açık tanımlanmalıdır. Client hataları her zaman servis başarısızlığı değildir. Measurement window SLO değerlendirmesini etkiler. Yüzde 99,9 gibi hedefler kalan hata bütçesinin ne kadar olduğunu somut biçimde gösterir.

Successful Requests / Total Requests

Başarılı request sayısı toplam geçerli request sayısına bölünebilir. Hangi status veya business sonucu başarı sayılacak belirlenmelidir. Load balancer ve application metric kaynakları farklı sonuç verebilir. Ölçüm noktası kullanıcı deneyimine yakın olmalıdır. SLI query version control altında tutulabilir.

Good Event

Good event hizmet beklentisini karşılayan işlemdir. HTTP 2xx her zaman business success anlamına gelmeyebilir. Domain-specific kriter eklenebilir. Tanım sade ve ölçülebilir olmalıdır. Ekipler arasında ortak kabul sağlanmalıdır.

Bad Event

Bad event kullanıcı açısından başarısız kabul edilen işlemdir. Server error, timeout veya yanlış business response olabilir. Client kaynaklı hatalar gerektiğinde hariç tutulabilir. Tanım değişirse historical karşılaştırmalar etkilenebilir. SLO dokümanında açıkça yazılmalıdır.

Measurement Window

Measurement window SLO'nun değerlendirildiği süreyi belirler. Otuz günlük rolling window yaygın bir yaklaşımdır. Calendar month veya farklı pencere de kullanılabilir. Burn rate hesapları pencereye bağlıdır. Dashboard'da pencere açık biçimde belirtilmelidir.

%99.9 Ne Anlama Gelir?

Yüzde 99,9 SLO toplam olayların yüzde 0,1'inin başarısız olmasına izin verildiği anlamına gelir. Bu oran request tabanlı ölçümde trafik miktarına uygulanır. Time-based availability kullanılıyorsa izin verilen downtime süresine dönüşebilir. Hedef bağlama göre yorumlanmalıdır. Yüzde değeri tek başına business gereksinimi olmadan seçilmemelidir.

Error Budget Nedir?

Error budget SLO'nun izin verdiği başarısızlık payıdır. Yüzde 99,9 hedefte kalan yüzde 0,1 budget olarak düşünülebilir. Bu budget'ın ne hızla tükendiği reliability riskini gösterir. Release hızı ile sistem stabilitesi arasında karar mekanizması oluşturabilir. Monitoring error budget consumption değerini sürekli hesaplayabilir.

SLO ile Error Budget İlişkisi

Error budget doğrudan SLO hedefinden türetilir. SLO yükseldikçe izin verilen hata payı azalır. Gerçek performans hedefin üzerindeyse budget korunur. Hızlı tüketim riskin arttığını gösterir. Ekip release ve reliability çalışmalarını bu veriye göre dengeleyebilir.

Allowed Failure

Allowed failure sistemin hedef dahilinde tolere edebileceği hata miktarıdır. Sıfır hata hedeflemek çoğu servis için gerçekçi değildir. Bu yaklaşım engineering maliyetini business beklentisiyle dengeler. Kritik servisler daha düşük hata payına sahip olabilir. Tanım kullanıcı etkisine dayanmalıdır.

Error Budget Consumption

Consumption belirli dönemde budget'ın ne kadarının kullanıldığını gösterir. Tek incident büyük bölümü tüketebilir. Dashboard üzerinde yüzdelik kalan budget gösterilebilir. Hızlı tüketim burn rate alarmı üretir. Budget bitişi release politikasını etkileyebilir.

Release Hızı ile Reliability Dengesi

Sürekli değişiklik yapmak ürün gelişimini hızlandırır ancak her değişiklik risk taşır. Error budget ekiplerin ne kadar risk alabileceğini görünür hale getirir. Budget sağlıklıysa release hızına devam edilebilir. Budget hızla tükeniyorsa reliability çalışmalarına öncelik verilebilir. Bu karar kurumsal politika ile desteklenmelidir.

Burn Rate Alerting

Burn rate error budget'ın planlanan süreden ne kadar hızlı tüketildiğini ölçer. Sabit error rate threshold yerine SLO bağlamında risk değerlendirir. Kısa window hızlı büyük incident'ları, uzun window ise kalıcı düşük seviyeli bozulmaları yakalayabilir. Multi-window yaklaşımı false positive'i azaltmaya yardımcı olur. Bu yöntem kullanıcı etkisine yakın page alarmı tasarlamak için güçlü seçeneklerden biridir.

Burn Rate Nedir?

Burn rate budget tüketim hızının hedeflenen tüketim hızına oranıdır. Değer 1 civarında budget planlanan hızda kullanılıyor demektir. Çok yüksek değer budget'ın hızlı biteceğini gösterir. SLO window bağlamında yorumlanmalıdır. Alarm threshold'u service tier'a göre ayarlanabilir.

Error Budget Ne Hızla Tüketiliyor?

Consumption hızı yalnızca mevcut error rate'ten daha anlamlı olabilir. Aynı error rate farklı SLO hedeflerinde farklı risk taşır. Burn rate bunu normalize eder. Kısa incident'ın etkisi budget üzerinden görülebilir. Ekip mitigation aciliyetini daha iyi değerlendirebilir.

Kısa Window

Kısa window ani ve büyük hatalara hızlı tepki verir. Örneğin son beş veya on dakikalık pencere kullanılabilir. Tek kısa spike false positive üretebilir. Bu nedenle daha uzun window ile birlikte koşul kurulabilir. Büyük user-facing outage için hızlı detection sağlar.

Uzun Window

Uzun window düşük seviyeli ancak kalıcı bozulmaları yakalar. Saatlik veya daha geniş pencere kullanılabilir. Kısa spike etkisini yumuşatır. Incident'ın uzun süre devam edip etmediğini gösterir. Multi-window tasarımında kısa pencereyi doğrular.

Multi-Window Multi-Burn-Rate

Bu yaklaşım birden fazla zaman penceresi ve burn rate threshold'u birlikte kullanır. Büyük incident hızlı, küçük fakat uzun incident daha yavaş alarm üretebilir. Kullanıcı etkisini error budget bağlamında değerlendirir. Rule'lar önce test ortamında doğrulanmalıdır. SLO query'lerinin doğru olması kritik önemdedir.

Neden Sabit Threshold'dan Daha Anlamlı Olabilir?

Sabit yüzde threshold service hedefini hesaba katmaz. Burn rate SLO ve allowed failure ile doğrudan bağlantılıdır. Böylece aynı error rate farklı kritik seviyedeki servislerde farklı değerlendirilebilir. Alarm gerçek reliability riskini daha iyi temsil eder. On-call sayısını azaltırken kullanıcı etkisini yakalama şansını artırabilir.

SLO Bazlı Alarm ile CPU Alarmı Arasındaki Fark

SLO tabanlı alarm doğrudan kullanıcı tarafından algılanan hizmet kalitesini ölçmeye çalışır. CPU alarmı ise olası teknik nedeni gösterir. CPU yükselmesine rağmen SLO etkilenmeyebilir. Tersine CPU normal görünürken external dependency nedeniyle SLO bozulabilir. Page kararında SLO sinyali, troubleshooting sırasında CPU metriği birlikte kullanılabilir.

Cause vs Symptom

CPU yüksekliği cause sinyalidir. Error rate veya availability bozulması symptom sinyalidir. Page kullanıcı semptomunu hedeflediğinde daha az gürültü üretir. Cause dashboard'da kök neden araştırmasına yardımcı olur. İki veri birlikte güçlüdür.

User Impact

SLO doğrudan kullanıcı kalite hedefini temsil eder. CPU ise kullanıcı etkisini dolaylı gösterir. Bu nedenle aynı CPU değeri farklı servislerde farklı sonuç yaratabilir. User impact severity kararını daha doğru hale getirir. Business metric gerektiğinde ek bağlam sağlar.

Noise

Resource threshold'ları workload dalgalanmalarında sık firing olabilir. SLO alarmı yalnızca hizmet hedefi etkilenince çalıştığı için daha az gürültü üretebilir. Ancak SLO yanlış tanımlanırsa gerçek incident kaçabilir. Veri kalitesi önemlidir. Her iki alarm türü düzenli review edilmelidir.

Page Kararı

Page hızlı insan müdahalesi gereken olaylara ayrılmalıdır. SLO burn rate bunun için güçlü sinyal olabilir. CPU high alarm ticket veya dashboard seviyesinde tutulabilir. CPU ile kullanıcı error birlikteyse severity yükseltilebilir. Bu hiyerarşi on-call deneyimini geliştirir.

CPU Alarmını Troubleshooting Sinyali Olarak Kullanmak

CPU metric'ini tamamen kaldırmak doğru değildir. Incident başladığında sorunun resource saturation kaynaklı olup olmadığını gösterir. Grafana dashboard üzerinde SLO alarmından CPU paneline geçiş sağlanabilir. Deployment annotation ek bağlam sunar. Böylece page sayısı azalırken teknik görünürlük korunur.

Synthetic Monitoring

Synthetic monitoring gerçek kullanıcı beklemeden belirli kullanıcı akışlarını düzenli biçimde çalıştırır. HTTP endpoint kontrolünden tam login akışına kadar farklı seviyelerde uygulanabilir. Multi-region test bölgesel erişim problemlerini ortaya çıkarabilir. Synthetic check gerçek kullanıcı telemetry'sinin yerini tamamen almaz. Ancak kritik yolculukların proaktif kontrolü için güçlü bir tamamlayıcıdır.

Synthetic Check Nedir?

Synthetic check otomatik bir test isteğinin belirli aralıklarla çalıştırılmasıdır. Gerçek kullanıcı gelmese bile servisin çalışıp çalışmadığını doğrular. Response status, content ve duration ölçülebilir. Test verileri production business metriklerini bozmayacak biçimde işaretlenmelidir. Failure alarmı duration ile doğrulanabilir.

HTTP Endpoint

Basit synthetic check belirli HTTP endpoint'e istek gönderebilir. Expected status ve response content doğrulanabilir. Authentication gerekiyorsa güvenli test credential kullanılmalıdır. Endpoint gerçek dependency'leri gerektiği ölçüde kapsamalıdır. Sadece static health endpoint tüm kullanıcı yolculuğunu temsil etmeyebilir.

Login Flow

Login flow synthetic test kullanıcı adı, parola girişi ve başarılı oturum kontrolünü kapsayabilir. Authentication dependency problemlerini yakalar. Test hesabı production verilerinden ayrılmalıdır. Credential güvenli secret storage içinde tutulmalıdır. Çok sık test rate limit veya security sistemlerini etkileyebilir.

User Journey

User journey birden fazla adımı kapsayan synthetic senaryodur. Login, ürün görüntüleme ve kritik işlem doğrulaması örnek olabilir. Gerçek business akışına daha yakındır. Failure olduğunda hangi adımda koptuğu kaydedilmelidir. Test data cleanup süreci düşünülmelidir.

Multi-Region Test

Aynı synthetic test farklı region'lardan çalıştırılabilir. Böylece DNS, CDN veya network kaynaklı bölgesel problemler ayırt edilebilir. Tek location failure global outage olarak yorumlanmamalıdır. Region bazlı alarm grouping yapılabilir. Global severity birden fazla location etkilenmesine göre belirlenebilir.

Gerçek Kullanıcıdan Önce Hata Tespit Etmek

Synthetic monitoring düşük trafikli saatlerde bile servisi düzenli test eder. Bu nedenle gerçek kullanıcı bildirimi gelmeden problem yakalanabilir. Certificate, DNS veya login dependency failure erken görülebilir. Ancak synthetic test kapsamının sınırlı olduğu unutulmamalıdır. Real user metrics ile birlikte kullanıldığında en iyi sonucu verir.

Uptime Monitoring

Uptime monitoring bir servisin belirli süre boyunca erişilebilirliğini ölçer. Ping tek başına bu amaç için yetersizdir, çünkü host network seviyesinde erişilebilirken uygulama bozuk olabilir. HTTP status, response content, response time ve dependency davranışı birlikte ölçülebilir. Multi-location test gerçek internet erişimini daha iyi temsil eder. Uptime metriği SLI hesaplamasının bir parçası haline getirilebilir.

Ping Tek Başına Yeterli mi?

Hayır, ping yalnızca belirli network seviyesinde cevap alındığını gösterir. Web server process durmuş olabilir. TLS veya DNS problemi kullanıcı erişimini engelleyebilir. HTTP veya protocol seviyesinde kontrol eklenmelidir. Ping yardımcı sinyal olarak kalabilir.

HTTP Status

HTTP status endpoint'in temel response sonucunu gösterir. 2xx beklenen servis için 5xx doğrudan failure olabilir. Redirect davranışı gerektiğinde doğrulanmalıdır. 200 status sahte sağlık göstergesi olabilir. Response content ek kontrol sağlar.

Response Content

Response content uygulamanın beklenen cevabı gerçekten ürettiğini doğrular. Error page yanlışlıkla 200 dönebilir. Küçük ve stabil bir içerik kontrolü kullanılmalıdır. Hassas veya dinamik veri kontrol edilmemelidir. Test mümkün olduğunca hafif olmalıdır.

Response Time

Servis erişilebilir olsa bile aşırı yavaş olabilir. Response time uptime kontrolüne performans boyutu ekler. Threshold region'a göre değişebilir. Percentile historical trend olarak tutulabilir. Kullanıcı SLO hedefleriyle ilişkilendirilebilir.

Dependency Check

Health endpoint dependency durumunu da kontrol edebilir ancak aşırı kapsamlı health check zincirleme failure oluşturabilir. Liveness ve readiness amaçları ayrılmalıdır. Synthetic test gerçek kullanıcı akışını daha iyi temsil edebilir. Dependency bazlı dashboard sorunun nerede olduğunu gösterir. Tek bir "healthy" boolean ayrıntıyı gizlememelidir.

Multi-Location Monitoring

Farklı location'lardan uptime kontrolü internet path sorunlarını ayırt eder. Tek probe failure local sorun olabilir. Birden fazla region aynı anda başarısızsa global incident ihtimali artar. Alarm aggregation buna göre yapılabilir. DNS ve TLS testleri aynı dış noktadan çalıştırılabilir.

Logs, Metrics ve Traces Nasıl Birlikte Kullanılır?

Metrics ne olduğunu hızlı gösterir, logs olayın ayrıntısını sunar ve traces isteğin servisler arasında nerede zaman harcadığını açıklar. Üç sinyal aynı resource ve correlation bilgilerini paylaştığında incident araştırması çok hızlanır. Metric alarmından ilgili trace'e, oradan aynı trace ID'ye sahip loglara geçmek güçlü bir workflow oluşturur. Deployment annotation ve service metadata bağlamı daha da artırır. Amaç mümkün olduğunca çok veri toplamak değil, doğru soruyu hızla cevaplayacak telemetry üretmektir.

Metrics: Ne Oldu?

Metrics sistem davranışındaki sayısal değişimi gösterir. Error rate arttı mı, latency yükseldi mi veya disk capacity azaldı mı hızlıca görülebilir. Aggregate yapısı trend analizi için uygundur. Tek request ayrıntısını göstermez. Investigation başlangıç noktası olarak güçlüdür.

Logs: Ayrıntıda Ne Oldu?

Logs belirli olayların mesaj ve bağlam bilgilerini içerir. Error stack, operation sonucu veya dependency response görülebilir. Structured logging sorgulamayı kolaylaştırır. Password, token ve kişisel veri loglanmamalıdır. Trace ID eklemek korelasyonu güçlendirir.

Traces: Nerede Yavaşladı?

Trace tek request'in servisler arası yolculuğunu gösterir. Her span belirli operation süresini ve ilişkisini temsil eder. Dependency latency kolayca görülebilir. Sampling maliyet yönetiminde kullanılabilir. Metric exemplars trace'e geçişi kolaylaştırabilir.

Correlation

Correlation farklı telemetry türlerini ortak kimlikler üzerinden bağlar. Service name, instance, region ve trace ID kullanılabilir. Timestamp senkronizasyonu önemlidir. Ortak resource attributes standardı kurulmalıdır. Bu yapı incident sırasında araçlar arasında kaybolmayı azaltır.

Aynı Incident İçinde Üç Sinyali Birleştirmek

Örneğin p99 latency alarmı incident'ı başlatabilir. Grafana paneli belirli deployment sonrası artışı gösterebilir. İlgili exemplar trace'e götürür ve trace database çağrısının yavaşladığını gösterir. Trace ID ile loglarda timeout mesajı bulunabilir. Bu zincir MTTD sonrasındaki diagnosis süresini ciddi biçimde azaltır.

OpenTelemetry'nin Monitoring'deki Rolü

OpenTelemetry metrics, logs ve traces üretimi ve taşınması için ortak telemetry standartları sağlar. Vendor-neutral yaklaşımı uygulamaların tek bir backend'e sıkı bağlanmasını azaltabilir. OpenTelemetry Collector receiver, processor ve exporter katmanları üzerinden veri pipeline'ı oluşturur. OTLP ortak taşıma protokollerinden biridir. Monitoring sistemlerinde özellikle metric, trace ve log correlation için önemli rol oynar.

OpenTelemetry Nedir?

OpenTelemetry telemetry oluşturma, toplama ve taşıma için açık standart ve araç setidir. Application instrumentation için API ve SDK'lar sunar. Collector merkezi veya agent modunda çalışabilir. Backend seçimini tamamen ortadan kaldırmaz ancak veri üretim katmanını daha taşınabilir hale getirir. Service metadata standardizasyonuna yardımcı olur.

Metrics

OpenTelemetry metric API uygulama seviyesinde sayısal ölçümler üretmeyi sağlar. Counter, gauge benzeri enstrümanlar kullanılabilir. Resource attributes servis kimliğini taşır. Metric backend'e Collector üzerinden gönderilebilir. Cardinality kuralları burada da geçerlidir.

Logs

Log sinyali structured event'lerin ortak telemetry bağlamıyla taşınmasına yardımcı olur. Trace ve span ID korelasyonu eklenebilir. Hassas veri filtering Collector aşamasında uygulanabilir. Log volume storage maliyetini etkiler. Retention ve sampling stratejisi gerekebilir.

Traces

Tracing request yolculuğunu span'lar üzerinden temsil eder. Context propagation servisler arasında bağlantıyı korur. Sampling maliyeti kontrol etmek için kullanılabilir. Error ve latency araştırmasında yüksek değer taşır. Resource metadata metrics ve logs ile aynı tutulmalıdır.

OpenTelemetry Collector

Collector telemetry verisini alır, işler ve backend'lere aktarır. Receiver kaynaklardan veri kabul eder. Processor filtering, batching veya enrichment yapabilir. Exporter hedef sisteme gönderim yapar. Pipeline config version control altında tutulmalıdır.

OTLP

OTLP OpenTelemetry telemetry verisinin taşınması için kullanılan protokoldür. gRPC veya HTTP tabanlı kullanım mümkündür. Uygulama ve Collector arasında standart bağlantı sağlar. Network güvenliği için TLS kullanılmalıdır. Retry ve queue davranışı production kapasitesine göre ayarlanmalıdır.

Vendor-Neutral Telemetry

Vendor-neutral yaklaşım instrumentation kodunu belirli gözlem platformundan ayırmaya yardımcı olur. Backend değişikliğinde application kodunun tamamını yeniden yazma ihtiyacı azalabilir. Yine de metric semantics ve query yapıları backend'e göre farklılaşabilir. Ortak resource naming standardı önemlidir. Collector bu soyutlama katmanını güçlendirebilir.

OpenTelemetry Collector Mimarisi

OpenTelemetry Collector receiver, processor ve exporter bileşenlerini pipeline içinde birleştirir. Agent mode host'a yakın telemetry toplarken gateway mode merkezi işleme ve routing sağlar. İki model birlikte de kullanılabilir. Batching, retry, filtering ve enrichment gibi işlemler collector katmanında yönetilebilir. Collector'un kendisi queue, memory ve export failure metrikleriyle izlenmelidir.

Receiver

Receiver farklı protocol veya kaynaktan telemetry kabul eder. OTLP, host metrics veya farklı input türleri kullanılabilir. Gereksiz receiver açılmamalıdır. Network erişimi sınırlandırılmalıdır. Receiver error ve accepted item sayıları monitoring için değerlidir.

Processor

Processor telemetry backend'e gitmeden önce veriyi işler. Batch, filter, attributes veya memory limiter gibi işlemler uygulanabilir. Sıralama bazı durumlarda önemlidir. Hassas veri redaction burada yapılabilir. Yanlış processor config veri kaybına neden olabilir.

Exporter

Exporter işlenmiş telemetry'yi hedef backend'e gönderir. Retry ve queue ayarları network kesintilerinde önemlidir. Permanent failure ayrı izlenmelidir. Birden fazla exporter farklı backend'lere veri gönderebilir. Authentication secret'ları güvenli yönetilmelidir.

Pipeline

Pipeline receiver, processor ve exporter zincirini tanımlar. Metrics, logs ve traces ayrı pipeline'lara sahip olabilir. Config açık ve version control altında tutulmalıdır. Büyük değişiklikler test ortamında doğrulanmalıdır. Pipeline health metrikleri metamonitoring'e eklenmelidir.

Agent Mode

Agent mode Collector'un host veya workload'a yakın çalışmasını sağlar. Local log ve host metric toplama için uygundur. Merkezi gateway'e OTLP gönderebilir. Çok sayıda agent configuration management ihtiyacı oluşturur. Resource footprint izlenmelidir.

Gateway Mode

Gateway mode merkezi veya bölgesel Collector katmanı sağlar. Routing, filtering ve export işlemleri tek noktada yönetilebilir. High availability planlanmalıdır. Gateway saturation telemetry kaybına yol açabilir. Queue ve export latency alarmı gereklidir.

Metric–Trace–Log Correlation

Metric, trace ve log korelasyonu monitoring verisini araştırma workflow'una dönüştürür. Ortak trace ID, span ID ve resource attributes sinyaller arasında bağlantı sağlar. Metric exemplar belirli latency örneğinden trace'e geçiş sunabilir. Trace içinden ilişkili loglara ulaşmak root cause araştırmasını hızlandırır. Bu tasarım özellikle mikroservis sistemlerinde ciddi operasyon avantajı sağlar.

Trace ID

Trace ID tek request zincirinin ortak kimliğidir. Servisler arasında context propagation ile taşınır. Loglara eklenirse aynı request'e ait kayıtlar bulunabilir. Kişisel veri değildir ancak güvenlik politikaları yine uygulanmalıdır. Trace backend sorgularının temel anahtarlarından biridir.

Span ID

Span ID trace içindeki belirli operation'ı temsil eder. Parent-child ilişkisi request yolculuğunu oluşturur. Log içinde span ID kullanımı daha hassas correlation sağlar. Her span gerekli değildir. Instrumentation kalite ve maliyet dengesiyle tasarlanmalıdır.

Resource Attributes

Resource attributes service name, environment, region ve instance gibi ortak metadata taşır. Metrics, logs ve traces üzerinde tutarlı olması gerekir. Farklı isimler correlation'ı zorlaştırır. Semantic convention kullanımı faydalıdır. High-cardinality değerler dikkatle seçilmelidir.

Exemplars

Exemplar aggregate metric bucket'ından belirli örnek trace'e bağlantı sağlayabilir. Özellikle latency histogramlarında değerlidir. p99 spike görüldüğünde gerçek request trace'i açılabilir. Her backend exemplar desteklemeyebilir. Instrumentation ve storage davranışı önceden doğrulanmalıdır.

Dashboard'dan Trace'e Geçiş

Grafana benzeri dashboard üzerinde metric spike seçildiğinde ilgili trace'e bağlantı sağlanabilir. Bu geçiş incident investigation süresini kısaltır. Time range ve service context korunmalıdır. Trace backend erişimi on-call ekibinde hazır olmalıdır. Linklerin kırık kalmaması için entegrasyon test edilmelidir.

Trace'den Log'a Geçiş

Trace içindeki span ID veya trace ID log sorgusunda kullanılabilir. Böylece problemli request'in ayrıntılı hata mesajı bulunur. Timestamp ve service metadata eşleşmesi önemlidir. Structured logging bu workflow'u güçlendirir. Hassas veri loglarda maskelenmelidir.

Monitoring Verisinde Cardinality ve Maliyet

Monitoring sistemi sınırsız veri depolayan ücretsiz bir alan değildir. Her yeni metric, label kombinasyonu ve uzun retention süresi CPU, memory ve storage maliyeti oluşturur. Label explosion en hızlı büyüme nedenlerinden biridir. Sampling ve aggregation bazı telemetry türlerinde maliyeti kontrol etmeye yardımcı olabilir. Kullanılmayan metric'leri düzenli temizlemek sürdürülebilir monitoring için gereklidir.

Çok Fazla Metric Toplamanın Bedeli

Her metric sample storage tüketir. Query engine daha fazla seri üzerinde çalıştıkça CPU ve memory ihtiyacı artar. Çok sayıda gereksiz metric dashboard'ları da zorlaştırır. Metric'in hangi soruyu cevapladığı bilinmelidir. Kullanılmayan metric'ler instrumentation'dan kaldırılabilir.

Label Explosion

Label explosion sınırsız farklı değerlerin yeni time series üretmesidir. User ID ve raw URL sık görülen nedenlerdir. Seri sayısı kısa sürede milyonlara çıkabilir. Prometheus memory baskısı yaşayabilir. Label policy ve cardinality monitoring uygulanmalıdır.

Retention

Retention telemetry'nin ne kadar süre saklanacağını belirler. Daha uzun süre capacity planning ve historical analiz için faydalıdır. Ancak storage maliyeti artar. Raw ve downsampled veri için farklı süreler kullanılabilir. Compliance ihtiyaçları ayrıca değerlendirilmelidir.

Sampling

Sampling özellikle trace verisinde maliyeti azaltır. Her request'in trace'ini tutmak yüksek trafikte pahalı olabilir. Error veya high-latency trace'leri daha yüksek oranda saklamak mümkündür. Sampling kararının troubleshooting ihtiyaçlarını bozmadığı doğrulanmalıdır. Metric verisi için farklı aggregation stratejileri kullanılır.

Aggregation

Aggregation yüksek detaylı veriyi daha düşük cardinality özetlere dönüştürebilir. Uzun dönem raporlarında günlük veya saatlik aggregate yeterli olabilir. Raw verinin kısa retention ile tutulması mümkündür. SLO hesapları doğru aggregation semantics gerektirir. Gereksiz detay storage maliyetini artırmamalıdır.

Kullanılmayan Metric'leri Silmek

Hiçbir dashboard, alert veya raporda kullanılmayan metric'ler düzenli tespit edilebilir. Silmeden önce gelecekteki troubleshooting ihtiyacı değerlendirilmelidir. Ownership bilgisi karar sürecini kolaylaştırır. Metric removal versioned change olarak yapılmalıdır. Böylece observability maliyeti kontrol altında tutulur.

Monitoring Data Retention

Retention planı operational troubleshooting, capacity planning ve compliance ihtiyaçlarını birlikte değerlendirmelidir. Son birkaç günün raw metric'i ayrıntılı incident analizi için gerekli olabilir. Aylar önceki veri için downsampling yeterli olabilir. Long-term storage ayrı sistem üzerinde tutulabilir. Retention kararı storage bütçesi ve sorgu ihtiyacına göre verilmelidir.

Raw Metric Retention

Raw metric en yüksek zaman çözünürlüğünü korur. Incident analizi için değerlidir. Uzun süre saklandığında storage maliyeti yükselir. Scrape interval kapasiteyi doğrudan etkiler. Kritik metric ve genel telemetry aynı retention'a sahip olmak zorunda değildir.

Downsampling

Downsampling eski verinin daha düşük çözünürlükle saklanmasını sağlar. Capacity trendleri için dakika yerine saatlik aggregate yeterli olabilir. Storage ihtiyacını düşürür. Peak değerlerin kaybolmaması için doğru aggregation seçilmelidir. SLO hesapları için veri yöntemi ayrıca doğrulanmalıdır.

Long-Term Storage

Long-term storage Prometheus local retention sınırlarının ötesinde veri saklamayı sağlar. Remote write tabanlı sistemler kullanılabilir. Query latency ve cost model değerlendirilmelidir. HA replica verisinin deduplication davranışı önemlidir. Backup ve disaster recovery planı da gereklidir.

Capacity Planning

Uzun dönem metric verisi büyüme trendlerini görmek için değerlidir. CPU, memory, disk ve traffic artışı incelenebilir. Forecast modelleri historical data gerektirir. Retention çok kısa olursa sezonluk davranış görülemez. Kapasite planı iş büyüme tahminleriyle birlikte yapılmalıdır.

Compliance Gereksinimleri

Bazı telemetry verileri düzenleyici veya kurum içi saklama gereksinimlerine tabi olabilir. Metric'ler çoğu zaman kişisel veri içermemelidir. Logs için risk daha yüksektir. Retention policy veri sınıflandırmasına göre tanımlanmalıdır. Gereğinden uzun saklama da risk oluşturabilir.

Prometheus Uzun Süreli Saklama ve Ölçeklendirme

Tek Prometheus instance küçük ve orta ortamlar için güçlü olabilir ancak retention ve scale ihtiyaçları büyüdükçe ek mimari gerekebilir. Local TSDB kısa dönem operasyon verisi için kullanılabilir. Remote write uzun dönem veya merkezi backend'e veri aktarabilir. Thanos, Grafana Mimir ve VictoriaMetrics gibi çözümler farklı ölçekleme yaklaşımları sunar. Mimari seçim target sayısı, cardinality, retention ve operasyon becerisine göre yapılmalıdır.

Local TSDB

Prometheus local TSDB veriyi kendi diskinde saklar. Basit ve hızlı operasyon modeli sunar. Disk arızası veya instance kaybı uzun dönem veriyi etkileyebilir. Retention local kapasiteye göre ayarlanmalıdır. HA için iki replica kullanılabilir.

Remote Write

Remote write metric sample'larını harici backend'e aktarmayı sağlar. Long-term storage veya merkezi metric platformu için kullanılabilir. Queue, retry ve dropped sample metrikleri izlenmelidir. Network kesintisi kapasite baskısı yaratabilir. Remote endpoint security önemlidir.

Thanos

Thanos Prometheus ekosisteminde long-term storage, global query ve HA deduplication ihtiyaçları için kullanılabilir. Object storage yaklaşımı uzun dönem saklama sağlar. Birden fazla component operasyon yükü getirir. Query ve compaction davranışı izlenmelidir. Küçük ortamlar için gereksiz ek yapı olabilir.

Grafana Mimir

Grafana Mimir ölçeklenebilir merkezi metric storage yaklaşımı sunar. Multi-tenant kullanım senaryolarında değerlendirilebilir. Dağıtık component yapısı operasyon bilgisi gerektirir. Cardinality ve ingestion limitleri planlanmalıdır. Küçük ekipler önce gerçek scale ihtiyacını ölçmelidir.

VictoriaMetrics

VictoriaMetrics time-series storage ve Prometheus uyumlu ingestion ihtiyaçlarında kullanılabilen seçeneklerden biridir. Tek node ve cluster mimarileri farklı ölçekler için değerlendirilebilir. Query uyumluluğu kullanılacak sorgularla test edilmelidir. Retention ve replication planı yapılmalıdır. Operasyon modeli mevcut ekip bilgisiyle karşılaştırılmalıdır.

Merkezi ve Dağıtık Mimari

Merkezi sistem yönetimi kolaylaştırabilir ancak failure domain büyüyebilir. Dağıtık Prometheus yapısı bölgesel bağımsızlık sağlar. Global query ihtiyacı ek katman gerektirir. Network partition senaryoları düşünülmelidir. Mimari organizasyon yapısı ve service ownership modeliyle uyumlu olmalıdır.

Prometheus High Availability

Tek Prometheus instance monitoring sisteminde single point of failure oluşturabilir. İki replica aynı target'ları scrape ederek HA sağlayabilir. Ancak her replica aynı alarmı üreteceği için Alertmanager deduplication önem kazanır. External labels replica veya cluster kimliğini taşıyabilir. Long-term storage tarafında duplicate sample davranışı ayrıca değerlendirilmelidir.

Tek Prometheus Instance Riski

Prometheus down olursa metric collection ve alert evaluation durabilir. Bu durum gerçek production incident sırasında görünürlük kaybı yaratır. Monitoring sistemi kritik dependency olarak ele alınmalıdır. External heartbeat körlüğü fark edebilir. Yüksek kritik ortamlarda replica kullanılmalıdır.

İki Prometheus Replica

İki replica aynı target setini bağımsız scrape edebilir. Bir instance kaybedildiğinde diğeri metric toplamaya devam eder. Configuration mümkün olduğunca aynı tutulmalıdır. Rule evaluation iki tarafta da yapılabilir. Notification deduplication gerekir.

Aynı Target'ları Scrape Etmek

Replica'ların aynı target'ları scrape etmesi metric continuity sağlar. Scrape interval hizalı olmak zorunda değildir. Target yükü iki kat scrape isteğini kaldırmalıdır. Exporter endpoint'leri genellikle hafiftir ancak kapasite değerlendirilmelidir. Farklı failure domain'lerde çalıştırmak faydalıdır.

Alert Deduplication

İki Prometheus aynı alert'i firing yapabilir. Alertmanager label setine göre duplicate notification'ı azaltır. Replica label alarm identity'yi bozmayacak biçimde yönetilmelidir. HA testinde tek Prometheus kapatılarak notification davranışı doğrulanabilir. Duplicate page on-call güvenini azaltır.

External Labels

External labels Prometheus instance veya cluster kimliğini eklemek için kullanılabilir. Long-term query sistemlerinde kaynak ayrımına yardımcı olur. Replica label deduplication sistemiyle uyumlu olmalıdır. İsimler standartlaştırılmalıdır. Gereksiz label cardinality artırmamalıdır.

Long-Term Store

HA Prometheus replica'ları long-term store'a veri gönderdiğinde duplicate series oluşabilir. Backend deduplication yaklaşımı değerlendirilmelidir. Remote write ve sidecar modelleri farklı davranabilir. Query sonuçlarının iki kat görünmemesi gerekir. Failure senaryoları production öncesi test edilmelidir.

Alertmanager High Availability

Tek Alertmanager notification zincirinde single point of failure oluşturabilir. Cluster mode birden fazla instance'ın koordineli çalışmasını sağlar. Peer communication state paylaşımı için önemlidir. Notification deduplication aynı alarmın birden fazla kez gönderilmesini azaltır. Cluster'ın kendisi availability ve peer health metrikleriyle izlenmelidir.

Alertmanager Cluster

Birden fazla Alertmanager instance HA amacıyla cluster oluşturabilir. Prometheus birden fazla endpoint'e alert gönderebilir. Instance'lar notification state paylaşır. Farklı failure domain kullanmak faydalıdır. Cluster partition senaryoları değerlendirilmelidir.

Peer Communication

Peer communication Alertmanager node'larının birbirleriyle state paylaşmasını sağlar. Network problemi cluster koordinasyonunu etkileyebilir. Peer sayısı ve health izlenmelidir. Firewall configuration doğru yapılmalıdır. Cluster recovery davranışı test edilmelidir.

Notification Deduplication

HA ortamında aynı alert birden fazla Alertmanager'a ulaşabilir. Deduplication kullanıcıya tek notification gitmesini hedefler. Cluster state problemi duplicate mesaj oluşturabilir. Test alarmı ile davranış doğrulanmalıdır. Notification ID ve timestamp incident incelemesinde yardımcı olur.

Tek Notification Manager Riskini Önlemek

Alert rule doğru çalışsa bile notification manager down ise on-call kişi alarmı göremez. Bu nedenle monitoring zincirinin her katmanı redundant olmalıdır. External heartbeat son notification noktasını kontrol edebilir. HA yalnızca process sayısını artırmak değil failure domain ayırmak anlamına gelir. Düzenli failover testi yapılmalıdır.

Monitoring Sistemini Kim İzleyecek?

Monitoring sistemi production sistemlerini izlerken kendi sağlığını da görünür tutmalıdır. Prometheus availability, scrape failure, rule evaluation failure, Alertmanager health, notification error ve storage kapasitesi metamonitoring kapsamındadır. Aksi durumda sistem sessizce körleşebilir. Monitoring sistemini yalnızca kendisiyle izlemek tam güvence sağlamaz. Bu nedenle bağımsız external check ve heartbeat eklenmelidir.

Metamonitoring Nedir?

Metamonitoring monitoring altyapısının kendisini izlemektir. Collector, query, alert ve notification component'leri takip edilir. Resource saturation da önemlidir. Kendi metriklerini kendi sisteminde tutmak faydalıdır ancak dış doğrulama gerektirir. Kritik monitoring ortamı ayrı failure domain'e sahip olabilir.

Prometheus Availability

Prometheus HTTP health endpoint dışarıdan kontrol edilebilir. Scrape ve query davranışı ayrıca izlenmelidir. Process ayakta olsa bile storage problemi yaşayabilir. Replica health ayrı ayrı gösterilmelidir. External check alerting körlüğünü fark edebilir.

Alertmanager Availability

Alertmanager down olduğunda firing alert'ler notification'a dönüşmeyebilir. Cluster node health ve peer state izlenmelidir. API endpoint blackbox test edilebilir. Notification queue veya error metric'leri takip edilmelidir. Failover düzenli test edilmelidir.

Scrape Failure

Target scrape failure monitoring görünürlüğünü azaltır. Tek target failure servis probleminden veya network erişiminden kaynaklanabilir. Çok sayıda aynı anda failure collector veya network sorununu gösterebilir. Scrape duration ve last success birlikte değerlendirilebilir. Critical target'lar farklı severity taşıyabilir.

Rule Evaluation Failure

Alert rule syntax veya query problemi evaluation failure oluşturabilir. Böyle bir durumda beklenen alarm hiç firing olmayabilir. Rule evaluation error metriği kritik metamonitoring sinyalidir. CI validation riski azaltır. Production config reload sonrası health kontrolü yapılmalıdır.

Notification Failure

Webhook, email veya on-call provider erişim problemi notification failure oluşturabilir. Alert firing olsa bile insan haberdar olmaz. Delivery error ve retry metrikleri izlenmelidir. Secondary kanal düşünülebilir. Dead man's switch zincirin uçtan uca çalışmasını doğrular.

Storage Problemi

Prometheus disk dolması metric ingestion'ı etkileyebilir. Disk capacity ve I/O latency izlenmelidir. Retention ayarı capacity ile uyumlu olmalıdır. WAL veya compaction problemleri ayrıca görülebilir. Monitoring storage alarmı başka bağımsız notification yoluna sahip olabilir.

Monitoring Sistemini Dışarıdan İzlemek

Monitoring sisteminin kendi health alarmını yine aynı sistem üzerinden göndermek tek failure domain yaratabilir. External blackbox check ve dead man's switch bu riski azaltır. Heartbeat düzenli olarak dış bir noktaya gönderilir. Beklenen heartbeat gelmezse monitoring veya notification zincirinde problem olduğu anlaşılır. Test alarmı metric'ten on-call kişisine kadar tüm akışı doğrulamalıdır.

External Blackbox Check

Dış sistem Prometheus veya Alertmanager endpoint'ini kontrol edebilir. Böylece local monitoring tamamen down olduğunda bile sinyal alınabilir. Network erişimi güvenli biçimde sınırlandırılmalıdır. Health endpoint hassas veri göstermemelidir. Birden fazla location gerekirse kullanılabilir.

Dead Man's Switch

Dead man's switch normalde sürekli gelmesi beklenen sinyal kesildiğinde alarm üretir. Klasik alert'ten ters mantıkla çalışır. Monitoring sisteminin sessizce durmasını yakalamak için uygundur. Heartbeat interval ve grace period doğru seçilmelidir. Dış notification provider kullanılması failure domain'i ayırır.

Heartbeat

Heartbeat belirli aralıklarla başarılı monitoring zinciri sinyali üretir. Son başarılı zaman izlenir. Belirlenen süre aşılırsa external alarm çalışır. Cron job ve backup monitoring için de aynı fikir kullanılabilir. Heartbeat'in sahte başarı üretmediği doğrulanmalıdır.

Test Alarmı

Test alarmı gerçek rule ve notification pipeline'ını düzenli doğrular. Metric veya synthetic event kontrollü biçimde firing yapılabilir. Notification'ın doğru on-call ekibine ulaştığı kontrol edilir. Test label'ı incident istatistiklerinden ayrılabilir. Otomatik haftalık veya aylık test politikası uygulanabilir.

Notification Zincirinin Uçtan Uca Doğrulanması

Uçtan uca test yalnızca Prometheus'un alert ürettiğini kontrol etmez. Metric'in oluşmasından on-call kişinin bildirimi almasına kadar tüm zincir doğrulanır. Her katmanın failure ihtimali vardır. Test sonucu kayıt altına alınabilir. Böylece monitoring sistemi gerçekten işe yarayan bir güvenlik mekanizmasına dönüşür.

Metric

Test için kontrollü metric üretilebilir. Metric belirlenen değere ulaştığında alert rule firing olmalıdır. Metric freshness doğrulanmalıdır. Test production kullanıcı verisini etkilememelidir. İşlem bittikten sonra metric state normale dönmelidir.

Prometheus

Prometheus test metriğini scrape etmeli ve rule'u evaluate etmelidir. Pending ve firing geçişleri kontrol edilebilir. Replica'lar varsa ikisinde de davranış izlenebilir. Rule evaluation error olmamalıdır. Test sonucu dashboard'da görünmelidir.

Alertmanager

Alertmanager firing alarmını almalı ve doğru grouping ile route etmelidir. Silence veya inhibition yanlışlıkla testi bastırmamalıdır. Notification state incelenebilir. HA cluster davranışı doğrulanabilir. Resolve mesajı gerekiyorsa ayrıca test edilmelidir.

Notification Provider

E-posta, chat veya on-call provider alarmı gerçekten almalıdır. Webhook response success tek başına kullanıcıya ulaştığını garanti etmeyebilir. Provider delivery status mümkünse izlenmelidir. Secondary kanal senaryosu test edilebilir. Rate limit etkileri göz önünde bulundurulmalıdır.

On-Call Person

Son aşamada gerçek rotation içindeki kişinin notification aldığı doğrulanmalıdır. Acknowledge işlemi incident sistemine yansımalıdır. Escalation timeout kontrollü test edilebilir. Test önceden işaretlenerek gereksiz panik önlenebilir. Bu doğrulama zincirin gerçek dünyada çalıştığını kanıtlar.

Monitoring-as-Code ve Alert-as-Code

Monitoring configuration'ını kod gibi yönetmek değişikliklerin izlenmesini, review edilmesini ve geri alınmasını kolaylaştırır. Prometheus rules, Grafana provisioning ve altyapı tanımları Git repository içinde tutulabilir. Terraform gibi araçlar uygun kaynakların yönetiminde kullanılabilir. Her değişiklik pull request üzerinden incelenebilir. Bu yaklaşım yanlış production alarm değişikliklerini azaltır ve audit izi oluşturur.

Monitoring Configuration'ını Git'te Tutmak

Configuration Git içinde versionlanınca kimin neyi ne zaman değiştirdiği görülür. Rollback kolaylaşır. Branch ve review süreçleri uygulanabilir. Secret değerler repository içine yazılmamalıdır. CI syntax ve unit test çalıştırabilir.

Prometheus Rules

Recording ve alerting rules dosya olarak yönetilebilir. Rule isimlendirmesi standardize edilmelidir. Pull request içinde threshold ve duration tartışılabilir. promtool benzeri doğrulamalar CI'da çalıştırılabilir. Production reload sonrası health kontrol edilmelidir.

Grafana Provisioning

Dashboard ve data source tanımları provisioning ile koddan yönetilebilir. Manual değişiklik drift oluşturabilir. Repository tek referans noktası haline getirilebilir. Environment-specific değerler template yöntemiyle ayrılabilir. Dashboard review teknik kaliteyi artırır.

Terraform

Terraform desteklenen monitoring kaynaklarının declarative yönetiminde kullanılabilir. Dashboard, alert veya contact point gibi kaynaklar provider yeteneklerine göre yönetilebilir. State güvenliği önemlidir. Secret değerler dikkatli ele alınmalıdır. Plan çıktısı change review için faydalıdır.

Code Review

Alarm değişikliği production davranışını etkileyen kod değişikliği gibi incelenmelidir. Query doğruluğu, severity, owner ve runbook kontrol edilebilir. Reviewer service context'i bilmelidir. Çok geniş matcher veya threshold hataları review sırasında yakalanabilir. Böylece alarm kalitesi ekip sorumluluğuna dönüşür.

Change History

Git history alarmın zaman içinde nasıl değiştiğini gösterir. Incident sonrası hangi rule versiyonunun aktif olduğu bulunabilir. Postmortem kararları commit ile ilişkilendirilebilir. Audit ihtiyacı kolaylaşır. Manual UI değişikliklerinden kaçınılması bu değeri korur.

Rollback

Yanlış alarm değişikliği hızlıca önceki versiyona döndürülebilir. Rollback mekanizması config deployment pipeline içinde test edilmelidir. Rule removal veya rename etkileri dikkate alınmalıdır. Dashboard ve notification config için de benzer yaklaşım kullanılabilir. Sonrasında health doğrulaması yapılmalıdır.

Alarm Kuralları Test Edilebilir mi?

Evet, alarm kuralları production incident beklenmeden test edilmelidir. Syntax validation ilk adımdır fakat yeterli değildir. PromQL sorgusu beklenen metric seti üzerinde doğrulanabilir. Unit test ve synthetic metric ile firing ve resolve senaryoları kontrol edilebilir. CI/CD içinde bu testlerin çalışması alarm değişikliklerini daha güvenli hale getirir.

Rule Syntax Validation

Syntax validation config'in parse edilip edilemediğini kontrol eder. Basit yazım hatalarını production öncesi yakalar. CI içinde otomatik çalıştırılmalıdır. Syntax doğru olması logic'in doğru olduğu anlamına gelmez. Query sonucu ayrıca test edilmelidir.

PromQL Testi

PromQL query gerçek veya fixture metric verisi üzerinde çalıştırılabilir. Label eşleşmeleri kontrol edilmelidir. Empty result alarmın hiç çalışmamasına neden olabilir. Fazla geniş query gereksiz target'ları kapsayabilir. Expected output test case olarak yazılabilir.

Unit Test

Prometheus alert rules için belirli input series ve expected alert sonuçları tanımlanabilir. Threshold crossing ve duration davranışı test edilir. Label ve annotation çıktıları doğrulanabilir. Regression riskini azaltır. Kritik rule'lar unit test olmadan değiştirilmemelidir.

Synthetic Metric

Controlled metric üretip gerçek pipeline'ı test etmek mümkündür. Test alarmı production user impact oluşturmamalıdır. Label ile test olayı ayrıştırılabilir. Firing ve notification görülmelidir. Sonrasında metric normale çekilip resolve davranışı kontrol edilmelidir.

Firing Senaryosu

Test input threshold'u aşmalı ve gerekli süre devam etmelidir. Alarmın pending'den firing'e geçmesi gözlenir. Routing ve grouping doğru çalışmalıdır. Mesajda gerekli annotation bilgileri görünmelidir. Acknowledge süreci gerekiyorsa test edilir.

Resolve Senaryosu

Metric normal seviyeye döndüğünde alarm resolved olmalıdır. Recovery threshold ve hysteresis davranışı kontrol edilir. Flapping oluşmaması beklenir. Resolve notification gerekiyorsa doğrulanır. Incident sistemi state'i güncellemelidir.

CI/CD İçinde Alert Testleri

Alert config değişikliği pull request açıldığında otomatik test çalıştırılabilir. Syntax, unit test ve policy kontrolü uygulanabilir. Owner veya runbook eksik rule engellenebilir. Deployment sonrası smoke test eklenebilir. Monitoring-as-code yaklaşımı böylece gerçek kalite kapısına dönüşür.

Monitoring Güvenliği

Monitoring altyapısı production sistemleri hakkında değerli teknik bilgi içerir. Metrics endpoint'lerini doğrudan internete açmak risklidir. TLS, authentication, RBAC ve network segmentation uygulanmalıdır. Collector ve dashboard kullanıcılarına least privilege verilmelidir. Monitoring sisteminin kendisi güvenlik kontrollerinin dışında bırakılmamalıdır.

Monitoring Endpoint'lerini İnternete Açmamak

Exporter endpoint'leri host, process ve network bilgileri gösterebilir. Public internet erişimine ihtiyaç yoksa kapalı tutulmalıdır. Prometheus yalnızca internal network üzerinden erişebilir. Firewall ve security group kuralları uygulanmalıdır. Public probe gerekiyorsa ayrı kontrollü blackbox endpoint kullanılmalıdır.

TLS

TLS telemetry ve dashboard trafiğinin ağ üzerinde korunmasına yardımcı olur. Internal network olması encryption ihtiyacını ortadan kaldırmaz. Certificate lifecycle ayrıca izlenmelidir. Mutual TLS bazı agent veya collector bağlantılarında kullanılabilir. Key management güvenli yapılmalıdır.

Authentication

Dashboard ve query endpoint'leri kullanıcı kimliği doğrulamalıdır. Shared account kullanımından kaçınılmalıdır. SSO entegrasyonu yönetimi kolaylaştırabilir. Service-to-service authentication ayrı credential kullanmalıdır. Credential rotation planlanmalıdır.

RBAC

RBAC kullanıcıların yalnızca gerekli kaynaklara erişmesini sağlar. Dashboard görüntüleme ile admin configuration yetkisi ayrılmalıdır. Team bazlı erişim uygulanabilir. Eski kullanıcı yetkileri düzenli kaldırılmalıdır. Audit logları gerektiğinde izlenmelidir.

Network Segmentation

Monitoring component'leri ayrı network segmentlerinde konumlandırılabilir. Exporter'lara yalnızca collector erişimi verilebilir. Management interface'leri kullanıcı network'ünden ayrılmalıdır. Firewall policy değişiklikleri kontrollü yapılmalıdır. Böylece compromise etkisi sınırlandırılabilir.

Least Privilege

Agent veya collector yalnızca ihtiyaç duyduğu yetkilerle çalışmalıdır. Root gerektirmeyen telemetry için yüksek privilege verilmemelidir. Cloud API credential scope sınırlandırılmalıdır. Secret'lar source code içine yazılmamalıdır. Periyodik permission review yapılmalıdır.

Dashboard Yetkilendirmesi

Her dashboard tüm kullanıcılar tarafından görülmek zorunda değildir. Production infrastructure detayları rol bazlı erişim gerektirebilir. Edit ve view izinleri ayrılmalıdır. Public dashboard paylaşımı dikkatli değerlendirilmelidir. Link içinde token veya hassas parametre taşınmamalıdır.

Telemetry İçinde Hassas Veri Riski

Telemetry sistemleri büyük miktarda veri topladığı için hassas bilgilerin yanlışlıkla metrics, logs veya traces içine girmesi ciddi risk oluşturur. Password, API key, access token, kişisel veri ve URL query parameter içerikleri filtrelenmelidir. Header redaction uygulama veya Collector katmanında yapılabilir. Metrics label'larında kullanıcıya özel değerler kullanılmamalıdır. Veri minimizasyonu monitoring tasarımının başından itibaren uygulanmalıdır.

Loglara Password Yazılması

Password hiçbir log seviyesinde kaydedilmemelidir. Debug mode bile production secret'larını göstermemelidir. Structured logger redaction desteği kullanılabilir. Eski loglarda secret varsa rotation gerekebilir. Log erişimleri ayrıca sınırlandırılmalıdır.

API Key

API key request header veya query içinde taşınıyorsa telemetry'ye düşme riski vardır. Collector filtering uygulanmalıdır. Trace attribute allowlist yaklaşımı faydalı olabilir. Secret manager dışında saklanmamalıdır. Sızıntı durumunda key hızlıca rotate edilmelidir.

Access Token

Access token kullanıcı veya service identity'sini temsil edebilir. Loglara ve trace attribute'larına yazılmamalıdır. HTTP instrumentation sensitive header'ları otomatik filtrelemelidir. Debug dump mekanizmaları kontrol edilmelidir. Token exposure incident sürecine tabi tutulmalıdır.

PII

Kişisel veri telemetry içinde gereksiz yere bulunmamalıdır. User ID yerine aggregate metric kullanılabilir. Troubleshooting için gerekli kullanıcı bağlamı özel güvenlik kurallarıyla yönetilmelidir. Retention ve erişim policy daha sıkı olabilir. Veri sınıflandırması ekipler tarafından bilinmelidir.

URL Query Parameters

URL query string token, email veya başka hassas değerler taşıyabilir. Raw URL'yi metric label yapmak hem cardinality hem güvenlik problemidir. Route template kullanılmalıdır. Logging layer query parametrelerini redact edebilir. Allowlist yaklaşımı daha güvenli olabilir.

Header Redaction

Authorization, Cookie ve benzeri header'lar telemetry'den çıkarılmalıdır. Instrumentation kütüphanesi default davranışı kontrol edilmelidir. Collector processor ek güvenlik katmanı sağlayabilir. Redaction sonrası application troubleshooting için gerekli non-sensitive header'lar tutulabilir. Policy otomatik test edilebilir.

OpenTelemetry Collector'da Filtering

Collector processor kullanarak belirli attribute veya log alanları filtrelenebilir. Sensitive field allowlist veya denylist uygulanabilir. Configuration version control altında tutulmalıdır. Filtering failure telemetry pipeline health içinde izlenmelidir. Uygulama tarafında veri üretmemek yine en güvenli yaklaşımdır.

On-Call Yönetimi

On-call yönetimi alarm sisteminin insan tarafıdır. Rotation, primary, secondary, escalation ve handover süreçleri açık biçimde tanımlanmalıdır. Follow-the-sun modeli farklı timezone'lardaki ekiplerde gece yükünü azaltabilir. On-call yükünün kendisi de ölçülmelidir. Çok sayıda gece page teknik monitoring probleminin organizasyon sağlığına yansımasıdır.

On-Call Rotation

Rotation sorumluluğun ekip üyeleri arasında adil paylaşılmasını sağlar. Takvim önceden görünür olmalıdır. İzin ve değişiklik süreçleri net tanımlanmalıdır. Tek kişiye sürekli yük bindirilmemelidir. Rotation service ownership ile uyumlu olmalıdır.

Primary

Primary ilk notification alan kişidir. Kritik incident'ı acknowledge eder ve triage başlatır. Gerekirse secondary'yi devreye alır. Primary'nin gerekli erişimleri hazır olmalıdır. Runbook ve dashboard izinleri rotation öncesi doğrulanmalıdır.

Secondary

Secondary primary ulaşılamadığında veya ek yardım gerektiğinde devreye girer. Escalation süresi önceden tanımlanmalıdır. Büyük incident'larda görev paylaşımı yapabilir. Secondary de gerekli sistem erişimlerine sahip olmalıdır. Rotation değişimlerinde otomatik güncellenmelidir.

Escalation Policy

Escalation policy alarm acknowledge edilmezse veya incident büyürse sonraki adımı tanımlar. Teknik lider veya ilgili dependency ekibi devreye girebilir. Süreler severity'ye göre değişebilir. Otomatik escalation yanlış routing riskine karşı test edilmelidir. Politika ekip değişiklikleriyle güncellenmelidir.

Handover

Handover vardiya veya rotation değişiminde aktif incident ve risklerin aktarılmasıdır. Açık alarm, maintenance veya bilinen degradation paylaşılmalıdır. Yazılı kısa özet faydalıdır. Yeni primary kritik bağlamı kaybetmemelidir. Uzun incident'larda düzenli handover süreci gerekir.

Follow-the-Sun Model

Global ekiplerde on-call sorumluluğu çalışma saatlerine göre region'lar arasında devredilebilir. Gece page yükünü azaltabilir. Handover kalitesi kritik hale gelir. Service knowledge farklı ekiplerde yeterli olmalıdır. Global incident için ortak escalation mekanizması gerekir.

On-Call Yükünü Ölçmek

Page sayısı, gece alarmı, MTTA ve notification-to-action rate on-call yükünü gösterir. Kişi başına dağılım incelenebilir. Çok sayıda false positive monitoring kalitesinin düştüğünü gösterir. Alert review önceliği bu verilere göre belirlenebilir. İnsan sürdürülebilirliği reliability sisteminin parçasıdır.

Incident Severity Modeli

Incident severity teknik hatanın büyüklüğünü kullanıcı ve business etkisi üzerinden sınıflandırır. SEV-1 en geniş ve kritik etkiyi, daha düşük seviyeler sınırlı etkileri temsil edebilir. Kullanıcı sayısı, veri kaybı, revenue etkisi ve workaround durumu dikkate alınabilir. Tanımlar olay sırasında tartışılmayacak kadar açık olmalıdır. Severity modeli communication ve escalation sürecini standartlaştırır.

SEV-1

SEV-1 geniş kullanıcı kitlesini etkileyen veya kritik business fonksiyonunu durduran incident için kullanılabilir. Hızlı escalation gerekir. Incident commander veya ayrı koordinasyon rolü devreye girebilir. Düzenli iletişim yapılmalıdır. Olay sonrası postmortem genellikle zorunlu tutulur.

SEV-2

SEV-2 önemli fakat daha sınırlı kullanıcı veya fonksiyon etkisini temsil edebilir. Servis kısmen çalışıyor olabilir. Workaround bulunabilir. Teknik ekip hızlı müdahale eder ancak organizasyon çapında kriz yönetimi gerekmeyebilir. Tanım kurum ihtiyacına göre netleştirilmelidir.

SEV-3

SEV-3 düşük etkili veya sınırlı degradation için kullanılabilir. Mesai içinde çözüm yeterli olabilir. Kullanıcı sayısı az veya fonksiyon ikincil olabilir. Ticket süreciyle yönetilebilir. Yine de repeated SEV-3 olaylar sistematik problem gösterebilir.

Severity Belirleme

Severity metric değerinden otomatik çıkarılmamalıdır. Kullanıcı etkisi, kapsam ve recovery süresi değerlendirilmelidir. İlk severity yeni bilgi geldikçe değişebilir. Incident commander gerektiğinde seviye yükseltebilir veya düşürebilir. Karar kriterleri runbook içinde yer alabilir.

Business Impact

Business impact teknik incident'ın işletme fonksiyonlarına etkisini gösterir. Kritik ödeme veya login akışı yüksek öneme sahip olabilir. Aynı süreli kesinti farklı servislerde farklı etki yaratır. Domain-specific metrics değerlendirmeyi güçlendirir. Kesin veri yoksa varsayım açık belirtilmelidir.

Kullanıcı Sayısı

Etkilenen kullanıcı sayısı incident kapsamını belirlemeye yardımcı olur. Yüzde ve mutlak sayı birlikte kullanılabilir. Küçük yüzde büyük trafik hacminde ciddi sayı olabilir. Bölgesel etki ayrıca gösterilmelidir. Privacy nedeniyle kullanıcı kimlikleri incident dashboard'unda gereksiz tutulmamalıdır.

Veri Kaybı

Veri kaybı riski severity kararında kritik faktördür. Kullanıcı görünür etkisi az olsa bile kalıcı veri kaybı yüksek öncelik gerektirir. RPO ve backup durumu değerlendirilmelidir. Recovery adımları güvenli ve kontrollü uygulanmalıdır. Security veya compliance ekipleri gerektiğinde devreye girebilir.

Incident Response Akışı

Incident response detect, alert, acknowledge, triage, mitigate, resolve, communicate ve postmortem aşamalarından oluşabilir. Monitoring ilk iki aşamada kritik rol oynar fakat sonraki adımlarda da gerçek zamanlı geri bildirim sağlar. Mitigation sonrası metric normalleşmesi çözümün işe yarayıp yaramadığını gösterir. İletişim kullanıcı etkisine ve severity'ye göre yürütülmelidir. Postmortem ise monitoring sistemini yeniden geliştirmek için fırsat sunar.

Detect

Detect problemin ilk kez fark edildiği aşamadır. Monitoring alarmı, synthetic check veya kullanıcı bildirimi kaynak olabilir. Hedef MTTD süresini azaltmaktır. İyi SLI ve blackbox monitoring erken detection sağlar. Olay timestamp'i kaydedilmelidir.

Alert

Detect edilen problem doğru kişiye iletilmelidir. Severity ve routing bu aşamada önemlidir. Notification mesajı yeterli bağlam sağlamalıdır. Duplicate alarmlar grouping ile azaltılmalıdır. Delivery failure ayrıca izlenmelidir.

Acknowledge

On-call kişi alarmı aldığını işaretler. MTTA burada ölçülür. Acknowledge olmayan kritik incident escalation tetikleyebilir. Ownership açık olduğunda bu süre azalır. Acknowledge çözüm anlamına gelmez.

Triage

Triage incident kapsamını ve ilk olası nedeni anlamaya çalışır. User impact, recent change ve dependency health kontrol edilir. Dashboard, logs ve traces kullanılır. Severity gerektiğinde güncellenir. İlk hedef root cause'u tam çözmek değil doğru mitigation yönünü bulmaktır.

Mitigate

Mitigation kullanıcı etkisini hızlı azaltmayı hedefler. Rollback, failover veya capacity artırma kullanılabilir. Kök neden daha sonra ayrıntılı çözülebilir. Riskli müdahalelerden kaçınılmalıdır. Monitoring mitigation sonucunu hemen göstermelidir.

Resolve

Resolve sistemin normal çalışma hedeflerine döndüğünü gösterir. Alert state resolved olabilir ancak kullanıcı doğrulaması da yapılmalıdır. Backlog veya delayed job etkileri devam edebilir. Recovery tamamlanmadan incident kapatılmamalıdır. Final timeline kaydedilmelidir.

Communicate

İletişim ekip içi ve kullanıcıya yönelik olabilir. Severity ve business impact'e göre sıklık belirlenir. Bilinmeyen nedenler kesinmiş gibi yazılmamalıdır. Düzenli ve kısa durum güncellemeleri güven sağlar. Teknik ayrıntı hedef kitleye göre uyarlanmalıdır.

Postmortem

Postmortem incident sonrası nedenleri ve sistem iyileştirmelerini inceler. Suçlayıcı olmayan teknik öğrenme yaklaşımı tercih edilmelidir. Alarm erken mi, geç mi veya gereksiz mi çalıştı değerlendirilir. Runbook ve monitoring eksikleri güncellenir. Her incident otomatik olarak yeni alarm üretmek zorunda değildir.

Monitoring ve Incident Response Metrikleri

Monitoring sisteminin başarısı yalnızca kaç metric toplandığıyla ölçülmemelidir. MTTD, MTTA, MTTR, alert volume, false positive rate ve notification-to-action rate operasyon kalitesini daha iyi gösterir. Service başına incident sayısı tekrar eden problemleri ortaya çıkarabilir. Bu metrikler ekip performansını cezalandırmak için değil sistem iyileştirmek için kullanılmalıdır. Trendler alert review ve reliability yatırımlarına yön verebilir.

MTTD: Mean Time to Detect

MTTD problem başladıktan ne kadar sonra fark edildiğini ölçer. Synthetic ve SLO alarmı süreyi azaltabilir. Kullanıcı bildiriminden sonra detection yapılıyorsa monitoring açığı vardır. Timestamp kaynakları doğru olmalıdır. Postmortem içinde ölçülebilir.

MTTA: Mean Time to Acknowledge

MTTA alarmın firing olmasından bir kişinin sorumluluk almasına kadar geçen süredir. Routing ve on-call süreçlerinin kalitesini gösterir. Yanlış owner süreyi uzatır. Çok fazla false positive acknowledge davranışını bozar. Escalation policy iyileştirme sağlayabilir.

MTTR: Mean Time to Restore/Resolve

MTTR hizmetin normale dönmesine kadar geçen süreyi ölçer. Restore ve resolve tanımı organizasyon içinde net olmalıdır. Runbook ve otomasyon bu süreyi azaltabilir. Root cause analizi daha uzun sürebilir. Kullanıcı etkisinin sona ermesi önemli referanstır.

Alert Volume

Alert volume belirli dönemde firing olan alarm sayısını gösterir. Ham sayı tek başına kalite ölçmez. Service ve severity bazında kırılım yapılmalıdır. Gece page sayısı ayrıca izlenebilir. Ani artış yeni yanlış rule'a işaret edebilir.

False Positive Rate

False positive rate gerçek incident veya aksiyon üretmeyen alarmların oranını gösterebilir. Tanım ekip içinde ortak olmalıdır. Yüksek oran on-call güvenini azaltır. En kötü rule'lar öncelikli iyileştirilebilir. Alert review sonucuyla ilişkilendirilebilir.

Notification-to-Action Rate

Bu oran notification'ların ne kadarının gerçek insan aksiyonuna dönüştüğünü gösterir. Düşük değer non-actionable alarm problemine işaret edebilir. Kanal bazında incelenebilir. Page için oran yüksek olmalıdır. Dashboard bilgilendirmelerinde bu metrik kullanılmayabilir.

Incidents per Service

Service başına incident sayısı problem yoğunluğunu gösterir. Aynı serviste tekrarlanan olaylar teknik borç işareti olabilir. Severity ve user impact ile ağırlıklandırılabilir. Release sıklığıyla karşılaştırma yapılabilir. Reliability yatırım önceliği belirlemeye yardımcı olur.

Postmortem ile Monitoring Nasıl İyileştirilir?

Her incident monitoring sisteminin gerçek koşullarda yapılmış testidir. Alarm olayı yakaladı mı, doğru zamanda mı çalıştı ve doğru kişiye mi gitti soruları incelenmelidir. Runbook'un işe yarayıp yaramadığı ve eksik telemetry olup olmadığı değerlendirilir. Yeni alarm eklemek ilk refleks olmamalıdır. Bazen mevcut alarmı kaldırmak, grouping eklemek veya dashboard'u iyileştirmek daha doğru sonuç verir.

Alarm Olayı Yakalamış mıydı?

Incident kullanıcı tarafından bildirildiyse mevcut alarmların neden çalışmadığı araştırılmalıdır. Metric eksik olabilir. Threshold yanlış olabilir. User-facing SLI tanımı yetersiz olabilir. Gerekirse yeni telemetry eklenmelidir.

Çok Erken mi Çalıştı?

Alarm gerçek kullanıcı etkisinden çok önce sürekli page üretmiş olabilir. Capacity warning page kanalına yanlış yönlendirilmiş olabilir. Pending period eklenebilir. Severity düşürülebilir. Amaç erken bilgi ile gereksiz aciliyet arasındaki dengeyi bulmaktır.

Çok Geç mi Çalıştı?

Detection geciktiyse threshold veya duration fazla yüksek olabilir. Metric scrape interval de etkileyebilir. SLO burn rate daha hızlı sinyal sağlayabilir. Blackbox probe kapsamı genişletilebilir. MTTD improvement action tanımlanmalıdır.

Gereksiz Alarm Var mıydı?

Aynı incident için yüzlerce alarm çıktıysa grouping ve inhibition gözden geçirilmelidir. Root cause alarmı belirlenebilir. Duplicate rule'lar kaldırılabilir. Page ve dashboard ayrımı yeniden yapılabilir. Notification-to-action rate veri sağlar.

Runbook Yeterli miydi?

On-call kişi gerekli adımları bulamadıysa runbook güncellenmelidir. Dashboard veya log linki eksik olabilir. Yanlış recovery komutu kaldırılmalıdır. Yeni güvenli mitigation adımları eklenebilir. Runbook incident deneyiminden beslenmelidir.

Eksik Metric Var mıydı?

Root cause'u bulmak için production'a SSH ile girip manuel veri aramak gerekiyorsa metric eksik olabilir. Ancak her manuel gözlem yeni metric gerektirmez. Tekrarlanma ihtimali ve operasyon değeri değerlendirilmelidir. High-cardinality riskine dikkat edilmelidir. Gereken telemetry kontrollü eklenmelidir.

Yeni Alarm Gerçekten Gerekli mi?

Her incident sonrası yeni alert eklemek alarm sayısını hızla artırır. Mevcut user-facing alarm incident'ı zaten yakaladıysa yeni cause alert page gerekmeyebilir. Dashboard paneli veya runbook adımı yeterli olabilir. Yeni alarmın aksiyonu net olmalıdır. Owner ve test senaryosu olmadan production'a eklenmemelidir.

Capacity Planning ve Forecasting

Capacity planning monitoring verisini gelecekteki kaynak ihtiyacını tahmin etmek için kullanır. CPU, memory, storage, network ve traffic trendleri birlikte incelenebilir. Mevcut kullanım kadar büyüme hızı ve peak davranışı önemlidir. Time-to-capacity hesapları procurement veya cloud scaling kararlarına zaman kazandırır. Forecast yalnızca geçmiş trend değil business büyüme planlarıyla da desteklenmelidir.

CPU Trend

CPU trend peak ve ortalama kullanımın zaman içindeki değişimini gösterir. Trafik artışıyla korele edilebilir. Sürekli yükseliş yeni kapasite ihtiyacına işaret edebilir. Autoscaling varsa scale event'leri de incelenmelidir. Tek kısa dönem verisiyle uzun tahmin yapılmamalıdır.

Memory Trend

Memory trend workload büyümesi veya leak tespitinde faydalıdır. Available memory ve process memory birlikte incelenebilir. Deployment sonrası kırılma noktaları dikkat çekicidir. Capacity planı swap veya OOM yaşanmadan yapılmalıdır. Cache davranışı ayrıca dikkate alınmalıdır.

Storage Growth

Storage growth en öngörülebilir capacity sinyallerinden biridir. Günlük veri artışı ve retention policy hesaplamaya dahil edilir. Backup storage da aynı planın parçasıdır. Time-to-full alarmı operasyon süresi kazandırır. Büyük data migration gibi planlı değişiklikler tahmine eklenmelidir.

Network Growth

Network traffic trendi bandwidth kapasitesinin ne zaman yetersiz kalacağını gösterebilir. Peak saatler özellikle önemlidir. Packet loss ve latency capacity probleminden önce artabilir. Region bazlı trend ayrımı yapılabilir. Dış trafik maliyeti de planlamaya dahil edilebilir.

Traffic Growth

Application request rate business büyümesini teknik capacity ile ilişkilendirir. CPU veya database load başına request oranı ölçülebilir. Böylece aynı hardware ile ne kadar ek trafik taşınabileceği tahmin edilir. Büyük kampanya veya seasonal peak ayrıca planlanmalıdır. Forecast modelinin belirsizliği açık tutulmalıdır.

Time-to-Capacity

Time-to-capacity mevcut büyüme hızına göre limitin ne zaman aşılacağını tahmin eder. Disk, connection pool veya traffic için uygulanabilir. Değer operasyon lead time ile karşılaştırılmalıdır. Yeni hardware tedariki haftalar sürüyorsa alarm erken gelmelidir. Cloud scaling daha kısa lead time sunabilir ancak maliyet etkisi vardır.

Gelecek Kapasite İhtiyacını Tahmin Etmek

Historical metric tek başına geleceği kesin göstermez. Business roadmap, yeni müşteri, data retention ve architecture change planları dikkate alınmalıdır. Best-case ve worst-case senaryolar oluşturulabilir. Kapasite headroom politikası service tier'a göre belirlenebilir. Monitoring verisi bu kararların sürekli güncellenmesini sağlar.

Open Source Sunucu Monitoring Araçları

Açık kaynak monitoring ekosisteminde farklı ihtiyaçlara odaklanan birçok araç bulunur. Prometheus metric toplama ve sorgulamada, Grafana görselleştirmede, Alertmanager notification yönetiminde güçlü roller üstlenir. Node Exporter Linux host telemetry'si, Blackbox Exporter dış probe ve OpenTelemetry daha geniş telemetry pipeline ihtiyaçları için kullanılabilir. Zabbix, Nagios, Icinga ve Uptime Kuma farklı operasyon modelleri ve kullanım kolaylıkları sunar. Araç seçerken yalnızca özellik listesine değil ekip deneyimi, target türü, ölçek, bakım maliyeti ve otomasyon ihtiyacına bakılmalıdır.

Prometheus

Prometheus label tabanlı time-series monitoring ve PromQL sorgulama modeli sunar. Dynamic service discovery ile cloud-native yapılarda güçlüdür. Alert rule desteği bulunur. Long-term retention için ek architecture gerekebilir. Ekip PromQL ve metric modelini öğrenmelidir.

Grafana

Grafana farklı data source'lardan dashboard oluşturmayı sağlar. Prometheus ile sık birlikte kullanılır. Alerting yetenekleri de bulunabilir ancak mimari görev ayrımı baştan netleştirilmelidir. Provisioning ile dashboard-as-code uygulanabilir. Görsel kaliteden önce operasyon sorularını cevaplamak hedeflenmelidir.

Alertmanager

Alertmanager Prometheus alert notification akışını yönetir. Grouping, deduplication, routing, silencing ve inhibition temel yeteneklerdir. HA cluster kurulabilir. Rule evaluation Prometheus tarafında kalır. Notification pipeline metamonitoring ile izlenmelidir.

Node Exporter

Node Exporter Linux host metriklerini Prometheus formatında sunar. CPU, memory, filesystem ve network görünürlüğü sağlar. Agent yerine exporter yaklaşımıyla çalışır. Endpoint network içinde korunmalıdır. Application health için tek başına yeterli değildir.

Blackbox Exporter

Blackbox Exporter HTTP, TCP, ICMP ve benzeri dış probe ihtiyaçları için kullanılabilir. User-facing availability kontrolünü güçlendirir. TLS certificate kontrolleri yapılabilir. Probe sonuçları Prometheus tarafından scrape edilir. Multi-region dağıtım daha geniş erişim görünürlüğü sağlar.

OpenTelemetry

OpenTelemetry application metrics, logs ve traces için ortak instrumentation ve taşıma yaklaşımı sağlar. Collector pipeline merkezi processing yapabilir. Vendor-neutral telemetry hedefler. Cardinality ve sensitive data kuralları yine ekip sorumluluğundadır. Prometheus ile birlikte veya farklı backend'lerle kullanılabilir.

Zabbix

Zabbix geleneksel sunucu ve ağ cihazı monitoring senaryolarında bütünleşik yaklaşım sunabilir. Agent ve agentless kontroller kullanılabilir. Trigger, inventory ve notification özellikleri aynı sistem içinde yönetilebilir. Büyük ölçekte template ve configuration yönetimi önem kazanır. Ekip mevcut altyapı ve operasyon yaklaşımına göre değerlendirme yapmalıdır.

Nagios

Nagios plugin tabanlı service check yaklaşımıyla uzun süredir kullanılan monitoring seçeneklerinden biridir. Host ve service availability kontrollerinde basit model sunar. Modern dynamic ortamlar için configuration operasyonu ek çalışma gerektirebilir. Plugin ekosistemi esneklik sağlar. Yeni kurulumlarda mevcut ekip bilgisi ve otomasyon ihtiyacı dikkate alınmalıdır.

Icinga

Icinga host ve service monitoring ihtiyaçlarında kullanılabilen açık kaynak seçeneklerden biridir. Configuration ve distributed monitoring yetenekleri değerlendirilebilir. Plugin tabanlı check yaklaşımı bulunur. Dynamic infrastructure kullanımında entegrasyon ihtiyacı incelenmelidir. Araç seçimi toplam operasyon maliyeti üzerinden yapılmalıdır.

Uptime Kuma

Uptime Kuma basit uptime ve endpoint monitoring ihtiyaçlarında kullanışlı olabilir. HTTP ve benzeri servis kontrolleri hızlı biçimde kurulabilir. Tam infrastructure metrics ve observability platformunun yerine geçmez. Küçük ekiplerin dış erişim kontrollerinde pratik rol oynayabilir. Production kritik sistemlerde notification redundancy ayrıca planlanmalıdır.

Prometheus + Grafana mı Zabbix mi?

Prometheus Grafana Zabbix sunucu izleme araçları karşılaştırması yapılırken tek bir evrensel kazanan aramak yerine ortamın yapısını değerlendirmek gerekir. Cloud-native ve dinamik service discovery ihtiyacı yüksek yapılarda Prometheus modeli doğal gelebilir. Geleneksel sunucu, ağ cihazı ve merkezi template yaklaşımı gereken ortamlarda Zabbix daha bütünleşik bir deneyim sunabilir. Ekiplerin öğrenme eğrisi ve mevcut operasyon kültürü seçimi ciddi biçimde etkiler. Araçtan daha önemli olan doğru metric, ownership, runbook ve alarm politikasının kurulmasıdır.

Cloud-Native Ortam

Dynamic workload ve container ortamlarında target listesi sürekli değişebilir. Prometheus service discovery modeli bu yapıya iyi uyum sağlar. Label tabanlı sorgular servis ve pod seviyesinde esneklik sunar. Grafana dashboard ve Alertmanager notification katmanı eklenebilir. Cardinality yönetimi özellikle önemlidir.

Geleneksel Sunucu Ortamı

Sabit host listesi, SNMP cihazları ve klasik server monitoring ihtiyacında bütünleşik platform yaklaşımı tercih edilebilir. Template tabanlı yönetim operasyonu kolaylaştırabilir. Agent rollout planı yapılmalıdır. Legacy sistemlerle entegrasyon önemli seçim kriteridir. Mevcut ekip deneyimi toplam maliyeti belirler.

Agent vs Exporter

Agent merkezi sisteme veri gönderme ve aktif check yetenekleri sunabilir. Exporter çoğunlukla metric endpoint expose eder ve collector pull yapar. Network topolojisi seçimi etkiler. Upgrade ve configuration management iki modelde de düşünülmelidir. Güvenlik açısından minimum gerekli erişim verilmelidir.

Service Discovery

Dinamik altyapılarda manuel host listesi hızla sürdürülemez hale gelir. Prometheus service discovery bu senaryoda güçlüdür. Geleneksel sistemlerde otomatik discovery farklı yöntemlerle sağlanabilir. Metadata kalitesi alarm routing'i de etkiler. Inventory ve ownership verisi güncel tutulmalıdır.

Dashboard

Grafana geniş görselleştirme esnekliği sunar. Zabbix kendi dashboard ve visualization seçeneklerini bütünleşik sağlayabilir. Tasarım aracı ne olursa olsun kullanıcı etkisi en üstte olmalıdır. Dashboard-as-code ihtiyacı değerlendirilmelidir. Ekip kullanım alışkanlığı önemlidir.

Alerting

Prometheus ve Alertmanager rule evaluation ile notification yönetimini ayrı bileşenlere böler. Zabbix daha bütünleşik trigger ve notification modeli sunabilir. Grouping ve dependency davranışı karşılaştırılmalıdır. Alarm test ve versioning süreçleri değerlendirilmelidir. Araç hangi olursa olsun actionability temel kriterdir.

Operasyon Maliyeti

Birden fazla component esneklik sağlarken bakım işini artırabilir. Tek platform daha basit olabilir ancak customization sınırları olabilir. Storage, HA, upgrade ve backup maliyeti hesaba katılmalıdır. Lisans maliyeti sıfır olsa bile mühendislik zamanı gerçek maliyettir. Ekip kapasitesi seçimde önemli faktördür.

Öğrenme Eğrisi

PromQL, label model ve distributed component'ler öğrenme gerektirir. Template tabanlı geleneksel sistemlerin de kendi configuration modeli vardır. Ekip hangi yaklaşımı daha hızlı yönetebilecekse toplam risk azalır. Eğitim ve dokümantasyon planlanmalıdır. Araç seçimi yalnızca demo ekranına göre yapılmamalıdır.

Production-Ready Örnek Monitoring Stack

Production-ready stack tek bir araçtan oluşmaz. Linux Server üzerinde Node Exporter host metriklerini üretir, Prometheus bunları toplar ve Alertmanager alarm notification akışını yönetir. Grafana dashboard sunarken Blackbox Exporter kullanıcıya yakın dış kontroller sağlar. OpenTelemetry Collector application telemetry'sini taşıyabilir, ayrı log ve trace backend'leri araştırma katmanını tamamlar. On-call ve incident management sistemi notification sonrasındaki insan sürecini yönetir.

Linux Server

Linux server host telemetry'nin temel kaynağıdır. CPU, memory, disk ve network metrikleri toplanmalıdır. Critical service process'leri ayrıca izlenmelidir. Exporter erişimi internal network ile sınırlandırılmalıdır. Time sync ve system uptime metrikleri unutulmamalıdır.

Node Exporter

Node Exporter host metriklerini Prometheus formatında sunar. Gereken collector'lar etkinleştirilebilir. Textfile collector backup veya local job metric'leri için kullanılabilir. Endpoint internete açılmamalıdır. Exporter scrape failure ayrıca alarm sinyalidir.

Prometheus

Prometheus metric collection, query ve alert rule evaluation yapar. Service discovery target yönetimini kolaylaştırır. İki replica HA sağlayabilir. Local retention capacity planlanmalıdır. Long-term storage ihtiyacı ayrı değerlendirilmelidir.

Alertmanager

Alertmanager routing, grouping, deduplication, silencing ve inhibition görevlerini üstlenir. Team ownership label'larına göre route yapılabilir. Critical ve warning farklı notification kanallarına ayrılabilir. HA cluster kullanılabilir. Notification failure external heartbeat ile doğrulanmalıdır.

Grafana

Grafana servis ve altyapı dashboard'larını sunar. En üstte Golden Signals ve SLO durumu gösterilebilir. Deployment annotation eklenebilir. Provisioning ile dashboard config Git'te tutulabilir. User access RBAC ile sınırlandırılmalıdır.

Blackbox Exporter

Blackbox Exporter dışarıdan HTTP, TCP, DNS veya TLS kontrolleri yapabilir. Internal host health ile user-facing availability arasındaki boşluğu kapatır. Multi-location deployment değerlidir. Certificate expiration izlenebilir. Probe result SLI hesabına girdi sağlayabilir.

OpenTelemetry Collector

Collector application metrics, logs ve traces pipeline'ını yönetebilir. Agent veya gateway mode kullanılabilir. Filtering ile hassas veri çıkarılabilir. Export queue ve failure metrikleri izlenmelidir. Configuration Git üzerinden versionlanmalıdır.

Log Backend

Log backend structured application ve system loglarını saklar. Retention ve access control uygulanmalıdır. Trace ID üzerinden correlation yapılabilir. High volume servisler için ingestion kapasitesi planlanmalıdır. Sensitive data redaction source veya Collector katmanında yapılmalıdır.

Trace Backend

Trace backend distributed request yolculuklarını saklar. Sampling maliyeti kontrol eder. Service map ve latency analysis için kullanılabilir. Metric exemplar entegrasyonu investigation süresini azaltır. Retention kullanım amacına göre seçilmelidir.

On-Call / Incident Management

On-call sistemi doğru kişiyi belirler ve escalation uygular. Incident management acknowledgement, timeline ve communication süreçlerini yönetir. Monitoring alert'leri service ownership ile eşleştirilmelidir. MTTA ve MTTR ölçülebilir. Postmortem çıktıları monitoring backlog'una dönüştürülmelidir.

Örnek Monitoring Veri Akışı

Pratik bir production akışında metric sunucuda üretilir, collector tarafından alınır, dashboard üzerinde görselleştirilir ve alert rule tarafından değerlendirilir. Koşul belirlenen süreyi aşarsa firing state'e geçer. Alertmanager grouping ve deduplication yaptıktan sonra doğru on-call ekibine yönlendirir. Mühendis runbook kullanarak müdahale eder. Incident sonrasında alarmın kalitesi ve monitoring eksikleri tekrar değerlendirilir.

1. Node Exporter Metric Üretir

Node Exporter Linux host metriklerini /metrics endpoint'inde sunar. CPU, memory, filesystem ve network verileri burada bulunur. Metric label standardı korunmalıdır. Endpoint internal erişime açık olmalıdır. Exporter health ayrıca kontrol edilebilir.

2. Prometheus Metric'i Scrape Eder

Prometheus belirlenen interval ile Node Exporter'a istek gönderir. Scrape success ve duration kaydedilir. Service discovery target listesini güncelleyebilir. Veri local TSDB'ye yazılır. Scrape failure metamonitoring kapsamında izlenir.

3. Grafana Dashboard'da Görselleştirir

Grafana Prometheus data source üzerinden query çalıştırır. Host ve service dashboard'ları gösterilir. Variable ile instance seçilebilir. Deployment annotation eklenebilir. Dashboard troubleshooting için kullanılır.

4. Alert Rule Koşulu Değerlendirilir

Prometheus belirli aralıklarla alert rule query'sini çalıştırır. Threshold, SLO veya başka koşul değerlendirilebilir. Label ve annotation alarm metadata'sını oluşturur. Rule error izlenmelidir. Unit test rule doğruluğunu artırır.

5. Alarm Pending Durumuna Geçer

Koşul ilk kez sağlandığında alarm pending olabilir. for süresi kısa spike'ı filtreler. Bu süre boyunca koşul devam etmelidir. Metric normale dönerse firing olmaz. Uygun duration servis davranışına göre seçilir.

6. Koşul Devam Ederse Firing Olur

Pending süresi tamamlandığında alarm firing state'e geçer. Bu nokta insan notification sürecini başlatabilir. Severity ve ownership label'ları doğru olmalıdır. Firing olmak kesin root cause bulunduğu anlamına gelmez. Sadece alarm koşulunun doğrulandığını gösterir.

7. Alertmanager Grouping/Deduplication Yapar

Alertmanager aynı incident'a ait alarmları gruplayabilir. HA kaynaklı duplicate alarmları azaltabilir. Inhibition root cause altında downstream gürültüyü bastırabilir. Silence maintenance döneminde uygulanabilir. Route öncesi alarm bağlamı düzenlenir.

8. Doğru On-Call Ekibine Route Eder

Service, team ve severity label'ları routing kararını belirler. Critical production alarmı on-call sistemine gönderilebilir. Warning ticket kanalına gidebilir. Acknowledge edilmezse escalation uygulanabilir. Yanlış route MTTA'yı artırır.

9. Mühendis Runbook ile Müdahale Eder

On-call kişi alarmı acknowledge eder. Runbook ilk kontrol, diagnosis ve mitigation adımlarını sunar. Dashboard, logs ve traces birlikte kullanılır. Recovery sonrası kullanıcı SLI'ları doğrulanır. Incident timeline kaydedilir.

10. Incident Sonrası Alarm Gözden Geçirilir

Alarm erken mi, geç mi veya gereksiz mi çalıştı değerlendirilir. False positive veya duplicate notification varsa düzeltme yapılır. Runbook güncellenir. Eksik metric yalnızca gerçekten gerekliyse eklenir. Böylece monitoring her incident ile gelişir.

Minimum Production Sunucu Alarm Seti

Yeni bir monitoring ortamında yüzlerce alarm ile başlamak gerekmez. Önce kullanıcı kesintisi, kritik capacity, memory pressure, disk I/O, application error ve latency gibi temel riskler güvenilir biçimde izlenmelidir. TLS, backup ve monitoring sisteminin kendi sağlığı da unutulmamalıdır. Her alarmın owner ve runbook bilgisi bulunmalıdır. Alarm seti gerçek incident deneyimleriyle zaman içinde geliştirilmelidir.

Sunucu Ulaşılamıyor

Host network üzerinden ulaşılamıyorsa temel infrastructure problemi olabilir. Birden fazla probe doğrulaması false positive'i azaltır. Planned maintenance silence kontrol edilmelidir. Host kritik service taşıyorsa severity yükselir. Downstream process alarmı inhibition ile bastırılabilir.

Kullanıcıya Açık Servis Ulaşılamıyor

User-facing endpoint blackbox check ile doğrulanmalıdır. HTTP status, content ve TLS birlikte kontrol edilebilir. Birden fazla location failure global impact ihtimalini güçlendirir. Critical service için doğrudan page uygun olabilir. Dashboard dependency health göstermelidir.

Kritik Disk Kapasitesi

Remaining capacity ve time-to-full kullanılmalıdır. Sabit yüzde tek başına yeterli değildir. Growth rate hızlıysa erken warning üretilebilir. Kritik mount point owner'a yönlendirilmelidir. Runbook cleanup veya capacity extension adımlarını içerebilir.

OOM / Memory Pressure

OOM event kritik process kaybına yol açabilir. Available memory, swap ve pressure metrikleri erken sinyal sağlar. Tek RAM yüzde alarmından kaçınılmalıdır. Application restart ve user error birlikte incelenmelidir. Leak şüphesinde trend analizi yapılmalıdır.

Kritik Disk I/O Problemi

Yüksek disk latency ve queue application performance'ı ciddi etkileyebilir. Utilization tek başına yeterli değildir. I/O error varsa severity artabilir. Kullanıcı latency ile correlation yapılmalıdır. Storage owner'a doğru route edilmelidir.

Yüksek User-Facing Error Rate

Error rate kullanıcı etkisine yakın güçlü alarm sinyalidir. SLO burn rate ile birleştirilebilir. Minimum traffic volume koşulu gerekebilir. Dependency failure root cause olabilir. Critical threshold hızlı page üretebilir.

Yüksek User-Facing Latency

p95 veya p99 latency SLO hedefini aştığında alarm üretilebilir. Average latency kullanılmamalıdır. Traffic volume ve error rate birlikte incelenmelidir. Trace root cause araştırmasını hızlandırır. Deployment annotation ilk kontrol noktası olabilir.

TLS Certificate Süresi

Certificate expiration önceden tahmin edilebilir. 30, 14 ve 7 günlük kademeli alarm kullanılabilir. Renewal job failure ayrıca izlenmelidir. Hostname ve chain doğrulanmalıdır. Son günlere kalmadan ownership üzerinden aksiyon alınmalıdır.

Backup Başarısız

Backup job success yanında last successful backup age izlenmelidir. Tek failure retry varsa warning olabilir. RPO penceresi aşılıyorsa severity yükselir. Backup size ve restore test sonucu kontrol edilmelidir. Alarm veri seti owner'ına gitmelidir.

Monitoring Sistemi Çalışmıyor

Prometheus, Alertmanager veya notification provider failure monitoring körlüğü oluşturur. External heartbeat kullanılmalıdır. Dead man's switch bağımsız sistemde çalışmalıdır. HA component'ler bulunabilir. Test alarmı zinciri periyodik olarak doğrular.

Production'a Çıkmadan Önce Monitoring Kontrol Listesi

Production'a çıkıştan önce monitoring sonradan eklenecek bir detay olarak görülmemelidir. Service ownership, SLI, infrastructure metrics, blackbox uptime, application telemetry, dashboard ve alarm testleri önceden tamamlanmalıdır. Notification routing ve on-call rotation gerçek kişilerle doğrulanmalıdır. Monitoring sisteminin kendi health ve retention planı da production readiness kapsamına alınmalıdır. Yapılan deployment kadar gözlem ve recovery yeteneğinin de hazır olması gerekir.

Kritik Servislerin Owner'ı Belli mi?

Her critical service için sorumlu ekip tanımlanmalıdır. Alarm routing bu owner'a gitmelidir. Repository ve runbook bağlantısı bulunmalıdır. Ownership organizasyon değişiklikleriyle güncellenmelidir. Sahipsiz service production'a çıkmamalıdır.

Kullanıcı Odaklı SLI'lar Tanımlı mı?

Availability, latency veya success rate gibi SLI'lar kullanıcı deneyimine yakın seçilmelidir. Query tanımı version control altında tutulmalıdır. SLO hedefi service ihtiyacına göre belirlenmelidir. Dashboard SLI durumunu göstermelidir. Alarm mümkünse bu hedeflerle ilişkilendirilmelidir.

CPU/RAM/Disk/Network İzleniyor mu?

Temel host kaynakları production için minimum görünürlük sağlar. Yalnızca utilization değil saturation ve errors da takip edilmelidir. Memory için available, disk için latency ve network için loss gibi ek sinyaller eklenmelidir. Threshold workload'a göre ayarlanmalıdır. Host dashboard hazır olmalıdır.

Uptime Blackbox Olarak Ölçülüyor mu?

Server iç metriği kullanıcı erişimini garanti etmez. Dış HTTP veya protocol probe çalıştırılmalıdır. TLS ve DNS yolu gerektiğinde kapsanmalıdır. Multi-location kritik servisler için faydalıdır. Probe failure doğru severity ile route edilmelidir.

Application Metrics Var mı?

Request rate, error rate ve duration temel application metric'leridir. Queue veya connection pool uygulamaya göre eklenebilir. Business-critical event metric'i gerekiyorsa tanımlanmalıdır. Cardinality kuralları uygulanmalıdır. Metric naming standardı korunmalıdır.

Dashboard'lar Hazır mı?

Service ve infrastructure dashboard'ları incident öncesinde hazırlanmalıdır. User impact üstte yer almalıdır. Deployment annotation görülmelidir. Dependency health ayrı bölümde bulunmalıdır. Dashboard linkleri alarm mesajlarından erişilebilir olmalıdır.

Kritik Alarm Kuralları Test Edildi mi?

Rule syntax ve PromQL query doğrulanmalıdır. Unit test firing ve resolve davranışını kontrol etmelidir. Synthetic alarm gerçek notification zincirini test edebilir. False positive senaryosu göz önünde bulundurulmalıdır. Production'a ilk çıkıştan önce en az kritik alarmlar doğrulanmalıdır.

Her Page Alarmının Runbook'u Var mı?

Page alarmı insanı uyandırıyorsa müdahale rehberi olmalıdır. İlk kontrol ve mitigation adımları açık yazılmalıdır. Dashboard ve log linkleri eklenmelidir. Runbook güncel tutulmalıdır. Aksiyonu olmayan page yeniden sınıflandırılmalıdır.

Notification Routing Test Edildi mi?

Test alarmı doğru ekibe ulaşmalıdır. Critical ve warning farklı kanallara gidiyorsa ikisi de doğrulanmalıdır. Escalation çalışmalıdır. Yanlış route production incident'ta ciddi gecikme yaratır. Team metadata deployment öncesi kontrol edilmelidir.

Alert Grouping Kullanılıyor mu?

Benzer alarmlar tek incident altında gruplanmalıdır. Service bazlı grouping iyi başlangıç olabilir. group_wait kritik notification'ı fazla geciktirmemelidir. Repeat interval gürültü oluşturmamalıdır. Gerçek test senaryosu uygulanmalıdır.

Maintenance Silence Süreci Var mı?

Planlı bakımda beklenen alarmlar kontrollü silence edilmelidir. Silence owner ve expiration içermelidir. Süresiz silence yasaklanabilir. Bakım sonrası health doğrulanmalıdır. Maintenance değişiklikleri incident timeline ile ilişkilendirilebilir.

On-Call Rotation Tanımlı mı?

Primary ve secondary kişi production çıkışından önce belirlenmelidir. Erişim yetkileri hazır olmalıdır. Escalation policy test edilmelidir. Handover süreci tanımlanmalıdır. Tek kişiye bağımlı sistem oluşturulmamalıdır.

Monitoring Sistemi Kendisi İzleniyor mu?

Prometheus, Alertmanager ve storage health izlenmelidir. Scrape ve rule evaluation failure alarmı bulunmalıdır. Notification delivery ayrıca kontrol edilmelidir. External monitoring körlük riskini azaltır. Monitoring sisteminin resource capacity planı yapılmalıdır.

External Heartbeat Var mı?

Dead man's switch monitoring zinciri sessizce durduğunda uyarı sağlar. Heartbeat bağımsız sistemde tutulmalıdır. Grace period normal interval'e göre ayarlanmalıdır. Test sonucu düzenli kontrol edilmelidir. Tek monitoring platformuna bağımlılık azaltılmalıdır.

Retention ve Storage Planlandı mı?

Metric retention disk kapasitesiyle uyumlu olmalıdır. Cardinality tahmini yapılmalıdır. Long-term storage ihtiyacı belirlenmelidir. Storage growth alarmı eklenmelidir. Compliance gereksinimleri ayrıca kontrol edilmelidir.

Monitoring Config Git'te mi?

Alert rules ve dashboard tanımları Git'te tutulabilir. Review ve rollback süreci hazırlanmalıdır. Secret'lar repository dışında tutulmalıdır. CI validation çalıştırılmalıdır. Manual production değişiklikleri minimuma indirilmelidir.

Backup ve DR Planı Var mı?

Monitoring configuration ve gerekli historical veriler için backup ihtiyacı değerlendirilmelidir. Prometheus raw data her zaman restore edilmek zorunda olmayabilir ancak config kaybı ciddi sorun yaratır. Dashboard ve rule repository yedekli olmalıdır. Alertmanager configuration korunmalıdır. Disaster recovery testi yapılmalıdır.

Container ve orchestration katmanında monitoring planlıyorsanız Kubernetes üzerinde yük dengeleme ve otomatik ölçekleme konusunu da birlikte düşünmek gerekir. Monitoring olmadan autoscaling davranışının gerçekten işe yarayıp yaramadığını anlamak zordur. CPU bazlı ölçeklendirme bazı workload'larda yetersiz kalabilir ve application metric'leri daha doğru sinyal sağlayabilir. Bu bağlantıyı daha geniş altyapı bakış açısıyla incelemek için https://www.diyarbakiryazilim.com.tr/posts/kubernetes-uzerinde-yuk-dengeleme-ve-otomatik-olcekleme adresindeki içeriği değerlendirebilirsiniz. Monitoring, capacity ve autoscaling birlikte düşünüldüğünde production altyapısı daha öngörülebilir hale gelir.

Sık Yapılan Monitoring Hataları

Monitoring projelerinde en sık gördüğüm sorun daha fazla veri toplamanın otomatik olarak daha iyi görünürlük sağladığının düşünülmesidir. Sadece CPU ve RAM izlemek, ping sonucunu availability kabul etmek ve her metric için alarm üretmek kısa sürede gürültü oluşturur. Owner ve runbook bulunmayan alarmlar aksiyona dönüşmez. Cardinality kontrol edilmezse monitoring sistemi kendi kaynaklarını tüketmeye başlar. Postmortem sonrası alarm ve dashboard'ların güncellenmemesi de aynı hataların tekrarlanmasına yol açar.

Sadece CPU ve RAM İzlemek

CPU ve RAM önemli ancak sınırlı sinyallerdir. Disk latency, network loss veya application error görünmeyebilir. Kullanıcı servise erişemiyorsa resource grafiğinin normal olması anlam taşımaz. Golden Signals eklenmelidir. Blackbox monitoring mutlaka düşünülmelidir.

Ping Başarılıysa Sistemi Sağlıklı Sanmak

Ping host'un network seviyesinde cevap verdiğini gösterir. HTTP service down olabilir. DNS veya TLS problemli olabilir. User-facing endpoint ayrıca test edilmelidir. Ping yalnızca destekleyici sinyal olarak kullanılmalıdır.

Her Metric İçin Alarm Oluşturmak

Her metric aksiyon gerektirmez. Birçok veri yalnızca troubleshooting içindir. Page sayısı arttıkça alert fatigue oluşur. User-facing semptomlar önceliklendirilmelidir. Resource metric'leri dashboard'da tutulabilir.

Geçici Spike'larda Page Göndermek

CPU veya latency kısa süreli spike yapabilir. İnsan müdahalesi gerekmeden normale dönebilir. Pending period eklenmelidir. Critical availability gibi sinyaller farklı değerlendirilebilir. Duration historical davranışa göre seçilmelidir.

Alarmın Owner'ını Belirlememek

Sahipsiz alarm kimsenin sorumluluğunda değildir. Notification kanalı dolarken MTTA uzar. Team veya service ownership label kullanılmalıdır. Default route geçici güvenlik ağıdır. Organization değişiklikleri config'e yansıtılmalıdır.

Runbook Eklememek

Page alan kişi ilk adımı bilmiyorsa müdahale süresi uzar. Runbook hızlı diagnosis sağlar. Dashboard ve log linkleri eklenmelidir. Recovery adımları güvenli olmalıdır. Incident sonrası runbook güncellenmelidir.

Aynı Incident İçin Yüzlerce Alarm Göndermek

Root cause birçok downstream alarm üretebilir. Grouping aynı incident'ı tek notification haline getirir. Inhibition beklenen alt alarmı bastırabilir. Deduplication HA kopyalarını azaltır. Böylece on-call kişi gerçek probleme odaklanır.

Monitoring Sisteminin Kendini İzlememesi

Prometheus down olursa alarm sisteminiz sessiz kalabilir. Alertmanager failure notification'ı engelleyebilir. Metamonitoring zorunludur. External dead man's switch kullanılmalıdır. Test alarmı zinciri doğrulamalıdır.

Cardinality'yi Kontrol Etmemek

User ID veya raw URL label kullanımı time series sayısını hızla artırır. Memory ve storage maliyeti büyür. Query performansı düşebilir. Label governance uygulanmalıdır. Cardinality dashboard'u oluşturulabilir.

Yalnızca Ortalama Latency İzlemek

Average tail kullanıcılarını gizler. p95 ve p99 daha fazla bilgi verir. Histogram uygun bucket'larla tasarlanmalıdır. Traffic volume bağlamı gereklidir. User-facing SLO percentile üzerinden tanımlanabilir.

Kullanıcı Etkisi Yerine Altyapı Sinyaline Page Vermek

CPU yüksekliği doğrudan kullanıcı problemi değildir. Error rate veya availability daha güçlü semptom sinyalidir. Altyapı metric'i diagnosis sırasında kullanılmalıdır. SLO alarmı page için tercih edilebilir. Bu yaklaşım notification gürültüsünü azaltır.

Postmortem Sonrası Alarm Kurallarını Güncellememek

Incident monitoring sisteminin gerçek testidir. Alarm geç çalıştıysa iyileştirilmelidir. Gereksiz alarmlar silinmelidir. Runbook ve dashboard güncellenmelidir. Aynı incident'ın tekrarında daha hızlı detection hedeflenmelidir.

Sunucu Monitoring Maturity Model

Monitoring maturity ekiplerin basit manuel kontrolden kullanıcı odaklı reliability yaklaşımına nasıl ilerlediğini anlamak için kullanılabilir. İlk seviyede mühendis SSH ile sunucuyu kontrol ederken sonraki seviyelerde merkezi metrics, logs, ownership, on-call ve SLO sistemi devreye girer. En ileri seviyelerde burn-rate alarm ve otomatik incident response uygulanabilir. Her ekip doğrudan en üst seviyeye çıkmak zorunda değildir. Öncelik mevcut riskleri azaltacak bir sonraki anlamlı adımı atmaktır.

Seviye 0: SSH ile Manuel Kontrol

Sistem problemi kullanıcı bildirimiyle fark edilir. Mühendis sunucuya SSH ile bağlanıp top, free ve df gibi komutları çalıştırır. Historical veri bulunmaz. Detection ve diagnosis yavaştır. İlk hedef merkezi metric toplamaya geçmek olmalıdır.

Seviye 1: CPU/RAM/Disk Dashboard

Temel host metrikleri merkezi dashboard'da görünür. Historical trend oluşmaya başlar. Ancak alarm veya user-facing SLI olmayabilir. Network ve application metrics eklenmelidir. Dashboard kullanıcı etkisiyle ilişkilendirilmelidir.

Seviye 2: Threshold-Based Alerting

CPU, disk veya memory için sabit threshold alarmları eklenir. Detection otomatikleşir. Yanlış threshold alert fatigue yaratabilir. Pending ve owner süreçleri oluşturulmalıdır. User-facing semptom alarmına geçiş planlanmalıdır.

Seviye 3: Merkezi Metrics + Logs

Metrics ve logs merkezi platformda toplanır. Incident sırasında veri aramak kolaylaşır. Correlation metadata eklenebilir. Log retention ve sensitive data policy önem kazanır. Trace sistemi sonraki adım olabilir.

Seviye 4: Alert Ownership + Runbook + On-Call

Her kritik alarmın sahibi ve runbook'u vardır. On-call rotation tanımlanmıştır. Routing ve escalation test edilir. Alert fatigue düzenli ölçülür. Monitoring teknik araçtan operasyon sistemine dönüşür.

Seviye 5: Observability + SLI/SLO

Metrics, logs ve traces korele edilebilir. Kullanıcı odaklı SLI ve SLO'lar tanımlanır. Page alarmları semptom ve SLO riskine yaklaşır. Error budget reliability kararlarında kullanılır. Technical resource alarm sayısı azaltılabilir.

Seviye 6: Burn-Rate + Otomatik Incident Response

Burn-rate alarm error budget riskine göre çalışır. Güvenli ve sınırlı mitigation adımları otomatikleştirilebilir. Otomasyonun kendi safety guardrail'ları olmalıdır. İnsan ownership tamamen ortadan kalkmaz. Postmortem sonuçları otomasyon ve alarm sistemine geri beslenir.

Sık Sorulan Sorular

Sunucu monitoring konusunda ekiplerin en çok sorduğu sorular genellikle doğru threshold, araç seçimi ve alarm tasarımı etrafında toplanır. Tek bir evrensel doğru cevap yerine workload, kullanıcı beklentisi ve operasyon modeline göre karar vermek gerekir. Aşağıdaki yanıtlar production ortamlarında uygulanabilecek pratik prensiplere odaklanır. Araç seçimi değişse bile kullanıcı etkisi, owner, runbook ve test yaklaşımı geçerliliğini korur. Monitoring'in hedefi grafik üretmek değil güvenilir ve aksiyon alınabilir görünürlük sağlamaktır.

Sunucu monitoring nedir?

Sunucu monitoring CPU, memory, disk, network, process ve service davranışlarını ölçüp zaman içinde takip etme sürecidir. Application ve user-facing metric'lerle birlikte kullanıldığında daha anlamlı hale gelir. Veriler dashboard üzerinde görünür ve alarm kurallarıyla aksiyona dönüştürülür. Historical trend capacity planning için kullanılabilir. İyi monitoring kullanıcı problemi oluşmadan önce riskleri gösterebilir.

Sunucuda hangi değerler izlenmelidir?

CPU utilization, saturation, available memory, disk capacity, disk latency, network errors ve process health temel sinyallerdir. File descriptor ve system uptime de önemlidir. Fiziksel sunucularda hardware health eklenmelidir. Application error rate ve latency unutulmamalıdır. Kullanıcıya açık servis ayrıca blackbox olarak test edilmelidir.

CPU kullanım alarmı yüzde kaçta olmalıdır?

Evrensel tek bir yüzde yoktur. Yüzde 90 başlangıç warning'i olabilir ancak duration ve workload behavior dikkate alınmalıdır. Run queue veya saturation sinyali daha değerlidir. Kullanıcı latency yükselmiyorsa CPU yüksekliği page gerektirmeyebilir. Baseline ve capacity hedeflerine göre threshold ayarlanmalıdır.

RAM kullanımının yüzde 90 olması problem midir?

Her zaman değil. Linux page cache nedeniyle RAM'i aktif biçimde kullanabilir. Available memory ve swap activity daha anlamlıdır. OOM veya memory pressure sinyalleri kritik olmalıdır. Tek used yüzde alarmından kaçınılmalıdır.

Linux load average nasıl yorumlanır?

Load average CPU yüzdesi değildir. Çalışan ve belirli kaynakları bekleyen görev yoğunluğunu gösterir. Core sayısı mutlaka dikkate alınmalıdır. CPU düşükken load yüksekse I/O bekleyen process'ler araştırılabilir. Alarm duration ve normalized load üzerinden tasarlanabilir.

Disk doluluk alarmı nasıl ayarlanır?

Sabit yüzde threshold başlangıç noktası olabilir ancak yeterli değildir. Remaining capacity ve growth rate eklenmelidir. Time-to-full tahmini erken uyarı sağlar. Büyük disklerde yüzde 90 çok erken alarm olabilir. Warning ve critical müdahale sürelerine göre ayrılmalıdır.

Prometheus nedir?

Prometheus time-series metric toplama ve sorgulama sistemi olarak kullanılır. Pull-based scrape modeli ve PromQL sunar. Label tabanlı veri modeli esnektir. Alert rules ile koşullar değerlendirilebilir. Notification yönetimi için Alertmanager ile birlikte kullanılabilir.

Node Exporter nedir?

Node Exporter Linux host metriklerini Prometheus formatında sunan exporter'dır. CPU, memory, filesystem ve network verileri sağlar. Prometheus /metrics endpoint'ini scrape eder. Application metric'i sağlamaz. Güvenli internal network içinde çalıştırılmalıdır.

Grafana nedir?

Grafana monitoring verilerini dashboard üzerinde görselleştirmek için kullanılır. Prometheus dahil farklı data source'lara bağlanabilir. Panel, variable ve annotation özellikleri sunar. Provisioning ile dashboard-as-code uygulanabilir. İyi dashboard kullanıcı etkisini üstte göstermelidir.

Prometheus ile Grafana arasındaki fark nedir?

Prometheus metric toplar, saklar ve PromQL ile sorgular. Grafana bu ve diğer kaynaklardan gelen verileri görselleştirir. İki araç farklı görevleri yerine getirir. Grafana'nın kendi alerting yetenekleri bulunsa da mimari görev ayrımı açık planlanmalıdır. Birlikte kullanımları yaygındır.

Alertmanager nedir?

Alertmanager Prometheus'tan gelen firing alarmların notification sürecini yönetir. Grouping ve deduplication uygular. Team ve severity bazlı routing yapabilir. Maintenance silence ve dependency inhibition destekler. HA cluster kurulabilir.

Monitoring ile observability arasındaki fark nedir?

Monitoring önceden tanımlanmış metrik ve koşullar üzerinden sistem durumunu takip eder. Observability beklenmeyen davranışları telemetry üzerinden araştırmaya odaklanır. Metrics, logs ve traces burada birlikte kullanılır. Monitoring known problem sınıflarında güçlüdür. Observability unknown durumları anlamayı kolaylaştırır.

Blackbox monitoring nedir?

Blackbox monitoring sistemi dışarıdan kullanıcı gibi test eder. HTTP, TCP, DNS veya TLS probe kullanılabilir. İç metrikleri bilmek zorunda değildir. User-facing availability için önemlidir. Whitebox monitoring ile birlikte kullanılmalıdır.

Whitebox monitoring nedir?

Whitebox monitoring sistemin iç durumunu metric'lerle izler. CPU, memory, queue veya process bilgileri örnektir. Root cause araştırmasında çok değerlidir. Dış kullanıcı erişimini tek başına kanıtlamaz. Blackbox check ile tamamlanmalıdır.

Alert fatigue nedir?

Alert fatigue aşırı veya kalitesiz alarm nedeniyle ekibin bildirimlere duyarlılığını kaybetmesidir. False positive ve duplicate alarmlar başlıca nedenlerdir. Page sayısı azaltılmalıdır. Grouping, inhibition ve pending kullanılabilir. Düzenli alert review yapılmalıdır.

Alert flapping nasıl önlenir?

Pending period ve hysteresis kullanılabilir. Firing ve recovery threshold birbirinden ayrılabilir. Kısa spike'lar duration ile filtrelenebilir. Keep-firing davranışı bazı sistemlerde yararlıdır. Threshold metric'in normal varyasyonuna göre ayarlanmalıdır.

SLI ve SLO nedir?

SLI ölçülen hizmet kalite göstergesidir. SLO bu göstergenin hedef seviyesidir. Availability veya latency SLI olabilir. SLO kullanıcı beklentisine göre belirlenir. Monitoring bu değerleri hesaplamak için veri sağlar.

Error budget nedir?

Error budget SLO'nun izin verdiği başarısızlık payıdır. Hedef yüzde 99,9 ise kalan yüzde 0,1 budget olarak düşünülebilir. Budget tüketimi reliability riskini gösterir. Release kararlarını destekleyebilir. Burn rate tüketim hızını ölçer.

Burn-rate alerting nedir?

Burn-rate alerting error budget'ın ne kadar hızlı tüketildiğine göre alarm üretir. Sabit error threshold yerine SLO bağlamı kullanır. Kısa ve uzun window birlikte kullanılabilir. Büyük incident hızlı tespit edilir. Kullanıcı etkisine yakın page tasarımına yardımcı olur.

Her alarm on-call mühendisine gönderilmeli midir?

Hayır. Yalnızca acil, önemli ve aksiyon alınabilir olaylar page üretmelidir. Warning ticket veya mesai içi notification olabilir. Bilgilendirme metric'leri dashboard'da kalabilir. On-call kanalını korumak alarm güvenilirliği için önemlidir.

Monitoring sisteminin kendisi nasıl izlenir?

Prometheus, Alertmanager, scrape, rule evaluation ve storage health izlenmelidir. Notification failure ayrıca kontrol edilmelidir. External heartbeat kullanılmalıdır. Dead man's switch monitoring körlüğünü yakalar. Test alarmı uçtan uca zinciri doğrular.

Prometheus production ortamında nasıl ölçeklendirilir?

İlk aşamada target ve cardinality optimize edilmelidir. HA için replica kullanılabilir. Long-term storage için remote write veya uygun external backend değerlendirilebilir. Thanos, Grafana Mimir veya VictoriaMetrics farklı mimari seçenekler sunabilir. Seçim gerçek ölçek ve ekip operasyon kapasitesine göre yapılmalıdır.

OpenTelemetry monitoring için gerekli midir?

Her sistem için zorunlu değildir. Basit host monitoring Node Exporter ve Prometheus ile yapılabilir. Microservice, distributed tracing ve vendor-neutral telemetry ihtiyacı arttığında OpenTelemetry büyük değer sağlar. Collector ortak pipeline sunar. Adoption gerçek observability ihtiyacına göre yapılmalıdır.

Sonuç: Etkili Sunucu Monitoring ve Alarm Sistemi Nasıl Kurulur?

Sunucu İzleme (Monitoring) ve Alarm Mekanizmaları başarılı olduğunda ekip yalnızca sunucunun ne kadar CPU kullandığını görmez. Kullanıcının hangi anda etkilendiğini, hangi dependency'nin problemi tetiklediğini, error budget'ın ne hızla tükendiğini ve kimin müdahale etmesi gerektiğini de bilir. Production sistemi için doğru yaklaşım metric toplamakla başlar ancak ownership, runbook, notification routing, metamonitoring ve postmortem süreçleriyle tamamlanır. Araç seçimi önemlidir fakat süreç kalitesi daha önemlidir. Monitoring sisteminizi bir grafik koleksiyonu değil, reliability kararlarını destekleyen sürekli operasyon sistemi olarak tasarladığınızda gerçek değer ortaya çıkar.

Her Şeyi İzlemek Yerine Doğru Sinyalleri İzleyin

Her metric'i toplamak storage ve dikkat maliyeti oluşturur. User-facing error, latency, availability ve saturation önce gelmelidir. Alt seviye metric'ler troubleshooting ihtiyacına göre seçilmelidir. Kullanılmayan veriler düzenli temizlenmelidir. Metric'in hangi soruyu cevapladığı her zaman bilinmelidir.

Altyapı Metriklerini Kullanıcı Etkisiyle Birlikte Değerlendirin

CPU veya RAM tek başına page nedeni olmamalıdır. Application error ve latency ile correlation yapılmalıdır. User impact severity kararını güçlendirir. Infrastructure metric root cause araştırmasına hizmet eder. Böylece alarm sistemi daha az gürültü üretir.

Dashboard ile Page Alarmını Birbirinden Ayırın

Dashboard araştırma için geniş veri sunabilir. Page yalnızca hızlı insan aksiyonu gereken olaylara ayrılmalıdır. Her grafik için alarm üretmek alert fatigue oluşturur. Warning ticket kanalına yönlendirilebilir. Bu ayrım on-call ekibinin kritik alarmlara güvenmesini sağlar.

Her Alarmı Aksiyon, Owner ve Runbook ile Eşleştirin

Alarmın sahibi yoksa notification'ın değeri düşer. Owner routing ile otomatik ilişkilendirilebilir. Runbook ilk müdahale süresini azaltır. Aksiyon bulunmayan page yeniden sınıflandırılmalıdır. Alarm review sırasında bu üç alan zorunlu kontrol edilmelidir.

Grouping, Inhibition ve Hysteresis ile Alarm Gürültüsünü Azaltın

Grouping aynı incident alarmlarını birleştirir. Inhibition root cause varken downstream notification'ı azaltır. Hysteresis threshold çevresindeki flapping davranışını önler. Pending period geçici spike'ları filtreler. Birlikte kullanıldıklarında alarm kalitesi belirgin biçimde artar.

SLI/SLO ve Error Budget ile Kullanıcı Odaklı Reliability Kurun

SLI kullanıcı deneyimini ölçer ve SLO hedefi belirler. Error budget kabul edilebilir hata payını görünür hale getirir. Burn rate budget tüketim hızını gösterir. Page alarmı bu sinyallere bağlanabilir. Böylece infrastructure yüzdelerinden service reliability hedeflerine geçilir.

Logs, Metrics ve Traces'i Korele Edin

Metric problemi gösterir, trace yavaşlayan adımı bulur ve log ayrıntıyı açıklar. Ortak resource metadata üç sinyali birbirine bağlar. Trace ID investigation akışını hızlandırır. OpenTelemetry bu standardizasyonu destekleyebilir. Veri toplama stratejisi maliyet ve güvenlik politikasıyla birlikte planlanmalıdır.

Monitoring Sisteminin Kendisini de İzleyin

Prometheus veya Alertmanager failure monitoring sisteminizi kör bırakabilir. Metamonitoring component health'i izler. External heartbeat bağımsız kontrol sağlar. Dead man's switch sessizlik durumunu alarm haline getirir. Test notification zinciri düzenli doğrulanmalıdır.

Alarm Kurallarını Kod Gibi Versionlayın ve Test Edin

Rule ve dashboard config Git içinde tutulmalıdır. Code review yanlış threshold ve routing hatalarını azaltır. Unit test firing ve resolve senaryolarını doğrular. CI syntax kontrolü yapabilir. Rollback gerektiğinde önceki güvenli configuration hızlıca geri getirilebilir.

Monitoring'i Dashboard Projesi Değil Sürekli Bir Reliability Disiplini Olarak Yönetin

Monitoring kurulum bittikten sonra unutulan bir proje değildir. Workload, ekip ve kullanıcı beklentileri değiştikçe alarm kuralları da değişmelidir. Alert review, postmortem ve capacity planning bu disiplinin devamlı parçalarıdır. Benim production operasyonlarında en fazla değer gördüğüm yaklaşım, her incident sonrası gerçekten işe yarayan sinyalleri koruyup gereksiz olanları azaltmaktır. Bu alışkanlık zaman içinde daha sakin, daha anlaşılır ve daha güvenilir bir operasyon ortamı oluşturur.

Kurumsal sunucu izleme ve alarm sistemi kurulum hizmeti kapsamında yalnızca araç kurulumuna değil, metric mimarisi, dashboard standardı, alarm sahipliği, SLO yaklaşımı ve incident response sürecine birlikte bakılması gerekir. Benzer teknik çalışmaların nasıl ele alındığını görmek için https://www.diyarbakiryazilim.com.tr/projects adresindeki proje alanını inceleyebilirsiniz. Topluluğun yaklaşımı ve çalışma alanları hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir. Sunucu monitoring ve sistem yönetimi danışmanlığı yakınımda şeklinde çözüm arıyorsanız sadece Prometheus veya Grafana kurulup kurulmayacağını değil, alarm kalitesinin nasıl ölçüleceğini ve on-call sürecinin nasıl tasarlanacağını da mutlaka sorun. Sunucu İzleme (Monitoring) ve Alarm Mekanizmaları konusunda uygulama, mimari değerlendirme veya eğitim ihtiyacınız varsa Diyarbakır Yazılım Topluluğu üzerinden iletişime geçebilirsiniz: https://www.diyarbakiryazilim.com.tr.

Sunucu İzleme ve Alarm Mekanizmaları Hakkında Ek Sık Sorulan Sorular

Aşağıdaki sorular özellikle gerçek bir monitoring altyapısı kurmaya hazırlanan ekiplerin karar aşamasında sık karşılaştığı konuları kapsar. Threshold belirleme, araç seçimi ve notification kanalı ilk bakışta ayrı kararlar gibi görünse de aslında aynı reliability sisteminin parçalarıdır. Monitoring mimarisi kurulurken veri toplama ile insan müdahalesi arasındaki tüm zincir birlikte düşünülmelidir. Küçük ekiplerde sade bir yapı tercih edilebilirken daha büyük production ortamlarında ownership ve high availability gereksinimleri artar. Hangi ölçekte olursa olsun kullanıcı etkisini merkeze alan alarm tasarımı en sağlam başlangıç noktasıdır.

Sunucu izleme (Monitoring) sistemi nasıl kurulur ve hangi metrikler takip edilmelidir?

İlk adım kritik servisleri, owner'ları ve kullanıcıya açık endpoint'leri belirlemektir. Ardından Linux host'larda CPU, available memory, filesystem, inode, disk latency, network error, process health ve uptime gibi temel metrikler toplanmalıdır. Application katmanında request rate, error rate, response time ve dependency health eklenmelidir. Prometheus ve Node Exporter gibi bileşenler metric toplama için, Grafana dashboard için ve Alertmanager notification yönetimi için birlikte kullanılabilir. Sistem kurulduktan sonra test alert, external heartbeat ve backup kontrolleriyle monitoring sisteminin kendisi de doğrulanmalıdır.

CPU RAM disk kullanımı ve ağ trafiği için alarm eşikleri nasıl belirlenmelidir?

Tek bir sabit yüzdeyi tüm sunuculara uygulamak yerine workload baseline'ı ve kullanıcı etkisi değerlendirilmelidir. CPU alarmında utilization yanında run queue ve latency, RAM alarmında available memory, swap ve OOM riski incelenmelidir. Disk alarmında yüzde doluluk yerine remaining capacity, growth rate ve time-to-full kullanmak daha doğru sonuç verir. Network tarafında bandwidth yanında packet loss, error, drop ve retransmission değerleri izlenmelidir. Her threshold kısa spike'ları filtrelemek için uygun duration ve recovery mantığıyla desteklenmelidir.

Prometheus Grafana Zabbix ve Nagios gibi monitoring araçlarından hangisi tercih edilmelidir?

Tercih altyapının yapısına, ekip deneyimine ve yönetim modeline göre yapılmalıdır. Prometheus ve Grafana dynamic service discovery, label tabanlı metrics ve cloud-native workload'lar için güçlü bir kombinasyon oluşturur. Zabbix daha bütünleşik agent, trigger ve geleneksel sunucu monitoring yaklaşımı isteyen ekiplerde değerlendirilebilir. Nagios plugin tabanlı basit host ve service check ihtiyaçlarında kullanılabilir ancak büyüyen dynamic yapılarda configuration otomasyonu ayrıca planlanmalıdır. Araç seçiminden önce target sayısı, HA ihtiyacı, retention, dashboard, alert routing, mevcut ekip bilgisi ve operasyon maliyeti karşılaştırılmalıdır.

Sunucu alarmlarında e-posta SMS Slack ve Microsoft Teams bildirimleri nasıl yapılandırılır?

Notification kanalları alarm severity ve urgency seviyesine göre ayrılmalıdır. Düşük öncelikli warning olayları e-posta veya ticket sistemine, ekip koordinasyonu gerektiren olaylar Slack ya da Microsoft Teams kanalına ve gerçekten acil incident'lar SMS, telefon veya on-call platformuna yönlendirilebilir. Alertmanager gibi notification manager katmanı team, service, environment ve severity label'larına göre routing yapabilir. Grouping ve deduplication aynı incident nedeniyle onlarca mesaj oluşmasını önlemelidir. Her notification içinde service, mevcut değer, kullanıcı etkisi, dashboard, runbook ve owner bilgileri bulunmalıdır.

Sunucu izleme ve alarm mekanizmaları kurulumu konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Danışmanlık veya eğitim ararken yalnızca monitoring aracını kurabilen bir hizmet yerine production alarm tasarımı, SLI/SLO, incident response ve metamonitoring konularını birlikte ele alabilen bir yaklaşım tercih edilmelidir. İyi bir çalışma mevcut sisteminizi incelemeli, hangi sinyallerin gerçekten önemli olduğunu belirlemeli ve gereksiz page alarmlarını azaltmalıdır. Diyarbakır Yazılım Topluluğu'nun çalışma ve proje yaklaşımını https://www.diyarbakiryazilim.com.tr/projects üzerinden değerlendirebilirsiniz. Topluluk hakkında daha ayrıntılı bilgi için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilirsiniz. Sunucu İzleme (Monitoring) ve Alarm Mekanizmaları için teknik danışmanlık, eğitim veya kurulum ihtiyacınızı paylaşmak üzere https://www.diyarbakiryazilim.com.tr adresini kullanabilirsiniz.