Uyarılar

İzleme sayfasında bugün de bir “dikkat gerektirenler” listesi var — ama onu görmek için sayfayı açmanız gerekir. Uyarılar bu bakışı bir kurala bağlar: eşik aşıldığında ya da veri kesildiğinde, seçtiğiniz kanala (e-posta, webhook, sohbet, ITSM) haber gider.

• Uyarı listesi İzleme sayfasında yeni bir sekmede. Açık uyarı sayısı üst çubukta bir çip olarak da görünür.
• Kural, kanal, yönlendirme, sessizlik ve bakım penceresi yalnız yönetici yazar. Uyarı listesini ise herkes kendi Kubernetes yetkisine göre görür: göremediğiniz bir namespace’teki uyarı listede görünmez, ama sayısı bir çipte kalır — sessizce yutulmaz.

Bir eşik kuralı; varlık türü (node, pod, iş yükü, PVC), metrik, karşılaştırma ve eşik değerinden oluşur. Bir geçişin olay sayılması için en az bir süre boyunca sürmesi, çözüldüğünün sayılması için de ayrı bir süre boyunca eşiğin altında kalması gerekir — tek bir örnek ne bir olay açar ne kapatır.

• Son örnek 3 dakikadan eskiyse eşik kuralı hiç değerlendirilmez. Donmuş bir değer üstünden ne “iyi” ne “kötü” denir; varlık bayat işaretlenir ve durumu neyse orada kalır.
• “Veri gelmiyor” ayrı bir kural türüdür. Toplayıcının kendisi, node ya da örneklerin akışı (alım) için ayrı ayrı izlenir — üçü farklı bir arızayı gösterir.
• Cevapsızlık arıza sayılmaz. Durumu sorulamayan bir cluster “veri yok” olayı açmaz; ikisi listede de ayrı görünür.
• Önem derecesi (bilgi/uyarı/kritik) yalnız yönlendirmeyi etkiler, ölçümü değil.

Kurulumda 14 hazır kural açık gelir (11 eşik + 3 “veri gelmiyor”); ateşlediklerinde İzleme sayfasında görünürler. Hiçbirinin varsayılan bir kanalı yoktur — bir kanala gitmeleri için bir yönlendirme tanımlamanız gerekir.

• Ölçümü tanımlayan alanlar kilitlidir. Tür, varlık türü, metrik, karşılaştırma, eşik ve kapsam değiştirilemez; hazır kural silinemez, yalnız kapatılabilir. Amaç, ekranın kırmızı gösterdiğiyle uyarının ateşlediğinin hep aynı kalması.
• Açık/kapalı, en az süre, çözülme süresi ve önem derecesi serbesttir. Bunlar uyarının kendi kavramlarıdır ve ekranda karşılığı yoktur; kendi ortamınıza göre ayarlayabilirsiniz.
• Kendi eşiğinizi ölçmek isterseniz hazır kuralı değil kendi kuralınızı yazın — aynı ölçümün iki farklı eşikle yaşaması, hangisine güveneceğinizi belirsizleştirir.

Bir yönlendirme; en az önem derecesi, isteğe bağlı cluster/kural filtresi ve hangi kanallara gideceğini taşır. Bir uyarı birden çok yolla eşleşirse hepsi gönderir — çift bildirim görülür, eksik bildirim görülmez.

• Çözülmemiş bir uyarı dört saatte bir hatırlatılır, çözülünce de haber verilir — ikisinin kanala ÇIKIŞ zamanlaması aşağıda.
• Bir cluster'da açılan uyarılar 5 dakikalık bir pencerede toplanıp o cluster için tek mesajda gider (kritik beklemez). HTTP Hook'a (ITSM vb.) giden gövde bu toplamadan etkilenmez — hâlâ kural × cluster başına bir satır, en çok 50 varlık taşır, kalanı bir sayı olarak söyler.
• Kısa aralıklarla ateşleyip çözülen bir hedef artık bastırılır: kapanış 30 dakika bekler, bu sürede yeniden açılırsa hiç gitmez; Uyarılar sekmesinde "N kez yeniden açıldı" rozeti görünür.

Toplama penceresi, kapanış beklemesi, gidip-gelme bastırması ve HTTP/ITSM zamanlaması: Bildirim zamanlaması.

İnsan kanalına (e-posta, sohbet) giden bir uyarı artık anında değil, cluster başına toplanarak gider. HTTP Hook'a (ITSM vb.) giden gövde biçimi bundan etkilenmez — değişen yalnız zamanlamadır.

