Troubleshooting nei microservizi: velocizzare la caccia all’errore con Elastic Stack

11 Nov 2020 - - by Tommaso Moroni

Troubleshooting nei microservizi: velocizzare la caccia all’errore con Elastic Stack

11 Nov 2020 - - by Tommaso Moroni
ISCRIVITI ALLA NEWSLETTER

La necessità di rispondere all’evoluzione veloce del mercato e di rimanere competitivi può generare diverse complessità interne ad un’organizzazione, soprattutto quando si tratta di realtà in cui ci sono più fornitori da gestire e integrare o quando occorre sviluppare un’Architettura IT decomposta in tanti microservizi. In questi scenari così articolati l’azione di troubleshooting, ossia il processo di ricerca sistematica delle cause di un problema, può diventare molto dispendiosa per l’azienda: scopriamo come velocizzare e rendere più efficace il processo per gli sviluppatori avvalendosi di uno strumento come Elastic Stack.

Le sfide di un’architettura IT a microservizi

Partiamo dal ruolo che stanno assumendo i microservizi all’interno di un’Architettura IT: le applicazioni vengono organizzate nelle loro funzioni di base come un insieme di piccoli componenti (servizi) che funzionano indipendentemente l’uno dall’altro. I microservizi rappresentano uno dei maggiori trend IT del momento, ma bisogna tenere conto che al contempo aumentano l’articolazione della struttura IT: quello che prima veniva fatto da un solo sistema, con la proliferazione dei microservizi viene infatti gestito da n sistemi, e nel momento in cui si verifica un errore diventa problematico scovare da dove proviene tra i diversi “frammenti” dell’architettura. È il caso ad esempio di un’Architettura IT che espone delle API, dalle quali ritornano dei dati recuperati da n sistemi diversi.

Tra le principali sfide che possono emergere in questo scenario, riconosciamo le seguenti:

  1. Evitare processi di troubleshooting poco efficienti
    Come già accennato prima, cercare un errore all’interno di un sistema frammentato è una bella sfida: se ad esempio un’API non funziona, dove sarà il problema tra gli n sistemi coinvolti? Se c’è un rallentamento, da quale macchina sarà provocato?
    Lo sviluppatore dovrebbe andare su una macchina, collegarsi, controllare i log ed esaminare tutte le macchine fino a trovare la fonte del problema: una serie di operazioni manuali lunghe, impegnative e soprattutto dispendiose.
  2. Possibilità di controllo su macchine in gestione a terzi
    In un Sistema Informativo aziendale capita spesso che i software, gli applicativi gestionali, i sistemi legacy o componenti fatti da altri fornitori siano in gestione a terze parti: questo significa che per lo sviluppatore non è possibile andare fisicamente sulla macchina a controllare i log. Prendiamo il caso di molti istituti bancari, in cui le API devono correlare le informazioni di anagrafica dell’utente presenti in un sistema documentale terzo con il sistema interno AS/400. Se si presenta un problema, l’IT della banca non potrebbe autonomia di controllo sul sistema del gestore documentale del fornitore terzo, limitando la sfera d’azione di troubleshooting ai soli sistemi interni.
  3. Risolvere i problemi in tempi ridotti per evitare disservizi
    Cercare il problema è molto oneroso in termini di tempo impiegato dalle risorse umane, con evidenti ripercussioni sui costi per la risoluzione del problema e sul disservizio che incide fortemente anche sull’esperienza utente.

Coniugare log management e monitoring con Elastic Stack

In simili condizioni, il lavoro dello sviluppatore può essere notevolmente facilitato centralizzando le informazioni provenienti dai sistemi coinvolti grazie a uno strumento come Elastic Stack.

Elastic Stack funge da punto centralizzato di passaggio delle informazioni di un’architettura, dando in un’unica soluzione le funzioni di:

  • Log management per la centralizzazione dei log;
  • Monitoring delle metriche degli applicativi per centralizzare le metriche di performance di servizio.

Da una parte abbiamo quindi il monitoring delle performance del sistema, dall’altro la centralizzazione dei log: questo significa che l’operatore non deve più andare a cercare un errore manualmente su tutte le macchine coinvolte, bensì potrà fare un controllo sistematico da un unico punto in grado di integrare praticamente qualsiasi sistema esistente.

I vantaggi di Elastic Stack e di un approccio proattivo di troubleshooting

  • Fare ricerche su entrambe le tipologie di informazioni, correlando gli errori del log con le variazioni delle metriche di performance;
  • Impostare degli allarmi per prevenire i problemi in punti in cui lo sviluppatore individua una correlazione tra log e variazione di metrica, velocizzando i tempi di intervento e passando quindi a un approccio proattivo alla risoluzione dei problemi di sistema;
  • Avere un’azione proattiva sui sistemi anche per migliorare l’esperienza dell’utente, che non viene a contatto con i problemi o al massimo percepisce un rallentamento momentaneo dei processi;
  • Integrare tutti i sistemi tramite plugin, collegando in un unico sistema fornitori e macchine diverse: accedere alle macchine di parti terze non è quindi più un problema, basta che il fornitore dia in modalità push le informazioni della macchina;
  • Sfruttare la funzione di ricerca full text sui log, che permette di effettuare ricerche veloci degli errori di sistema nel motore di ricerca di Elastic Stack e individuare velocemente la fonte dell’errore.

Cloud o non cloud? Le opzioni di installazione di Elastic Stack

Le grandi potenzialità di Elastic Stack lo rendono uno strumento potente per attuare un processo di trasformazione digitale fluido ed efficace nella propria organizzazione, sfruttando al meglio la flessibilità delle Architetture IT a microservizi.

Nell’adozione di una soluzione di questo tipo bisogna tenere in considerazione le caratteristiche e le esigenze specifiche dell’azienda, e il supporto di un consulente specializzato può essere una scelta molto conveniente per individuare la modalità di installazione più idonea:

  • On premise – i dati rimangono sotto il completo controllo dell’azienda, evitando potenziali complessità a livello legale;
  • In cloud – vengono eliminati problemi di backup, manutenzione macchine e trasparenza del sistema.

Fare queste considerazioni con accortezza vi permetterà di adottare una soluzione realmente adatta alle vostre necessità, con la possibilità di avere assistenza nell’installazione, nella scrittura dei log e nella trasformazione dei log utilizzabili per renderli più facilmente assimilabili dal sistema.

Vuoi sapere di più su questo tema? Partecipa il 26 novembre all’evento online:

“Headless & API date 2020: attuare e governare la trasformazione digitale con le architetture IT”

Iscriviti a Headless & API date 2020

iscriviti-alla-newsletter

Condividi su:

Tommaso Moroni

  • Come l’Open Banking cambia la User Experience

  • Kubernetes: cos’è e come usarlo per orchestrare i microservizi aziendali

  • IT governance delle API: come gestire le complessità evolutive con l’API Management

  • Architetture Evolutive, la soluzione IT a prova di futuro

  • Trasformazione digitale nel settore assicurativo: sfide competitive e nuove tecnologie abilitanti

Iscriviti alla Newsletter

Inserisci i tuoi dati e ti iscriveremo alla nostra Newsletter. Riceverai una mail ogni volta che uscirà un nostro nuovo articolo. Non ti preoccupare, non ti intaseremo la casella di posta e - se cambierai idea - potrai cancellarti in qualsiasi momento.
* campi richiesti
Interessi
Privacy *