web-dev-qa-db-fra.com

Comment gérer les filtres Grok Logstash non compatibles

Je me demande quelle est la meilleure approche à adopter avec mes filtres Logstash Grok. Certains filtres concernent des entrées de journal spécifiques et ne s'appliquent pas à toutes les entrées. Ceux qui ne s'appliquent pas génèrent toujours des balises _grokparsefailure. Par exemple, j'ai un filtre Grok qui est pour chaque entrée de journal et cela fonctionne bien. Ensuite, j'ai un autre filtre qui est pour les messages d'erreur avec tracebacks. Le filtre traceback jette une erreur grokparsefailure pour chaque entrée de journal sans traceback.

Je préférerais qu'il passe simplement la règle s'il n'y a pas de correspondance au lieu d'ajouter la balise parsefailure. J'utilise la balise parsefailure pour rechercher les éléments qui ne sont pas analysés correctement, mais pas ceux qui ne correspondent tout simplement pas à un filtre particulier. Peut-être que c'est juste la nomenclature "échec d'analyse" qui m'obtient. Pour moi, cela signifie qu’il ya quelque chose qui ne va pas avec le filtre (par exemple, mal formaté), cela ne veut pas dire qu’il ne correspond pas.

La question est donc, comment devrais-je gérer cela?

  • Rendre le modèle de filtre facultatif en utilisant?

  • (ab) utilise l'option tag_on_failure en la mettant à néant []

  • rendre le filtre conditionnel en utilisant quelque chose comme "if traceback in message"

  • quelque chose d'autre que je n'envisage pas?

Merci d'avance.

ÉDITER

J'ai pris le chemin d'ajouter une condition autour du filtre:

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

Toujours intéressé par les commentaires cependant. Qu'est-ce qui est considéré comme "meilleure pratique" ici?

filterlogstashlogstash-grok
49
Spanky

Si possible, j'utiliserais un wrapper conditionnel identique à celui que vous utilisez. N'hésitez pas à poster cela comme réponse!

Si votre application ne produit que quelques formats de ligne différents, vous pouvez utiliser plusieurs modèles de correspondance avec filtre de grok . Par défaut, le filtre traitera jusqu'à la première correspondance réussie:

grok {
    patterns_dir => "./patterns"
    match => {
        "message" => [ 
              "%{BASE_PATTERN} %{EXTRA_PATTERN}",
              "%{BASE_PATTERN}",
              "%{SOME_OTHER_PATTERN}"
        ]
    }
}

Si votre logique est moins simple (vous devez peut-être vérifier la même condition plusieurs fois), le filtre grep peut être utile pour ajouter une balise. Quelque chose comme ça:

grep {
    drop => false #grep normally drops non-matching events
    match => ["message", "/took\s\d+/"]
    add_tag => "has_traceback"
}


...

if "has_traceback" in [tags] {
    ...
}
36
rutter

Vous pouvez également ajouter tag_on_failure => [] à votre strophe de groupe comme ceci:

grok {
    match => ["context", "\"tags\":\[%{DATA:apptags}\]"]
    tag_on_failure => [ ]
}

grok échouera tout de même, mais le fera sans rien ajouter au tableau de balises.

22
Gary Rogers

C'est le moyen le plus efficace de le faire. Ignorer le filtre

filter {

        grok {
            match => [ "message", "something"]
    }

    if "_grokparsefailure" in [tags] {
            drop { }
        }
}
8
JAR

Vous pouvez aussi faire ça

remove_tag => ["_grokparsefailure"]

chaque fois que vous avez un match.

4
Tony Wong