Müşterilerimizde birçok zaman ürettiği bilgi ve hataları Windows Event Log’una yazmak yerine sistem üzerinde oluşturduğu bir dosyaya yazan bir BT bileşeni ile karşılaşıyoruz. Bu tip durumlar için Operations Manager’ın Log Dosyası’nın içeriğini okuyup, sizin verdiğiniz parametrelere göre uyarı veya hata üretme gibi bir özelliği var, bu özelliği de eminim birçoğunuz birçok defa kullanmıştır.

Bununla birlikte forumlarda bu konuda oldukça soru gelmesi sebebiyle bu konudaki püf noktaları yayınlamak istedim.

Öncelikle aşağıdaki noktalara dikkat etmekte fayda var:

Log dosyasını temizlemeyin

Operations Manager log dosyanızdaki “en son kontrol edilen satır” ı hatırlayacaktır. Örneğin, en son 120 numaralı satırda kaldıysa, bir sonraki kontrol zamanında 101. satırdan devam eder. Eğer log dosyasını silerseniz log dosyası 1. satırdan başlayacaktır ve SCOM, log dosyanız 120. satıra gelene kadar okumayacaktır.

Operations Manager will remember the last checked line within your log file. So in case that was in line 100, SCOM will start reading in line 101 the next time the workflow runs. If you decide to clear the log file and start filling it from line 1, SCOM will not proceed until line 101 is reached

Aynı log dosyasına yazıyorsa

Yeni log dosyası oluşturmuyorsa (sürekli aynı log dosyasına yazıyorsa), dosyanın boyutuna dikkat edin. Bunun için dosya boyutu belirli bir rakama ulaştığında SCOM’a uyarı oluşturtabilirsiniz.

Yeni dosya oluşturuyorsa

Belirli bir zamanda (günlük, haftalık vb) veya belirli bir dosya boyutuna ulaşıldığında otomatik olarak yeni dosya oluşturuyorsa (ki genelde bu tercih edilir) gerçek dosya isminin her zaman değişmek zorunda olduğunu unutmayın. Örneğin, güncel log dosyasının ismi uygulama_guncel.log iken eski log dosyalarını uygulama_<tarih>_<zaman>.log ya da benzer bir şekilde arşivliyor olabilir. Yeni oluşturulan dosyanın “Oluşturulma zamanı” etiketi eski dosyadan daha yeni olduğu sürece SCOM için problem olmaz, yeni dosyayı algılar ve devam eder.

Ancak, NTFS’te bir dosyayı sildiğinizde ve aynı dakika içinde aynı isimde yeni bir dosya oluşturduğunuzda yeni dosyanın “oluşturulma zamanı” eskisi ile aynı olacaktır ve SCOM da bu yeni dosyaya sanki içi temizlenmiş bir dosya olarak yaklaşacak ve birinci maddedeki (Log dosyasını temizlemeyin) problem ile karşılaşacaksınız.

Bu senaryoyu kolaylıkla test edebilirsiniz:

1. Bilgisayarınızda “dosya.txt” isminde bir dosya oluşturun.
2. Oluşturulma zamanına bakın.
3. En azından bir dakika bekleyin ve “şu anki zaman” ile “oluşturulma zamanını” aklınızda tutun.
4. Dosyayı silin.
5. Dosyayı sildikten sonraki 1 dakika içinde aynı isimde bir dosya oluşturun.
6. Dosyaının “oluşturulma” zamanına baktığınızda bir önce oluşturduğunuz dosya ile saniyesine kadar aynı olduğunu göreceksiniz.

Farklı bir senaryo olarak:

1. Bilgisayarınızda “dosya.txt” isminde bir dosya oluşturun.
2. Oluşturulma zamanına bakın.
3. En azından bir dakika bekleyin ve “şu anki zaman” ile “oluşturulma zamanını” aklınızda tutun.
4. Dosyayı silin.
5. Bir dakikadan daha uzun bir süre bekleyin.
5. Aynı isimde bir dosya oluşturun.
6. Dosyaının “oluşturulma” zamanına baktığınızda bir önce oluşturduğunuz dosya ile aynı olmadığın, güncel tarihi aldığını göreceksiniz.

Bunun sebebi, NTFS’in metadata’sının dakikada bir güncellenmesidir.

İlgili log dosyalarını oluşturan yazılımlar / donanımlar ise genelde eski log dosyasını arşivledikten sonra aynı dakika içinde yeni dosya oluşturular! SCOM ise bu dosyalara sanki dosyanın içi silinmiş gibi davranır.

Bu konuda bir geçiçi çözüm ararsanız: güncel log dosyasında da (mümkünse) tarih ve zaman kullanmak (jenerik bir isim kullanmamak) ve log dosyasını izlerken direk dosya ismi vermek yerine değişken kullanmak. Örneğin, log dosyanız uygulama_<tarih>_<zaman>.log ise iş akışını “uygulama_*_*.log” isimli dosyayı izlemek için oluşturabilirsiniz.