L'Elastic Agent rappresenta una soluzione fondamentale per il monitoraggio e la gestione centralizzata dei dati provenienti da diverse fonti all'interno di un'infrastruttura IT. Questa guida esplora l'implementazione di un Elastic Agent in modalità standalone, evidenziando i benefici e le caratteristiche del processo, nonché le differenze con l'uso del Fleet per una gestione centralizzata.

Quando si aggiunge un'integrazione a una policy esistente, diversi passaggi avvengono automaticamente dietro le quinte per garantire che i dati vengano acquisiti correttamente e gestiti in modo efficiente. In primo luogo, l'Elastic Agent comunica regolarmente con il Fleet Server, un po' come un satellite che si collega periodicamente alla sua stazione di terra. Questa interazione costante assicura che l'Elastic Agent sia sempre aggiornato rispetto a eventuali modifiche o modifiche della policy assegnata. Quando una policy viene modificata tramite l'aggiunta di una nuova integrazione, il Fleet Server acquisisce la nuova versione della policy e la distribuisce a tutti gli agenti connessi.

Questo approccio unificato riduce la complessità e migliora la performance complessiva della distribuzione Elastic Stack, consentendo una gestione semplificata dei dati e una maggiore sicurezza. Anche se questa guida si concentra principalmente sull'aggiunta di un'integrazione a una policy esistente, le funzionalità di gestione offerte dall'applicazione Fleet sono molto più ampie. Vi sono opzioni avanzate che non sono trattate qui, come la possibilità di aggiungere dei processori Elastic Agent per ridurre il numero di campi raccolti o per arricchire gli eventi con metadati aggiuntivi. Inoltre, è possibile utilizzare i tag per etichettare gli eventi durante l'indicizzazione in Elasticsearch, aggiungendo un ulteriore livello di personalizzazione e flessibilità a un'esperienza altrimenti semplificata.

Per chi desidera una maggiore personalizzazione e controllo, esiste anche la possibilità di configurare e gestire manualmente gli agenti tramite la modalità standalone. In questa modalità, l'utente non fa affidamento su Fleet per la gestione degli agenti, ma deve gestire manualmente gli aggiornamenti e le configurazioni. Questa modalità è ideale per utenti avanzati che necessitano di un controllo diretto su ciascun agente e su come i dati vengono gestiti. Tuttavia, va sottolineato che l'uso di Fleet-managed agents è generalmente consigliato, poiché la gestione manuale comporta un carico operativo maggiore.

Per procedere con la distribuzione di un Elastic Agent in modalità standalone, il primo passo è creare una policy per l'agente. Questo può essere fatto rapidamente utilizzando Kibana. Nella pagina di configurazione delle integrazioni, si può selezionare il server Apache come esempio di integrazione, per poi configurare la policy con un nome appropriato, come "standalone-policy". Una volta configurata la policy, il passo successivo consiste nell'associare l'Elastic Agent alla macchina host dove verrà eseguito.

Durante la configurazione dell'agente, l'utente avrà la possibilità di optare per la modalità standalone, il che significa che non ci sarà una registrazione centrale nell'applicazione Fleet. In questa modalità, il flusso dei dati verso Elasticsearch avviene direttamente, con l'agente che invia i dati senza dover fare affidamento su Fleet per la gestione centralizzata.

Una volta che l'agente è stato installato, è possibile monitorare i dati inviati tramite i dashboard di Kibana. Per esempio, in un ambiente Apache, si potrà visualizzare un dashboard che raccoglie informazioni sui log di accesso e di errore. Per confermare che l'Elastic Agent stia funzionando correttamente in modalità standalone, è sufficiente navigare all'interno della sezione delle policy di Fleet in Kibana, dove si noterà che la policy è utilizzata dall'agente standalone, ma non è associata a nessun altro agente.

