Monitoreo de logs centralizado con ELK Stack (Elasticsearch, Logstash, Kibana)

Introducción

En entornos de producción modernos, la dispersión de logs entre múltiples servidores (aplicaciones web, bases de datos, balanceadores de carga) representa un desafío crítico para la operación y la resolución de incidentes. Sin una centralización efectiva, el diagnóstico de fallos se convierte en una tarea manual, lenta y propensa a errores. ELK Stack (Elasticsearch, Logstash, Kibana) se ha consolidado como la solución open-source de facto para la agregación, procesamiento y visualización de logs a escala.

Este artículo desglosa la implementación de un pipeline completo de monitoreo centralizado con ELK, desde la arquitectura base hasta la configuración de Logstash para parsing y el envío seguro de logs desde clientes remotos mediante Filebeat. Se asume un entorno Linux (Ubuntu 22.04 LTS) y versiones recientes de la pila (8.x).

Arquitectura del Pipeline ELK

Antes de profundizar en la configuración, es vital comprender el flujo de datos. Un pipeline típico consta de cuatro capas:

1. Shipper (Filebeat): Agente ligero instalado en cada servidor fuente. Lee archivos de log, los envía de forma confiable a Logstash (o directamente a Elasticsearch) utilizando un protocolo de red (Beats).
2. Parser/Transformador (Logstash): Servidor central que recibe eventos, los parsea (estructura), los filtra, los enriquece (ej. añadiendo geolocalización desde una IP) y los envía a Elasticsearch.
3. Almacenamiento/Búsqueda (Elasticsearch): Motor de búsqueda y análisis distribuido. Indexa los datos recibidos y los expone a través de una API RESTful.
4. Visualización (Kibana): Interfaz web que se conecta a Elasticsearch para construir dashboards, realizar búsquedas ad-hoc y generar alertas.

Nota importante sobre versiones: Es imperativo mantener la compatibilidad de versiones entre todos los componentes de la pila. Utilizar Elasticsearch 8.4 con Logstash 8.4 y Filebeat 8.4. Mezclar versiones puede generar fallos en los protocolos de comunicación interna.

Instalación y Configuración de Elasticsearch

Elasticsearch es el núcleo del sistema. Su configuración debe priorizar la estabilidad y la seguridad.

Instalación desde el repositorio oficial

# Importar la clave GPG oficial de Elastic
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg

# Añadir el repositorio (ajustar para la versión 8.x)
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list

# Actualizar e instalar
sudo apt-get update && sudo apt-get install elasticsearch

¿Por qué este método? Instalar desde el .deb oficial garantiza que las dependencias (como la JVM empaquetada de Elastic) estén correctamente gestionadas y que las actualizaciones de seguridad se apliquen mediante apt upgrade.

Configuración crítica (/etc/elasticsearch/elasticsearch.yml)

# --- Red y Descubrimiento ---
# Escuchar en todas las interfaces (ajustar con firewall para restringir)
network.host: 0.0.0.0
# Puerto de comunicación entre nodos
transport.port: 9300

# Configuración para un clúster de un solo nodo (entornos de desarrollo/prueba)
# En producción, se debe configurar discovery.seed_hosts y cluster.initial_master_nodes
discovery.type: single-node

# --- Seguridad (Obligatorio en 8.x) ---
# Habilitar TLS para la capa de transporte
xpack.security.transport.ssl.enabled: true
# Autogenerar certificados (o especificar rutas)
xpack.security.enabled: true

# --- Memoria y Heap ---
# NO configurar aquí. Se configura en jvm.options.d/ o con variables de entorno
# ES_HEAP_SIZE=4g (máximo 50% de la RAM del servidor, no superar 32GB)

El porqué de discovery.type: single-node: En entornos de laboratorio o servidores pequeños, esta configuración evita que Elasticsearch intente descubrir otros nodos y falle. En producción con múltiples nodos, esta línea debe eliminarse y configurarse discovery.seed_hosts.

Configuración de la memoria Heap

# Crear archivo de configuración JVM personalizado
sudo mkdir -p /etc/elasticsearch/jvm.options.d/
cat <<EOF | sudo tee /etc/elasticsearch/jvm.options.d/heap.options
-Xms4g
-Xmx4g

EOF

¿Por qué configurarlo así? La JVM de Elasticsearch tiene un comportamiento complejo. Establecer -Xms y -Xmx al mismo valor evita que el recolector de basura tenga que renegociar el tamaño del heap en tiempo de ejecución, mejorando la predictibilidad del rendimiento.

Inicio y verificación

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch

# Verificar que esté corriendo y autenticarse (se genera contraseña por defecto)
sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic -i
# Probar conexión
curl -k -u elastic:<password> https://localhost:9200

