Alert bell and a grid of tiles with one warning

Veritabanı İzlemede Hangi Alarmlar Olmalı? DBA Alarm Matrisi

Veritabanı izleme sisteminde hangi metrik için hangi eşikte alarm üretilmeli? SQL Server ve PostgreSQL için önem dereceleri, eşik önerileri ve alarm yorgunluğunu önleme yöntemleri.

Kasım 5, 2026

DBA alarm matrisi, veritabanı izleme sisteminde hangi metrik için hangi eşikte alarm üretileceğini, alarmın önem derecesini ve alarm geldiğinde kimin ne yapacağını tek bir tabloda tanımlayan dokümandır. İyi bir alarm matrisi iki hatayı birlikte önler: kritik bir sorunun hiç alarm üretmemesini ve ekibin önemsiz alarmlar arasında gerçek sorunu gözden kaçırmasını.

Bu rehber, SQL Server ve PostgreSQL ortamları için bir alarm matrisinin nasıl kurulacağını anlatıyor. Önerilen eşikler bir başlangıç noktasıdır; kendi sisteminizin normal davranışına (baseline) göre ayarlanmalıdır.

Veritabanı İzleme

Doğru alarmlar, doğru zamanda

Aryasoft, veritabanlarınız için alarm matrisini sizinle birlikte kurar; SLA modelinde alarmlar otomatik olarak talep açar ve nöbetçi mühendis tarafından çözülür.

Bize Ulaşın

Kısaca: İyi Bir Alarm Matrisinin Özellikleri

Özellik Açıklama
Her alarm bir aksiyon gerektirir Alarm geldiğinde yapılacak bir şey yoksa, o bir alarm değil bir rapor satırıdır.
Önem derecesi nettir Kritik alarm gece uyandırır; uyarı mesai saatinde ele alınır; bilgi yalnızca kaydedilir.
Sahibi bellidir Her alarm için kimin, hangi süre içinde müdahale edeceği tanımlıdır.
Eşikler sisteme özeldir Bir sunucu için normal olan değer, diğerinde kriz işareti olabilir.
Düzenli gözden geçirilir Hiç tetiklenmeyen veya sürekli tetiklenip görmezden gelinen alarmlar ayıklanır.

Önem Dereceleri

Seviye Ne anlama gelir? Beklenen tepki
Kritik Hizmet durmuş veya dakikalar içinde duracak; veri kaybı riski var. Gece de dahil hemen müdahale
Yüksek Hizmet çalışıyor ama bozulma başlamış; saatler içinde kritiğe dönüşebilir. Aynı gün, mesai dışında da ele alınır
Uyarı Eğilim olumsuz; günler içinde sorun yaratabilir. Mesai saatinde planlı müdahale
Bilgi Kayıt ve eğilim analizi için Haftalık veya aylık raporda değerlendirilir

Alarm Matrisi: Ortak Metrikler

Aşağıdaki tablo hem SQL Server hem PostgreSQL için geçerli olan temel alarmları içeriyor. Eşikler başlangıç önerisidir.

Metrik Uyarı Kritik Alarm geldiğinde
Servis erişilebilirliği — Veritabanı servisine bağlanılamıyor Servis durumu, hata logu, son değişiklikler; kesinti prosedürü
Disk doluluğu (veri, log, yedek) %80 %90 veya tahmini dolma süresi 24 saatin altında Büyüyen dosyayı bulun; log yedeği veya alan açma; kapasite planı
Son başarılı tam yedek Planlanan süreden 1 gün geç Planlanan süreden 2 gün geç Yedekleme işinin hatası; hedef disk; yedeği elle başlatın
Son log / WAL yedeği RPO hedefinin yarısı RPO hedefi aşıldı Log yedek işi veya arşivleme hatası; log dosyasının büyümesini izleyin
Replikasyon gecikmesi Normal değerin birkaç katı RPO hedefini aşan gecikme Ağ, yedek sunucu disk gecikmesi, uzun işlemler
Blocking Bir oturum 1 dakikadan uzun bekliyor 5 dakikadan uzun veya zincir büyüyor Zincirin başındaki oturumu bulun; uygulama sahibiyle birlikte karar verin
Uzun süren işlem 30 dakikadan uzun açık işlem Log/WAL büyümesini engelleyen açık işlem Oturum sahibini bulun; işlemin durumunu değerlendirin
CPU kullanımı 15 dakika boyunca %80 üzeri 15 dakika boyunca %95 üzeri En çok CPU kullanan sorgular; plan değişikliği; yeni sürüm
Disk gecikmesi Okuma veya yazma ortalaması 20 ms üzeri 50 ms üzeri ve devam ediyor Hangi dosyada; depolama veya sanallaştırma ekibiyle metriklerle görüşün
Bağlantı sayısı Sınırın %80’i Sınırın %95’i Bağlantı sızıntısı; boşta bekleyen oturumlar; havuz ayarları
Hata logu Tekrarlayan giriş hataları Bozulma, G/Ç veya bellek hataları Hatanın türüne göre prosedür; bozulmada önce yedeklerin durumu

