ESM 3004 ve sorgu hataları: alarm yükünü veritabanı arızasından ayırmak

SIEM sorgusunda hata kodu görmek, olay verisinin kaybolduğu veya veritabanının bozulduğu sonucunu tek başına vermez. Sorgu yükü, çalışan görevler ve eşlik eden native hata kayıtları birlikte değerlendirilmelidir. Özellikle erişim ihlali gibi ek belirtiler normal bir “sonuç yok” durumundan ayrı ele alınır.

1. Hata zincirini sakla
2. Sorgu yükünü çıkar
3. Kaynakları ölç
4. Sorunlu işi daralt
5. Destekli düzeltmeyi uygula
6. Alarmları kademeli aç

Kodun çevresindeki hata zincirini kaydedin

Hata zamanı, ilgili alarm veya rapor, sorgu aralığı ve ürün build bilgisi saklanır. Sadece son satırın ekran görüntüsü yerine önceki ve sonraki olaylar birlikte incelenir. Kuruma ait alanlar destek paylaşımında uygun biçimde sınırlandırılır.

3004 gibi bir kod bütün sürümlerde tek kök nedeni kanıtlamaz. Eski bir vaka için yapılmış performans tahminini yeni olayın kesin sonucu gibi kullanmayın. Crash veya erişim ihlali varsa üretici destek incelemesi gerekebilir.

Çalışan sorguları ve zaman penceresini inceleyin

Task Manager üzerinden uzun süren rapor, görünüm, watchlist ve alarm sorguları değerlendirilir. Üreticinin izin verdiği kullanıcı sorguları kontrollü kapatılabilir; sistem sorgularına rastgele müdahale edilmez.

Çok sık çalışan ve geniş zaman aralığını tarayan alarmlar üst üste binebilir. Sıklığı veya pencereyi azaltırken tespit gereksinimini koruyun. Bütün alarmları aynı sabit aralığa çekmek her kullanım senaryosu için doğru değildir.

Kaynak baskısını ölçün

Disk ve inode doluluğu, bellek, swap ve yük ortalaması kontrol edilir. Veri bölümleri ile işletim sistemi alanı ayrı incelenmelidir. Bir partition doluluğu uygulama genelinde farklı hatalar üretebilir.

df -h
df -i
free -m
uptime

Appliance üzerinde standart Linux komutlarının erişilebilirliği sürüme bağlıdır. Üretici destek kapsamı dışındaki paket veya onarım araçlarını kurmayın.

Değişikliği kontrollü ve geri alınabilir tutun

Sorunlu alarm veya sorgu dar kapsamda durdurularak sistem davranışı gözlenir. Servis restart’ı gerekiyorsa bakım ve veri alım etkisi planlanır. HA veya çok düğümlü yapıda sıra üretici prosedürüne göre belirlenir.

Veritabanı dosyası silme, index rebuild veya metadata düzeltmesi destek yönlendirmesi olmadan uygulanmamalıdır. Destek paketi, build ve tekrar üretim adımları hazırlanır. Hotfix kararı tam sürüm ve resmî sürüm notuyla eşleştirilir.

Alarmları kademeli geri alın

Tek bir sorguyla başlayıp süre ve kaynak etkisini ölçün. Ardından diğer görevler kontrollü açılır. Sorgu başarısı kadar log alımının ve kritik alarm kapsamının sürdüğü de doğrulanmalıdır.

• Hata zinciri ve build kayıtlı.
• Sorgu yükü ölçüldü.
• Disk ve bellek durumu değerlendirildi.
• Destek dışı DB müdahalesi yapılmadı.
• Alarm kapsamı ve performans birlikte doğrulandı.

İlgili çalışma notları

• IPsec üzerinden yedek aktarımı yavaş: bant genişliği, MTU ve TCP ayrımı
• SIEM session lock ve ELM sağlık sorunları: kilidi silmeden önce ne incelenmeli?
• Windows yavaşlığını ölçmek: başlangıç, bellek, disk ve arka plan işleri