Eseguire la migrazione da System Center Operations Manager (SCOM) a Monitoraggio di Azure

  • Articolo

Questo articolo fornisce indicazioni per i clienti che attualmente usano System Center Operations Manager (SCOM) e pianificano una transizione al monitoraggio basato sul cloud con Monitoraggio di Azure durante la migrazione di applicazioni aziendali e altre risorse in Azure.

Non esiste un processo standard per la migrazione da SCOM e si può fare affidamento sui Management Pack SCOM per un periodo di tempo prolungato anziché eseguire una migrazione rapida. Questo articolo descrive le diverse opzioni disponibili e i criteri decisionali che è possibile usare per determinare la strategia migliore per l'ambiente specifico.

Monitoraggio del cloud ibrido

La maggior parte dei clienti usa una strategia di monitoraggio cloud ibrido che consente di eseguire una transizione graduale al cloud. Questo approccio consente di gestire i processi aziendali esistenti man mano che si ha familiarità con la nuova piattaforma. Spostarsi dalla funzionalità SCOM solo perché è possibile sostituirla con Monitoraggio di Azure. Più strumenti di monitoraggio aggiungono complessità, ma consente di sfruttare la capacità di Monitoraggio di Azure di monitorare i carichi di lavoro cloud di nuova generazione mantenendo al tempo stesso la capacità di SCOM di monitorare il software server e i carichi di lavoro.

L'ambiente prima di spostare tutti i componenti in Azure si basa su macchine virtuali e fisiche che si trovano in locale o con un provider di servizi gestiti. Si basa su SCOM per monitorare applicazioni aziendali, software server e altri componenti dell'infrastruttura nell'ambiente, ad esempio server fisici e reti. Si usano Management Pack standard per software server, ad esempio IIS, SQL Server e vari software fornitore, e si ottimizzano tali Management Pack per i requisiti specifici. I Management Pack personalizzati per le applicazioni e i componenti aziendali che non possono essere monitorati con i Management Pack esistenti e si configura anche SCOM per supportare i processi aziendali.

Quando si spostano i servizi nel cloud, Monitoraggio di Azure inizia a raccogliere le metriche della piattaforma e il log attività per ognuna delle risorse. È possibile creare impostazioni di diagnostica per raccogliere i log delle risorse in modo da poter analizzare in modo interattivo tutti i dati di telemetria disponibili usando query di log e informazioni dettagliate.

Durante questo periodo di transizione sono disponibili due strumenti di monitoraggio indipendenti. Si usano informazioni dettagliate e cartelle di lavoro per analizzare i dati di telemetria cloud nel portale di Azure mentre si usa ancora la Console operatore per analizzare i dati raccolti da SCOM. Poiché ogni sistema ha un proprio avviso, è necessario creare gruppi di azioni in Monitoraggio di Azure equivalenti ai gruppi di notifica in SCOM.

La tabella seguente descrive le diverse funzionalità e strategie disponibili per un ambiente di monitoraggio ibrido tramite SCOM e Monitoraggio di Azure.

metodo Descrizione
Agenti a doppio domicilio SCOM usa Microsoft Management Agent (MMA) che corrisponde all'agente di Log Analytics usato da Monitoraggio di Azure. È possibile configurare questo agente in modo che un singolo computer si connetta contemporaneamente sia a SCOM che a Monitoraggio di Azure. Questa configurazione richiede che le macchine virtuali di Azure abbiano una connessione ai server di gestione locali.

