Outils logs & observabilité

Analyseur de logs AWSpour les logs CloudFront et ALB

Collez un log standard CloudFront ou un log d'accès ALB, laissez le format se détecter automatiquement (ou choisissez-le), puis cliquez sur « Analyser le log » pour obtenir un tableau filtrable.

Exemple :

Type de log

FiltresTraiter comme regex

Log d'accès

Tout se passe localement dans votre navigateur. Le texte du log n'est jamais envoyé, aucun compte AWS n'est requis.

Lignes analysées

Analysez un log pour voir les lignes ici.

Collez un log CloudFront ou ALB, ou chargez un exemple, puis cliquez sur « Analyser le log ».

CloudFront et ALB génèrent deux des logs d'accès les plus courants sur AWS, et aucun des deux ne se lit facilement à l'œil nu : les champs de CloudFront dépendent des colonnes choisies à l'activation de la journalisation, et ALB entasse plus de 30 valeurs séparées par des espaces sur une seule ligne, dont plusieurs entre guillemets. Que vous cherchiez à analyser les journaux CloudFront ou à décortiquer un log ALB, cet analyseur de logs AWS existe pour le moment où vous avez sous la main un extrait de l'un de ces logs — copié d'un ticket support, téléchargé depuis S3 ou extrait d'un export CloudWatch — et devez savoir quel edge location a servi une requête, quelle cible a renvoyé un 502, ou quelle IP cliente sollicite trop souvent un chemin, sans monter une requête Athena.

Pensé pour une lecture rapide de quelques centaines à quelques milliers de lignes, pas pour remplacer un pipeline d'analyse permanent. Tout se passe dans l'onglet du navigateur ; le texte du log n'est jamais envoyé, et aucun compte AWS ni accès S3 n'est nécessaire.

Pourquoi utiliser cet analyseur de logs AWS

Conçu autour de la façon dont ces deux formats AWS déclarent réellement leurs champs.

L'en-tête de CloudFront indique lui-même les colonnes

Un log standard CloudFront commence par les lignes #Version et #Fields, qui nomment chaque colonne dans l'ordre. Cet analyseur lit ces deux lignes plutôt que de supposer une disposition fixe : quand AWS livre un log avec plus de champs, le tableau s'agrandit tout seul, sans mise à jour de l'outil ni numéro de version à choisir.

Essayer avec l'exemple CloudFront Voir les règles de champs

Une ligne d'en-tête #Fields de CloudFront mappée directement sur les colonnes du tableau

Des statistiques propres à chaque format, pas un résumé générique

Pour CloudFront, vous obtenez une répartition du résultat de cache (Hit, Miss, RefreshHit, Error) et les edge locations les plus sollicitées — exactement ce qu'on vérifie quand un CDN se comporte bizarrement. Pour ALB, une répartition des actions exécutées et le nombre de requêtes où le code de statut du load balancer diffère de celui de la cible, souvent le premier signe d'un backend défaillant.

Voir le panneau de statistiques Lire les notes sur la confidentialité

Deux panneaux séparés pour le résultat de cache et l'écart de code de statut ELB/cible

D'un log AWS brut à un tableau filtrable

Analyser, filtrer et exporter en trois étapes.

Coller le log et laisser la détection automatique faire son travail

Collez un log standard CloudFront ou un log d'accès ALB. La détection automatique ne regarde que la première ligne non vide : un début en #Version: signifie CloudFront, un premier mot parmi http/https/h2/grpcs/ws/wss signifie ALB. Si aucun des deux ne correspond (par exemple si vous n'avez collé que des lignes de données sans en-tête), choisissez le type manuellement dans le menu plutôt que de deviner.

Choisir CloudFront manuellement sur un log sans en-tête #Version/#Fields n'échoue pas — l'outil bascule sur sa liste de champs CloudFront par défaut, qui couvre l'ensemble de champs actuel d'AWS
Les deux exemples intégrés se chargent avec leur format déjà présélectionné, chacun avec une ligne volontairement invalide pour voir comment une non-correspondance est signalée

Cliquer sur « Analyser le log » (ou Ctrl/Cmd+Entrée)

L'analyse ne se lance pas automatiquement pendant la saisie — ces logs comptent souvent des milliers de lignes, certaines avec plus de 30 champs, et refaire la correspondance à chaque frappe serait inutile. Cliquez une fois sur « Analyser le log », ou utilisez le raccourci clavier, et le tableau se remplit.

