Monitorare un'applicazione di microservizi nel servizio Azure Kubernetes

Questo articolo descrive le procedure consigliate per il monitoraggio di un'applicazione di microservizi in esecuzione in servizio Azure Kubernetes (servizio Azure Kubernetes). Gli argomenti specifici includono la raccolta di dati di telemetria, il monitoraggio dello stato, le metriche, la registrazione, la registrazione strutturata e la traccia distribuita di un cluster. Quest'ultimo è illustrato in questo diagramma:

Scaricare un file di Visio di questa architettura.

Raccolta di dati di telemetria

In qualsiasi applicazione complessa è inevitabile che a un certo punto si verifichi un errore. In un'applicazione di microservizi è necessario tenere traccia di quanto avviene in decine o addirittura centinaia di servizi. Per comprendere cosa accade, è necessario raccogliere dati di telemetria dall'applicazione. I dati di telemetria possono essere suddivisi in queste categorie: log, tracce e metriche.

I log sono record basati su testo di eventi che si verificano durante l'esecuzione di un'applicazione. Includono elementi come i log applicazioni (istruzioni di traccia) e i log del server Web. Sono utili principalmente per la scienza forense e l'analisi delle cause radice.

Le tracce, dette anche operazioni, connettono i passaggi di una singola richiesta tra più chiamate all'interno e tra microservizi. Possono fornire un'osservabilità strutturata nelle interazioni dei componenti di sistema. Le tracce possono iniziare all'inizio del processo di richiesta, ad esempio all'interno dell'interfaccia utente di un'applicazione, e possono essere propagate attraverso servizi di rete in una rete di microservizi che gestiscono la richiesta.

• Gli intervalli sono unità di lavoro all'interno di una traccia. Ogni intervallo è connesso a una singola traccia e può essere annidato con altri intervalli. Spesso corrispondono a singole richieste in un'operazione tra servizi, ma possono anche definire il lavoro in singoli componenti all'interno di un servizio. Si estende anche per tenere traccia delle chiamate in uscita da un servizio a un altro. A volte gli intervalli sono denominati record di dipendenza.

Per metriche si intendono valori numerici che è possibile analizzare. È possibile usarli per osservare un sistema in tempo reale (o quasi in tempo reale) o per analizzare le tendenze delle prestazioni nel tempo. Per comprendere un sistema in modo olistico, è necessario raccogliere metriche a vari livelli dell'architettura, dall'infrastruttura fisica all'applicazione, tra cui:

• Metriche a livello di nodo, che includono utilizzo della CPU, della memoria, della rete, dei dischi e del file system. Le metriche di sistema consentono di comprendere l'allocazione delle risorse per ogni nodo del cluster e di risolvere i problemi relativi agli outlier.

• Metriche del contenitore. Per le applicazioni in contenitori, è necessario raccogliere le metriche a livello di contenitore, non solo a livello di macchina virtuale.

• Metriche dell'applicazione. Queste metriche sono rilevanti per comprendere il comportamento di un servizio. Tra gli esempi sono inclusi il numero di richieste HTTP in ingresso in coda, la latenza delle richieste e la lunghezza della coda di messaggi. Le applicazioni possono anche usare metriche personalizzate specifiche del dominio, ad esempio il numero di transazioni aziendali elaborate al minuto.

• Metriche dei servizi dipendenti. I servizi talvolta chiamano servizi o endpoint esterni, ad esempio servizi PaaS gestiti o SaaS. I servizi di terze parti potrebbero non fornire metriche. In caso contrario, è necessario basarsi sulle metriche dell'applicazione personalizzate per tenere traccia delle statistiche relative alla latenza e alla frequenza degli errori.

Monitoraggio dello stato del cluster

Usare Monitoraggio di Azure per monitorare l'integrità dei cluster. Lo screenshot seguente mostra un cluster con errori critici nei pod distribuiti dall'utente:

Da qui è possibile eseguire il drill-down per trovare il problema. Ad esempio, se lo stato del pod è ImagePullBackoff, Kubernetes non è riuscito a eseguire il pull dell'immagine del contenitore dal registro. Questo problema può essere causato da un tag contenitore non valido o da un errore di autenticazione durante un pull dal Registro di sistema.

Se un contenitore si arresta in modo anomalo, il contenitore State diventa Waiting, con un Reason di CrashLoopBackOff. Per uno scenario tipico, in cui un pod fa parte di un set di repliche e il criterio di ripetizione dei tentativi è Always, questo problema non viene visualizzato come errore nello stato del cluster. Tuttavia, è possibile eseguire query o configurare avvisi per questa condizione. Per altre informazioni, vedere Informazioni sulle prestazioni del cluster del servizio Azure Kubernetes con Informazioni dettagliate sui contenitori di Monitoraggio di Azure.

Nel riquadro cartelle di lavoro di una risorsa del servizio Azure Kubernetes sono disponibili più cartelle di lavoro specifiche del contenitore. È possibile usare queste cartelle di lavoro per una rapida panoramica, risoluzione dei problemi, gestione e informazioni dettagliate. Lo screenshot seguente mostra un elenco di cartelle di lavoro disponibili per impostazione predefinita per i carichi di lavoro del servizio Azure Kubernetes.

Metriche

È consigliabile usare Monitoraggio per raccogliere e visualizzare le metriche per i cluster del servizio Azure Kubernetes e per qualsiasi altro servizio di Azure dipendente.

• Per le metriche del cluster e dei contenitori, abilitare Informazioni dettagliate sui contenitori di Monitoraggio di Azure. Quando questa funzionalità è abilitata, Monitoraggio raccoglie metriche di memoria e processore da controller, nodi e contenitori tramite l'API Metriche di Kubernetes. Per altre informazioni sulle metriche disponibili in Informazioni dettagliate sui contenitori, vedere Informazioni dettagliate sui cluster del servizio Azure Kubernetes con Informazioni dettagliate sui contenitori di Monitoraggio di Azure.