L'agente di Log Analytics è stato sostituito con l'agente di Monitoraggio di Azure, che offre vantaggi significativi, tra cui una gestione più semplice e un migliore controllo sulla raccolta dati. I due agenti possono coesistere nello stesso computer consentendo di connettersi sia a Monitoraggio di Azure che a SCOM. Questa configurazione è un'opzione migliore rispetto al dual-homing dell'agente legacy a causa dei vantaggi significativi dell'agente di Monitoraggio di Azure.
gruppo di gestione Connessione ed Connessione il gruppo di gestione SCOM a Monitoraggio di Azure per inoltrare i dati raccolti dagli agenti SCOM a Monitoraggio di Azure. Questo comportamento è simile all'uso di agenti dual homed, ma non richiede che ogni agente sia configurato per la connessione a Monitoraggio di Azure. Questa strategia richiede l'agente legacy, quindi non è possibile specificare il monitoraggio con le regole di raccolta dati. Non è anche possibile usare informazioni dettagliate sulle macchine virtuali, a meno che non si connetta ogni macchina virtuale direttamente a Monitoraggio di Azure.
Istanza gestita di SCOM (anteprima) L'istanza gestita di SCOM (anteprima) è un'implementazione completa di SCOM in Azure che consente di continuare a eseguire gli stessi Management Pack eseguiti nell'ambiente SCOM locale. Non esiste alcuna integrazione corrente tra i dati e gli avvisi di SCOM e Monitoraggio di Azure e si continua a usare la stessa console operatore per analizzare l'integrità e gli avvisi.

SCOM MI è simile alla gestione dell'ambiente SCOM esistente e degli agenti dualhoming, anche se è possibile consolidare la configurazione di monitoraggio in Azure e ritirare i componenti locali, ad esempio i server di database e di gestione. Gli agenti dalle macchine virtuali di Azure possono connettersi all'istanza gestita di SCOM in Azure anziché connettersi ai server di gestione nel proprio data center.
Management Pack di Azure Il Management Pack di Azure consente a Operations Manager di individuare le risorse di Azure e di monitorarne l'integrità in base a un determinato set di scenari di monitoraggio. Questo Management Pack richiede l'esecuzione di una configurazione aggiuntiva per ogni risorsa in Azure. Può essere utile anche se fornire una certa visibilità delle risorse di Azure nella Console operatore fino a quando non si evolveno i processi aziendali per concentrarsi su Monitoraggio di Azure.

Monitorare le applicazioni aziendali

In genere sono necessari Management Pack personalizzati per monitorare le applicazioni aziendali con SCOM, usando gli agenti installati in ogni macchina virtuale. Application Insights in Monitoraggio di Azure monitora le applicazioni basate sul Web che si trovano in Azure, in altri cloud o in locale. Può essere usato per tutte le applicazioni indipendentemente dal fatto che sia stata eseguita o meno la migrazione ad Azure.

Se il monitoraggio di un'applicazione aziendale è limitato alle funzionalità fornite dal modello di prestazioni delle app .NET in SCOM, è probabilmente possibile eseguire la migrazione ad Application Insights senza perdita di funzionalità. Application Insights include infatti un numero significativo di altre funzionalità, tra cui:

  • Individuare e monitorare automaticamente i componenti dell'applicazione.
  • Raccogliere dati dettagliati sull'utilizzo e sulle prestazioni delle applicazioni, ad esempio il tempo di risposta, le percentuali di errore e le tariffe delle richieste.
  • Raccogliere dati del browser, ad esempio visualizzazioni pagina e prestazioni di caricamento.
  • Rilevare le eccezioni ed esaminare la traccia dello stack e le richieste correlate.
  • Eseguire analisi avanzate usando funzionalità come la traccia distribuita e il rilevamento intelligente.
  • Usare Esplora metriche per analizzare in modo interattivo i dati sulle prestazioni.
  • Usare le query di log per analizzare in modo interattivo i dati di telemetria raccolti insieme ai dati raccolti per i servizi di Azure e le informazioni dettagliate sulle macchine virtuali.

