Logs & Observability-Tools

AWS Logs analysierenfür CloudFront- und ALB-Zugriffsprotokolle

CloudFront-Standardprotokoll oder ALB-Zugriffsprotokoll einfügen, Format automatisch erkennen lassen (oder manuell wählen) und auf „Log analysieren“ klicken, um eine filterbare Tabelle zu erhalten.

Beispiel:

Log-Typ

FilterAls Regex behandeln

Zugriffsprotokoll

Läuft lokal im Browser. Der Log-Text wird nie hochgeladen, ein AWS-Konto ist nicht nötig.

Analysierte Zeilen

Log analysieren, um hier Zeilen zu sehen.

CloudFront- oder ALB-Log einfügen oder Beispiel laden, dann auf „Log analysieren“ klicken.

CloudFront und ALB erzeugen zwei der gängigsten Zugriffsprotokolle auf AWS, und keines lässt sich bequem mit bloßem Auge lesen: Welche Felder ein CloudFront-Log enthält, hängt davon ab, welche Spalten beim Aktivieren der Protokollierung gewählt wurden, und ALB packt über 30 leerzeichengetrennte Werte in eine Zeile, mehrere davon in Anführungszeichen. Dieses Tool zum AWS Logs analysieren ist für den Moment gedacht, in dem ein Ausschnitt eines dieser Logs vorliegt — aus einem Support-Ticket kopiert, aus S3 heruntergeladen oder aus einem CloudWatch-Export — und man wissen muss, welcher Edge-Standort eine Anfrage bedient hat, welches Ziel einen 502 zurückgegeben hat oder welche Client-IP einen Pfad auffällig oft anfragt, ohne dafür Athena aufzusetzen.

Gedacht für die schnelle Durchsicht von ein paar hundert bis ein paar tausend Zeilen, nicht als dauerhafte Analyse-Pipeline. Alles läuft im Browser-Tab; der Log-Text wird nie hochgeladen, und weder ein AWS-Konto noch S3-Zugriff sind nötig.

Warum sich AWS Logs analysieren mit diesem Parser lohnt

Entwickelt danach, wie diese beiden AWS-Formate ihre Felder tatsächlich deklarieren.

CloudFronts eigener Header verrät die Spalten

Ein CloudFront-Standardprotokoll beginnt mit den Zeilen #Version und #Fields, die jede Spalte der Reihe nach benennen. Dieser Parser liest genau diese beiden Zeilen, statt ein festes Layout anzunehmen — fügt AWS künftig weitere Felder hinzu, wächst die Tabelle einfach mit, ohne Update dieses Tools und ohne Versionsauswahl.

Mit dem CloudFront-Beispiel testen Feldregeln ansehen

Eine CloudFront-#Fields-Headerzeile wird direkt auf Tabellenspalten abgebildet

Formatspezifische Statistiken statt einer generischen Zusammenfassung

Bei CloudFront gibt es eine Aufschlüsselung des Cache-Ergebnisses (Hit, Miss, RefreshHit, Error) und die häufigsten Edge-Standorte — genau das, was man bei auffälligem CDN-Verhalten prüft. Bei ALB gibt es eine Aufschlüsselung der ausgeführten Aktionen sowie die Anzahl der Anfragen, bei denen der Load-Balancer-Statuscode vom Ziel-Statuscode abweicht — meist das erste Anzeichen für ein Backend-Problem.

Statistik-Panel ansehen Datenschutzhinweise lesen

Getrennte Panels für Cache-Ergebnis- und ELB/Ziel-Statuscode-Abweichungsstatistik

Vom rohen AWS-Log zur filterbaren Tabelle

Analysieren, filtern und exportieren in drei Schritten.

Log einfügen und automatisch erkennen lassen

