Osservabilità dei servizi per Kubernetes con abilitazione di Azure Arc

L'osservabilità è una caratteristica dell'applicazione che fa riferimento al grado di comprensione dello stato interno o dello stato di un sistema dagli output esterni. I sistemi informatici vengono misurati osservando tempo CPU, memoria, spazio su disco, latenza, errori e altre metriche. Più osservabile è un sistema, più facile è per noi capire cosa sta facendo guardandolo.

L'osservabilità di un sistema ha un effetto significativo sul costo operativo. I sistemi osservabili producono dati significativi e interattivi ai loro operatori, consentendo loro di ottenere risultati favorevoli e di avere meno tempi di inattività. Altre informazioni non si traducono necessariamente in un sistema più osservabile. In effetti, a volte la quantità di informazioni generate da un sistema può rendere più difficile identificare segnali di integrità preziosi dal rumore generato dall'applicazione.

L'osservabilità del servizio è importante perché consente di comprendere le prestazioni e i problemi nei sistemi distribuiti e cloud basati su architetture dinamiche.

L'implementazione di una soluzione per ottenere l'osservabilità dei servizi consente di:

• Assicurarsi che gli utenti finali possano usare l'applicazione e che vengano soddisfatte le aspettative aziendali.
• Comprendere un intero sistema e come funziona insieme usando un unico riquadro di vetro.
• Stabilire una linea di base per il sistema e comprendere in che modo le diverse circostanze influiscono sulle prestazioni del sistema.
• Generare elementi di azione da scenari e comportamenti imprevisti.

Kubernetes abilitato per Azure Arc offre due opzioni di estensione integrate che consentono di ottenere l'osservabilità dei servizi: Open Service Mesh e gateway Gestione API self-hosted. Queste opzioni sono descritte in dettaglio nelle sezioni seguenti relative alla considerazione sulla progettazione.

Architettura

Il diagramma seguente illustra i tre pilastri di Services Observability con impatto sul volume dei dati.

Il diagramma seguente illustra vari componenti open service mesh in esecuzione in un cluster Kubernetes abilitato per Arc. Mostra anche un'applicazione di esempio abilitata nella mesh del servizio, che viene configurata automaticamente con un contenitore envoy side-car.

Considerazioni relative alla progettazione

I tre pilastri dell'osservabilità sono metriche, log e tracce. Incorporarli nella strategia di osservabilità per rendere il sistema osservabile.

• Le metriche sono valori numerici che descrivono alcuni aspetti di un sistema in un determinato momento e vengono sempre raccolti a intervalli regolari.

Lo screenshot seguente mostra una visualizzazione di una metrica di richiesta HTTP di esempio per un servizio. La metrica in questo esempio viene visualizzata come frequenza delle richieste HTTP al minuto in un periodo di tempo specificato.

• I log possono archiviare vari tipi di dati con strutture personalizzate. Un log contiene informazioni dettagliate sulle transazioni che consentono di ottenere una storia più completa per un determinato evento. I log applicazioni in genere includono timestamp, livelli di log e tutte le informazioni necessarie per comprendere il contesto di un evento. I log vengono raccolti e spediti a un servizio di log per l'archiviazione e l'analisi.

• La traccia distribuita è una tecnica di diagnostica che consente agli utenti di localizzare gli errori e i problemi di prestazioni all'interno delle applicazioni, in particolare qualsiasi elemento distribuito tra più computer o processi. Questa tecnica tiene traccia delle richieste tramite un'applicazione, correlando il lavoro svolto da diversi componenti dell'applicazione e separandolo da altre operazioni che l'applicazione potrebbe eseguire per le richieste simultanee.

Lo screenshot seguente mostra una visualizzazione di una transazione end-to-end con Application Insights. Questo oggetto visivo consente di comprendere facilmente i tempi di risposta, i codici di risposta e le eccezioni che si verificano tra le richieste in una catena di transazioni.

I tre pilastri delle metriche, dei log e della traccia distribuita sono interconnessi. Le metriche vengono archiviate come valori numerici in un database time series. Sono anche molto più piccoli rispetto ai log, che semplificano la valutazione e l'utilità per gli avvisi quasi in tempo reale. I log acquisiscono e trasmettono molte più informazioni rispetto alle metriche, che le rendono utili per il debug più approfondito. Le tracce sono con ambito richiesta e sono utili per ottenere visibilità su una richiesta mentre attraversa vari componenti di un sistema distribuito.