Uyarı

Alarm eşiğini yalnızca yüzde olarak tanımlamayın. 10 TB’lık bir diskte %90 doluluk 1 TB boş alan demektir ve haftalarca yetebilir; 100 GB’lık bir log diskinde ise birkaç dakikada dolabilir. Mümkün olduğunda “tahmini dolma süresi” gibi eğilime dayalı alarmlar kullanın.

SQL Server’a Özgü Alarmlar

Alarm Neden önemli?
Hata 823, 824, 825 G/Ç ve sayfa bozulması belirtileri. 825, okumanın tekrar denemeyle başarılı olduğunu gösterir ve çoğu zaman yaklaşan bir disk sorununun ilk işaretidir.
Önem derecesi 19–25 hatalar Kaynak, yazılım veya donanım kaynaklı ciddi hatalar
DBCC CHECKDB’nin son başarılı tarihi Tutarlılık kontrolü belirlenen süreden uzun süredir çalışmamışsa bozulma geç fark edilir.
Agent işlerinin hataları Yedekleme ve bakım işleri sessizce başarısız olabilir.
Always On senkronizasyon durumu NOT SYNCHRONIZING veya artan gönderim ve yeniden uygulama kuyrukları
Deadlock sayısı Ani artış, yeni bir uygulama sürümünün veya plan değişikliğinin işareti olabilir.
tempdb doluluğu tempdb’nin dolması tüm instance’ı etkiler.

Hata 823, 824 ve 825 için SQL Server Agent alarmları birkaç satırla kurulabilir. Aşağıdaki örnek alarmları oluşturur; bildirim için bir operatör tanımlayıp sp_add_notification ile bağlamanız gerekir:

USE msdb;
EXEC dbo.sp_add_alert @name = N'Error 823 - I/O error',
     @message_id = 823, @severity = 0, @include_event_description_in = 1;
EXEC dbo.sp_add_alert @name = N'Error 824 - Logical consistency error',
     @message_id = 824, @severity = 0, @include_event_description_in = 1;
EXEC dbo.sp_add_alert @name = N'Error 825 - Read retry',
     @message_id = 825, @severity = 0, @include_event_description_in = 1;
EXEC dbo.sp_add_alert @name = N'Severity 024 - Fatal hardware error',
     @severity = 24, @include_event_description_in = 1;

Hangi alarmların açılması gerektiğini ve operatör ayarlarını SQL Server alert rehberimizde ayrıntılı olarak anlattık.

PostgreSQL’e Özgü Alarmlar

Alarm Neden önemli?
İşlem numarası yaşı (wraparound) Yaş autovacuum_freeze_max_age değerine yaklaşıyorsa autovacuum yetişemiyordur; en kötü durumda veritabanı yeni işlemleri kabul etmez.
Aktif olmayan replication slot’lar Kullanılmayan bir slot, disk dolana kadar WAL biriktirir.
WAL arşivleme hataları Başarısız arşivleme, belirli bir ana geri dönüş imkânını sessizce ortadan kaldırır.
Boşta bekleyen açık işlemler “idle in transaction” oturumları VACUUM’u engeller.
Ölü satır oranı Yoğun tablolarda hızla artan ölü satırlar, autovacuum ayarlarının yetersiz olduğunu gösterir.
Failover olayı Patroni veya küme yöneticisinin lider değiştirmesi; nedeni incelenmelidir.

Örneğin işlem numarası yaşı ve aktif olmayan slot’lar için şu sorgular izleme sistemine eklenebilir:

-- Transaction ID age as a percentage of autovacuum_freeze_max_age
SELECT datname,
       age(datfrozenxid) AS xid_age,
       round(100.0 * age(datfrozenxid) / current_setting('autovacuum_freeze_max_age')::int, 1) AS pct_of_freeze_max
