Risoluzione dei problemi di monitoraggio dei computer UNIX e Linux

Importante

Questa versione di Operations Manager ha raggiunto la fine del supporto. È consigliabile eseguire l'aggiornamento a Operations Manager 2022.

System Center Operations Manager offre funzionalità di monitoraggio dei computer UNIX e Linux simili a quelle disponibili per i computer Windows. È possibile monitorare lo stato e le prestazioni, ottenere report, eseguire attività e implementare strumenti di monitoraggio personalizzati.

È possibile monitorare i seguenti aspetti dei computer UNIX e Linux:

  • Servizi e applicazioni

  • File system, spazio su disco, spazio di swapping, memoria di sistema

  • Interfacce di rete

  • Attributi e processi di base

  • Configurazioni dei tasti

Prima di poter monitorare computer UNIX e Linux, è necessario completare la procedura seguente:

  1. Importare i Management Pack scaricando le versioni più recenti dall'Area download Microsoft.
  2. Creare un pool di risorse dedicato per il monitoraggio dei computer UNIX e Linux.
  3. Configurare i certificati per ogni server di gestione nel pool.
  4. Creare e configurare account RunAs.
  5. Installare l'agente in UNIX e Linux usando l'Individuazione guidata.
  1. Importare i Management Pack scaricando le versioni più recenti dall'Area download Microsoft.
  2. Creare un pool di risorse dedicato per il monitoraggio dei computer UNIX e Linux.
  3. Configurare i certificati per ogni server di gestione nel pool.
  4. Creare e configurare account RunAs.
  5. Installare l'agente in UNIX e Linux usando l'Individuazione guidata.
  1. Importare i Management Pack scaricando le versioni più recenti dall'Area download Microsoft.
  2. Creare un pool di risorse dedicato per il monitoraggio dei computer UNIX e Linux.
  3. Configurare i certificati per ogni server di gestione nel pool.
  4. Creare e configurare account RunAs.
  5. Installare l'agente in UNIX e Linux usando l'Individuazione guidata.

Dopo aver completato i passaggi precedenti e aver scoperto e distribuito correttamente l'agente in uno o più computer UNIX e Linux, è necessario verificare che siano monitorati correttamente. Al termine della procedura di distribuzione di un agente, vengono usati gli account RunAs per eseguire individuazioni usando le regole di individuazione applicabili e avviare il monitoraggio. Dopo alcuni minuti, nell'area di lavoro Amministrazione passare a Gestione dispositivi/UNIX/Linux Computers e verificare che i computer non siano elencati come Sconosciuto. Dovrebbero invece essere individuati e indicare la versione specifica del sistema operativo e della distribuzione.

Per impostazione predefinita, Operations Manager esegue il monitoraggio degli oggetti seguenti dei sistemi operativi:

  • Sistema operativo
  • Disco logico
  • Schede di rete

È possibile fornire monitoraggio aggiuntivo e funzionalità di interazione con i computer UNIX e Linux gestiti utilizzando i modelli del pacchetto di monitoraggio UNIX e Linux. Per ulteriori informazioni, vedere File di registro UNIX o Linux e Processo UNIX o Linux nella Guida alla creazione.

Risoluzione dei problemi relativi al monitoraggio di UNIX e Linux

Le sezioni seguenti forniscono informazioni sui problemi che possono verificarsi durante il monitoraggio di computer UNIX e Linux in Operations Manager.

Messaggio di errore di firma del certificato

Durante l'installazione di agenti UNIX/Linux, è possibile che venga visualizzato il messaggio di errore seguente.

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:  

Questo errore si verifica quando viene chiamato il modulo di firma del certificato, ma il certificato è vuoto. Può inoltre essere causato da un errore di connessione SSH al sistema remoto.

Se viene visualizzato questo messaggio di errore, effettuare le operazioni seguenti:

  1. Assicurarsi che il daemon SSH nell'host remoto sia in esecuzione.

  2. Assicurarsi di poter aprire una sessione SSH con l'host remoto usando le credenziali specificate nell'Individuazione guidata.

  3. Assicurarsi che le credenziali specificate nell'Individuazione guidata dispongano dei privilegi necessari per l'individuazione. Per altre informazioni, vedere Credenziali necessarie per l'accesso a computer UNIX e Linux.

Mancata corrispondenza tra nome del certificato e nome host

Il nome comune (CN) utilizzato nel certificato deve corrispondere al nome di dominio completo (FQDN) risolto da Operations Manager. Se il cn non corrisponde, verrà visualizzato l'errore seguente quando si esegue l'Individuazione guidata:

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

Per visualizzare i dettagli di base del certificato sul computer UNIX o Linux, immettere il comando seguente:

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

Quando si esegue questa operazione, verrà visualizzato un output simile al seguente:

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  

Convalidare le date e i nomi host e verificare che corrispondano al nome risolto dal server di gestione di Operations Manager.