La tabella seguente illustra l'impatto della raccolta per i tre pilastri.

Caratteristica raccolta	Metrica	Registri	Traccia distribuita
Account per ogni transazione	Sì	Sì	No (campionato)
Problemi di cardinalità immune alla cardinalità	No	Sì	Sì
Costi	Ridotto	Alto	Basso

Esistono diversi modi per ottenere l'osservabilità del servizio. È possibile usare una mesh di servizi per eseguire questa operazione a livello di piattaforma, in cui l'applicazione non è a conoscenza e non modificata. È anche possibile instrumentare un'applicazione con una libreria, che in genere viene eseguita usando uno strumento application Monitor prestazioni ing (APM) come Application Insights. I gateway API offrono osservabilità nel traffico nord-sud, ma manca l'osservabilità nel pod per la comunicazione tra pod e facilità di configurazione su larga scala.

Le sezioni seguenti illustrano come usare una mesh di servizi e il gateway API self-hosted disponibili per Azure Arc per ottenere l'osservabilità dei servizi.

Mesh di servizi

Una mesh di servizi offre funzionalità come la gestione del traffico, la resilienza, l'applicazione dei criteri, la sicurezza del trasporto, la sicurezza delle identità e l'osservabilità dei carichi di lavoro. L'applicazione è disaccoppiata da queste funzionalità operative; la mesh del servizio li sposta dal livello dell'applicazione e verso il basso nel livello dell'infrastruttura. Questa operazione viene eseguita tramite un proxy ad alte prestazioni che media tutto il traffico in ingresso e in uscita al servizio.

• Kubernetes abilitato per Azure Arc supporta Open Service Mesh (OSM), un progetto CLOUD Native Computing Foundation (CNF), distribuito come estensione. Open Service Mesh è una mesh di servizi nativa del cloud leggera ed estendibile che consente agli utenti di gestire, proteggere e ottenere funzionalità predefinite di osservabilità per ambienti di microservizi altamente dinamici.
• Altre mesh di servizi comuni che richiedono il supporto fornitore includono Istio, Consul Connessione e Linkerd.
• A seconda delle funzionalità usate durante l'implementazione di una mesh di servizi, è possibile che venga assegnata una responsabilità aggiuntiva agli operatori dell'applicazione per definire una configurazione per ogni servizio, ad esempio regole di accesso e servizi di onboarding. Inoltre, gli operatori cluster devono gestire e conoscere il controller mesh del servizio. A causa del modo in cui la mesh di servizi usa il modello side-car, i log di accesso dal piano di controllo della mesh di servizio e il sidecar sono necessari durante il debug di Egress e Ingress.

Osservabilità della mesh di servizi

L'osservabilità è una funzionalità importante tra le molte offerte dalle mesh di servizi. Scegliere una mesh di servizi che soddisfi i requisiti minimi di osservabilità in modo da ridurre la quantità di complessità e componenti che la mesh di servizi può avere e che deve essere configurata. Valutare le funzionalità comuni seguenti e i casi d'uso di osservabilità forniti dalle mesh di servizi:

• Generazione di metriche, inclusi i quattro segnali d'oro: latenza, traffico, errori e saturazione.
• Il metodo RED (rate-calls/sec, Errors, Duration-call latencies), che è un subset dei quattro segnali d'oro e viene usato per misurare i servizi. La mesh di servizi deve fornire un modo standardizzato per raccogliere metriche, tracce e così via RED.
• L'osservabilità aumenta, dall'aumento dell'ampiezza della copertura a tutti i servizi che fanno parte della mesh di servizi.
• Funzionalità che aumentano l'adozione dell'osservabilità instrumentando automaticamente tutti i servizi.
• Integrazione avanzata con i pilastri dell'osservabilità del servizio. La mesh di servizi deve essere in grado di raschiare le metriche e raccogliere i log che vengono visualizzati nella soluzione di monitoraggio. Assicurarsi che la raccolta di dati di telemetria della mesh di servizi supporti le esigenze aziendali e si integri bene con la soluzione di monitoraggio esistente.

