Sistem Sağlığı

Yönetim → Sistem Sağlığı → Genel Bakış, kurulumun kendisi hakkında bildiklerini tek sayfada gösterir: sağlık denetimleri, sürüm ve çalışma süresi, inSCADA süreci ve üzerinde çalıştığı makine, son 24 saatin kaynak geçmişi, sertifika ve lisansın kalan günleri, küme, bağlı olmayan bağlantılar, script’ler, işler, en sık tekrarlanan hatalar ve destek için tanılama dosyaları.

Bir durum ekranıdır, ayar değil: hiçbir şeyi değiştirmez. Sayfa kendiliğinden yenilenmez; her okuma sunucuda tüm sağlık denetimlerini çalıştırdığı için yalnızca açıldığında ve Yeniden Yükle ile okunur. Sağ üstte Son denetim zamanı yazar.

Kümede her düğüm kendisi için cevap verir

Sayfa, isteği yanıtlayan düğümü gösterir; kartların başında düğümün adı yazar. Diğer düğümün JVM’i, makinesi ve denetimleri kendi adresinden açıldığında görünür.

Kim açabilir

Yetki	Ne sağlar
VIEW_SYSTEM_HEALTH	Sayfanın kendisi. Bildirim e-postaları da bu yetkiyi taşıyan hesaplara gider.
VIEW_SYSTEM_DIAGNOSTICS	Tanılama kartı: sunucu logu, thread dump, destek paketi.

İkisi de kurulum genelindedir ve varsayılan alanın yönetici rolünde bulunur; tek süreç, tek JVM, tek sertifika ve tek lisans her alan için cevap verdiğinden bu, kurulumun görünümüdür. Bir kiracı alanının yöneticisi bu yetkileri taşımaz; kendi alanının durumunu zaten gördüğü yerlerde görür (İş İzleyici, bağlantı durum ekranları).

Tanılama ayrı bir yetkidir, çünkü sunucu logu her alanın satırlarını, hesap adlarını, cihaz adreslerini taşır; VIEW_SYSTEM_HEALTH tek başına onu açmaz.

Durum ve “Çalışır durumda olmayan denetimler”

Sayfanın üstünde kurulumun genel durumu ve, iyi değilse, Çalışır durumda olmayan denetimler: listesi durur. Durumlar en kötüden iyiye:

Durum	Anlamı
Çalışmıyor	Bir denetim başarısız: bir veri deposu yanıt vermiyor, disk fiilen dolu, lisans geçersiz… Dış izlemede HTTP 503.
Hizmet dışı	Bir denetim kendini hizmet dışı bildiriyor. Dış izlemede HTTP 503.
Uyarı	Bir şey bozulmaya gidiyor, ama sistem çalışıyor. Dış izlemede yine HTTP 200.
Çalışıyor	Her şey yolunda.
Bilinmiyor	Denetimin okuyacağı bir değer yok (henüz ölçülmedi, bu platformda raporlanmıyor, yapılandırılmamış). Genel durumu değiştirmez ve e-posta göndermez.

Genel durum, denetimlerin en kötüsüdür. Bağlantılar, İşler, Script’ler, kaynak geçmişi ve en sık hatalar genel durumu değiştirmez: onlar gösterilir, yargılanmaz.

Bildirimler

Durumun altındaki satır, sağlık değişikliklerinin e-postayla gidip gidemeyeceğini söyler:

• “Sağlık değişiklikleri N adrese e-postayla gönderiliyor.”
• “Bildirimler gönderilemiyor: uygulama e-postası yapılandırılmamış.” — Uygulama E-postası ayarlarını aç bağlantısıyla.
• “Bildirimler gönderilemiyor: Sistem Sağlığı erişimi olan hiç kimsenin e-posta adresi yok.”
• E-posta adresi olmayan hesaplar sayılır: “Sistem Sağlığı erişimi olan N hesabın e-posta adresi yok; bu hesaplara bildirim gitmiyor.”

Ne zaman ve neyin gönderildiği aşağıda: E-posta bildirimleri.