Esistono tuttavia alcuni scenari in cui potrebbe essere necessario continuare a usare SCOM oltre ad Application Insights fino a quando non è possibile ottenere le funzionalità necessarie. Alcuni esempi in cui potrebbe essere necessario continuare con SCOM includono quanto segue:

  • I test di disponibilità, che consentono di monitorare e avvisare la disponibilità e la velocità di risposta delle applicazioni richiedono richieste in ingresso dagli indirizzi IP degli agenti di test Web. Se i criteri non consentono tale accesso, potrebbe essere necessario continuare a usare i monitoraggi della disponibilità delle applicazioni Web in SCOM.
  • In SCOM è possibile impostare qualsiasi intervallo di polling per i test di disponibilità, con molti clienti che controllano ogni 60-120 secondi. Application Insights ha un intervallo di polling minimo di cinque minuti, che potrebbe essere troppo lungo per alcuni clienti.
  • Una quantità significativa di monitoraggio in SCOM viene eseguita raccogliendo eventi generati dalle applicazioni e eseguendo script nell'agente locale. Queste non sono opzioni standard in Application Insights, quindi è possibile richiedere un lavoro personalizzato per soddisfare i requisiti aziendali. Ciò potrebbe includere regole di avviso personalizzate che usano i dati degli eventi archiviati in un'area di lavoro Log Analytics e gli script avviati in una macchina virtuale guest usando un ruolo di lavoro ibrido per runbook.
  • A seconda del linguaggio in cui è scritta l'applicazione, è possibile limitare la strumentazione che è possibile usare con Application Insights.

Seguendo la strategia di base nelle altre sezioni di questa guida, continuare a usare SCOM per le applicazioni aziendali, ma sfruttare le funzionalità aggiuntive fornite da Application Insights. Poiché è possibile sostituire le funzionalità critiche con Monitoraggio di Azure, è possibile iniziare a ritirare i Management Pack personalizzati.

Monitorare le macchine virtuali

Il monitoraggio del software nelle macchine virtuali in un ambiente ibrido usa spesso una combinazione di Monitoraggio di Azure e SCOM, a seconda dei requisiti dei carichi di lavoro in esecuzione nelle macchine virtuali. Non appena viene creata una macchina virtuale in Azure, le metriche della piattaforma e i log attività per l'host della macchina virtuale iniziano automaticamente a essere raccolti. Abilitare gli avvisi consigliati per notificare errori comuni per l'host della macchina virtuale, ad esempio il server inattivo e l'utilizzo elevato della CPU.

Abilitare le informazioni dettagliate sulle macchine virtuali per installare l'agente di Monitoraggio di Azure e iniziare a raccogliere dati sulle prestazioni comuni dal sistema operativo client. Ciò può sovrapporsi ad alcuni dati già raccolti in SCOM, ma consente di iniziare a visualizzare le tendenze nel tempo e monitorare le macchine virtuali di Azure con altre risorse cloud. È anche possibile scegliere di abilitare la funzionalità di mappa che fornisce informazioni dettagliate sui processi in esecuzione nelle macchine virtuali e sulle relative dipendenze da altri servizi.

Continuare a usare i Management Pack per le funzionalità che non possono essere fornite da altre funzionalità in Monitoraggio di Azure. Sono inclusi i Management Pack per software server critico, ad esempio IIS, SQL Server o Exchange. È anche possibile che siano stati sviluppati Management Pack personalizzati per l'infrastruttura locale che non è possibile raggiungere con Monitoraggio di Azure. Continuare a usare SCOM anche se è strettamente integrato nei processi operativi fino a quando non è possibile passare alla modernizzazione delle operazioni del servizio in cui Monitoraggio di Azure e altri servizi di Azure possono aumentare o sostituire.

Nota

Se si abilitaNo informazioni dettagliate macchina virtuale con l'agente di Log Analytics anziché con l'agente di Monitoraggio di Azure, non è necessario installare alcun agente aggiuntivo nella macchina virtuale. L'agente di Monitoraggio di Azure è consigliato anche se grazie ai miglioramenti significativi apportati al monitoraggio della macchina virtuale nel cloud. La complessità della gestione di più agenti è compensata dalla possibilità di definire il monitoraggio nelle regole di raccolta dati che consentono di configurare una raccolta di dati diversa per diversi set di macchine virtuali, analogamente alla strategia per la progettazione dei Management Pack.

