Archivi categoria: Log Analytics

Azure Application Gateway: come monitorarlo con Log Analytics

L’Azure Application Gateway è un load balancer applicativo (OSI layer 7) per il traffico web, disponibile in ambiente Azure, che consente di gestire il traffico HTTP e HTTPS delle applicazioni. In questo articolo verrà approfondito come effettuare il monitor degli Azure Application Gateway utilizzando Log Anaytics.

Figura 1 – Schema di base dell’Azure Application Gateway

Utilizzando l’Azure Application Gateway è possibile usufruire delle seguenti funzionalità:

  • Routing basato su URL
  • Redirection
  • Multiple-site hosting
  • Session affinity
  • Secure Sockets Layer (SSL) termination
  • Web application firewall (WAF)
  • Supporto nativo per i protocolli WebSocket e HTTP/2

Per maggiori dettagli sugli Azure Application Gateway è possibile consultare la documentazione ufficiale Microsoft.

Configurazione Diagnostics logs dell’Application Gateway

L’Azure Application Gateway prevede l’invio dei log di diagnostica verso un workspace di Log Analytics. Questa funzionalità è molto utile per controllare le performance, per rilevare eventuali errori ed è   fondamentale per operazioni di troubleshooting, in particolare in presenza del modulo WAF.  Per abilitare la diagnostica dal portale Azure è possibile selezionare la risorsa Application Gateway specifica ed accedere alla sezione “Diagnostics logs”:

Figura 2 –  Avvio della configurazione dei Diagnostics logs

Figura 3 – Configurazione dei Diagnostics logs

Dopo aver scelto il workspace di Log Analytics dove inviare i dati di diagnostica, nella sezione Log, è possibile selezionare quale tipologia di Log collezionare tra i seguenti:

  • Access log (ApplicationGatewayAccessLog)
  • Performance log (ApplicationGatewayPerformanceLog)
  • Firewall log (ApplicationGatewayFirewallLog): questi log vengono generati solo se il Web Application Firewall è configurato sull’Application Gateway.

Oltre a questi log sono inoltre collezionati di default gli Activity Log generati da Azure. Questi log vengono mantenuti per 90 giorni nello store dell’Azure event logs. Per maggiori dettagli è possibile consultare questo documento specifico.

Solution Azure Application Gateway analytics di Log Analytics

Microsoft mette a disposizione la solution Azure Application Gateway analytics che può essere aggiunta al workspace di Log Analytics seguendo questi semplici step:

Figura 4 – Avvio della procedura di aggiunta della solution al workspace OMS

Figura 5 – Selezione della solution Azure Application Gateway analytics

Figura 6 – Aggiunta della solution nel workspace selezionato

Dopo aver abilitato l’invio dei log di diagnostica verso il workspace di Log Analytics ed aver aggiunto sullo stesso la solution, selezionando il tile Azure Application Gateway analytics presente nella pagina di Overview, si potrà visualizzare una overview dei dati di log raccolti dall’Application Gateway:

Figura 7 – Schermata di overview della solution Azure Application Gateway analytics

Sarà inoltre possibile consultare i dettagli per le seguenti categorie.

  • Application Gateway Access logs:
    • Client and server errors for Application Gateway access logs
    • Requests per hour for each Application Gateway
    • Failed requests per hour for each Application Gateway
    • Errors by user agent for Application Gateways

Figura 8 – Schermata degli Application Gateway Access logs

  • Application Gateway performance:
    • Host health for Application Gateway
    • Maximum and 95th percentile for Application Gateway failed requests

Figura 9 – Schermata delle performance degli Application Gateway

Dashboard personalizzata di Log Analytics per il monitor dell’Application Gateway

Oltre a questa solution può essere conveniente utilizzare anche una apposita dashboard di Log Analytics, specifica per il monitoring dell’Application Gateway, reperibile a questo indirizzo. Il deploy della dashboard avviene tramite template ARM e richiede anche in questo caso l’abilitazione dei Diagnostics logs dell’Application Gateway, come descritto precedentemente. Le varie query di Log Analytics, utilizzate dalla dashboard, sono documentate in questo blog. Grazie a queste query la dashboard riporta diverse informazioni aggiuntive esposte dalla diagnostica dell’Application Gateway.

Figura 10 – Dashboard custom di Log Analytics per il monitor dell’Application Gateway

Query di Log Analytics per monitorare i Firewall Log

Utilizzando la solution Azure Application Gateway analytics di Log Analytics oppure la dashboard custom (riportata nel paragrafo precedente) non sono al momento contemplati i Firewall log, generati quando risulta attivo il Web Application Firewall (WAF) sull’Application Gateway. Il WAF si basa sulle regole di OWASP Core Rule Set 3.0 o 2.2.9 per intercettare gli attacchi, alle applicazioni Web, che sfruttano le più note vulnerabilità. Per citarne alcune, troviamo ad esempio gli attacchi SQL injection e gli attacchi cross site scripting.

In questo caso, qualora si decida di verificare i Firewall log, è necessario eseguire direttamente delle query di Log Analytics, come ad esempio:

Figura 11 – Query di LA per recuperare le richieste bloccate dal modulo WAF, negli ultimi 7 giorni, per uno specifico URI, suddivise per RuleId

Per consultare la lista delle regole del WAF, associando il RuleId alla relativa description, è possibile consultare questo documento.

Il messaggio descrittivo della rule viene riportato anche all’interno dei risultati restituiti dalla query:

Figura 12 – Query di LA per recuperare le richieste bloccate dal modulo WAF, negli ultimi 7 giorni, per uno specifico URI e per specifica RuleId

Conclusioni

Secondo la mia esperienza, nelle architetture Azure che richiedono la pubblicazione sicura di servizi Web verso internet, è spesso utilizzato il servizio Azure Application Gateway con il modulo WAF attivo. Grazie alla possibilità di inviare i log di diagnostica di questo componente verso Log Analytics si ha la possibilità di avere un monitor completo, che risulta fondamentale per analizzare eventuali condizioni di errore e per valutare lo stato del componete in tutte le sue sfaccettature.

Microsoft Azure: panoramica delle soluzioni di monitoring per la rete

In Microsoft Azure sono disponibili diverse soluzioni che consentono di monitorare le risorse di rete, non solo per ambienti cloud, ma anche in presenza di architetture ibride. Si tratta di funzionalità cloud-based, orientate a controllare lo stato di salute della rete e la connettività verso le proprie applicazioni. Inoltre, sono in grado di fornire informazioni dettagliate sulle performance di rete. In questo articolo verrà effettuata una panoramica delle diverse soluzioni riportandone le caratteristiche principali, necessarie per orientarsi nell’utilizzo degli strumenti di monitor della rete più opportuni per le proprie esigenze.

Network Performance Monitor (NPM) è una suite che comprende le seguenti soluzioni:

  • Performance Monitor
  • ExpressRoute Monitor
  • Service Endpoint Monitor

Oltre agli strumenti inclusi in Network Performance Monitor (NPM) è possibile utilizzare Traffic Analytics e DNS Analytics.

Performance Monitor

L’approccio sempre più frequentemente utilizzato è quello di avere ambienti ibridi con un networking eterogeneo, che consente di mettere in comunicazione la propria infrastruttura on-premises con l’ambiente implementato nel cloud pubblico. In alcuni casi si potrebbe disporre anche di differenti cloud provider, che rendono ancor più complicata l’infrastruttura di rete. Questi scenari richiedono pertanto l’utilizzo di strumenti di monitor flessibili e che possano lavorare in modo trasversale on-premises, in cloud (IaaS), e in ambienti ibridi. Performance Monitor ha tutte queste caratteristiche e grazie all’utilizzo di transazioni sintetiche, fornisce la possibilità di monitorare, pressoché in tempo reale, i parametri di rete per avere le informazioni relative alle performance, come la perdita di pacchetti e la latenza. Inoltre, questa soluzione consente di localizzare facilmente la sorgente di una problematica in uno specifico segmento di rete o identificando un determinato dispositivo. La soluzione richiede la presenza dell’agente di OMS e tenendo traccia dei pacchetti di retransmission e del tempo di roundtrip, è in grado di restituire un grafico di facile e immediata interpretazione.

