Cómo crear un servidor de logs con OpenSearch para buscar errores, investigar incidentes y monitorear toda una empresa

Cuando una empresa tiene 20, 50 o 200 servidores, buscar un error abriendo archivos /var/log máquina por máquina deja de ser viable. La solución es centralizar los registros y convertir millones de líneas aparentemente inútiles en información que pueda buscarse en segundos.

OpenSearch permite construir precisamente esa plataforma utilizando software libre: recibir logs de servidores, aplicaciones, contenedores y dispositivos de red; almacenarlos de forma centralizada; buscar errores; crear paneles; detectar comportamientos anómalos y generar alertas cuando algo importante sucede.

El proyecto OpenSearch documenta actualmente una arquitectura de análisis de logs basada en Fluent Bit, Data Prepper, OpenSearch y OpenSearch Dashboards. Data Prepper recibe y transforma los eventos antes de almacenarlos, mientras Dashboards proporciona la capa de consulta, investigación y visualización.

1. El problema: cada servidor guarda una parte diferente de la historia

Imaginemos una empresa con esta infraestructura:

Cuando cada sistema conserva sus propios registros, investigar un incidente obliga al administrador a conectarse a varias máquinas y reconstruir manualmente la secuencia de acontecimientos.

Un servidor centralizado cambia completamente ese escenario.

2. Qué vamos a construir con OpenSearch

En lugar de representar la arquitectura con una larga cadena de flechas, podemos dividirla en cuatro capas:

Esta arquitectura coincide con el flujo de log analytics documentado oficialmente por OpenSearch. Fluent Bit puede enviar los eventos mediante HTTP a Data Prepper, que dispone de procesadores como Grok para convertir logs sin estructura en campos útiles antes de escribirlos en OpenSearch.

3. ¿Qué puede responder este servidor?

Una vez centralizada la información, las preguntas cambian radicalmente.

La diferencia fundamental es que el administrador deja de buscar archivos y comienza a buscar eventos.

4. OpenSearch 3.8 como base de la plataforma

A septiembre de 2026, OpenSearch 3.8 es la versión estable publicada más reciente en la rama 3.x reflejada por el proyecto. Fue publicada el 4 de agosto de 2026 e incluye nuevas capacidades relacionadas con búsqueda, IA y observabilidad.

Para producción es preferible fijar explícitamente la versión utilizada. La propia documentación muestra 3.8.0 como ejemplo y recomienda versiones explícitas para evitar actualizaciones inesperadas.

docker --version
docker compose version

5. Preparar el servidor Linux

Para una prueba de concepto puede utilizarse una máquina relativamente pequeña, pero el almacenamiento debe dimensionarse según la cantidad de logs generados diariamente y el periodo de retención.

Antes de ejecutar OpenSearch en Linux, la documentación recomienda desactivar swap para mejorar el rendimiento y establecer vm.max_map_count en al menos 262144.

sudo swapoff -a

sudo sysctl -w vm.max_map_count=262144

cat /proc/sys/vm/max_map_count

Para hacerlo permanente:

sudo nano /etc/sysctl.conf

Agregar:

vm.max_map_count=262144

Y aplicar:

sudo sysctl -p

6. Crear una contraseña administrativa segura

Desde OpenSearch 2.12, una instalación nueva que utiliza la configuración de seguridad de demostración requiere definir una contraseña administrativa personalizada. La documentación también advierte que las credenciales y certificados de demostración no deben mantenerse en una instalación productiva.

Puede definir temporalmente la variable:

export OPENSEARCH_INITIAL_ADMIN_PASSWORD='CAMBIAR_POR_UNA_CLAVE_MUY_SEGURA'

No coloque contraseñas reales en repositorios Git, scripts compartidos o documentación interna.

7. Empezar con Docker Compose

OpenSearch mantiene imágenes oficiales para OpenSearch y OpenSearch Dashboards y documenta Docker Compose como una de las formas más sencillas de levantar un laboratorio o definir un despliegue controlado.

La recomendación práctica es crear un directorio exclusivo:

sudo mkdir -p /opt/opensearch
sudo chown $USER:$USER /opt/opensearch
cd /opt/opensearch

Dentro del directorio deben mantenerse, como mínimo, los archivos de Docker Compose, configuración, certificados y posteriormente la configuración de Data Prepper.

Para iniciar los servicios:

docker compose up -d

Comprobar:

docker compose ps

Y ante problemas:

docker compose logs

8. Instalar Fluent Bit en los servidores que queremos monitorear

Ahora necesitamos recolectar los logs.

La idea no es instalar OpenSearch en cada servidor. En cada máquina colocamos un agente ligero encargado de leer los registros y enviarlos hacia la plataforma central.

OpenSearch utiliza Fluent Bit precisamente de esta forma en su arquitectura documentada de log analytics. Fluent Bit puede leer archivos y enviar los eventos mediante su salida HTTP hacia Data Prepper.

En un servidor Linux podríamos querer recopilar inicialmente:

Las rutas exactas dependen de la distribución y de cada aplicación.

9. No envíes solamente texto: agrega contexto

Este punto separa una plataforma útil de un gigantesco depósito de texto.

Cada evento debería identificar, cuando sea posible:

Con campos estructurados podremos preguntar “muéstrame únicamente los errores de facturación en producción” en lugar de realizar búsquedas de texto imprecisas.

10. Data Prepper convierte líneas de texto en información

Data Prepper ocupa una posición estratégica. Puede recibir datos de Fluent Bit mediante HTTP, procesarlos y escribir los resultados en OpenSearch. Su procesador Grok permite extraer campos de formatos conocidos como logs de Apache o de formatos personalizados.

Una línea tradicional podría ser:

192.168.10.45 - - [27/Sep/2026:08:42:11] "GET /api/clientes HTTP/1.1" 500 928

Después de procesarla podemos trabajar conceptualmente con campos independientes:

La documentación oficial utiliza exactamente este enfoque para convertir logs web en documentos estructurados que posteriormente pueden consultarse desde OpenSearch.

11. Cómo organizar los logs de toda la empresa

No conviene guardar absolutamente todo en un único índice llamado simplemente logs.

Una organización más limpia puede separar la información por función:

logs-linux
logs-nginx
logs-aplicaciones
logs-firewall
logs-vpn
logs-database
logs-seguridad

Para datos temporales como logs, OpenSearch también ofrece data streams, diseñados para datos append-only basados en tiempo. Estos pueden combinarse con Index State Management para automatizar rollover y eliminación de los índices internos conforme envejecen.

12. Buscar un error que está afectando a toda la empresa

Una vez que los eventos aparecen en OpenSearch Dashboards podemos comenzar la investigación.

Desde OpenSearch 3.5, la página especializada de logs permite consultar información utilizando Piped Processing Language (PPL), filtrar eventos, realizar agregaciones, generar visualizaciones y añadirlas a dashboards.

Por ejemplo, una consulta conceptual para localizar errores de un servicio sería:

source = logs-aplicaciones
| where level = 'ERROR'
| where service = 'facturacion'

También podemos contar errores por servidor:

source = logs-aplicaciones
| where level = 'ERROR'
| stats count() by host

PPL está especialmente orientado al análisis secuencial de información de observabilidad como logs, métricas y trazas. OpenSearch también permite utilizar SQL cuando el equipo está más familiarizado con consultas relacionales.

13. Caso realista: la aplicación comenzó a fallar a las 10:30

Supongamos que los usuarios llaman a soporte porque el sistema de ventas está devolviendo errores.

En lugar de conectarnos inmediatamente a cinco servidores, realizamos esta investigación:

Podríamos descubrir que a las 10:28 apareció:

ERROR database connection pool exhausted

Después comprobaríamos que el mismo patrón apareció en varios nodos.

La investigación deja de comenzar con “¿en qué servidor estará el problema?” y pasa a comenzar con “¿qué dicen todos los servidores juntos?”.

14. Detectar ataques SSH también resulta mucho más sencillo

Centralizar auth.log o los eventos equivalentes de systemd permite encontrar patrones que podrían pasar inadvertidos en una máquina individual.

Podemos analizar:

OpenSearch no convierte automáticamente cualquier conjunto de logs en un SIEM completo, pero proporciona componentes de búsqueda, análisis, seguridad y alertamiento sobre los que pueden construirse casos de monitoreo e investigación.

15. Crear alertas: no esperar a que alguien descubra el problema

Buscar manualmente sirve para investigar. Una empresa necesita además detectar determinadas condiciones automáticamente.

El sistema de Alerting de OpenSearch utiliza tres conceptos principales: monitor, trigger y action. El monitor ejecuta consultas de forma programada; el trigger determina cuándo existe una condición de alerta y la acción define qué debe suceder.

Podríamos crear alertas para:

OpenSearch también admite monitores basados directamente en consultas PPL.

16. Crear un dashboard para operaciones

Un buen dashboard empresarial no necesita veinte gráficos. Necesita mostrar rápidamente qué requiere atención.

Un panel inicial podría contener:

La interfaz actual de Logs puede convertir agregaciones PPL en visualizaciones y guardarlas directamente en dashboards.

17. Controlar cuánto almacenamiento consumen los logs

Este es uno de los errores más habituales al crear una plataforma de logs: guardar absolutamente todo para siempre.

Si una empresa genera 50 GB diarios:

Son cifras brutas simplificadas; el consumo real dependerá del mapeo, compresión, réplicas, índices y arquitectura.

OpenSearch incorpora Index State Management (ISM) precisamente para automatizar el ciclo de vida. Una política puede, por ejemplo, realizar rollover cuando un índice alcanza determinado tamaño, convertir información antigua en solo lectura, crear snapshots y eliminar datos al alcanzar la edad establecida.

18. Cuidado con crear miles de shards pequeños

Más índices y shards no significan automáticamente mayor rendimiento.

