Agenti di Operations Manager

  • Articolo

Importante

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

In System Center Operations Manager un agente è un servizio installato in un computer che cerca i dati di configurazione e raccoglie in modo proattivo le informazioni per l'analisi e la creazione di report, misura lo stato di integrità degli oggetti monitorati, ad esempio un database SQL o un disco logico, ed esegue attività su richiesta da un operatore o in risposta a una condizione. Consente a Operations Manager di monitorare i sistemi operativi Windows, Linux e UNIX e i componenti di un servizio IT installato in essi, ad esempio un sito Web o un controller di dominio Active Directory.

Agente Windows

In un computer Windows monitorato, l'agente operations manager è elencato come servizio Microsoft Monitoring Agent (MMA). Il servizio Microsoft Monitoring Agent raccoglie dati sugli eventi e le prestazioni ed esegue attività e altri flussi di lavoro definiti in un Management Pack. Anche quando tale servizio non è in grado di comunicare con il server di gestione a cui invia i report, la sua esecuzione continua ed esso continua ad accodare i dati e gli eventi raccolti sul disco del computer monitorato. Quando la connessione viene ripristinata, il servizio Microsoft Monitoring Agent invia al server di gestione i dati e gli eventi raccolti.

Nota

  • Il servizio Microsoft Monitoring Agent viene talvolta denominato Servizio integrità.

Il servizio Microsoft Monitoring Agent viene eseguito anche nei server di gestione. In un server di gestione, il servizio esegue flussi di lavoro di monitoraggio e gestisce le credenziali. Per eseguire i flussi di lavoro, il servizio avvia i processi MonitoringHost.exe usando le credenziali specificate. Questi processi eseguono il monitoraggio e la raccolta dei dati del registro eventi, i dati del contatore delle prestazioni, i dati di Strumentazione gestione Windows (WMI), e infine eseguono azioni come gli script.

Comunicazione tra gli agenti e i server di gestione

L'agente di Operations Manager invia i dati di avviso e individuazione al server di gestione primario assegnato, che scrive i dati nel database operativo. L'agente inoltre invia i dati di eventi, prestazioni e stato al server di gestione primario di tale agente, che scrive i dati contemporaneamente sul database operativo e su quello del data warehouse.

L'agente invia i dati in base ai parametri di pianificazione per ogni regola e monitoraggi. Per avere regole di raccolta ottimizzata, i dati vengono trasmessi solo se un campione di contatore differisce dal precedente campione secondo una tolleranza specificata, ad esempio il 10%. Si riducono così il traffico di rete e il volume di dati memorizzati nel database operativo.

Inoltre, tutti gli agenti inviano periodicamente un pacchetto di dati, denominato heartbeat, al server di gestione in uso (per impostazione predefinita, ogni 60 secondi). Lo scopo dell'heartbeat è di convalidare la disponibilità dell'agente e la comunicazione tra l'agente e il server di gestione. Per ulteriori informazioni sugli heartbeat, vedere How Heartbeats Work in Operations Manager (Come funzionano gli heartbeat in Operations Manager).

Per ogni agente, Operations Manager esegue un controllo servizio integritàche esegue il monitoraggio dello stato del servizio integrità remoto dalla prospettiva del server di gestione. L'agente comunica con un server di gestione tramite la porta TCP 5723.

Illustrazione della comunicazione tra agente e server di gestione.

Agente Linux/UNIX

L'architettura dell'agente UNIX e Linux differisce in misura significativa da quella di un agente Windows. L'agente Windows dispone di un Servizio integrità responsabile della valutazione dell'integrità del computer monitorato. L'agente UNIX e Linux non esegue un servizio di integrità; passa invece le informazioni al servizio integrità in un server di gestione da valutare. Il server di gestione esegue tutti i flussi di lavoro per il monitoraggio dell'integrità del sistema operativo definiti nell'implementazione dei Management Pack UNIX e Linux:

  • Disco
  • Processore
  • Memoria
  • Schede di rete
  • Sistema operativo
  • Processi
  • File di log

Gli agenti UNIX e Linux per Operations Manager sono costituiti da un'istanza di CIM Object Manager (ossia un server CIM) e da un set di provider CIM. Gestione oggetti CIM è il componente server che implementa la comunicazione WS-Management, l'autenticazione, l'autorizzazione e l'invio di richieste ai provider. I provider svolgono un ruolo chiave nell'implementazione di CIM nell'agente perché definiscono le classi e le proprietà CIM, eseguono l'interfacciamento con le API del kernel per il recupero dei dati non elaborati, formattano i dati (ad esempio calcolano i delta e le medie) e gestiscono le richieste inviate da CIM Object Manager. Da System Center Operations Manager 2007 R2 fino a System Center 2012 SP1, l'istanza di CIM Object Manager usata negli agenti UNIX e Linux di Operations Manager è il server OpenPegasus. I provider usati per raccogliere i dati di monitoraggio e creare i relativi report sono sviluppati da Microsoft e sono disponibili in modalità open source in CodePlex.com.

