Che cosa sono i log di rete dei contenitori?

I log di rete dei contenitori in Servizi di rete contenitore avanzata per Servizio Azure Kubernetes (AKS) offrono visibilità su ogni flusso di rete all'interno del cluster. Le metriche indicano cosa accade nella rete (utilizzo della larghezza di banda, percentuali di errore). I log indicano perché: chi ha avviato una connessione, quali protocolli sono stati usati e se il traffico è stato consentito o bloccato.

Questi log acquisiscono i metadati per ogni flusso di rete:

• Indirizzi IP di origine e di destinazione, nomi di pod e nomi di servizio
• Namespace, porte e protocolli
• Direzione del traffico e verdetti dei criteri

Con questo contesto, è possibile correlare il comportamento di rete con carichi di lavoro specifici, risolvere i problemi di connettività, convalidare i criteri di sicurezza ed eseguire analisi forensi. I log di rete dei contenitori coprono il traffico di livello 3 (IP), livello 4 (TCP/UDP) e di livello 7 (HTTP/gRPC/Kafka).

Per gestire il volume di dati e i costi, i log di rete del contenitore supportano l'aggregazione dei log dei flussi, che raggruppa flussi simili in record riepilogati anziché archiviare un record per ogni evento di connessione. Si mantengono i modelli operativi necessari riducendo i costi di archiviazione e ingestione. Per altre informazioni, vedere Aggregazione dei log di flusso.

I log di rete dei contenitori offrono due modalità:

• Log archiviati : raccolta continua con filtri personalizzati e aggregazione dei flussi. Ideale per il monitoraggio e l'analisi a lungo termine.
• Log su richiesta : acquisizione in tempo reale tramite l'interfaccia della riga di comando di Hubble e l'interfaccia utente di Hubble. Ideale per la risoluzione dei problemi ad hoc.

Usare i log archiviati quando sono necessari record persistenti per conformità, analisi delle tendenze o avvisi automatizzati. Usare i log su richiesta quando si esegue attivamente il debug di un problema di connettività o prestazioni e si necessita di visibilità immediata sul traffico live.

File di log archiviati

La modalità log archiviati viene abilitata automaticamente ogni volta che Advanced Container Networking Services è abilitato in un cluster. La funzionalità è disponibile, ma non vengono generati log fino a quando non si indica a ACNS cosa acquisire.

Per iniziare a raccogliere i log, definire ContainerNetworkLog risorse personalizzate che specificano il traffico da monitorare: per spazio dei nomi, pod, servizio, protocollo o verdetto. Dopo l'applicazione di un CRD, l'agente Cilium inizia a generare flussi corrispondenti ai filtri e li scrive in ogni nodo. La raccolta rimane attiva fino a quando non si rimuovono i CRD o si disabilita ACNS.

Poiché si controlla esattamente quale traffico viene registrato tramite filtri CRD, è possibile concentrarsi sui flussi importanti ed evitare di raccogliere dati non necessari. In combinazione con l'aggregazione dei log di flusso, questo approccio mantiene i costi di archiviazione prevedibili e incentrati sull'analisi.

Funzionamento della modalità di archiviazione dei log

Advanced Container Networking Services usa la tecnologia eBPF con Cilium per acquisire i flussi di rete in ogni nodo. Dopo l'abilitazione di ACNS e l'applicazione di una ContainerNetworkLog risorsa personalizzata, l'agente Cilium raccoglie il traffico corrispondente al filtro e scrive i log in formato JSON su ogni host. La generazione dei log viene eseguita interamente all'interno del cluster e non dipende da Monitoraggio di Azure.

Per l'uso in produzione, è consigliabile abilitare il componente aggiuntivo Monitoraggio di Azure. Se abilitato, gli agenti di Container Insights raccolgono i log locali dell'host, applicano limiti di limitazione al flusso e li inviano a un'area di lavoro Log Analytics, dove è possibile ottenere la conservazione a lungo termine, le query KQL, il portale di Azure predefinito e i dashboard Grafana. Questo è il percorso più integrato e quello che la maggior parte dei clienti dovrebbe scegliere.

Se il team dispone di una pipeline di osservabilità esistente, è invece possibile inoltrare gli stessi log locali dell'host a qualsiasi agente di raccolta o servizio di registrazione compatibile con OpenTelemetry, insieme a Monitoraggio di Azure o al posto di esso.

