Logstag
EN Demo talep edin
Alarmlar

Kendini açıklayan alarmlar.

Logstag 200'den fazla kontrolle gelir. Her alarm neyin yanlış olduğunu, neden önemli olduğunu, genellikle neyin buna yol açtığını ve ne yapılması gerektiğini söyler.

Demo talep edin
Alarmlara genel bakış

Ne açık, ne kadar hızlı kapanıyor.

Tüm veritabanlarındaki alarmlar için tek sayfa: şu an neyin tetiklendiği, alarmların ne kadar sürede çözüldüğü ve her günün SLA'nıza göre durumu.

Logstag uygulamasında Alarmlar sayfası: aktif ve kritik alarm sayıları, ortalama çözülme süresi ve son haftada tetiklenen alarmlar; altında her gün oluşan ve çözülen alarmların grafiği, SLA'yı aşan kısım kırmızıyla.

  • Şu an açık olanlar

    Tüm veritabanlarındaki aktif alarmlar; kritik olanlar ayrıca sayılır.

  • Ne kadar hızlı kapanıyor

    Seçili hafta boyunca ortalama çözülme süresi.

  • SLA'ya göre

    Her gün oluşan ve çözülen alarmlar; belirlediğiniz SLA'yı aşan kısım kırmızıyla işaretlenir.

Yerleşik kontroller

200'den fazla kontrol, yazılacak kural yok.

Eşikler her kontrolle birlikte gelir. Logstag'in işe yaraması için alarm kuralı oluşturmanız veya sayıları ayarlamanız gerekmez: bir veritabanı bağlayın, o motorun kontrolleri çalışmaya başlasın.

Kilitleyen sorgularBoşta bekleyen işlemlerReplikasyon gecikmesiKapasitesi dolmak üzere olan log dosyasıxp_cmdshell etkinKoleksiyon taramalarıTablespace kullanımıBellek parçalanmasıKullanım ömrü sonuna yaklaşan sürümVeri göndermeyi bırakan agent

Yerleşik kontrolleri olan motorlar

  • PostgreSQL
  • SQL Server
  • Oracle
  • MongoDB
  • Redis
  • Valkey
  • ClickHouse

Ek okuma: Veritabanı güvenilirliği, çalışır durumda olmak değildir.

Bir alarmın içi

Çalışma kılavuzu alarmla birlikte gelir.

Aşağıdaki metin, PostgreSQL kilitleyen sorgular kontrolünün gerçek metninden kısaltılarak çevrilmiştir. Her kontrol aynı bölümleri taşır; alarm da tetiklendiği andaki bağlamı ekler.

YüksekKilitleyen sorgular tespit edildiPostgreSQL · Aktivite

Etki

Kilitleyen sorgular, ilerleyemeyen bağımlı işlemlerden oluşan bir kuyruk oluşturur; bu da uygulama zaman aşımlarına, bağlantı havuzunun tükenmesine ve kullanıcı deneyiminin bozulmasına yol açar.

Yaygın nedenler

  • Kilitleri uzun süre tutan, uzun süre çalışan işlemler
  • Şema değişikliklerinden kaynaklanan tablo düzeyinde kilitler (ALTER TABLE, CREATE INDEX)
  • Sorguların gerekenden fazla kilit almasına neden olan eksik index'ler

Önerilen işlemler

  1. Kilitleyen sorguları ve kilitledikleri oturumları belirleyin.
  2. Kilitleyen işlemlerin ne kadar süredir açık olduğunu kontrol edin.
  3. Süresiz kilitlenmeyi önlemek için statement_timeout ayarlayın.

Bağlam (örnek)

blocking_pid 4127 · blocked 3 · wait 2 m 14 s

Listeyi kısa tutmak

Aynı sorunu yaşayan birçok veritabanı tek satırdır.

Tekrarlar birleşir

Aynı nesnedeki aynı durum tek bir alarmdır; her yoklamada yeni bir alarm açılmaz.

Kontrole göre gruplama

Liste alarmları kontrole göre gruplar; böylece tüm altyapınızdaki bir sorun, sayısıyla birlikte tek bir satır olarak okunur.

Kapsamlı susturma

Bir kontrolü bir instance, bir veritabanı veya tek bir nesne için susturun. Kural, siz kaldırana kadar aynı biçimdeki gelecek alarmları da kapsar.

Kendiliğinden çözülür

Koşulu ortadan kalkınca alarm kendiliğinden çözülür. Kimsenin onu elle kapatması gerekmez.

SLA'lar

Yöneticiler kontrole, öneme, instance'a veya veritabanına göre süre sınırları belirler. Alarmlar, süre içinde mi olduklarını yoksa sınırı aştıklarını gösterir.

Sessizlik de bir alarmdır

İzlenen bir sunucu bir gün boyunca veri göndermeyi bırakırsa, sağlıklı görünen boş bir grafik yerine bir alarm alırsınız.

Sıfır yapılandırma. Bağlayın ve başlayın.

Yazılacak kural, ayarlanacak eşik yok. Bir veritabanı bağlandığı anda, motoruna ait tüm kontroller kendiliğinden çalışmaya başlar.

Demo talep edin