Registro centralizado: Parte 2 — ELK Stack (Elasticsearch, Logstash, Kibana)

ELK Stack — el conjunto de programas más conocido para el registro centralizado. El nombre está formado por las primeras letras de los tres componentes de la compañía Elastic: Elasticsearch, Logstash y Kibana. Juntos recogen los logs, los descomponen en campos, los almacenan con un índice de texto completo y los muestran en una interfaz web.

Componentes

• Elasticsearch — sistema de búsqueda y analítica distribuido basado en Apache Lucene. Almacena entradas en índices, realiza búsquedas de texto completo y agregaciones, y escala añadiendo nodos.
• Logstash — canal de procesamiento: recibe datos de distintas fuentes, los parsea, filtra, enriquece y envía a Elasticsearch. Funciona con decenas de plugins de entrada y salida.
• Kibana — interfaz web para búsqueda, paneles, alertas y administración del clúster.
• Beats y Elastic Agent — agentes en los servidores. Filebeat lee archivos de logs, Metricbeat recopila métricas. Elastic Agent unifica sus funciones en un solo agente, que se gestiona de forma centralizada mediante Fleet en Kibana.

Por eso a la suite a menudo se le llama Elastic Stack: en ella hay más agentes que letras en el nombre.

Cómo fluyen los datos

1. Un agente en el servidor lee el log y envía las entradas a Logstash o directamente a Elasticsearch.
2. Logstash o la canalización de ingestión dentro de Elasticsearch (ingest pipeline) descomponen las líneas en campos.
3. Elasticsearch indexa las entradas.
4. En Kibana se buscan, se construyen gráficos y se configuran alertas.

Logstash es necesario cuando el procesamiento es complejo o las fuentes son muchas. Para casos sencillos basta con el agente y un ingest pipeline — eso elimina un componente.

Licencia

La historia de las licencias de Elastic es relevante para la elección:

• hasta 2021 Elasticsearch y Kibana se distribuían bajo Apache 2.0;
• en 2021 Elastic pasó a ofrecer dos opciones de licencia — SSPL y Elastic License 2.0. Ninguna de las dos es reconocida como abierta por OSI; como respuesta surgió el fork OpenSearch;
• el 29 de agosto de 2024 Elastic anunció la adición de una tercera opción — AGPLv3, aprobada por OSI. Desde entonces Elasticsearch y Kibana se pueden volver a considerar software abierto.

Para una empresa que despliega ELK en sus propios servidores para sus propios logs, ninguna de estas licencias impone restricciones. Son importantes para quienes venden Elasticsearch como servicio en la nube o lo integran en su producto.

Separado de la licencia del código existen suscripciones de Elastic. El nivel gratuito Basic incluye protección básica — usuarios, roles, cifrado de conexiones — y alertas de Kibana con un conjunto limitado de canales de entrega. Machine learning, parte de las funciones de Elastic Security y las integraciones avanzadas están disponibles en suscripciones de pago.

Lenguaje de consultas ES|QL

Además del clásico Query DSL y KQL en Kibana, Elasticsearch tiene el lenguaje ES|QL. La consulta se construye como una cadena de pasos separados por la barra vertical. ES|QL apareció en la versión 8.11 como función experimental y se hizo generalmente disponible en la versión 8.14.

FROM logs-*
| WHERE log.level == "error"
| STATS errors = COUNT(*) BY service.name
| SORT errors DESC
| LIMIT 10

La consulta selecciona errores de los índices de logs, los cuenta por servicio y muestra los diez servicios con más errores.

Cómo desplegar para probar

Para un primer contacto local Elastic ofrece el script start-local: descarga las versiones actuales de Elasticsearch y Kibana y las arranca en Docker. Es mejor tomar el comando y la descripción de la documentación oficial — se actualiza junto con las versiones. Para entornos productivos la documentación incluye instrucciones separadas: clúster de varios nodos con Docker Compose, instalación desde paquetes DEB y RPM, despliegue en Kubernetes mediante el operador ECK.

Al instalar por cuenta propia es importante:

• asignar suficiente memoria a Elasticsearch y no darle toda la RAM del servidor — parte es necesaria para la caché de archivos del sistema;
• no abrir el puerto 9200 a Internet;
• mantener habilitadas la autenticación y TLS, que en las versiones modernas se configuran en el primer arranque.

Retención: ILM

Los índices de logs crecen constantemente, por eso se gestionan mediante una política de ciclo de vida (Index Lifecycle Management, ILM). Esta traslada los índices por fases — hot, warm, cold, frozen, delete — y ejecuta en cada una acciones: crear un índice nuevo, compactar, mover a nodos más baratos, eliminar.

Ejemplo de política de la documentación de Elastic: se crea un índice nuevo cuando el shard primario alcanza 25 GB, y el índice se elimina tras 30 días:

PUT _ilm/policy/logs-30d
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": { "max_primary_shard_size": "25GB" }
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": { "delete": {} }
      }
    }
  }
}

Sin una política así, el disco del clúster tarde o temprano se llenará y Elasticsearch dejará de aceptar escrituras.

Ventajas

• Búsqueda. Búsqueda de texto completo y agregaciones sobre grandes volúmenes de logs.
• Analítica y visualización. Kibana ofrece paneles (dashboards), exploración de datos y alertas.
• Ecosistema. Integraciones listas para sistemas populares, agentes para todas las plataformas principales, y una gran comunidad.
• Escalado. El clúster crece añadiendo nodos.

Inconvenientes

• Recursos. Elasticsearch y Logstash demandan memoria, CPU y disco; el índice de texto completo aumenta el volumen de datos almacenados.
• Complejidad de operación. Hay que vigilar shards, índices, políticas de retención, actualizaciones y copias de seguridad.
• Parte de las funciones es de pago. Machine learning y funciones avanzadas de seguridad requieren suscripción.

Errores típicos

• Demasiados shards pequeños. Un índice por día con varios shards por índice rápidamente produce miles de shards, y el clúster gasta recursos en su gestión.
• Sin política ILM. El disco se llena y la escritura se detiene.
• Clúster abierto en Internet. Instancias de Elasticsearch sin protección son una fuente habitual de fugas de datos.
• Un nodo sin réplicas ni snapshots. La caída de un disco implica pérdida de todos los logs; las copias se hacen mediante snapshot a un almacenamiento separado.

Cuándo elegir ELK

ELK es adecuado si se necesita búsqueda de texto completo sobre grandes volúmenes de logs, analítica avanzada y hay personal para operar el clúster. Para infraestructuras pequeñas, donde los logs se usan principalmente para investigar fallos, suele ser sobredimensionado: Loki o Graylog consumen menos recursos y son más sencillos de mantener.