Estendere Microsoft OMS con Linux

Introduzione

Microsoft Operations Management Suite (OMS) è un insieme di prodotti cloud borne che aspira a fornire una completa soluzione per il modern management delle operations di un sistema ICT ibrido: monitor, security, patching, automazione, protezione del dato e disaster recovery sono solo alcuni degli ambiti coperti. In questo articolo ci concentreremo sulle capacità della piattaforma di log ingestion and analysis di OMS: Log Analytics. Log analytics è una piattaforma completamente cloud based per la memorizzazione e l’analisi di “machine data”, più dati vengono consolidati maggiore è il valore che la piattaforma può fornire.

Microsoft fornisce connettori e agenti per diverse piattaforme e applicativi (Windows, Linux, Azure, MySQL, Office 365, AWS, VMWare, …), ma è evidente che non potrà mai coprire tutte le differenti possibili fonti dati presenti nel moderno ed eterogeneo mondo ICT.

Ovviamente Log Analytics ha diverse modalità per consentire l’ingestion dei dati, tra cui anche un servizio REST accessibile via https. Per quanto possa sembrare strano però il miglior modo per estendere Log Analytics è tramite l’agente su piattaforma Linux.

Come inviare data a Log Analytics

Esistono diversi modi per inviare custom data a Log Analytics, dove per custom si intende tutto ciò che la piattaforma e Microsoft non forniscono già nativamente:

  • Tramite l’agente Windows
  • Tramite l’agente Linux
  • Tramite la OMS HTTP API

L’agente Windows può di fatto estendere le capacità di Log Analytics con informazioni custom, solo se contemporaneamente connesso a un Management Group System Center Operations Manager (SCOM) e tramite lo sviluppo di un Management Pack che, per chi ci si è cimentato, non è certamente questione rapida.

L’agente Linux permette di effettuare ingestion di qualsiasi dato anche con formato nativo alla piattaforma scrivendo codice Ruby. L’agente fornisce già i meccanismi di buffering, queuing e retrying necessari alla comunicazione.

L’interfaccia REST permette di effettuare upload di qualsiasi payload rappresentabile in formato json, ma non permette di fare upload di dati nativi alla piattaforma. È evidente che la gestione del buffering e del queuing delle informazioni, fondamentale per la comunicazione con un sistema cloud based, deve essere realizzata dal nostro codice. È possibile usare qualsiasi linguaggio di programmazione su qualsiasi piattaforma fin tanto che è in grado di gestire una POST http.

La presenza dei meccanismi per una comunicazione affidabile e la possibilità di inviare dati in formato nativo sono elementi decisivi nella scelta della piattaforma per estendere Log Analytics. È opportuno aggiungere che sui dati nativi OMS mette a disposizione un meccanismo di ingestion più rapido e delle perspective (viste personalizzate) che altrimenti è impossibile sfruttare con i dati custom. In particolare la possibilità di inviare dati di performance in formato nativo consente la visualizzazione in near-realtime delle performance.

OMS-1.png

Agente OMS per Linux

L’agente OMS di Linux è un progetto opensource su github basato su FluentD  (v0.12.24). L’agente sfrutta il framework FluentD ed aggiunge i propri plugin.

L’agente porta con se altri payload che vengono utilizzati dai plugin e per la configurazione dell’agente stesso con le impostazioni inserite nel workspace OMS:

  • OMI è un porting dello standard CIM/WBEM su Linux ed è utilizzato per la configurazione dell’agente e per la collezione di dati di performance
  • SCX è un provider open source per OMI utilizzato originariamente da System Center Operations Manager e utilizzato per aggiungere dati a quelli che OMI può collezionare dal sistema. SCX originariamente presente su Codeplex è oggi stato spostato su github.

Non è quindi una sorpresa se l’agente OMS ha un’architettura FluentD standard con input plugins per collezionare dati, filtri per il post processing e una serie di output plugin per inviare dati a OMS che si preoccupano della resilienza della comunicazione e dell’autenticazione

oms-2.png

Semplificando è possibile riassumere un flusso FluentD come segue

oms-3.png

Estendere l’agente Linux

Estendere OMS è dunque questione di implementare l’agente Linux con un appropriato input plugin e se necessario con un filter plugin, gli output plugin da utilizzare sono quelli già forniti dalla piattaforma.

Dal momento che FluentD è un framework molto utilizzato nel mondo OpenSource, prima di scrivere i propri plugin, è possibile verificare se ne esistono di disponibili nella community.

A titolo di esempio analizziamo come integrare OMS con lo status di un server NGinx. Per fare questo è necessario attivare la pagina di nginx status e aggiungere un location directive alla sezione server{}:

sudo nano /etc/nginx/sites-enabled/default

...
location /nginx_status {
stub_status on;
access_log off;
}
...

oms-4.png