Illustrazione dell'architettura software dell'agente UNIX/Linux di Operations Manager.

L'architettura è stata modificata in System Center 2012 R2 Operations Manager. Gli agenti UNIX e Linux sono ora basati su un'implementazione di OMI (Open Management Infrastructure) completamente coerente come l'istanza di CIM Object Manager. Nel caso degli agenti UNIX/Linux di Operations Manager, OMI sostituisce OpenPegasus. Come OpenPegasus, OMI è un'implementazione open source, leggera e portabile di CIM Object Manager, anche se è più leggera e più portabile di OpenPegasus. Questa implementazione è ancora applicata in System Center 2016 - Operations Manager e versioni successive.

Diagramma dell'architettura software aggiornata dell'agente UNIX/Linux di Operations Manager.

La comunicazione tra il server di gestione e l'agente UNIX e Linux è suddivisa in due categorie: manutenzione dell'agente e monitoraggio dell'integrità. Il server di gestione usa due protocolli per comunicare con un computer UNIX o Linux:

  • SSH (Secure Shell) e SFTP (Secure Shell File Transfer Protocol)

    Usato per attività di manutenzione dell'agente quali l'installazione, l'aggiornamento e la rimozione di agenti.

  • Web Services for Management (WS-Management)

    Utilizzato per tutte le operazioni di monitoraggio e l'individuazione degli agenti già installati.

La comunicazione tra il server di gestione di Operations Manager e l'agente UNIX e Linux avviene mediante WS-Man su HTTPS e l'interfaccia WinRM. Tutte le attività di manutenzione dell'agente vengono eseguite su SSH sulla porta 22. Tutte le attività di monitoraggio dell'integrità vengono eseguite su WS-MAN sulla porta 1270. Il server di gestione richiede dati sulle prestazioni e la configurazione tramite WS-MAN prima di eseguirne la valutazione per fornire lo stato di integrità. Tutte le operazioni, quali la manutenzione degli agenti, i monitoraggi, le regole, le attività e i ripristini, sono configurate per utilizzare i profili predefiniti in base all'account richiesto, ossia con o senza privilegi.

Nota

Tutte le credenziali indicate in questo articolo sono relative agli account stabiliti nel computer UNIX o Linux, non agli account di Operations Manager configurati durante l'installazione di Operations Manager. Per ottenere le credenziali e le informazioni di autenticazione, contattare l'amministratore di sistema.

Per supportare i nuovi miglioramenti della scalabilità per i numerosi sistemi UNIX e Linux monitorabili con System Center 2016 Operations Manager e versioni successive per ogni server di gestione, sono disponibili le nuove API Windows Management Infrastructure (MI) asincrone invece delle API WSMAN sincrone, usate per impostazione predefinita. Per abilitare questa modifica, è necessario creare la nuova chiave del Registro di sistema UseMIAPI per consentire a Operations Manager di usare le nuove API MI asincrone nei server di gestione che monitorano i sistemi UNIX/Linux.

  1. Aprire il Registro di sistema Editor da un prompt dei comandi con privilegi elevati.
  2. Creare la chiave del Registro di sistema UseMIAPI in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup.

Se è necessario ripristinare la configurazione originale usando le API di sincronizzazione WSMAN, è possibile eliminare la chiave del Registro di sistema UseMIAPI .

Sicurezza degli agenti

Autenticazione su un computer UNIX/Linux

In Operations Manager non è più necessario che l'amministratore di sistema fornisca la password radice del computer UNIX o Linux al server di gestione. Tramite il processo di elevazione, un account senza privilegi può ora assumere l'identità di un account con privilegi sul computer UNIX o Linux. Il processo di elevazione viene eseguito dall'account su (utente con privilegi avanzati) UNIX e dai programmi sudo che utilizzano le credenziali fornite dal server di gestione. Per le operazioni di manutenzione agente con privilegi in cui viene utilizzato SSH (quali l'individuazione, la distribuzione, gli aggiornamenti, la disinstallazione e il ripristino agente) viene fornito supporto per su, l'elevazione sudo e l'autenticazione tramite codice SSH (con o senza passphrase). Per le operazioni di WS-Management con privilegi, (ad esempio la visualizzazione dei file di registro protetti), viene aggiunto supporto per l'elevazione sudo (senza password).