• Toplama penceresi: cluster başına 5 dakika. Bir cluster'da açılan uyarılar 5 dakika içinde toplanıp o cluster için tek mesajda gider; pencere sabittir, yeni bir ateşleme onu uzatmaz. Kritik bir ateşleme beklemez — aynı turda, o ana kadar bekleyen diğer ateşlemeleri de yanına alarak gider.
• Kapanış her zaman 30 dakika bekler (önem derecesinden bağımsız), sonra en çok 5 dakikalık kendi penceresinde gider — toplamda ~30–35 dakika. Bekleme boyunca aynı hedef yeniden açılırsa kapanış hiç gitmez ve yeni tetiklenme de bildirilmez: kanal açısından uyarı hiç kapanmamıştır. Giden kapanış mesajı "30 dakikadır yeniden açılmadı" der, bir sebep iddia etmez.
• Birden çok kez gidip gelen bir hedef tek bildirilir. Kapanış mesajı kaç kez yeniden açıldığını yazar; Uyarılar sekmesinde de "N kez yeniden açıldı" rozeti görünür.
• İzleme bekleme sırasında kesilirse ya da hedef artık okunmuyorsa mesaj bunu söyler: kapanışın ölçüt satırı "· izleme arada N dk kesildi" ekler; hedefi kaybolan bir varlık için "Hedef artık okunmuyor" der.
• HTTP Hook'a (ITSM vb.) giden gövde biçimi DEĞİŞMEDİ, yalnız zamanlama değişti: tetiklenme ~5 dakika, kapanış ~35 dakika gecikmeyle gider. Gidip gelen bir olayda olay kimliği (id) değişebilir; kayıtlarınızı id değil fingerprint ile eşleyin.
• Denetim kaydı ve SIEM aktarımı bu pencerelerden etkilenmez — ikisi de gerçek zamanlı kalır.

Bu süreler normal çalışmada geçerlidir. Bir cluster'ın değerlendirmesi aksarsa (ör. erişilemiyor, lisans askıda) kapanış mesajı o cluster'dan toplam 30 dakikalık taze veri gelene kadar ertelenir; kesinti süresi sayılmaz. Üst sınır yoktur: kapanış kaybolmaz, gecikir.

Sessizlik geçici ve gerekçe ister — kendi kapsamını seçerek “bu kuralı bu cluster’da yarına kadar sustur” gibi geniş bir kayıt da açabilirsiniz. Bakım penceresi haftalık tekrar eder ve change-freeze ile aynı takvim biçimini kullanır, ama listesi ayrıdır: bir pencerede değişiklik yasak olması, o pencerede uyarının da susacağı anlamına gelmez — ikisi ayrı ayrı açılır.

Bir sessizlik artık yerinde düzenlenebiliyor: gerekçe, kapsam ve tarihler yeniden yazılabiliyor, yeni bir kayıt açılmadan aynı kayıt güncelleniyor. Kimin ne zaman düzenlediği listede görünüyor; hangi alanların değiştiği de ayrıca kaydediliyor, ama önceki gerekçe ya da tarihler ayrıca tutulmuyor.

İzleme sayfasındaki “Sustur” kısayolunun varsayılan kapsamı artık yalnız o uyarının kendi hedefidir — bir pod için bu, pod’un sahibi olan iş yükü demektir ve pod yeniden başlasa da geçerli kalır; sahibi çözülemeyen bir pod, bir iş yükü, bir node ya da bir hacim için ise kendisidir. “Bu cluster’daki tüm hedefler” hâlâ seçilebiliyor ama artık ikinci seçenek, varsayılan değil. Bir CronJob’un pod’u kendi koşumunun işine bağlı olduğundan, dar seçenek CronJob’larda yalnız o koşumu susturuyor; bir sonraki koşum yeniden uyarır.

Her cluster’ın en fazla bir zamanlaması olabilir: aralık (6 saat, 12 saat, 24 saat ya da haftalık), bir çapa saati ve saat dilimi (IANA, yerel saatle). Zamanlama, onu kuran yöneticinin kimliğiyle koşar.

• Sahip kontrolü her koşuda yeniden yapılır, kayıtlı bir yetkiye güvenilmez. Şu durumlardan biri varsa zamanlama duraklar ve üst çubukta yalnız yöneticiye görünür: sahip devre dışı bırakılmış, sahibin yöneticilik rolü kalkmış, cluster kimliği artık çözülmüyor, sahibin dizin grubu üyeliği (sunucudan yeniden sorularak) daralmış, OIDC ile gelen sahip 30 gündür giriş yapmamış, ya da cluster’ın AI egress’i kapatılmış.
• Geçici bir arıza durdurmaz. Dizin sunucusuna erişilemiyorsa, tünel yoksa ya da günlük AI bütçesi bittiyse zamanlama aynı koşuyu bir pencere içinde yeniden dener; yalnız kimliğin kendisi doğrulanamazsa durur.
• Rapor bittiğinde bildirim kanalına gider: önem derecesine göre bulgu sayıları, ilk 10 bulgu ve raporun kendisine bağlantı — tamamı kanal gövdesine gömülmez.
• Tek dosya HTML rapor (Enterprise); taramanın JSON çıktısı Community’de ücretsiz kalmaya devam ediyor.

Hazır dört kural gelir: node ve iş yükü × CPU ve bellek. Kural, varlığın kendi son 14 günlük gün-içi profiline (medyan ve medyan-mutlak-sapma, MAD) bakar; sapma en az 60 dakika kesintisiz sürerse ve node'da kendi kapasitesinin %10'unu, iş yükünde cluster kapasitesinin %1'ini aşarsa ateşler. Cluster’ın %1’inden küçük iş yükleri ve 60 dakikadan kısa sapmalar tanım gereği görülmez — bu bir eksiklik değil, aracın kendi eşiği. 7 günden az geçmişi olan bir varlık için kural hiç ateşlemez (“profil yok”).

