{"id":82019,"date":"2026-09-08T09:00:00","date_gmt":"2026-09-08T17:00:00","guid":{"rendered":"http:\/\/www.sumologic.com\/blog\/strukturierte-felder-aus-unstrukturierten-logs-extrahieren"},"modified":"2026-10-29T16:51:55","modified_gmt":"2026-10-30T00:51:55","slug":"how-to-extract-structured-fields-from-unstructured-logs","status":"publish","type":"blog","link":"https:\/\/www.sumologic.com\/de\/blog\/how-to-extract-structured-fields-from-unstructured-logs","title":{"rendered":"Strukturierte Felder aus unstrukturierten Logs extrahieren"},"content":{"rendered":"\n
\n
\n
\n
\n
\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Wenn Sie schon einmal Zeit damit verbracht haben, in Logs<\/a> nach Erkenntnissen zu suchen, kennen Sie das Problem. Eine einzelne Protokollzeile kann eine IP-Adresse, einen Statuscode, eine Antwortzeit und eine Benutzer-ID enthalten, aber alles ist in einer langen, unstrukturierten Zeichenkette vergraben. Sie wissen, dass die Informationen vorhanden sind. Sie in ein Feld zu bringen, das Sie filtern, gruppieren oder in einem Diagramm darstellen k\u00f6nnen, ist eine andere Sache.<\/p>\n\n\n\n

Dies ist einer der h\u00e4ufigsten Engp\u00e4sse in der Log-Analyse<\/a>, und es lohnt sich, die tats\u00e4chlichen Mechanismen zu verstehen, warum dies geschieht und welche Optionen Sie zur Behebung haben \u2013 egal ob Sie einen einzelnen Vorfall beheben oder eine permanente Pipeline aufbauen.<\/p>\n\n\n\n

Warum Logs von Anfang an unstrukturiert sind<\/h2>\n\n\n\n

Die meisten Anwendungen schreiben Logs auf die Weise, die ein Entwickler im Moment praktisch findet, nicht auf die Weise, wie ein Analyst sie sechs Monate sp\u00e4ter abfragen m\u00f6chte. Eine einzelne Protokollzeile mischt oft Freitext, Zeitstempel, Schl\u00fcssel-Wert-Paare und verschachtelte Bezeichner ohne konsistentes Trennzeichen. Multiplizieren Sie das \u00fcber Dutzende von Diensten, von denen jeder seine eigene Protokollierungsbibliothek und sein eigenes Format hat, und Sie erhalten einen Datenstrom aus Rohtext, der technisch alles enth\u00e4lt, was Sie brauchen, und praktisch vor Ihnen verbirgt.<\/p>\n\n\n\n

Strukturierte Felder l\u00f6sen dies, indem sie jedem Informationselement einen Namen geben. Anstatt nach einer Teilzeichenkette in einer Textwand zu suchen, suchen Sie nach status_code=500<\/strong> oder response_time>2000<\/strong>. Die Daten \u00e4ndern sich nicht. Was sich \u00e4ndert, ist Ihre F\u00e4higkeit, darauf zu reagieren.<\/p>\n\n\n\n

Ansatz eins: Felder zur Abfragezeit parsen<\/h2>\n\n\n\n

Manuelle Erstellung von Parse-Ausdr\u00fccken<\/h3>\n\n\n\n

Die traditionelle und direkteste Methode zum Extrahieren eines Feldes ist das Schreiben eines Parse-Ausdrucks<\/a> als Teil Ihrer Suche. Die meisten Log-Plattformen unterst\u00fctzen eine Version eines ankergest\u00fctzten Parse-Operators: Sie identifizieren ein Textst\u00fcck in einer Beispiel-Protokollzeile, teilen dem System mit, was es umgibt, und geben dem extrahierten Wert einen Feldnamen.<\/p>\n\n\n\n

Dies funktioniert gut f\u00fcr einmalige Untersuchungen. Sie schauen sich einen bestimmten Fehler an, Sie ben\u00f6tigen jetzt ein oder zwei Felder daraus, und Sie ben\u00f6tigen diese Parse-Logik nicht \u00fcber diese Suche hinaus. Der Kompromiss besteht darin, dass echtes Syntax-Wissen erforderlich ist. Das Erstellen eines genauen Parse-Ausdrucks von Hand bedeutet normalerweise, jede Feldgrenze zu identifizieren, die richtigen Zeichen zu escapen und gegen einige Beispielzeilen zu testen, bevor Sie das Ergebnis vertrauen. F\u00fcr ein Teammitglied, das t\u00e4glich Logs parst, wird dies zur zweiten Natur. F\u00fcr alle anderen ist es eine Wissensl\u00fccke, die eine zweimin\u00fctige Untersuchung in eine zwanzigmin\u00fctige verwandelt.<\/p>\n\n\n\n

Lassen Sie KI das tun<\/h3>\n\n\n\n

Der obige Ansatz schafft einen Engpass: Sie m\u00fcssen wissen, wie man einen Parse-Ausdruck schreibt. Das ist eine echte H\u00fcrde, besonders wenn Sie neu im Team sind oder nur gelegentlich Logs parsen, anstatt t\u00e4glich.<\/p>\n\n\n\n

KI-gest\u00fctzte Parse-Tools entfernen diesen Schritt, ohne Ihre Kontrolle \u00fcber das Ergebnis zu entfernen. In Sumo Logics Log Search<\/a> sieht dies wie AI Parse Assist<\/a> aus: Sie w\u00e4hlen eine repr\u00e4sentative Protokollzeile aus, w\u00e4hlen \u201eMit KI parsen\u201c und lassen die KI potenzielle Felder identifizieren und den entsprechenden Parse-Ausdruck generieren. \u00dcberpr\u00fcfen Sie die vorgeschlagenen Felder und den Ausdruck, nehmen Sie bei Bedarf \u00c4nderungen vor und wenden Sie sie auf Ihre Suche an. Nichts wird automatisch ausgef\u00fchrt. Es ist ein Beschleuniger f\u00fcr die gleiche F\u00e4higkeit, keine Black Box, die verbirgt, was mit Ihrer Abfrage geschieht.<\/p>\n\n\n\n

Ansatz zwei: Felder zur Erfassungszeit extrahieren<\/h2>\n\n\n\n

Wenn Sie feststellen, dass Sie denselben Parse-Ausdruck immer wieder schreiben (oder KI ihn schreiben lassen), ist Query-Time-Parsing das falsche Tool. Feldextraktionsregeln<\/a> (FERs) l\u00f6sen dies, indem sie Felder einmal bei der Erfassung parsen, anstatt jedes Mal, wenn jemand eine Suche ausf\u00fchrt.<\/p>\n\n\n\n

Der Vorteil w\u00e4chst. Das Extrahieren von Feldern bei der Erfassung macht sie f\u00fcr Ad-hoc-Suchen, geplante Suchen, Echtzeit-Warnmeldungen und Dashboards verf\u00fcgbar, sodass niemand die Parse-Logik neu ableiten muss. Dies standardisiert auch Feldnamen in Ihrer Organisation, sodass \u201eIP-Adresse\u201c nicht je nach Autor der Suche als ip, ip_addr und client_ip angezeigt wird. FERs gelten nur ab dem Zeitpunkt ihrer Erstellung, daher lohnt es sich, die Regel fr\u00fch einzurichten, wenn ein Feld f\u00fcr Ihr Team wichtig ist, anstatt zu warten, bis Sie historische Daten r\u00fcckwirkend parsen m\u00fcssen.<\/p>\n\n\n\n

Der Kompromiss hier ist die anf\u00e4ngliche Investition. Sie m\u00fcssen identifizieren, welche Felder plattformweit extrahiert werden sollen, und die FER korrekt konfigurieren, was wiederum normalerweise bedeutet, Parse-Syntax zu kennen oder sich auf einen Teamkollegen zu verlassen, der dies tut.<\/p>\n\n\n\n

Den richtigen Ansatz w\u00e4hlen<\/h2>\n\n\n\n