Felsöka övervakning av UNIX- och Linux-datorer

System Center – Operations Manager tillhandahåller övervakning av UNIX- och Linux-datorer som liknar övervakning av Windows-datorer. Du kan övervaka hälsa, prestanda, hämta rapporter, köra uppgifter och implementera anpassade övervakningsinstrumentation.

Du kan övervaka följande aspekter av UNIX- och Linux-datorer:

• Tjänster och program

• Filsystem, disksystem, växlingsutrymme, systemminne

• Nätverksgränssnitt

• Kärnprocesser och attribut

• Nyckelkonfigurationer

Innan du kan övervaka UNIX- och Linux-datorer måste du utföra följande steg:

1. Importera hanteringspaket genom att ladda ned de senaste versionerna från Microsoft Download Center.
2. Skapa en dedikerad resurspool för övervakning av UNIX- och Linux-datorer.
3. Konfigurera certifikaten för varje hanteringsserver i poolen.
4. Skapa och konfigurera Kör som-konton.
5. Installera agenten på UNIX och Linux med identifieringsguiden.

När du har slutfört stegen ovan och upptäckt och distribuerat agenten till en eller flera UNIX- och Linux-datorer bör du kontrollera att de övervakas korrekt. När en agent har distribuerats används Kör som-kontona för att utföra identifieringar som körs med hjälp av tillämpliga identifieringsregler och sedan börja övervaka. Efter några minuter går du till arbetsytan Administration och navigerar till Enhetshantering/UNIX/Linux-datorer och kontrollerar att datorerna inte visas som Okända. De bör identifieras och visa den specifika versionen av operativsystemet och distributionen.

Som standard övervakar Operations Manager följande operativsystemobjekt:

• Operativsystem
• Logisk disk
• Nätverkskort

Du kan lägga till ytterligare funktioner för övervakning och interaktion för dina hanterade UNIX- och Linux-datorer genom att använda mallarna för UNIX- och Linux-övervakningspaketen. Mer information finns i UNIX- eller Linux-loggfil och UNIX- eller Linux-process i redigeringsguiden.

Felsöka UNIX- och Linux-övervakning

Följande avsnitt innehåller information om problem som kan uppstå vid övervakning av UNIX- och Linux-datorer i Operations Manager.

Felmeddelande vid certifikatsignering

Under installationen av UNIX-/Linux-agenter kan följande felmeddelande visas.

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:  

Felet inträffar när certifikatsigneringsmodulen anropas men själva certifikatet är tomt. Felet kan orsakas av ett fel på SSH-anslutningen till fjärrsystemet.

Om du ser felmeddelandet gör du följande:

1. Kontrollera att SSH-daemonen på fjärrvärden körs.

2. Se till att du kan öppna en SSH-session med fjärrvärden med hjälp av de autentiseringsuppgifter som anges i identifieringsguiden.

3. Kontrollera att de autentiseringsuppgifter som anges i identifieringsguiden har de behörigheter som krävs för identifiering. Mer information finns i Autentiseringsuppgifter som du måste ha för att få åtkomst till UNIX- och Linux-datorer.

Certifikat- och värdnamnet matchar inte

Det gemensamma namnet (CN) som används i certifikatet måste matcha det fullständigt kvalificerade domännamnet (FQDN) som matchas av Operations Manager. Om CN inte matchar visas följande fel när du kör identifieringsguiden:

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

Du kan visa certifikatets grundläggande information på en UNIX- eller Linux-dator genom att ange följande kommando:

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

När du gör detta visas utdata som liknar följande:

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  

Validera värdnamnen och datumen och se till att de matchar namnet som matchas av Operations Manager-hanteringsservern.

Om värdnamnen inte matchar använder du någon av följande åtgärder för att lösa problemet:

• Om UNIX- eller Linux-värdnamnet är rätt men Operations Manager-hanteringsservern matchar det felaktigt ändrar du DNS-posten så att den matchar rätt fullständigt domännamn eller lägger till en post i värdfilen på Operations Manager-servern.

• Om UNIX- eller Linux-värdnamnet är fel gör du något av följande:

  • Ändra värdnamnet på UNIX- eller Linux-värden till det rätta och skapa ett nytt certifikat.

  • Skapa ett nytt certifikat med det önskade värdnamnet.

Så här ändrar du namnet på certifikatet:

Om certifikatet har skapats med ett felaktigt namn kan du ändra värdnamnet och skapa certifikatet och den privata nyckeln på nytt. Det kan du göra genom att köra följande kommando i UNIX- eller Linux-datorn:

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

Alternativet -f tvingar filerna i /etc/opt/microsoft/scx/ssl att skrivas över.

Du kan också ändra värdnamnet och domännamnet på certifikatet med hjälp av växlarna -h och -d , som i följande exempel:

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

Starta om agenten genom att köra följande kommando:

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

Så här lägger du till en post i värdfilen:

Om det fullständiga domännamnet inte finns i omvänd DNS kan du lägga till en post i värdfilen som finns på hanteringsservern för att ange namnmatchning. Värdfilen finns i mappen Windows\System32\Drivers\etc. En post i värdfilen är en kombination av IP-adressen och det fullständiga domännamnet.

Om du till exempel vill lägga till en post för värden med namnet newhostname.newdomain.name med IP-adressen 192.168.1.1 lägger du till följande i slutet av värdfilen:

192.168.1.1      newhostname.newdomain.name  

Problem med hanteringspaket

ExecuteCommand stödjer inte pipelineoperatorer eller alias

När du använder ett alias eller en pipelineoperator med parametern ExecuteCommand misslyckas kommandot. Parametern ExecuteCommand stöder inte pipelineoperatorn, alias och gränssnittsspecifik syntax.

I System Center Operations Manager-hanteringspaket som är utformade för att hantera UNIX- och Linux-datorer startar parametern ExecuteCommand inte en skalprocess, vilket gör att den anpassade åtgärden misslyckas.

För var och en av följande anpassade åtgärdstyper anger du hur kommandoargumenten anropas med hjälp av parametern ExecuteCommand eller parametern ExecuteShellCommand :

• Microsoft.Unix.WSMan.Invoke.ProbeAction

• Microsoft.Unix.WSMan.Invoke.WriteAction

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

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

Parametern ExecuteCommand skickar kommandoradsargumenten till konsolen utan att starta en gränssnittsprocess.

Parametern ExecuteShellCommand skickar kommandoargumenten till en gränssnittsprocess med hjälp av användarens standardgränssnitt. det här gränssnittet stöder pipeline, alias och gränssnittsspecifik syntax.

Anteckning

Parametern ExecuteShellCommand använder standardgränssnittet för den användare som kör kommandot. Om du behöver ett specifikt gränssnitt använder du parametern ExecuteCommand och prefixar kommandoargumenten med det nödvändiga gränssnittet.

Följande exempel visar hur du använder parametrarna ExecuteCommand och ExecuteShellCommand :

• Överföra kommandoradsargument till konsolen utan att starta en gränssnittsprocess:

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

• Överföra kommandoradsargument till en gränssnittsprocess som refererar till ett explicit gränssnitt:

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

• Överföra kommandoradsargument till en gränssnittsprocess som använder användarens standardgränssnitt:

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

Loggning och felsökning

I det här avsnittet beskrivs hur du aktiverar loggnings- och felsökningsverktyg för felsökning av problem med övervakning av UNIX- och Linux-datorer.

Anteckning

Du kan ändra inställningarna på loggnivå utan att agenten startas om. Läs mer.

Aktivera drifthanterarens modulloggning

Operations Manager-agenterna för UNIX och Linux har flera loggfiler som kan vara användbara vid felsökning av klientproblem. Dessa loggfiler finns på den hanterade UNIX- eller Linux-datorn. Loggningsnivån för agentloggfilerna kan konfigureras efter behov. Mer utförlig loggning kan vara användbar vid diagnos av ett problem. För normal drift bör loggnivåer inte anges till ett värde som är mer utförligt än standardkonfigurationerna (mellanliggande) för att förhindra överdriven loggfilstillväxt.

Anteckning

Anrop som görs utanför WinRM (Windows Remote Management) görs med SSH/SFTP. De här komponenterna förlitar sig på en annan loggningsmekanism än Operations Manager.

Anteckning

Loggningsnivån för omiserver.log loggfil kan inte ändras från standardvärdet i den här versionen av Operations Manager-agenter för UNIX och Linux.

1. Skapa en tom fil med namnet EnableOpsmgrModuleLogging i temp-katalogen för användarkontot som anropar dessa moduler genom att skriva i en kommandotolk eller PowerShell-kommandotolk:

   COPY /Y NUL %windir%\TEMP\EnableOpsMgrModuleLogging
   

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

   Anteckning

   I allmänhet är det SYSTEM-kontot som anropar och C:\Windows\Temp är standardmappen SYSTEM temp.

