Archivi categoria: Azure Monitor

Azure management services e System Center: novità di Gennaio 2019

Il nuovo anno è iniziato con diversi annunci da parte di Microsoft riguardanti novità relative agli Azure management services e a System Center. La Cloud Community rilascia mensilmente questo riepilogo, che consente di avere una panoramica complessiva delle principali novità del mese, in modo da rimanere sempre aggiornati su questi argomenti ed avere i riferimenti necessari per condurre eventuali approfondimenti.

Come già annunciato nei mesi scorsi, le funzionalità di monitoring, management, e security di Operations Management Suite (OMS) sono state incluse nel portale Azure. Dal 15 gennaio 2019 il portale OMS è stato ufficialmente ritirato e tutte le funzionalità sono usufruibili dal portale Azure.

Azure Monitor

Azure Monitor logs in Grafana

Per Azure Monitor è stato annunciato un nuovo pluging per effettuare l’integrazione con Grafana. Grazie a questo pluging è possibile consultare in modo semplice e intuitivo qualsiasi dato raccolto in Log Analytics. Il plugin richiede almeno la versione 5.3 di Grafana e tramite le API di Log Analytics recupera le informazioni direttamente dal workspace, rendendole usufruibili direttamente dalle dashboard di Grafana. Per maggiori informazioni è possibile consultare la documentazione ufficiale Microsoft.

Figura 1 – Integrazione di Log Analytics in Grafana

Azure Monitor per containers

Durante il mese di gennaio l’agente di Azure Monitor per containers (build version 01/09/19) è stato aggiornato per introdurre miglioramenti nella stabilità e nelle performance. L’agente in ambienti cluster Azure Kubernetes Service (AKS) sarà aggiornato automaticamente. Per maggiori informazioni a riguardo è possibile consultare le release notes dell’agente.

Azure Security Center

Nuova dashboard sulle conformità normative

In Azure Monitor è stata resa disponibile una nuova dashboard che riporta lo stato di compliance dell’ambiente rispetto a specifici standard e normative. Al momento gli standard supportati sono: Azure CIS, PCI DSS 3.2, ISO 27001, e SOC TSP. Nella dashboard viene riportato il punteggio complessivo di conformità e il dettaglio delle valutazioni che riporta lo stato di conformità rispetto a ogni standard.

Figura 2 – Regulatory compliance dashboard in Azure Security Center

Azure Backup

Introdotto il supporto per PowerShell e per le ACLs per Azure Files

Nello scenario di protezione delle Azure file shares utilizzando Azure Backup sono state introdotte le seguenti funzionalità:

Azure Site Recovery

Nuovo Update Rollup

Per Azure Site Recovery è stato rilasciato l’Update Rollup 32 che introduce nuove versioni per i seguenti componenti:

  • Microsoft Azure Site Recovery Unified Setup (versione 9.21.5091.1): utilizzato per scenari di replica da VMware verso Azure.
  • Microsoft Azure Site Recovery Provider (versione 5.1.3800.0): utilizzato per scenari di replica da Hyper-V verso Azure oppure verso un secondary site.
  • Microsoft Azure Recovery Services Agent (versione 2.0.9144.0): utilizzato per scenari di replica da Hyper-V verso Azure.

L’installazione di questo update rollup è possibile su tutti i sistemi con installato Microsoft Azure Site Recovery Service Provider, includendo:

  • Microsoft Azure Site Recovery Provider per System Center Virtual Machine Manager (3.3.x.x).
  • Microsoft Azure Site Recovery Hyper-V Provider (4.6.x.x).
  • Microsoft Azure Site Recovery Provider (5.1.3400.0) e versioni successive.

L’Update Rollup 31 per Microsoft Azure Site Recovery Unified Setup si applica a tutti i sistemi che hanno installato la versione 9.17.4860.1 o successive.

Per ottenere maggiori informazioni sulle problematiche risolte, sugli improvements dati da questo Update Rollup e per ottenere la procedura da seguire per la relativa installazione è possibile consultare la KB specifica 4485985.

