Docker et Portainer

Transformez Container Logs en tables interrogeables.

Chaque conteneur exécuté par le daemon écrit un journal. Interrogez-les tous à la fois — en récupérant le véritable nom du conteneur, son image et son service Compose, plutôt qu’un répertoire rempli d’identifiants de 64 caractères.

Utilisez les résultats dans Excel, Google Sheets, les outils d'IA et vos applications via l'API REST Database.

Tous les types de connecteurs sont disponibles avec le forfait gratuit. Commencez avec 2 sources de données et 1 agent.

Connectez Container Logs gratuitementDétails de connexion
Journaux de conteneursFichiers lus là où ils se trouvent
Au sein de votre réseauAgent de réseau Query Streams

Lisez, organisez et interrogez les données sur votre machine.

Requêtes en lecture seule · connexion sortante
ExcelGoogle SheetsVotre IAVos applications

Les fichiers sources restent en place. Vos outils reçoivent les résultats des requêtes.

Source → agent → résultats autorisés

Query Streams transforme les journaux json-file de Docker, les exports de docker logs que vous enregistrez manuellement et le journal du serveur Portainer en tables SQL en temps réel, consultables depuis Microsoft Excel, Google Sheets, les assistants IA via MCP, l’API REST et Power BI. Le problème difficile qu’il résout est celui de l’identité : sur le disque, ces fichiers portent le nom de l’ID du conteneur. L’agent retrouve donc pour chacun son véritable nom, son image et son service Compose avant d’insérer les lignes. Rien n’est téléversé : l’agent lit les fichiers sur l’hôte et seuls les résultats des requêtes quittent votre réseau.

  • Les véritables noms des conteneurs, pas leurs ID
  • Image et service Compose pour chaque ligne
  • stdout et stderr restent distincts

Connectez Container Logs avec les paramètres appropriés.

Laissez la connexion sur le Network Agent. Voici les détails propres à Container Logs.

Dossier
Le répertoire des journaux du daemon sur l’hôte du conteneur, ou un dossier contenant des journaux exportés
Sources
Journaux Docker json-file, exports de docker logs enregistrés et journal du serveur Portainer
Identité
Nom du conteneur, image et service Compose résolus à partir du daemon, afin que les lignes ne soient pas indexées par un ID de 64 caractères
Rotation
Suivi des rotations du daemon, ainsi que des dix modèles de rotation nommés pour les fichiers exportés
Lignes non reconnues
Conservées telles quelles dans events_raw_lines, jamais supprimées
Identifiants
Aucun : l’agent lit les fichiers sur l’hôte, là où ils se trouvent
dialecte SQL
DuckDB : SQL standard, aucune spécificité des conteneurs à apprendre

L’agent lit les fichiers journaux déjà écrits par le daemon. Il ne s’attache pas aux conteneurs, ne maintient pas le socket du daemon ouvert pour diffuser les journaux et n’écrit jamais lui-même dans ces fichiers ni ne les fait tourner. Ainsi, un connecteur laissé en fonctionnement ne peut pas modifier le comportement de l’hôte.

Conçu pour le fonctionnement de Container Logs.

Le plus difficile, c’est l’identité, pas l’analyse

Le pilote json-file de Docker écrit les journaux de chaque conteneur dans un répertoire nommé d’après son ID de 64 caractères. Analyser le JSON est trivial ; savoir de quel conteneur il s’agit ne l’est pas, et c’est ce qui rend la table exploitable.

  • Chaque ligne contient le véritable nom du conteneur, son image et son service Compose, résolus à partir du daemon au lieu d’être déduits du chemin.
  • Ainsi, « les erreurs du service api ce matin » se traduit par une clause WHERE, et non par une table de correspondance à maintenir manuellement.
  • Le flux est également conservé, afin que stdout et stderr restent différenciables au lieu d’être fusionnés dans une seule colonne de texte.
  • Un conteneur supprimé conserve les lignes qu’il a déjà produites : son historique ne disparaît pas avec lui.
