[TR] VMware Operations Manager’da Notifications Listesi Boş Görünüyor ve “Alert Definition Ids not found” Hatası ve Kalıcı Çözüm (Cassandra Temizliği)

[TR] VMware Operations Manager’da Notifications Listesi Boş Görünüyor ve “Alert Definition Ids not found” Hatası ve Kalıcı Çözüm (Cassandra Temizliği)

vRealize Operations Manager (vROPS / Aria Operations) tarafında bazen “Notifications” ekranına girdiğinizde beklediğiniz gibi kayıtları görmeniz gerekirken liste tamamen boş gelebiliyor.

İlk bakışta “UI bug” gibi duruyor ama aslında genellikle arka tarafta bir Notification Rule kaydının bozulması ya da artık sistemde olmayan bir Alert Definition’a referans vermesi nedeniyle vROPS bu listeyi çekerken hata alıyor ve sonuç olarak listeyi render edemiyor.

Benim karşılaştığım senaryoda:

  • Alerts → Configuration → Notifications ekranı boştu
  • Üst kısımda çok kısa süreli (göz kırpacak kadar hızlı) bir hata belirip kayboluyordu:

Alert Definition Ids '[AlertDefinition-VMWARE-HostViolateHardeningGuide6.0]' not found.

Bu mesaj notification kuralının bir yerde AlertDefinition-VMWARE-HostViolateHardeningGuide6.0 gibi artık sistemde bulunmayan ya da isim/ID’si değişmiş bir tanıma referans verdiğini söylüyordu. Kısacası Notifications listesi aslında boş değil ekranı bozan “problemli tek bir kayıt” var ve listeyi yüklemeyi engelliyor.

Bu Neden Olur?

Bu tip durumlar genellikle şunlardan sonra görülür:

  • vROPS upgrade / patch sonrası bazı “built-in” alert tanımlarının isim/ID değişmesi
  • Paket/solution (örn. VMware / adapter) güncellemeleri
  • Eski bir notification rule’un, artık sistemde olmayan bir alert tanımına bağlı kalması
  • Nadiren: Cassandra içinde tutarsız/yarım kalmış kayıt

Bu yüzden sorun “UI’da liste yok” gibi görünse de kök sebep çoğu zaman veritabanındaki notificationplugin tablosunda bulunan bir rule kaydıdır.

İşleme Başlamadan Önce Kritik Uyarılar (Lütfen Atlamayın)

Bu çözüm doğrudan vROPS’un Cassandra veritabanına dokunur. Doğru yapıldığında güvenlidir ama yine de üretim ortamında “geri dönüş planı” şarttır.

Mutlaka yapın:

  1. Tüm vROPS node’larının snapshot’ını alın (MASTER + diğer node’lar).
  2. İşlemi mümkünse bakım penceresinde uygulayın.
  3. Ne sildiğinizi kesin olarak doğrulayın (ID’yi yanlış alırsanız başka bir rule’u uçurabilirsiniz).

Snapshot alma adımı benim senaryomda VMware Support’un ilk söylediği şeydi. Kesinlikle unutmayın.

Adım Adım Çözüm

Adım A – MASTER Node’a SSH ile Bağlanınız

vROPS cluster kullanıyorsanız işlemleri MASTER node üzerinde yapmanız gerekir.

Adım B – Notification Kayıtlarını Cassandra’dan Dışarı Alın

Sistemde kayıtlı tüm notification rule’ları listeleyip hataya sebep olan rule’un identifier bilgisini bulmak.

Aşağıdaki komut notificationplugin tablosunu okuyup çıktıyı dosyaya yazar;

$VMWARE_PYTHON_BIN $ALIVE_BASE/cassandra/apache-cassandra-*/bin/cqlsh.py --ssl --cqlshrc $ALIVE_BASE/user/conf/cassandra/cqlshrc -e 'PAGING OFF; SELECT * from globalpersistence.notificationplugin' > /tmp/notifications.txt

