UNIX ve Linux bilgisayarlarını izleme sorunlarını giderme

System Center - Operations Manager, Windows bilgisayarlarının izlenmesine benzer UNIX ve Linux bilgisayarların izlenmesini sağlar. Sistem durumunu, performansı izleyebilir, raporları alabilir, görevleri çalıştırabilir ve özel izleme izleme araçları uygulayabilirsiniz.

UNIX ve Linux bilgisayarlarının şu yönlerini izleyebilirsiniz:

• Hizmetler ve uygulamalar

• Dosya sistemi, disk alanı, takas alanı, sistem belleği

• Ağ arabirimleri

• Çekirdek süreçler ve öznitelikler

• Ana yapılandırmalar

UNIX ve Linux bilgisayarları izleyebilebilmeniz için önce aşağıdaki adımları tamamlamanız gerekir:

1. Microsoft İndirme Merkezi'nden en son sürümleri indirerek yönetim paketlerini içeri aktarın.
2. UNIX ve Linux bilgisayarları izlemek için ayrılmış bir kaynak havuzu oluşturun.
3. Havuzdaki her yönetim sunucusu için sertifikaları yapılandırın.
4. Farklı Çalıştır hesaplarını oluşturun ve yapılandırın.
5. Bulma Sihirbazı'nı kullanarak UNIX ve Linux'a aracı yükleyin.

Yukarıdaki adımları tamamladıktan ve aracıyı bir veya daha fazla UNIX ve Linux bilgisayara başarıyla keşfedip dağıttığınızda, doğru izlendiklerini doğrulamanız gerekir. Aracı dağıtıldıktan sonra Farklı Çalıştır hesapları, geçerli bulma kuralları kullanılarak çalıştırılan bulmaları gerçekleştirmek ve ardından izlemeyi başlatmak için kullanılır. Birkaç dakika sonra, Yönetim çalışma alanı altında Cihaz Yönetimi/UNIX/Linux Bilgisayarları'na gidin ve bilgisayarların Bilinmiyor olarak listelenmediğinden emin olun. Bunlar keşfedilmeli ve işletim sistemi ile dağıtımın belirli bir sürümünü göstermelidir.

Varsayılan olarak, Operations Manager aşağıdaki işletim sistemi nesnelerini izler:

• İşletim Sistemi
• Mantıksal disk
• Ağ Bağdaştırıcıları

UNIX ve Linux izleme paketi şablonları kullanarak yönetilen UNIX ve Linux bilgisayarlarınızla ek izleme ve etkileşim yetenekleri sağlayabilirsiniz. Daha fazla bilgi için, Yazar Kılavuzu'ndaki UNIX or Linux Log File (UNIX veya Linux Günlük Dosyası) ve UNIX or Linux Process (UNIX veya Linux İşlemi) konusuna bakınız.

UNIX ve Linux izleme sorunlarını giderme

Aşağıdaki bölümde, Operations Manager'da UNIX ve Linux bilgisayarlarını izlemeyle ilgili oluşabilecek sorunlar hakkında bilgi sağlanır.

Sertifika İmzalama Hata Mesajı

UNIX/Linux aracılarının yüklenmesi sırasında, aşağıdaki hatayı görebilirsiniz.

Event Type: Error  
Event Source: Cross Platform Modules  
Event Category: None  
Event ID: 256  
Date: 4/1/2009  
Time: 4:02:27 PM  
User: N/A  
Computer: COMPUTER1  
Description: Unexpected ScxCertLibException: Can't decode from base64  
; input data is:  

Sertifika imzalama modülü çağrıldığı ama sertifikanın kendisi boş olduğu zaman bu hata oluşur. Bu hata, uzak sisteme bir SSH bağlantısı arızasından kaynaklanabilir.

Bu hatayı görürseniz, aşağıdakileri yapın:

1. Uzak konakta SSH daemon'unun çalıştığından emin olun.

2. Bulma Sihirbazı'nda belirtilen kimlik bilgilerini kullanarak uzak konakla bir SSH oturumu açabildiğinizi doğrulayın.