-- Quels services sont les plus bruyants en ce moment
SELECT   service, stream, COUNT(*) AS lines
FROM     fileset.events
WHERE    stream = 'stderr'
GROUP BY service, stream
ORDER BY lines DESC

Trois éléments, pas un seul

Les journaux json-file du daemon constituent l’essentiel, mais ce ne sont pas les seuls journaux de conteneurs qu’il vaut la peine d’interroger : un export de docker logs enregistré manuellement a un format différent, et Portainer écrit son propre journal serveur. Les trois disposent de profils : vous choisissez donc ce que vous lisez au lieu d’espérer qu’un seul analyseur puisse tout traiter.

Les formats et le comportement, en détail.

Ouvrez la référence dont vous avez besoin pour Container Logs.

Un dossier de journaux de conteneurs devient une table.
La grande idée

Un dossier de journaux de conteneurs devient une table.

Query Streams lit les fichiers déjà écrits par le daemon, fixe leur format et fournit des colonnes typées, avec le nom du conteneur indiqué à côté de chaque ligne. Pas de sidecar, pas de pipeline d’expédition, pas d’index à maintenir — et une ligne que l’analyseur ne peut pas lire est conservée sous forme de ligne, avec une explication, au lieu d’être silencieusement ignorée.

Dossier journalsur l'hôte
a3f9c1…-json.logDocker
Dockershopfront-stack_api.logexporter
portainer.logPortainer

Rotations, archives compressées et fichiers relus : tout est pris en charge

noisy-containers.sqlSQL
SELECTIONNER application, service_composer,
       compter(*) AS lignes
DE   ensembles de fichiers.événements
OÙ  flux = 'stderr'
GROUPE PAR application, service de composition
ORDER BY lignes DESC
Résultatstderr par conteneur
applicationservicelignes
API de vitrineAPI1,284
employé de magasintravailleur417
vitrine-webweb62
cache de la façade de la boutiquecache3

Intégrez-la à la base de données de votre application dans la même requête.

Fichiers que le démon écrit déjà, désormais un tableau sur lequel vous pouvez générer des rapports.

Deux outils, trois formats, pas de side-car
Sources

Deux outils, trois formats, pas de side-car

Chaque fiche indique les fichiers exacts lus par Query Streams et leur emplacement. Il n’est pas nécessaire de modifier votre pilote de journalisation pour que cela fonctionne — fichier json est la valeur par défaut de Docker, et c'est la valeur par défaut qui est prise en charge.

Journaux de conteneurs pris en charge

3 formats · 2 outils
Logo Docker - Query Streams lit les journaux de conteneurs Docker au format JSON et exporte les journaux Docker. Dockerpilote de journalisation de fichiers JSON
  • Un {"log","stream","time"} une enveloppe par ligne, écrite par le démon
  • Le nom du conteneur provient de celui que Docker fournit lui-même config.v2.json à côté de la bûche
  • Projet/service Image et Compose s'accompagnent comme des colonnes
  • Généralement /var/lib/docker/containers
  • Ajoute ; rotations numérotées et .gz suivi
Logo Docker - Query Streams lit les journaux Docker --timestamps exportés fichiers Dockerexport des journaux Docker
  • Fichiers que vous avez enregistrés avec docker logs --timestamps
  • Un horodatage RFC 3339 à la nanoseconde, suivi de la ligne propre au conteneur
  • Les lignes de bannières de conteneur sont ignorées par déclaration, et non par hasard.
  • N'importe quel dossier dans lequel vous conservez les exportations
  • Un fichier par service ; le nom provient de la racine du fichier
Logo Portainer - Query Streams lit les journaux de la console zerolog du serveur Portainer PortainerJournal du serveur, console zerolog
  • portainer.log ou de la sortie propre au conteneur
  • Les codes de couleur ANSI sont supprimés avant l'analyse, donc un niveau est un niveau
  • Le clé=valeur La queue se transforme en colonnes ; le reste atterrit dans données
  • Les lignes au format différent du serveur de tunnel intégré sont également lues
  • Horodatage à la minute près, lu en UTC