Figura 1 – Diagramma Hop-by-hop fornito da Performance Monitor

Dove installare gli agenti

L’installazione dell’agente di Operations Management Suite (OMS) è necessario farla su almeno un nodo connesso a ogni sottorete dalla quale si intende monitorare la connettività verso altre sottoreti. Nel caso si intenda monitorare uno specifico link di rete è necessario installare gli agenti su entrambe gli endpoint del link. Nei casi dove non si è a conoscenza della topologia esatta di rete, un possibile approccio è quello di installare gli agenti su tutti i server che detengono workload particolarmente critici e per i quali è necessario monitorare le performance di rete.

Costo della soluzione

Il costo della funzionalità Performance Monitor in NPM è calcolato sulla base della combinazione di questi due elementi:

  • Subnet link monitorati. Per ottenere i costi per il monitoring di un singolo subnet link per un mese, è possibile consultare la sezione Ping Mesh.
  • Volume di dati.

Per maggiori dettagli a riguardo è possibile consultare la pagina ufficiale Microsoft.

ExpressRoute Monitor

Utilizzando ExpressRoute Monitor è possibile effettuare il monitor della connettività end-to-end e verificare le performance tra l’ambiente on-premises ed Azure, in presenza di connettività ExpressRoute con connessioni Azure Private peering e Microsoft peering. Le funzionalità chiave di questa soluzione sono:

  • Auto-detection dei circuit ExpressRoute associati alla propria subscription Azure.
  • Detection della topologia di rete.
  • Capacity planning e analisi dell’utilizzo di banda.
  • Monitoring e alerting sia per il primary che per il secondary path dei circuit ExpressRoute.
  • Monitoring sulla connettività verso i servizi Azure come Office 365, Dynamics 365 che utilizzano ExpressRoute come connettività.
  • Rilevamento di eventuali degradi della connettività verso le varie virtual network.

Figura 2 – Topology view di una VM su Azure (sinistra) connessa a una VM on-prem (destra), tramite connessione ExpressRoute

Figura 3 – Trend sull’utilizzo della banda e sulla latenza riscontrata sul circuit ExpressRoute

Dove installare gli agenti

Per poter utilizzare ExpressRoute Monitor è necessario installare almeno un agente di Operations Management Suite su un sistema che risiede sulla virtual network di Azure e almeno un agente su una macchina attestata sulla sottorete nell’ambiente on-premises, connessa tramite private peering di ExpressRoute.

Costo della soluzione

Il costo della soluzione ExpressRoute Monitor è calcolato in base al volume dei dati generato durante le operazioni di monitoring. Per maggiori dettagli è possibile consultare la sezione dedicata nella pagina dei costi di NPM.

Service Endpoint Monitor

Utilizzando questa soluzione si ha la possibilità di monitorare e testare la raggiungibilità dei propri servizi e delle proprie applicazioni, pressoché in tempo reale, simulando gli accessi degli utenti. Si ha inoltre la possibilità di rilevare problemi nelle prestazioni lato network e di individuare il segmento di rete problematico.

Si riportano le funzionalità principali della soluzione:

  • Effettua il monitor end-to-end delle connessioni di rete verso le proprie applicazioni. Il monitor può essere fatto di qualsiasi endpoint “TCP-capable” (HTTP, HTTPS, TCP, e ICMP), come websites, applicazioni SaaS, applicazioni PaaS, e database SQL.
  • Correla la disponibilità delle applicazioni con le performance della network, per localizzare con precisione il punto di degrado sulla rete, partendo dalla richiesta dell’utente fino al raggiungimento dell’applicativo.
  • Testa la raggiungibilità delle applicazioni da differenti location geografiche.
  • Determina le latenze di rete e i pacchetti persi per raggiungere le proprie applicazioni.
  • Rileva hot spots sulla rete che possono causare problemi di performance.
  • Effettua il monitor della raggiungibilità di applicazioni Office 365, tramite test built-in specifici per Microsoft Office 365, Dynamics 365, Skype for Business e altri servizi Microsoft.

Figura 4 – Creazione di un Service Connectivity Monitor test

Figura 5 – Diagramma che mostra la topology di rete, generata da diversi nodi, per raggiungere un Service Endpoint

Dove installare gli agenti

Per utilizzare Service Endpoint Monitor è necessario installare l’agente di Operations Management Suite su ogni nodo da cui si vuole monitorare la connettività di rete verso uno specifico service endpoint.

Costo della soluzione

Il costo per l’utilizzo di Service Endpoint Monitor è basato su questi due elementi:

  • Numero delle connessioni, dove la connessione è intesa come test di raggiungibilità di un singolo endpoint, da un singolo agente, per l’intero mese. A questo proposito è possibile consultare la sezione Connection Monitoring nella pagina dei costi.
  • Volume di dati generato dall’attività di monitor. Il costo lo si ricava dalla pagina dei costi di Log Analytics, nella sezione Data Ingestion.

Traffic Analytics

Traffic Analytics è una soluzione totalmente cloud-based, che consente di avere una visibilità complessiva sulle attività di rete che vengono intraprese nell’ambiente cloud. In Azure per poter consentire o negare la comunicazione di rete verso le risorse connesse alle Azure Virtual Networks (vNet) vengono utilizzati i Network Security Group (NSG), che contengono una lista di regole di accesso. I NSG vengono applicati alle interfacce di rete connesse alle macchine virtuali oppure direttamente alle subnet. La platform utilizza i NSG flow logs per mantenere la visibilità del traffico di rete in ingresso e in uscita dai Network Security Group. Traffic Analytics si basa sull’analisi dei NSG flow logs e dopo una opportuna aggregazione dei dati, inserendo l’intelligence necessaria relativamente a security, topologia e mappa geografica, è in grado di fornire informazioni dettagliate sul traffico di rete del proprio ambiente cloud Azure.

Utilizzando Traffic Analytics si possono effettuare le seguenti operazioni:

  • Visualizzare le attività di rete cross Azure subscriptions e identificare hotspots.
  • Intercettare potenziali minacce di security lato network, per poi poter adottare le giuste operazioni correttive. Questo viene reso possibile grazie alle informazioni riportate dalla soluzione: quali porte sono aperte, quali applicazioni tentano di accedere verso Internet e quali macchine virtuali si connettono a reti non autorizzate.
  • Comprendere i flussi di rete presenti tra le varie region Azure e Internet, al fine di ottimizzare il proprio deployment di rete in termini di performance e capacità.
  • Individuare configurazioni di rete non corrette che portano ad avere tentativi di comunicazione errati.
  • Analisi delle capacità dei gateway VPN o di altri servizi, per rilevare problemi generati da over-provisioning o sottoutilizzo.

Figura 6 – Traffic Analytics overview

Figura 7 – Map delle Region Azure attive sulla subscription

DNS Analytics

La soluzione DNS Analytics è in grado di collezionare, analizzare e correlare i log del servizio DNS e mette a disposizione degli amministratori le seguenti funzionalità:

  • Indentifica i client che tentano di risolvere domini ritenuti malevoli.
  • Rileva i record appartenenti a risorse obsolete.
  • Mette in evidenza nomi di dominio frequentemente interrogati.
  • Mostra il carico delle richieste ricevute dai server DNS.
  • Effettua il monitor delle registrazioni dinamiche sul DNS fallite.

Figura 8 – Overview della solution DNS Analytics