Per istruzioni dettagliate sulla specifica delle credenziali e la configurazione degli account, vedere How to Set Credentials for Accessing UNIX and Linux Computers (Come impostare le credenziali per l'accesso a computer UNIX e Linux).

Autenticazione con il server gateway

I server gateway vengono usati per consentire la gestione tramite agenti dei computer che si trovano al di fuori del limite di trust Kerberos di un gruppo di gestione. Poiché il server gateway risiede in un dominio non attendibile dal dominio in cui si trova il gruppo di gestione, i certificati devono essere usati per stabilire l'identità, l'agente, il server gateway e il server di gestione di ogni computer. In questo modo vengono soddisfatti i requisiti di Operations Manager per l'autenticazione reciproca.

Per questo è necessario richiedere i certificati per ogni agente che fa riferimento a un server gateway e importare i certificati nel computer di destinazione usando lo strumento MOMCertImport.exe, disponibile nella directory SupportTools\ (amd64 o x86) dei supporti di installazione. È necessario avere accesso a un'autorità di certificazione (CA), che può essere una CA pubblica, ad esempio VeriSign, oppure è possibile usare i servizi certificati Microsoft.

Distribuzione degli agenti

È possibile installare gli agenti di System Center Operations Manager usando uno dei tre metodi seguenti. La maggior parte delle installazioni usa una combinazione di questi metodi per installare diversi set di computer, se necessario.

Nota

  • Non è possibile installare MMA in un computer in cui è installato il server di gestione di Operations Manager, il server gateway, la console operatore, il database operativo, la console Web, System Center Essentials o System Center Service Manager, perché è già installata la versione predefinita di MMA.
  • È possibile usare solo MMA o l'agente di Log Analytics (versione dell'estensione macchina virtuale).
  • Individuazione e installazione di uno o più agenti dalla Console operatore. Questa è la forma di installazione più comune. Un server di gestione deve essere in grado di connettersi al computer con RPC. L'account azione del server di gestione o altre credenziali fornite devono avere accesso amministrativo al computer di destinazione.
  • Inclusione nell'immagine di installazione. Si tratta di un'installazione manuale in un'immagine di base che viene usata per la preparazione di altri computer. In questo caso, l'integrazione di Active Directory può essere usata per assegnare automaticamente il computer a un server di gestione al momento dell'avvio iniziale.
  • Installazione manuale. Questo metodo viene usato quando l'agente non può essere installato da uno degli altri metodi, ad esempio quando la chiamata di routine remota (RPC) non è disponibile a causa di un firewall. La configurazione viene eseguita manualmente sull'agente o quest'ultimo viene installato mediante un software di distribuzione esistente.

Gli agenti installati tramite l'individuazione guidata possono essere gestiti dalla console operatore, ad esempio l'aggiornamento delle versioni dell'agente, l'applicazione di patch e la configurazione del server di gestione a cui l'agente segnala.

Quando si installa l'agente utilizzando un metodo manuale, è necessario eseguire manualmente anche gli aggiornamenti dell'agente. Sarà possibile usare l'integrazione di Active Directory per assegnare agenti ai gruppi di gestione. Per altre informazioni, vedere Integrazione di Active Directory e Operations Manager.

Selezionare la scheda necessaria per altre informazioni sulla distribuzione dell'agente nei sistemi Windows e UNIX e LINUX:

Per l'individuazione di un sistema Windows è necessario che le porte TCP 135 (RPC), quelle dell'intervallo RPC e TCP 445 (SMB) rimangano aperte e che il servizio SMB sia abilitato nel computer dell'agente.

  • Una volta individuato un dispositivo di destinazione, è possibile distribuirvi un agente. Per l'installazione degli agenti è necessario quanto segue:
  • Apertura delle porte RPC a partire dall'agente di mapping degli endpoint TCP 135 e della porta Server Message Block (SMB) TCP/UDP 445.
  • Abilitazione dei servizi Condivisione file e stampanti per le reti Microsoft e Client per i servizi di rete Microsoft. Questo garantisce che la porta SMB sia attiva.
  • Se attivate, le impostazioni dei criteri di gruppo "Windows Firewall: Consenti eccezione per amministrazione remota" e "Windows Firewall: Consenti eccezione condivisione file e stampanti" devono essere impostate su "Consenti messaggi in ingresso non richiesti da:" indirizzo IP e subnet per i server di gestione primario e secondario per l'agente.
  • Un account con diritti di amministratore locale per il computer di destinazione.
  • Windows Installer 3.1. Per l'installazione, vedere l'articolo 893803 della Microsoft Knowledge Base https://go.microsoft.com/fwlink/?LinkId=86322
  • Microsoft Core XML Services (MSXML) 6 nella sottodirectory \msxml dei supporti di installazione del prodotto Operations Manager. L'installazione dell'agente push installa MSXML 6 nel dispositivo di destinazione se non è già installato.