3. Bulma Sihirbazı'nda belirtilen kimlik bilgilerinin bulma için gerekli ayrıcalıklara sahip olduğundan emin olun. Daha fazla bilgi için bkz. UNIX ve Linux Bilgisayarlara Erişmek için Sahip Olmanız Gereken Kimlik Bilgileri.

Sertifika Adı ve Ana Bilgisayar Adı Eşleşmiyor

Sertifikada kullanılan ortak ad (CN) Operations Manager ile çözümlenen tam etki alanı adı (FQDN) ile eşleşmelidir. CN eşleşmiyorsa Bulma Sihirbazı'nı çalıştırdığınızda aşağıdaki hatayı görürsünüz:

The SSL certificate contains a common name (CN) that doesn't match the hostname  

Şu komutu girerek UNIX ya da Linux bilgisayarda sertifikanın temel ayrıntılarını görebilirsiniz:

openssl x509 -noout -in /etc/opt/microsoft/scx/ssl/scx.pem -subject -issuer -dates  

Bunu yaptığınızda aşağıdakine benzer bir çıkış görürsünüz:

subject= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name  
issuer= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name  
notBefore=Mar 25 05:21:18 2008 GMT  
notAfter=Mar 20 05:21:18 2029 GMT  

Ana bilgisayar adları ve tarihleri ​​doğrulayın ve Operations Manager yönetim sunucusu tarafından çözümlenen ad ile eşleştiğinden emin olun.

Ana bilgisayar adları eşleşmiyorsa, sorunu çözmek için aşağıdaki eylemlerden birini kullanın:

• UNIX veya Linux ana bilgisayar adı doğruysa ama Operations Manager yönetim sunucusu onu yanlış çözümlüyorsa, DNS girdisini doğru FQDN ile eşleşecek şekilde değiştirin veya Operations Manager sunucusuna dosyasına ana bilgisayar dosyalarına bir giriş ekleyin.

• UNIX veya Linux ana bilgisayar adı yanlışsa, aşağıdakilerden birini yapın:

  • UNIX veya Linux ana bilgisayarında ana bilgisayar adını doğrusuyla değiştirin ve yeni bir sertifika oluşturun.

  • İstenen ana bilgisayar adıyla yeni bir sertifika oluşturun.

Sertifikadaki Adı Değiştirmek İçin:

Sertifika yanlış bir adla oluşturulmuşsa, ana bilgisayar adını değiştirebilir ve sertifika ve özel anahtarı yeniden oluşturabilirsiniz. Bunu yapmak için, UNIX veya Linux bilgisayarda aşağıdaki komutu çalıştırın:

/opt/microsoft/scx/bin/tools/scxsslconfig -f -v  

-f seçeneği /etc/opt/microsoft/scx/ssl içindeki dosyaların üzerine yazılmasını zorlar.

Aşağıdaki örnekte olduğu gibi -h ve -d anahtarlarını kullanarak sertifikadaki ana bilgisayar adını ve etki alanı adını da değiştirebilirsiniz:

/opt/microsoft/scx/bin/tools/scxsslconfig -f -h <hostname> -d <domain.name>  

Aşağıdaki komutu çalıştırarak aracıyı yeniden başlatın:

/opt/microsoft/scx/bin/tools/scxadmin -restart  

Ana bilgisayarlar dosyasına bir giriş eklemek için:

FQDN Ters DNS'de değilse, ad çözümlemesi sağlamak için yönetim sunucusunda bulunan hosts dosyasına bir girdi ekleyebilirsiniz. Hosts dosyası Windows\System32\Drivers\etc klasöründe bulunur. Konaklar dosyasındaki bir giriş IP adresi ve FQDN'nin birleşimidir.

Örneğin, ip adresi 192.168.1.1 olan newhostname.newdomain.name adlı konağa giriş eklemek için, konak dosyasının sonuna aşağıdakileri ekleyin:

192.168.1.1      newhostname.newdomain.name  

Yönetim paketi sorunları