Dove installare gli agenti

La soluzione richiede la presenza dell’agente di OMS oppure di Operations Manager installato su ogni server DNS che si intende monitorare.

Conclusioni

All’aumentare della complessità delle architetture network in ambienti ibridi, aumenta di conseguenza la necessità di potersi avvalere di strumenti in grado di contemplare differenti topologie di rete. Azure mette a disposizione diversi strumenti cloud based e integrati nella fabric, come quelli descritti in questo articolo, che consentono di monitorare in modo completo ed efficace il networking di questi ambienti. Ricordo che per testare e valutare in modo gratuito Operations Management Suite (OMS) è possibile accedere a questa pagina e selezionare la modalità che si ritiene più idonea per le proprie esigenze.

OMS e System Center: novità di Giugno 2018

Nel mese di giugno sono state annunciate, da parte di Microsoft, un numero considerevole di novità riguardanti Operations Management Suite (OMS) e System Center. La nostra community, tramite questi articoli rilasciati mensilmente, vuole fornire una panoramica complessiva delle principali novità del mese, in modo da rimanere sempre aggiornati su questi argomenti ed avere i riferimenti necessari per effettuare maggiori approfondimenti.

Operations Management Suite (OMS)

Log Analytics

Recentemente è stato ufficialmente annunciato che il portale OMS sarà deprecato, a favore del portale Azure. In questo articolo vengono esaminati gli aspetti legati a questo cambiamento e cosa è bene sapere per non farsi cogliere impreparati.

Figura 1 – Notifiche presenti nel portale OMS

Azure Backup

Azure Backup si arricchisce con una nuova importante funzionalità che consente di proteggere in modo nativo i workload SQL, in esecuzione sulle macchine virtuali IaaS che risiedono su Azure. In questo articolo vengono riportati i benefici introdotti e le caratteristiche di questa nuova funzionalità.

Figura 2 – Protezione con Azure Backup di SQL Server su VMs Azure

Rilasciata una versione aggiornata dell’Azure Backup agent (MARS), la quale la si può ottenere accedendo a questo indirizzo.

Utilizzando Azure Backup c’è la possibilità di generare la reportistica necessaria per poter facilmente controllare lo stato di protezione delle risorse, i dettagli sui vari job di backup configurati, l’effettivo utilizzo dello storage e lo stato dei relativi alert. Il tutto è reso possibile grazie all’utilizzo di Power BI, che consente di avere un elevato grado di flessibilità nella generazione e nella personalizzazione della reportistica. In questo video, recentemente pubblicato, viene riportato come configurare un workspace Power BI per la condivisione dei reports di Azure Backup all’interno della propria organizzazione. Per analizzati gli step necessari per configurare la reportistica di Azure Backup è possibile consultare questo articolo.

Figura 3 – La condivisione di report PowerBI di Azure Backup

In Azure Backup è stata introdotta la possibilità di proteggere workloads in esecuzione in ambiente Azure Stack. I tenant che usufruiscono della soluzione Azure Stack possono quindi disporre di una protezione short term direttamente sull’ambiente Azure Stack e possono usufruire dei Recovery Service vault in Azure per la long term retention e per effettuare l’offsite. Per maggiori dettagli a riguardo è possibile consultare l’annuncio del rilascio.

Figura 4 – Azure Stack Tenant backup con Microsoft Azure Backup Server

Azure Site Recovery

In Azure Site Recovery (ASR) è stata annunciata in “general availability (GA)” la funzionalità che consente di configurare il Disaster Recovery (DR) di Azure Virtual Machines. Configurando la replica delle macchine virtuali in region differenti di Azure, si ha la possibilità di rendere le applicazioni resilienti ad eventuali guasti che interessano una specifica region di Azure. Questa funzionalità è disponibile in tutte le region Azure dove è possibile utilizzare ASR. Azure è il primo cloud pubblico a offrire una soluzione nativa di Disaster Recovery per le applicazioni in esecuzione in ambiente IaaS.

Durante il periodo di preview, Microsoft ha preso in considerazione i diversi feedback ricevuti dai client ed ha aggiunto alla soluzione le seguenti importati funzionalità:

Si segnalano questi utili riferimenti riguardanti questa soluzione:

Security e Audit

La solution Azure Network Security Group Analytics sarà sostituita da Traffic Analytics che è stato rilasciato in General availability (GA). Questa soluzione, totalmente cloud-based, consente di avere una visibilità complessiva sulle attività di rete che vengono intraprese nell’ambiente cloud. Per maggiori dettagli a riguardo è possibile consultare l’articolo “Come monitora le attività di rete nel cloud Azure con Traffic Analytics

System Center

System Center Data Protectrion Manager

In ambienti dove System Center Data Protection Manager (SCDPM) è connesso al servizio Azure Backup è stata introdotta la possibilità di visualizzare tutti gli items protetti, i dettagli sull’utilizzo dello storage e le informazioni sui recovery point, direttamente dal portale Azure, all’interno dei Recovery Service vault. Questa funzionalità è supportata per SCDPM 2012 R2, 2016 e per Azure Backup Server v1 e v2, purché sia installata l’ultima versione dell’Azure Backup Agent (MARS).

Figura 5 – Informazioni provenienti da DPM riportate nel Recovery Service vault

System Center Configuration Manager

Solitamente viene rilasciata una technical preview al mese di Configuration Manager, ma questo mese, visto il numero considerevole di novità, ne sono state rilasciate due.

La prima è la versione 1806 per il branch Technical Preview di System Center Configuration Manager. La principale novità introdotta da questo aggiornamento è l’aggiunta del supporto per il software update catalogs di terze parti. Dalla console di Configuration Manager si potrà facilmente effettuare la sottoscrizione al catalog degli update di partner software di terze parti, per poi pubblicare gli updates tramite il Software Update Point. Tali aggiornamenti potranno essere rilasciati ai client utilizzando il metodo classico di Configuration Manager per la distribuzione dei software update.

Figura 6 – Accesso al software update catalogs di terze parti dalla console di SCCM

Oltre a questa nuova funzionalità sono stati rilasciati aggiornamenti riguardanti:

  • Sync MDM policy from Microsoft Intune for a co-managed device
  • Office 365 workload transition in co-management
  • Configure Windows Defender SmartScreen settings for Microsoft Edge
  • Improvements to the Surface dashboard
  • Office Customization Tool integration with the Office 365 Installer
  • Content from cloud management gateway
  • Simplified client bootstrap command line
  • Software Center infrastructure improvements
  • Removed Network Access Account (NAA) requirement for OSD Boot Media
  • Removed Network Access Account (NAA) requirement for Task Sequences
  • Package Conversion Manager
  • Deploy updates without content
  • Currently logged on user information is shown in the console
  • Provision Windows app packages for all users on a device

La seconda è la versione 1806.2 per il branch Technical Preview di System Center Configuration Manager, che include principalmente le seguenti novità relative al Phased deployment:

  • Possibilità di monitorare lo stato in modo nativo, dal Deployments node.
  • Possibilità di creare Phased deployment di applications e non solo per le task sequences.
  • Possibilità di effettuare un rollout graduale durante la fase di deployment.

Inoltre questa preview contiene aggiornamenti riguardanti:

  • Management Insights for proactive maintenance
  • Mobile apps for co-managed devices
  • Support for new Windows app package formats
  • New boundary group options for optimized P2P behaviors
  • Third-party software updates support for custom catalogs
  • Compliance 9 – Overall health and compliance (Report)

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

Rilasciata una versione aggiornata del Management Pack per OS Windows Server 2016 e 1709 Plus che include diversi aggiornamenti e risoluzioni di problematiche. Per maggiori informazioni a riguardo è possibile consultare questo articolo.