Per ulteriori informazioni sul throttling e su Container Insights, consultare la documentazione di Container Insights.

Uso dei log di rete dei contenitori con o senza Monitoraggio di Azure

È possibile usare i log di rete dei contenitori in due modi. La scelta corretta dipende dal fatto che si voglia un'esperienza nativa di Azure integrata o si abbia già una pipeline di osservabilità che si vuole continuare a usare.

Per la maggior parte dei clienti, è consigliabile abilitare Monitoraggio di Azure. È il modo più rapido per ottenere funzionalità di conservazione, query e dashboard senza creare una pipeline personalizzata.

Funzionalità chiave della modalità log archiviati

• Filtri personalizzabili. Definire risorse ContainerNetworkLog personalizzate per filtrare in base allo spazio dei nomi, ai pod, al servizio, alla porta, al protocollo, al verdetto o alla direzione del traffico. Viene registrato solo il traffico corrispondente, in modo da ottenere un controllo preciso sugli elementi raccolti e sui costi.

• Aggregazione dei log di flusso. I flussi simili sono raggruppati automaticamente in record riepilogati ogni 30 secondi, riducendo il volume dei dati mentre si conservano i segnali operativi come i modelli di comunicazione dei servizi, i tassi di errore e i verdetti di sicurezza. Associato a filtri mirati, l'aggregazione consente di mantenere una visibilità ampia senza costi di inserimento eccessivi. Per altre informazioni, vedere Aggregazione dei log di flusso.

• Opzioni di archiviazione dei log. ACNS scrive sempre i log in locale in ogni nodo. Da qui è possibile scegliere come usarli:

  • File locali dell'host (sempre attivi): I log vengono archiviati nei nodi ospitanti in /var/log/acns/hubble. I file ruotano automaticamente a 50 MB e i log precedenti vengono sovrascritti. Usare questa opzione direttamente per il monitoraggio a breve termine, in tempo reale o inoltrare i file a qualsiasi agente di raccolta o servizio di registrazione compatibile con OpenTelemetry per una gestione aggiuntiva dei log.

  • Monitoraggio di Azure (scelta consigliata): Abilitare il componente aggiuntivo Monitoraggio di Azure per raccogliere e archiviare i log in un'area di lavoro Log Analytics. Si ottengono risorse di archiviazione sicure e conformi con conservazione a lungo termine, query KQL, rilevamento anomalie, analisi cronologica e invio di avvisi tramite il servizio gestito per Prometheus. La generazione dei log avviene ancora attraverso l'agente Cilium e il ContainerNetworkLog CRD; Monitoraggio di Azure aggiunge il livello di consumo superiore.

    La ContainerNetworkLogs tabella usa il livello Analytics per impostazione predefinita. È possibile passare al livello Basic per ridurre i costi di inserimento e conservazione mantenendo al tempo stesso un'esperienza di osservabilità simile. Ogni livello ha un dashboard dedicato del portale di Azure ottimizzato per le funzionalità di query. Per ulteriori informazioni sui piani delle tabelle, vedere piani delle tabelle di Log Analytics. Per informazioni su come impostare il piano di tabella, vedere Impostare il piano di tabella.

• Visualizzazione nel portale di Azure. Eseguire query e analizzare i log direttamente in Log Analytics oppure usare i dashboard predefiniti del portale di Azure. Un dashboard dedicato è disponibile per ogni livello di tabella, quindi si ottiene la stessa esperienza di osservabilità indipendentemente dal livello scelto. Per informazioni dettagliate, vedere Visualizzare i log nel portale di Azure.

Visualizzare i log nel portale di Azure

È possibile visualizzare, eseguire query e analizzare i log dei flussi nel portale di Azure nell'area di lavoro Log Analytics per il cluster.

I log di rete dei contenitori includono dashboard predefiniti del portale di Azure per la visualizzazione dei dati del flusso. Per ogni livello di tabella Log Analytics è disponibile un dashboard separato:

Entrambi i dashboard mostrano quali carichi di lavoro AKS comunicano tra loro, inclusi richieste di rete, risposte, rifiuti ed errori. Usare il dashboard corrispondente al livello della tabella configurato per la tabella ContainerNetworkLogs.

I dashboard del portale di Azure hanno i componenti principali seguenti:

• Panoramica della salute della rete. La sezione superiore mostra le metriche di riepilogo (log di flusso totali, richieste univoche, richieste eliminate e richieste inoltrate) in modo da individuare rapidamente le anomalie. Le statistiche sono suddivise per protocollo: richieste DNS eliminate, risposte HTTP 2xx, frequenza di richiesta e risposta di livello 4 e conteggi di rilascio. Un grafico delle dipendenze dei servizi mostra quali servizi comunicano tra loro, semplificando l'identificazione dei colli di bottiglia e dei percorsi di traffico imprevisti.

  

• Log dei flussi e log degli errori. Il dashboard separa i log dei flussi dai log degli errori in visualizzazioni distinte, in modo da potersi concentrare sugli errori senza analizzare il normale traffico. Usare i filtri predefiniti per restringere i risultati in base al protocollo, allo spazio dei nomi o al verdetto. Ad esempio, per risolvere gli errori di risoluzione DNS, filtrare i log degli errori in base al protocollo DNS.

  

  Ogni voce di log include etichette, timestamp e dettagli di origine/destinazione per individuare eventi specifici durante un'indagine.

  

• Principali namespace, carichi di lavoro ed errori DNS. Questa sezione illustra gli spazi dei nomi più attivi, i carichi di lavoro con traffico più elevato, l'utilizzo delle porte e gli errori DNS più frequenti. Usarlo per identificare i carichi di lavoro che generano la maggior parte del traffico, individuare le richieste eliminate e confrontare la distribuzione del protocollo (ad esempio, TCP e UDP). In questo caso modelli insoliti, ad esempio picchi imprevisti o destinazioni sconosciute, possono indicare errori di configurazione o problemi di sicurezza.

  

Aggregazione dei log di flusso

I flussi di rete si accumulano rapidamente. Un cluster con 200 microservizi può generare centinaia di migliaia di record di flusso ogni 30 secondi. L'archiviazione di tutti i dati non elaborati diventa costoso.

Ad esempio, supponiamo che client-1 e client-2 entrambi comunichino con un server pod tramite TCP. In una finestra di 30 secondi, i record di flusso non elaborati nel nodo hanno un aspetto simile al seguente:

Con l'aggregazione, questi 10 record diventano due:

L'aggregazione dei log di flusso affronta questo problema raggruppando flussi simili in record riepilogati. Durante ogni finestra di 30 secondi, i flussi che condividono gli stessi campi chiave di aggregazione vengono combinati in un singolo record con un conteggio del numero di flussi che rappresenta.

I campi seguenti costituiscono la chiave di aggregazione:

I flussi che corrispondono a tutti questi campi all'interno di una finestra di 30 secondi vengono uniti in un unico record. In questo modo vengono mantenuti i segnali necessari (quali servizi comunicano, con quale frequenza si verificano errori, se il traffico è stato consentito o bloccato) durante il taglio significativo del volume di dati. A differenza del campionamento, che elimina in modo casuale i flussi e può perdere eventi di sicurezza rari, l'aggregazione mantiene 100% delle informazioni sul modello.

Punti principali:

• L'aggregazione è abilitata e configurata per impostazione predefinita. In questo modo si riducono i costi di archiviazione e inserimento dei log senza alcuna ottimizzazione manuale.
• Controlli quale traffico viene catturato tramite includeFilters nel ContainerNetworkLog CRD.
• I filtri più stretti (coppie di spazio dei nomi o di servizio specifici) in genere ottengono una compressione migliore perché i flussi acquisiti sono più simili.
• I log aggregati ignorano attributi di cardinalità elevata e per flusso (ad esempio, timestamp individuali, INDIRIZZI IP pod, URL HTTP, nomi di query DNS) per ridurre al minimo il volume di inserimento e i costi di archiviazione. Sono progettati per il rilevamento di problemi di alto livello. Usare i log su richiesta per l'analisi e l'analisi dei flussi con granularità fine.

Log su richiesta

I log su richiesta consentono di acquisire ed esaminare i log dei flussi in tempo reale, senza la configurazione precedente o l'archiviazione permanente. Usare i log su richiesta quando si risolve attivamente un problema di connettività o prestazioni e si necessita di visibilità immediata.

ACNS offre due strumenti per l'acquisizione su richiesta. Per configurare uno degli strumenti, vedere Configurare la modalità log su richiesta.