Nuovi statement di supporto

In Azure Site Recovery sono state recentemente inclusi i seguenti miglioramenti:

  • Supporto per server fisici con boot di tipologia UEFI. Nonostante in Azure non siano supportate VMs con dischi di boot UEFI, ASR è in grado di gestire la migrazione di questi sistemi effettuando una conversione della tipologia di boot in BIOS, anche per i server fisici e non solo per quelli virtuali. Tale funzionalità è solo per macchine virtuali Windows (Windows Server 2012 R2 e successivo).
  • Supporto per sistemi che hanno directory di sistema ( /[root], /boot, /usr, etc.) anche su dischi differenti rispetto a quello dell’OS e supporto di /boot su volume LVM.
  • Esteso il supporto per la migrazione dei server da AWS anche per i seguenti SO: RHEL 6.5+, RHEL 7.0+, CentOS 6.5+ e CentOS 7.0+

System Center

System Center Configuration Manager

Versione 1901 per il branch Technical Preview di System Center Configuration Manager.

Tra le principali novità di questa release troviamo una nuova dashboard interattiva di client health che riporta una overview dello stato di salute dei client ed errori comuni presenti nel proprio ambiente, con la possibilità di applicare filtri per escludere i client offline e obsoleti.

Figura 3  – Nuova dashboard di Client Health

Per tutti i dettagli riguardanti le novità incluse in questa release è possibile consultare questo documento. Si ricorda che i rilasci nel Technical Preview Branch consentono di valutare in anteprima le nuove funzionalità di SCCM ed è consigliato applicare questi aggiornamenti solo in ambienti di test.

System Center Operations Manager

Management Packs

In seguito, si riportano le novità riguardanti i seguenti Management Pack di SCOM:

  • Microsoft System Center 2016 Management Pack per Microsoft Azure version 1.6.0.7
  • Microsoft System Center Management Pack per SQL Server 2017+ Reporting Services version 7.0.12.0
  • Log Analytics Management Pack per SCOM 1801 versione 7.3.13288.0 e SCOM 2016 versione 7.2.12074.0

Valutazione di Azure e System Center

Per testare e valutare in modo gratuito i servizio offerti da Azure è possibile accedere a questa pagina, mentre per provare i vari componenti di System Center è necessario accedere all’Evaluation Center e, dopo essersi registrati, è possibile avviare il periodo di trial.

OMS e System Center: novità di Dicembre 2018

Nel mese di dicembre sono state annunciate, da parte di Microsoft, un numero importante di novità riguardanti gli Azure management services e System Center. La nostra community rilascia mensilmente questo riepilogo che consente di avere una panoramica complessiva delle principali novità del mese, in modo da rimanere sempre aggiornati su questi argomenti ed avere i riferimenti necessari per condurre eventuali approfondimenti.

Azure Monitor

Il servizio Azure Monitor per containers è ora disponibile per monitorare lo stato di salute e le performance di cluster Kubernetes ospitati su Azure Kubernetes Service (AKS). Azure Monitor per containers consente di avere una visibilità completa sulle prestazioni, raccogliendo delle metriche sulla memoria e sul processore dei controllers, dei nodi e dei containers. Vengono raccolti inoltre anche i log dei container. Dopo aver abilitato il monitor dei cluster di Kubernetes, le metriche e i log vengono raccolti automaticamente tramite una versione per container dell’agente di Log Analytics per Linux e vengono archiviati in un workspace di Log Analytics.

Nel corso degli ultimi mesi le soluzioni di monitoring, management e sicurezza, usufruibili dal portale di Operations Management Suite (OMS), sono state incorporate nel portale Azure. A partire dal 15 gennaio 2019 il portale OMS sarà definitivamente ritirato e sarà necessario utilizzare il portale Azure. Prima di questa data è opportuno portare a termine le seguenti operazioni:

Per maggiori dettagli è possibile fare riferimento a questo documento Microsoft.