FROM pg_database
ORDER BY xid_age DESC;
-- Inactive replication slots and the WAL they retain
SELECT slot_name, active,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_replication_slots
WHERE NOT active;

Alarm Yorgunluğunu Önlemek

Çok fazla alarm, hiç alarm olmamasından daha tehlikeli olabilir: ekip, sürekli gelen bildirimlere alışır ve kritik olanı da görmezden gelir. Bunu önlemek için:

  • Süre koşulu ekleyin: Anlık CPU sıçramaları yerine “15 dakika boyunca” gibi süreli koşullar kullanın.
  • Tekrarları birleştirin: Aynı sorun için her dakika yeni bildirim göndermeyin.
  • Bakım dönemlerini tanımlayın: Planlı çalışmalar sırasında beklenen alarmları sessize alın.
  • Aylık gözden geçirin: Hangi alarmın kaç kez tetiklendiğini ve kaçının gerçek aksiyon gerektirdiğini raporlayın.

İpucu

Her alarma kısa bir “ilk bakılacaklar” notu ekleyin. Gece 3’te alarmı alan mühendisin ilk beş dakikada ne kontrol edeceğini bilmesi, müdahale süresini doğrudan kısaltır. Bu notlar zamanla ekibinizin en değerli runbook’una dönüşür.

Alarm Matrisi Bir Dokümandır, Araç Değil

Hangi izleme aracını kullandığınız, alarm matrisinden sonra gelen bir karardır. Önce neyi, hangi eşikte, kimin izleyeceğini tanımlayın; sonra bu matrisi uygulayabilecek aracı seçin. Günlük, haftalık ve aylık kontrolleri SQL Server izleme kontrol listemizde, bir kesinti anında ilk adımları ilk 30 dakika runbook’umuzda bulabilirsiniz.

Aryasoft ile 7×24 İzleme

Aryasoft’un SLA modelinde izleme 7x24x365 sürer: alarmlar otomatik olarak talep açar, nöbetçi ekipteki bir mühendis alarmı çözer ve tüm olaylar aylık raporda yer alır. Ekip; bir müşteri temsilcisi, teknik ekip ve nöbetçi ekipten oluşur. Mesai saatlerinde ilk müdahale süresi 30 dakika, mesai dışında 2 saattir. Alarm matrisini ilk gün sizinle birlikte, sistemlerinizin normal davranışına göre kurarız. Ayrıntılar yönetilen veritabanı hizmetleri sayfamızda.

Sıkça Sorulan Sorular

Yedekleme alarmları. Diğer sorunlar kesinti veya yavaşlık olarak kendini gösterir; başarısız bir yedek ise ancak geri yükleme gerektiğinde fark edilir. Son başarılı tam ve log yedeğinin yaşı her alarm matrisinde olmalıdır.
Önce birkaç hafta boyunca metrikleri toplayarak sistemin normal davranışını (baseline) çıkarın. Eşikleri bu normale göre belirleyin ve ilk ayın sonunda gereksiz tetiklenen alarmları ayarlayın.
825, SQL Server’ın bir sayfayı ilk denemede okuyamadığını ama tekrar denemede başarılı olduğunu gösterir. İşlem başarılı göründüğü için genellikle fark edilmez; oysa çoğu zaman yaklaşan bir depolama sorununun ilk belirtisidir.
Sayıdan çok her alarmın bir aksiyon gerektirmesi önemlidir. Kritik seviyede az sayıda, net alarm tutun; diğer metrikleri uyarı veya rapor seviyesinde izleyin.

Kaynaklar

Bu rehberdeki teknik bilgiler Kasım 2026’da aşağıdaki resmi dokümantasyonla karşılaştırıldı.

  1. Microsoft Learn: MSSQLSERVER_825
  2. Microsoft Learn: MSSQLSERVER_824
  3. Microsoft Learn: Database engine error severities
  4. Microsoft Learn: sp_add_alert
  5. PostgreSQL dokümantasyonu: Routine Vacuuming
  6. PostgreSQL dokümantasyonu: pg_replication_slots

Veritabanı İzleme

7×24 izleme, gerçek müdahale

Aryasoft’un SLA modelinde alarmlar otomatik olarak talep açar, nöbetçi mühendis çözer ve her olay aylık raporda yer alır.

4.7/5