Bonjour,
Je suis arrivé à envoyer des données dans Graylog via rsyslog. Cependant les informations sont toutes dans le champ message. J'ai lu sur la doc de Graylog qu'il existait des extracteurs via la mise en place d'expressions régulières. Cependant il semble qu'il ne soit pas possible de le faire sur la plateforme ou bien je n'ai pas trouvé où ?
Merci pour la réponse
Dans l'offre pro l'option "outils de collecte" commence à 4,99Euros/mois avec 1 outil de collecte de 2 instances
Que représente le nombre d'instances ?
J'ai avancé avec les collectors. Cependant il semble que les filtres de type mutate ne fonctionnent pas et rendent impossible l'envoi des données. Le champ add_tag ne semble avoir aucun effet.
La configuration suivante fonctionne mais le tag n'est pas ajouté
```
grok {
match => [ "message", "
Bonjour,
Est-ce que le changement de configuration redémarre logstash ou pas ? Actuellement je redémarre toujours mais je ne sais jamais quand les modifications sont prises en compte
Il faut redémarrer logstash lors de changement de configuration pour qu'elle soit prise en compte.
Pour info l'outil de test de configuration ne fonctionne jamais.
L'outil de test de configuration n'est juste qu'un test de syntaxe de logstash fourni par l'option " --configtest". Aujourd'hui il émet un avertissement en première ligne due à l'utilisation de alpine comme OS suivie par le message "Configuration OK" qui indique que la syntaxe de la configuration est correcte.
Suite à une modification de notre backend, celui-ci été planté sur le téléchargement du fichier de configuration, le problème est en cours d'être fixé. Merci pour la remonter du problème.
Est-ce qu'il y a une restriction à votre niveau car en local la configuration fonctionne bien ?
Concernant le tag dans json, celui-ci est bien ajouté :
Soit ["_jsonparsefailure"], quand il n'arrive pas a parser de json, soit ["application"] dans votre configuration s'il arrive pas à décoder le json.
Concernant le "remove_field" en "mutate", il n'est pas possible de supprimer full_message, qui n'est généré que lors de l'output.
La règle par défaut est de prendre le champ full_message s'il existe déjà ou alors prendre le cas échéant le champ message.
Je vous préconise les grok/mutate suivant pour faire du RFC5424 en input TCP :
grok {
match => { "message" => "(?m)%{SYSLOG5424LINE}" }
}
syslog_pri { }
if !("_grokparsefailure" in [tags]) {
mutate {
replace => [ "logsource", "%{syslog5424_host}" ]
replace => [ "message", "%{syslog5424_msg}" ]
replace => [ "timestamp", "%{syslog5424_ts}" ]
replace => [ "priority", "%{syslog5424_pri}" ]
replace => [ "program", "%{syslog5424_app}" ]
replace => [ "pid", "%{syslog5424_proc}" ]
replace => [ "syslog_version", "%{syslog5424_ver}" ]
}
mutate {
remove_field => [ "syslog5424_host", "syslog5424_msg", "syslog5424_ts", "syslog5424_pri", "syslog5424_app", "syslog5424_proc", "syslog5424_ver" ]
}
Merci pour les explications. Initialement je voulais supprimer full_message car le champ message existe déjà et je ne souhaitais pas avoir l'information dupliquée.
Est-ce que vous prenez les 2 champs pour calculer X-OVH-CONTENT-SIZE ?
Est-ce que vous prenez les 2 champs pour calculer X-OVH-CONTENT-SIZE ?
Effectivement le champ "full_message" est copié par défaut alors qu'il est optionnel dans le protocole GELF.
Nous allons changer cette partie pour ne pas copier le champ" message" si "full_message" est vide ou non présent.
Les 2 champs "full_message" et le champ "message" sont comptabilité dans "X-OVH-CONTENT-SIZE".
Le changement cité ci-dessus a été poussé en production.
Pour prendre en compte ses modifications, veuillez "arrêter" puis "démarrer" votre "Outil de collecte".
Un grand merci pour toutes ces remarques constructives.