Alerta de seguridad: La contraseña del usuario elastic (superusuario) se genera aleatoriamente durante la primera instalación. Guárdala en un gestor de contraseñas. Para entornos productivos, crea usuarios de API con roles específicos (ej. logstash_writer, kibana_system).

Instalación y Configuración de Kibana

Kibana es la ventana a los datos. Su configuración principal es apuntar al Elasticsearch correcto.

Instalación

sudo apt-get install kibana

Configuración (/etc/kibana/kibana.yml)

# --- Servidor Kibana ---
# Escuchar en todas las interfaces (o en localhost si usas proxy inverso)
server.host: "0.0.0.0"
# Puerto por defecto
server.port: 5601

# --- Conexión a Elasticsearch ---
elasticsearch.hosts: ["https://localhost:9200"]
# Usar HTTPS y autenticación
elasticsearch.username: "kibana_system"
elasticsearch.password: "<contraseña_generada_para_kibana>"

# --- SSL ---
# Deshabilitar verificación SSL si usas certificados autofirmados (SOLO PRUEBAS)
elasticsearch.ssl.verificationMode: none

# --- Localización (opcional) ---
i18n.locale: "es-ES"

Nota sobre kibana_system: Este usuario es creado automáticamente por Elasticsearch al habilitar la seguridad. No es un usuario para login humano, sino para que Kibana se comunique con el backend. Su contraseña se puede resetear desde la consola de Elasticsearch.

Inicio

sudo systemctl enable kibana
sudo systemctl start kibana
# Acceder a http://<ip-servidor>:5601

Instalación y Configuración de Logstash

Logstash actúa como el cerebro del pipeline. Aquí es donde se transforman líneas de texto plano en documentos JSON estructurados.

Instalación

sudo apt-get install logstash

Pipeline de ejemplo: Parseo de logs de Nginx

Crear un archivo de configuración en /etc/logstash/conf.d/nginx-pipeline.conf.

input {
  beats {
    port => 5044
    # Habilitar SSL (MUY RECOMENDADO)
    ssl => true
    ssl_certificate => "/etc/logstash/certs/logstash.crt"
    ssl_key => "/etc/logstash/certs/logstash.key"
  }
}

filter {
  if [fields][service] == "nginx" {
    grok {
      match => { "message" => "%{COMBINEDAPACHELOG}" }
    }

    # Extraer timestamp del log, no del momento de recepción
    date {
      match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
      target => "@timestamp"
    }

    # Geolocalización simple
    geoip {
      source => "clientip"
      target => "geoip"
      database => "/usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-filter-geoip-7.2.10/vendor/GeoLite2-City.mmdb"
    }

    # Eliminar campos innecesarios para ahorrar espacio
    mutate {
      remove_field => ["message", "path", "host", "tags"]
    }
  }
}

output {
  elasticsearch {
    hosts => ["https://localhost:9200"]
    user => "logstash_writer"
    password => "<contraseña>"
    index => "nginx-logs-%{+YYYY.MM.dd}"
    ssl => true
    cacert => "/etc/logstash/certs/ca.crt"
  }
}

Explicación detallada del pipeline:

• input { beats { ... } }:
  • port => 5044: Puerto estándar para el protocolo Beats.
  • ssl: Obligatorio en producción para evitar que logs viajen en texto plano. Los certificados pueden ser autofirmados, pero deben ser los mismos que confíen los clientes Filebeat.
• filter { grok { ... } }:
  • %{COMBINEDAPACHELOG} es un patrón predefinido de Logstash que parsea automáticamente logs en formato Combined de Apache/Nginx. Extrae campos como clientip, ident, auth, timestamp, verb, request, httpversion, response, bytes, referrer, agent.
  • El bloque if [fields][service] == "nginx" permite aplicar filtros diferentes según el tipo de log (ej. un pipeline para syslog, otro para logs de aplicación Java).
• output { elasticsearch { ... } }:
  • index => "nginx-logs-%{+YYYY.MM.dd}": Crea un índice diario. Esto es crucial para la retención de datos (puedes eliminar índices de más de 30 días usando Curator o ILM).
  • user y password: Crear un usuario en Elasticsearch con el rol logstash_writer que tenga permisos de escritura en los índices nginx-logs-*.

Creación de usuario para Logstash en Elasticsearch

# Desde el servidor Elasticsearch
sudo /usr/share/elasticsearch/bin/elasticsearch-users useradd logstash_writer -p <contraseña> -r logstash_writer