Azure Log Analytics, ora parte di Azure Monitor, è ora disponibile anche nella region Azure di West US 2.

Nel mese di gennaio selezionando viste e solution Log Analytics, sarà utilizzata la nuova Azure Monitor Logs UX, che consente di ottenere un editor di query più funzionale e miglioramenti nelle viste.

Azure Site Recovery

Per Azure Site Recovery è stato rilasciato l’Update Rollup 31 che introduce nuove versioni per i seguenti componenti:

  • Microsoft Azure Site Recovery Unified Setup (version: 9.20.5051.1): utilizzato per scenari di replica da VMware verso Azure.
  • Microsoft Azure Site Recovery Provider (version 5.1.3700.0): utilizzato per scenari di replica da Hyper-V verso Azure oppure verso un secondary site.
  • Microsoft Azure Recovery Services Agent (version 2.0.9144.0): utilizzato per scenari di replica da Hyper-V verso Azure.

L’installazione di questo update rollup è possibile su tutti i sistemi con installato Microsoft Azure Site Recovery Service Provider, includendo:

  • Microsoft Azure Site Recovery Provider per System Center Virtual Machine Manager (3.3.x.x).
  • Microsoft Azure Site Recovery Hyper-V Provider (4.6.x.x).
  • Microsoft Azure Site Recovery Provider (5.1.3300.0) e versioni successive.

L’Update Rollup 31 per Microsoft Azure Site Recovery Unified Setup si applica a tutti i sistemi che hanno installato la versione 9.16.4860.1 o successive.

Per ottenere maggiori informazioni sulle problematiche risolte, sugli improvements dati da questo Update Rollup e per ottenere la procedura da seguire per la relativa installazione è possibile consultare la KB specifica 4478871.

In Azure Site Recovery è stata inoltre introdotta la possibilità di aggiornare in automatico il Mobility Agent installato a bordo delle macchine virtuali di Azure, nello scenario di replica di VMs in Azure. Considerando che Azure Site Recovery rilascia mensilmente un aggiornamento che introduce miglioramenti e nuove funzionalità, la possibilità di mantenere l’infrastruttura aggiornata in automatico risulta particolarmente comoda. Questi aggiornamenti non richiedono il riavvio delle macchine virtuali e non hanno impatti sulla replica dei sistemi. Abilitando l’update automatico, il processo avviene tramite un runbook, all’interno di un automation account, creato nella stessa subscription del vault. Di dafult il runbook viene eseguito alle 12:00 AM, ma la schedulazione può essere modificata a piacimento.

Figura 1 – Abilitazione dell’update automatico in fase di attivazione

Figura 2 – Abilitazione dell’update automatico a livello di Revovery Service vault

Un’altra importante funzionalità introdotta in Azure Site Recovery è la possibilità di replicare ed effettuare il failover verso altre region di macchine virtuali che appartengono ad Availability Zones. Tale funzionalità è stata resa disponibile per tutte le region Azure che supportano le Availability Zones.

Azure Backup

In Azure backup è stata semplifica la procedura per effettuare i restore di macchine virtuali, introducendo la funzionalità In-Place restore of disks, che consente di ripristinare i dischi di una macchina virtuale, senza la necessità di creare un nuovo sistema. Per farlo è sufficiente selezionare la seguente opzione in fase di ripristino:

Figura 3 – In-Place restore dal portale Azure

Al momento questa funzionalità è supportata solo per le VMs managed unencrypted. Non c’è al momento il supporto per le generalized VMs e per le VMs create utilizzando custom images, ma tale funzionalità è sicuramente destinata ad aumentare le funzionalità.

In Azure Backup c’è la possibilità di attivare la protezione di SQL Server installato a bordo di una macchina virtuale Azure. In questo ambito è stata aggiunta la funzionalità di auto-protection che, se attivata, consente di fare il discovery e la protezione di tutti i database che saranno aggiunti su quella istanza di SQL Server, standalone oppure in un Always On availability group.

Figura 4 – Auto-protect SQL databases con Azure Backup