Rilasciata la versione 8.2 del MP Author che include diversi miglioramenti. Per la lista delle novità incluse in questa nuova versione è possibile consultare l’annuncio ufficiale del rilascio.

Valutazione di OMS e System Center

Si ricorda che per testare e valutare in modo gratuito Operations Management Suite (OMS) è possibile accedere a questa pagina e selezionare la modalità che si ritiene più idonea per le proprie esigenze.

Per provare i vari componenti di System Center 2016 è possibile accedere all’Evaluation Center e dopo essersi registrati è possibile avviare il periodo di trial.

La gestione di Log Analytics dal portale Azure

Da diverso tempo Microsoft ha iniziato un processo che ha portato a far confluire nel portale Azure diverse funzionalità e impostazioni di OMS Log Analytics. Recentemente è stato ufficialmente annunciato che il portale OMS sarà deprecato, a favore del portale Azure. In questo articolo saranno esaminati gli aspetti legati a questo cambiamento e cosa è bene sapere per non farsi cogliere impreparati.

La scelta di abbandonare il portale OMS, a favore del portale Azure, è stata fatta per mettere a disposizione una user experience unica per il monitor e la gestione dei propri sistemi, indipendentemente dalla loro locazione (on-premises oppure su Azure). Grazie al portale Azure è infatti possibile esplorare e gestire tutti i servizi Azure e presto si avrà anche il controllo completo di OMS Log Analytics. L’aspettativa è che il gap attualmente presente tra i due portali venga definitivamente colmato entro la fine dell’estate e a breve Microsoft annuncerà la data per la dismissione definitiva del portale OMS.

Figura 1 – Notifiche presenti nel portale OMS

Figura 2 – Overview di Log Analytics nel portale Azure

Cosa comporta questo cambiamento?

La dismissione del portale OMS, oltre a un evidente cambio nella user experience, comporta anche un cambio nell’utilizzo di Log Analytics per gli aspetti in seguito riportati.

Gestione degli alert

Anziché utilizzare la solution di Alert management di Log Analytics è necessario utilizzare Azure Monitor che, oltre a consentire di monitorare tutte le risorse Azure borne, detiene anche l’engine di “alerting” per l’intera piattaforma cloud. Nell’articolo “L’estensione degli Alerts di Log Analytics in Azure Monitor” viene presentata la nuova gestione degli Alerts in Log Analytics e i relativi benefici introdotti da questa evoluzione.

Autorizzazioni per accedere al portale

La gestione degli accessi nel portale Azure, basata su role-based access control (RBAC), è sicuramente più flessibile e potente rispetto a quella presente nel portale OMS. Azure di default prevede questi due built-in user roles per Log Analytics:

  • Log Analytics Reader
  • Log Analytics Contributor

Per i dettagli riguardanti la gestione degli accessi di Log Analytics dal portale Azure è possibile consultare questa documentazione. A partire dal 25 giugno avrà inizio il processo di conversione automatico, durante il quale ogni utente o gruppo di security presente nel portale OMS verrà riportato nel portale Azure con il ruolo opportuno, secondo la seguente associazione:

Figura 3 – Associazione permessi portale OMS e ruoli in Azure

Mobile App

Così come per il portale OMS, anche la mobile app di OMS sarà deprecata. Al suo posto è possibile accedere al portale Azure direttamente dal browser del dispositivo mobile, in attesa di future estensioni dell’App Mobile di Azure. Per ricevere le notifiche sui dispositivi mobile, quando si generano degli alert, è possibile utilizzare gli Azure Action Groups.

Application Insights Connector

L’Application Insights Connector viene utilizzato per riportare i dati di Application Insights all’interno del workspace di Log Analytics. Questo connector non è più necessario e sarà deprecato, dal mese di Novembre di quest’anno, visto che la stessa funzionalità la si può ottenere utilizzando queries cross-resource.

Azure Network Security Group Analytics

La solution  Azure Network Security Group Analytics sarà sostituita da Traffic Analytics, accessibile solamente dal portale Azure. Per maggiori dettagli su questo nuovo strumento è possibile consultare l’articolo “Come monitora le attività di rete nel cloud Azure con Traffic Analytics

 

Attuali mancanze nel portale Azure

Ad oggi viene imposto l’utilizzo del portale OMS, a chi utilizza le seguenti solution, in quanto non sono totalmente utilizzabili nel portale Azure:

Microsoft sta lavorando per aggiornare queste solution e renderle disponibili utilizzando il portale Azure. Per rimanere aggiornati su cambiamenti in merito è possibile fare riferimento alla pagina degli Azure Updates.

 

Considerazioni

Per la gestione di Log Analytics è consigliabile utilizzare fin da oggi il portale Azure, il quale consente di adottare nuovi strumenti, di beneficiare della migliore experience offerta, e di usufruire delle funzionalità note del portale, come le dashboards, le ricerche, e il tagging per la gestione delle risorse. Il portale OMS è destinato a breve alla dismissione definitiva, ma può essere ancora necessario utilizzarlo nel caso si debbano utilizzare le solution non ancora compatibili (sopra riportate), in attesa di un loro imminente aggiornamento che le renderà totalmente funzionanti con il portale Azure.

OMS e System Center: novità di Maggio 2018

Rispetto a quanto siamo stati abituati a vedere nei mesi scorsi, nel mese di maggio, sono state annunciate da Microsoft un numero ridotto di novità riguardanti Operations Management Suite (OMS) e System Center. In questo articolo verranno riepilogate riportando i riferimenti necessari per effettuare ulteriori approfondimenti.

Operations Management Suite (OMS)

Log Analytics

Microsoft ha annunciato il ritiro, a partire dall’8 Giugno 2018, delle seguenti solution:

Questo significa che, a partire da questa data, non sarà più possibile aggiungerle nei workspaces di Log Analytics. Per coloro che le stanno attualmente utilizzando è opportuno tenere in considerazione che le solution continueranno a funzionare, ma verrà a mancare il relativo supporto e non saranno rilasciati nuovi aggiornamenti.

In questo articolo vengono riportate alcune importanti raccomandazioni che è opportuno seguire quando si utilizzano gli operatori “Summarize” e “Join” nelle query di Log Analytics e Application Insights. Si consiglia di adeguare la sintassi di eventuali query esistenti, che utilizzano questi operatori, per rispettare le specifiche riportate nell’articolo.

Security e Audit

Si segnala questo interessante articolo dove viene riportato come è possibile rilevare ed investigare attività anomale e potenzialmente malevole utilizzando Log Analytics ed Azure Security Center.

Azure Site Recovery

Microsoft ha annunciato che le seguenti versioni delle REST API di Azure Site Recovery saranno deprecate a partire dal 31 Luglio 2018:

  • 2014-10-27
  • 2015-02-10
  • 2015-04-10
  • 2015-06-10
  • 2015-08-10

Sarà quindi necessario utilizzare le API almeno della versione 2016-08-10 per interfacciarsi con Azure Site Recovery. Questo tipo di modifica non ha nessun impatto sul portale di Azure Site Recovery e sull’accesso alla soluzione tramite PowerShell.

System Center

System Center Orchestrator

Gli Integration Pack di Orchestrator, versione 7.3 per System Center 2016, sono stati rilasciati.
Il download può essere effettuato a questo indirizzo e include i seguenti componenti:

  • System Center 2016 Integration Pack per System Center 2016 Configuration Manager.
  • System Center 2016 Integration Pack per System Center 2016 Data Protection Manager.
  • System Center 2016 Integration Pack per System Center 2016 Operations Manager.
  • System Center 2016 Integration Pack per System Center 2016 Service Manager.
  • System Center 2016 Integration Pack per System Center 2016 Virtual Machine Manager.

Questi Integration Pack consentono di sviluppare delle automazioni, interfacciandosi direttamente anche con gli altri componenti di System Center. L’Integration Pack di System Center 2016 Operations Manager è stato rivisto per non richiedere più la presenza della console di Operations Manager per funzionare in modo corretto.