2. När den tomma filen har skapats börjar Operations Manager omedelbart logga SSH- och certifikataktivitet till temp-katalogen. Skript som anropar till SSH-modulloggen för att <Scriptname.vbs>.log. Övriga moduler har egna loggar.

I vissa fall kan det krävas att du startar om HealthService för att AktiveraOpsmgrModuleLogging-loggning ska börja gälla.

Aktivera loggning på UNIX-agenten

De här loggarna rapporterar UNIX-agentåtgärderna. Om det är problem med de data som returneras till Operations Manager kan du titta i den här loggen. Du kan ange mängden information som loggas med kommandot scxadmin. Syntaxen för kommandot är:

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

I följande tabell visas möjliga parametervärden:

Nivå	Description
Fel	Logga bara Varning - eller Fel -meddelanden.
Medel	Logginformation, varnings- och felmeddelanden.
Verbose	Logga Info-, Varning- och Fel -meddelanden utan felsökningsloggning. Observera att denna loggningsnivå troligen kommer att orsaka snabb ökning i storleken på loggfilerna. Vi rekommenderar att det här alternativet endast används under korta tidsperioder för att diagnostisera ett specifikt problem.

Felsöka identifieringsproblem med DebugView

DebugView är en alternativ metod till EnableOpsmgrModuleLogging för felsökning av identifieringsproblem.

1. Ladda ned DebugView från: https://go.microsoft.comfwlink/?Linkid=129486.

2. Starta DebugView på hanteringsservern som utför identifieringen.

3. Starta identifieringen av UNIX-agenterna. Du bör snart se utdata i DebugView-fönstren.

4. DebugView visar identifieringsprocessen steg för steg. Det här är ofta den snabbaste metoden att felsöka identifieringsproblem.

Aktivera Operations Manager-inloggning för Windows Remote Management

Den här utförliga spårningsmetoden används för att visa WinRM-frågorna (Windows Remote Management) som används av Operations Manager till att samla in data från agenten. Om du misstänker att det är problem med WinRM-anslutningen innehåller den här loggen detaljerad information som kan hjälpa dig med felsökning.

1. På hanteringsservern som övervakar UNIX- eller Linux-agenten öppnar du en kommandotolk.

2. Ange följande kommandon i kommandotolken:

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

   2. StopTracing.cmd

   3. StartTracing.cmd VER

3. Återge problemet i Operations Manager.

4. Ange följande kommandon i kommandotolken:

   1. StopTracing.cmd

   2. FormatTracing.cmd

5. Sök efter WS-Man i filen TracingGuidsNative.log.

Anteckning

WinRM kallas även WS-Management (WS-Man).

Anteckning

Kommandot FormatTracing öppnar ett Fönster i Utforskaren C:\Windows\Logs\OpsMgrTrace där katalogen visas. Filen TracingGuidsNative.log finns i den katalogen.

Hantera UNIX- och Linux-loggfiler

Operations Manager-agenterna för UNIX och Linux begränsar inte storleken på agentloggfilerna. Om du vill styra den maximala storleken för loggfiler implementerar du en process för att hantera loggfilerna. Standardverktyget logrotate finns till exempel på många UNIX- och Linux-operativsystem. Verktyget logrotate kan konfigureras för att styra loggfilerna som används av Operations Manager-agenter för UNIX eller Linux. När agentens loggfiler har roterats eller ändrats måste agenten signaleras att loggar har roterats för att återuppta loggning. Kommandot scxadmin kan användas med parametern -log-rotate med följande syntax:

scxadmin -log-rotate all

Exempel med logrotate konfigurationsfil

I följande exempel visas en konfigurationsfil för att rotera scx.log-filer och omiserver.log med logrotate-verktyget i Linux. Normalt körs logrotate som ett schemalagt jobb (med crond) och agerar på konfigurationsfiler som finns i /etc/logrotate.d. Om du vill testa och använda den här konfigurationsfilen ändrar du konfigurationen så att den passar din miljö och länkar eller sparar filen i /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\
#}  

Nästa steg

Mer information om hur du löser vanliga problem med agentdistribution finns i Felsökning av Operations Manager 2012: WIKI för IDENTIFIERING av UNIX-/Linux-agent.