Ich frage mich, welchen Ansatz ich mit meinen Logstash Grok-Filtern am besten wählen kann. Ich habe einige Filter, die für bestimmte Protokolleinträge gelten und nicht für alle Einträge gelten. Diejenigen, die nicht zutreffen, generieren immer _grokparsefailure-Tags. Zum Beispiel habe ich einen Grok-Filter, der für jeden Protokolleintrag gilt und gut funktioniert. Dann habe ich noch einen Filter, der für Fehlermeldungen mit Tracebacks ist. Der Traceback-Filter gibt für jeden einzelnen Protokolleintrag, für den es keinen Traceback gibt, einen Grokparse-Fehler aus.

Ich würde es vorziehen, wenn es nur die Regel besteht, wenn es keine Übereinstimmung gibt, anstatt das Parsefailure-Tag hinzuzufügen. Ich benutze das parsefailure-Tag, um Dinge zu finden, die nicht richtig analysiert wurden, und nicht Dinge, die einfach nicht mit einem bestimmten Filter übereinstimmen. Vielleicht ist es nur die Nomenklatur "Fehler analysieren", die mich erwischt. Für mich bedeutet das, dass mit dem Filter etwas nicht stimmt (z. B. falsch formatiert), nicht, dass er nicht übereinstimmt.

Die Frage ist also, wie soll ich damit umgehen?

Stellen Sie das Filtermuster optional mit?

(ab) benutze die tag_on_failure Option indem du sie auf nichts setzt []

mach den Filter mit so etwas wie "if traceback in message" bedingt

etwas anderes, über das ich nicht nachdenke?

Danke im Voraus.

BEARBEITEN

Ich bin den Weg gegangen, um den Filter eine Bedingung hinzuzufügen:

    if [message] =~ /took\s\d+/ {
        grok {
            patterns_dir => "/etc/logstash/patterns"
            match => ["message", "took\s+(?<servicetime>[\d\.]+)"]
            add_tag => [ "stats", "servicetime" ]
        }
    }

Ich bin immer noch an Feedback interessiert. Was wird hier als "Best Practice" bezeichnet?