Archivi categoria: Operations Management Suite

Come connettere soluzioni di security di terze parti a OMS

Tra le varie funzionalità di Operations Management Suite (OMS) c’è la possibilità di collezionare eventi generati nel formato standard Common Event Format (CEF) ed eventi generati da device Cisco ASA. Molti vendor di soluzioni di security generano eventi e file di log rispettando la sintassi definita nello standard CEF per garantire l’interoperabilità con altre soluzioni. Configurando l’invio di dati in questo formato verso OMS e adottando la soluzione OMS Security and Audit è possibile mettere in correlazione le diverse informazioni raccolte, sfruttare il potente motore di ricerca di OMS per monitorare la propria infrastruttura, recuperare informazioni di audit, rilevare eventuali problemi e utilizzare la funzionalità di Threat Intelligence.

In questo articolo verranno approfonditi gli step necessari per integrare i log generati da Cisco Adaptive Security Appliance (ASA) all’interno di OMS. Per poter configurare questa integrazione è necessario disporre di una macchina Linux con installato l’agente di OMS (versione 1.2.0-25 o successiva) e configurarla per inoltrare i log ricevuti dagli apparati verso il workspace OMS. Per l’installazione e l’onboard dell’agente Linux vi rimando alla documentazione ufficiale Microsoft: Steps to install the OMS Agent for Linux.

Figura 1 – Architettura per la raccolta dei log da Cisco ASA in OMS

L’apparato Cisco ASA deve essere configurato per inoltrare gli eventi generati verso la macchina Linux definita come collector. Per farlo è possibile utilizzare gli strumenti di gestione del device Cisco ASA come ad esempio Cisco Adaptive Security Device Manager:

Figura 2 – Esempio di configurazione Syslog Server di Cisco ASA

Sulla macchina Linux deve essere in esecuzione il daemon syslog che si occuperà di inviare gli eventi verso la porta UDP 25226 locale. L’agente OMS è infatti in ascolto su questa porta per tutti gli eventi in ingresso.

Per fare questa configurazione è necessario creare il file security-config-omsagent.conf rispettando le specifiche seguenti a seconda della tipologia di Syslog in esecuzione sulla macchina Linux. Un possibile esempio di configurazione per inviare tutti gli eventi con facility local4 all’agente OMS è la seguente:

  • In caso di daemon rsyslog il file dovrà essere presente nella directory /etc/rsyslog.d/ con il seguente contenuto:
#OMS_facility = local4

local4.* @127.0.0.1:25226
  • In caso di daemon syslog-ng il file dovrà essere presente nella directory /etc/syslog-ng/ con il seguente contenuto:
#OMS_facility = local4  

filter f_local4_oms { facility(local4); };  

destination security_oms { tcp("127.0.0.1" port(25226)); };  

log { source(src); filter(f_local4_oms); destination(security_oms); };  

Lo step successivo è la creazione del file di configurazione Fluentd denominato security_events.conf che consente di collezionare e di fare il parsing degli eventi ricevuti dall’agente OMS. Il file è possibile scaricarlo dal repository GitHub e dovrà essere copiato nella directory /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/.

Figura 3 – File di configurazione Fluentd dell’agent OMS

Giunti a questo punto, per rendere effettive le modifiche apportate, è necessario riavviare il daemon syslog e l’agente OMS tramite i seguenti comandi:

  • Riavvio daemon Syslog:
sudo service rsyslog restart oppure sudo /etc/init.d/syslog-ng restart
  • Riavvio agente OMS:
sudo /opt/microsoft/omsagent/bin/service_control restart

Completate queste operazioni è opportuno visualizzare il log dell’agente OMS per verificare la presenza di eventuali errori utilizzando il comando:

tail /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log

Dopo aver concluso la configurazione dal portale OMS sarà possibile digitare in Log Search la query Type=CommonSecurityLog per analizzare i dati collezionati dall’apparato Cisco ASA:

Figura 4 – Query per visualizzare eventi del Cisco ASA raccolti in OMS

La raccolta di log di questo tipo è arricchita dalla funzionalità di Threat Intelligence presente nella solution Security & Compliance che grazie a una correlazione pressoché in tempo reale dei dati raccolti nel repository OMS con le informazioni provenienti dai principali vendor di soluzioni di Threat Intelligence e con i dati forniti dai centri di sicurezza Microsoft consente di individuare la natura e l’esito di eventuali attacchi che coinvolgono i nostri sistemi, compresi gli apparati di rete.

Accedendo alla solution Security And Audit dal portale OMS viene visualizzata la sezione Threat Intelligence:

Figura 5 – Informazioni di Threat Intelligence

Selezionando il tile Detected threat types è possibile consultare i dettagli relativi ai tentativi di intrusione che nel caso seguente coinvolgono l’apparato Cisco ASA:

Figura 5 – Detected threat su Cisco ASA

In questo articolo si è entrati nel dettagli della configurazione di Cisco ASA, ma configurazioni analoghe è possibile farle per tutte le soluzioni che supportano la generazione di eventi nel formato standard Common Event Format (CEF). Per configurare l’integrazione di Check Point Securtiy Gateway con OMS vi rimando al documento Configuring your Check Point Security Gateways to send logs to Microsoft OMS.

Conclusioni

Utilizzando Operations Management Suite c’è la possibilità di consolidare e di mettere in correlazione eventi provenienti da diversi prodotti che forniscono soluzioni di security consentendo di avere una panoramica completa della propria infrastruttura e di rispondere in modo rapido e preciso ad eventuali incident di security.

OMS Azure Backup: nuove funzionalità di reporting tramite Power BI

Recentemente è stata introdotta la possibilità in Azure Backup 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. Un aspetto particolarmente interessante è la possibilità di generare reportistica anche cross subscription e cross vault di Azure. 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. Per consultare i benefici di questa funzionalità e valutare come analizzare i dati tramite Power BI vi invito a consultare il post “Gain business insights using Power BI reports for Azure Backup”.  In questo articolo verranno analizzati gli step necessari per configurare la reportistica di Azure Backup.

Accedendo dal portale Azure al Recovery Service Vault che contiene le risorse protette compare l’avviso della disponibilità di questa nuova funzionalità:

Figura 1 – Avviso della disponibilità della nuova funzionalità di reportistica nel Recovery Services vault

Per attivare la funzionalità è necessario posizionarsi nelle impostazioni del Recovery Services vault e nella sezione “Monitoring and Reports” selezionare “Backup Reports”:

Figura 2 – Configurazione della funzionalità di reportistica