CloudFront-Standardprotokoll oder ALB-Zugriffsprotokoll einfügen. Die automatische Erkennung betrachtet nur die erste nicht leere Zeile: Beginnt sie mit #Version:, ist es CloudFront; beginnt das erste Wort mit http/https/h2/grpcs/ws/wss, ist es ALB. Passt keins von beiden (etwa weil nur Datenzeilen ohne Header eingefügt wurden), den Log-Typ lieber manuell aus dem Dropdown wählen statt zu raten.

CloudFront manuell auf einem Log ohne #Version-/#Fields-Header zu wählen führt nicht zu einem Fehler — es wird auf die eingebaute Standard-Feldliste zurückgegriffen, die den aktuellen AWS-Feldumfang abdeckt
Beide eingebauten Beispiele laden mit bereits vorausgewähltem Format und enthalten jeweils eine absichtlich fehlerhafte Zeile, damit sichtbar wird, wie eine Nichtübereinstimmung gemeldet wird

Auf „Log analysieren“ klicken (oder Strg/Cmd+Enter)

Die Analyse startet nicht automatisch beim Tippen — diese Logs haben oft tausende Zeilen mit teils über 30 Feldern, und bei jedem Tastendruck neu zu matchen wäre Verschwendung. Einmal auf „Log analysieren“ klicken oder das Tastenkürzel nutzen, und die Tabelle füllt sich.

Ein späterer Wechsel des Log-Typs löst keine automatische Neuanalyse aus; die alte Tabelle bleibt sichtbar, wird aber abgeblendet, bis erneut auf „Log analysieren“ geklickt wird

Filtern und exportieren

Statuscode-, Pfad-, Client-IP- und (bei CloudFront) Edge-Standort-Filter wirken sofort auf die bereits analysierten Zeilen — ein erneuter Klick auf „Log analysieren“ ist nicht nötig. Das Zusammenfassungs-Panel unter der Tabelle aktualisiert sich mit dem Filter, inklusive Cache-Ergebnis- bzw. Aktions-Aufschlüsselung sowie Gesamtbytes, Durchschnitts- und Maximalzeit für die aktuell angezeigten Zeilen. Die sichtbaren Zeilen lassen sich als CSV, JSON oder Klartext exportieren.

Das Edge-Standort-Filterfeld erscheint nur, wenn der Log-Typ CloudFront oder Automatisch erkennen ist — ALB-Logs haben kein entsprechendes Feld, das Eingabefeld wird also gar nicht erst angezeigt statt nur deaktiviert

Zum Parser springen

Was diese Tabelle über den reinen Text hinaus bietet

Feldzuordnung, vier Filter und formatspezifische Statistiken für die Fehlersuche in echten AWS-Zugriffsprotokollen.

Selbstbeschreibende Feldzuordnung für CloudFront

Die Spaltennamen stammen direkt aus der #Fields-Zeile des Logs selbst, sodass die Tabelle immer genau zu der Version des eingefügten Logs passt — inklusive einer beim Aktivieren der Protokollierung ausgewählten eigenen Feldauswahl.

Eine feste, nur wachsende Feldzuordnung für ALB

ALB hat keine Header-Zeile, aber AWS dokumentiert ausdrücklich, dass neue Felder ausschließlich am Ende ergänzt werden. Dieser Parser ordnet die Tokens einer Zeile positionsbasiert der vollständigen bekannten Feldliste zu und meldet, wie viele bekannte Felder tatsächlich getroffen wurden — ein älteres Log mit weniger abschließenden Feldern wird also weiterhin sauber analysiert statt einen Fehler auszulösen.

Vier Filter: Status, Pfad, Client-IP, Edge-Standort

Die Tabelle lässt sich auf einen Statusbereich oder einen exakten Code, einen Pfad-Teilstring oder Regex, einen Client-IP-Teilstring sowie — bei CloudFront — einen Edge-Standort-Teilstring einschränken, ganz ohne erneute Analyse des Logs.

Cache-Ergebnis- und Aktions-Aufschlüsselung plus Statusabweichungen