/tmp/notifications.txt bu dosyayı WinSCP ile bilgisayara kopyalayıp Notepad++ ile açmak işinizi çok kolaylaştırır.

Adım C – Problemli Rule ID’sini Bulunuz

Dosya içinde genellikle şunları aramak işe yarar:

  • NotificationRule.
  • ya da hata mesajındaki alert tanımı ismini (örneğin HostViolateHardeningGuide)

Benim bulduğum örnek rule anahtarı şuydu:

NotificationRule.c837603b-139e-42a0-8cca-20c10d001b78

Buradaki kritik kısım:
NotificationRule.<GUID>

Bu GUID’yi bir sonraki adımda kullanacağız.

İlk Deneme olarak API Üzerinden Silme (Her Zaman Çalışmayabilir)

Normalde en temiz yöntem API üzerinden silmektir. Fakat bu vakada API delete işlemi başarısız oldu. Yine de süreç şöyle;

Adım D – Basic Auth Aktif Edin (Gerekiyorsa)

VMware KB: 77271
api-conf.properties dosyasını düzenleyiniz.

vi /usr/lib/vmware-vcops/user/conf/api-conf.properties

Aşağıdakini bulunuz.

basicAuthentication.enabled=false




Şöyle değiştiriniz.

basicAuthentication.enabled=true




Sonra API servisini yeniden başlatınız.

service api restart




Adım E – Notification Rule’u API ile Silmeyi Deneyiniz.

curl -v -X DELETE -k --user admin \
  https://IPADDRESS/suite-api/api/notifications/rules/NotificationRule.c837603b-139e-42a0-8cca-20c10d001b78




Benim senaryomda bu komut başarısız oldu (her ortamda farklı hata dönebilir). Bu noktada Cassandra ile manuel silme yöntemine geçtim.

Kesin Çözüm Cassandra Üzerinden Rule’u Silmek

Adım F – Cassandra CLI Açınız

$VMWARE_PYTHON_BIN $ALIVE_BASE/cassandra/apache-cassandra-*/bin/cqlsh \
  --ssl --cqlshrc $ALIVE_BASE/user/conf/cassandra/cqlshrc




Adım G – Doğru Kaydı Sildiğinizden Emin Olunuz (Önerilir)

Silmeden önce, hedef kaydı gerçekten görmek isterseniz şu tip bir kontrol sorgusu mantıklıdır:

  • Not: Cassandra’da key alanı birebir eşleşmeli. Bazı ortamlarda sütun isimleri farklı olabilir; elinizdeki dump formatına göre uyarlarsınız.
  • Eğer dump içinde key tam netse direkt DELETE’e geçebilirsiniz.

Adım H – Rule Kaydını Silin

Aşağıdaki sorguda sadece GUID kısmını değil NotificationRule.… anahtarını komple giriyoruz;

DELETE from globalpersistence.notificationplugin
where namespace='notificationplugin'
and classtype='notificationplugin'
and key='NotificationRule.c837603b-139e-42a0-8cca-20c10d001b78';




Bu işlem problemli rule’u kaldırır.

Son Kontroller (UI ve Sistem Doğrulama)

Silme işleminden sonra:

  1. vROPS UI’a tekrar girin
  2. Alerts → Configuration → Notifications sayfasını açın
  3. Liste normal şekilde doluyorsa sorun çözülmüştür.

Ek olarak şunları da kontrol etmek iyi olur;

  • Notification rule sayısı beklediğiniz gibi mi?
  • Yeni rule ekleyebiliyor musunuz?
  • Hata mesajı tekrar çıkıyor mu?

Bu yöntemde sadece tek bir notification rule silinir. Yani

  • Bildirim kanallarınızın tamamı gitmez,
  • Sadece bozuk/uyumsuz rule kaydı kaldırılmış olur,
  • Eğer o rule önemliyse daha sonra UI üzerinden yeniden oluşturabilirsiniz,