Il diagramma seguente illustra un esempio della funzionalità proxy service mesh della raccolta e dell'inoltro dei dati.

Gateway self-hosted di Gestione API

Con l'integrazione tra Azure Gestione API e Azure Arc in Kubernetes, è possibile distribuire il componente gateway Gestione API come estensione nel cluster Kubernetes abilitato per Azure Arc. Ciò consente l'esecuzione di una versione in contenitori di Gestione API gateway nel cluster. Tutti i gateway self-hosted vengono gestiti dal servizio Gestione API con cui sono federati, offrendo visibilità e un'esperienza di gestione unificata in tutte le API interne ed esterne.

La configurazione del gateway self-hosted per accettare il traffico in ingresso da indirizzare ai servizi richiede la creazione di criteri. La gestione può diventare più complessa man mano che aumenta la scalabilità dei servizi.

Per altre informazioni, vedere panoramica del gateway self-hosted

Gestione API'osservabilità del gateway self-hosted

Il gateway self-hosted genera metriche, log stdout e log stderr. Le metriche generate possono essere configurate da un oggetto ConfigMap nel cluster. Per informazioni sul monitoraggio avanzato con Gestione API, vedere Monitoraggio avanzato.

L'osservabilità del gateway self-hosted tiene conto del traffico esterno (nord-sud) che entra nel cluster, ma non fornisce alcuna osservabilità per il traffico da pod a pod all'interno del cluster (est-ovest).

Metriche e log cloud: le metriche vengono generate in Monitoraggio di Azure per impostazione predefinita. Log Analytics consente di raccogliere e visualizzare i log dei contenitori di gateway self-hosted usando Monitoraggio di Azure per i contenitori. Per altre informazioni, vedere Configurare metriche e log locali per Azure Gestione API gateway self-hosted.

Metriche e log locali: le metriche e i log del gateway self-hosted possono essere integrati con gli strumenti di monitoraggio locale o generati da Config Map. Le metriche possono essere configurate per la pubblicazione nei server delle metriche. I log del gateway vengono generati per impostazione predefinita su stdout e stderr. Per altre informazioni, vedere Configurare metriche e log locali per Azure Gestione API gateway self-hosted.

Tabella di confronto delle tecnologie

La tabella seguente illustra le differenze tra le opzioni di implementazione per scegliere un metodo per ottenere l'osservabilità dei servizi.

Funzionalità	Mesh di servizi	APM (Application Performance Monitoring)	Self-hosted API Gateway
Traffico est-ovest supportato	Sì	Sì	No
Funzionalità delle metriche	Sì	Sì	Sì
Funzionalità di registrazione	Sì	Sì	Implementazione personalizzata
Funzionalità Tracce distribuite	Sì	Sì	Sì
Livello di implementazione	Rete	Applicazione	Rete
Protocolli supportati	HTTP(S), TCP, gRPC	N/D	HTTP(S), websocket
Responsabilità della configurazione	Operatori cluster	Sviluppatori di applicazioni	Operatori applicazioni e operatori cluster
Complessità della configurazione per l'osservabilità	Ridotto	Elevato	Medio

Suggerimenti per la progettazione

Implementare Open Service Mesh per ottenere l'osservabilità dell'integrità e delle prestazioni dei servizi. Open Service Mesh usa proxy sidecar inseriti come contenitore separato negli stessi pod dei carichi di lavoro per ottenere i dati di telemetria. Questi proxy intercettano tutto il traffico HTTP in ingresso e in uscita verso i carichi di lavoro e segnalano i dati a Open Service Mesh. Con questo sistema, gli sviluppatori di servizi non devono instrumentare il codice per raccogliere dati di telemetria.

Abilitare Open Service Mesh usando la funzionalità di estensione del cluster Kubernetes abilitata per Azure Arc, che consente a Microsoft di gestire il piano di controllo. Per altre informazioni, vedere Distribuire Open Service Mesh (anteprima) abilitato per Azure Arc.