Per maggiori informazioni su come installare Nginx su Ubuntu si veda (in lingua inglese):

Una volta che il server Nginx è configurato con la pagina di stato, occorre aggiungere al sistema i plugin FluentD necessari:

  • in_nginx plugin che legge e fa parsing della pagina di stato
  • filter_record_modifier plugin. Questo sarà utilizzato per modificare il record in un formato meglio consumabile da OMS senza dover scrivere codice

**Attenzione** contrariamente ad una installazione standard di FluentD non è possibile installare I plugin come FluentD gem, devono invece essere copiati manualmente nella corretta directory.

sudo wget -O /opt/microsoft/omsagent/plugin/in_nginx.rb https://raw.githubusercontent.com/robertpitt/fluent-plugin-nginx-status/master/lib/fluent/plugin/in_nginx.rb

sudo wget -O /opt/microsoft/omsagent/plugin/filter_record_modifier.rb https://raw.githubusercontent.com/repeatedly/fluent-plugin-record-modifier/master/lib/fluent/plugin/filter_record_modifier.rb

Una volta installati i plugin occorre configurare l’agente perché li utilizzi, si tratta di preparare un conf file per FluentD con le opportune direttive e copiarlo in /etc/opt/microsoft/omsagent/conf/omsagent.d.

In questo esempio useremo un custom dataset e faremo ingestion tramite OMS HTTP API, sicuramente il modo più semplice per inviare dati, infatti basta aggiungere un match al tag del dato in input (oms.qnd.NginxStatus) con il plugin out_oms_api.


 <source>
 @type nginx_status
 tag oms.qnd.NginxStatus
 host localhost
 port 80
 path /nginx_status
 interval 10
 <source>
 <match oms.qnd.NginxStatus.**>
 @type out_oms_api
 log_level info
 num_threads 1
 buffer_chunk_limit 1m
 buffer_type file
 buffer_path /var/opt/microsoft/omsagent/state/out_oms_nginx*.buffer
 buffer_queue_limit 10
 buffer_queue_full_action drop_oldest_chunk
 flush_interval 10s
 retry_limit 10
 retry_wait 30s
 max_retry_wait 10m
 </match>
 

Riavviando il Servizio omsagent la configurazione diventa attiva e i dati vengono collezionati in OMS. Per consultarli sarà sufficiente la seguente interrogazione: Type:NginxStatus_CL. Si scoprirà così come alcune proprietà sono inviate in formato testo mentre sarebbe più opportuno trasformarle in numerici in modo da poter utilizzare le funzioni statistiche messe a disposizione da OMS durante le interrogazioni. Occorre dunque modificare il record letto dallo stato di NGInx e trasformarne alcune proprietà. Ancora una volta è possibile farlo senza scrivere codice utilizzando un altro plugin standard “record_modifier”. Nella configurazione seguente le proprietà: active, reading, writing e waiting, sono trasformate da testo a numerico, viene aggiunta qualche informazione aggiuntiva (esempio Computer) e il tutto viene spedito a OMS.


 <source>
 @type nginx_status
 tag oms.qnd.NginxStatus
 host localhost
 port 80
 path /nginx_status
 interval 10
 <source>

<filter oms.qnd.NginxStatus.**>
 @type record_modifier
 remove_keys accepted,handled,total
 <record>
 Computer "#{Socket.gethostname}"
 Provider QND
 active ${record['active'].to_f}
 reading ${record['reading'].to_f}
 writing ${record['writing'].to_f}
 waiting ${record['waiting'].to_f}
 </record>
</filter>

<match oms.qnd.NginxStatus.**>
 @type out_oms_api
 log_level info
 num_threads 1
 buffer_chunk_limit 1m
 buffer_type file
 buffer_path /var/opt/microsoft/omsagent/state/out_oms_nginx*.buffer
 buffer_queue_limit 10
 buffer_queue_full_action drop_oldest_chunk
 flush_interval 10s
 retry_limit 10
 retry_wait 30s
 max_retry_wait 10m
 </match>

Conclusioni

L’agente Linux per OMS è il canale più completo per estendere i dati raccolti dalla soluzione, è possibile sfruttare l’ampia base di plugin forniti dalla community o sviluppare i propri. Questo primo articolo ha lo scopo di fornirvi un’idea generale su  come sia possibile integrare virtualmente qualsiasi fonte dati in OMS, successivi approfondimenti potranno mostrare come scrivere propri plugin e progettare una completa solution su OMS.

A proposito di Daniele Grandini

Daniele, Microsoft MVP su System Center dal 2009 è il fondatore della community alla quale porta il contributo di più di 15 anni di esperienza in sistemi di monitor e gestione. Attualmente Daniele è Microsoft MVP System Center Cloud and Datacenter Management. Twitter:@DanieleGrandini

Lascia un commento