Changer le type de log ensuite ne relance pas l'analyse automatiquement ; l'ancien tableau reste visible mais s'estompe jusqu'à ce que vous cliquiez de nouveau sur « Analyser le log »

Filtrer et exporter

Les filtres par statut, chemin, IP cliente et (pour CloudFront) edge location s'appliquent instantanément aux lignes déjà analysées — inutile de recliquer sur « Analyser le log ». Le panneau de résumé sous le tableau se met à jour avec le filtre, y compris la répartition du résultat de cache ou des actions exécutées, ainsi que le total d'octets et la latence moyenne/maximale pour ce qui est actuellement affiché. Copiez ou téléchargez les lignes visibles en CSV, JSON ou texte brut.

Le filtre edge location n'apparaît que si le type de log est CloudFront ou Détection automatique — les logs ALB n'ont pas de champ équivalent, donc ce champ n'est pas affiché du tout plutôt que désactivé

Aller à l'analyseur

Ce que ce tableau apporte en plus du texte brut

Mappage de champs, quatre filtres et statistiques propres à chaque format, conçus pour dépanner un vrai log d'accès AWS.

Mappage de champs auto-descriptif pour CloudFront

Les noms de colonnes viennent directement de la ligne #Fields du log lui-même, si bien que le tableau correspond toujours exactement à la version du log collé, y compris un sous-ensemble de champs personnalisé choisi à l'activation.

Une correspondance de champs fixe et strictement additive pour ALB

ALB n'a pas de ligne d'en-tête, mais la documentation officielle d'AWS précise que les nouveaux champs sont toujours ajoutés à la fin. Cet analyseur mappe les tokens d'une ligne, par position, sur la liste complète des champs connus, et indique combien de champs connus ont réellement été trouvés — un log plus ancien avec moins de champs finaux reste donc analysé proprement, sans erreur.

Quatre filtres : statut, chemin, IP cliente, edge location

Restreignez le tableau à une plage de statuts ou un code exact, une sous-chaîne de chemin ou une regex, une sous-chaîne d'IP cliente, et — pour CloudFront — une sous-chaîne d'edge location, sans jamais réanalyser le log.

Répartitions du résultat de cache et des actions, plus les écarts de statut

Les lignes CloudFront sont résumées par x-edge-result-type (Hit, Miss, RefreshHit, Error et proches) ; les lignes ALB sont résumées par la valeur actions_executed séparée par des virgules, avec en plus un compteur de requêtes où les codes ELB et cible diffèrent.

Lignes invalides avec leur numéro

Une ligne dont le nombre de colonnes ne correspond pas au format détecté est listée avec son numéro de ligne (base 1) et son texte d'origine, pour qu'une poignée de lignes anormales ne disparaisse jamais silencieusement du décompte.

Export en CSV, JSON ou texte brut

Exporte exactement les lignes actuellement affichées par les filtres, avec les mêmes colonnes que le tableau, prêtes pour un tableur ou un autre outil.

Ce que cet analyseur lit, et ce qu'il ne lit pas

Le comportement exact concernant la détection des champs, les lignes invalides et les limites du périmètre, qui a peu de chances de changer.

CloudFront exige un nombre de colonnes exact, ALB au moins 13 tokens: Une ligne de données CloudFront n'est acceptée que si son nombre de colonnes séparées par des tabulations correspond exactement à la liste de champs active (depuis #Fields, ou la liste par défaut intégrée). Une ligne ALB doit avoir au moins 13 tokens séparés par des espaces — de quoi atteindre le champ request entre guillemets —, sinon elle est listée comme ligne invalide plutôt que devinée.
Les champs ALB au-delà des 34 connus ne sont simplement pas mappés: Si une future version d'AWS ajoute des champs après ceux actuellement connus par cet outil, ces valeurs finales ne s'affichent pas comme colonnes supplémentaires — l'indication de couverture des champs continue d'afficher le nombre réel de champs connus par rapport au total, pour repérer quand un log est plus récent que la liste de champs de cet outil.
Cet outil lit le format de log texte classique, pas le JSON ou Parquet de CloudFront Standard Logging v2: CloudFront Standard Logging v2 peut aussi livrer des fichiers JSON ou Parquet. Parquet est un format binaire en colonnes qu'un navigateur ne peut pas analyser utilement en tant que texte collé, donc cet outil ne traite que le format texte classique de type W3C (le format legacy, et l'option de sortie w3c équivalente en v2).
Pas de S3, pas d'identifiants AWS, pas de logs temps réel ou en streaming: Cet outil ne demande jamais de nom de bucket ni de clé d'accès et ne fait jamais de requête réseau — vous collez un texte que vous avez déjà. Il ne lit pas non plus les logs temps réel de CloudFront, livrés via Kinesis Data Streams plutôt que sous forme de fichier à coller.
Un collage est limité à 300 000 caractères et 20 000 lignes: Cette limite garde l'analyse rapide et prévisible dans l'onglet du navigateur. Divisez un export de log plus volumineux en plusieurs lots si vous atteignez la limite.

