İÇİNDEKİLER
- •Doğru alarmlar, doğru zamanda
- •Kısaca: İyi Bir Alarm Matrisinin Özellikleri
- •Önem Dereceleri
- •Alarm Matrisi: Ortak Metrikler
- •SQL Server’a Özgü Alarmlar
- •PostgreSQL’e Özgü Alarmlar
- •Alarm Yorgunluğunu Önlemek
- •Alarm Matrisi Bir Dokümandır, Araç Değil
- •Aryasoft ile 7×24 İzleme
- •Sıkça Sorulan Sorular
- •Kaynaklar
- •7×24 izleme, gerçek müdahale
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.
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.
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
Kaynaklar
Bu rehberdeki teknik bilgiler Kasım 2026’da aşağıdaki resmi dokümantasyonla karşılaştırıldı.
- Microsoft Learn: MSSQLSERVER_825
- Microsoft Learn: MSSQLSERVER_824
- Microsoft Learn: Database engine error severities
- Microsoft Learn: sp_add_alert
- PostgreSQL dokümantasyonu: Routine Vacuuming
- 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.