Merhabalar,

Merhabalar,

Gönderdiğiniz listeyi göz önünde bulundurararak FM kayıtlarına neden clear talebi açıldığına yönelik bir
liste çıkarttım.

1.Cloud katmanında
1.1.Alert Key: alarm.DatastoreDiskUsageAlarm - Datastore doluluğu alarmın treshold değerini aştığı
zaman tarafımıza alarm düşüyor. Datastore clusterında doluluk dengelendiği zaman alarm kendiliğinde
kapanıyor fakat çoğunlukta değil.
1.2.Alert Key: alarm.HostConnectionStateAlarm Summary: Host not responding - Host kapandığı zaman
tarafımıza alarm düşüyor.Host açıldığı durumda ise bu alarm kendiliğinden clear olmayabiliyor.Olmadığı
durumlarda clear talebi açıyoruz.
1.3.Alert Key: Host connection and power state - Hostlarda networksel olarak anlık kesinti yaşandığı
zaman bu alarm tarafımıza düşüyor.Sorun düzeldiği zaman alarm kendiliğinden clear olmuyor.
Summary:Host connection and power state - State is equal to Not responding OR State is equal to Not
responding
1.4.Alert Key :Host connection and power state - Host connected duruma geçtiği zaman alarm üretiyor.
Bu durumda alarmın clear edilmesi için clear talebi açıyoruz.
Summary:Host connection and power state - State is equal to Connected OR State is equal to
Connected

2.Retired edilen sunucular - Sunucu retired edildiği zaman bu sunucuya bağlı olan tüm katmanlardan
alarm geliyor.Bu sunuculardan gelen alarmlar kapanmadığı için SMOC ekibine clear talebi açıyoruz.
2.1.Windows - Retired edilen sunucunun down alarmı
2.2.Backup - Retired edilen sunucuya tanımlı backup policylerin alarmları
2.3.Database - Retired edilen sunucu üzerinde çalışan SQLServer service is unavailable alarmı

3.Backup katmanında
3.1."BP_EXCH_ESN_dagvftr_D" policy için backup başarılı tamamlandığında alarm kendiliğinden clear
olmuyor.Bu policy özelinde backup başarılı alındığında SMOC ekibine clear talebi açıyoruz.
3.2. Test amaçlı oluşturulan policylerden gelen alarmlar için clear talebi açılıyor.Örn: testforsap,
Test_gto, TEST_MONGODB_DXL, MONGO_DB_TEST, TEST_EHM_TEST, TEST_mongodb,
TEST_backuptest1_SQL, test_uni-msgsqldd1.backup.testvftr.local_test gibi test amaçlı oluşturulan
policyler için clear talebi açmaktayız.
3.3. Backup tanımı kaldırılan sunucuların tanımlı olduğu policylerden gelen alarmlar policy deactivate
edildikten sonra clear talebi açılıyor.
3.4. Main jobı olmayan policyler clear olmamaktadır. Örn:"VM_ESN_VFTR_esenyurtvc01_D" main job'ı
olmadığı için başarılı backup alındığında clear olmamaktadır
3.5. HPE StoreOnce'tan gelen alarmlar kendiliğinden clear olmadığı için gerekli kontroller yapılıp Uğur
Günder'in bilgisi ve onayı dahilinde clear talebi açılmaktadır.
3.6. Gönderdiğiniz listede Nodealiasta “Day Time Backup” olarak tanımlı 600 adet alarm backup’ın
başladığına dair gelen alarmlardı.Günlük ortalama 50-60 adet backup başladığına dair running alarmı
gelmekteydi. Bu alarmlar kendiliğinden kapanmıyordu, bu sebepten SMOC ekibine clear talebi
açmaktaydık.Bu alarmlar artık gelmiyor.Geçen sene Eylül ayında bu sorun Gökhan Bey ile çözüldü.
3.7.
4.Windows katmanında kendiliğiden clear olmayan bir alarm bulunmuyor.
4.1.Defender projesi kapsamında sunuculardan Symantec ajanları IT IO Winos ekibi tarafından
kaldırılmıştı.Zabbix konfigurasyonu sağlanıncaya kadar bu sunuculardan birçok 'SEPMaster Service is not
running' alarmları düştü.Bu alarmları IT IO Winos ekibinin bilgisi dahilinde SMOC ekibine clear ettirdik.
Şuan zabbix konfigurasyonu sağlandı ve artık alarm düşmüyor.

5.Oracle Database katmanında

5.1.Alert Key: problemTbspUndo:pctUsed - Databaselerden Tablespace [UNDOTBS2] alarmları için
herhangi bir aksiyon alınmıyor.Bu alarmlar düştüğü zaman clear talebi açıyoruz.
5.2.Alert Key: ME$dataguard_open_mode:sayi - Standby database read-only modeda olmadığı
durumlarda geliyor. Örneğin : Standby tarafı bir çalışma sonrası mount mode bırakılabiliyor.Bu durumda
tarafımıza alarm düşüyor. Standby tarafı Read-only'e çektikten sonra çoğu alarm kapanmıyor.
Kendiliğinden kapananlar var fakat çoğunlukta değil.
5.3.Alert Key: ME$asm_pct:value Data Diski doluluğu - Data diskine servis ekibi tarafından yeterli disk
eklendiğinde alarmın treshold değerinin üzerine çıkamadığı durumlarda clear talebi açıyoruz.Alarmın
treshold değerini aşabilmesi için yüksek derece disk eklenmesi gerekiyor.Örneğin 1 TB disk eklenmesi
yeterli olacak fakat tresholda erişebilmesi için 15 TB disk eklenmesi gerekiyor.
5.4.Alert Key: ME$tablespace_percentage:value - Yeterli tablespace eklendiğinde alarmın treshold
değerinin üzerine çıkamadığı durumlarda clear talebi açıyoruz.Data disk doluluk sorunu ile aynı
problemden kaynaklı olarak alarmın treshold değeri kadar tablespace eklenmesi ihtiyaç dışı kalıyor.
5.5.Goldengate alarmları bazında,
a) Ortamdan kaldırılan extract veya replicattan gelen alarmlar için clear talebi açılmaktadır.
b) Daha önce izleme sistemlerinde yaşanan sorundan kaynaklı olarak extract ve replicatlardan ‘
çalışmıyor’ ve ‘lag var’ alarmları oluşmuştur. Bu alarmların clear edilmesi için IT IO Database ekibinin
onayı sonrasında Smoc ekibine talep açılmıştır.
Örn: Alert Key: VODAFONE_IS_DB_OPS_GOLDENGATE_ goldendp02|ECLUO : ECLUO extract
çalışmasına ragmen 250 adet alarm oluşmuş olup , bu alarmların clear edilmesi için tek tek clear talebi
açılmıştır.

İyi çalışmalar,
Mehveş Demirel