Registro centralizado: Parte 1 — ¿Por qué recopilar los registros en un solo lugar?

Las métricas muestran que algo anda mal con el sistema: aumentó el tiempo de respuesta, se terminó la memoria, cayó la proporción de solicitudes exitosas. Para entender por qué ocurrió esto hacen falta logs — registros de eventos que escriben el sistema operativo, el servidor web, la base de datos y la propia aplicación. En el log se fija qué pasó, cuándo, en qué servidor y en qué componente.

Mientras hay un solo servidor, los registros se pueden leer directamente en él. Cuando los servidores y servicios son varios, ese enfoque deja de funcionar y los registros se recogen en un único lugar.

Por qué es malo tener logs dispersos por los servidores

• Son difíciles de recopilar. Para analizar una falla hay que entrar por SSH en varias máquinas y buscar los archivos necesarios.
• No se pueden correlacionar los eventos. Una solicitud pasó por el balanceador, la aplicación y la base de datos, pero las entradas sobre ella están en tres sitios diferentes y en tres formatos distintos.
• La búsqueda es lenta. grep en archivos de una decena de servidores funciona mientras los logs son pocos; al crecer el volumen se vuelve impracticable.
• Los logs se pierden. Los archivos se rotan y eliminan, y si el servidor falla o lo comprometen, las entradas en él pueden desaparecer o ser modificadas justo cuando más se necesitan.

Qué aporta la recopilación centralizada

El registro centralizado es la recolección de logs de todos los servidores y servicios en un almacén común, donde se puede buscar, construir gráficos y configurar alertas.

• Un punto de acceso. Todas las entradas están disponibles en una interfaz web; no hace falta acceder a servidores individuales.
• Búsqueda rápida. Filtros por tiempo, servidor, servicio, nivel de severidad y contenido.
• Correlación de eventos. Las entradas de diferentes componentes se ven en una misma línea temporal; si la aplicación transmite un identificador de solicitud, su recorrido se traza completo.
• Conservación. Una copia de los logs se guarda separada de los servidores que los generaron.
• Alertas. Llega una notificación cuando aumenta el número de errores o aparece una entrada sospechosa, por ejemplo una serie de inicios de sesión fallidos.

De qué se compone el sistema

Cualquier sistema de registro centralizado realiza los mismos pasos:

1. Recolección. Un agente en el servidor lee los archivos de log, el registro del sistema o la salida de los contenedores. Ejemplos de agentes: Filebeat, Fluent Bit, Grafana Alloy, Vector.
2. Transmisión. Las entradas se envían al almacén por syslog, HTTP o por el protocolo propio del sistema.
3. Procesamiento. Las líneas se parsean en campos, se descarta lo innecesario y se añaden el nombre del host, el entorno y el nombre del servicio.
4. Almacenamiento e indexación. Las entradas se guardan de forma que sea posible buscarlas rápidamente en el periodo requerido.
5. Búsqueda y visualización. Consultas, dashboards, informes.
6. Alertas. Reglas según las cuales el sistema notifica sobre un problema.

Para recopilar logs desde clientes remotos se puede prescindir de una pila completa — esta opción se explica en el artículo «Cómo organizar la recolección de logs desde clientes remotos por HTTP».

Logs estructurados

La mayor parte del tiempo al implementar se dedica a parsear las líneas. Una línea como

2026-09-22 10:15:03 ERROR Payment failed for order 1842: timeout

hay que parsearla con expresiones regulares, y cualquier cambio de formato rompe el parseo. Si la aplicación escribe el log directamente en JSON, los campos ya están separados:

{"time":"2026-09-22T10:15:03Z","level":"error","service":"payments","order_id":1842,"msg":"payment failed","error":"timeout"}

Con una entrada así se pueden filtrar todos los errores del servicio payments o encontrar todo lo relacionado con la orden 1842, sin configuración adicional. Reglas prácticas:

• un evento — una línea;
• hora en UTC y en formato ISO 8601;
• nombres de campos constantes en todos los servicios: level, service, msg, request_id;
• el identificador de la solicitud se transmite entre servicios y aparece en cada entrada.

Niveles de severidad

El estándar syslog (RFC 5424) define ocho niveles — de 0 (emergency, el sistema no funciona) a 7 (debug, mensajes de depuración). En las aplicaciones normalmente se usa un conjunto reducido: debug, info, warning, error, critical.

El nivel debug es mejor desactivarlo en el entorno de producción: aumenta el volumen de logs por varios órdenes de magnitud y, con ello, el coste de almacenamiento. Si las entradas de depuración son necesarias para analizar un problema concreto, se activan de forma temporal.

Cuánto conservar

El periodo de retención lo determina la tarea, no el espacio libre en disco:

• Logs operativos para analizar fallos normalmente se necesitan de los últimos días o semanas.
• Registros de seguridad — inicios de sesión, cambios de permisos, acciones de administradores — se conservan más tiempo para investigar un incidente descubierto meses después.
• Entradas de depuración bastan conservarlas unos pocos días.

En todos los sistemas de este ciclo el periodo de retención se establece mediante una política: los datos antiguos se eliminan automáticamente. Sin esa política el almacén tarde o temprano se llenará.

Datos personales en los logs

A los logs fácilmente llegan datos de usuarios: correos electrónicos, teléfonos, nombres, contenido de formularios. Si un log contiene datos personales, su recolección y almacenamiento se consideran tratamiento de datos personales y están sujetos a los requisitos de la 152-ФЗ. En particular, según la parte 7 del artículo 5 de la ley, los datos personales se conservan no más de lo que exigen los fines del tratamiento, salvo que el plazo lo establezca una ley federal o un contrato.

En la práctica esto significa:

• no escribir en los logs contraseñas, tokens, números de tarjetas ni el contenido de formularios completo;
• enmascarar o eliminar los datos personales en la fase de procesamiento, antes de que lleguen al almacén;
• limitar el acceso a los logs al grupo de personas que realmente lo necesita;
• fijar un periodo de retención y eliminar los datos una vez cumplido.

Errores típicos

• Logs sin un formato único. Cada servicio escribe a su manera y hay que crear un parser para cada uno.
• No hay política de retención. El almacén crece hasta que se llena el disco y deja de aceptar nuevas entradas.
• Nivel de depuración en producción. El volumen de logs crece exponencialmente sin beneficio.
• Secretos en los logs. Tokens y contraseñas que aparecen en los logs están disponibles para cualquiera que tenga acceso al sistema de logging.
• Almacenamiento en el mismo servidor. Si el servidor falla, se pierden también los logs que se necesitan para el análisis.

Qué sistema elegir

En este ciclo se analizan cuatro sistemas comunes:

• ELK Stack (Elasticsearch, Logstash, Kibana) — búsqueda de texto completo y analítica avanzada, pero con altos requisitos de recursos.
• OpenSearch — fork abierto de Elasticsearch y Kibana con capacidades similares.
• Graylog — plataforma lista para logs con pipelines, reglas de procesamiento y control de acceso.
• Loki y Grafana — almacenamiento económico gracias a indexar solo etiquetas, conveniente junto a Prometheus.