Assegnazione di agenti di Active Directory

System Center Operations Manager consente di sfruttare l'investimento in Active Directory Domain Services usando tali servizi per assegnare i computer gestiti tramite agente ai gruppi di gestione. Questa funzionalità viene comunemente usata con l'agente distribuito come parte di un processo di compilazione della distribuzione del server. Quando il computer è online per la prima volta, l'agente di Operations Manager invia una query ad Active Directory per l'assegnazione del server di gestione primario e di failover e inizia automaticamente a monitorare il computer.

Per assegnare computer a gruppi di gestione mediante Servizi di dominio Active Directory:

  • Il livello di funzionalità dei domini di Active Directory Domain Services deve essere Windows 2008 nativo o versione successiva
  • I computer gestiti tramite agenti e tutti i server di gestione devono trovarsi nello stesso dominio o in domini con trust bidirezionale.

Nota

Un agente che determina che è installato in un controller di dominio non eseguirà query su Active Directory per le informazioni di configurazione. Questo avviene per motivi di sicurezza. L'integrazione di Active Directory è disabilitata per impostazione predefinita sui controller di dominio perché l'agente viene eseguito usando l'account di sistema locale. L'account di sistema locale su un controller di dominio dispone dei privilegi di amministratore di dominio. Di conseguenza, individua tutti i punti di connessione del servizio del server di gestione registrati in Active Directory, indipendentemente dall'appartenenza al gruppo di sicurezza del controller di dominio. Come risultato, l'agente tenta di connettersi a tutti i server di gestione di tutti i gruppi di gestione. I risultati possono essere imprevedibili e rappresentano quindi un rischio per la sicurezza.

L'assegnazione degli agenti viene eseguita usando un punto di connessione del servizio. Si tratta di un oggetto di Active Directory per la pubblicazione di informazioni che le applicazioni client possono usare per l'associazione a un servizio. Viene creato da un amministratore di dominio che, con lo strumento da riga di comando MOMADAdmin.exe, crea un contenitore di Active Directory Domain Services per un gruppo di gestione di Operations Manager nei domini dei computer da gestire. Il gruppo di sicurezza di Active Directory Domain Services specificato durante l'esecuzione diMOMADAdmin.exe viene concesso le autorizzazioni Read and Delete Child per il contenitore. Il punto di connessione del servizio contiene informazioni per la connessione al server di gestione, incluso il nome di dominio completo e il numero di porta del server. Gli agenti di Operations Manager possono individuare automaticamente i server di gestione eseguendo una query relativa ai punti di connessione del servizio. L'ereditarietà non è disabilitata e poiché un agente può leggere le informazioni di integrazione registrate in AD, se si forza l'ereditarietà per il gruppo Tutti per leggere tutti gli oggetti a livello radice in Active Directory, ciò influisce gravemente e interrompe essenzialmente le funzionalità di integrazione di Active Directory. Se si forza esplicitamente l'ereditarietà nell'intera directory concedendo le autorizzazioni di lettura del gruppo Tutti, è necessario bloccare questa ereditarietà nel contenitore di integrazione active directory di primo livello, denominato OperationsManager e tutti gli oggetti figlio.  Se non è possibile eseguire questa operazione, l'integrazione di ACTIVE Directory non funzionerà come progettato e non sarà disponibile un'assegnazione primaria e coerente e coerente per gli agenti distribuiti. Se in più succede che il gruppo di gestione sia più di uno, tutti gli agenti dei gruppi di gestione saranno multihomed. 

Questa funzionalità risulta utile per il controllo dell'assegnazione degli agenti in un'installazione distribuita di gruppi di gestione. In questo modo, si impedisce agli agenti di fare riferimento a server di gestione dedicati a pool di risorse o a server di gestione presenti in un data center secondario in una configurazione warm standby, evitando così il failover degli agenti durante il normale funzionamento.

La configurazione dell'assegnazione degli agenti è gestita da un amministratore di Operations Manager tramite l'Assegnazione e failover guidati agenti, che consente di assegnare i computer a un server di gestione primario e secondario.

Nota

L'integrazione di Active Directory viene disabilitata per gli agenti installati dalla Console operatore. Per impostazione predefinita, Integrazione Active Directory viene installato manualmente tramite MOMAgent.msi.

Passaggi successivi