CloudFront-Zeilen werden nach x-edge-result-type zusammengefasst (Hit, Miss, RefreshHit, Error und ähnliche); ALB-Zeilen werden nach dem kommagetrennten Wert von actions_executed zusammengefasst, plus einer Zählung der Anfragen, bei denen ELB- und Ziel-Statuscode voneinander abweichen.

Fehlerhafte Zeilen mit Zeilennummer

Eine Zeile, deren Spaltenzahl nicht zum erkannten Format passt, wird mit ihrer 1-basierten Zeilennummer und dem Originaltext aufgeführt, damit ein paar unpassende Zeilen nie stillschweigend aus der Zählung verschwinden.

Export als CSV, JSON oder Klartext

Exportiert wird genau das, was die Filter gerade anzeigen, mit denselben Spalten wie in der Tabelle — bereit für eine Tabellenkalkulation oder ein anderes Tool.

Was dieser Parser liest — und was nicht

Das genaue Verhalten bei Felderkennung, fehlerhaften Zeilen und den Grenzen des Funktionsumfangs, die sich kaum ändern werden.

CloudFront braucht eine exakt passende Spaltenzahl, ALB mindestens 13 Tokens: Eine CloudFront-Datenzeile wird nur akzeptiert, wenn ihre tabgetrennte Spaltenzahl exakt zur aktiven Feldliste passt (aus #Fields oder der eingebauten Standardliste). Eine ALB-Zeile braucht mindestens 13 leerzeichengetrennte Tokens — genug, um das in Anführungszeichen stehende request-Feld zu erreichen —, sonst wird sie als fehlerhafte Zeile geführt statt geraten.
ALB-Felder jenseits der bekannten 34 werden schlicht nicht zugeordnet: Fügt AWS künftig Felder hinter den derzeit bekannten hinzu, werden diese nachfolgenden Werte nicht als zusätzliche Spalten angezeigt — der Hinweis zur Feldabdeckung zeigt weiterhin die tatsächlich bekannte Feldzahl im Verhältnis zur Gesamtzahl, sodass erkennbar bleibt, wenn ein Log neuer ist als die Feldliste dieses Tools.
Verarbeitet wird das klassische Textformat, nicht CloudFront Standard Logging v2 als JSON oder Parquet: CloudFront Standard Logging v2 kann auch als JSON- oder Parquet-Dateien ausgeliefert werden. Parquet ist ein binäres, spaltenorientiertes Format, das sich als eingefügter Text im Browser nicht sinnvoll auswerten lässt — dieses Tool verarbeitet daher nur das klassische, W3C-artige Textlog (das Legacy-Format sowie die entsprechende w3c-Ausgabeoption in v2).
Kein S3, keine AWS-Zugangsdaten, keine Echtzeit- oder Streaming-Logs: Dieses Tool fragt nie nach einem Bucket-Namen oder Zugriffsschlüssel und stellt nie eine Netzwerkanfrage — es wird Text eingefügt, den man bereits vorliegen hat. Auch CloudFront-Echtzeitprotokolle, die über Kinesis Data Streams ausgeliefert werden, werden nicht gelesen, da sie keine einfügbare Datei sind.
Ein Einfügevorgang ist auf 300.000 Zeichen und 20.000 Zeilen begrenzt: Das hält die Analyse im Browser-Tab schnell und vorhersehbar. Größere Log-Exporte bei Bedarf in kleinere Abschnitte aufteilen.

Häufige Fragen zum Thema AWS Logs analysieren

Antworten auf Fragen, die vor dem Online-Analysieren eines CloudFront- oder ALB-Zugriffsprotokolls häufig auftauchen.

Was bedeuten die Felder im ALB-Zugriffsprotokoll?

Da ALB keine Header-Zeile hat, ordnet dieses Tool die leerzeichengetrennten Tokens jeder Zeile positionsbasiert der von AWS dokumentierten Feldreihenfolge zu — beginnend mit type, time, elb, client:port bis hin zu neueren Feldern wie classification und ip_address. Diese Zuordnung greift automatisch, sobald ALB gewählt oder per Auto-Erkennung ermittelt wird.

Was bedeuten die Felder in CloudFront-Logs?

Das hängt von der Protokollierungskonfiguration und der Version zum Zeitpunkt der Aktivierung ab — genau deshalb liest dieses Tool die Feldnamen aus der #Fields-Zeile des Logs selbst, statt eine feste Liste anzunehmen. Nach dem Einfügen zeigen die Spaltenüberschriften die tatsächlichen Feldnamen der jeweiligen Version, von date und c-ip bis zu selteneren Feldern wie fle-status oder sc-range-start.

Wie lassen sich CloudFront- und ALB-Logs miteinander korrelieren?

Dieses Tool verknüpft die beiden Logs nicht automatisch, sondern analysiert jedes für sich. Es liefert aber die Felder, die für einen manuellen Abgleich nötig sind: x-edge-request-id und x-forwarded-for auf CloudFront-Seite sowie trace_id auf ALB-Seite — genau der Wert, den AWS laut Dokumentation zur Zuordnung über beide Hops hinweg vorsieht.

Wie ermittle ich die echte Client-IP hinter ALB, wenn CloudFront davorsteht?

Steht CloudFront vor einem ALB, sieht der ALB als Client meist die IP der CloudFront-Edge-Verbindung. Dieses Tool zeigt das client:port-Feld von ALB unverändert als Spalte an und erlaubt eine IP-Filterung ohne den Portanteil, sodass sich direkt prüfen lässt, ob der Wert der Erwartung entspricht.

Kann ich eine Logdatei lokal im Browser analysieren, ohne sie hochzuladen?

Ja. Der eingefügte Text wird nirgendwohin gesendet. Analyse, Filterung und Export laufen vollständig im Browser-Tab per JavaScript ab, es gibt kein serverseitiges Hochladen, Speichern oder Protokollieren des eingefügten Texts, und es wird zu keinem Zeitpunkt ein AWS-Konto oder S3-Zugriff verlangt.

Was sind die neuen Felder in ALB-Zugriffsprotokollen wie conn_trace_id oder classification?

AWS hat dem ALB-Logformat seit 2016 mehrfach Felder am Ende hinzugefügt — classification und classification_reason zur Desync-Abwehr, conn_trace_id und zuletzt transformed_host sowie ip_address. Dieser Parser ordnet so viele der bekannten 34 Felder zu, wie eine Zeile tatsächlich enthält, und meldet die Anzahl, sodass er sowohl auf älteren als auch auf neueren ALB-Logs nützlich bleibt, ohne dass man wissen muss, welches Release welches Feld eingeführt hat.

Unterstützt dieses Tool das JSON- oder Parquet-Format von CloudFront Standard Logging v2?

Nein — dieser Parser liest nur das klassische, tabgetrennte Textlogformat (das Legacy-Format sowie die entsprechende w3c-Option unter Standard Logging v2). Parquet ist eine binäre, spaltenorientierte Datei und lässt sich nicht sinnvoll als Text einfügen, weshalb diese Ausgabeoption für ein browserbasiertes Text-Tool außerhalb des Umfangs liegt.

Eine echte Log-Zeile gefunden, bei der dieser Parser danebenliegt?

Jetzt CloudFront- oder ALB-Logs auswerten

CloudFront-Standardprotokoll oder ALB-Zugriffsprotokoll einfügen und in Sekunden eine filterbare, exportierbare Tabelle erhalten — ohne S3, ohne AWS-Zugangsdaten, ohne Upload.

Dieses Tool zum AWS Logs analysieren als Lesezeichen speichern für das nächste Mal, wenn eine Cache-Trefferquote geprüft, ein auffälliger Pfad-Zugriff gefunden oder eine falsche Statuscode-Antwort einer Zielgruppe untersucht werden muss.

Zurück zum Parser Logs & Observability-Tools ansehen

Die gesamte Analyse läuft lokal im Browser.

AWS Logs analysierenfür CloudFront- und ALB-Zugriffsprotokolle