System Center Operations Manager

In seguito, si riportano gli aggiornamenti rilasciati per i Management Pack di Operations Manager:

  • Active Directory Federation Services versione 10.0.1.0
  • Active Directory Federation Services 2012 R2 versione 7.1.10100.1

System Center Service Management Automation

Service Management Automation vede il rilascio dell’Update Rollup 5. Tra le problematiche risolte troviamo:

  • Runbooks che, utilizzando cmdlets di System Center 2016 Service Manager, falliscono con l’errore “MissingMethodException”.
  • Runbooks che falliscono con l’exception “unauthorized access”.

Sono stati inoltre apportati miglioramenti nella parte di debug logging.

Per consultare l’elenco completo dei problemi risolti e i dettagli da seguire per effettuare l’aggiornamento è possibile accedere alla relativa knowledge base.

 

Valutazione di OMS e System Center

Si ricorda che per testare e valutare in modo gratuito Operations Management Suite (OMS) è possibile accedere a questa pagina e selezionare la modalità che si ritiene più idonea per le proprie esigenze.

Per provare i vari componenti di System Center 2016 è possibile accedere all’Evaluation Center e dopo essersi registrati è possibile avviare il periodo di trial.

OMS e System Center: novità di Aprile 2018

Microsoft annuncia in modo costante novità riguardanti Operations Management Suite (OMS) 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.

Operations Management Suite (OMS)

Log Analytics

Microsoft ha deciso di estendere gli Alerts presenti in Log Analytics dal portale OMS verso il portale Azure, facendoli confluire in Azure Monitor. Questo processo avverrà in modo automatico a partire dal 14 Maggio 2018 (la data è stata posticipata, inizialmente era prevista per il 23 Aprile), non comporterà nessun tipo di modifica alla configurazione degli Alerts e delle relative query, e non prevede nessun downtime per la sua attuazione. Per maggiori informazioni a riguardo è possibile consultare l’articolo specifico “L’estensione degli Alerts di Log Analytics in Azure Monitor“.

Figura 1 – Notifica estensione alerts nel portale OMS

Per evitare situazioni dove, le risorse gestite in Log Analytics inviino in modo inaspettato un elevato volume dei dati verso il Workspace OMS, è stata introdotta la possibilità di fissare un Daily Volume cap. Questo consente di limitare la data ingestion giornaliera per il proprio workspace. Il Data volume cap è possibile configurarlo in tutte le regions, accedendo nella sezione Usage and estimated costs:

Figura 2 – Impostazione del Daily volume cap

Il portale mostra inoltre il trend del volume dei dati negli ultimi 31 giorni e il totale del volume dei dati, suddiviso per solution:

Figura 3 – Data ingestion per solution (ultimi 31 giorni e totale)

L’utilizzo della Log Search API, utilizzata dal vecchio linguaggio di query di Log Analytics, è stato deprecato a partire dal 30 Aprile 2018. La Log Search API è stata sostituita con l’Azure Log Analytics REST API, la quale supporta il nuovo linguaggio di query e introduce una maggiore scalabilità rispetto ai risultati che è in grado di restituire. Per maggiori dettagli a riguardo è possibile consultare l’annuncio ufficiale.

Agente

Questo mese la nuova versione dell’agente OMS per sistemi Linux risolve un importante numero di bug e introduce nuove versioni dei vari componenti. Viene inoltre introdotto il supporto per Debian 9, AWS 2017 e Open SSL 1.1. Per ottenere la versione aggiornata dell’agente OMS è possibile accedere alla pagina ufficiale GitHub OMS Agent for Linux Patch v1.6.0-42.

Figura 4 – Elenco Bug Fix e novità del nuovo agente OMS per Linux

Azure Backup

Per quanto riguarda Azure Backup sono stati annunciati i seguenti miglioramenti nella scalabilità del servizio:

  • Possibilità di creare fino a 500 recovery services vaults in ogni subscription per region (in precedenza il limite era di 25).
  • Il numero di macchine virtuali che può essere registrato in ogni vault è aumentato a 1000 (precedentemente era 200).

Azure Backup, per la protezione delle Azure Iaas VM, ora supporta gli storage account messi in sicurezza utilizzando storage firewalls and Virtual Networks. Per maggiori dettali a riguardo è possibile consultare il blog ufficiale Microsoft.

Figura 5 – Protezione Azure Iaas VM in scenari di storage protetti

Cambiano le modalità previste per abilitare il backup long-term per gli Azure SQL Database. La procedura, per consentire di mantenere il backup degli Azure SQL DB fino a 10 anni, prevedeva il salvataggio all’interno di un Azure Recovery Service Vault. Grazie all’introduzione di questa nuova funzionalità, si ha la possibilità di mantenere il backup long-term direttamente all’interno di un Azure Blob Storage e viene a decadere l’esigenza di un Recovery Service Vault. Tutto ciò consente di avere più flessibilità e un maggiore controllo dei costi. Per maggiori dettagli a riguardo è possibile consultare l’articolo SQL Database: Long-term backup retention preview includes major updates.

System Center

System Center Configuration Manager

Per System Center Configuration Manager è stata rilasciata la versione 1804 per il branch Technical Preview. Oltre che improvements generici nella soluzione vengono introdotte novità riguardanti l’OSD, il Software Center e l’infrastruttura di Configuration Manager. Tutte le nuove funzionalità incluse in questo update possono essere consultate nell’articolo Update 1804 for Configuration Manager Technical Preview Branch. 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

Microsoft ha rilasciato l’Update Rollup 5 (UR5) per System Center 2016 Long-Term Servicing Channel (LTSC). Questo aggiornamento non introduce nuove funzionalità, ma risolve diversi bug.

In seguito, si riportano i riferimenti, riguardanti questo aggiornamento, per ogni prodotto System Center:

Non sono presenti invece aggiornamenti riguardanti Service Provider Foundation.

System Center Operations Manager 1801 introduce il supporto per la Kerberos authentication quando il protocollo WS-Management viene utilizzato dal management server per la comunicazione con i sistemi UNIX e Linux. Questo consente di avere un maggiore Livello di sicurezza, eliminando la necessità di abilitare la basic authentication per Windows Remote Management (WinRM).

Inoltre in System Center Operations Manager 1801 sono stati introdotti i seguenti miglioramenti riguardanti la gestione del monitor dei file di log di Linux:

  • Supporto per caratteri Wild Card nel nome e nel percorso del file di log.
  • Supporto per nuovi match patterns che consentono ricerche personalizzate dei log.
  • Supporto per pluging Fluentd pubblicati dalla community fluentd.

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

  • MP per Windows Server Operating System 2016 e 1709 Plus 10.0.19.0
  • MP per SQL Server 2008-2012 7.0.4.0
  • MP per SQL Server 2014 7.0.4.0
  • MP per SQL Server 2016 7.0.4.0
  • MP per Microsoft Azure SQL Database 7.0.4.0
  • MP per SQL Server Dashboards 7.0.4.0
  • MP per UNIX e Linux 7.6.1085.0

Valutazione di OMS e System Center

Si ricorda che per testare e valutare in modo gratuito Operations Management Suite (OMS) è possibile accedere a questa pagina e selezionare la modalità che si ritiene più idonea per le proprie esigenze.

Per provare i vari componenti di System Center 2016 è possibile accedere a l’Evaluation Center e dopo essersi registrati è possibile avviare il periodo di trial.

L’estensione degli Alerts di Log Analytics in Azure Monitor