La documentación de OpenSearch advierte expresamente que un número excesivo de shards puede sobrecargar el cluster y ofrece como regla general mantener tamaños de shard aproximadamente entre 10 y 50 GB.

Por eso, antes de crear un índice diferente para cada servidor, aplicación, departamento, día y entorno, conviene diseñar una estrategia coherente de data streams, templates, rollover y retención.

19. Proteger OpenSearch: los logs contienen información sensible

Un servidor de logs puede terminar almacenando direcciones IP, nombres de usuario, rutas internas, errores de aplicaciones, consultas, identificadores y datos operativos.

Por tanto, la plataforma debe tratarse como infraestructura sensible.

OpenSearch Security proporciona mecanismos para cifrado, autenticación, control de acceso y auditoría. TLS puede proteger tanto las conexiones cliente-nodo como la comunicación entre nodos del cluster.

Como mínimo, una implementación empresarial debería contemplar:

OpenSearch dispone además de roles predefinidos y control granular de permisos. El rol all_access, por ejemplo, es un rol de superusuario y no debería convertirse en el permiso cotidiano de todos los operadores.

20. Activar auditoría del propio OpenSearch

También debemos saber quién está utilizando nuestra plataforma de logs.

OpenSearch puede registrar eventos como autenticaciones correctas, autenticaciones fallidas, privilegios insuficientes, operaciones autorizadas y excepciones TLS.

Esto permite responder preguntas como:

Sin embargo, tampoco conviene habilitar indiscriminadamente cada categoría de auditoría: la propia documentación advierte que un volumen excesivo de auditoría puede afectar el rendimiento y consumir almacenamiento rápidamente.

21. OpenSearch también necesita backup

Centralizar todos los logs en OpenSearch y después no respaldar OpenSearch sería trasladar el punto de fallo.

Los snapshots permiten respaldar índices y estado del cluster. OpenSearch admite repositorios basados, entre otros, en sistemas de archivos compartidos, almacenamiento S3, HDFS y Azure Storage.

Además, los snapshots son incrementales: después del primer snapshot exitoso, se reutilizan datos existentes y se almacena lo que ha cambiado, lo que hace viable ejecutarlos con relativa frecuencia según las necesidades de recuperación.

22. ¿Un solo servidor OpenSearch es suficiente?

Para aprender, desarrollar una prueba de concepto o centralizar un volumen pequeño de información, un único nodo puede ser perfectamente válido.

Para una plataforma empresarial crítica debemos pensar en cluster.

La documentación de OpenSearch recomienda para prácticamente todos los escenarios productivos utilizar tres nodos dedicados elegibles como cluster manager, idealmente distribuidos entre diferentes zonas, para mantener quorum y tolerancia a fallos.

No existe una cantidad universal de CPU, RAM o almacenamiento válida para todas las empresas. El dimensionamiento debe partir del volumen diario de datos, retención, complejidad de consultas, cantidad de usuarios, número de réplicas y crecimiento esperado.

23. OpenTelemetry abre la puerta a algo mayor que los logs

Una vez que centralizamos logs podemos avanzar hacia observabilidad completa.

Las versiones actuales de OpenSearch permiten trabajar conjuntamente con logs, métricas y trazas. Las interfaces de Observability permiten consultar logs mediante PPL, métricas mediante PromQL y trazas distribuidas para investigar aplicaciones complejas.

OpenSearch 3.6 introdujo además una arquitectura APM que utiliza OpenTelemetry Collector y Data Prepper para ingerir telemetría de aplicaciones.

Eso permite evolucionar desde:

Esta combinación permite acercarse mucho más rápidamente a la causa raíz de un incidente.

24. Errores frecuentes al construir un servidor de logs

25. Una arquitectura empresarial razonable

En una empresa mediana podemos organizar la solución sin necesidad de diagramas complejos:

Es mucho más fácil de mantener que una colección de scripts que obliguen al equipo de TI a revisar manualmente archivos de logs en decenas de máquinas.

26. Checklist antes de ponerlo en producción

Preguntas y respuestas

Recomendamos

Como complemento a esta implementación, resulta útil revisar en SomosLibres los contenidos dedicados al monitoreo de Linux y a las herramientas utilizadas por equipos de respuesta a incidentes y CSIRT.

En resumen

Crear un servidor centralizado de logs con OpenSearch puede cambiar radicalmente la forma en que una empresa resuelve problemas.

En lugar de conectarse servidor por servidor, revisar manualmente archivos y tratar de reconstruir qué ocurrió, el equipo dispone de un punto central desde el cual puede buscar errores, comparar eventos, investigar incidentes, crear dashboards y generar alertas automáticas.

Fluent Bit se encarga de recolectar. Data Prepper transforma. OpenSearch indexa y busca. OpenSearch Dashboards permite investigar. ISM controla el ciclo de vida y los snapshots proporcionan una capa de recuperación. Es una arquitectura completamente alineada con el stack de log analytics documentado actualmente por OpenSearch.