Skip to main content

Grazie alle tecnologie cloud-native e alle più versatili architetture a microservizi, le aziende riescono a innovare in modo rapido ed efficiente. Ma per mantenere il livello richiesto dal mercato ed evitare disservizi, ottenere la cosiddetta observability dei moderni ambienti IT diventa una sfida importante per molte aziende. La complessità, infatti, non è mai stata così elevata: il volume e la velocità dei dati e la rapida ascesa di piattaforme applicative come Kubernetes rendono difficile garantire l’osservabilità senza i giusti processi e le opportune tecnologie. Per questo, secondo CITE Research, l’81% dei CIO prevede di aumentare il proprio budget per l’osservabilità nel 2022, mentre il 20% prevede un aumento significativo.

Le sfide nel sistema di monitoraggio di applicazioni complesse

La natura disaccoppiata dei moderni sistemi di progettazione degli applicativi genera modelli IT scalabili e resilienti; tuttavia, intensifica anche il livello di complessità, riducendo la capacità di monitorare lo stato dell’infrastruttura e delle applicazioni, nonché di identificare e risolvere i problemi che inevitabilmente si presenteranno.

Contrariamente all’approccio monolitico, uno stile architetturale a microservizi si basa sulla decomposizione di un applicativo in più componenti indipendenti. I log applicativi, che tipicamente venivano generati e depositati in un unico punto nel monolite, con i microservizi vengono invece sparsi su più macchine e container, amplificando i punti in cui andrebbe ricercato un eventuale errore e rendendo più difficile la correlazione degli eventi a causa della distribuzione delle chiamate su tutti i sistemi.

O ancora, ipotizziamo il caso di un disservizio in un’architettura API-based che, prevedendo l’aggregazione di dati da molteplici sistemi back-end, rende difficile l’azione di troubleshooting applicativo a causa delle molteplici macchine da controllare, spesso difficilmente accessibili perché gestite da terze parti.

Si pensi, ad esempio, a un sistema per la firma di contratti di finanziamento di una banca che deve interagire con:

  • Il sistema legacy AS/400 per recuperare i dati dei firmatari;
  • Il sistema documentale per scaricare i documenti da far firmare;
  • Il sistema di archiviazione sostitutiva per caricare i documenti firmati.

Se i tre sistemi sono gestiti da fornitori terzi, la rilevazione di un eventuale errore su un endpoint esposto in un’API diventa un’operazione molto complicata.

SCARICA IL CASO DI UN GRUPPO BANCARIO

Le complessità nel processo di troubleshooting applicativo

Ipotizziamo il caso di un operatore che per comprendere la causa di un problema su un’architettura complessa dovrà:

1

Collegarsi su una macchina/container;

2

Cercare informazioni utili nei log applicativi;

3

Guardare il carico della macchina/container (memoria, CPU, etc.);

4

Ripetere quanto sopra per ogni macchina coinvolta nell’architettura;

5

Mettere a fattor comune quanto trovato e correlare le relative informazioni.

Ognuno di questi punti può potenzialmente portare a delle complicazioni nel processo di troubleshooting, per esempio, a causa di operazioni manuali intrinsecamente lente o perché l’operatore non conosce quali macchine sono coinvolte o non è autonomo al loro accesso perché in gestione a fornitori terzi.

Anche il recupero delle informazioni utili nei log applicativi può rappresentare una sfida: ogni applicazione può scrivere log in qualunque punto del file system e l’operatore dovrebbe cercare fisicamente questi log. Inoltre, una volta individuati i log, la ricerca di informazioni utili è complicata dal fatto che i log possono essere scritti in modo diverso, con un formato che quasi sempre non viene normalizzato.

Infine, anche recuperare i dati del carico di una macchina potrebbe non essere per niente semplice: oltre all’indisponibilità dei dati storici per capire l’accaduto durante il verificarsi del problema, servono anche strumenti diversi a seconda del contesto; per esempio, su Windows ci sono dei tool specifici rispetto a un sistema di container.

Ottenere l’osservabilità necessaria per il monitoraggio degli applicativi

 

L’observability è la capacità di un’architettura software di rendersi monitorabile e controllata sotto tutti i punti di vista.

L’osservabilità di un ambiente IT non è qualcosa che si può semplicemente comprare per farlo funzionare, ma è un attributo del sistema che si deve costruire al pari dell’usabilità, dell’affidabilità e della stabilità.

Un sistema si definisce altamente osservabile quando il suo stato può essere facilmente determinato e l’individuazione di criticità può essere facilmente circoscritta, un fattore che sta diventando sempre più strategico con l’aumentare dell’adozione di moderne architetture software da parte delle aziende.

Per affrontare questa complessità, è necessario semplificare i processi di monitoraggio tramite opportuni strumenti che consentono di ottenere informazioni significative sulle prestazioni del sistema, nonché identificare facilmente gli errori, ottimizzando tempi e costi di gestione degli applicativi e garantendo il livello di servizio agli utenti.

Logo Intesys bianco
IL CASO DOLOMITI SUPERSKI

Favorire il monitoraggio continuo
di un’app mobile

SCARICA IL CASO
3.7/5.0 Article rating
3 Reviews
Cosa ne pensi dell'articolo?
  1. Amazing
  2. Good
  3. Bad
  4. Meh
  5. Pff
Tommaso Moroni
Senior Software Developer

Appassionato di sviluppo software dal 2006, Tommaso, dopo Java EE e Liferay Portal Server, si è specializzato in Intesys sugli strumenti per la governance delle architetture IT, in particolare sul monitoring delle applicazioni.

NEWSLETTER