Registro centralizado: Parte 4 — Graylog

Graylog — plataforma para la gestión centralizada de logs. A diferencia de ELK, que se monta a partir de componentes separados, Graylog está diseñado desde el inicio como un sistema único: recepción, procesamiento, enrutamiento, almacenamiento, búsqueda, alertas y control de acceso se configuran en una sola interfaz web.

Licencia y ediciones

La edición gratuita se llama Graylog Open. Desde la versión 4.0 (2021) todas sus distribuciones se publican bajo la Server Side Public License (SSPL). Esta licencia está basada en la GPL, pero además requiere revelar el código fuente del servicio si el programa se ofrece como servicio en la nube. La OSI no la reconoce como licencia abierta, por lo que es más preciso llamar a Graylog Open un producto con código fuente disponible.

Para una empresa que despliega Graylog para sus propios logs, SSPL no impone restricciones. Además de Open hay ediciones de pago con funciones adicionales —archivado, auditoría ampliada, funciones para investigación de incidentes de seguridad.

Componentes

• Graylog Server — recepción de mensajes, procesamiento, interfaz web, usuarios, streams, alertas.
• MongoDB — almacena la configuración, usuarios y metadatos, pero no los logs en sí. Graylog 7.0 requiere MongoDB no inferior a 7.0.
• Almacenamiento de logs — motor de búsqueda donde se indexan los mensajes:
  • Graylog Data Node — opción preferida: un nodo gestionado por el propio Graylog basado en OpenSearch. Graylog se encarga de su configuración, certificados y actualizaciones;
  • OpenSearch autogestionado — si ya existe un clúster o se necesita control total. El soporte de OpenSearch 1.x en Graylog 7.0 se declara obsoleto y será eliminado en 8.0;
  • Elasticsearch — a partir de Graylog 7.0 el uso de Elasticsearch se declara obsoleto y será eliminado por completo en Graylog 8.0. No se recomienda elegirlo para nuevas instalaciones.
• Graylog Sidecar — agente ligero de gestión: desde la interfaz de Graylog configura y arranca recolectores de logs en los servidores, por ejemplo Filebeat o NXLog.

Cómo se procesan los mensajes

1. Inputs (Entradas). Graylog acepta datos por syslog (UDP/TCP), en formato GELF, vía Beats, por HTTP y otros protocolos.
2. Extracción y pipelines. Extractores y pipelines de procesamiento (Pipelines) analizan los mensajes en campos, descartan lo innecesario y añaden metadatos.
3. Streams (Flujos). Reglas distribuyen los mensajes entre streams: logs de servidores web, registros de seguridad, logs de una aplicación concreta. Para cada stream se define su propio conjunto de índices, periodo de retención y permisos de acceso.
4. Almacenamiento. Los mensajes se indexan en Data Node u OpenSearch.
5. Búsqueda, dashboards, alertas. Todo —en una sola interfaz.

GELF

Graylog Extended Log Format — formato de mensajes en JSON que elimina las limitaciones del syslog clásico: no hay un límite rígido de longitud, los campos se transmiten de forma explícita. Existen librerías GELF para la mayoría de los lenguajes, y Docker puede enviar la salida de los contenedores a GELF con su driver de logging por defecto. Mensaje mínimo:

{
  "version": "1.1",
  "host": "web-01",
  "short_message": "payment failed",
  "level": 3,
  "_service": "payments",
  "_order_id": 1842
}

Los campos adicionales comienzan con un guion bajo; level — el nivel de severidad según la numeración de syslog (3 — error).

Pipelines de procesamiento

Una regla de pipeline se escribe en un lenguaje sencillo y se dispara para los mensajes que cumplan la condición. Ejemplo: analizar una cadena key=value y eliminar el campo original:

rule "parse key-value"
when
  has_field("message") && contains(to_string($message.message), "=")
then
  set_fields(key_value(to_string($message.message)));
end

Las reglas se agrupan en etapas, las etapas en un pipeline, y el pipeline se conecta a los streams necesarios.

Instalación

La forma oficial para familiarizarse y para instalaciones pequeñas es Docker Compose. En el repositorio Graylog2/docker-compose hay archivos listos para la edición Open: tres servicios — MongoDB, Data Node y Graylog. Antes de arrancar se configuran un secreto para cifrar contraseñas y el hash de la contraseña del administrador; para almacenar datos se necesitan volúmenes separados para cada uno de los tres servicios. Para entornos de producción la documentación describe la instalación desde paquetes y un clúster de varios nodos.

La compatibilidad entre versiones de Graylog, MongoDB y OpenSearch está descrita en la matriz de compatibilidad en la documentación. Consúltala antes de cada actualización: las versiones mayores de Graylog regularmente elevan los requisitos mínimos.

Ventajas

• Sistema único. Recepción, procesamiento, almacenamiento, búsqueda y alertas se configuran en un único lugar.
• Streams y permisos. Cómodo para separar logs por equipos y asignar accesos distintos.
• Pipelines de procesamiento sin necesidad de un Logstash separado.
• Data Node libera al administrador de gran parte del trabajo de mantenimiento de OpenSearch.
• Sidecar — gestión centralizada de los recolectores en los servidores.

Desventajas

• Varios componentes. MongoDB, Data Node y Graylog Server deben actualizarse de forma coordinada.
• Visualización más sencilla que en Kibana u OpenSearch Dashboards.
• Licencia SSPL para la edición gratuita y algunas funciones solo en las versiones de pago.
• Recursos. Debajo del almacenamiento sigue habiendo un motor de búsqueda con índice de texto completo.

Errores comunes

• Nueva instalación sobre Elasticsearch. En Graylog 8.0 quitarán el soporte y habrá que migrar.
• MongoDB obsoleto. Después de actualizar a Graylog 7.0 el servidor no pasará la comprobación al arrancar si MongoDB es anterior a 7.0.
• Syslog por UDP para logs importantes. UDP no garantiza entrega; para registros de seguridad es mejor TCP con TLS o GELF por TCP.
• Todo en un mismo stream. Sin separación en streams no se pueden definir diferentes periodos de retención ni permisos de acceso.

Cuándo elegir Graylog

Graylog es adecuado para equipos pequeños y medianos que necesitan un sistema de logs listo para usar con control de acceso, reglas de procesamiento y alertas, pero no quieren montar y configurar un stack a partir de componentes separados. Si lo más importante es ahorro de recursos y los logs deben estar junto con métricas de Prometheus, vale la pena considerar Loki.