Se i nomi host non corrispondono, usare una delle azioni seguenti per risolvere il problema:

  • Se il nome host UNIX o Linux è corretto ma il server di gestione di Operations Manager lo risolve in modo errato, modificare la voce DNS in modo che corrisponda al nome FQDN corretto oppure aggiungere una voce nel file hosts sul server di Operations Manager.

  • Se il nome host UNIX o Linux non è corretto, effettuare una delle operazioni seguenti:

    • Sostituire il nome host UNIX o Linux con quello corretto e creare un nuovo certificato.

    • Creare un nuovo certificato con il nome host desiderato.

Per modificare il nome sul certificato:

Se il certificato è stato creato con un nome errato, è possibile modificare il nome host e ricreare il certificato e la chiave privata. A tale scopo, eseguire il comando seguente sul computer UNIX o Linux:

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

L'opzione -f forza la sovrascrittura dei file in /etc/opt/microsoft/scx/ssl.

È anche possibile modificare il nome host e il nome di dominio nel certificato usando le opzioni -h e -d , come nell'esempio seguente:

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

Riavviare l'agente eseguendo il comando seguente:

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

Per aggiungere una voce al file hosts:

Se il nome di dominio completo non è in DNS inverso, è possibile aggiungere una voce al file hosts che si trova nel server di gestione per fornire la risoluzione dei nomi. Il file hosts si trova nella cartella Windows\System32\Drivers\etc. Una voce nel file degli host è una combinazione di indirizzo IP e nome FQDN.

Ad esempio, per aggiungere una voce per l'host denominato newhostname.newdomain.name con un indirizzo IP 192.168.1.1, aggiungere quanto segue alla fine del file hosts:

192.168.1.1      newhostname.newdomain.name  

Problemi relativi ai Management Pack

ExecuteCommand non supporta gli operatori pipeline o alias

Quando si utilizza un alias o un operatore pipeline con il parametro ExecuteCommand , il comando ha esito negativo. Il parametro ExecuteCommand non supporta l'operatore della pipeline, gli alias e la sintassi specifica della shell.

Nei Management Pack di System Center Operations Manager progettati per gestire i computer UNIX e Linux, il parametro ExecuteCommand non avvia un processo della shell, causando l'esito negativo dell'azione personalizzata.

Per tutti i tipi di azione personalizzata riportati di seguito, specificare come gli argomenti di comando vengono richiamati utilizzando il parametro ExecuteCommand o il parametro ExecuteShellCommand :

  • Microsoft.Unix.WSMan.Invoke.ProbeAction

  • Microsoft.Unix.WSMan.Invoke.WriteAction

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

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

Il parametro ExecuteCommand passa gli argomenti della riga di comando alla console senza avviare un processo della shell.

Il parametro ExecuteShellCommand trasferisce gli argomenti di comando a un processo shell utilizzando la shell predefinita dell'utente. Questa shell supporta la pipeline, gli alias e la sintassi specifica della shell.

Nota

Il parametro ExecuteShellCommand utilizza la shell predefinita dell'utente che esegue il comando. Se è necessaria una shell specifica, utilizzare il parametro ExecuteCommand e aggiungere la shell richiesta come prefisso degli argomenti di comando.

Negli esempi seguenti viene illustrato come utilizzare i parametri ExecuteCommand e ExecuteShellCommand :

  • Per trasferire gli argomenti della riga di comando alla console senza avviare un processo shell:

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

  • Per trasferire gli argomenti della riga di comando a un processo shell che fa riferimento a una shell esplicita:

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

  • Per trasferire gli argomenti della riga di comando a un processo shell che utilizza la shell predefinita dell'utente:

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

Logging and Debugging

Questa sezione descrive come abilitare gli strumenti di registrazione e debug per la risoluzione dei problemi relativi al monitoraggio dei computer UNIX e Linux.

Nota

Con Operations Manager 2019 UR3, le impostazioni a livello di log possono essere modificate senza il riavvio dell'agente. Altre informazioni

Nota

È possibile modificare le impostazioni a livello di log senza il riavvio dell'agente. Altre informazioni

Abilitare la registrazione dei moduli di Operations Manager

Gli agenti di Operations Manager per UNIX e Linux gestiscono diversi file di log, che possono risultare utili per la risoluzione dei problemi dei client. Questi file di log si trovano nel computer gestito UNIX o Linux. Il livello di registrazione per i file di log dell'agente può essere configurato in base alle esigenze. La registrazione più dettagliata può essere utile per la diagnosi di un problema. Per l'operazione normale, i livelli di log non devono essere impostati su un valore più dettagliato rispetto alle configurazioni predefinite (Intermedio) per impedire una crescita eccessiva dei file di log.

Nota

Le chiamate effettuate all'esterno di Gestione remota Windows (WinRM) vengono effettuate mediante SSH/SFTP. Questi componenti si basano su un meccanismo di registrazione distinto rispetto a Operations Manager.

Nota

