Logo Container Logs

Docker e Portainer Nuovo

Collegare Registri dei container per Excel, Fogli e IA

Docker scrive un log per ogni container: interrogali tutti contemporaneamente. Il file json registra ciò che il demone scrive, il log di Docker Esportazioni salvate manualmente e il log del server di Portainer. Puntando Query Streams sulla cartella, ogni riga diventa una riga a sé stante, contenente il nome reale del container, la sua immagine e il suo servizio Compose, invece di una directory piena di ID a 64 caratteri.

1connessione
0porti in entrata
sola letturaimposto
3 formati di log del contenitore Docker · Portainer Denominato in base al contenitore, all'immagine e al servizio. Sola lettura · nulla installato nel contenitore
La grande idea

Una cartella contenente i log dei container diventa un'unica tabella.

Query Streams legge i file che il demone ha già scritto, ne blocca il formato e fornisce colonne tipizzate con il nome del contenitore accanto a ogni riga. Nessun sidecar, nessuna pipeline di distribuzione, nessun indice da gestire: una riga che il parser non riesce a leggere viene conservata come riga con una motivazione, anziché essere ignorata silenziosamente.

Cartella di registrosull'host
a3f9c1…-json.logDocker
Dockershopfront-stack_api.logesportare
portainer.logPortatore

Rotazioni, archivi compressi e file riletti: gestiti

noisy-containers.sqlSQL
SELEZIONARE app, compose_service,
       contare(*) AS linee
DA   set di file.eventi
DOVE  flusso = 'stderr'
GRUPPO PER app, compose_service
ORDINATO DA linee DESC
Risultatostderr per container
appserviziolinee
API della vetrinaAPI1,284
commesso/alavoratore417
sito web della vetrinaweb62
cache della vetrinacache3

Aggiungilo al database della tua applicazione nella stessa query

File che il demone scrive già, ora una tabella su cui puoi creare report

Sorgenti

Due strumenti, tre formati, senza sidecar

Ogni scheda indica i file esatti che Query Streams legge e la loro posizione. Non è necessario modificare il driver di logging per far funzionare questa funzionalità. file json è l'impostazione predefinita di Docker, e l'impostazione predefinita è quella supportata.

Log dei container supportati

3 formati · 2 strumenti
Dockerdriver di registrazione file json
  • Uno {"log","stream","time"} busta per riga, scritta dal demone
  • Il nome del container deriva da quello di Docker config.v2.json accanto al tronco
  • Immagine e composizione del progetto/servizio durante il percorso come colonne
  • Generalmente /var/lib/docker/containers
  • Aggiunge; rotazioni numerate e .gz seguito
Dockeresportazione dei log di Docker
  • File salvati con log di docker --timestamps
  • Un timbro RFC 3339 in nanosecondi, quindi la linea propria del contenitore
  • Le righe relative ai banner dei container vengono omesse per dichiarazione, non per caso.
  • Qualsiasi cartella in cui conservi i file esportati
  • Un file per servizio; il nome deriva dalla radice del file
PortatoreRegistro del server, console zerolog
  • portainer.log o l'output del contenitore stesso
  • I codici colore ANSI vengono rimossi prima dell'analisi, quindi un livello è un livello
  • IL chiave=valore la coda diventa colonne; il resto atterra in dati
  • Le linee di forma diversa del server tunnel incorporato vengono lette anche
  • I timestamp con risoluzione al minuto si leggono come UTC
Altro in arrivoQuesti sono l'inizio, non il limite.

Con ogni nuova versione dell'Agent vengono aggiunti nuovi formati di log per i container. Poiché gli Agent si aggiornano automaticamente, un formato aggiunto successivamente verrà visualizzato nel connettore senza che sia necessario accedere al server.