Eseguire la migrazione della logica del Management Pack per i carichi di lavoro delle macchine virtuali

Non sono disponibili strumenti di migrazione per convertire i Management Pack SCOM in Monitoraggio di Azure perché la logica è fondamentalmente diversa rispetto alla raccolta di dati di Monitoraggio di Azure. La migrazione della logica del Management Pack è in genere incentrata sull'analisi dei dati raccolti da SCOM e sull'identificazione degli scenari di monitoraggio che possono essere replicati da Monitoraggio di Azure. Quando si personalizza Monitoraggio di Azure per soddisfare i requisiti per applicazioni e componenti diversi, è possibile iniziare a ritirare diversi Management Pack e agenti legacy in SCOM.

I Management Pack in SCOM contengono regole e monitoraggi che combinano la raccolta di dati e l'avviso risultante in un singolo flusso di lavoro end-to-end. I dati già raccolti da SCOM vengono usati raramente per l'invio di avvisi. Monitoraggio di Azure separa la raccolta dati e gli avvisi in processi separati. Le regole di avviso accedono ai dati dai log di Monitoraggio di Azure e dalle metriche di Monitoraggio di Azure già raccolti dagli agenti. Inoltre, le regole e i monitoraggi sono in genere strettamente incentrati su dati specifici, ad esempio un determinato evento o contatore delle prestazioni. Le regole di raccolta dei dati in Monitoraggio di Azure in genere raccolgono più set di eventi e contatori delle prestazioni in un singolo DCR.

Per indicazioni sulla creazione di raccolta dati e avvisi per scenari di monitoraggio comuni, vedere il contenuto seguente:

Anziché tentare di replicare l'intera funzionalità di un Management Pack, analizzare il monitoraggio critico fornito da ognuno di essi. Decidere se è possibile replicare tali requisiti di monitoraggio usando metodi alternativi. In molti casi, è possibile configurare le regole di raccolta dati e di avviso in Monitoraggio di Azure che replicano funzionalità sufficienti che è possibile ritirare un Management Pack specifico. I Management Pack possono spesso includere centinaia e persino migliaia di regole e monitoraggi.

Una strategia consiste nell'concentrarsi su tali monitoraggi e regole che hanno attivato avvisi nell'ambiente in uso. Fare riferimento ai report esistenti disponibili in Operations Manager, ad esempio Avvisi e Avvisi più comuni, che consentono di identificare gli avvisi nel tempo. È anche possibile eseguire la query seguente nel database operativo per valutare gli avvisi più comuni.

select AlertName, COUNT(AlertName) as 'Total Alerts' from
Alert.vAlertResolutionState ars
inner join Alert.vAlertDetail adt on ars.AlertGuid = adt.AlertGuid
inner join Alert.vAlert alt on ars.AlertGuid = alt.AlertGuid
group by AlertName
order by 'Total Alerts' DESC

Valutare l'output per identificare avvisi specifici per la migrazione. Ignorare tutti gli avvisi ottimizzati o che sono noti come problematici. Esaminare i Management Pack per identificare eventuali avvisi critici di interesse che non sono mai stati attivati.

Transazioni sintetiche

I Management Pack spesso usano transazioni sintetiche che si connettono a un'applicazione o a un servizio in esecuzione in un computer per simulare una connessione utente o il traffico utente effettivo. Se l'applicazione è disponibile, è possibile presupporre che il computer sia in esecuzione correttamente. I test di disponibilità di Application Insights in Monitoraggio di Azure offrono questa funzionalità. Funziona solo per le applicazioni accessibili da Internet. Per le applicazioni interne, è necessario aprire un firewall per consentire l'accesso da URL Microsoft specifici che eseguono il test. In alternativa, è possibile continuare a usare il Management Pack esistente.

Passaggi successivi