Plus à venirCe sont les débuts, pas le plafond

De nouveaux formats de journaux de conteneurs sont ajoutés à chaque nouvelle version de l'Agent. Grâce à la mise à jour automatique des Agents, un format ajouté ultérieurement sera disponible dans votre connecteur sans intervention sur le serveur.

Les trois analyseurs ont été conçus et testés avec de véritables journaux de conteneurs : des journaux json-file, de volumineux exports issus d’un hôte Swarm et le journal serveur de Portainer CE 2.39.1. À savoir d’emblée : avec Docker Desktop pour Windows et Mac, les journaux json-file se trouvent dans sa machine virtuelle, à laquelle un Agent exécuté comme service ne peut pas accéder. Exportez-les avec journaux Docker Des conteneurs dans chaque région, des journaux lus là où ils se trouvent docker logs --timestamps et utilisez le deuxième profil.
Des conteneurs dans chaque région, les journaux lus là où ils se trouvent
Partout où il court

Des conteneurs dans chaque région, les journaux sont lus où ils s'assoient

Les conteneurs ne s’exécutent que rarement tous au même endroit. Un hôte au bureau, un cluster Swarm dans une région cloud, une machine dans un autre pays. Chaque emplacement exécute un Network Agent qui lit les fichiers journaux là où ils se trouvent déjà et ouvre une connexion sortante vers Query Streams. Du point de vue de votre pare-feu, il s’agit d’une connexion sortante ordinaire : rien à ouvrir et aucun VPN à configurer.

Siège social Un Agent couvre tout un site, pas un simple dossier : chaque format de journal que vous souhaitez lire à cet emplacement devient son propre connecteur File Set sur ce même Agent. La configuration habituelle consiste à avoir un Agent par emplacement. Le forfait Free exécute un seul Agent, et les forfaits payants en exécutent davantage. composez le numéro.
UE-Ouest Un cluster Swarm, un journaux Docker exporter par service composez le numéro.
États-Unis-Est Portainer gère une poignée d'hôtes, son propre journal de serveur à côté composez le numéro.

Trois connexions sortantes, un seul endroit pour les interroger — aucun port entrant, aucun VPN, aucun changement au pare-feu

Un agent par emplacement

L’Agent établit une seule connexion sortante chiffrée ; la requête sortante et les lignes renvoyées passent toutes deux par cette connexion. Pas de port entrant, pas de VPN, aucune modification du pare-feu à demander — et les identifiants restent dans votre réseau.

1 site = 1 agent = plusieurs connecteurs

Rien à ouvrir

attribue un nom à son propre Agent, afin qu’une seule instruction puisse lire un journal dans un pays et un autre journal dans un autre, puis renvoyer un résultat unique — ou joindre l’un ou l’autre à une base de données. Inclus dans les offres Business et Enterprise.

une seule connexion, dans les deux sens

Une requête sur plusieurs sites

Chaque source dans un requête fédérée 2 pays → 1 jeu de résultats

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

Ils se tiennent au courant

Les agents se mettent à jour automatiquement ; ainsi, un format de journal de conteneur ajouté dans une version ultérieure est déployé sur tous les sites sans qu'aucune connexion serveur ne soit nécessaire pour l'installer. C'est pourquoi la liste ci-dessus représente un point de départ plutôt qu'une liste figée.

De nouveaux formats arrivent avec l'Agent

Noms, horloges et codes couleur
La partie difficile

Noms, horloges et codes couleur

Un journal de conteneur n'est pas un fichier texte daté. Trois problèmes surviennent fréquemment lorsqu'on tente de le traiter comme des données ; ici, chacun est géré par déclaration plutôt que par conjecture.

Des noms, pas des identifiants hexadécimaux.

Docker nomme chaque dossier de journalisation d'après l'identifiant du conteneur, ce qui rend une requête groupée illisible. Query Streams lit l'enregistrement que Docker écrit à côté du journal et en extrait le nom réel, en conservant l'identifiant dans une colonne distincte.

L’horloge du daemon