ExecuteCommand Ardışık Düzen İşleçleri veya Diğer Adları Desteklemez

ExecuteCommand parametresiyle bir diğer ad veya işlem hattı işleci kullandığınızda, komut başarısız olur. ExecuteCommand parametresi işlem hattı işlecini, diğer adları ve kabuğa özgü söz dizimini desteklemez.

UNIX ve Linux bilgisayarları yönetmek için tasarlanmış System Center Operations Manager yönetim paketlerinde ExecuteCommand parametresi bir kabuk işlemi başlatmaz ve özel eylemin başarısız olmasına neden olur.

Aşağıdaki özel eylem türlerinin her biri için komut bağımsız değişkenlerinin ExecuteCommand parametresini veya ExecuteShellCommand parametresini kullanarak nasıl çağrılacağını belirtirsiniz:

• Microsoft.Unix.WSMan.Invoke.ProbeAction

• Microsoft.Unix.WSMan.Invoke.WriteAction

• Microsoft.Unix.WSMan.Invoke.Privileged.ProbeAction

• Microsoft.Unix.WSMan.Invoke.Privileged.WriteAction

ExecuteCommand parametresi, kabuk işlemi başlatmadan komut satırı bağımsız değişkenlerini konsola geçirir.

ExecuteShellCommand parametresi, kullanıcının varsayılan kabuğunu kullanarak komut bağımsız değişkenlerini bir kabuk işlemine geçirir; bu kabuk işlem hattını, diğer adları ve kabuğa özgü söz dizimlerini destekler.

Not

ExecuteShellCommand parametresi, komutu çalıştıran kullanıcının varsayılan kabuğunu kullanır. Belirli bir kabuğa ihtiyacınız varsa ExecuteCommand parametresini kullanın ve komut bağımsız değişkenlerinin önüne gerekli kabuğu koyun.

Aşağıdaki örneklerde ExecuteCommand ve ExecuteShellCommand parametrelerinin nasıl kullanılacağı gösterilmiştir:

• Bir kabuk süreci başlatmadan komut satırı bağımsız değişkenlerini konsola iletmek için:

  <p:ExecuteCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem"> <p:Command> service syslog status </p:Command> <p:timeout>10</p:timeout> </p:ExecuteCommand_INPUT>

• Komut satırı bağımsız değişkenlerini açık bir kabuğa gönderme yapan bir kabuk sürecine iletmek için:

  <p:ExecuteCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem"> <p:Command> /bin/sh ps -ef syslog | grep -v grep </p:Command> <p:timeout>10</p:timeout> </p:ExecuteCommand_INPUT>

• Komut satırı bağımsız değişkenlerini kullanıcının varsayılan kabuğunu kullanan bir kabuk sürecine iletmek için:

  <p:ExecuteShellCommand_INPUT xmlns:p="https://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem"> <p:Command> uptime |&nbsp; awk '{print $10}' |awk -F"," '{print $1}' </p:Command> <p:timeout>10</p:timeout> </p:ExecuteShellCommand_INPUT>

Günlük Kaydı ve Hata Ayıklama

Bu bölümde, UNIX ve Linux bilgisayarlarını izlemeyle ilgili sorunları gidermek için günlüğe kaydetme ve hata ayıklama araçlarının nasıl etkinleştirileceği açıklanır.

Not

Aracı yeniden başlatmadan günlük düzeyi ayarlarını değiştirebilirsiniz. Daha fazla bilgi edinin.

Operations Manager Modülü Günlüğe Kaydetmeyi Etkinleştir

UNIX ve Linux için Operations Manager Aracıları, istemci sorunlarını giderirken yararlı olabilecek birkaç günlük dosyası tutar. Bu günlük dosyaları yönetilen UNIX veya Linux bilgisayarda bulunur. Aracı günlük dosyalarının günlük düzeyi gerektiğinde yapılandırılabilir. Daha ayrıntılı günlük kaydı, bir sorunu tanılamada yararlı olabilir. Normal işlem için günlük düzeyleri, aşırı günlük dosyası büyümesini önlemek için varsayılan yapılandırmalardan (Ara) daha ayrıntılı bir değere ayarlanmalıdır.

