Rozwiązywanie problemów z monitorowaniem komputerów z systemami UNIX i Linux

System Center — Operations Manager umożliwia monitorowanie komputerów z systemami UNIX i Linux, podobnie jak monitorowanie komputerów z systemem Windows. Możesz monitorować kondycję, wydajność, uzyskiwać raporty, uruchamiać zadania i implementować niestandardową instrumentację monitorowania.

Możesz monitorować następujące aspekty komputerów z systemami UNIX i Linux:

• Usługi i aplikacje

• System plików, miejsce na dysku, obszar wymiany, pamięć systemowa

• Interfejsy sieciowe

• Podstawowe procesy i atrybuty

• Klucze konfiguracji

Przed rozpoczęciem monitorowania komputerów z systemami UNIX i Linux należy wykonać następujące czynności:

Po wykonaniu powyższych kroków i pomyślnym odnalezieniu i wdrożeniu agenta na co najmniej jednym komputerze z systemami UNIX i Linux należy sprawdzić, czy są one monitorowane prawidłowo. Po wdrożeniu agenta konta Uruchom jako są używane do wykonywania odnajdywania uruchomionych przy użyciu odpowiednich reguł odnajdywania, a następnie rozpocząć monitorowanie. Po kilku minutach w obszarze roboczym Administracja przejdź do Zarządzanie urządzeniami/komputerów z systemem UNIX/Linux i sprawdź, czy komputery nie są wyświetlane jako Nieznane. Należy je odnaleźć i pokazać określoną wersję systemu operacyjnego i dystrybucji.

Domyślnie program Operations Manager monitoruje następujące obiekty systemu operacyjnego:

• System operacyjny
• Dysk logiczny
• Karty sieciowe

Dodatkowe możliwości monitorowania i interakcji można udostępniać zarządzanym komputerom z systemami UNIX i Linux przy użyciu szablonów pakietów monitorowania systemów UNIX i Linux. Aby uzyskać więcej informacji, zobacz Plik dziennika systemu UNIX lub Linux oraz proces systemu UNIX lub Linux w przewodniku tworzenia.

Rozwiązywanie problemów z monitorowaniem systemów UNIX i Linux

Poniższa sekcja zawiera informacje o problemach, które mogą wystąpić podczas monitorowania komputerów z systemami UNIX i Linux w programie Operations Manager.

Komunikat o błędzie podpisywania certyfikatu

Podczas instalacji agentów systemu UNIX/Linux może zostać wyświetlony następujący błąd.

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:  

Ten błąd występuje, gdy jest wywoływany moduł podpisywania certyfikatu, ale sam certyfikat jest pusty. Ten błąd może być spowodowany niepowodzeniem połączenia SSH z systemem zdalnym.

Jeśli zostanie wyświetlony ten błąd, wykonaj następujące czynności:

1. Upewnij się, że demon SSH na hoście zdalnym jest uruchomiony.

2. Upewnij się, że możesz otworzyć sesję SSH z hostem zdalnym przy użyciu poświadczeń określonych w Kreatorze odnajdywania.

3. Upewnij się, że poświadczenia określone w Kreatorze odnajdywania mają wymagane uprawnienia do odnajdywania. Aby uzyskać więcej informacji, zobacz Poświadczenia musisz mieć dostęp do komputerów z systemami UNIX i Linux.

Nazwa certyfikatu i nazwa hosta nie są zgodne z sobą

Nazwa pospolita (CN) używana w certyfikacie musi być zgodna z w pełni kwalifikowaną nazwą domeny (FQDN), która jest rozpoznawana przez program Operations Manager. Jeśli cn nie jest zgodny, podczas uruchamiania Kreatora odnajdywania zostanie wyświetlony następujący błąd:

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

Podstawowe informacje o certyfikacie można wyświetlić na komputerze z systemem UNIX lub Linux, wprowadzając następujące polecenie:

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

Gdy to zrobisz, zobaczysz dane wyjściowe podobne do następujących:

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  

Zweryfikuj nazwy hostów i daty i upewnij się, że są one zgodne z nazwą rozpoznawaną przez serwer zarządzania programu Operations Manager.

Jeśli nazwy hostów nie są zgodne, użyj jednej z następujących akcji, aby rozwiązać ten problem:

• Jeśli nazwa hosta systemu UNIX lub Linux jest poprawna, ale serwer zarządzania programu Operations Manager jest rozpoznawany niepoprawnie, zmodyfikuj wpis DNS tak, aby był zgodny z poprawną nazwą FQDN lub dodaj wpis do pliku hostów na serwerze programu Operations Manager.