Si un conteneur qui affiche son propre horodatage en secondes depuis l’époque Unix est pris au mot, son horodatage aboutit en 1970. L’heure de l’événement est celle de sa capture par le daemon ; l’horodatage propre au conteneur est conservé dans une colonne, sans être considéré comme fiable.

heure de l’enveloppe → event_time

Les enregistreurs de console écrivent directement les séquences d’échappement du terminal dans le journal. Elles sont supprimées avant l’analyse : le niveau est donc interprété comme un niveau, et non comme un niveau entouré de caractères d’échappement — les octets d’origine restent intacts.

Codes de couleur dans le fichier

codes d’échappement supprimés → level = INF

Pas un bloc de texte accompagné d’un horodatage. Chaque format est analysé en colonnes typées que vous pouvez directement filtrer, regrouper et agréger — et lorsque le conteneur consigne du JSON structuré, ses propres champs sont également dépliés en colonnes.

Rien ne compte deux fois

Chaque fichier est identifié par ses 4 premiers kilo-octets, ce qui permet de reconnaître un fichier pivoté comme identique plutôt que de le relire depuis le début. Une fenêtre de duplication glissante détecte le chevauchement lorsqu'un processus d'écriture relit sa fin.

Hachage de préfixe de 4 Ko · fenêtre de 20 000 enregistrements

Les colonnes que vous obtenez réellement
Le schéma

Les colonnes que vous obtenez réellement

, l’horodatage brut dont il a été extrait et le fichier d’où il provient. Chaque format ajoute sa colonne d’identité —

Logo Docker
journal du conteneur de fichiers JSONDémon Docker
fluxniveaubûcheronmessagehôteservicedonnées
Logo Docker
export des journaux DockerInterface de ligne de commande Docker
message
Logo Portainer
journal de la console zerologPortainer
niveaudemandeurmessageerreurdonnées

Chaque rangée contient également heure_événement, l’horodatage brut auquel il a été lu, et le fichier dont il provient. Chaque format ajoute sa colonne d’identification — application pour les fichiers JSON et Portainer, récipient pour une exportation — et les lignes json-file comportent en plus image, composer_project, composer_service et id_conteneurLe célibataire message colonne dans une exportation est un choix délibéré : la ligne propre au conteneur est conservée intégralement, plutôt que reconstituée par supposition.

Ce que cela ne fait pas délibérément

Ce que cela ne fait pas délibérément

Il ne s'agit pas d'un flux en temps réel. Query Streams lit les fichiers tels qu'ils se trouvent sur le disque lors de l'exécution de la requête ; une boucle de redémarrage apparaît donc sous forme de lignes et non comme un flux continu. Si vous avez besoin d'alertes en moins d'une seconde sur une ligne dès son affichage, un pipeline de journalisation est l'outil approprié.

La sortie d’un conteneur est libre, et cela entraîne une conséquence qu’il vaut mieux énoncer clairement : tout ce que votre application affiche se retrouve dans la table. Si elle journalise un jeton ou l’adresse e-mail d’un client, cette chaîne figure déjà dans le fichier journal et se retrouvera aussi dans la colonne. Il n’existe pas de correspondance d’en-têtes permettant de les exclure, comme pour un journal de serveur web : traitez la table obtenue avec exactement les mêmes précautions que le fichier.

Deux limites plus petites, nommées plutôt que cachées. Sur un journaux Docker exportation, la ligne propre au conteneur est conservée intégralement dans une seule message colonne ; l’analyse de cette ligne interne selon son propre format n’est pas encore implémentée. De plus, les attributs facultatifs que Docker peut ajouter au moyen d’une balise de journalisation ne sont reconnus que par leur forme : aucun conteneur du corpus capturé ne les utilisait, ce chemin est donc déclaré, mais pas validé.

Le reste suit la conception habituelle. L'agent se connecte en sortie et lit les fichiers ; rien n'est installé dans le conteneur, aucune donnée n'est écrite en arrière-plan, le socket Docker et l'API ne sont jamais utilisés, et l'accès est en lecture seule. La durée de rétention est de 30 jours par défaut et vous pouvez la modifier.