System Center

System Center Virtual machine Manager

L’installazione dei seguenti aggiornamenti ‘KB4467684‘, ‘KB4478877‘, ‘KB4471321‘ oppure ‘KB4483229’ su un host Windows Server 2016 gestito da SCVMM, può comportare che SCVMM non sia più in grado di enumerare oppure gestire i Logical Switch configurati sull’host. Il problema è dato dal fatto che gli aggiornamenti sopra citati rimuovono la registrazione di classi WMI utilizzate dall’agente di SCVMM per enumerare e gestire i Logical Switch dell’host. La soluzione è di registrare le classi nel repository WMI, come riportato da questo articolo.

System Center Configuration Manager

Rilasciata la versione 1811 per il branch Technical Preview di System Center Configuration Manager.

Tra le principali novità di questa release troviamo la possibilità di inserire del codice PowerShell come step di una Task Sequence, eliminando così la necessità di dover creare e distribuire dei package per l’esecuzione di comandi PowerShell.

Figura 5 – Inserimento di codice PoerShell in una Task Sequence

In questo rilascio vengono contemplati ulteriori novità che possono essere consultati in questo documento.

Si ricorda che i rilasci nel Technical Preview Branch consentono di valutare in anteprima le nuove funzionalità di SCCM ed è consigliato applicare questi aggiornamenti solo in ambienti di test.

Per il branch Technical Preview di System Center Configuration Manager è stata rilasciata la versione 1812. Tutte le novità introdotte in questa release possono essere consultate in questo documento Microsoft. Si ricorda che i rilasci nel Technical Preview Branch consentono di valutare in anteprima le nuove funzionalità di SCCM, in modo da poterle approfondire ed eventualmente fornire feedback al team di prodotto. Questi aggiornamenti è consigliato applicarli solo in ambienti di test.

System Center Operations Manager

In seguito, si riportano le novità riguardanti i seguenti Management Pack di SCOM:

Valutazione di Azure e System Center

Per testare e valutare in modo gratuito i servizio offerti da Azure è possibile accedere a questa pagina, mentre per provare i vari componenti di System Center è necessario accedere all’Evaluation Center e, dopo essersi registrati, è possibile avviare il periodo di trial.

La protezione da attacchi DDoS in Azure

Un attacco informatico di tipologia denial-of-service distribuito (attacco DDoS – Distributed Denial of Service) è rivolto a far esaurire deliberatamente le risorse di un determinato sistema che eroga un servizio ai client, come ad esempio un sito web ospitato su dei web server, al punto da renderlo non più in grado di erogare il servizio a coloro che lo richiedono in modo legittimo. In questo articolo saranno riportate le caratteristiche della protezione che è possibile avere in Azure per questa tipologia di attacchi, in modo da proteggere al meglio le applicazioni presenti sul cloud e garantire la loro disponibilità a fronte di attacchi DDoS.

Gli attacchi DDoS sono sempre più diffusi e sofisticati, al punto da poter raggiungere dimensioni, in termini di larghezza di banda, sempre più importanti, che ne rendono difficoltosa la protezione e aumentano le possibilità di apportare un downtime ai servizi pubblicati, con un impatto diretto sul business aziendale.

Figura 1 – DDoS Attack Trends

Spesso questa tipologia di attacchi viene inoltre utilizzata dagli hackers per distrarre le aziende e mascherare altre tipologie di attacchi informatici (cyber Smokescreen).

 

Caratteristiche della soluzione

In Azure la protezione da attacchi DDoS è disponibile in due differenti tiers: Basic oppure Standard.

Figura 2 – Comparativa delle funzionalità dei tiers disponibili per la protezione DDoS

La protezione Basic è abilitata di default nella piattaforma Azure, la quale effettua costantemente il monitor del traffico e applica in tempo reale delle mitigazioni agli attacchi di rete più comuni. Questo tier fornisce lo stesso livello di protezione adottato e collaudato dai servizi online di Microsoft ed è attiva per gli indirizzi IP Pubblici di Azure (Pv4 e IPv6). Non è richiesta alcun tipo di configurazione per il tier Basic.