Tutti e tre i parser sono stati costruiti e testati su log di container reali: log in formato json, log di grandi dimensioni log di Docker esporta da un host Swarm e dal log del server di Portainer CE 2.39.1. Una cosa da sapere in anticipo: su Docker Desktop per Windows e Mac i log in formato json risiedono all'interno della macchina virtuale, dove un agente in esecuzione come servizio non può raggiungerli. Esportali con log di docker --timestamps e utilizzare il secondo profilo.
Ovunque funzioni

Contenitori in ogni regione, registri letti dove siedono

Raramente i container vengono eseguiti tutti nello stesso luogo. Un host in ufficio, un cluster Swarm in una regione cloud, un singolo server in un altro paese. In ogni sede è in esecuzione un Network Agent che legge i file di log nella posizione in cui si trovano già e si connette a Query Streams. Per il firewall si tratta di una normale connessione in uscita: non c'è nulla da aprire e nessuna VPN da configurare.

Direzione Un host Docker su disco locale, log in formato json nella cartella del demone chiama in uscita
eu-ovest Un cluster di sciami, uno log di Docker esportazione per servizio chiama in uscita
Stati Uniti orientali Portainer gestisce una manciata di host, il proprio registro server insieme chiama in uscita

Tre connessioni in uscita, un unico punto per interrogarle: nessuna porta in entrata, nessuna VPN, nessuna modifica al firewall.

Un agente per sede

Un agente gestisce un intero sito anziché una singola cartella: ogni formato di log desiderato diventa un connettore File Set dedicato su quello stesso agente. La configurazione standard prevede un agente per ogni posizione. Il piano gratuito esegue un singolo agente, mentre i piani superiori ne eseguono di più.

1 sito = 1 agente = molti connettori

Niente da aprire

L'agente stabilisce una connessione in uscita crittografata, e sia la richiesta in uscita che le righe di risposta viaggiano attraverso di essa. Nessuna porta in entrata, nessuna VPN, nessuna modifica al firewall da richiedere: le credenziali rimangono all'interno della rete.

un collegamento, in entrambe le direzioni

Una singola query tra i siti

Ogni fonte in un query federata Assegna un nome al proprio agente, in modo che una singola istruzione possa leggere un registro in un paese e un registro in un altro e restituire un unico risultato, oppure unire uno dei due a un database. Incluso nelle versioni Business ed Enterprise.

2 paesi → 1 set di risultati

Si tengono aggiornati

Gli agenti si aggiornano automaticamente, quindi un formato di log del container aggiunto in una versione successiva raggiunge ogni sito senza che nessuno debba accedere a un server per installarlo. Questo è ciò che rende l'elenco precedente un punto di partenza piuttosto che un elenco fisso.

nuovi formati arrivano con l'Agente

La parte difficile

Nomi, orologi e codici colore

Il log di un container non è un file di testo con una data. Tre cose in genere non funzionano quando si cerca di trattarlo come un dato, e ognuna di esse viene gestita qui tramite una dichiarazione anziché per tentativi.

Nomi, non ID esadecimali

Docker assegna a ciascuna cartella di log il nome corrispondente all'ID del container, il che rende illeggibile una query raggruppata. Query Streams legge il record che Docker scrive accanto al log e ne estrae il nome reale, mantenendo l'ID come colonna a sé stante.

a3f9c1…-json.log → app = shopfront-api

L'orologio del demone

Un contenitore che stampa il proprio timestamp in secondi epoch atterra nel 1970, se ci si crede. L'ora dell'evento è l'ora di cattura del demone; il timestamp del contenitore stesso viene conservato come colonna anziché essere considerato attendibile.

tempo dell'inviluppo → tempo_evento

Codici colore nel file

I logger della console scrivono le sequenze di escape del terminale direttamente nel log. Queste vengono rimosse prima dell'analisi, quindi un livello viene letto come un livello e non come un livello racchiuso tra caratteri di escape, e i byte originali rimangono inalterati.

codici di escape rimossi → livello = INF

Nulla è stato contato due volte