• Bu sürümde gölge kipinde. Ateşleyen bir anomali İzleme sekmesinde görünür ve kendi rozetini taşır, ama hiçbir kanala gitmez ve üst çubuğun açık uyarı sayısına eklenmez. Amaç yöntemi canlı veriyle doğrulamak; kanala teslim ayrı bir sürümün konusu.
• Kapsam node ve iş yükünde. Ağ ve disk için bir kapasite paydası olmadığından kapsam dışı; pod da kapsam dışı — pod serisinin geçmişi en fazla 48 saat saklanır, 14 günlük bir profil için yeterli veri yok.
• Bir olayı “beklenen davranış” diye işaretleyebilirsiniz (yalnız anomali kurallarında). Bu geri alınabilir bir geri bildirim kaydıdır; profili o an değiştirmez.
• Kendi anomali kuralınızı da yazabilirsiniz — aynı daralma geçerlidir (node ya da iş yükü, iki metrik, en az 60 dakika) — ve onu canlı teslime açabilirsiniz; hazır dört kural gölgede kilitlidir.

Yönetim → Bildirimler → Hook’lar → Yeni hook ekranında Taşıma için E-posta seçilince Adres alanı kaybolur, yerine gelen Alıcılar alanına hedef yazılır. Teslim SMTP rölesinden gider ve hook’ların izin listesi hiç sorulmaz.

1. Yönetim → Bildirimler → Hook’lar ekranının altındaki SMTP sunucusu kartına sunucuyu, portu, TLS ayarını, gerekiyorsa kullanıcı adı ve parolayı, gönderen adresini ve adını girip kaydedin; hemen altındaki Deneme e-postası gönder ile röleyi sınayın. Bu kart tek kayıttır ve bütün e-posta hook’larınca paylaşılır — kaydetmek tek başına bir kanal açmaz.
2. Aynı ekranda Yeni hook: Tip için Bildirim, Taşıma için E-posta seçin, Alıcılar alanına satır başına bir adres yazın; isterseniz gövde dilini de seçin.
3. Uyarılar → Yönlendirme → Yeni yol: şiddeti, cluster’ları ve kuralları seçin, Kanallar listesinde bu hook’u işaretleyin. Yol olmadan uyarı ekranda görünür ama gönderilmez; eşleşen her yol kendi başına gönderir — iki yol eşleşirse iki e-posta gider.

• SMTP rölesi tek bir kayıttır, aynı Hook’lar ekranında bir kart olarak yaşar — cluster ya da kanal başına ayrı bir kayıt yoktur. Parola şifreli saklanır.
• Kurumun kendi iç ağındaki bir röle kullanılabilir. Yalnız loopback ve link-local adresler reddedilir; kurumsal ağ aralıkları engellenmez.
• E-posta gövdesinin dili kanal başına seçilir (Türkçe/İngilizce) — aynı kural iki farklı dildeki iki kanala aynı anda gidebilir.
• Aynı kanal operasyon bildirimlerini de taşır (plan uygulandı/reddedildi gibi): apply hatasının sebebi, hangi adımda düştüğü ve apiserver’ın verdiği yanıt gövdede kendi satırında görünür, hiçbir alan sessizce düşmez.
• ITSM entegrasyonu ayrı bir kanal değildir — var olan webhook taşımasıdır; ITSM’e bağlama aynen geçerlidir.

• Anomali olayları kanala gitmiyor. Gölge kipinde yalnız İzleme sekmesinde görünür; e-posta, webhook, sohbet ya da ITSM’e düşmesi ayrı bir sürümün konusu.
• Anomali kapsamı node ve iş yükünde. Pod için veri yok (geçmiş en fazla 48 saat saklanır), ağ ve disk için kapasite paydası yok — ikisi de hazır bir kuralla gelmiyor.
• Uyarıdan otomatik eylem yok. Bir uyarının bir operasyon planını tetiklemesi yok ve olmayacak — onay kartını ve dry-run’ı atlayan ikinci bir yazma yüzeyi açılmıyor.
• Prometheus / Alertmanager uyumu yok. Ne PromQL ile kural içe aktarma ne Alertmanager’a dışa aktarma.
• Dış çağrı, SMS ya da sesli arama yok. PagerDuty ve benzerleri webhook üzerinden bağlanır; YEKE bir çağrı sağlayıcısı olmaz.
• Nöbet takvimi (on-call rotation) yok. Yönlendirme bir kanala gider, bir kişiye değil.
• Log tabanlı uyarı yok. Ürün log akışı sunar ama log saklamaz; saklanmayan bir şey üstünde kural çalıştırılamaz.
• Olay korelasyonu / kök neden analizi yok. Bu, tarama ve teşhis ekseninin konusu.
• Kuralların GitOps ile yönetimi yok. Kural, kanal, yönlendirme, sessizlik ve bakım penceresi yalnız veritabanında yaşar.