De la connexion à des résultats utiles.

  1. Installez le Network Agent sur l’hôte du conteneur, où il peut accéder au répertoire de journaux du démon.
  2. Pointez le connecteur vers ce répertoire. Le journal json-file de chaque conteneur est détecté, et vous pouvez restreindre la sélection à l’aide de motifs.
  3. L’agent associe chaque répertoire de 64 caractères au conteneur correspondant — nom réel, image et service Compose — pour que les lignes soient lisibles avant même d’écrire du SQL.
  4. Chaque ligne devient une ligne de table, avec son flux (stdout ou stderr) et l’horodatage du démon ; la rotation est suivie au fur et à mesure que le démon fait tourner les fichiers.
  5. Interrogez les données : les erreurs de tous les conteneurs à la fois, un service isolé, ou une comparaison avant et après un déploiement.

Mettez à profit les résultats de Container Logs.

Une seule connexion alimente vos feuilles de calcul, vos applications et vos outils d’IA. Accordez l’autorisation d’exécuter une requête enregistrée ; les destinataires voient les résultats autorisés, sans accès au SQL ni aux identifiants de connexion à la source.

Pour votre équipe, vos fournisseurs et vos partenaires

Container Logs vers Excel

Importez directement les résultats en temps réel de Container Logs dans une feuille de calcul et actualisez-les à la demande — Excel pour ordinateur, Excel Online, Microsoft 365.

Découvrir Excel

Container Logs vers Data Viewer

Partagez un résultat Container Logs en direct avec qui vous voulez — collègue, fournisseur ou partenaire — sous la forme d’une grille accessible par signet, qui récupère des données actualisées à chaque ouverture, sur téléphone, tablette ou ordinateur. Les destinataires voient les résultats, jamais le SQL ni les fichiers.

Fonctionnement du visualiseur de données

Pour les applications et les systèmes

API REST des journaux de conteneurs

Publiez une requête Container Logs sous forme de point de terminaison JSON authentifié, accessible à toute application, avec une spécification OpenAPI 3.1 et des collections Postman, Insomnia et Hoppscotch prêtes à l’emploi. Aucun port de base de données n’est ouvert.

Découvrir l’API REST

Container Logs vers Power BI

Collez le code Power Query M généré dans l’éditeur avancé de Power BI : le rapport récupère alors en direct les résultats de Container Logs via HTTPS — sans pilote ODBC ni ouverture de port de base de données.

Découvrir Power BI

Container Logs vers Anvil

Alimentez une application Python Anvil avec Container Logs via le point de terminaison REST, plutôt que d’intégrer des identifiants de base de données dans l’application.

Découvrir Anvil

Pour les outils d'IA

Serveur MCP Container Logs

Donnez à un assistant IA un accès en lecture seule à Container Logs et au schéma nécessaire pour rédiger du SQL correct — sans identifiants dans la conversation.

Découvrir MCP

Livré aux personnes

Reliez Container Logs au reste de vos données.

Rassemblez bases de données, API métier, fichiers et journaux dans une seule requête en lecture seule. Tous les connecteurs prennent en charge les requêtes fédérées.

Indiquez le nom des connexions et des tables. Query Streams gère les requêtes sur les sources et combine les résultats.

Découvrir les requêtes fédérées
Exemple de requête entre plusieurs sources
-- rien copié, rien fusionné, rien programmé
SELECTIONNER   c.region, COUNT(*) AS commandes, SUM(i.montant_dû) AS facturé
DE     containerlogs.fileset.orders1 f
JOINDRE     pg_crm.public.clients2      c ON c.id = f.customer_id
JOINDRE     facturation.stripe.factures3      i ON i.customer = c.stripe_id
GROUPE PAR région c.
ORDER BY facturé DESC;

Utilisez vos propres noms de connexions, de schémas, de tables et de colonnes.

Partagé par toute la famille de connecteurs.