La modalità standalone di Elastic Agent è particolarmente utile per scenari in cui l'utente desidera un controllo più diretto e dettagliato sull'agente, come in ambienti più piccoli o specializzati dove una gestione centralizzata può risultare superflua. Tuttavia, la modalità Fleet-managed offre numerosi vantaggi in termini di scalabilità e gestione semplificata in ambienti più complessi, dove è necessario un controllo centralizzato per garantire l'efficienza operativa e la coerenza tra i vari agenti distribuiti.

Va notato che, pur avendo l'opzione di generare la configurazione manualmente, utilizzare Kibana per configurare l'Elastic Agent in modalità standalone ha il vantaggio di configurare automaticamente anche gli asset di integrazione necessari, senza bisogno di installarli separatamente. Inoltre, questa modalità è pienamente supportata dall'operatore ECK (Elastic Cloud on Kubernetes), se si desidera distribuire gli agenti in un ambiente Kubernetes.

In sintesi, l'approccio a Elastic Agent, sia in modalità standalone che gestita tramite Fleet, dipende dalle specifiche necessità e complessità dell'ambiente in cui viene implementato. Se da un lato la modalità standalone offre un maggiore controllo e personalizzazione, dall'altro la modalità Fleet-managed semplifica notevolmente la gestione e l'aggiornamento degli agenti in scenari di grande scala. La scelta della modalità dipende dalle priorità di controllo, scalabilità e complessità operativa dell'utente finale.

Come impostare manualmente un flusso di dati in Elasticsearch

Impostare un flusso di dati in Elasticsearch è una delle operazioni fondamentali per la gestione efficiente dei dati temporali. Questo approccio è stato introdotto in Elasticsearch a partire dalla versione 7.9, per migliorare la gestione e ridurre i costi legati alla gestione dei dati. A partire dalla versione 8, l’architettura di Beats ha iniziato a supportare il salvataggio degli eventi direttamente nei flussi di dati anziché negli indici tradizionali. La configurazione di un flusso di dati manualmente offre una flessibilità significativa, soprattutto quando non si ha la possibilità di utilizzare Elastic Agent o Beats come shipper di dati.

Un flusso di dati consente di gestire in modo più efficiente i dati temporali, riducendo il sovraccarico dovuto alla gestione degli indici tradizionali. Mentre un indice è una raccolta statica di dati, un flusso di dati è dinamico e può evolversi nel tempo. A differenza di un indice, che ha una struttura rigida, i flussi di dati possono essere configurati per gestire i dati con un ciclo di vita ben definito, come il rollover automatico e l’eliminazione dei dati obsoleti. Un flusso di dati quindi offre un modo più scalabile e gestibile di lavorare con grandi volumi di dati temporali, riducendo la necessità di interventi manuali e migliorando le prestazioni complessive.

Immaginate di avere un dataset in tempo reale, come il traffico in una grande città, e di volerlo gestire in Elasticsearch. In questo caso, un flusso di dati permette di creare un’infrastruttura più robusta per monitorare e analizzare il traffico in tempo reale, applicando politiche di gestione dei dati come il rollover automatico quando un determinato shard raggiunge una certa dimensione, o l’eliminazione dei dati dopo un determinato periodo. Questo approccio risulta particolarmente utile quando si gestiscono grandi volumi di dati che si accumulano velocemente, come nel caso di dati di traffico, meteo, o altre fonti di dati temporali.

Per configurare manualmente un flusso di dati, è necessario seguire una serie di passaggi in Elasticsearch e Kibana. Innanzitutto, si deve creare una policy di gestione del ciclo di vita degli indici (Index Lifecycle Management, ILM). In questo esempio, creeremo una policy ILM per gestire i dati relativi al traffico della città di Rennes. La policy prevede che il rollover avvenga quando uno shard raggiunge i 50 GB e che i dati vengano eliminati dopo 30 giorni.