Not

Windows Uzak Yönetimi (WinRM) dışında yapılan çağrılar SSH/SFTP kullanılarak yapılır. Bu bileşenler Operations Manager'dan ayrı bir kayıt mekanizmasına dayanır.

Not

omiserver.log günlük dosyasının günlük düzeyi, UNIX ve Linux için Operations Manager Aracıları'nın bu sürümünde varsayılandan değiştirilemez.

1. Komut satırına veya PowerShell istemine yazarak bu modülleri çağıran kullanıcı hesabının Temp dizininde EnableOpsmgrModuleLogging adlı boş bir dosya oluşturun:

   COPY /Y NUL %windir%\TEMP\EnableOpsMgrModuleLogging
   

   New-Item "$env:windir\TEMP\EnableOpsMgrModuleLogging"
   

   Not

   Genellikle, çağrıları yapan SYSTEM hesabıdır ve C:\Windows\Temp varsayılan SYSTEM temp klasörüdür.

2. Boş dosya oluşturulduktan sonra Operations Manager, SSH ve Sertifika etkinliğini Temp dizinine kaydetmeye hemen başlar. SSH modüllerine çağrıda bulunan betiklerScriptname.vbs.log >için günlüğe < kaydedilir. Diğer modüllerin kendi günlükleri vardır.

Bazı durumlarda, EnableOpsmgrModuleLogging günlüğünün etkili olması için HealthService'i yeniden başlatmak gerekebilir.

UNIX Aracısında Günlüğü Etkinleştirme

Bu günlükler UNIX aracı eylemlerini raporlar. Operations Manager'a döndürülen verilerle ilgili bir sorun varsa bu günlüğe bakın. scxadmin komutu ile, günlüğe kaydedilen oturum bilgilerinin miktarını ayarlayabilirsiniz. Bu komutun söz dizimi şöyledir:

scxadmin -log-set [all|cimom|provider] {verbose|intermediate|errors}

Aşağıdaki tablo olası parametre değerlerini listeler:

Level	Açıklama
Hatalar	Yalnızca Uyarı veya Hata iletilerini günlüğe kaydet.
Orta	Günlük Bilgileri, Uyarı ve Hata iletileri.
Ayrıntılı	Hata ayıklama günlük kaydıyla Bilgi, Uyarıve Hata iletilerini günlüğe kaydet. Bu günlüğe kaydetme düzeyinin büyük olasılıkla günlük dosyası boyutundaki hızlı büyümenin nedeni olduğunu unutmayın. Bu seçeneğin yalnızca belirli bir sorunu tanılamak için kısa süreler boyunca kullanılması önerilir.

Bulma sorunlarını gidermek için DebugView Kullanma

DebugView bulma sorunlarını giderme için EnableOpsmgrModuleLogging'e alternatif bir yöntemdir.

1. DebugView'ı şu kaynaktan indirin: https://go.microsoft.comfwlink/?Linkid=129486.

2. Bulma işlemini yapan Yönetim Sunucusunda DebugView'i başlatın.

3. UNIX Aracılarını bulmaya başlayın. DebugView pencerelerinde çıktıyı görmeye başlayacaksınız.

4. DebugView bulma sihirbazı sürecinin adım adım okumasını sunar. Bu genellikle bulma sorunlarını gidermek için en hızlı yöntemdir.

Windows Uzaktan Yönetim için Operations Manager Günlüğüne Kaydetmeyi etkinleştir

Bu ayrıntılı izleme yöntemi Operations Manager tarafından aracıdan veri toplamak için kullanılan Windows Uzaktan Yönetimi (WinRM) sorgularını görmek için kullanılır. WinRM bağlantısında bir sorun olduğundan şüpheleniyorsanız, bu günlük sorun gidermeye yardımcı olabilecek ayrıntılı bilgiler sağlar.

1. UNIX veya Linux aracısını izleyen yönetim sunucusunda, bir komut istemi açın.