L’Azure DDoS Protection di tipologia Standard fornisce delle funzionalità di mitigation aggiuntive rispetto al tier Basic, che sono ottimizzate in modo specifico per le risorse dislocate nelle virtual network di Azure. Le policy di protezione sono auto-configurate e vengono ottimizzate effettuando un monitoraggio specifico del traffico di rete e applicando degli algoritmi di machine learning, che consentono di profilare nel modo più opportuno e flessibile il proprio applicativo studiando il traffico generato. Nel momento in cui vengono superate le soglie impostate nella policy di DDoS, viene in automatico avviato il processo di DDoS mitigation, il quale viene sospeso nel momento in cui si scende al di sotto delle soglie di traffico stabilite. Queste policy vengono applicate a tutti gli IP pubblici Azure (IPv4) associati alle risorse presenti nelle virtual network, come: macchine virtuali, Azure Load Balancer, Azure Application Gateway, Azure Firewall, VPN Gateway e istanze Azure Service Fabric. Questa protezione non si applica agli App Service Environments.

Figura 3 – Panoramica dell’Azure DDoS Protection Standard

L’Azure DDoS Protection di tipologia Standard è in grado di far fronte ai seguenti attacchi:

  • Volumetric attacks: l’obiettivo di questi attacchi è di inondare la rete con una quantità considerevole di traffico apparentemente legittimo (UDP floods, amplification floods, e altri spoofed-packet floods).
  • Protocol attacks: questi attacchi puntano a rendere inaccessibile una specifica destinazione, sfruttando un punto debole che viene individuato nel layer 3 e nel layer 4 dello stack (ad esempio SYN flood attacks e reflection attacks).
  • Resource (application) layer attacks: questi attacchi hanno come obiettivo i pacchetti delle Web application, al fine di interrompere la trasmissione di dati tra i sistemi. Gli attacchi di questo tipo includono: violazioni del protocollo HTTP, SQL injection, cross-site scripting e altri attacchi di livello 7. Per proteggersi da attacchi di questa tipologia non è sufficiente la protezione DDoS standard, ma è necessario utilizzarla in concomitanza con il modulo Web Application Firewall (WAF) disponibile nell’Azure Application Gateway, oppure con soluzione web application firewall di terze parti, disponibili nel marketplace di Azure.

 

Abilitazione della protezione DDoS Standard

La protezione DDoS Standard viene attivata a livello di virtual network ed è contemplata per tutte le risorse che risiedono al suo interno. L’attivazione dell’Azure DDoS Protection Standard richiede di creare un DDoS Protection Plan che raccoglie le virtual network con la protezione DDoS Standard attiva, cross subscription.

Figura 4 – Creazione di un DDoS Protection Plan

Il protection Plan viene creato in una determinata subscription, alla quale saranno associati i costi della soluzione.

Figura 5 – Abilitazione della protezione DDoS Standard su una Virtual Network esistente

Il tier Standard fornisce una telemetria in tempo reale che è consultabile tramite viste in Azure Monitor.

Figura 6 – Metriche DDoS disponibili in Azure Monitor

Qualsiasi metrica relativa alla protezione DDoS può essere utilizzata per generare degli alert. Utilizzando la metrica “Under DDoS attack” si può essere avvisati nel momento in cui viene rilevato un attacco DDoS e viene applicata una azione di mitigation.

La protezione DDoS Standard applica tre auto-tuned mitigation policies (TCP SYN, TCP & UDP) per ogni IP Pubblico associato a una risorsa protetta, che risiede quindi su una virtual network con il servizio DDoS standard attivo.

Figura 7 – Metriche di mitigation disponibili in Azure Monitor

Per effettuare la generazione di report, riguardanti le azioni svolte per mitigare gli attacchi DDoS, è necessario configurare le impostazioni di diagnostica.

Figura 8 – Diagnostics Settings in Azure Monitor