Poter usufruire di un servizio centralizzato ed efficace per la gestione degli Alerts della propria infrastruttura è sicuramente un aspetto importante e fondamentale nella strategia di monitor. A questo scopo Microsoft ha introdotto una nuova experience nella gestione degli Alerts tramite la soluzione Azure Monitor. In questo articolo verrà presentato come evolverà la gestione degli Alerts in Log Analytics e quali sono i benefici introdotti da questo cambiamento.

In Log Analytics c’è la possibilità di generare degli Alerts quando, a fronte di una ricerca che avviene con frequenza schedulata nel repository di OMS, si ottengono dei risultati che fanno match con i criteri stabiliti. Nel momento in cui viene generato un Alert in Log Analytics si possono configurare le seguenti azioni:

  • Notifica via email.
  • Invocazione di un webhook.
  • Esecuzione di un runbook di Azure Automation.
  • Attività di IT Service Management (richiede la presenza del connettore per la solution ITSM).

Figura 1 – Alerts in Log Analytics

Fino ad oggi questo tipo di configurazione è stata gestita dal portale OMS.

Azure Monitor è un servizio che oltre a consente di monitorare tutte le risorse Azure borne, detiene l’engine di “alerting” per l’intera piattaforma cloud. Accedendo al servizio dal portale Azure si avranno infatti a disposizione, in una unica location, tutti gli Alerts della propria infrastruttura, provenienti da Azure Monitor, Log Analytics, e Application Insights. Si potrà quindi usufruire di una experience unificata sia per quanto riguarda la consultazione degli Alerts che per il relativo authoring.

Allo stato attuale gli Alerts creati in Log Analytics vengono già riportati nella dashboard di Azure Monitor, ma l’eventuale modifica comporta l’accesso al portale OMS. Per agevolare questa gestione Microsoft ha quindi deciso di estendere gli Alerts presenti in Log Analytics dal portale OMS verso il portale Azure. Questo processo avverrà in modo automatico a partire dal 23 Aprile 2018, non comporterà nessun tipo di modifica alla configurazione degli Alerts e delle relative query, e non prevede nessun downtime per la sua attuazione.

Ne consegue che, dopo questa operazione, le eventuali azioni associate agli Alerts saranno effettuate tramite Action Groups, i quali saranno creati automaticamente dal processo di estensione.

L’estensione degli Alerts di Log Analytics nel portale Azure, oltre al vantaggio di poter consentire la gestione degli stessi da un unico portale, consente di usufruire dei seguenti benefici:

  • Non esiste più il limite dei 250 Alerts.
  • Si ha la possibilità di gestire, enumerare e visualizzare non solo gli Alerts di Log Analytics, ma anche quelli provenienti da altre fonti.
  • Si ha una maggiore flessibilità nelle azioni che si possono intraprendere a fronte di un Alerts, grazie all’utilizzo degli Action Groups, come ad esempio la possibilità di inviare SMS oppure di effettuare delle chiamate vocali.

Nel caso non si voglia attendere il processo automatico è possibile forzare la migrazione via API oppure dal portale OMS, secondo gli step in seguito documentati:

Figura 2 – Avvio del processo di “Extend into Azure” dal portale OMS

Figura 3 – Step 1: mostra i dettagli del processo di estensione.

Figura 4 – Step 2: summary delle modifiche proposte

Figura 5 – Step 3: conferma del processo di estensione

Specificando un indirizzo email è possibile ricevere una notifica al termine del processo di migrazione, contenente il summary report.

Figura 6 – Notifica dell’estensione degli Alerts pianificata

Durante il processo di estensione degli Alerts di Log Analytics in Azure non sarà possibile apportare delle modifiche agli Alerts esistenti e la creazione di nuovi Alerts dovrà avvenire da Azure Monitor.

Al termine del processo di estensione gli Alerts saranno comunque visibili anche dal portale OMS e si riceverà la notifica via mail, all’indirizzo specificato durante il wizard di migrazione:

Figura 7 – Mail di notifica al termine del processo di estensione

Dal portale Azure, nella sezione “Monitor – Alerts”, si avrà una gestione completa degli Alerts di Log Analytics:

Figura 8 – Esempio di modifica di una Alert Rule da Azure Monitor

L’estensione degli Alerts di Log Analytics in Azure Monitor non comporta dei costi, ma è opportuno tenere in considerazione che, l’utilizzo degli Azure Alerts generati da query di Log Analytics, non è soggetta a fatturazione solamente se rientra nei limiti e nelle condizioni riportati nella pagina dei costi di Azure Monitor.

Conclusioni

Grazie a questa attività di estensione degli Alerts di Log Analytics, Azure Monitor si conferma il nuovo engine di gestione di tutti gli Alerts, mettendo a disposizione degli amministratori una semplice e intuitiva interfaccia centralizzata ed arricchendo le possibili azioni di notifica a fronte di un alert.

Come monitora le attività di rete nel cloud Azure con Traffic Analytics

Le reti nel mondo cloud presentano differenze sostanziali rispetto a quelle presenti in ambiente on-premises, ma sono accomunate dalla necessità di essere costantemente monitorate, gestite e analizzate. Tutto ciò è importante per poterle conoscere al meglio, al fine di proteggerle ed ottimizzarle. Microsoft ha introdotto in Azure la soluzione Traffic Analytics, totalmente cloud-based, che consente di avere una visibilità complessiva sulle attività di rete che vengono intraprese nell’ambiente cloud. Questo articolo analizza le caratteristiche della soluzione e spiega come è possibile attivarla.

Principi di funzionamento della soluzione

In Azure per poter consentire o negare la comunicazione di rete verso le risorse connesse alle Azure Virtual Networks (vNet) vengono utilizzati i Network Security Group (NSG), che contengono una lista di regole di accesso. I NSG vengono applicati alle interfacce di rete connesse alle macchine virtuali oppure direttamente alle subnet. La platform utilizza i NSG flow logs per mantenere la visibilità del traffico di rete in ingresso e in uscita dai Network Security Group. Traffic Analytics si basa sull’analisi dei NSG flow logs e dopo una opportuna aggregazione dei dati, inserendo l’intelligence necessaria relativamente a security, topologia e mappa geografica, è in grado di fornire informazioni dettagliate sul traffico di rete del proprio ambiente cloud Azure.

Figura 1 – Data flow di Traffic Analytics

Funzionalità della soluzione

Utilizzando Traffic Analytics si possono effettuare le seguenti operazioni:

  • Visualizzare le attività di rete cross Azure subscriptions e identificare hotspots.
  • Intercettare potenziali minacce di security lato network, per poi poter adottare le giuste operazioni correttive. Questo viene reso possibile grazie alle informazioni riportate dalla soluzione: quali porte sono aperte, quali applicazioni tentano di accedere verso Internet e quali macchine virtuali si connettono a reti non autorizzate.
  • Comprendere i flussi di rete presenti tra le varie region Azure e Internet, al fine di ottimizzare il proprio deployment di rete in termini di performance e capacità.
  • Individuare configurazioni di rete non corrette che portano ad avere tentativi di comunicazione errati.

Come abilitare la soluzione

Per poter analizzare il traffico di rete è necessario disporre di un Network Watcher in ogni region dove sono presenti i NSG per i quali si intente analizzare il traffico. Il Network Watcher è un servizio regionale grazie al quale è possibile monitorare e diagnosticare il networking di Azure. L’abilitazione del Network Watcher può essere fatta dal portale Azure, tramite Powershell oppure via REST API. Creandolo dal portale non è possibile stabilire il nome del Network Watcher e il relativo Resource Group, ma viene assegnato un nome di default a entrambe le entità.

Figura 2 – Abilitazione del Network Watcher dal portale

Figura 3 – Abilitazione del Network Watcher tramite PowerShell

Trattandosi di un servizio in preview per poterlo utilizzare è necessario effettuare nuovamente la registrazione del network resource provider sulla subscription Azure interessata. Inoltre è necessario registrare il provider Azure Insights.