Sağlık denetimleri

Denetimler, neyi izlediklerine göre gruplanmış kutucuklar olarak gösterilir; her biri durumunu ve en çok şey söyleyen tek ayrıntısını taşır, Ayrıntıları göster gerisini açar.

Grup	Denetim	Uyarı	Çalışmıyor
Altyapı	Veritabanı (konfigürasyon) — PostgreSQL, bu düğümün kullandığı haliyle	—	3 saniyede yanıt yok, bağlantı hatası, bağlantı havuzu tükendi ya da 60 saniyedir hiç denetlenemedi
	Redis (canlı değerler) — canlı değerler, oturumlar, alarm durumu; kümede liderlik kaydı	—	Aynı kural
	InfluxDB (kayıtlı değerler) — kaydedilen değerler	—	Aynı kural. Yanlış bir parola ya da eksik veritabanı burada değil, InfluxDB yazma kaybında görünür.
Makine	Disk alanı	—	Boş alan Disk dolu eşiğinin (varsayılan 5 GB) altında: PostgreSQL, InfluxDB ve log yazamamak üzere
	Boş disk alanı	Boş alan diskin %10’unun altında	Hiçbir zaman
	Makinede kullanılan bellek	15 dakika boyunca her ölçümde %90’ın üstünde	Hiçbir zaman
	Makine CPU’su	15 dakika boyunca her ölçümde %90’ın üstünde	Hiçbir zaman
Güvenlik	TLS sertifikaları	—	Sunulan sertifika geçersiz (süresi dolmuş ya da henüz geçerli değil)
	Proxy güvenliği	—	Ters vekil kipinde, ama sunucu iletilen başlıkları okumuyor
	LDAP bağlantısı (LDAP açıkken)	—	Dizin yanıt vermiyor; yapılandırılmamışsa Bilinmiyor
	Lisans	—	Lisans geçersiz ya da süresi dolmuş
Küme (kümede)	Küme	Bir Sentinel ya da hakem yanıt vermiyor	Lider yok
	Küme replikasyonu	Hiçbir şey gönderilmiyor ya da yedek uzun süredir yok	Bir kayıt kalıcı olarak gönderilemedi
İş parçacığı havuzları	İşlerin iş parçacığı havuzu, Script’lerin iş parçacığı havuzu	Havuz %80 dolu	Havuz %95 dolu ya da kapanıyor
Veri	InfluxDB yazma kaybı	Kayıtlı değerler InfluxDB’ye ulaşmadan düşürüldü	—
Web sunucusu	HTTP portları — uygulamanın kendi portları, 30 saniyede bir içeriden denenir. Cihaz bağlantılarına bakmaz.	Ana port dışındaki bir port (örneğin sandbox) yanıt vermiyor	Ana port yanıt vermiyor

Bu listede adı geçmeyen bir denetim — bir kurulumun eklediği — Diğer altında görünür.

Makinenin erken uyarıları

Boş disk alanı, Makinede kullanılan bellek ve Makine CPU’su bir sıkıntının gelmekte olduğunu, hâlâ önlem alınabilecekken söyler. Yalnızca Uyarı verirler, asla Çalışmıyor değil: e-posta gider, ama trafiği yanıt koduna göre yönlendiren hiçbir şey düğümü devreden çıkarmaz. Bellek ve CPU için “sürekli” her ölçüm demektir: pencere içindeki tek bir düşük ölçüm uyarıyı geri tutar, ve pencere dolmadan — örneğin açılıştan 10 dakika sonra — uyarı verilmez.

Eşikler ve pencere Sunucu Ayarları → Genel → Sistem Sağlığı altındadır ve bir sonraki yeniden başlatmada devreye girer. 50 GB’tan küçük bir diskte 5 GB’lık Disk dolu eşiği %10’luk uyarıdan önce gelir; küçük bir kurulumda eşiği düşürün.

Bu düğüm ve JVM

Bu düğüm kartı: Düğüm, Sürüm, Derleme zamanı, Başlama zamanı, Çalışma süresi.