Selezionando il pulsante “Configure” si avvia il processo di configurazione che richiede due step distinti. Nel primo step è necessario selezionare lo Storage Account sul quale verranno archiviate le informazioni necessarie per la generazione della reportistica. Inoltre c’è la possibilità di inviare queste informazioni ad un workspace di Log Analytics. Per ogni tipologia di log è possibile selezionare il periodo di retention, il quale si applica solamente alle informazioni presenti sullo Storage Account e non a quelle invitate al workspace di OMS. Impostando a 0 giorni il periodo di retention i dati non vengono mai rimossi dallo Storage Account.

Figura 3 – Step 1: Configurazione della diagnostica

All’interno dello storage account viene creato un apposito container per salvare i log di Azure Backup denominato insights-logs-azurebackupreport:

Figura 4 – Azure Backup container per i job di Azure Backup

Il secondo step di configurazione richiede l’accesso al portale Power BI e l’aggiunta dell’Azure Backup Content Pack svolgendo gli step seguenti:

Figura 5 – Aggiunta Azure Backup Content Pack dal portale Power BI

Giunti a questo punto è necessario inserire il nome dello Storage Account sul quale, durante lo step 1 della configurazione, si è scelto di salvare le informazioni relative ai backup.

Figura 6 – Inserimento del nome dello Storage Account

Nella fase successiva viene richiesta l’autenticazione allo storage account tramite l’apposita access key:

Figura 7 – Inserimento chiave per autenticazione allo Storage Account

Dopo aver completato questi passaggi dal portale Power BI è possibile consultare tramite l’apposita dashboard tutte le informazioni relative ad Azure Backup e se necessario personalizzare la reportistica in base alle proprie esigenze.

Figura 8 – Azure Backup Dashboard presente nel portale Power BI

Avendo scelto di inviare le informazioni di diagnostica anche verso Log Analytics è possibile, accedendo al portale OMS, interrogare il repository tramite la seguente query e recuperare le informazioni relative ad Azure Backup:

Figura 9 – Ricerca degli eventi di Azure Backup in Log Analytics

Utilizzando il View Designer di OMS è inoltre possibile costruirsi una vista personalizzata utilizzando i dati di Azure Backup raccolti in Log Analytics.

 

Conclusioni

Questa nuova funzionalità consente di avere un controllo completo sullo stato dei backup della propria infrastruttura e di tenere facilmente sotto controllo gli SLA nel rispetto delle compliance aziendali. Il tutto in modo semplice e utilizzando una soluzione nel cloud completamente gestita. Tutto ciò che serve è uno storage account di Azure e una sottoscrizione Power BI. L’analisi dei dati raccolti tramite Power BI è inoltre estremamente flessibile grazie alle ampie possibilità di personalizzazione fornite dallo strumento.

OMS Log Analytics: la soluzione di Update Management per sistemi Linux

Utilizzando la soluzione di Update Management di Operations Manager Suite (OMS) si ha la possibilità di gestire e controllare in modo centralizzato lo stato di aggiornamento dei sistemi in ambienti eterogenei composti sia da macchine Windows che Linux e in modo indipendente dal loro posizionamento, on-premises piuttosto che nel cloud. In questo articolo verranno approfonditi gli aspetti della solution per quanto riguarda i sistemi Linux.

La soluzione di Update Management consente di valutare rapidamente lo stato degli aggiornamenti disponibili su tutti i server con l’agente di OMS installato ed è in grado di avviare il processo di installazione degli aggiornamenti mancanti. I sistemi Linux configurati per utilizzare questa solution richiedono oltre all’agente OMS la presenza di PowerShell Desired State Configuration (DSC) per Linux e dell’Automation Hybrid Runbook Worker (installati in modo automatico).

La solution al momento supporta le seguenti distribuzioni Linux:

  • CentOS 6 (x86/x64) e CentOS 7 (x64).
  • Red Hat Enterprise 6 (x86/x64) e Red Hat Enterprise 7 (x64).
  • SUSE Linux Enterprise Server 11 (x86/x64) e SUSE Linux Enterprise Server 12 (x64).
  • Ubuntu 12.04 LTS e successive (x86/x64).

Inoltre per poter funzionare in modo corretto è necessario che il sistema Linux abbia accesso ad un update repository. A tal proposito è bene precisare che al momento non c’è la possibilità da OMS di selezionare quali aggiornamenti applicare, ma vengono proposti tutti gli aggiornamenti disponibili dall’update repository configurato sulla macchina. Per aver un maggior controllo sugli aggiornamenti da applicare si potrebbe valutare l’utilizzo di un update repository appositamente creato e personalizzato che contiene solamente gli aggiornamenti che si desidera approvare.

Nel diagramma seguente viene mostrato il flusso delle operazioni che viene svolto dalla solution per riportare verso il workspace OMS lo stato di compliance e per applicare gli aggiornamenti mancanti:

Figura 1 – Flusso delle operazioni svolte sui sistemi Linux

  1. L’agente OMS per Linux effettua una scansione ogni 3 ore per rilevare eventuali aggiornamenti mancanti e riporta l’esito della scansione verso il workspace OMS.

Figura 2 – Dashboard OMS della soluzione di Update Management

  1. L’operatore utilizzando la dashboard di OMS può consultare l’update assessment e definire la schedulazione per il deployment degli aggiornamenti:

Figura 3 – Gestione degli Update Deployment

Figura 4 – Dashboard OMS della soluzione di Update Management

Nella creazione dell’Update Deployment viene definito un nome, l’elenco dei sistemi da coinvolgere, che può essere fornito in modo esplicito oppure utilizzando una query di Log Analytics, e una schedulazione.

  1. Il componente Hybrid Runbook Worker in esecuzione sui sistemi Linux controlla la presenza di finestre manutentive e la disponibilità di eventuali deployment da applicare. A tal proposito è bene specificare che abilitando la solution di Update Management ogni sistema Linux connesso al workspace OMS viene automaticamente configurato come Hybrid Runbook Worker per poter eseguire runbook creati per la distribuzione degli aggiornamenti. Inoltre ogni sistema gestito dalla solution costituisce un Hybrid Runbook Worker Group all’interno dell’Automation Account di OMS seguendo la naming convention Hostname_GUID:

Figura 5 – Hybrid Worker Groups

  1. Nel caso ad una macchina sia associato un Update Deployment (come membro diretto oppure perché appartiene ad uno specifico gruppo di computer) su di essa viene avviato il package manager (Yum, Apt, Zypper) per l’installazione degli aggiornamenti. L’installazione degli aggiornamenti viene pilotato da OMS tramite specifici runbook all’interno di Azure Automation. Questi runbook non sono visibili in Azure Automation e non richiedono nessuna configurazione da parte dell’amministratore.