Dopo aver definito la policy ILM, si passa alla creazione di un template di indice. I template di indice in Elasticsearch definiscono la struttura dei dati che andranno a popolare l’indice. Per il traffico di Rennes, sarà necessario definire il mapping dei campi, come la data e ora del traffico, la posizione, lo stato del traffico e altri parametri specifici. Ogni campo avrà un tipo di dato associato, come "date", "keyword" o "geo_point", per permettere una corretta indicizzazione e ricerca.

Una volta creato il template di indice, si applica la policy ILM e si inizia a ingestire i dati. In questo caso, utilizziamo un dataset pubblico di traffico in tempo reale fornito dal sito europeo di dati pubblici. La procedura di ingestione avviene tramite uno script Python che invia i dati a Elasticsearch, dove vengono indicizzati nel flusso di dati appena creato. Kibana, che è lo strumento di visualizzazione e analisi di Elasticsearch, permette di verificare i dati ingested, visualizzandoli in tempo reale.

Una volta completata l’impostazione, i dati possono essere esplorati, analizzati e visualizzati attraverso le potenti capacità di Kibana. Ad esempio, è possibile creare dashboard che mostrano il traffico in tempo reale, analizzare i trend, fare previsioni e molto altro ancora. Il flusso di dati si adatta perfettamente a questo tipo di scenario, poiché gestisce in modo dinamico l’accumulo di nuovi dati e la loro rimozione quando non più rilevanti, senza sovraccaricare il sistema con dati obsoleti.

È fondamentale comprendere che il flusso di dati non è solo un miglioramento rispetto agli indici, ma una vera e propria evoluzione del modo in cui Elasticsearch gestisce i dati temporali. La gestione del ciclo di vita del dato tramite ILM, insieme al rollover automatico, rende possibile la gestione di dataset di grandi dimensioni senza compromettere le prestazioni del sistema.

Inoltre, va sottolineato che i flussi di dati sono pensati per applicazioni in tempo reale, come il monitoraggio di sistemi IoT, la raccolta di dati da sensori, la gestione di log in tempo reale, e naturalmente, la gestione di dati geospaziali come nel caso dei dati di traffico. L’automazione del ciclo di vita dei dati riduce i costi operativi e migliora l’efficienza, rendendo Elasticsearch un sistema ideale per l’elaborazione e l’analisi di grandi volumi di dati temporali.

Come configurare e abilitare la ricerca tra cluster in un contesto di osservabilità con Elastic Stack

Per iniziare, è necessario preparare l’ambiente creando una distribuzione nel Cloud di Elastic. A questo scopo, eseguiamo una serie di comandi Terraform nel terminale, che permetteranno di inizializzare il modulo Terraform, pianificare e applicare la configurazione desiderata per il deployment. Dopo aver completato questi passaggi, il sistema inizierà a creare la risorsa e, dopo un breve lasso di tempo, dovrebbe essere possibile visualizzare un messaggio che conferma la creazione della distribuzione.

Una volta completata la creazione del deployment, è possibile verificare lo stato della distribuzione nel pannello di controllo di Elastic Cloud all’indirizzo https://cloud.elastic.co. In questa fase, dovreste vedere entrambi i cluster operativi. Tuttavia, prima di stabilire una relazione di fiducia tra i due cluster, è necessario annotare l’ID dell’organizzazione del proprio account Elastic Cloud. Per farlo, cliccate sull'icona dell’utente nell’angolo in alto a destra e selezionate "Organization" dal menu a discesa. Qui troverete l'ID dell’organizzazione, che dovrete segnare per i passaggi successivi.

Il passo successivo consiste nell’instaurare una relazione di fiducia tra i due cluster. Tornate alla homepage della console di Elastic Cloud, cliccate sul deployment appena creato e navigate nella sezione "Security" nel menu laterale sinistro. Scorrete fino alla sezione "Remote Connections" e cliccate su "Add trusted environment". Successivamente, selezionate "Elastic Cloud" e procedete al passaggio successivo dove dovrete scegliere "Certificates". In questo modo, accedete al passaggio finale dove sarà necessario inserire l’ID dell’organizzazione annotato precedentemente.