Interfaccia della riga di comando di Hubble

L'interfaccia della riga di comando di Hubble consente di eseguire query, filtrare e analizzare i log dei flussi direttamente dal terminale. È particolarmente utile quando sono necessari filtri con granularità fine, ad esempio isolando il traffico in base allo spazio dei nomi, all'etichetta del pod o al verdetto durante una sessione di debug attiva.

Interfaccia utente hubble

L'interfaccia utente di Hubble offre una visualizzazione grafica delle comunicazioni da servizio a servizio. È una scelta ottimale quando si vogliono tracciare visivamente i percorsi del traffico, identificare i servizi che comunicano e individuare le anomalie senza scrivere comandi dell'interfaccia della riga di comando.

Vantaggi principali dei log su richiesta

• Non è necessaria alcuna configurazione precedente. Avviare immediatamente l'acquisizione dei flussi senza definire risorse personalizzate o configurare l'archiviazione.
• Visibilità in tempo reale. Esaminare il traffico attivo e visualizzare i metadati dei pacchetti man mano che si verificano problemi.
• Risoluzione dei problemi rapida. Filtrare i flussi in modo interattivo tramite l'interfaccia della riga di comando di Hubble o visualizzare le mappe dei servizi visivamente nell'interfaccia utente di Hubble.
• Sovraccarico ridotto. Nessuna risorsa di archiviazione persistente necessaria, quindi non sono previsti costi continui per le indagini ad hoc.

Raccomandazioni per i log archiviati

1. Iniziare con filtri ampi, quindi restringere. Quando si abilitano per la prima volta i log dei flussi, usare filtri ampi per acquisire il traffico negli spazi dei nomi principali. Eseguire la configurazione per alcuni giorni ed esaminare i dati raccolti in Log Analytics. Esaminare il volume dei dati, il costo e se i flussi acquisiti corrispondono a ciò di cui si ha effettivamente bisogno. Quindi stringi il tuo includeFilters per concentrarti sul traffico di alto valore e ridurre il rumore.

2. Usare i dashboard predefiniti per prima cosa. I dashboard predefiniti del portale di Azure riguardano casi d'uso comuni, ad esempio modelli di comunicazione del servizio, percentuali di errore e errori DNS. Inizia da lì. Aggiungere pannelli personalizzati o query Log Analytics solo se si ha bisogno di una visibilità che i dashboard predefiniti non garantiscono.

3. Esaminare periodicamente. Man mano che i carichi di lavoro e i modelli di traffico cambiano, i filtri potrebbero richiedere l'aggiornamento. Controllare periodicamente il volume di dati e la copertura del flusso per assicurarsi di acquisire il traffico corretto a un costo ragionevole.

Limitazioni

Requisiti relativi al piano dati e alle funzionalità:

• La modalità log archiviati funziona solo con il piano dati Cilium.
• I log dei flussi di livello 7 vengono acquisiti solo quando è abilitato il supporto dei criteri di livello 7. Per altre informazioni, vedere Configurare un criterio di livello 7.
• I flussi DNS e le metriche vengono acquisiti solo quando viene applicato un criterio di rete FQDN (Cilium Fully Qualified Domain Name). Per altre informazioni, vedere Configurare un criterio FQDN.

Compromessi nelle aggregazioni:

• L'aggregazione dei log di flusso non conserva i singoli timestamp del flusso, gli indirizzi IP per pod o i campi ad alta cardinalità come URL HTTP e nomi di query DNS. Usare i log su richiesta per l'analisi per flusso.

Archiviazione e piattaforma:

• Il file locale host in /var/log/acns/hubble/ è limitato a 50 MB per nodo e ruota automaticamente. Se è necessaria la conservazione a lungo termine, abilitare Monitoraggio di Azure (scelta consigliata) o inoltrare il file al proprio servizio di registrazione.
• Il piano tabella log ausiliario non è supportato.

Tariffazione

Per altre informazioni sui prezzi, vedere Servizi di rete dei contenitori avanzati - Prezzi.

Contenuti correlati

• Configurare i log di rete dei contenitori
• Servizi di rete avanzati per AKS
• Osservabilità della rete dei container in servizi di rete avanzati dei container
• Sicurezza di rete dei contenitori in Advanced Container Networking Services