JVM (inSCADA süreci) kartı yalnızca inSCADA sürecini gösterir: Heap (kullanılan / en çok), Ayrılan heap, Heap dışı kullanım, İş parçacıkları (canlı · en yüksek · daemon), İşlemciler, Yük ortalaması (1 dk) (Windows’ta yok) ve Java sürümü. Tek bir anlık okumadır; zaman içindeki değişimi Kaynak geçmişi gösterir.

Makine

Makine kartı, düğümün çalıştığı bilgisayarın tamamıdır — üzerindeki her programla, veritabanları da dahil. PostgreSQL, InfluxDB ve Redis çoğunlukla aynı makinededir ve onların tükettiği bellek ya da CPU JVM kartında görünmez.

Alan	Açıklama
Makine CPU’su	Makinenin tüm işlemcileri üzerinden yük, son bir dakikalık ölçüm aralığında.
Makinede kullanılan bellek	Toplamdan kullanılabilir belleğin düşülmesi. Linux’ta çekirdeğin kendi “kullanılabilir” tahmini okunur, sayfa önbelleği dahil — bu yüzden sağlıklı bir sunucu “boş belleği sıfıra yakın” görünmez.
Kullanılan swap	Swap’i olmayan makinede “Bu makinede swap yok”. Windows’ta raporlanmaz.
Disk (veri ve log’lar)	Disk alanı denetiminin izlediği diskin boş alanı.

Okunamayan bir değer sıfır olarak değil, nedeniyle gösterilir (“Bu platformda raporlanmıyor.”, “Henüz ölçülmedi: ilk okuma açılıştan yaklaşık iki dakika sonra gelir.”). Konteyner içinde değerler konteynerin limitleridir, sunucunun değil; veritabanları kendi konteynerlerindeyse onların tüketimi buradan görünmez.

Kaynak geçmişi (son 24 saat)

Anlık bir okuma bir sızıntıyı gösteremez. Bu yüzden her düğüm kendini dakikada bir ölçer ve son 24 saati belleğinde tutar; sayfa her seriyi eğrisiyle ve Son 1 saat ile Son 24 saat’teki saatlik değişimiyle (/sa) gösterir.

Grup	Seri	Sürekli artış ne demek
inSCADA süreci (JVM)	GC sonrası heap	Bellek sızıntısı: her toplamadan sonra tutulu kalan bellek büyüyor
	Metaspace, Yüklü sınıflar	Sınıf sızıntısı
	Kod önbelleği	Derlenmiş (JIT) kod alanı doluyor
	İş parçacığı sayısı	İş parçacığı sızıntısı
	inSCADA süreci CPU’su	Yüksek kalıyorsa işlemcileri inSCADA meşgul ediyor
	GC’de geçen süre	Bellek baskısı
	Veritabanı / Redis / InfluxDB yanıt süresi	Veri deposu yavaşlıyor
Makine	Makine CPU’su	Yüksek kalıyorsa makine meşgul — inSCADA ya da bir veritabanı
	Makinede kullanılan bellek	Makinedeki bir şey giderek daha fazla bellek alıyor
	Kullanılan swap	Bellek yetmiyor, diske taşınıyor
	Boş disk alanı (veri ve log’lar)	Düşüş: log ya da veri diski dolduruyor

Değişim, penceredeki tüm ölçümlere uydurulan eğimdir; tek bir ölçüm sonucu belirlemez. Pencerenin en az yarısını kapsayacak kadar veri yoksa “Henüz yeterli veri yok” yazar. Eğriler gösterilir, yargılanmaz: makine belleği ve CPU uyarıları dışında hiçbir seri uyarı ya da e-posta üretmez.

Yeniden başlatma geçmişi siler

Geçmiş bellektedir ve yeniden başlatma onu boşaltır — oysa bir sızıntı çoğunlukla tam da yeniden başlatmayla biter. Bu yüzden her beş dakikada bir, son ölçüm sunucu loguna tek bir JVM trend: satırı olarak da yazılır; 30 günlük log, yeniden başlatmadan sonra da “ne zamandan beri artıyor” sorusunu cevaplar.