Figura 9 – Abilitazione diagnostica su IP Pubblico per collezionare i log DDoSMitigationReports

Nelle impostazioni di diagnostica c’è la possibilità di collezionare anche altri log relativi alle attività di mitigation e alle notifiche. Per maggiori informazioni a riguardo è possibile consultare la sezione Configure DDoS attack analytics della documentazione Microsoft. Le metriche per la protezione DDoS Standard vengono mantenute in Azure Moniotr per 30 giorni.

Figura 10 – Attack flow logs in Azure Log Analytics

Come testare l’efficacia della soluzione

Microsoft ha instaurato una partnership con BreakingPoint Cloud che, grazie a una interfaccia molto intuitiva, consente di generare del traffico, verso gli IP Pubblici di Azure, per simulare un attacco DDoS. In questo modo è possibile:

  • Validare l’effettiva efficacia della soluzione.
  • Simulare ed ottimizzare le risposte a fronte di incident relativi ad attacchi DDoS.
  • Documentare il livello di compliance per attacchi di questa tipologia.
  • Formare il network security team.

Costi della soluzione

Il tier Basic non prevede nessun costo, mentre l’abilitazione della protezione DDoS Standard prevede un prezzo mensile fisso (non trascurabile) e un addebito per i dati che vengono elaborati. Il prezzo mensile fisso include la protezione per 100 risorse, superate le quali è previsto un costo unitario aggiuntivo per ogni risorsa protetta. Per maggiori dettagli sui costi di Azure DDoS Protection Standard è possibile consultare la pagina ufficiale Microsoft.

Conclusioni

La protezione da attacchi DDoS in Azure ci consente di avere sempre attiva una protezione di base per far fronte ad attacchi di questo tipo. A seconda della criticità applicative si può valutare l’abilitazione della protezione Standard, che in concomitanza con una soluzione di web application firewall, consente di avere funzionalità complete per mitigare attacchi distribuiti di denial-of-service.

Azure Monitor: introduzione al servizio di monitor delle macchine virtuali

In Azure Monitor è stato introdotto un nuovo servizio che consente di effettuare il monitor delle macchine virtuali, chiamato Azure Monitor for VMs. Questo servizio analizza i dati di performance e lo stato delle macchine virtuali, effettua il monitor dei processi installati e ne esamina le relative dipendenze. In questo articolo sono riportate le caratteristiche della soluzione ed descritta la procedura da seguire per effettuarne l’attivazione.

Caratteristiche della soluzione

Il servizio Azure Monitor for VMs è suddiviso secondo tre differenti prospettive:

  • Health: i componenti logici presenti a bordo delle macchine virtuali vengono valutati secondo specifici criteri pre-configurati, generando alert quando si verificano determinate condizioni. Tale funzionalità, al momento, è presente solo per sistemi che risiedono in Azure.
  • Performance: vengono riportati i dati principali di performance, provenienti dal sistema operativo guest.
  • Map: viene generata una mappa con le interconnessioni presenti tra vari componenti che risiedono su sistemi differenti.

Tale soluzione può essere utilizzata su macchine virtuali Windows e Linux, indipendentemente dall’ambiente in cui esse risiedono (Azure, on-premises oppure presso altri cloud provider).

Azure Monitor for VMs richiede la presenza di un workspace di Log Analytics. Trattandosi di una funzionalità al momento in preview, sono supportati i workspace presenti in queste regions: West Central US, East US, West Europe e Southeast Asia. L’abilitazione di un workspace di Log Analytics può avvenire secondo queste modalità:

Per individuare i sistemi operativi supportati da questa soluzione è possibile consultare la relativa documentazione ufficiale Microsoft.

 

Come abilitare Azure Monitor for VMs

Per abilitare la soluzione per una singola macchina virtuale, dal portale Azure, è possibile procedere accedendo alla sezione Insights della macchina virtuale:

Figura 1 – Abilitazione di Azure Monitor for VMs su una singola VM