Nota sobre roles: En versiones 8.x, se recomienda usar el API de seguridad de Elasticsearch para crear roles personalizados en lugar de los roles predefinidos. El rol logstash_writer por defecto es suficiente para entornos simples, pero en producción, créalo con permisos mínimos (create_index, write, manage sobre el patrón de índices).

Configuración del Cliente: Filebeat

Filebeat es el shipper. Su configuración es ligera y debe ser segura.

Instalación en el servidor de aplicación (ej. servidor Nginx)

sudo apt-get install filebeat

Configuración (/etc/filebeat/filebeat.yml)

# ============================== Filebeat inputs ===============================
filebeat.inputs:
- type: filestream
  enabled: true
  id: nginx-access
  paths:
    - /var/log/nginx/access.log
  fields:
    service: nginx
    environment: production
  fields_under_root: true

# ============================== Outputs ======================================
output.logstash:
  hosts: ["<ip-logstash>:5044"]
  # Habilitar SSL
  ssl.certificate_authorities: ["/etc/filebeat/certs/ca.crt"]
  ssl.certificate: "/etc/filebeat/certs/filebeat.crt"
  ssl.key: "/etc/filebeat/certs/filebeat.key"

# ============================== Processors ===================================
processors:
  - add_host_metadata:
      when.not.contains.tags: forwarded
  - add_cloud_metadata: ~
  - add_docker_metadata: ~

Explicación de la configuración:

• type: filestream: El nuevo input de Filebeat (reemplaza a log). Es más eficiente y maneja mejor la rotación de logs (log rotation).
• fields: Añade metadatos personalizados. El campo service: nginx es el que Logstash usará en su condicional if [fields][service].
• output.logstash: Envía los eventos directamente a Logstash, no a Elasticsearch. Esto permite el filtrado centralizado.
• processors: Añaden información contextual (IP del host, metadata de cloud o Docker) sin necesidad de que Logstash lo haga, reduciendo la carga en el servidor central.

Gestión de certificados SSL para Filebeat

La comunicación entre Filebeat y Logstash debe ser cifrada. La forma más sencilla es usar una Autoridad Certificadora (CA) interna.

# En el servidor Logstash (o en una máquina de gestión)
# 1. Crear CA
openssl req -x509 -days 3650 -nodes -newkey rsa:2048 \
  -keyout /etc/logstash/certs/ca.key \
  -out /etc/logstash/certs/ca.crt \
  -subj "/CN=ELK-CA"

# 2. Crear certificado para Logstash (servidor)
openssl req -nodes -newkey rsa:2048 \
  -keyout /etc/logstash/certs/logstash.key \
  -out /etc/logstash/certs/logstash.csr \
  -subj "/CN=logstash.sysprovider.local"

openssl x509 -req -days 365 \
  -in /etc/logstash/certs/logstash.csr \
  -CA /etc/logstash/certs/ca.crt \
  -CAkey /etc/logstash/certs/ca.key \
  -CAcreateserial \
  -out /etc/logstash/certs/logstash.crt

# 3. Copiar ca.crt, filebeat.crt y filebeat.key a cada servidor Filebeat
#    (en /etc/filebeat/certs/)

¿Por qué este proceso? No usar SSL en el pipeline Beats es una vulnerabilidad crítica. Cualquier máquina en la misma red podría enviar logs falsos a tu Logstash, inyectando datos maliciosos o simplemente saturando el sistema. La autenticación mutua (mTLS) no es obligatoria pero es altamente recomendable.

Visualización en Kibana: Creación de un Dashboard

Una vez que los datos fluyen, el siguiente paso es construir un dashboard.

Paso 1: Crear un Index Pattern

1. Ve a Stack Management > Kibana > Data Views.
2. Haz clic en Create data view.
3. Nombre: Nginx Logs.
4. Index pattern: nginx-logs-* (debe coincidir con el patrón definido en Logstash).
5. Timestamp field: @timestamp.
6. Guarda.

Paso 2: Crear una Visualización (Ej: Códigos de respuesta HTTP)

1. Ve a Analytics > Visualize Library.
2. Create visualization.
3. Selecciona Pie (gráfico de pastel).
4. Selecciona la data view Nginx Logs.
5. Buckets: Añade un bucket de tipo Split slices.
   • Aggregation: Terms
   • Field: response.keyword (el campo response mapeado como keyword).
   • Size: 10.
6. Haz clic en Save y nómbrala HTTP Status Codes.

Paso 3: Montar el Dashboard

1. Analytics > Dashboard > Create dashboard.
2. Add la visualización creada.
3. Añade otras visualizaciones útiles:
   • Line chart: Número de requests por minuto (usando @timestamp y count).
   • Tag cloud: Top URLs solicitadas (campo request.keyword).
   • Data table: `Top 5 IPs con más