Sertifika ve lisans

Sertifika kartı sunucunun sunduğu sertifikanın adını, Geçerlilik sonu’nu ve kalan günleri gösterir; 30 günden az kalınca turuncu, süresi dolunca kırmızıdır. Sunucu kendi TLS’ini sunmuyorsa (bir proxy’nin arkasında) bunu söyler; o durumda proxy’nin sertifikası Sunucu Ayarları’ndaki Sertifika kartındadır (Sunucu Ayarları’nı aç).

Lisans kartı Tip, Geçerlilik sonu ve kalan günleri gösterir; 30 günden az kalınca turuncu, 7 günden az kalınca kırmızıdır. Süresiz bir lisans Süresiz yazar.

Küme

Tek sunucuda “Bu düğüm tek başına çalışıyor.” Kümede: bu düğümün rolü (Lider / Yedek), Aktif sunucu, Düğümler ve görünmeyen beklenen düğümler (”… süredir yok”), Replikasyon gecikmesi, Başarısız kayıtlar, Çakışmalar. Replikasyonun ayrıntısı Sistem Sağlığı → Replikasyon Tutarlılığı’ndadır (Replikasyon Tutarlılığı’nı aç).

Bağlantılar

Bir operatörün başlattığı ve durdurmadığı bağlantılar — tüm alanlarda: Başlatılmış, Bağlı, Bağlı değil. Bağlı olmayanlar alan, proje ve adla listelenir; Durum sütunu:

Durum	Anlamı
Başlatılamadı	Başlatma başarısız oldu; artan aralıklarla, en sık dakikada bir yeniden denenir.
Bağlanıyor	Başlatma sürüyor ya da cihaza ilk erişim denemesi henüz bitmedi.
Bağlantı kopuk	Bağlantı çalışıyor ama cihazla bağı kopuk.

“Ne zamandan beri” bilgisi yoktur; ürün bir bağın ne zaman koptuğunu tutmaz.

Başlatılmış bağlantıların son yeniden başlatılması, servis açıldığında (ya da kümede liderlik alındığında) başlatılmış bağlantıların yeniden başlatılmasının sonucunu gösterir: Tetikleyen (Açılışta / Liderlik alınınca), Bitiş zamanı ve Sonuç (kaç tanesi yeniden başlatıldı, başarısız oldu, atlandı, çözülemedi). Bu hâlâ sürüyorsa sayfa, bazı bağlantıların henüz başlatılmamış olabileceğini söyler.

Script’ler (son 24 saat)

Bu düğümde script çalışmalarının nasıl bittiği: Çalıştırma, Başarısız çalıştırma — içinde Zaman aşımı (Script süre sınırı durdurdu), Reddedilen (havuz dolu) ve Komut sınırı aşıldı —, Başarısız olan script’ler ve En çok başarısız olan script’ler (en çok 5, Son başarısızlık ile). Kaydedilmiş script’ler, ekranlardan gelen callApi çağrıları, veri bloğu ifadeleri, rapor veri kaynakları hepsi sayılır; hata ayıklama oturumları sayılmaz.

Şu an hata veren bölümü, bağlantılarda şu anda başarısız olan ifadeleri adıyla listeler: Değer ifadeleri, Log ifadeleri ve bütün olarak başarısız olan Veri bloğu script’leri — Bağlantı, Mesaj ve Hata başlangıcı ile. Bir veri bloğu script’i çalıştığı halde içindeki tek bir değişkenin ifadesi başarısız oluyorsa, bunun göründüğü tek yer burasıdır: değişken son değerini korur ve alarm oluşmaz.

Sayılar bu düğümün belleğindedir; yeniden başlatma sayımı baştan başlatır. Kümede script’lerin neredeyse tamamı liderde çalışır.

İşler

Bu düğümde planlanmış işlerin tazeliği, her projede birden. Üç sekme — bir iş birden fazlasında olabilir:

Sekme	Ne zaman
Hata veriyor	Son çalışan çalıştırması başarısız oldu ve o zamandan beri başarılı olmadı.
Atlayan	Son 24 saatte bir tetiklemeyi atladı: önceki çalıştırma hâlâ sürüyordu ya da iş havuzu doluydu. Atlama bir hata değildir — yavaş bir iş bozuk bir iş değildir. Atlanan ve Atlanan % iş bu düğümde planlandığından beri sayılır.
Bayat	Periyodik ya da sabit gecikmeli bir iş 10 periyottan (en az 5 dakika) uzun süredir başarılı çalışmadı. Asılı kalan ve hiç bitmeyen bir çalıştırma ne başarı ne hata yazar; bu etiket tam olarak onu yakalar. Günlük, aylık ve tek seferlik işler için bayat kararı verilmez.

Sütunlar İş İzleyici ile aynı sayıları kullanır (Son başarı, Son hata, Bayat olduğu an…).

Yedek düğümde

Bağlantılar, işler ve ifadeler yalnızca liderde çalışır. Kümede yedek düğüm bu bölümlerde boş bir liste yerine “Bu düğüm yedek: … burada değil, aktif sunucuda çalışır.” der; boş liste “sorun yok” diye okunurdu.

Hatalar ve tanılama

En sık tekrarlanan hatalar (son 24 saat)

Olay günlüğünde — Günlük ekranının gösterdiği — son 24 saatte en çok tekrarlanan on hata, tüm alanlarda. Mesajları yalnızca sayılarda, tırnak içindeki değerlerde ya da kimliklerde farklı olan satırlar birlikte sayılır (Desen); her grup Sayı (en az), İlk görülme, Son görülme, kaç alanda göründüğü ve en yeni örnek satırıyla gösterilir. Sayılar alt sınırdır. Sonuç bir dakika boyunca saklanır.

Tanılama

Bir arızanın kanıtını, sorun hâlâ sürerken uygulamadan almak için (VIEW_SYSTEM_DIAGNOSTICS gerekir):

• Sunucu logu — sunucunun kendi log dosyasının (inscada.log) son satırları (Satır sayısı seçilir). Bu, Log ekranındaki proje olay günlüğü değildir.
• Log dosyaları — güncel dosya ve döndürülmüş parçalar, boyut ve son değişiklik zamanıyla; her biri İndir ile.
• Thread dump indir — JVM’deki her iş parçacığının o anki durumu.
• Destek paketini indir — destek ekibine gönderilecek tek bir zip: Sistem Sağlığı raporu, kaynak geçmişi, en sık hatalar, düğümün etkin yapılandırması (gizli değerler maskelenmiş), bir thread dump ve son 24 saatin sunucu logları (en çok 100 MB). Daha eski log dosyaları listeden tek tek indirilir.

Yeniden başlatmadan önce alın

Yeniden başlatma, bir thread dump’ın göstereceği iş parçacıklarını sonlandırır. Bir donma ya da yavaşlamada önce thread dump’ı ya da destek paketini indirin, sonra yeniden başlatın.

Kümede her düğümün logları ve thread dump’ı o düğümün kendi adresinden alınır. Her indirme sunucu loguna kimin neyi indirdiğini yazan bir satır bırakır.

E-posta bildirimleri

Kimse ekranı bütün gün izlemez. Bu yüzden her düğüm kendini dakikada bir değerlendirir ve bir şey değiştiğinde yöneticilere e-posta gönderir.

Kime ve neyle:

• Yalnızca e-postayla, kurulumun Uygulama E-postası hesabı üzerinden (Ayarlar → Giriş → Uygulama E-postası). Bir alanın kendi e-posta ayarları ya da SMS kullanılmaz.
• VIEW_SYSTEM_HEALTH yetkisini taşıyan etkin hesaplara — pratikte varsayılan alanın yöneticileri ve rolleri bu yetkiyi veren herkes. E-posta adresi olmayan hesap sayılır ama yazılmaz; aynı adresi paylaşan iki hesap tek e-posta alır.
• Uygulama e-postası yapılandırılmamışsa ya da kimsenin adresi yoksa hiçbir şey gönderilmez ve hiçbir şey kuyruğa alınmaz; o arada olan bir değişiklik sonradan gönderilmez. Sayfanın üstündeki bildirim satırı bunu söyler.