Ogni file viene identificato tramite un'impronta digitale costituita dai suoi primi 4 KB, in modo che un file ruotato venga riconosciuto come lo stesso file anziché essere letto nuovamente dall'inizio. Una finestra di duplicazione scorrevole cattura la sovrapposizione quando un processo di scrittura riproduce la sua parte finale.

Hash con prefisso di 4 KB · Finestra di 20.000 record

Lo schema

Le colonne che ottieni effettivamente

Non si tratta di un blocco di testo con un timestamp accanto. Ogni formato viene analizzato e suddiviso in colonne tipizzate che è possibile filtrare, raggruppare e aggregare direttamente; inoltre, laddove un contenitore registri JSON strutturato, anche i suoi campi vengono scomposti in colonne.

Logo Docker
registro del contenitore del file jsondemone Docker
flussolivelloregistratoremessaggioospiteserviziodati
Logo Docker
esportazione dei log di DockerDocker CLI
messaggio
Logo del trasportatore
registro della console zerologPortatore
livellochiamantemessaggioerroredati

Ogni fila trasporta anche tempo_evento, il timbro grezzo da cui è stato letto e il file da cui proviene. Ogni formato aggiunge la sua colonna identificativa — app per file json e Portainer, contenitore per un'esportazione — e le righe del file json trasportano inoltre immagine, compose_project, servizio_di_composizione e container_id. Il singolo messaggio La colonna in un'esportazione è una scelta deliberata: la riga del contenitore viene mantenuta intera anziché essere dedotta per tentativi.

Un collegamento, ogni superficie

Dove possono essere archiviati i dati di log del tuo container

I file di log non sono un vicolo cieco. Collega la cartella una sola volta e la stessa connessione di sola lettura alimenterà tutte le superfici supportate da Query Streams: nessuna seconda configurazione, nessuna seconda copia dei dati e nessun trattamento diverso rispetto a un connettore di database.

Supportato

Log dei container in Excel

Microsoft Excel · Componente aggiuntivo di Excel

Importa i risultati dei log dei container in tempo reale direttamente in un foglio di lavoro e aggiornali su richiesta: Excel per desktop, Excel Online, Microsoft 365.

Come funziona Excel
Supportato

Log dei container su Fogli Google

Componente aggiuntivo Fogli

Esegui una query di log del contenitore salvata dalla barra laterale e trascina le righe nel foglio. I collaboratori che condividono il file possono aggiornarlo autonomamente.

Come funziona Google Sheets
Supportato

Server MCP dei log dei contenitori

Client Claude, Cursor e MCP · Server MCP

Concedi a un assistente IA l'accesso in sola lettura al log del container con lo schema necessario per scrivere query SQL corrette, senza fornire credenziali nella chat.

Come funziona MCP
Supportato

API REST dei log dei contenitori

Endpoint dell'HT

Pubblica una query di log del container come endpoint JSON autenticato che qualsiasi applicazione può richiamare, con una specifica OpenAPI 3.1 e raccolte predefinite per Postman, Insomnia e Hoppscotch. Non viene aperta alcuna porta del database.

Come funziona un'API REST
Supportato

Registri dei container su Airtable

Piattaforma di automazione

Sincronizza le righe del log del container in una base Airtable a intervalli regolari, oppure recuperale tramite uno script di automazione di Airtable.

Come funziona Airtable
Supportato

Log dei container su Baserow

Piattaforma di automazione

Alimenta una tabella Baserow dai log del container tramite l'endpoint REST, sia in locale che nel cloud Baserow.

Come funziona Baserow
Supportato

Registri dei container per SeaTable

Piattaforma di automazione

Mantieni aggiornata la base di SeaTable con i dati di log dei container senza esportare un file o esporre il database.

Come funziona SeaTable
Supportato

Registri dei container in Smartsheet

Piattaforma di automazione

Trasferisci i risultati dei log dei container in una griglia Smartsheet in modo che i piani e i report leggano dal sistema di origine e non dall'esportazione della settimana precedente.

Come funziona Smartsheet
Supportato