Figura 6 – Azure Automation Account utilizzato dalla solution di Update Management

  1. Al termine dell’installazione l’agente di OMS per Linux riporta lo stato dell’Update Deployment e di compliance verso il workspace OMS.

Conclusioni

Microsoft Operations Management Suite è uno strumento consolidato che consente di gestire e monitorare ambienti eterogenei. Ancora oggi purtroppo ci si trova di fronte al dibattito sulla reale necessità di mantenere aggiornati periodicamente i sistemi Linux, ma considerando anche alcuni recenti incident di security causati da sistemi non aggiornati, è evidente che è bene disporre di una soluzione che consenta di gestire gli aggiornamenti anche per le macchine Linux. La solution di Update Management di OMS è in continua evoluzione, ma già oggi ci consente di controllare e gestire la distribuzione degli aggiornamenti anche sui sistemi Linux in modo semplice ed efficace.

Per maggiori dettagli vi invito a consultare la documentazione ufficiale Microsoft della Solution di Update Management di OMS.

Per approfondire ulteriormente questa e altre funzionalità è possibile attivare gratuitamente OMS.

 

OMS Security: presentazione della soluzione di Antimalware Assessment

Microsoft Operations Management Suite (OMS) mette a disposizione una interessante solution denominata Antimalware Assessment grazie alla quale è possibile monitorare lo stato della protezione antimalware sull’intera infrastruttura e rilevare facilmente potenziali minacce.

Per poter utilizzare la solution Antimalware Assessment è necessario sottoscrivere l’offerta “Security & Compliance” di OMS. L’installazione della solution può essere fatta seguendo la procedura illustrata nella parte iniziale dell’articolo OMS Security: Threat Intelligence oppure accedendo direttamente all’Azure Marketplace. Dopo essere attivata nel workspace di OMS non è necessaria nessuna ulteriore configurazione ed è pronta per essere utilizzata.

La solution grazie a una dashboard di facile consultazione evidenzia i sistemi senza una protezione real-time antimalware attiva ed è in grado di riportare lo stato antimalware in OMS per i seguenti prodotti:

  • Windows Defender su Windows 8, Windows 8.1, Windows 10 e Windows Server 2016.
  • Windows Security Center (WSC) su Windows 8, Windows 8.1, Windows 10, Windows Server 2016.
  • System Center Endpoint Protection (versione 4.5.216 o successiva).
  • Estensione antimalware e Windows Malicious Software Removal Tool (MSRT) attivato su macchine virtuali in Azure.
  • Symantec Endpoint 12.x e 14.x.
  • Trend Micro Deep 9.6.

Al momento vengono rilevate solamente le installazioni di alcune soluzioni di vendor di terze parti quali Symantec e Trend Micro, ma con tutta probabilità questo elenco è destinato ad aumentare.

Sui sistemi monitorati da OMS viene fatto un assessment sulla protezione verificando lo stato del prodotto antimalware, se vengono eseguite analisi a intervalli regolari e se si stanno utilizzando firme risalenti a non più di sette giorni.

Nella home page del portale OMS è presente il tile Antimalware Assessment che riporta un summary dello stato dell’infrastruttura:

Figura 1 – Antimalware Assessment tile

Selezionando questo tile si accede alla dashboard della solution Antimalware Assessment che categorizza le informazioni raccolte e le riporta in 4 tile differenti:

  • Threat Status
  • Detected Threats
  • Protection Status
  • Type of Protection

Figura 2 – Dashboard Antimalware Assessment

I primi due tile sono incentrati sulle rilevazioni delle infezioni riportando la tipologia di malware intercettato, i sistemi infettati ed evidenziando situazioni dove l’antimalware non è stato in grado di pulire il sistema dall’infezione.

Selezionando la macchina infettata oppure il nome del malware si viene rimandati nella pagina di Log Search dove è possibile consultare le informazioni dettagliate del threat rilevato:

Figura 3 – Dettagli del threat rilevato

Selezionando il link View accanto al nome del threat si viene indirizzati verso l’enciclopedia dei malware di Microsoft:

Figura 4 – Ricerca all’interno dell’enciclopedia Microsoft dei malware

Selezionando il nome del malware è possibile consultare la scheda con tutti i dettagli relativi all’infezione:

Figura 5 – Scheda con le informazioni del malware

I restanti tile riportano informazioni utili sullo stato di protezione dell’infrastruttura:

  • Quali macchine non risultano protette e per quale ragione (agente disabilitato, signature non aggiornate oppure scansione non effettuata recentemente) consentendo così di intraprendere le necessarie azioni correttive.
  • L’elenco delle soluzioni antimalware rilevate sul parco macchine.

Da questi tile è possibile fare facilmente un drill down per vedere la lista delle macchine interessate, come ad esempio la lista delle macchine senza una protezione real time attiva:

Figura 6 – Macchine senza real time protection

Conclusioni

Poter contare su uno strumento in grado di identificare velocemente sistemi con una protezione antimalware non sufficiente oppure macchine compromesse da malware è di fondamentale importanza per mitigare tentativi di compromissione dei dati aziendali ed evitare importanti incidenti di security. Microsoft Operations Management Suite (OMS) oltre a queste funzionalità include altre importanti soluzioni in questo ambito che lo rendono un ottimo strumento per garantire la security e la compliance della propria infrastruttura. Per approfondire ulteriormente questa e altre funzionalità è possibile provare la soluzione OMS gratuitamente.

OMS Log Analytics: come effettuare il monitor del networking di Azure

All’interno di Log Analytics c’è la possibilità di abilitare delle solution specifiche che consentono di effettuare il monitor di alcuni componenti dell’infrastruttura di rete presente in Microsoft Azure.

Tra queste solution troviamo Network Performance Monitor (NPM) la quale è stata approfondita nell’articolo Monitorare le performance di rete con la nuova solution di OMS e che si presta molto bene anche per monitorare lo stato di salute, la disponibilità e la raggiungibilità del networking di Azure. Sono inoltre attualmente disponibili nella gallery di Operations Management Suite le seguenti solution che arricchiscono le potenzialità di monitoring lato OMS:

  • Azure Application Gateway Analytics
  • Azure Network Security Group Analytics

Abilitazione delle Solution

Accedendo al portale OMS è possibile aggiungere facilmente queste solution presenti nella gallery seguendo gli step che trovate documentati nel seguente articolo: Aggiungere soluzioni di gestione di Operations Management Suite (OMS).