Figura 4 – Registrazione dei provider tramite PowerShell

Per poter abilitare la raccolta degli NSG Flow Logs è necessario dotarsi di uno storage account sul quale memorizzarli. Inoltre è necessario disporre di un workspace OMS Log Analytics sul quale Traffic Analytics consoliderà i dati aggregati e indicizzati. Le informazioni presenti in Log Analytics verranno poi utilizzate per generare la relativa analisi.

Primo step di configurazione delle impostazioni dei NSG flow logs:

Figura 5 – Selezione dei NSG sui quali abilitare la raccolta dei flow logs

Scelta dello storage account e del workspace OMS Log Analytics per ogni NSG:

Figura 6 – Abilitazione della raccolta dei NSG flow logs e del consolidamento in OMS Log Analytics

Gli step precedentemente riportati dovranno essere ripetuti per ogni NSG per il quale si desidera abilitare Traffic Analytics.

Figura 7 – Lista dei NSGs con le impostazioni abilitate

Entro alcuni minuti dall’abilitazione, tempo necessario per avere un quantitativo di dati aggregati sufficientemente indicativo, viene popolata la relativa dashboard con le informazioni di Traffic Analytics.

Figura 8 – Dashboard di Traffic Analytics

Dalla dashboard di Traffic Analytics sono facilmente reperibili le informazioni quali: gli host con un livello elevato di comunicazione, i protocolli applicativi maggiormente utilizzati, le comunicazioni che avvengono in modo più frequente e i flussi relativi al traffico di rete nel cloud.

Selezionando la sezione di interesse viene mostrata la query di Log Analytics che estrapola i dati:

Figura 9 – Esempio di query Log Analytics che mostra il traffico malicious consentito

Per avere una panoramica completa dei possibili scenari di utilizzo di Traffic Analytics è possibile consultare questo documento Microsoft.

Conclusioni

Traffic Analytics è una nuova funzionalità, al momento in preview, introdotta in Azure. Si tratta di uno strumento efficace e di facile utilizzo che consente di tenere sotto controllo lo stato della rete in Azure riportando dati molto utili, come chi si sta collegando e dove, quali porte sono esposte verso internet, quale traffico di rete viene generato e molto altro. Si tratta di informazioni fondamentali per individuare eventuali anomalie e apportare le dovute azioni correttive. Tutte operazioni di difficile raggiungimento senza questo strumento totalmente integrato nella platform.

OMS e System Center: novità di Febbraio 2018

Il mese di Febbraio è stato ricco di novità e diversi sono gli aggiornamenti che hanno interessato Operations Management Suite (OMS) e System Center. In questo articolo verranno riepilogati in modo sintetico per avere una visione globale e saranno presenti i riferimenti necessari per effettuare maggiori approfondimenti a riguardo.

Operations Management Suite (OMS)

Log Analytics

Tutti coloro che utilizzano Azure ExpressRoute saranno lieti di sapere che ora è possibile effettuarne il monitor utilizzando Network Performance Monitor (NPM). Tale funzionalità è stata in preview per alcuni mesi e ora è passata nello stato di general availability. Tra le caratteristiche di questa soluzione di monitor troviamo:

  • Possibilità di visualizzare in modo interattivo, tramite la topology view di NPM, i vari componenti (network on-premises, circuit provider edge, circuit ExpressRoute, edge Microsoft, e le Azure VMs) e la latenza misurata in ogni hop. Questo consente di indentificare facilmente eventuali problemi di performance nella connettività e di individuare rapidamente il segmento problematico della comunicazione.
  • Capacità di visualizzare l’utilizzo di banda del primary e del secondary circuit ExpressRoute. Grazie al drill-down è inoltre possibile intercettare l’utilizzo di banda per ogni singola vNet connessa ai circuit ExpressRoute.
  • Possibilità di creare query e visualizzazioni personalizzate grazie al fatto che tutti i dati della soluzione sono disponibili nel repository di Log Analytics e di conseguenza è possibile utilizzare le funzionalità native di ricerca e correlazione in base alle proprie esigenze.
  • Capacità di diagnosticare problemi vari di connettività presenti nei circuit ExpressRoute.

Figura 1 – Azure ExpressRoute Monitoring

Per maggiori informazioni su come configurare il monitor di ExpressRoute con NPM è possibile consultare la documentazione ufficiale Microsoft.

Inoltre in Network Performance Monitor (NPM) è stata introdotta la funzionalità di Service Endpoint Monitor che integra nel monitor e nella visualizzazione delle performance della propria applicazione anche le performance end-to-end della network. Questa funzionalità consente di creare differenti tipologie di test (HTTP, HTTPS, TCP e ICMP), che dovranno essere effettuati da punti chiave della propria infrastruttura di rete, in modo da poter identificare in modo rapido se il problema riscontrato è legato alla network oppure è relativo all’applicativo. Grazie all’utilizzo della network topology map il problema e la sua natura è inoltre facilmente localizzabile. Si tratta di una funzionalità in public preview le cui caratteristiche sono riportate nel dettaglio in questo articolo.

Agente

Questo mese la nuova versione dell’agente OMS per sistemi Linux risolve alcuni bug e introduce anche una versione aggiornata dei componenti SCX e OMI. Per ottenere la versione aggiornata dell’agente OMS è possibile accedere alla pagina ufficiale GitHub OMS Agent for Linux Patch v1.4.4-210.

Figura 2 – Elenco Bug Fix e novità del nuovo agente OMS per Linux

Azure Backup

In questo articolo viene descritto come costruire la propria soluzione di monitor in Log Analytics per Azure Backup. Tramite questa soluzione di monitor è possibile controllare i principali aspetti di Azure Backup come i job di backup e restore, backup alert e l’utilizzo dello storage in cloud. Il tutto è possibile farlo cross Recovery Service vault e cross subscription potendo trarre beneficio delle funzionalità integrate in Log Analytics, quali ad esempio l’apertura automatizzata di ticket tramite webhooks oppure grazie all’integrazione con ITSM. Si tratta di una soluzione community e ogni contribuito è ovviamente ben accetto.

Per quanto riguarda Azure Backup è stata annunciata (in general availability) la possibilità di realizzare backup consistenti a livello applicativo per le macchine virtuali Linux in esecuzione su Azure. Sui sistemi Windows questo avviene utilizzando il componente VSS, mentre per le VM Linux viene messo a disposizione uno scripting framework grazie al quale è possibile eseguire dei pre-script e dei post-script per controllare l’esecuzione dei backup.

Figura 3 – Meccanismo per la realizzazione di backup application consistent in VMs Linux su Azure

Per maggiori dettagli a riguardo è possibile consultare l’annuncio ufficiale, mentre per ulteriori informazioni sulla protezione delle macchine virtuali Linux presenti in Microsoft Azure, utilizzando Azure Backup, è possibile prendere visione dell’articolo: Azure Backup: la protezione dei sistemi Linux in Azure.

In Azure Backup è stata introdotta la possibilità di proteggere in modo nativo Azure File Shares. Tale funzionalità al momento è in Public Preview e tra le caratteristiche principali troviamo:

  • Possibilità, accedendo ai Recovery Service vault, di effettuare il discovery degli storage acccount e di rilevare le file shares presenti e non protette.
  • Protezione su larga scala: c’è la possibilità di effettuare il backup di più file shares contenute in uno storage account e di applicare un policy di protezione comune.
  • Restore istantanei e granulari. La protezione è basata su file share snapshots e questo consente di effettuare in modo rapido il ripristino di file in modo selettivo.
  • Dal portale Azure è possibile esplorare i vari restore point presenti per individuare facilmente quali file ripristinare.

Figura 4 – Backup di Azure File Shares

Per maggiori informazioni a riguardo è possibile consultare l’annuncio ufficiale.