Ora, scegliete "Specific deployments" e, se necessario, utilizzate la barra di ricerca per individuare il deployment principale. Selezionate il deployment desiderato e cliccate su "Create trust". Una volta completato, apparirà una pagina di conferma che indica che l’ambiente è ora considerato "trusted". Successivamente, nella sezione "Remote cluster parameters", cliccate su "Proxy address" per copiare l’indirizzo URL che dovrà essere utilizzato come parametro di connessione per il cluster principale.

Per configurare il cluster remoto, aprite Kibana dal cluster principale, andate su "Stack Management" > "Remote Clusters" e cliccate su "Add a remote cluster". Nella pagina di configurazione, assegnate un nome al cluster e inserite l’URL del proxy precedentemente copiato. Dopo aver cliccato su "Next", il sistema procederà con la configurazione. Una volta completato, potrete validare la connessione selezionando "Add remote cluster" e confermando la configurazione.

A questo punto, vedrete che il cluster remoto sarà elencato come "Connected" e potrete procedere con il passo successivo, che consiste nell’onboardare i dati di osservabilità nel cluster remoto. Selezioniamo quindi il contesto di monitoraggio dell’applicazione (APM) già configurato nel Capitolo 10, ma questa volta direzioniamo i dati di monitoraggio delle tracce applicative e del monitoraggio utente reale (RUM) al cluster remoto. Dopo aver completato il processo di onboarding, potrete accedere all’area di "Observability" nel cluster remoto e verificare che i dati siano stati raccolti correttamente.

Il passaggio successivo consiste nel configurare gli indici APM nel cluster principale per poter ispezionare simultaneamente le tracce dell’applicazione OpenTelemetry dal cluster principale e le tracce dell’applicazione Elastiflix dal cluster remoto. Per fare ciò, in Kibana, navigate su "Observability" > "APM" e cliccate su "Settings" nella barra del menu superiore. Selezionate la scheda "Indices" e inserite i valori desiderati, aggiungendo il prefisso del cluster remoto per ogni indice, come indicato nel documento di configurazione. È anche possibile utilizzare un carattere jolly (*) per includere tutti i deployment remoti fidati.

Una volta configurati correttamente gli indici, sarà possibile tornare a "Observability" > "APM" > "Services", dove potrete osservare, oltre ai servizi OpenTelemetry Demo, anche i servizi Elastiflix dal cluster remoto, come mostrato nella schermata. Ora che i servizi APM remoti sono correttamente configurati tramite CCS, è possibile interagire con essi come se fossero servizi locali. Ad esempio, è possibile creare lavori di rilevamento delle anomalie per le latenze dei servizi, selezionando "Anomaly detection" nel menu e creando un lavoro di rilevamento delle anomalie per i servizi associati all’ambiente di staging.

Questi passaggi descrivono come abilitare la ricerca tra cluster (CCS) all’interno di un contesto di osservabilità, permettendo di aggregare i dati da cluster differenti e migliorare l'analisi. Inoltre, questa configurazione aiuta nella gestione della multi-tenancy, consentendo di eseguire ricerche tra i dati di diversi tenant, mantenendo la privacy. CCS può rispondere anche a esigenze operative più ampie, come l'incremento dell’efficienza delle risorse e l’integrazione post-fusione di cluster senza necessità di riprogettare l’infrastruttura.

Endtext

Come l'intelligenza artificiale e l'apprendimento automatico stanno trasformando il settore finanziario attraverso l'inclusione e la sicurezza
Come Creare e Costruire Ricchezza: La Mentalità del Negoziante di Successo
Come rivitalizzare il Patto Sociale: Cittadinanza Inclusiva nell'Era della Politica Estrema