Log dei container per Anvil

Anvil Works · Piattaforma per app

Esegui il backup di un'app Anvil Python con log del container tramite l'endpoint REST anziché incorporare le credenziali del database nell'app.

Come funziona Anvil
Supportato

Log dei container in Power BI

Power Query M

Incolla la query Power Query M generata nell'editor avanzato di Power BI e il report leggerà i risultati del log del container in tempo reale tramite HTTPS, senza driver ODBC né porte di database aperte.

Come funziona Power BI
Supportato

Avvisi e report sui log dei container

Slack · Discord · Email · Webhook

Imposta una query di log del container su una pianificazione e fai in modo che le righe vengano recapitate a Slack, Discord, via e-mail o tramite un webhook firmato, oppure trattieni il messaggio finché il numero di righe, la soglia o la variazione percentuale non superano il valore da te impostato.

Come funzionano gli avvisi e i report
La scheda degli avvisi è quella che merita una seconda occhiata per i container: una query pianificata sul conteggio degli errori non richiede che nessuno tenga d'occhio un terminale, quindi un ciclo di riavvio raggiunge Slack autonomamente. Le guide dettagliate specifiche per i log non sono ancora state scritte: le pagine collegate descrivono il funzionamento di ciascuna interfaccia.

Ciò che questo deliberatamente non fa

Non si tratta di un flusso di dati in tempo reale. Query Streams legge i file così come sono sul disco quando si esegue la query, quindi un ciclo di riavvio viene visualizzato come righe anziché come un flusso da monitorare. Se è necessario ricevere avvisi con una precisione inferiore al secondo su una riga durante la stampa, una pipeline di log è lo strumento più adatto.

L'output di un container è a formato libero, e questo ha una conseguenza che vale la pena di chiarire: tutto ciò che la tua applicazione stampa finisce nella tabella. Se registra un token o un indirizzo email di un cliente, quella stringa è già presente nel file di log e sarà presente anche nella colonna. Non esiste una mappatura dell'intestazione da escludere come nel caso dei log di un server web: tratta la tabella risultante con la stessa cura con cui tratteresti il file.

Due limiti più piccoli, denominati anziché nascosti. Su un log di Docker esporta la linea propria del contenitore viene mantenuta intera in uno messaggio colonna; la rielaborazione di quella riga interna secondo il suo formato non è ancora stata implementata. Inoltre, gli attributi opzionali che Docker può allegare a un tag di logging vengono riconosciuti solo in base alla forma: nessun container nel corpus acquisito li ha utilizzati, quindi quel percorso è dichiarato, non dimostrato.

Il resto segue il design standard. L'agente si connette in uscita e legge i file; nulla viene installato nel container, nulla viene scritto, il socket Docker e l'API non vengono mai utilizzati e l'accesso è in sola lettura. Il campo di conservazione predefinito è di 30 giorni per questa configurazione e può essere modificato dall'utente.

Come funziona

Tre passaggi, e non viene installato nulla in un container.

01

Indica la cartella dei log

Concedi all'agente Query Streams l'accesso in lettura alla posizione in cui vengono già archiviati i log. /var/lib/docker/containers su un host Docker, in una cartella di esportazioni salvate o in una condivisione su cui le raccogli.

02

Riconosce il formato

Query Streams identifica il formato dal contenuto delle righe, non dal nome del file; pertanto, una copia rinominata viene comunque letta correttamente e un file che non corrisponde al formato predefinito viene archiviato con una motivazione, anziché corrompere la tabella.

03

Interrogalo o unisciti a esso

Esegui query SQL dal portale, importale direttamente in Microsoft Excel o Fogli Google, oppure utilizza una query federata per unire i log dei container agli utenti e agli ordini presenti nel database della tua applicazione, il tutto con un'unica istruzione.

FAQ sul registro dei contenitori

Devo cambiare il driver di logging di Docker?