Figura 1 – Solution Azure Application Gateway Analytics

Figura 2 – Solution Azure Network Security Group Analytics

Azure Application Gateway Analytics

L’Azure Application Gateway è un servizio che è possibile configurare in ambiente Azure in grado di fornire funzionalità di Application Delivery garantendo un bilanciamento applicativo layer 7. Per ottenere maggiori informazioni relative all’Azure Application Gateway è possibile consultare la documentazione ufficiale.

Per poter collezionare i log di diagnostica in Log Analytics è necessario posizionarsi nel portale Azure sulla risorsa Application Gateway che si intende monitorare e nella sezione Diagnostics logs selezionare l’invio dei log verso il workspace Log Analytics opportuno:

Figura 3 – Application Gateway Diagnostics settings

Per l’Application Gateway è possibile selezionare la raccolta dei seguenti log:

  • Log relativi agli accessi effettuati
  • Dati di performance
  • Firewall log (nel caso l’Application Gateway abbia il Web Application Firewall abilitato)

Dopo aver completato questi semplici passaggi la solution OMS installata consente di consultare facilmente i dati inviati dalla platform:

Figura 4 – Azure Application Gateway Analytics Overview nel portale OMS

All’interno della solution è possibile visualizzare un sommario delle informazioni raccolte e selezionando i singoli grafici si accede ai dettagli relativi alle categorie seguenti:

  • Application Gateway Access log
    • Errori client e server riscontrati nei log di accesso dell’Application Gateway
    • Richieste ricevute dall’Application Gateway per ora
    • Richieste fallite per ora
    • Errori rilevati per user agent

Figura 5 – Application Gateway Access log

  • Application Gateway performance
    • Stato di salute degli host che rispondono alle richieste dell’Application Gateway
    • Richieste fallite dell’Application Gateway espresso come numero massimo e con il 95° percentile

Figura 6 – Application Gateway performance

  • Application Gateway Firewall log

 

Azure Network Security Group Analytics

In Azure è possibile controllare le comunicazioni di rete tramite i Network Security Group (NSG) i quali aggregano una serie di regole (ACL) per consentire oppure negare il traffico di rete basandosi sulla direzione (in ingresso o in uscita), il protocollo, l’indirizzo e la porta sorgente oppure l’indirizzo e la porta di destinazione. I NSG vengono utilizzati per controllare e proteggere le virtual network oppure direttamente le interfacce di rete. Per tutti i dettagli relativi ai NSG è possibile consultare la documentazione ufficiale Microsoft.

Per poter collezionare i log di diagnostica dei Network Security Group in Log Analytics è necessario posizionarsi nel portale Azure sulla risorsa Network Security Group che si intende monitorare e nella sezione Diagnostics logs selezionare l’invio dei log verso il workspace Log Analytics opportuno:

Figura 7 – Abilitazione diagnostica NSG

Figura 8 – Configurazione diagnostica NSG

Sui Network Security Group è possibile raccogliere le seguenti tipologie di log:

  • Eventi
  • Contatori relativi alle rule

Giunti a questo punto nell’home page del portale OMS è possibile selezionare il tile di Overview della solution Azure Network Security Group Analytics per accedere ai dati dei NSG raccolti dalla platform:

Figura 9 – Azure Network Security Group Analytics Overview nel portale OMS

La solution mette a disposizione un summary dei log raccolti suddividendoli nelle seguenti categorie:

  • Network security group blocked flows
    • Regole del Network Security Group con traffico bloccato
    • Indirizzamenti di rete con regole di traffico bloccato

Figura 10 – Network security group blocked flows

  • Network security group allowed flows
    • Regole del Network security group con traffico consentito
    • Indirizzamenti di rete con regole di traffico consentito

Figura 11 – Network security group allowed flows

La metodologia di invio dei log di diagnostica degli Application Gateway e dei Network Security Group di Azure verso Log Analytics è cambiata recentemente introducendo i seguenti vantaggi:

  • La scrittura dei log in Log Analytics avviene direttamente senza la necessità di utilizzare degli storage account come repository. Si può comunque scegliere di salvare i log di diagnostica sugli storage account, ma non è necessario per l’invio dei dati verso OMS.
  • La latenza tra il tempo di generazione dei log e la loro consultabilità in Log Analytics è stata ridotta.
  • Sono stati semplificati gli step necessari per la configurazione.
  • Tutti le informazioni di diagnostica di Azure sono state uniformate come formato.

Conclusioni

Grazie a una sempre più completa integrazione tra Azure e Operations Management Suite (OMS) è possibile monitorare e controllare lo stato dei componenti dell’infrastruttura di rete realizzata su Azure in modo completo ed efficace, il tutto con passaggi semplici e intuitivi. Questa integrazione della platform Azure con OMS è sicuramente destinata ad arricchirsi con nuove soluzioni specifiche anche per altri componenti. Per chi è interessato ad approfondire ulteriormente questa e altre funzionalità di OMS ricordo che è possibile provare la soluzione OMS gratuitamente.

Monitorare le performance di rete con la nuova solution di OMS

In questo articolo vedremo come funziona e quali sono le caratteristiche principali della nuova solution di OMS chiamata Network Performance Monitor (NPM). Si tratta di una soluzione in grado di controllare lo stato della rete anche in presenza di architetture ibride consentendo di identificare rapidamente l’eventuale segmento o device di rete che in un determinato momento sta causando oppure ha causato disservizi o problemi di performance lato network. Questo nuovo servizio effettua il monitor della rete in modalità application centric e tale caratteristica la rende differente rispetto alle tradizionali soluzioni di monitor presenti sul mercato che tendenzialmente hanno un focus particolare sul controllo degli apparati di rete.

Figura 1 – Overview della solution NPM