2. Komut istemine aşağıdaki komutları girin:

   1. cd C:\Program Files\Microsoft System Center\Operations Manager\Tools

   2. StopTracing.cmd

   3. StartTracing.cmd VER

3. Operations Manager'da başarısız sorunu yeniden üretin.

4. Komut istemine aşağıdaki komutları girin:

   1. StopTracing.cmd

   2. FormatTracing.cmd

5. TracingGuidsNative.log dosyasında WS-Man arayın.

Not

WinRM, WS-Management (WS-Man) olarak da bilinir.

Not

FormatTracing komutu, dizini görüntüleyen C:\Windows\Logs\OpsMgrTrace bir Windows Gezgini penceresi açar. TracingGuidsNative.log dosyası bu dizindedir.

UNIX ve Linux Günlük Dosyalarını Yönet

UNIX ve Linux için Operations Manager Aracıları aracı günlük dosyalarının boyutunu sınırlamaz. Günlük dosyalarının maksimum boyutunu denetlemek için günlük dosyalarını yönetecek bir işlem uygulayın. Örneğin, standart yardımcı programı logrotate birçok UNIX ve Linux işletim sisteminde kullanılabilir. Logrotate yardımcı programı, Operations Manager Aracıları tarafından UNIX veya Linux için kullanılan günlük dosyalarını denetlemek için yapılandırılabilir. Aracısının günlük dosyalarını döndürdükten veya değiştirdikten sonra aracıya, günlüklerin günlüğe kaydetmeyi sürdürmek için döndürüldüğü bildirilmelidir. scxadmin komutu aşağıdaki söz dizimiyle -log-rotate parametresiyle kullanılabilir:

scxadmin -log-rotate all

Örnek Logrotate yapılandırma dosyası

Aşağıdaki örnekte, scx.log dosyalarını döndürmek ve Linux'ın logrotate yardımcı programıyla omiserver.log için bir yapılandırma dosyası gösterilmektedir. Genellikle logrotate zamanlanmış bir iş (crond ile) olarak çalışır ve içinde /etc/logrotate.dbulunan yapılandırma dosyaları üzerinde işlem görür. Bu yapılandırma dosyasını test etmek ve kullanmak için, yapılandırmayı ortamınıza uygun olacak şekilde değiştirin ve dosyasını /etc/logrotate.döğesine bağlayın veya kaydedin.

#opsmgr.lr  

#Rotate scx.log  
#Weekly rotation, retain four weeks of compressed logs  
#Invoke scxadmin -log-rotate to resume logging after rotation  

/var/opt/microsoft/scx/log/scx.log {  
rotate 4  
weekly  
compress  
missingok  
notifempty  
postrotate  

/usr/sbin/scxadmin -log-rotate all  
endscript  
}

#Rotate scx.log for the monitoring user account named: monuser  
#Weekly rotation, retain four weeks of compressed logs  
#Invoke scxadmin -log-rotate to resume logging after rotation  

/var/opt/microsoft/scx/log/monuser/scx.log {  
rotate 4  
weekly  
compress  
missingok  
notifempty  
postrotate  

/usr/sbin/scxadmin -log-rotate all
endscript  
}  

#Optionally, rotate omiserver.log. This requires that OMI be stopped and started to prevent  
#impact to logging. Monthly rotation, retain two weeks of compressed logs  
#Uncomment these lines if rotation of omiserver.log is needed  

#/var/opt/microsoft/scx/log/omiserver.log{  
#        rotate 2  
#        monthly  
#        compress  
#        missingok  
#        notifempty  
#        prerotate  
#        /usr/sbin/scxadmin -stop  
#        endscript  
#        postrotate  
#        /usr/sbin/scxadmin -start  
#        endscript\
#}  

Sonraki adımlar

Yaygın aracı dağıtım sorunlarını çözmeye yardımcı olacak ek yönergeler için Operations Manager 2012 Sorun Giderme: UNIX/Linux Aracısı Bulma Wiki'sini gözden geçirin.