• Jeśli nazwa hosta systemu UNIX lub Linux jest nieprawidłowa, wykonaj jedną z następujących czynności:

  • Zmień nazwę hosta na hoście z systemem UNIX lub Linux na poprawny i utwórz nowy certyfikat.

  • Utwórz nowy certyfikat z żądaną nazwą hosta.

Zmień nazwę certyfikatu:

Jeśli certyfikat został utworzony z nieprawidłową nazwą, możesz zmienić nazwę hosta i ponownie utworzyć certyfikat i klucz prywatny. W tym celu uruchom następujące polecenie na komputerze z systemem UNIX lub Linux:

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

Opcja -f wymusza zastąpienie plików w pliku /etc/opt/microsoft/scx/ssl.

Nazwę hosta i nazwę domeny w certyfikacie można również zmienić przy użyciu przełączników -h i -d , jak w poniższym przykładzie:

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

Uruchom ponownie agenta, uruchamiając następujące polecenie:

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

Dodaj wpis do pliku hosts:

Jeśli nazwa FQDN nie znajduje się w odwrotnym systemie DNS, możesz dodać wpis do pliku hostów znajdującego się na serwerze zarządzania, aby podać rozpoznawanie nazw. Plik hosts znajduje się w folderze Windows\System32\Drivers\etc. Wpis w pliku hosts jest kombinacją adresu IP i nazwy FQDN.

Aby na przykład dodać wpis dla hosta o nazwie newhostname.newdomain.name z adresem IP 192.168.1.1, dodaj następujący kod na końcu pliku hosts:

192.168.1.1      newhostname.newdomain.name  

Problemy dotyczące pakietu administracyjnego

ExecuteCommand nie obsługuje operatorów potoku ani aliasów

Jeśli używasz aliasu lub operatora potoku z parametrem ExecuteCommand , polecenie kończy się niepowodzeniem. Parametr ExecuteCommand nie obsługuje operatora potoku, aliasów i składni specyficznej dla powłoki.

W pakietach administracyjnych programu System Center Operations Manager przeznaczonych do zarządzania komputerami z systemami UNIX i Linux parametr ExecuteCommand nie uruchamia procesu powłoki, co powoduje niepowodzenie akcji niestandardowej.

Dla każdego z następujących typów akcji niestandardowych należy określić, jak argumenty polecenia są wywoływane przy użyciu parametru ExecuteCommand lub parametru ExecuteShellCommand:

• Microsoft.Unix.WSMan.Invoke.ProbeAction

• Microsoft.Unix.WSMan.Invoke.WriteAction

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

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

Parametr ExecuteCommand przekazuje argumenty wiersza polecenia do konsoli bez uruchamiania procesu powłoki.

Parametr ExecuteShellCommand przekazuje argumenty poleceń do procesu powłoki przy użyciu domyślnej powłoki użytkownika. Ta powłoka obsługuje potok, aliasy i składnię specyficzną dla powłoki.

W poniższych przykładach pokazano, jak używać parametrów ExecuteCommand i ExecuteShellCommand :

• Aby przekazać argumenty wiersza polecenia do konsoli bez uruchamiania procesu powłoki:

  <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>

• Aby przekazać argumenty wiersza polecenia do procesu powłoki, który odwołuje się do jawnej powłoki:

  <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>

• Aby przekazać argumenty polecenia do procesu powłoki, który używa domyślnej powłoki użytkownika:

  <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>

Rejestrowanie i debugowanie

W tej sekcji opisano, w jaki sposób włączać narzędzia rejestrowania i debugowania w celu rozwiązywania problemów związanych z monitorowaniem komputerów z systemami UNIX i Linux.

Włączanie logowania modułu programu Operations Manager

Agenci programu Operations Manager dla systemów UNIX i Linux utrzymują kilka plików dziennika, które mogą być przydatne podczas rozwiązywania problemów z klientem. Te pliki dziennika znajdują się na zarządzanym komputerze z systemem UNIX lub Linux. Poziom rejestrowania plików dziennika agenta można skonfigurować zgodnie z potrzebami. Pełniejsze rejestrowanie może być przydatne przy diagnozowaniu problemu. W przypadku normalnego działania poziomy dziennika nie powinny być ustawiane na wartość bardziej szczegółową niż domyślne konfiguracje (pośrednie), aby zapobiec nadmiernemu wzrostowi pliku dziennika.

1. Utwórz pusty plik o nazwie EnableOpsmgrModuleLogging w katalogu Temp dla konta użytkownika wywołującego te moduły, wpisując polecenie w wierszu polecenia lub wierszu polecenia programu PowerShell:

   COPY /Y NUL %windir%\TEMP\EnableOpsMgrModuleLogging
   

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

   Uwaga

   Ogólnie rzecz biorąc, jest to konto SYSTEM wykonujące wywołania, a C:\Windows\Temp jest domyślnym folderem tymczasowym SYSTEM.