Utilizzando la solution Network Performance Monitor di OMS è possibile avere una visibilità totale per quanto riguarda la disponibilità, le latenze e le performance della propria infrastruttura di rete. Il processo di attivazione e di funzionamento è il seguente:

  • Accedendo al portale OMS si aggiunge la solution “Network Performance Monitor (NPM)” presente nella gallery delle solution di OMS. Per farlo è possibile seguire gli step che trovate documentati nel seguente articolo: Aggiungere soluzioni di gestione di Operations Management Suite (OMS)
  • La solution richiede l’agente OMS installato sulle macchine presenti in ogni subnet che si desidera monitorare. Si tratta dell’agente OMS tradizionale e non è richiesta l’installazione di nessun ulteriore componente.
  • Le macchine con a bordo l’agente OMS effettueranno il download da OMS del Network Monitoring Intelligence Pack il quale consente di effettuare il detect della subnet su cui è attestata la macchina e di fare l’upload di queste informazioni verso il workspace OMS.
  • L’agente recupera a sua volta le configurazioni della rete da OMS e vengono effettuati dei probe per individuare eventuali perdite di pacchetti e le performance di rete. Network Performance Monitor (NPM) fa uso di transazioni sintetiche per calcolare quanti pacchetti vengono persi e la latenza presente per i vari link di rete. I pacchetti di probe che vengono inviati tra i vari agenti OMS per effettuare l’assessment e per monitorare lo stato della rete possono essere TCP (pacchetti TCP SYN seguiti da un TCP handshake) oppure ICMP (messaggi ICMP ECHO come quelli generati dall’utility tradizionale Ping). L’utilizzo del protocollo ICMP per effettuare i probe è utile in ambienti dove a causa di determinate restrizioni gli apparati di rete non sono in grado di rispondere a dei probe di tipologia TCP.
  • Tutti i dati vengono inviati verso il workspace OMS e vengono aggregati per visualizzare in modo chiaro e comprensibile lo stato della rete. Grazie infatti al Topology Map si ha a disposizione una visualizzazione grafica di tutti i percorsi di rete presenti tra i vari endpoint che aiuta a localizzare rapidamente eventuali problemi di rete. Le topology map sono interattive e consentono di fare il drill down sui vari collegamenti di rete per visualizzare hop-by-hop i dettagli della topologia. Inoltre è possibile impostare dei filtri in base allo stato di salute dei link, effettuare lo zoom sui segmenti di rete e personalizzare la topologia.

Figura 2 – Network Topology

Le principali caratteristiche della soluzione sono le seguenti:

  • La soluzione è agnostica dal punto di vista dei dispositivi di rete e dei relativi vendor ed è in grado di monitorare qualsiasi rete IP.
  • La solution è in grado di effettuare il monitor della connettività tra:
    • Data-center dislocati in site differenti e connessi tramite rete pubblica o privata.
    • Cloud pubblici quali Azure e AWS, reti on-premises e postazioni utente.
    • Reti virtuali presenti presso cloud pubblici e on-premises.

      Figura 3 – Componenti monitorati dalla solution NPM

  • NPM consente di identificare in modo preciso e dettagliato il path di rete che sta causando un disservizio o un degrado di performance, a prescindere dalla complessità della rete, grazie al modello di monitoring adottato:

    Figura 4 – Modello di monitoring

  • Grazie alla funzionalità definita Network State Recorder è possibile non solo vedere lo stato di salute attuale della rete, ma di valutarlo anche in un determinato momento del passato, utile per investigare segnalazioni di problematiche transitorie.

    Figura 5 – Network State Recorder

  • Utilizzando la funzionalità di alerting inclusa in OMS è possibile configurare l’invio di segnalazioni tramite posta elettronica a fronte di problematiche riscontrate dalla solution NPM. Inoltre è possibile scatenare azioni di remediation tramite runbook oppure configurare webhooks per integrarsi con una soluzione esistente di service management.

    Figura 6 – NPM alerting

  • La soluzione supporta non solo sistemi Windows Server ma l’agente funziona anche per sistemi operativi client (Windows 10, Windows 8.1, Windows 8 e Windows 7) ed è presente anche il supporto per sistemi operativi Linux (server e workstation).

Per quanto riguarda il costo ed il modello di licensing la solution Network Performance Monitor (NPM) è parte di OMS Insight & Analytics. Nella pagina Prezzi di Microsoft Operations Management Suite trovate tutti i dettagli inerenti al pricing di OMS.

 

Conclusioni

In ambienti IT che vedono architetture sempre più complesse è utile disporre di uno strumento per monitorare in modo efficace lo stato della rete e che permette di isolare con precisione la sorgente di eventuali problemi. Utilizzando la solution Network Performance Monitor (NPM) di OMS si ha una visibilità completa della rete anche in architettura ibride e si può agire in modo proattivo nell’identificazione di potenziali problemi. NPM è inoltre uno strumento adatto non solo per gli amministratori di rete, ma grazie alle sue caratteristiche può essere molto utile e facilmente utilizzabile anche da chi gestisce l’infrastruttura e gli applicativi.  Per chi è interessato ad approfondire ulteriormente questa e altre funzionalità di OMS ricordo che è possibile provare la soluzione OMS gratuitamente. Per maggiori informazioni relative alla solution Network Performance Monitor (NPM) è possibile consultare la documentazione ufficiale.

OMS Security: Threat Intelligence

Tra le varie funzionalità offerte da Operations Management Suite (OMS) c’è la possibilità di attivare la solution denominata Security & Compliance che consente di identificare, valutare e mitigare potenziali rischi di security sui nostri sistemi. La solution è possibile attivarla facilmente con pochi passaggi:

  1. Accedo al portale OMS e seleziono il tile “Solutions Gallery”

Figura 1 – Step 1: attivazione solution Security & Compliance

  1. Tra le varie soluzioni offerte ho la possibilità di aggiungere “Security & Compliance” che al momento comprende le solution “Antimalware Assessment” e “Security and Audit

Figura 2 – Step 2: attivazione solution Security & Compliance

  1. Seleziono il Workspace OMS e premendo il pulsante Create la solution viene aggiunta e resa disponibile per essere utilizzata

Figura 3 – Step 3: attivazione solution Security & Compliance

In seguito all’attivazione della solution OMS si collegherà ai sistemi con l’agente installato per effettuare un security assessment che può richiedere inizialmente anche alcune ore, per poi riportare i dati elaborati nel portale. La solution è in grado di esaminare sia macchine Windows che sistemi Linux e aiuta a proteggere l’infrastrutture sia essa on-premises o nel cloud. In questo articolo approfondiremo il funzionamento del meccanismo di Threat Intelligence.

Figura 4 – Architettura Threat Intelligence

Threat Intelligence ricopre un ruolo fondamentale nell’ambito della soluzione di security di OMS grazie a una correlazione pressoché in tempo reale dei dati raccolti nel repository OMS con le informazioni provenienti dai principali vendor di soluzioni di Threat Intelligence e con i dati forniti dai centri di sicurezza Microsoft. Non dimentichiamoci che Microsoft lavora costantemente per proteggere i propri servizi nel cloud ed ha pertanto una visibilità unica e molto estesa delle minacce che possono affliggere potenzialmente i nostri sistemi. Fornendo questa funzionalità Microsoft consente ai propri clienti di beneficiare facilmente della sua conoscenza per proteggere le risorse, rilevare gli attacchi ed agire agli stessi con una rapida risposta senza dover ricorrere a complessi scenari di integrazione.