Ne gönderilir:

Olay	Kural
Çalışır durumda olmayan denetimler değişir — bir denetim Uyarı, Çalışmıyor ya da Hizmet dışı olur, bunlar arasında geçer ya da düzelir	Yeni durum 5 dakika sürdükten sonra, her denetim kendi saatiyle. 5 dakika içinde geri dönen bir değişiklik hiçbir şey göndermez. Genel durum zaten Çalışmıyor’ken ikinci bir denetimin düşmesi de, birinin düzelmesi de ayrıca gönderilir; hiçbir sorun kalmayınca “her şey düzeldi” e-postası gider.
Sunulan sertifikanın kalan günü 30, 7 ve 1’e iner	Her eşik için bir kez; yeniden başlatma aynısını tekrar göndermez, yenilenen sertifika baştan başlar.
Bir küme düğümü görünmez olur ve geri gelir	5 dakika sürünce; yalnızca lider gönderir, böylece üç düğümlü bir küme bir kaybı iki kez bildirmez.
İşler bayatlar ve düzelir	Tek e-postada, en çok 20’şer iş ve gerçek sayıyla — 200 cihaz sorgusunu bayatlatan bir kesinti tek e-posta gönderir.

Bilinmiyor gönderilmez. Her tür e-postadan 10 dakikada en çok bir gider; bekletilen bir değişiklik kaybolmaz, bir sonraki değerlendirme o anki durumu son gönderilenle karşılaştırır. Sürekli bir yük, başladıktan yaklaşık 20 dakika sonra bildirilir (uyarı için 15, oturması için 5).

E-postanın konusu genel durumu ve düğümü taşır; gövdesi neyin ne zamandan beri değiştiğini (tesis saat diliminde) listeler. Uygulama adresi dışarıdan erişilebilir bir adres olarak ayarlıysa e-posta kurulumu ve Sistem Sağlığı’na bir bağlantıyı da içerir. Dil kurulumun dilidir, yoksa İngilizce. Ayrıntı, yığın izi ya da gizli değer içermez.

Dışarıdan izleme

Bu sayfa ve e-postalar, raporladığı sürecin içinde çalışır. Üç arızayı raporlayamaz, çünkü raporlayan da onlarla birlikte gider:

• Ölüm — kapanan bir süreç e-posta göndermez. Windows servis yöneticisi onu yeniden başlatır, ama her açılışta çöken bir düğüm döngüye girer ve bunu kimse söylemez.
• Donma — yanıt vermeyen ama kapanmamış bir JVM’i servis yöneticisi yeniden başlatmaz; bildirim iş parçacığı da diğerleri kadar takılıdır.
• Ağ kaybı — sağlıklı ama operatörlerin bulunduğu yerden ya da e-posta sunucusuna ulaşılamayan bir düğüm her iki durumda da sessizdir.