• Usare Application Insights per raccogliere le metriche dell'applicazione. Application Insights è un servizio APM (Extensible Application Performance Management). Per usarlo, installare un pacchetto di strumentazione nell'applicazione. Questo pacchetto monitora l'app e invia i dati di telemetria ad Application Insights. Il pacchetto può anche estrarre i dati di telemetria dall'ambiente host. I dati vengono quindi inviati a Monitoraggio. Application Insights offre anche la correlazione predefinita e il rilevamento delle dipendenze. (Vedere Traccia distribuita, più avanti in questo articolo.

Application Insights ha una velocità effettiva massima misurata negli eventi al secondo e limita i dati di telemetria se la velocità dei dati supera il limite. Per informazioni dettagliate, vedere Limiti di Application Insights. Creare istanze di Application Insights diverse per ogni ambiente, in modo che gli ambienti di sviluppo/test non siano in competizione con i dati di telemetria di produzione per la quota.

Una singola operazione può generare molti eventi di telemetria, quindi se un'applicazione riscontra un volume elevato di traffico, è probabile che l'acquisizione dei dati di telemetria venga limitata. Per ovviare a questo problema, è possibile eseguire il campionamento in modo da ridurre il traffico dei dati di telemetria. Il compromesso è che le metriche saranno meno precise, a meno che la strumentazione non supporti la pre-aggregazione. In tal caso, ci saranno meno campioni di traccia per la risoluzione dei problemi, ma le metriche mantengono l'accuratezza. Per altre informazioni, vedere Campionamento in Application Insights. È anche possibile ridurre il volume di dati preaggregando le metriche. Ovvero, è possibile calcolare valori statistici, ad esempio la deviazione media e standard, e inviare tali valori anziché i dati di telemetria non elaborati. Questo post di blog descrive un approccio all'uso di Application Insights su larga scala: Monitoraggio di Azure e Analisi su larga scala.

Se la velocità dei dati è sufficientemente elevata per attivare la limitazione delle richieste e il campionamento o l'aggregazione non sono accettabili, valutare la possibilità di esportare le metriche in un database time series, ad esempio Azure Esplora dati, Prometheus o InfluxDB, in esecuzione nel cluster.

• Azure Esplora dati è un servizio di esplorazione dei dati nativo di Azure altamente scalabile per i dati di log e telemetria. Offre il supporto per più formati di dati, un linguaggio di query avanzato e connessioni per l'utilizzo di dati in strumenti comuni come Jupyter Notebook e Grafana. Azure Esplora dati include connettori predefiniti per inserire dati di log e metriche tramite Hub eventi di Azure. Per altre informazioni, vedere Inserire ed eseguire query sui dati di monitoraggio in Azure Esplora dati.

• InfluxDB è un sistema basato sul push, questo significa che un agente deve eseguire il push delle metriche. È possibile usare lo stack TICK per configurare il monitoraggio di Kubernetes. Successivamente, è possibile eseguire il push delle metriche in InfluxDB usando Telegraf, che è un agente per la raccolta e la creazione di report delle metriche. È possibile usare InfluxDB per eventi irregolari e tipi di dati stringa.

• Prometheus è un sistema basato sul pull, che recupera periodicamente le metriche da posizioni configurate. Prometheus può raschiare le metriche generate da Monitoraggio di Azure o kube-state-metrics. kube-state-metrics è un servizio che raccoglie le metriche dal server API Kubernetes e le rende disponibili per Prometheus (o uno scraper compatibile con un endpoint client Prometheus). Per le metriche di sistema, usare l'utilità di esportazione dei nodi, che è un utilità di esportazione Prometheus per le metriche di sistema. Prometheus supporta dati a virgola mobile, ma non dati stringa, pertanto è appropriato per le metriche di sistema, ma non per i log. Il server metriche Kubernetes è un aggregatore a livello di cluster dei dati di utilizzo delle risorse.

Registrazione

Ecco alcune delle problematiche generali della registrazione in un'applicazione di microservizi:

• Comprensione dell'elaborazione end-to-end di una richiesta client, in cui potrebbero essere richiamati più servizi per gestire una singola richiesta.
• Consolidamento dei log da più servizi in una singola vista aggregata.
• Analisi dei log provenienti da più origini che usano schemi di registrazione personalizzati o che non hanno uno schema specifico. I log potrebbero essere generati da componenti di terze parti che non si controllano.
• Le architetture di microservizi generano spesso un volume maggiore di log rispetto ai monoliti tradizionali perché sono presenti più servizi, chiamate di rete e passaggi in una transazione. Ciò significa che la registrazione stessa può essere un collo di bottiglia delle prestazioni o delle risorse per l'applicazione.

Esistono alcuni problemi aggiuntivi per le architetture basate su Kubernetes:

• I contenitori possono essere spostati e ripianificati.
• Kubernetes ha un'astrazione di rete che usa gli indirizzi IP virtuali e i mapping delle porte.

In Kubernetes l'approccio standard alla registrazione consiste nel scrivere log in stdout e stderr per un contenitore. Il motore del contenitore reindirizza questi flussi a un driver di registrazione. Per semplificare l'esecuzione di query e per evitare possibili perdite di dati di log se un nodo smette di rispondere, l'approccio consueto consiste nel raccogliere i log da ogni nodo e inviarli a una posizione di archiviazione centrale.

Monitoraggio di Azure si integra con il servizio Azure Kubernetes per supportare questo approccio. Monitoraggio raccoglie i log dei contenitori e li invia a un'area di lavoro Log Analytics. Da qui è possibile usare il Linguaggio di query Kusto per scrivere query nei log aggregati. Ad esempio, ecco una query Kusto per visualizzare i log del contenitore per un pod specificato:

ContainerLogV2
| where PodName == "podName" //update with target pod
| project TimeGenerated, Computer, ContainerId, LogMessage, LogSource

Monitoraggio di Azure è un servizio gestito e la configurazione di un cluster del servizio Azure Kubernetes per l'uso di Monitoraggio è una semplice modifica della configurazione nell'interfaccia della riga di comando o nel modello di Azure Resource Manager. Per altre informazioni, vedere Come abilitare Informazioni dettagliate sui contenitori di Monitoraggio di Azure. Un altro vantaggio dell'uso di Monitoraggio di Azure consiste nel consolidare i log del servizio Azure Kubernetes con altri log della piattaforma Azure per offrire un'esperienza di monitoraggio unificata.

Monitoraggio di Azure viene fatturato per gigabyte (GB) di dati inseriti nel servizio. (Vedere Prezzi di Monitoraggio di Azure. A volumi elevati, i costi potrebbero diventare una considerazione. Sono disponibili molte alternative open source per l'ecosistema Kubernetes. Ad esempio, molte organizzazioni usano Fluentd con Elasticsearch. Fluentd è un agente di raccolta dati open source e Elasticsearch è un database di documenti usato per la ricerca. Una sfida con queste opzioni è che richiedono una configurazione e una gestione aggiuntive del cluster. Per un carico di lavoro di produzione, potrebbe essere necessario sperimentare le impostazioni di configurazione. È anche necessario monitorare le prestazioni dell'infrastruttura di registrazione.

OpenTelemetry

OpenTelemetry è uno sforzo tra il settore per migliorare la traccia standardizzando l'interfaccia tra applicazioni, librerie, dati di telemetria e agenti di raccolta dati. Quando si usa una libreria e un framework instrumentati con OpenTelemetry, la maggior parte delle operazioni di traccia che sono tradizionalmente operazioni di sistema viene gestita dalle librerie sottostanti, che includono gli scenari comuni seguenti:

• Registrazione di operazioni di richiesta di base, ad esempio ora di inizio, ora di uscita e durata
• Eccezioni generate
• Propagazione del contesto (ad esempio l'invio di un ID di correlazione tra i limiti delle chiamate HTTP)

Al contrario, le librerie e i framework di base che gestiscono queste operazioni creano strutture di dati di analisi e interrelazione avanzate e le propagano in contesti diversi. Prima di OpenTelemetry, questi venivano in genere inseriti come messaggi di log speciali o come strutture di dati proprietarie specifiche del fornitore che hanno creato gli strumenti di monitoraggio. OpenTelemetry incoraggia anche un modello di dati di strumentazione più completo rispetto a un approccio tradizionale di registrazione e i log sono più utili perché i messaggi di log sono collegati alle tracce e agli intervalli in cui sono stati generati. Questo rende spesso semplice trovare i log associati a un'operazione o a una richiesta specifica.

Molti degli SDK di Azure sono stati instrumentati con OpenTelemetry o sono in fase di implementazione.

Uno sviluppatore di applicazioni può aggiungere strumentazione manuale usando gli SDK OpenTelemetry per eseguire le attività seguenti:

• Aggiungere la strumentazione in cui non viene fornita una libreria sottostante.
• Arricchire il contesto di traccia aggiungendo intervalli per esporre unità di lavoro specifiche dell'applicazione, ad esempio un ciclo di ordine che crea un intervallo per l'elaborazione di ogni riga dell'ordine.
• Arricchire gli intervalli esistenti con le chiavi di entità per semplificare la traccia. Ad esempio, aggiungere una chiave/valore OrderID alla richiesta che elabora tale ordine. Queste chiavi vengono visualizzate dagli strumenti di monitoraggio come valori strutturati per l'esecuzione di query, filtri e aggregazioni (senza analizzare le stringhe dei messaggi di log o cercare combinazioni di sequenze di messaggi di log, come è stato comune con un approccio di registrazione-primo).
• Propagare il contesto di traccia accedendo agli attributi di traccia e span, inserendo traceId in risposte e payload e/o leggendo traceId dai messaggi in ingresso, per creare richieste e intervalli.

Altre informazioni sulla strumentazione e sugli SDK OpenTelemetry sono disponibili nella documentazione di OpenTelemetry.

Application Insights

Application Insights raccoglie dati avanzati da OpenTelemetry e dalle relative librerie di strumentazione e le acquisisce in un archivio dati efficiente per offrire funzionalità avanzate di visualizzazione e supporto delle query. Le librerie di strumentazione basate su OpenTelemetry di Application Insights per linguaggi come .NET, Java, Node.js e Python semplificano l'invio di dati di telemetria ad Application Insights.

Se si usa .NET Core, è consigliabile prendere in considerazione anche la libreria Application Insights per Kubernetes . Questa libreria arricchisce le tracce di Application Insights con informazioni aggiuntive, ad esempio il contenitore, il nodo, il pod, le etichette e il set di repliche.

Application Insights esegue il mapping del contesto OpenTelemetry al modello di dati interno:

• Traccia -> Operazione
• ID traccia -> ID operazione
• Span -> Richiesta o dipendenza

Tenere conto delle considerazioni seguenti:

• Application Insights limita i dati di telemetria se la velocità dei dati supera un limite massimo. Per informazioni dettagliate, vedere Limiti di Application Insights. Una singola operazione può generare diversi eventi di telemetria, quindi se un'applicazione riscontra un volume elevato di traffico, è probabile che venga limitata.
• Poiché Application Insights raggruppa i dati, è possibile perdere un batch se un processo ha esito negativo con un'eccezione non gestita.
• La fatturazione di Application Insights si basa sul volume di dati. Per altre informazioni, vedere Gestire volumi di dati e prezzi in Application Insights.

Registrazione strutturata

Per semplificare l'analisi dei log, usare la registrazione strutturata quando possibile. Quando si usa la registrazione strutturata, l'applicazione scrive i log in un formato strutturato, ad esempio JSON, anziché restituire stringhe di testo non strutturate. Sono disponibili molte librerie di registrazione strutturate. Ecco, ad esempio, un'istruzione di registrazione che usa la libreria Serilog per .NET Core:

public async Task<IActionResult> Put([FromBody]Delivery delivery, string id)
{
    logger.LogInformation("In Put action with delivery {Id}: {@DeliveryInfo}", id, delivery.ToLogInfo());

    ...
}

In questo caso, la chiamata a LogInformation include un parametro e DeliveryInfo un Id parametro. Quando si usa la registrazione strutturata, questi valori non vengono interpolati nella stringa del messaggio. L'output del log è invece simile al seguente:

{"@t":"2019-06-13T00:57:09.9932697Z","@mt":"In Put action with delivery {Id}: {@DeliveryInfo}","Id":"36585f2d-c1fa-4a3d-9e06-a7f40b7d04ef","DeliveryInfo":{...

Si tratta di una stringa JSON, in cui il @t campo è un timestamp, @mt è la stringa di messaggio e le coppie chiave/valore rimanenti sono i parametri. L'output del formato JSON semplifica l'esecuzione di query sui dati in modo strutturato. Ad esempio, la query di Log Analytics seguente, scritta nel linguaggio di query Kusto, cerca le istanze di questo particolare messaggio da tutti i contenitori denominati fabrikam-delivery:

traces
| where customDimensions.["Kubernetes.Container.Name"] == "fabrikam-delivery"
| where customDimensions.["{OriginalFormat}"] == "In Put action with delivery {Id}: {@DeliveryInfo}"
| project message, customDimensions["Id"], customDimensions["@DeliveryInfo"]

Se si visualizza il risultato nella portale di Azure, è possibile notare che DeliveryInfo è un record strutturato che contiene la rappresentazione serializzata del DeliveryInfo modello:

Ecco il codice JSON di questo esempio:

{
  "Id": "36585f2d-c1fa-4a3d-9e06-a7f40b7d04ef",
  "Owner": {
    "UserId": "user id for logging",
    "AccountId": "52dadf0c-0067-43e7-af76-86e32b48bc5e"
  },
  "Pickup": {
    "Altitude": 0.29295161612934972,
    "Latitude": 0.26815900219052985,
    "Longitude": 0.79841844309047727
  },
  "Dropoff": {
    "Altitude": 0.31507750848078986,
    "Latitude": 0.753494655598651,
    "Longitude": 0.89352830773849423
  },
  "Deadline": "string",
  "Expedited": true,
  "ConfirmationRequired": 0,
  "DroneId": "AssignedDroneId01ba4d0b-c01a-4369-ba75-51bde0e76cc9"
}

Molti messaggi di log contrassegnano l'inizio o la fine di un'unità di lavoro oppure connettono un'entità aziendale con un set di messaggi e operazioni per la tracciabilità. In molti casi, l'arricchimento degli oggetti OpenTelemetry e request è un approccio migliore rispetto alla registrazione solo dell'inizio e della fine dell'operazione. In questo modo, tale contesto viene aggiunto a tutte le tracce connesse e alle operazioni figlio e inserisce tali informazioni nell'ambito dell'operazione completa. Gli SDK OpenTelemetry per diversi linguaggi supportano la creazione di intervalli o l'aggiunta di attributi personalizzati su intervalli. Ad esempio, il codice seguente usa Java OpenTelemetry SDK, supportato da Application Insights. Un intervallo padre esistente (ad esempio, un intervallo di richieste associato a una chiamata al controller REST e creato dal framework Web in uso) può essere arricchito con un ID entità associato, come illustrato di seguito:

import io.opentelemetry.api.trace.Span;

// ...

Span.current().setAttribute("A1234", deliveryId);

Questo codice imposta una chiave o un valore sull'intervallo corrente, connesso alle operazioni e ai messaggi di log che si verificano in tale intervallo. Il valore viene visualizzato nell'oggetto richiesta di Application Insights, come illustrato di seguito:

requests
| extend deliveryId = tostring(customDimensions.deliveryId)  // promote to column value (optional)
| where deliveryId == "A1234"
| project timestamp, name, url, success, resultCode, duration, operation_Id, deliveryId

Questa tecnica diventa più efficace quando viene usata con log, filtri e annotazioni delle tracce di log con contesto di intervallo, come illustrato di seguito:

requests
| extend deliveryId = tostring(customDimensions.deliveryId)  // promote to column value (optional)
| where deliveryId == "A1234"
| project deliveryId, operation_Id, requestTimestamp = timestamp, requestDuration = duration  // keep some request info
| join kind=inner traces on operation_Id   // join logs only for this deliveryId
| project requestTimestamp, requestDuration, logTimestamp = timestamp, deliveryId, message

Se si usa una libreria o un framework già instrumentato con OpenTelemetry, gestisce la creazione di intervalli e richieste, ma il codice dell'applicazione potrebbe anche creare unità di lavoro. Ad esempio, un metodo che esegue un ciclo attraverso una matrice di entità che esegue operazioni su ognuno di essi può creare un intervallo per ogni iterazione del ciclo di elaborazione. Per informazioni sull'aggiunta di strumentazione al codice dell'applicazione e della libreria, vedere la documentazione di strumentazione OpenTelemery.

Traccia distribuita

Uno dei problemi che si verifica quando si usano i microservizi è comprendere il flusso di eventi tra i servizi. Una singola transazione può comportare chiamate a più servizi.

Esempio di traccia distribuita

In questo esempio viene descritto il percorso di una transazione distribuita tramite un set di microservizi. L'esempio si basa su un'applicazione di recapito tramite drone.

In questo scenario la transazione distribuita include questi passaggi:

1. Il servizio di inserimento inserisce un messaggio in una coda di bus di servizio di Azure.
2. Il servizio Flusso di lavoro esegue il pull del messaggio dalla coda.
3. Il servizio Flusso di lavoro chiama tre servizi back-end per elaborare la richiesta (Utilità di pianificazione drone, Pacchetto e Recapito).

Lo screenshot seguente mostra la mappa delle applicazioni per l'applicazione di recapito tramite drone. Questa mappa mostra le chiamate all'endpoint API pubblico che comportano un flusso di lavoro che coinvolge cinque microservizi.

Le frecce da fabrikam-workflow e fabrikam-ingestion a una coda di bus di servizio mostrano dove vengono inviati e ricevuti i messaggi. Non è possibile indicare dal diagramma quale servizio sta inviando messaggi e quali ricevono. Le frecce mostrano solo che entrambi i servizi chiamano bus di servizio. Tuttavia, le informazioni su quale servizio invia e che riceve sono disponibili nei dettagli:

Poiché ogni chiamata include un ID operazione, è anche possibile visualizzare i passaggi end-to-end di una singola transazione, incluse le informazioni sulla tempistica e le chiamate HTTP in ogni passaggio. Ecco la visualizzazione di una di queste transazioni:

Questa visualizzazione mostra i passaggi dal servizio di inserimento alla coda, dalla coda al servizio Flusso di lavoro e dal servizio Flusso di lavoro agli altri servizi back-end. L'ultimo passaggio è il servizio Flusso di lavoro che contrassegna il messaggio di bus di servizio completato.

Questo esempio mostra le chiamate a un servizio back-end che ha esito negativo:

Questa mappa mostra che una frazione elevata (36%) delle chiamate al servizio Utilità di pianificazione drone non è riuscita durante il periodo della query. La visualizzazione delle transazioni end-to-end rivela che si verifica un'eccezione quando viene inviata una richiesta HTTP PUT al servizio:

Se si esegue il drill-in più, si noterà che l'eccezione è un'eccezione socket: "Nessun dispositivo o indirizzo di questo tipo".

Fabrikam.Workflow.Service.Services.BackendServiceCallFailedException: 
No such device or address 
---u003e System.Net.Http.HttpRequestException: No such device or address 
---u003e System.Net.Sockets.SocketException: No such device or address

Questa eccezione suggerisce che il servizio back-end non è raggiungibile. A questo punto, è possibile usare kubectl per visualizzare la configurazione della distribuzione. In questo esempio il nome host del servizio non viene risolto a causa di un errore nei file di configurazione di Kubernetes. L'articolo Servizi di debug nella documentazione di Kubernetes contiene suggerimenti per la diagnosi di questo tipo di errore.

Ecco alcune cause comuni di errori:

• Bug di codice. Questi bug potrebbero apparire come:
  • Eccezioni. Esaminare i log di Application Insights per visualizzare i dettagli dell'eccezione.
  • Un processo che ha esito negativo. Esaminare lo stato del contenitore e del pod e visualizzare i log dei contenitori o le tracce di Application Insights.
  • Errori HTTP 5xx .
• Esaurimento delle risorse:
  • Cercare la limitazione (HTTP 429) o i timeout delle richieste.
  • Esaminare le metriche dei contenitori per CPU, memoria e disco.
  • Esaminare le configurazioni per i limiti delle risorse contenitore e pod.
• Individuazione dei servizi. Esaminare i mapping delle porte e della configurazione del servizio Kubernetes.
• Mancata corrispondenza dell'API. Cercare errori HTTP 400. Se le API vengono sottoposte a controllo delle versioni, esaminare la versione chiamata.
• Errore durante il pull di un'immagine del contenitore. Esaminare la specifica del pod. Assicurarsi anche che il cluster sia autorizzato a eseguire il pull dal registro contenitori.
• Problemi di controllo degli accessi in base al ruolo.

Passaggi successivi

Altre informazioni sulle funzionalità di Monitoraggio di Azure che supportano il monitoraggio delle applicazioni nel servizio Azure Kubernetes:

• Panoramica delle informazioni dettagliate sul contenitore di Monitoraggio di Azure
• Comprendere le prestazioni del cluster del servizio Azure Kubernetes con Informazioni dettagliate sui contenitori di Monitoraggio di Azure

Risorse correlate

• Ottimizzazione delle prestazioni di un'applicazione distribuita
• Uso dell'analisi del dominio per modellare i microservizi
• Progettare un'architettura di microservizi
• Progettare API per microservizi