Threat Intelligence è in grado di fornire le seguenti informazioni che consentono ai team di security di effettuare le dovute azioni e di capire l’eventuale livello di compromissione dei propri sistemi:

  • Rileva la natura dell’attacco
  • Determina l’intento dell’attacco, utile per capire se si tratta di un attacco mirato alla propria organizzazione per acquisire informazioni specifiche oppure se si tratta di un attacco casuale e massivo
  • Identifica da dove deriva l’attacco
  • Intercetta eventuali sistemi compromessi e riporta i server che effettuano traffico considerato malevole verso l’esterno
  • Riporta quali file sono stati eventualmente acceduti

Per accedere alle informazioni di Threat Intelligence nella dashboard principale del portale OMS è necessario selezionare il tile “Security and Audit”:

Figura 5 – Tile Security and Audit

Nella dashboard “Security and Audit” è presente la sezione Threat Intelligence in seguito riportata:

Figura 6 – Informazioni di Threat Intelligence

Nel tile Server with outbound malicious traffic vengono segnalati i sistemi server monitorati che stanno generando traffico malevole verso Internet. Nel caso vengano segnalati sistemi in questo tile è opportuno intraprendere immediatamente dei rimedi.

Nel tile Detected threat types viene mostrato un summary dei threat rilevati recentemente:

Figura 7 – Tile Detected threat types

 Selezionando il tile è inoltre possibile ottenere maggiori dettagli a riguardo:

Figura 8 – Dettagli relative al threat rilevato

Threat Intelligence mette a disposizione anche la visualizzazione della mappa degli attacchi che consente di identificare velocemente da quale parte del globo vengono effettuati. Le frecce di colore arancione segnalano la presenza di traffico maligno in ingresso, mentre le frecce di colore rosso evidenziano traffico maligno in uscita verso determinate location. Selezionando una freccia specifica si ottengono ulteriori dettagli in merito alla fonte dell’attacco:

Figura 9 – Threat Intelligence map

Conclusioni

Rilevare potenziali attacchi e rispondere in modo rapido ed efficace a incidenti di security che avvengono nel proprio ambiente è di fondamentale importanza. Attivando la solution “Security & Compliance” di Microsoft Operations Management Suite (OMS) è possibile utilizzare la funzionalità di Threat Intelligence per rendere più efficace la propria strategie in ambito security ed avere a disposizione un potente strumento in grado di ridurre al minimo l’entità di potenziali incidenti di security. Per chi è interessato ad approfondire ulteriormente questa e altre funzionalità di OMS ricordo che è possibile provare la soluzione OMS gratuitamente.

Come migrare sistemi verso Microsoft Azure utilizzando OMS Azure Site Recovery

Nell’articolo OMS Azure Site Recovery: panoramica della soluzione sono state presentate le caratteristiche di Azure Site Recovery e sono stati esaminati gli aspetti che la rendono una efficace e flessibile soluzione per la creazione di strategie di business continuity e di disaster recovery per il proprio data center. In questo articolo vedremo come utilizzare Azure Site Recovery per migrare ambienti anche potenzialmente eterogenei verso Microsoft Azure. Sempre più spesso ci si trova infatti di fronte all’esigenza non solo di creare nuove macchine virtuali nella cloud pubblica di Microsoft, ma anche di migrare sistemi già esistenti. Per svolgere queste migrazioni è possibile adottare diverse strategie, tra le quali compare anche Azure Site Recovery (ASR) che ci consente di migrare agilmente macchine virtuali presenti su Hyper-V, VMware, sistemi fisici e workload di Amazon Web Services (AWS) verso Microsoft Azure.

Nella seguente tabella vengono riportati quali scenari di migrazione è possibile affrontare con ASR:

Sorgente Destinazione Tipologia di SO Guest supportati
Hyper-V 2012 R2 Microsoft Azure Tutti i SO guest supportati in Azure
Hyper-V 2008 R2 SP1 and 2012 Microsoft Azure Windows e Linux *
VMware e Server Fisici Microsoft Azure Windows e Linux*
Amazon Web Services (Windows AMIs) Microsoft Azure Windows Server 2008 R2 SP1+

* Supporto limitato a Windows Server 2008 R2 SP1+, CentOS 6.4, 6.5, 6.6, Oracle Enterprise Linux 6.4, 6.5, SUSE Linux Enterprise Server 11 SP3

Quando si ha la necessità di effettuare attività di migrazione solitamente è di fondamentale importanza rispettare i seguenti punti:

  • Ridurre al minimo il tempo di downtime dei workload di produzione durante il processo di migrazione.
  • Avere la possibilità di testare e validare il funzionamento della soluzione nell’ambiente di destinazione (Azure nel caso specifico) prima di convalidare la migrazione.
  • Effettuare un’unica migrazione dei dati utile sia per il processo di convalida che per la migrazione vera e propria.

Con ASR tutto ciò è possibile seguendo questo semplice flusso di operazioni:

Figura 1 – Flusso di migrazione con ASR

 

Vediamo ora nel dettaglio quali sono le operazioni da svolgere in uno scenario di migrazione di macchine virtuali presenti su un host Hyper-V 2012 R2 verso Microsoft Azure.

Come prima cosa dal portale Azure è necessario creare un Recovery Service Vault nella subscription sulla quale si desidera migrare le macchine virtuali:

Figura 2 – Creazione Recovery Service Vault

In seguito è necessario preparare l’infrastruttura per poter utilizzare Azure Site Recovery. Il tutto è possibile farlo seguendo la procedura guidata  proposta dal portale Azure:

Figura 3 – Preparazione infrastruttura

Dopo aver dichiarato lo scenario di migrazione (macchine virtuali su host Hyper-V non gestito da SCVMM verso Azure), assegno un nome al site Hyper-V e associo ad esso l’host Hyper-V che detiene le macchine virtuali:

Figura 4 – Preparazione Source: step 1.1

Figura 5 – Preparazione Source: step 1.2

Giunti a questo punto è necessario installare sull’host Hyper-V il provider Microsoft Azure Site Recovery. Durante l’installazione è possibile specificare un server proxy e la chiave di registrazione al vault, la quale è necessario scaricarla direttamente dal portale Azure:

Figura 6 – Installazione provider ASR

Figura 7 – Configurazione accesso al vault

Figura 8 – Impostazioni proxy

Figura 9 – Registrazione al vault ASR

