1. La gestion des plugins #
Étendre Logstash.
Les commandes #
bin/logstash-plugin list --verbose # plugins installés et versions
bin/logstash-plugin install logstash-filter-translate
bin/logstash-plugin update logstash-input-kafka
bin/logstash-plugin remove logstash-output-xyz
# Hors ligne : préparer un paquet sur une machine connectée, l'installer ailleurs
bin/logstash-plugin prepare-offline-pack logstash-filter-translate
bin/logstash-plugin install file:///tmp/logstash-offline-plugins-9.1.0.zip| Type | Exemples |
|---|---|
| input | beats, kafka, jdbc, s3, http |
| filter | grok, dissect, mutate, translate, geoip |
| output | elasticsearch, s3, kafka, file |
| codec | json, multiline, plain |
Erreur courante : Installer des plugins à la main sur chaque serveur : les versions divergent et un redéploiement les perd. Construisez une image Docker ou un paquet qui embarque les plugins nécessaires.
2. Elastic Common Schema #
Des champs communs.
Pourquoi ECS #
ECS définit des noms de champs communs : source.ip, host.name, http.response.status_code, log.level, event.category… Quand toutes les sources les respectent, une même requête, un même tableau de bord ou une même règle de détection fonctionne sur toutes les données.
| Champ maison | Champ ECS |
|---|---|
| clientip | source.ip |
| status | http.response.status_code |
| level | log.level |
| server | host.name |
| user | user.name |
filter {
mutate {
rename => {
"clientip" => "[source][ip]"
"status" => "[http][response][status_code]"
"level" => "[log][level]"
}
}
}Le mode ecs_compatibility #
Depuis la version 8, les plugins Logstash produisent par défaut des champs compatibles ECS (pipeline.ecs_compatibility: v8) : l'input beats, grok avec les motifs ECS, geoip… Le mode disabled retrouve l'ancien comportement, utile pour migrer d'anciens pipelines.
Bonne pratique : Placez vos champs métier hors des espaces ECS, sous un préfixe à vous (labels.*pour des mots-clés simples, oumonapp.*) : ils ne risquent pas d'entrer en conflit avec une future version d'ECS.