Bu yüzden ürünün dışındaki bir izleme aracının (PRTG, Zabbix, Uptime Kuma, herhangi bir HTTP izleyici) düğümü düzenli olarak sorması gerekir. Her düğümü doğrudan yoklayın (varsayılan https://<düğüm>:8082), kullanıcıların proxy üzerinden ulaştığı adresi değil: kümede proxy her şeyi tek düğüme gönderir, haberini alamayacağınız diğeridir.

/actuator/health/readiness — erişilebilirlik

Asıl yoklama budur; HTTP durum kodu kararın kendisidir:

Durum	HTTP	Gövde (kimlik bilgisi olmadan)
Sağlıklı	200	{"status":"UP"}
Bozulmuş: bir denetim Uyarı’da, hiçbiri çalışmıyor değil	200	{"status":"WARNING"}
Bir denetim Çalışmıyor ya da Hizmet dışı	503	{"status":"DOWN"} (ya da OUT_OF_SERVICE)
Ölü, donmuş, ulaşılamıyor	yok — bağlantı reddedilir ya da zaman aşımı	—

Uyarı bilinçli olarak 200 döner: yalnızca durum koduna bakan bir izleyici bozulmuş bir düğümü ayakta sayar. PostgreSQL, Redis ve InfluxDB’nin her biri kritiktir: biri Çalışmıyor olunca readiness 503 döner.

/actuator/health — ikinci, daha yumuşak izleyici

Ham sağlık, readiness’ın bilinçli olarak geçirdiğini de yakalar: herhangi bir Uyarı ve kümede replikasyon kaybı. Gövdesi "status":"UP" değilse daha düşük bir önem derecesiyle alarm verin. Kümede erişilebilirlik ya da yük dengeleme için ham sağlığı kullanmayın: Küme replikasyonu tek bir kayıt yüzünden Çalışmıyor olduğunda ham sağlık 503 döner, oysa düğüm tesise sorunsuz hizmet vermektedir; readiness bu denetimi içermez.

Kümede /actuator/leader aktif düğümü söyler (liderde 200, yedekte 503). Alarm gerektiren, hiçbir düğümün 200 vermemesidir; proxy önündeyse tesisin adresini üçüncü bir izleyiciyle de yoklayın.

Kimlik bilgisi

/actuator/health, /actuator/health/readiness ve /actuator/leader kimlik bilgisi olmadan okunur ve yalnızca durum satırını döner. İzleme kullanıcısı ve İzleme parolası (Sunucu Ayarları → Genel) ile her denetimin durumu ve ayrıntısı da gelir — alarm metnine başarısız denetimin adını koymak için. Bedeli: yanlış parola taşıyan bir istek sağlık yoklamasında bile reddedilir (401); düğümde değiştirilip izleyicide değiştirilmeyen bir parola kesinti gibi okunur. Bir izleyicinin kimlik bilgisine ihtiyacı yoktur.

Önerilen ayarlar

	Erişilebilirlik (readiness)	Bozulma (ham sağlık)	Proxy üzerinden (küme)
Aralık	60 sn	5 dk	60 sn
Zaman aşımı	30 sn	30 sn	30 sn
Alarm	Art arda 3 başarısızlık	Art arda 3 başarısızlık	Art arda 3 başarısızlık
Beklenen	HTTP 200	HTTP 200 ve gövdede "status":"UP"	HTTP 200

Üç dakika bir yeniden başlatmayı ve uzun bir duraklamayı kimseyi uyandırmadan atlatır, ama bir operatör donmuş bir ekranı fark etmeden çok önce “çalışmıyor” der. Zaman aşımı bilinçli olarak geniştir: eşi ya da dizini sessizleşen bir düğüm geç ama kararıyla yanıt verir, 10 saniyelik bir zaman aşımı bunu yanlış bir “ulaşılamıyor”a çevirirdi.

Düğümün sertifikası çoğunlukla kurulumun kendi sertifikasıdır (kendinden imzalı ya da özel bir CA’dan). İzleyiciye o CA’yı verin ya da bu izleyicilerde sertifika doğrulamasını kapatın; sertifikanın süresi ürün tarafından e-postayla bildirilir.

İzleyicinin bildirimini başka bir yere yönlendirin

Her izleyicinin bildirimini izlediği sunucudan başka birine gönderin: düğümün kendi e-posta sunucusu üzerinden giden bir e-posta, ölü bir düğümün yapamayacağı tek şeydir.

İlgili

• Sunucu Ayarları — Sistem Sağlığı eşikleri, izleme kullanıcısı, sertifika
• Uygulama E-postası — bildirimlerin gönderildiği hesap
• İş İzleyici — işlerin sayıları, alan bazında
• Günlük — proje olay günlüğü
• Yedekli Mimari — küme ve yük dengeleyicinin ne yokladığı