Dopo aver atteso qualche istante il server Hyper-V appena registrato al vault di Azure Site Recovery comparirà sul portale Azure:

Figura 10 – Preparazione Source: step 2

Lo step successivo richiede di specificare su quale subscription Azure verranno create le macchine virtuali e il modello di deployment (Azure Resource Manager – ARM nel caso riportato). A questo punto è importante verificare che sia presente uno storage account e una virtual network su cui attestare le macchine virtuali:

Figura 11 – Preparazione Target

Lo step seguente consente di specificare quale policy di replica associare al site. Nel caso non siano presenti policy in precedenza create è opportuno configurare una nuova policy stabilendo i parametri riportati in seguito, più idonei al proprio ambiente:

Figura 12 – Impostazione policy di replica

Figura 13 – Associazione alla policy di replica

L’ultimo step di preparazione dell’infrastruttura richiede l’esecuzione del Capacity Planner, strumento molto utile per stimare l’utilizzo di banda e di storage. Inoltre permette di valutare una serie di altri aspetti che è necessario prendere bene in considerazione in scenari di replica per evitare problematiche. Lo strumento può essere scaricato direttamente dal portale Azure:

Figura 14 – Capacity planning

Giunti a questo punto sono state completate tutte le operazioni di configurazione e preparazione dell’infrastruttura ed è possibile proseguire selezionando quali macchine si desidera replicare dal site precedentemente configurato:

Figura 15 – Abilitazione replica

Nello step successivo è possibile selezionare le configurazioni delle macchine replicate in termini di Resource Group, Storage Account e Virtual Network – Subnet:

Figura 16 – Impostazioni di recovery del target

Tra tutte le macchine ospitate sull’host Hyper-V è opportuno selezionare per quali si desidera attivare la replica verso Azure:

Figura 17 – Selezione VMs da replicare

Per ogni macchina virtuale selezionata è necessario specificare il sistema operativo guest (Windows oppure Linux), qual’è il disco che detiene il sistema operativo e quali dischi dati si vuole replicare:

Figura 18 – Proprietà delle VMs in replica

Dopo aver concluso la configurazione di tutti gli step inizierà il processo di replica secondo le impostazioni configurate nella policy specifica:

Figura 19 – Step di replica

Terminata la replica iniziale è consigliato verificare che la macchina virtuale funzioni regolarmente in ambiente Microsoft Azure effettuando un “Test Failover” (punto 1 dell’immagine seguente) e dopo aver svolto i controlli opportuni è necessario effettuare un “Planned Failover” (punto 2) per avere la macchina virtuale disponibile e pronta per essere utilizzata in ambiente di produzione. Al termine di questa operazione può ritenersi completata la migrazione verso Azure del vostro sistema e sarà possibile rimuovere la configurazione della replica all’interno del Recovery Service Vault (punto 3).

Figura 20 – Finalizzazione del processo di migrazione

Conclusioni

Azure Site Recovery con semplici passaggi guidati ci consente di migrare facilmente, in modo sicuro e con un downtime minimo sistemi che si trovano presso i propri datacenter oppure workload presenti in Amazon Web Services (AWS) verso Microsoft Azure. Vi ricordo che le funzionalità di Azure Site Recovery possono essere testate attivando un ambiente trial di Operations Management Suite oppure di Microsoft Azure.

OMS Azure Site Recovery: panoramica della soluzione

Poter disporre di una adeguata strategia di business continuity e di disaster recovery che consenta di mantenere in esecuzione le applicazioni e ripristinare le normali condizioni di lavoro quando si ha l’esigenza di effettuare attività manutentive pianificate oppure durante fermi non previsti è di fondamentale importanza.

Azure Site Recovery favorisce l’attuazione di queste strategie orchestrando le repliche delle macchine virtuali e dei server fisici presenti all’interno del proprio data center. Si ha la possibilità di replicare i server e le macchine virtuali che si trovano in un data center primario locale verso il cloud (Microsoft Azure) oppure verso un data center secondario.

Nel caso dovessero verificarsi interruzioni nel data center primario è possibile avviare un processo di failover per mantenere i carichi di lavoro accessibili e disponibili. Quando sarà possibile utilizzare nuovamente le risorse nel data center primario verrà gestito il processo di failback.

Possibili scenari di replica

In Azure Site Recovery sono contemplati i seguenti scenari di replica:

  • Replica di macchine virtuali Hyper-V

In questo scenario se le macchine virtuali Hyper-V vengono gestite da System Center Virtual Machine Manager (VMM) è possibile prevedere la replica sia verso un data center secondario sia verso Microsoft Azure. Nel caso invece le macchine virtuali non siano gestite tramite VMM la replica sarà possibile solo verso Microsoft Azure.

  • Replica di macchine virtuali VMware

Le macchine virtuali presenti su VMware possono essere replicate sia verso un data center secondario utilizzando un canale dati di InMage Scout sia verso Microsoft Azure.

  • Replica di server fisici Windows e Linux

I server fisici possono essere replicati sia verso un data center secondario (tramite canale dati di InMage Scout) che verso Microsoft Azure.

Figura 1 – Scenari di replica di ASR

Configurazione di Azure Site Recovery

Nella seguente tabella sono riportati i documenti con le specifiche da seguire per configurare Azure Site Recovery nei differenti scenari:

Tipologia dei sistemi da replicare Destinazione della replica
Macchine virtuali VMware Microsoft Azure

Data center Secondario

Macchine virtuali Hyper-V gestite in cloud VMM Microsoft Azure

Data center Secondario

Macchine virtuali Hyper-V gestite in cloud VMM, con archiviazione su SAN Data center Secondario
Macchine virtuali Hyper-V senza VMM Microsoft Azure
Server fisici Windows/Linux locali Microsoft Azure

Data center Secondario

 

Principali vantaggi nell’adozione di Azure Site Recovery

Dopo aver esaminato cosa è possibile fare con Azure Site Recovery e quali step seguire per implementare i piani di recovery riportiamo quelli che sono alcuni dei principali vantaggi che si possono avere con l’adozione di questa soluzione:

  • Utilizzando gli strumenti di Azure Site Recovery si semplifica il processo di creazione di piani di business continuity e di disaster recovery. Nei piani di ripristino è infatti possibile includere script e runbook presenti in Azure Automation in modo da poter modellare e personalizzare le procedure di DR anche per applicativi con architetture complesse.
  • Si può avere una elevata flessibilità grazie alle potenzialità della soluzione che consente di orchestrare repliche di server fisici e di macchine virtuali in esecuzione sia su Hyper-V che su VMware.
  • Grazie alla possibilità di replicare i carichi di lavoro direttamente su Azure in alcuni casi si può valutare di eliminare completamente un data center secondario realizzato solo a fini di business continuity e di disaster recovery.
  • Si ha la possibilità di eseguire periodicamente test di failover per validare l’efficacia dei piani di recovery realizzati, senza dare nessun impatto all’ambiente applicativo di produzione.
  • Risulta possibile integrare ASR con altre tecnologie BCDR già esistenti in azienda (come ad esempio SQL Server AlwaysOn oppure SAN replication).

 

