1. La gestión de los plugins #
Ampliar Logstash.
Los comandos #
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| Tipo | Ejemplos |
|---|---|
| input | beats, kafka, jdbc, s3, http |
| filter | grok, dissect, mutate, translate, geoip |
| output | elasticsearch, s3, kafka, file |
| codec | json, multiline, plain |
Error común: Instalar plugins a mano en cada servidor: las versiones divergen y un nuevo despliegue los pierde. Construye una imagen Docker o un paquete que incluya los plugins necesarios.
2. Elastic Common Schema #
Campos comunes.
Por qué ECS #
ECS define nombres de campos comunes: source.ip, host.name, http.response.status_code, log.level, event.category… Cuando todas las fuentes los respetan, una misma consulta, panel o regla de detección funciona con todos los datos.
| Campo propio | Campo 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]"
}
}
}El modo ecs_compatibility #
Desde la versión 8, los plugins de Logstash generan por defecto campos compatibles con ECS (pipeline.ecs_compatibility: v8): el input beats, grok con los patrones ECS, geoip… El modo disabled recupera el comportamiento antiguo, útil para migrar pipelines heredados.
Buena práctica: Coloca tus campos de negocio fuera de los espacios de ECS, bajo un prefijo propio (labels.*para palabras clave sencillas, omiapp.*): así no entrarán en conflicto con una futura versión de ECS.