FAQ de l'analyseur de logs AWS

Réponses aux questions posées avant d'analyser en ligne un log d'accès CloudFront ou ALB.

Que signifient les champs des logs d'accès ALB ?

Comme ALB n'a pas de ligne d'en-tête, cet outil mappe les tokens séparés par des espaces de chaque ligne, par position, sur l'ordre des champs documenté par AWS — type, time, elb, client:port, jusqu'aux champs plus récents comme classification ou ip_address. Ce mappage s'applique automatiquement dès que ALB est choisi ou détecté.

Que signifient les champs des logs CloudFront ?

Cela dépend de la configuration de journalisation et de la version au moment de l'activation — c'est justement pourquoi cet outil lit les noms de champs directement depuis la ligne #Fields du log, plutôt que de supposer une liste fixe. Après collage, les en-têtes de colonnes sont les vrais noms de champs de votre version, de date et c-ip jusqu'à des champs plus rares comme fle-status ou sc-range-start.

Comment corréler les logs CloudFront et ALB pour une même requête ?

Cet outil ne fusionne pas automatiquement les deux logs, il analyse chacun séparément. Il fournit en revanche les champs nécessaires pour faire la correspondance à la main : x-edge-request-id et x-forwarded-for côté CloudFront, trace_id côté ALB — exactement la valeur qu'AWS documente pour relier les deux sauts.

Comment obtenir la véritable adresse IP du client derrière ALB quand CloudFront est devant ?

Quand CloudFront est placé devant un ALB, ce dernier voit généralement l'IP du côté edge de CloudFront comme client. Cet outil affiche le champ client:port d'ALB tel quel dans une colonne et permet de filtrer par IP cliente sans la partie port, pour vérifier directement si la valeur correspond à ce qui est attendu.

Peut-on analyser un fichier de log directement dans le navigateur, sans envoi au serveur ?

Oui. Le texte collé n'est envoyé nulle part. L'analyse, le filtrage et l'export se font entièrement dans l'onglet du navigateur en JavaScript, sans envoi, stockage ni journalisation côté serveur, et sans jamais demander de compte AWS ni d'accès S3.

Que sont les nouveaux champs des logs ALB comme conn_trace_id ou classification ?

AWS a plusieurs fois ajouté des champs à la fin du format de log ALB depuis 2016 — classification et classification_reason pour l'atténuation des attaques desync, conn_trace_id, et plus récemment transformed_host et ip_address. Cet analyseur mappe autant des 34 champs connus qu'une ligne en contient réellement et indique ce compte, restant ainsi utile sur des logs ALB anciens comme récents sans qu'il faille savoir quelle version a introduit quel champ.

Ce parseur prend-il en charge le format JSON ou Parquet de CloudFront Standard Logging v2 ?

Non — cet analyseur ne lit que le format de log texte classique séparé par tabulations (le format legacy, et l'option de sortie w3c équivalente sous Standard Logging v2). Parquet est un fichier binaire en colonnes qu'on ne peut pas coller utilement comme texte, cette option de sortie sort donc du périmètre d'un outil d'analyse texte basé sur le navigateur.

Une ligne de log réelle que cet analyseur traite mal ?

Analysez votre log CloudFront ou ALB maintenant

Collez un log standard CloudFront ou un log d'accès ALB et obtenez en quelques secondes un tableau filtrable et exportable — sans S3, sans identifiants AWS, sans envoi.

Mettez cet analyseur de logs AWS en favori pour la prochaine fois qu'il faudra vérifier un taux de cache hit, trouver qui sollicite trop un chemin, ou comprendre pourquoi un groupe cible renvoie le mauvais code de statut.

Retour à l'analyseur Voir les outils logs & observabilité

Toute l'analyse se fait localement dans votre navigateur.

Analyseur de logs AWSpour les logs CloudFront et ALB