Per ottimizzare la disponibilità e le prestazioni delle applicazioni e dei servizi, abilitare Azure Monitor Container Insights. Offre una soluzione completa per la raccolta, l'analisi e l'esecuzione dei dati di telemetria dagli ambienti cloud e locali. Azure Arc-enabled Open Service Mesh si integra in modo approfondito con Monitoraggio di Azure, offrendo un metodo semplice di visualizzazione e risposta agli indicatori KPI critici forniti dalle metriche OSM e dai log dei contenitori di applicazioni. È possibile abilitare le metriche OSM seguendo questa procedura. Per la traccia distribuita, è consigliabile usare Jaeger, che può essere integrato con il piano di controllo OSM.

Open Service Mesh offre anche integrazioni di osservabilità documentate per le metriche con Prometheus e Grafana, la traccia con Jaeger e l'inoltro dei log con Fluent Bit. Queste integrazioni offrono opzioni alternative se non si usano soluzioni di monitoraggio di Azure. È possibile usare queste integrazioni per estendersi ad altri strumenti di monitoraggio interni in base alle esigenze.

È necessario definire almeno le tre metriche RED seguenti e misurarle per tutti i servizi:

• Frequenza richiesta: numero di richieste ricevute dal servizio al secondo.
• Errori: numero di richieste non riuscite o frequenza di richieste non riuscite al secondo.
• Durata: tempo necessario per gestire una richiesta da parte di un servizio.

Open Service Mesh offre diverse cartelle di lavoro del servizio preconfigurato in Monitoraggio di Azure, quindi non è necessario configurare manualmente dashboard e grafici. Questa telemetria dettagliata consente di osservare il comportamento del servizio e consente di risolvere i problemi, gestire e ottimizzare le applicazioni. L'uso della cartella di lavoro di monitoraggio di OSM in Monitoraggio di Azure consente di:

• Ottenere una panoramica di tutti i servizi nella mesh e ottenere metriche critiche a livello di servizio per tre dei quattro segnali d'oro del monitoraggio: latenza, richieste ed errori.
• Definire, esaminare e impostare avvisi in base agli obiettivi del livello di servizio ,che riepilogano le prestazioni visibili dell'utente del servizio.
• Visualizzare i grafici delle metriche per i singoli servizi per analizzarli in modo approfondito usando filtri e suddivisioni, per analizzare i dati in base al codice di risposta, al protocollo, al pod di destinazione, all'origine del traffico e altro ancora.

Usare le visualizzazioni dall'interfaccia utente di Jaeger per:

• Osservare una visualizzazione del grafo della topologia che mostra i microservizi che comunicano tra loro, dove vanno le richieste e per quanto tempo sono necessari.
• Esaminare le richieste e le risposte specifiche per vedere come e quando si verificano per il monitoraggio e la risoluzione dei problemi dei sistemi distribuiti.

L'osservabilità dei servizi è solo una disciplina della strategia di monitoraggio del cloud. Per altre informazioni sulle discipline di gestione, vedere l'area Progettazione critica delle discipline di gestione.

Passaggi successivi

Per altre informazioni sul percorso cloud ibrido e multicloud, vedere gli articoli seguenti:

• Esaminare i prerequisiti per Kubernetes abilitato per Azure Arc.
• Esaminare le distribuzioni kubernetes convalidate per Kubernetes con abilitazione di Azure Arc.
• Informazioni su come gestire ambienti ibridi e multicloud.
• Per altre informazioni su Open Service Mesh abilitata per Azure Arc, vedere:
  • Distribuire Open Service Mesh (anteprima) abilitato per Azure Arc.
  • Aprire il componente aggiuntivo servizio Azure Kubernetes.
  • Aprire la documentazione upstream di Service Mesh
• Informazioni su come configurare monitoraggio e osservabilità con Open Service Mesh in servizio Azure Kubernetes (servizio Azure Kubernetes)
• Informazioni su Gestione e monitoraggio per Kubernetes abilitato per Azure Arc.
• Informazioni sulle mesh di servizi.
• Provare Kubernetes abilitato per Azure Arc con l'estensione Open Service Mesh di Azure Arc Jumpstart.
• Altre informazioni su Azure Arc tramite il percorso di apprendimento di Azure Arc.
• Per trovare le risposte alle domande più comuni, vedere Domande frequenti - Abilitazione di Azure Arc.