NO. file json è il driver predefinito di Docker ed è quello supportato. Se non hai mai configurato il logging, i file sono già presenti e nel formato corretto.

Se sei passato a un driver diverso, log di docker --timestamps L'esportazione è il percorso di input: funziona indipendentemente dal driver, perché la CLI legge attraverso il demone.

Come fa a conoscere il nome del contenitore e non solo il suo ID?

Docker scrive il proprio record di un container nella stessa cartella del log. Query Streams legge il nome da quel file e lo usa come colonna di identità, con l'immagine e il progetto e servizio Compose mantenuti come colonne accanto. L'ID della cartella di 64 caratteri viene mantenuto come container_id, quindi non si perde nulla.

Se il record è mancante, illeggibile o non ha un nome, viene utilizzato il nome della cartella e la scansione conta quante volte si è verificato questo caso: in questo modo, l'eventuale soluzione alternativa viene visualizzata come un numero consultabile, non come una sostituzione silenziosa.

Utilizzo Docker Desktop per Windows o Mac. Funziona?

Non direttamente sui log in formato JSON. Docker Desktop li conserva all'interno della propria macchina virtuale e un agente in esecuzione come servizio sull'host non può accedervi.

La soluzione è il profilo di esportazione: docker logs --timestamps <container> Il reindirizzamento avviene a un file, in qualsiasi cartella accessibile dall'agente. Si tratta di un formato supportato a tutti gli effetti, non di una soluzione alternativa: è lo stesso metodo già utilizzato per conservare una copia di un log dopo la chiusura di un container.

È in tempo reale?

Si tratta di un servizio on-demand, non in streaming. I file vengono letti così come sono al momento dell'esecuzione della query, quindi le nuove righe vengono visualizzate man mano che i container le scrivono e il file viene prelevato, non secondo una pianificazione fissa notturna, ma nemmeno in tempo reale.

Per porre una domanda relativa alle ultime settimane a tutti i contenitori e ottenere la risposta in un foglio di calcolo, questa è la forma utile e richiede molta meno attrezzatura rispetto a una catasta di tronchi.

Che ne dici di Kubernetes o Podman?

Nessuno dei due ha un profilo proprio al momento, e preferiamo dirlo piuttosto che sottintendere una copertura. Ciò che conta è il formato di esportazione: il profilo è associato alla forma esatta log di docker --timestamps scrive — un timestamp RFC 3339 in nanosecondi, uno spazio, poi la riga del contenitore stesso, un file per servizio. Gli strumenti che scrivono con la stessa struttura la leggono.

Il modo più affidabile per scoprirlo per i propri file è utilizzare il comando "Test connessione", che segnala ciò che ha rilevato prima di confermare qualsiasi operazione.

I miei container registrano file JSON. I loro campi vengono visualizzati come colonne?

Sì, per i log in formato json. L'involucro del demone viene spacchettato e il JSON del container al suo interno viene appiattito in colonne: livello, logger, messaggio, host e servizio, laddove presenti. Tutto ciò che non corrisponde a una colonna denominata viene mantenuto in un dati colonna anziché essere scartata, in modo che un campo insolito sia comunque interrogabile.

L'unico elemento non prelevato dal JSON del container è il timestamp. Questo proviene dal demone, perché il timestamp di un'applicazione può essere in qualsiasi formato e un errore in questo caso causerebbe silenziosamente uno spostamento temporale errato della riga.

Che succede se il parser non riesce a leggere una riga?

Viene mantenuta, non eliminata. Una riga che non corrisponde al formato predefinito viene conservata come riga grezza con una motivazione allegata, in modo che una voce non valida o una modifica di formato imprevista risulti visibile e interrogabile, anziché come una lacuna silenziosa nei dati.

I tuoi container stanno già parlando

Collega una cartella di log ed esegui la tua prima query in pochi minuti. Piano gratuito, nessuna carta di credito richiesta, niente installato in un container.

Sola lettura · solo connessione in uscita · i tuoi log rimangono sul tuo host