Bonjour à tous ! Je débute depuis plusieurs heures sur le parsing des log logstash.
C'est peut-être une question très anodine pour vous mais je cherche les "best practice" pour parser mes logs et surtout rechercher les erreurs.
J'ai tout fraichement réalisé un pattern grok et j'arrive à découper comme je le souhaite mais j'ai toujours un tag "grokparsefailure" . Dans ce cas je conclu que mon filter n'est pas "propre" ?
Quel est le moyen le plus pratique pour repérer les defaux de grokparsefailure ?
J'ai bien lu les doc et je me suis bien documenté. Étant donner que je n'ai peut être pas la logique d'un développeur je suis passé au travers de quelque chose.
C'est une question plutôt général donc dans un premier temps je ne demande pas de vérifier mon fichier de conf logstash.
C'est étrange parce que le découpage se fait correctement et comme je le souhaite. Avons nous la possibilité d’analyser à quel endroit le "parsing" ne s’effectue pas correctement ? Ou la meilleur des façons est de recommencer le fichier de conf petit à petit afin d'observer quand le grokparsefailure s’exécute ?
Oui j'ai justement utilisé Grokconstructor qui m'a été très utile pour monter dans un premier temps les regex.
C'est étrange parce que le découpage se fait correctement et comme je le souhaite.
Sans doute. SAUF pour la ligne en question qui est rejetée.
Avons nous la possibilité d’analyser à quel endroit le "parsing" ne s’effectue pas correctement ?
Je ne sais pas si il y a un debugger d'expressions régulières. Peut-être que @colinsurprenant sait ça...
En tout cas, déjà trouve la ligne qui ne fonctionne pas. Eventuellement partage là ici avec ton expression grok si tu n'y arrives pas.
J'ai effectué un nouveau logstash from scratch et je construis mon filtre petit à petit et je viens de me rendre compte que j'ai un grokparsefailure rien qu'en taguant déjà les log. Donc c'est déjà ma première démarche qui n'est pas bonne.
Exemple : J'ai un serveur où je récupère en syslog des log radius et dhcp. Je veux dans un premier temps les taguer pour ensuite les "parser" comme je veux.
N'utilise pas la citation pour formater du code mais le bouton </>. J'ai édité ton post.
Ici le parsing grok ne fonctionne pas car ta ligne ne contient pas que le texte dhcpd mais autre chose. Il faut donc que tu fasses une expression régulière qui corresponde à une ligne qui contient dhcpd.
J'ai approfondi la doc et j'ai observé qu'il était possible d'utilisé grok dans l'input. ET de cette manière ça marche . Alors pareil je ne sais pas si c'est la manière la plus propre.
input {
syslog {
type => "syslog"
port => 514
grok_pattern => "<%{POSINT:priority}>%{SYSLOGTIMESTAMP:timestamp} %{WORD:Server_Name} %{SYSLOGHOST:Service_Name}%{SYSLOG5424SD:ID_Service}: %{GREEDYDATA:Message_du_log}"
}
}
filter {
if [Service_Name] == "radiusd" {
grok {
match => { "Service_Name" => "radiusd" }
add_tag => "radiusd"
}
}
if [Service_Name] == "dhcpd" {
grok {
match => { "Service_Name" => "dhcpd" }
add_tag => "dhcpd"
}
}
}
En tout cas merci @dadoonet pour ton coup de main et de te prendre le temps. Ca me permet de progresser sur la solution.
J'ai trouvé un article sur le blog d'elasticsearch. Qui explique la bonne manière d'identifier et debugger les grokparsefailure.
Je le traduit et dépose ici. Cela pourra toujours servir
Bien qu'il soit très important de savoir à quelle vitesse votre modèle grok correspond à une entrée de log, il est également essentiel de comprendre ce qui se passe quand ce n'est pas le cas. Les matchs réussis peuvent avoir des performances très différentes de ceux qui échouent.
Lorsque grok ne match pas à un événement, il ajoute une balise à l'événement. Par défaut, cette balise est _grokparsefailure.
Logstash vous permet ensuite d’acheminer ces events à un endroit où ils peuvent être comptés et examinés. Par exemple, vous pouvez écrire toutes les correspondances ayant échoué dans un fichier:
input { # ... }
filter {
grok {
match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} \[%{IPV4:ip};%{WORD:environment}\] %{LOGLEVEL:log_level} %{GREEDYDATA:message}" }
}
}
output {
if "_grokparsefailure" in [tags] {
# write events that didn't match to a file
file { "path" => "/tmp/grok_failures.txt" }
} else {
elasticsearch { }
}
}
Personnellement j'ai un ELK en dévelopement et lorsque mes filtres en production ont des grokparsefailure, je met ces entrées dans un fichier log, je configure un filebeat en dev pour ce fichier et je déconstruit mon filtre en remplaçant la fin du filtre par "%{GREEDYDATA}". Je réimporte ensuite les entrées avec le filtre déconstruit jusqu'à ce que je trouve le morceau fautif.
Par exemple j'essaie mon filtre original: %{TIMESTAMP_ISO8601:timestamp} \[%{IPV4:ip};%{WORD:environment}\] %{LOGLEVEL:log_level} %{GREEDYDATA:message}
Si ça ne passe pas j'essaie: %{TIMESTAMP_ISO8601:timestamp} \[%{IPV4:ip};%{WORD:environment}\] %{GREEDYDATA:restant}
Jusqu'à ce que le _grokparsefailure ne se produise plus. Puisque le "Greedydata" capture toujours le restant par défaut, lorsque ça passe c'est que la dernière portion enlevée ne fonctionnais pas.
Cela me permet souvent d'identifier la portion du filtre qui est fautive.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
. Alors pareil je ne sais pas si c'est la manière la plus propre.