Abilitando la soluzione su una singola macchina virtuale è possibile scegliere quale workspace Log Analytics utilizzare ed eventualmente crearne uno nuovo. Il consiglio è di precedere a priori con la creazione del workspace, in modo da potergli assegnare un nome significativo in fase di creazione. Il workspace di Log Analytics deve essere configurato come segue:

  • Deve aver installato le solution ServiceMap e InfrastructureInsights. L’installazione di queste solution può essere fatta tramite dei template JSON, secondo le modalità riportate in questo documento.

Figura 2 – Presenza delle solution ServiceMap e InfrastructureInsights

Figura 3 – Raccolta dei performance counters abilitata sul workspace di Log Analytics

Azure Monitor for VMs richiede la presenza dell’agent di Log Analytics sulle macchine virtuali, inoltre la funzionalità di Map richiede l’installazione del Microsoft Dependency agent. Si tratta di un agente aggiuntivo il quale si affida all’agente di Log Analytics per la connessione al workspace.

Nel caso si voglia abilitare la soluzione per sistemi presenti in Azure è possibile attivare il Dependency agent utilizzando l’apposita extension, che ne effettua l’installazione. Per le macchine virtuali che non risiedono su Azure è necessario effettuarne l’installazione manualmente oppure tramite una soluzione che consente di automatizzare il deployment (ad esempio System Center Configuration Manager).

Per abilitare questa funzionalità in modo automatico sulle nuove macchine virtuali create in ambiente Azure ed ottenere un livello elevato di compliance si possono anche utilizzare le Azure Policy. Tramite le Azure Policy è possibile:

  • Effettuare il deployment dell’agente di Log Analytics e del Dependency agent.
  • Avere un report sullo stato di compliance
  • Avviare delle azioni di remediation per le VMs non compliant.

Figura 4 – Aggiunta di un Assignment

Figura 5 – Initiative definition di esempio per abilitare Azure Monitor for VMs

Figura 6 – Consultazione dello stato di compliance della Policy

 

Consultazione dei dati raccolti dalla soluzione

Per analizzare e identificare eventi critici del sistema operativo, rilevare prestazioni non ottimali e problematiche di rete, è possibile consultare i dati forniti dalla solution direttamente dalla singola VM oppure utilizzando Azure Monitor, nel caso si voglia avere una vista aggregata delle varie macchine virtuali. Il tutto consente di rilevare e identificare se determinati problemi sono relativi a specifiche dipendenze con altri servizi.

Figura 7 – Stato di Health di una singola macchina virtuale

Figura 8 – Performance raccolte da più VMs, consultabili da Azure Monitor

Figura 9 – Mappa delle dipendenze dei vari servizi presenti sulle VMs, consultabili da Azure Monitor

Per maggiori informazioni sull’utilizzo della funzionalità di Health è possibile consultare questa documentazione Microsoft, mentre l’articolo View Azure Monitor for VMs Map mostra come individuare e analizzare le dipendenze rilevate dalla soluzione.

Costi della soluzione

Attivando la solution Azure Monitor for VMs, i dati collezionati dalle macchine virtuali vengono inviati e mantenuti in Azure Monitor e possono dipendere da diversi fattori, come ad esempio il numero dei logical disks e delle schede di rete. I costi sono quelli relativi ad Azure Monitor, il quale prevede delle spese sulla base dei seguenti elementi:

  • Dati inseriti e collezionati.
  • Numero di criteri di health monitorati.
  • Alert rule create.
  • Notifiche inviate.

 

Conclusioni

Il servizio Azure Monitor for VMs consente di avere uno strumento totalmente integrato in Azure per monitorare le macchine virtuali ed ottenere un controllo completo dei sistemi, indipendentemente da dove risiedono. Questa soluzione risulta anche particolarmente utile per condurre operazioni di troubleshooting in modo semplice ed immediato. Tale servizio, nonostante sia attualmente in preview, è comunque già sufficientemente completa ed è sicuramente destinata ad arricchirsi presto con nuove funzionalità.