Udostępnij za pośrednictwem

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

  • Kluczowe konfiguracje

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

  1. Zaimportuj pakiety administracyjne, pobierając najnowsze wersje z Centrum pobierania Microsoft.
  2. Utwórz dedykowaną pulę zasobów do monitorowania komputerów z systemami UNIX i Linux.
  3. Skonfiguruj certyfikaty dla każdego serwera zarządzania w puli.
  4. Tworzenie i konfigurowanie kont "Uruchom jako".
  5. Zainstaluj agenta w systemach UNIX i Linux za pomocą Kreatora odnajdywania.
  1. Zaimportuj pakiety administracyjne, pobierając najnowsze wersje z Centrum pobierania Microsoft.
  2. Utwórz dedykowaną pulę zasobów do monitorowania komputerów z systemami UNIX i Linux.
  3. Skonfiguruj certyfikaty dla każdego serwera zarządzania w puli.
  4. Tworzenie i konfigurowanie kont "Uruchom jako".
  5. Zainstaluj agenta w systemach UNIX i Linux za pomocą Kreatora odnajdywania.
  1. Zaimportuj pakiety administracyjne, pobierając najnowsze wersje z Centrum pobierania Microsoft.
  2. Utwórz dedykowaną pulę zasobów do monitorowania komputerów z systemami UNIX i Linux.
  3. Skonfiguruj certyfikaty dla każdego serwera zarządzania w puli.
  4. Tworzenie i konfigurowanie kont "Uruchom jako".
  5. Zainstaluj agenta w systemach UNIX i Linux za pomocą Kreatora odnajdywania.

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ą wykorzystywane do wykonywania odkryć przy użyciu odpowiednich reguł odkrywania, a następnie rozpoczynają 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. Powinny zostać odnalezione i wyświetlone z określeniem wersji systemu operacyjnego i dystrybucji systemu.

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 UNIX lub Linux oraz proces 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 usługa SSH na zdalnym hoście jest uruchomiona.

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

  3. Upewnij się, że poświadczenia podane w Kreatorze odnajdywania mają wymagane uprawnienia do przeprowadzania odnajdywania. Aby uzyskać więcej informacji, zobacz Poświadczenia, które musisz posiadać, aby uzyskać 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 wykrywania 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 Operations Manager niepoprawnie rozwiązuje tę nazwę, zmodyfikuj wpis DNS, aby pasował do poprawnej nazwy FQDN, lub dodaj wpis do pliku hostów na serwerze 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 odwróconym DNS, możesz dodać wpis do pliku hostów znajdującego się na serwerze zarządzania, aby umożliwić 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 oraz składni specyficznej dla powłoki.

W pakietach administracyjnych programu System Center Operations Manager, które są przeznaczone 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 systemowej.

Parametr ExecuteShellCommand przekazuje argumenty komendy do procesu powłoki, używając domyślnej powłoki użytkownika; ta powłoka obsługuje pipeline, aliasy i składnię specyficzną dla powłoki.

Uwaga

Parametr ExecuteShellCommand używa domyślnej powłoki użytkownika wykonującego to polecenie. Jeśli potrzebujesz konkretnej powłoki, użyj parametru ExecuteCommand i poprzedź argumenty polecenia wymaganą powłoką.

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 w powłoce, który odwołuje się do powłoki eksplicytnej:

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

Uwaga

W programie Operations Manager 2019 UR3 można zmienić ustawienia na poziomie dziennika bez ponownego uruchamiania agenta. Dowiedz się więcej.

Uwaga

Ustawienia na poziomie dziennika można zmienić bez ponownego uruchamiania agenta. Dowiedz się więcej.

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. Bardziej szczegółowe logowanie 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.

Uwaga

Połączenia wykonywane poza Windows Remote Management (WinRM) realizowane są z użyciem SSH/SFTP. Te komponenty polegają na osobnym mechanizmie rejestrowania niż Operations Manager.

Uwaga

Nie można zmienić domyślnego poziomu rejestrowania pliku dziennika omiserver.log w tej wersji Operations Manager Agentów dla systemów UNIX i Linux.

  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ć konieczne ponowne uruchomienie usługi HealthService, aby rejestrowanie EnableOpsmgrModuleLogging zaczęło działać.

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, sprawdź to 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:

Poziom opis
Błędy Rejestruj tylko Ostrzeżenia i Komunikaty o błędach .
Średni Rejestruj wiadomości informacyjne, ostrzeżenia i błędy.
Pełne informacje Rejestruj Informacje, Ostrzeżeniai Komunikaty o błędach z rejestrowaniem debugowania. Należy pamiętać, że ten poziom rejestrowania może spowodować szybkie zwiększenie rozmiaru plików dziennika. Zaleca się, aby ta opcja była używana tylko przez krótki czas w celu zdiagnozowania określonego problemu.

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

DebugView jest alternatywną metodą dla funkcji EnableOpsmgrModuleLogging w rozwiązywaniu problemów z wykrywaniem.

  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 prezentowana relacja krok po kroku procesu kreatora wykrywania. Często jest to najszybszy sposób rozwiązywania problemów z wykrywaniem.

Włącz rejestrowanie w programie Operations Manager dla zarządzania zdalnego Windows

Ta metoda śledzenia w trybie szczegółowym służy do wyświetlania kwerend Zdalnego zarządzania systemem Windows (Windows Remote Management, WinRM), które Operations Manager wykorzystuje 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 powodujący awarię w programie Operations Manager.

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

    1. StopTracing.cmd

    2. FormatTracing.cmd

  5. Wyszukaj WS-Man w pliku TracingGuidsNative.log.

Uwaga

Usługa WinRM jest także znana jako usługa WS-Management (WS-Man).

Uwaga

Polecenie FormatTracing otwiera okno Eksploratora Windows z wyświetlonym katalogiem C:\Windows\Logs\OpsMgrTrace . To w tym katalogu znajduje się plik 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 przerotowaniu lub modyfikacji plików dziennika agenta należy zasygnalizować agentowi, że dzienniki zostały przerotowane, aby wznowić rejestrowanie zdarzeń. 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.d. 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.