vCenter Sensor -1 Type Alarm

ESXi 6.7 Update 3 güncellemesinden sonra bu uyarıyı alıyorsanız acilen aksiyon almanız gerekmektedir. Uyarı ilk görüşte sorun oluşturmuyor olarak ignore edilmektedir fakat ortamda bulunan host sayısı arttıkça bu uyarı çok fazla gelmekte ve ESXi host’ların hostd.log’larını rotate etmektedir. Bu durum ESXi host’da yaşanan bir sorun sonrası logları incelemenizi zorlaştıracaktır.

Logları rotate etmesinden daha kötü bir etkisi vCenter /storage/seat partition’ı doldurmasıdır. vCenter kurulumunda seçtiğiniz ortam büyüklüğüne göre bu partition’a bir boyut atanmaktadır. ESXi host’a olan event’ler ve task’lar bu partition’da toplanmakta ve defaultta 30 günde rotate olmaktadır. Çok fazla Unknown Sensor -1 alarmı bu partition’ı şişirmekte ve %95’e ulaştığında vCenter servislerini durdurmaktadır. Bu durum vCenter’ı web arayüzünden açtığınızda servisler çalışmadığından 503 Service Unavailable şeklinde görülmesine neden olmaktadır.

Gelelim sorunun çözümüne VMware tarafından bu problem adreslenmiş ve Kasım 2019’da yayınlanan ESXi670-201911001 sürümünde düzeltilmiştir. Update’i hemen uygulamanız tabikide vCenter’ın seat partition’ında yer açmayacaktır bu durumda öncelikle vCenter’ı ayağa kaldırmamız gerekiyor. Burda 2 seçenek vardır;

1. /storage/seat partition size’ı genişletmek.
2. vCenter database’inden event tablolarını truncate etmek.

İki çözümde servisleri restart ettiğinizde vCenter’ın açılmasını sağlayacaktır. Partition genişletme ile ilgili aşağıdaki makaleyi inceleyebilirsiniz. Farklı bir yazımda bu konuyu açıklayıcı bir şekilde paylaşacağım.

Increasing the disk space for the VMware vCenter Server Appliance in vSphere 6.5 and 6.7 (2145603)
https://kb.vmware.com/s/article/2145603

İkinci çözümü kullanarak seat partition’da yer açmayı seçebilirsiniz fakat bu durumda unknown sensor alarmı haricinde oluşan event ve task’ları kaybetmeyi göze almanız gerekmektedir. İşlem için aşağıdaki adımları takip edebilirsiniz.

vCenter Server’a SSH ile bağlanıp aşağıdaki komutla postgres DB’ye bağlanıyoruz.
(NOT: Komutun çalışması için postgres servisinin çalışıyor olması gerekmektedir.)

/opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres

Aşağıdaki SQL sorgusu ile en yüksek boyuta sahip 20 tabloyu listeleyebilirsiniz.

SELECT nspname || '.' || relname AS "relation", pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
               FROM pg_class C
               LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
               WHERE nspname NOT IN ('pg_catalog', 'information_schema')
               AND C.relkind <> 'i'
               AND nspname !~ '^pg_toast'
               ORDER BY pg_total_relation_size(C.oid) DESC
               LIMIT 20;

VPX_EVENT_XX ve VPX_EVENT_ARG_XX tablolarının yüksek boyutlu olanlarını truncate edebiliriz.

TRUNCATE table VPX_EVENT_XX;
TRUNCATE table VPX_EVENT_ARG_XX;

Aşağıdaki komut ile postgres db’den çıkış yapabilir ve servisleri restart edebilirsiniz.

\q 

service-control --stop --all

service-control --start --all

Son olarak çözüm için uygulamanız gereken workaround’dan bahsetmek istiyorum. Eğer ortamınız çok büyük ve update işlemini ileri bir tarihte planlamanız gerekiyorsa workaround’ı uygulayabilirsiniz. Unknown Sensor -1 alarmı anlamlandırlamayan bir hardware sensor’den gelmektedir. ESXi host’un hardware sensor’leri takip etmesini durdurarak bu alarmların gelmesini engelleyebilirsiniz.

Aşağıdaki komut ile wbem servisini kapatarak workaround’ı gerçekleştirebilirsiniz.

esxcli system wbem set --enable false

ESXi host reboot olduğunda 3rd party uygulamalar wbem servisini tekrar aktif edebilmektedir. Bu durumun önüne geçmek için watchdog servisini kapatabilirsiniz.

chkconfig sfcbd-watchdog off

Örnek ESXi Host Logları:

Hostd.log

2019-08-26T12:05:45.321Z info hostd[2221115] [Originator@6876 sub=Vimsvc.ha-eventmgr] Event 6021 : Sensor -1 type , Description Proc 1 Level-2 Cache state assert for . Part Name/Number N/A N/A Manufacturer N/A
 2019-08-26T12:05:45.321Z info hostd[2221115] [Originator@6876 sub=Vimsvc.ha-eventmgr] Event 6022 : Sensor -1 type , Description Proc 1 Level-3 Cache state assert for . Part Name/Number N/A N/A Manufacturer N/A
 2019-08-26T12:05:45.321Z info hostd[2221115] [Originator@6876 sub=Vimsvc.ha-eventmgr] Event 6023 : Sensor -1 type , Description Proc 2 Level-1 Cache state assert for . Part Name/Number N/A N/A Manufacturer N/A
 2019-08-26T12:05:45.321Z info hostd[2221115] [Originator@6876 sub=Vimsvc.ha-eventmgr] Event 6024 : Sensor -1 type , Description Proc 2 Level-2 Cache state assert for . Part Name/Number N/A N/A Manufacturer N/A
 …

Referanslar:

Excessive Hardware health alarms being triggered for “Sensor -1 type” on ESXi hosts running vSphere 6.7 U3 (74607)

https://kb.vmware.com/s/article/74607

VMware ESXi 6.7, Patch Release ESXi670-201911001

PR 2439205: You see Sensor -1 type hardware health alarms on ESXi hosts and receive excessive mail alerts
After upgrading to ESXi 6.7 Update 3, you might see Sensor -1 type hardware health alarms on ESXi hosts being triggered without an actual problem. This can result in excessive email alerts if you have configured email notifications for hardware sensor state alarms in your vCenter Server system. These mails might cause storage issues in the vCenter Server database if the Stats, Events, Alarms and Tasks (SEAT) directory goes above the 95% threshold.

This issue is resolved in this release.

https://docs.vmware.com/en/VMware-vSphere/6.7/rn/esxi670-201911001.html