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.
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.
a3f9c1…-json.logDocker
shopfront-stack_api.logesportare
portainer.logPortatoreRotazioni, archivi compressi e file riletti: gestiti
SELEZIONARE app, compose_service,
contare(*) AS linee
DA set di file.eventi
DOVE flusso = 'stderr'
GRUPPO PER app, compose_service
ORDINATO DA linee DESCAggiungilo al database della tua applicazione nella stessa query
File che il demone scrive già, ora una tabella su cui puoi creare report
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.jsonaccanto al tronco - Immagine e composizione del progetto/servizio durante il percorso come colonne
- Generalmente
/var/lib/docker/containers - Aggiunge; rotazioni numerate e
.gzseguito
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.logo l'output del contenitore stesso- I codici colore ANSI vengono rimossi prima dell'analisi, quindi un livello è un livello
- IL
chiave=valorela coda diventa colonne; il resto atterra indati - Le linee di forma diversa del server tunnel incorporato vengono lette anche
- I timestamp con risoluzione al minuto si leggono come UTC
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.
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.
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.
log di Docker esportazione per servizio
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
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
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.
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.
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.
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 ExcelLog 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 SheetsServer 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 MCPAPI 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 RESTRegistri 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 AirtableLog 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 BaserowRegistri 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 SeaTableRegistri 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 SmartsheetLog 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 AnvilLog 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 BIAvvisi 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 reportCiò 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.
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.
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.
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