Chaque connecteur de journaux vous fournit également

  • events — une ligne par ligne analysée, avec son horodatage, les champs nommés par la grammaire et _source_file, qui indique le fichier d’origine.
  • events_raw_lines — les lignes non reconnues par la grammaire, conservées telles quelles plutôt que supprimées. Ainsi, même un format imprévu reste exploitable pour répondre à vos questions.
  • files_current et files_events — l’inventaire actuel et la piste d’audit : les éléments apparus, ceux qui ont subi une rotation, ceux qui ont disparu et ceux qui ont été mis en attente, avec le nom du fichier et la raison.
  • La rotation est prise en charge, et non contournée : dix modèles de rotation nommés, plus les fichiers sans rotation, pour que le journal d’hier et son archive compressée appartiennent à la même table que celui d’aujourd’hui.

Bon à savoir

  • Lecture seule, garantie : une instruction à la fois, SELECT et opérations similaires uniquement. Nous n’écrivons jamais dans vos journaux, ne les déplaçons pas, ne les faisons pas tourner et ne les tronquons pas.
  • Aucune donnée n’est téléversée : les lignes sont analysées et mises en cache de manière chiffrée sur votre propre machine, à côté de l’agent. Seul le résultat d’une requête quitte votre réseau.
  • Seuls les nouveaux octets sont lus : l’agent reprend là où il s’était arrêté dans chaque fichier au lieu de le relire. Ainsi, un journal très actif n’entraîne pas de surcoût chaque jour.
  • Le dialecte SQL est DuckDB — le même SQL que celui que vous utiliseriez avec n’importe quel autre connecteur.

Questions sur Container Logs

Où puis-je utiliser les résultats des requêtes Container Logs ?

Utilisez les résultats de Container Logs dans Excel, Google Sheets et Data Viewer, dans vos applications via l’API REST Database, et dans les outils d’IA via MCP ou Nova. Les résultats enregistrés alimentent également les destinations Automation prises en charge, les rapports et les alertes. La disponibilité des destinations et les quotas dépendent de votre forfait.

Dois-je ouvrir un port entrant pour Container Logs ?

Non. Installez Network Agent sur une machine qui peut accéder à Container Logs. L’agent se connecte à Query Streams par une connexion sortante ; aucun port entrant ni VPN n’est nécessaire. Votre source doit toutefois autoriser la connexion de la machine de l’agent, conformément à ses propres règles d’accès.

Mes fichiers Container Logs sont-ils téléversés ?

Le Network Agent lit les fichiers là où ils se trouvent et conserve son cache sur la machine de l’agent. Les fichiers source ne sont ni téléversés, ni déplacés, ni réécrits. Seuls les résultats de requête demandés quittent votre réseau via la connexion chiffrée sortante.

De quoi ai-je besoin pour connecter Container Logs ?

Dossier : répertoire de journaux du démon sur l’hôte du conteneur, ou dossier contenant des journaux exportés. Sources : journaux Docker json-file, exportations docker logs enregistrées et journal serveur de Portainer. Identité : nom du conteneur, image et service Compose résolus depuis le démon ; les lignes ne sont donc pas identifiées par un ID de 64 caractères. Rotation : suivie au fur et à mesure que le démon fait tourner les fichiers, avec en plus les dix motifs de rotation nommés pour les fichiers exportés.

Puis-je joindre Container Logs à d’autres sources connectées ?

Oui. Les requêtes fédérées prennent en charge tous les types de connecteurs, notamment les bases de données, les API métier, les fichiers et les journaux. Indiquez le nom des connexions et des tables dans une seule requête en lecture seule. Query Streams traduit au besoin les portions destinées aux sources et combine les résultats. Découvrez le fonctionnement des requêtes fédérées.

Dois-je changer mon pilote de journalisation Docker ?

Non. fichier json C’est le pilote par défaut de Docker et le pilote pris en charge. Si vous n’avez jamais configuré la journalisation, les fichiers sont déjà présents et dans le bon format.

Si vous avez changé de conducteur, le docker logs --timestamps L'exportation est la voie d'entrée : elle fonctionne quel que soit le pilote, car l'interface de ligne de commande lit à travers le démon.

