Quando un'applicazione viene riscritta per utilizzare i microservizi, aumenta il numero di componenti e endpoint coinvolti in una singola transazione utente. Pertanto, l'osservabilità è fondamentale per gestire in modo affidabile i servizi per gli utenti. Questa architettura di riferimento mostra come acquisire le informazioni sulle tracce delle applicazioni di microservizi utilizzando OpenTelemetry e Cloud Trace.
Questo documento è rivolto a sviluppatori, SRE e ingegneri DevOps che vogliono comprendere i fondamenti del monitoraggio distribuito e applicare questi principi ai propri servizi per migliorarne l'osservabilità.
Architettura
Il seguente diagramma mostra l'architettura di un'applicazione che implementa questa architettura.
Come illustrato nel diagramma precedente, questa architettura include due cluster GKE. Esegui il deployment di un'applicazione in ciascuno dei cluster. Il traffico utente viene inviato all'applicazione frontend nel cluster frontend. Il pod frontend sul cluster frontend comunica con il pod backend sul cluster backend. Il pod di backend chiama un endpoint API esterno.
I dati di osservabilità vengono esportati in Cloud Trace, che monitora il modo in cui le richieste si propagano nelle applicazioni.
Note sul layout
Per i servizi in esecuzione su Kubernetes, puoi utilizzare un mesh di servizi come Istio per abilitare il monitoraggio distribuito del traffico tra servizi senza bisogno di instrumentation dedicata. Tuttavia, potresti avere uno dei seguenti requisiti:
- Vuoi avere un maggiore controllo sulle tracce rispetto a quello fornito da Istio.
- Potresti dover acquisire le informazioni interne dell'applicazione nelle informazioni sulla traccia.
- Potresti dover tracciare il codice che non è in esecuzione su Kubernetes.
Per questi casi d'uso, puoi utilizzare OpenTelemetry, una libreria open source che può aggiungere strumenti alle applicazioni di microservice distribuite per raccogliere tracce, metriche e log in un'ampia varietà di linguaggi, piattaforme ed ambienti.
Informazioni su tracce, intervalli e contesto
Il concetto di monitoraggio distribuito è descritto nel documento di ricerca Dapper pubblicato da Google. Come descritto nel documento, il seguente diagramma mostra cinque tratti in una traccia.
Un trattino è il totale delle informazioni che descrivono in che modo un sistema distribuito risponde a una richiesta dell'utente. Le tracce sono composte da span, dove ogni span rappresenta una coppia specifica di richiesta e risposta coinvolta nell'elaborazione della richiesta dell'utente. Lo span principale descrive la latenza osservata dall'utente finale. Ognuno degli elementi figlio descrive in che modo è stato chiamato e a cui è stata data risposta a un determinato servizio nel sistema distribuito, con le informazioni sulla latenza acquisite per ciascuno.
Il diagramma mostra una singola richiesta frontend che effettua due richieste di backend. La seconda chiamata di backend richiede due chiamate di supporto per essere completata. Ogni chiamata è etichettata con il proprio ID span e l'ID dello span principale.
Un problema con il monitoraggio nei sistemi distribuiti è che le informazioni sulla richiesta frontend originale non vengono trasferite automaticamente o intrinsecamente quando vengono effettuate richieste successive a vari servizi di backend.
Con alcuni strumenti (ad esempio nel linguaggio Go), puoi effettuare richieste con il contesto: l'indirizzo IP e le credenziali del cluster. OpenTelemetry estende il concetto di contesto per includere il contesto dell'ambito, il che significa che vengono caricate informazioni aggiuntive nell'intestazione HTTP. Le informazioni sull'elemento span principale possono essere incluse in ogni richiesta successiva. Puoi aggiungere span secondari per comporre la traccia complessiva, in modo da vedere in che modo la richiesta dell'utente ha attraversato il sistema ed è stata infine restituita all'utente.
Deployment
Per eseguire il deployment di questa architettura, consulta Eseguire il deployment del monitoraggio distribuito per osservare la latenza dei microservizi.
Passaggi successivi
- Scopri di più su OpenTelemetry.
- Scopri di più sulle funzionalità DevOps correlate a questa architettura:
- Esegui il controllo rapido DevOps per capire dove ti trovi rispetto al resto del settore.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Cloud Architecture Center.