2. Po utworzeniu pustego pliku program Operations Manager natychmiast rozpocznie rejestrowanie aktywności SSH i certyfikatu w katalogu tymczasowym. Skrypty wywołujące moduły SSH logują się do <pliku Scriptname.vbs>.log. Inne moduły mają własne dzienniki.

W niektórych przypadkach może być wymagane ponowne uruchomienie usługi HealthService w celu uzyskania rejestrowania EnableOpsmgrModuleLogging, aby zaczęły obowiązywać.

Włączanie rejestrowania na agencie UNIX

W tych dziennikach będą raportowane działania agenta UNIX. Jeśli wystąpił problem z danymi zwróconymi do programu Operations Manager, poszukaj w tym dzienniku. Ilość rejestrowanych informacji można ustawić za pomocą polecenia scxadmin. Składnia tego polecenia:

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

Poniższa tabela zawiera listę możliwych wartości parametrów:

Korzystanie z programu DebugView do rozwiązywania problemów z odnajdywaniem

Program DebugView stanowi alternatywę dla funkcji EnableOpsmgrModuleLogging w rozwiązywaniu problemów z odnajdywaniem.

1. Pobierz aplikację DebugView z: https://go.microsoft.comfwlink/?Linkid=129486.

2. Uruchom program DebugView na serwerze zarządzania, który przeprowadza odnajdywanie.

3. Rozpocznij odnajdywanie agentów UNIX. W oknach programu DebugView powinny zacząć się wyświetlać dane wyjściowe.

4. W programie DebugView będzie prezentowany odczyt krok po kroku procesu kreatora odnajdywania. Jest to często najszybszy sposób rozwiązywania problemów z odnajdywaniem.

Włączanie rejestrowania programu Operations Manager dla Windows Remote Management

Ta metoda śledzenia w trybie informacji pełnej służy do wyświetlania kwerend Zdalnego zarządzania systemem Windows (Windows Remote Management, WinRM), których program Operations Manager używa do gromadzenia danych od agenta. Jeśli podejrzewasz, że wystąpił problem z połączeniem usługi WinRM, ten dziennik zawiera szczegółowe informacje, które mogą pomóc w rozwiązywaniu problemów.

1. Na serwerze zarządzania monitorującym agenta UNIX lub Linux otwórz wiersz polecenia.

2. Wprowadź następujące polecenia w wierszu polecenia:

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

   2. StopTracing.cmd

   3. StartTracing.cmd VER

3. Odtwórz problem w programie Operations Manager.

4. Wprowadź następujące polecenia w wierszu polecenia:

   1. StopTracing.cmd

   2. FormatTracing.cmd

5. Wyszukaj ciąg WS-Man w pliku TracingGuidsNative.log.

Zarządzanie plikami dziennika systemu UNIX i Linux

Agenci programu Operations Manager dla systemów UNIX i Linux nie ograniczają rozmiaru plików dziennika agenta. W celu kontrolowania maksymalnego rozmiaru plików dziennika należy wdrożyć proces zarządzania plikami dziennika. W wielu systemach operacyjnych UNIX i Linux jest na przykład dostępne standardowe narzędzie logrotate. Narzędzie logrotate można skonfigurować do kontroli plików dziennika używanych przez Agentów programu Operations Manager w systemach UNIX lub Linux. Po obróceniu lub modyfikacji plików dziennika agenta należy zasygnalizować agentowi, że dzienniki zostały obrócone w celu wznowienia rejestracji. Polecenia scxadmin można używać z parametrem -log-rotate z następującą składnią:

scxadmin -log-rotate all

Przykładowy plik konfiguracji narzędzia Logrotate

W poniższym przykładzie pokazano plik konfiguracji do rotacji plików scx.log i omiserver.log za pomocą narzędzia logrotate systemu Linux. Zazwyczaj logrotate będzie działać jako zaplanowane zadanie (z crond) i działa na plikach konfiguracji znalezionych w /etc/logrotate.dprogramie . Aby przetestować i użyć tego pliku konfiguracji, zmodyfikuj konfigurację, aby być odpowiednia dla danego środowiska, a następnie połącz lub zapisz plik w pliku /etc/logrotate.d.

#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\
#}  

Następne kroki

Aby uzyskać dodatkowe wskazówki ułatwiające rozwiązywanie typowych problemów z wdrażaniem agentów, zapoznaj się z artykułem Rozwiązywanie problemów z programem Operations Manager 2012: wiki odnajdywania agentów systemu UNIX/Linux.