Comment le système connaît-il le nom du conteneur plutôt que son seul identifiant ?

Docker enregistre le nom du conteneur dans le même dossier que le journal. Query Streams lit ce nom et l'utilise comme colonne d'identité, tandis que l'image, le projet Compose et le service sont conservés dans des colonnes adjacentes. L'identifiant du dossier (64 caractères) est conservé. id_conteneur, donc rien n'est perdu.

Si cet enregistrement est manquant, illisible ou ne contient pas de nom, le nom du dossier est utilisé à la place et l’analyse compte le nombre de fois où cela s’est produit : le recours à une valeur de remplacement est donc visible sous forme d’un nombre consultable, et non d’une substitution silencieuse.

J'utilise Docker Desktop pour Windows ou Mac. Est-ce que cela fonctionne ?

Je ne m'attaque pas directement aux journaux au format JSON. Docker Desktop les conserve dans sa propre machine virtuelle, et un agent exécuté en tant que service sur l'hôte ne peut pas y accéder.

La solution consiste à utiliser le profil d'exportation : docker logs --timestamps <conteneur> redirigé vers un fichier dans n’importe quel dossier lisible par l’Agent. Il s’agit d’un format pris en charge à part entière, et non d’un contournement : c’est la même méthode que celle qu’utilisent déjà les personnes qui souhaitent conserver une copie du journal après la suppression d’un conteneur.

Est-ce en temps réel ?

La lecture se fait à la demande, et non en continu. Les fichiers sont lus tels quels au moment de l’exécution de la requête : les nouvelles lignes apparaissent au fur et à mesure que vos conteneurs les écrivent et que le fichier est détecté — pas selon un calendrier nocturne fixe, mais pas non plus en suivi en temps réel.

Pour poser une question portant sur les dernières semaines et couvrant chaque conteneur, et obtenir la réponse dans un tableur, cette forme est utile et nécessite considérablement moins de machines qu'une pile de bûches.

Et Kubernetes ou Podman ?

Aucun des deux ne possède aujourd'hui de profil propre, et nous préférons le dire plutôt que de sous-entendre une couverture. Ce qui s'applique, c'est le format d'exportation : le profil est lié à la forme exacte. docker logs --timestamps écritures — un horodatage à la nanoseconde au format RFC 3339, une espace, puis la ligne propre au conteneur, à raison d’un fichier par service. Les outils qui écrivent dans ce même format peuvent le lire.

La méthode la plus fiable pour vérifier vos propres fichiers est d'effectuer un test de connexion, qui vous indique ce qu'il a reconnu avant toute action de votre part.

Mes conteneurs enregistrent du JSON. Est-ce que je récupère leurs champs sous forme de colonnes ?

Oui, pour les journaux json-file. L’enveloppe du démon est retirée, puis le JSON propre au conteneur qu’elle contient est réparti en colonnes — niveau, logger, message, hôte et service lorsqu’ils sont présents. Tout élément qui ne correspond pas à une colonne nommée est conservé dans une données La colonne n'est pas supprimée, ce qui permet d'interroger un champ inhabituel.

Le seul élément qui n’est pas extrait du JSON du conteneur est l’horodatage. Il provient du démon, car l’horodatage propre à une application peut être dans n’importe quel format et une erreur d’interprétation décalerait silencieusement la ligne dans le temps.

Que se passe-t-il si l'analyseur syntaxique ne peut pas lire une ligne ?

Elle est conservée, non supprimée. Une ligne ne respectant pas le format défini est conservée comme une ligne brute avec une explication, de sorte qu'une entrée malformée ou un changement de format inattendu apparaisse comme une information visible et exploitable, et non comme une lacune silencieuse dans vos données.

Intégrez Container Logs à vos processus de travail.

Commencez avec l’offre Free : tous les types de connecteurs, 2 sources de données et 1 Network Agent. Ajoutez les quotas de votre offre à mesure que vos besoins évoluent.

Obtenez le forfait gratuitVoir les quotas des offres