Tipologie di Failover in Azure Site Recovery

Dopo aver completato la creazione di un piano di recovery è possibile eseguire differenti tipologie di failover. Nella tabella seguente sono elencate le varie tipologie di failover e per ognuna di essa è specificato il relativo scopo e quali azioni comporta il processo di esecuzione.

Conclusioni

Azure Site Recovery è una soluzione potente e flessibile per la creazione di strategie di business continuity e di disaster recovery per il proprio data center, in grado di orchestrare e gestire anche infrastrutture eterogenee e complesse. Tutto ciò rende ASR uno strumento adeguato per la maggior parte degli ambienti. Per chi volesse esplorare direttamente sul campo le funzionalità di Azure Site Recovery può attivare un ambiente di trial di Operations Management Suite oppure di Microsoft Azure.

OMS Log Analytics: Raccogliere i Log Custom

In alcuni scenari può sorgere l’esigenza di collezionare log provenienti da applicazioni che non utilizzano i tradizionali metodi come l’Event Log in ambiente Windows oppure Syslog per i sistemi Linux per scrivere le informazioni ed eventuali errori. Log Analytics ci consente di collezionare anche gli eventi presenti in file di testo sia su sistemi Windows che sulle diverse distribuzione Linux supportate.

2016_11_09_loganalytics-01

Figura 1 – Il processo di raccolta dei log custom

Le nuove entry scritte nel custom log vengono collezionate da Log Analytics ogni 5 minuti. L’agente è inoltre in grado di memorizzare qual è l’ultima entry collezionata in modo tale che anche se l’agente dovesse fermarsi per un certo periodo di tempo nessun dato viene perso, ma quando torna in esecuzione riprende l’elaborazione dal punto dove si era fermato.

Per poter collezionare i file di log utilizzando Log Analytics devono essere rispettati i seguenti requisiti:

  • Il log deve avere una singola entry per ogni riga del file oppure ogni entry deve iniziare con un timestamp che rispetti uno dei seguenti formati:
  • YYYY-MM-DD HH:MM:SS
  • M/D/YYYY HH:MM:SS AM/PM
  • Mon DD,YYYY HH:MM:SS
  • yyMMdd HH:mm:ss
  • ddMMyy HH:mm:ss
  • MMM d hh:mm:ss
  • Dd/MMM/yyyy:HH:mm:ss zzz
  • Il file di log non deve essere configurato per essere sovrascritto con circular updates.

Definizione di un custom log

Per poter collezionare le informazioni dei custom log è necessario seguire questa semplice procedura.

  1. Aprire il wizard dei custom Log:
    1. Accedere al portale OMS
    2. Settings – Data
    3. Custom Logs
    4. Add+
2016_11_09_loganalytics-02

Figura 2 – Custom Log Wizard

Di default tutti i cambiamenti apportati nella sezione Custom Logs vengono inviati in automatico a tutti gli agenti OMS. Per gli agenti Linux viene inviato un file di configurazione al data collector Fluentd. Se si vuole modificare manualmente questo file sugli agenti Linux è necessario rimuovere il flag “Apply below configuration to my Linux machines”.

  1. Effettuare l’upload e il parsing di un log di esempio:
2016_11_09_loganalytics-03

Figura 3 – Upload di un file di log di esempio

Selezionare il metodo che deve essere utilizzato per delimitare ogni record del file. Di defalut viene proposto di delimitare il file in base alle righe. Questo metodo può essere utilizzato quando il file di log contiene una singola entry per ogni riga del file. In alternativa è possibile selezionare il Timestamp per delimitare ogni record del file di log se inizia con un timestamp in un un formato supportato. Se viene utilizzato il Timestamp per delimitare i vari record la proprietà “TimeGenerated” di ogni record memorizzato in OMS verrà popolata con la data e l’ora specificata nel file di log. Se invece viene utilizzato il metodo alternativo (New Line) la proprietà “TimeGenerated” è valorizzata con la data e l’ora di raccolta del valore da parte di Log Analytics.

2016_11_09_loganalytics-04

Figura 4 – Parsing del log con metodo New Line

2016_11_09_loganalytics-04-bis

Figura 4bis – Parsing del log con metodo Timestamp

  1. Aggiungere i path dei log da collezionare:
    1. Selezionare Windows oppure Linux per specificare il formato del path opportuno
    2. Specificare il path e aggiungerlo con il pulsante +
    3. Ripetere il processo per ogni path da aggiungere
2016_11_09_loganalytics-05

Figura 5 – Percorsi da dove collezionare i log

Quando si inserisce un path è possibile specificare anche un valore contente un wildcard nel nome, utile per supportare applicazioni che creano nuovi file di log ogni giorno oppure al raggiungimento di una determinata dimensione.

  1. Assegnare un nome e una descrizione al log configurato.
2016_11_09_loganalytics-06

Figura 6 – Nome e descrizione del custom log

Il suffisso _CL viene aggiunto di default.

  1. Validare la configurazione effettuata.

Quando Log Analytics inizia a collezionare i custom log (può essere necessario attendere fino a 1 ora dal momento dell’attivazione per visualizzare i primi dati) è possibile consultarli dal portale OMS accedendo a Log Search. Come Type è necessario specificare il nome assegnato al custom Log (esempio Type=nginx_error_CL).

2016_11_09_loganalytics-07

Figura 7 – Ricerca dei log

Dopo avere configurato la raccolta dei custom log (ogni entry viene salvata come RawData) è possibile effettuare il parsing di ogni record presente all’interno del log in singoli campi utilizzando la funzionalità di Custom Fields presente in Log Analytics. Questo ci consente di analizzarli e di fare ricerche in modo più efficace.

Conclusioni

Ancora una volta Log Analytics si dimostra una soluzione potente e flessibile che ci consente di collezionare dati direttamente da log custom, sia per sistemi Windows che per macchine Linux, il tutto seguendo dei semplici e intuitivi passaggi guidati. Per chi vuole approfondire questa e altre funzionalità di OMS vi ricordo che è possibile provare la soluzione OMS gratuitamente.