Questo mese è stato rilasciato un Mandatory Update per l’agente Microsoft Azure Recovery Services (MARS). Per tutti coloro che utilizzano Azure Backup è necessario installare quanto prima questo aggiornamento per evitare fallimenti nelle attività di backup e di recovery.

Azure Site Recovery

In Azure Site Recovery è stata resa disponibile un’attesa funzionalità, che consente di proteggere macchine virtuali aventi managed disk, nello scenario di replica tra differenti region di Azure, consentendo di avere una maggiore flessibilità per l’attivazione di scenari di Disaster Recovery con sistemi presenti in Azure.

Figura 5 – Attivazione replica di una VM con Managed Disks

System Center

Come annunciato nei mesi scorsi e come già avviene per il sistema operativo e per Configuration Manager, anche gli altri prodotti System Center, in particolare Operations Manager, Virtual Machine Manager e Data Protection Manager seguiranno un rilascio di versioni aggiornate ogni 6 mesi (semi-annual channel). Questo mese c’è stato il primo rilascio con la versione 1801 di System Center.

Figura 6 – Sintesi delle novità introdotte nella versione 1801 di System Center

Per conoscere i dettagli delle novità introdotte in questo rilascio è possibile consultare l’annuncio ufficiale. Si ricorda infine che per le release appartenenti al semi-annual channel è garantito un supporto di 18 mesi.

System Center Configuration Manager

Rilasciata la versione 1802 per il branch Technical Preview di System Center Configuration Manager: Update 1802 for Configuration Manager Technical Preview Branch.

Questa release introduce un numero considerevole di novità su diversi ambiti, tra i quali: OSD, Cloud Management Gateway, funzionalità di Windows 10 e Office 365, Software Center e Site Server High Availability.

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

La funzionalità definita “Updates and Recommendations”, introdotta in SCOM 2016 per i Management Pack di casa Microsoft, è utile per facilitare il processo di discovery dei MPs appropriati per effettuare il monitor dei differenti workload presenti nella propria infrastruttura e per mantenerli aggiornati. Questa funzionalità è abilitata per ben oltre 110 workload Microsoft. Microsoft ha annunciato che sta estendendo questa funzionalità anche per i MPs realizzati e offerti da terze parti. Nella release 1801 di Operations Manager sono al momento contemplati i MPs dei seguenti partner esterni:

Figura 7 – Funzionalità Updates and Recommendations con MPs dei partners

Come conseguenza del rilascio della versione 1801 di System Center sono stati resi disponibili anche i seguenti nuovi Management Pack di SCOM:

System Center Service Manager

Rilasciata una nuova versione del Service Manager Authoring Tool.

Valutazione di OMS e System Center

Si ricorda che per testare e valutare in modo gratuito Operations Management Suite (OMS) è possibile accedere a questa pagina e selezionare la modalità che si ritiene più idonea per le proprie esigenze.

Per provare i vari componenti di System Center 2016 è possibile accedere all’Evaluation Center e, dopo essersi registrati, è possibile avviare il periodo di trial.

Tutto quello che c’è da sapere sui workspace di OMS Log Analytics

Per poter utilizzare Log Analytics è necessario disporre di un workspace OMS, che costituisce l’ambiente dedicato di Log Analytics all’interno del quale troviamo il repository dei dati e le differenti solution. In questo articolo verranno presi in considerazione i diversi aspetti che è bene valutare in merito ai workspace di Log Analytics.

Che cos’è un workspace?

Un workspace di Log Analytics non è altro che un contenitore in ambiente Azure all’interno del quale vengono collezionati, aggregati e analizzati i dati provenienti da fonti differenti e raccolti da Log Analytics.

Per poter creare un workspace è necessario disporre di una subscription Azure. A partire dal 26 settembre 2016 infatti tutti i workspace devono necessariamente essere collegati ad una subscription Azure al momento della creazione. Durante il processo di creazione del workspace sarà inoltre necessario assegnargli un nome, che al momento non è possibile cambiare post creazione, ed associarlo ad un Resource Group esiste oppure crearne uno specifico. Infine viene richiesto in quale location crearlo e quale modello di licensing adottare. A questo proposito si ricorda che Log Analytics può essere licenziato secondo differenti modalità che è possibile consultare a questo indirizzo.

Figura 1 – Creazione di un workspace Log Analytics

Figura 2 – Location attualmente disponibili per la creazione di un workspace

Quanti workspace è opportuno creare?

All’interno di ogni subscription Azure possono essere creati più workspace. Quando si ha la necessità di stabilire il numero appropriato di workspace da creare è opportuno prendere in considerazione i seguenti fattori:

  • Locazione geografica dei dati. Realtà aziendali geograficamente distribuite a livello globale possono avere la necessità di archiviare i dati in region specifiche per contemplare politiche aziendali di sovranità del dato e per ragioni di compliance. Un altro aspetto da tenere in considerazione può essere la presenza di altre risorse in ambiente Azure che devono riportare dati in Log Analytics. In questi scenari, per evitare addebiti causati dal trasferimento di dati in uscita, è bene mantenere, qualora possibile, le risorse e il workspace OMS nella medesima region.
  • Data Isolation. Nel caso si debbano gestire dati in Log Analytic provenienti da diversi clienti (ad esempio per quanto riguarda i Service Provider) oppure da unità organizzative distinte che per diversi motivi devono essere mantenuti isolati è opportuno creare workspace distinti.
  • Maggiore flessibilità per la fatturazione. La fatturazione avviene per workspace quindi può essere utile, per mantenere ben distinti i costi di fatturazione e averne maggiore visibilità, creare workspace separati per i differenti dipartimenti oppure per le diverse business unit aziendali.

Quando si valuta il numero di workspace di Log Analytics che è necessario creare è bene tenere in considerazione che se nel proprio ambiente è stata attivata l’integrazione tra System Center Operations Manager e OMS Log Analytics sarà possibile connettere ogni Operations Manager management group con un solo workspace. Il Microsoft Monitoring Agent può invece essere configurato direttamente per riportare i dati sia verso Operations Manager che verso diversi workspace di Log Analytics.

Figura 3 – Configurazione Microsoft Monitoring Agent per riportare dati a più workspace

Come fare query tra workspace differenti

Grazie al nuovo linguaggio introdotto nei mesi scorsi in Log Analycts è ora possibile creare delle query cross workspace al fine di analizzare e aggregare dati inclusi in workspace distinti. Questa tipologia di query è possibile eseguirla accedendo al nuovo portale Advanced Analytics.

Durante la creazione delle query, per referenziare un altro workspace è necessario utilizzare l’espressione workspace(). Maggiori dettagli a riguardo è possibile consultarli nella documentazione ufficiale Microsoft.

Figura 4 – Esempio di query cross workspace

Come migrare workspace

La migrazione di un workspace Log Analytics esistente verso un’altra subscription Azure può avvenire direttamente dal portale Azure oppure utilizzando il cmdlet powershell Move-AzureRmResource. Non esiste la possibilità di migrare i dati contenuti in un workspace verso un altro workspace Log Analytics oppure di cambiare la region dove risiedono i dati.

Figura 5 – Seleziono il cambio della subscription

Figura 6 – Migrazione di un workspace verso un’altra subscription Azure

A seconda delle solution installate potrebbe essere necessario ripetere l’installazione delle stesse post migrazione.

Conclusioni

Quando si decide adottare Log Analytics è opportuno effettuare un assessment dettagliato per stabilire il design di implementazione più opportuno, che passa in primis dagli aspetti trattati riguardanti i workspace. Determinate scelte effettuate al momento della creazione dei workspace non possono essere facilmente cambiate in seguito e per questo motivo è opportuno effettuarle in modo mirato, seguendo le best practice di implementazione, per effettuare un deployment di successo di Log Analytics.