Il livello di registrazione per il file di log omiserver.log non può essere modificato dal valore predefinito in questa versione degli agenti di Operations Manager per UNIX e Linux.

  1. Creare un file vuoto denominato EnableOpsmgrModuleLogging nella directory Temp per l'account utente chiamando questi moduli digitando una riga di comando o un prompt di PowerShell:

    COPY /Y NUL %windir%\TEMP\EnableOpsMgrModuleLogging
    
    New-Item "$env:windir\TEMP\EnableOpsMgrModuleLogging"
    

    Nota

    In genere, è l'account SYSTEM che effettua le chiamate e C:\Windows\Temp è la cartella temp SYSTEM predefinita.

  2. Dopo la creazione del file vuoto, Operations Manager inizierà immediatamente a registrare l'attività SSH e Certificato nella directory Temp. Script che chiamano nel log dei moduli SSH per <Scriptname.vbs.log >. Altri moduli dispongono di specifici log.

In alcuni casi, potrebbe essere necessario riavviare HealthService per ottenere l'effetto della registrazione EnableOpsmgrModuleLogging.

Abilitare la registrazione nell'agente UNIX

Questi log segnalano le azioni dell'agente UNIX. Se si verifica un problema con i dati restituiti a Operations Manager, esaminare questo log. È possibile configurare la quantità di informazioni registrate con il comando scxadmin. La sintassi per questo comando è la seguente:

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

La tabella seguente elenca i valori possibili per i parametri:

Level Descrizione
Errors Registrazione dei soli messaggi di tipo Avviso o Errore .
Intermedio Informazioni di log, avvisi e messaggi di errore.
Dettagliato Registrazione dei messaggi di tipo Info, Avvisoed Errore con la registrazione debug. Si noti che questo livello di registrazione provocherà probabilmente un aumento rapido delle dimensioni dei file di log. È consigliabile usare questa opzione solo per brevi periodi di tempo per diagnosticare un problema specifico.

Usare DebugView per la risoluzione dei problemi di individuazione

DebugView è un metodo alternativo a EnableOpsmgrModuleLogging per la risoluzione dei problemi di individuazione.

  1. Scaricare DebugView dall'indirizzo: https://go.microsoft.comfwlink/?Linkid=129486.

  2. Avviare DebugView sul server di gestione che esegue l'individuazione.

  3. Avviare l'individuazione degli agenti UNIX. A questo punto si dovrebbe iniziare a vedere l'output nelle finestre di DebugView.

  4. DebugView presenterà una lettura dettagliata del processo dell'individuazione guidata. Questo metodo è spesso il più veloce per la risoluzione dei problemi di individuazione.

Abilitare la registrazione in Operations Manager per Gestione remota Windows

Questo metodo di traccia dettagliata consente di visualizzare le query di Gestione remota Windows (WinRM) usate da Operations Manager per raccogliere dati dall'agente. Se si sospetta che si verifichi un problema con la connessione WinRM, questo log fornisce informazioni dettagliate che consentono di risolvere i problemi.

  1. Nel server di gestione che esegue il monitoraggio dell'agente di UNIX o Linux, aprire un prompt dei comandi.

  2. Immettere i comandi seguenti al prompt dei comandi:

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

    2. StopTracing.cmd

    3. StartTracing.cmd VER

  3. Riprodurre il problema non risolto in Operations Manager.

  4. Immettere i comandi seguenti al prompt dei comandi:

    1. StopTracing.cmd

    2. FormatTracing.cmd

  5. Cercare WS-Man nel file TracingGuidsNative.log.

Nota

Gestione remota Windows è anche nota come WS-Management (WS-Man).

Nota

Il comando FormatTracing apre una finestra di Esplora finestre che visualizza la C:\Windows\Logs\OpsMgrTrace directory. Il file TracingGuidsNative.log si trova in tale directory.

Gestire file di log UNIX e Linux

Gli agenti di Operations Manager per UNIX e Linux non limitano le dimensioni dei file di log dell'agente. Per controllare le dimensioni massime dei file di log, implementare un processo per la gestione dei file di log. Ad esempio, l'utilità standard logrotate è disponibile in molti sistemi operativi UNIX e Linux. L'utilità logrotate può essere configurata in modo da controllare i file di log usati dagli agenti di Operations Manager per UNIX o Linux. Dopo la rotazione o la modifica dei file di log dell'agente, è necessario segnalare all'agente che i log sono stati ruotati, in modo da riprendere la registrazione. Il comando scxadmin può essere usato con il parametro -log-ruota con la sintassi seguente:

scxadmin -log-rotate all

File di configurazione di Logrotate di esempio

Nell'esempio seguente viene illustrato un file di configurazione per ruotare i file di scx.log e omiserver.log con l'utilità logrotate di Linux. In genere, logrotate verrà eseguito come processo pianificato (con crond) e agire sui file di configurazione trovati in /etc/logrotate.d. Per testare e usare questo file di configurazione, modificare la configurazione in modo appropriato per l'ambiente e collegare o salvare il file in /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\
#}  

Passaggi successivi

Per altre indicazioni per risolvere i problemi comuni di distribuzione dell'agente, vedere Il wiki di individuazione agente UNIX/Linux di Operations Manager 2012.