En mayo de 2022 publiqué una guía para centralizar logs de aplicaciones Java, .NET y GeneXus. El objetivo era deliberadamente simple: dejar de recorrer archivos dispersos en distintos servidores y poder buscar todos los eventos desde una única interfaz.
La primera versión utilizaba Elasticsearch, Logstash y Kibana, y el repositorio se llamaba log4kibana. El 18 de julio de 2022 cambié el motor de almacenamiento y visualización a OpenSearch y OpenSearch Dashboards; al día siguiente dejé registrada la actualización en el artículo original.
Ese fue el primer hito. El segundo llegó con la maduración posterior del proyecto, especialmente entre 2024 y 2026: retención automática mediante ISM, mappings explícitos, dashboards versionados, aprovisionamiento de una sola ejecución, health checks y un camino opcional para logs y trazas mediante OpenTelemetry.
Dicho de otra forma:
Cambié el motor a OpenSearch en julio de 2022, y con el tiempo el proyecto evolucionó —retención, dashboards versionados y OpenTelemetry— hasta convertirse en
log4opensearch.
El resultado es log4opensearch, un proyecto open source que permite construir una plataforma reproducible de logs centralizados para aplicaciones .NET, Java y GeneXus.
Este artículo no intenta duplicar su manual de instalación. El README de log4opensearch es la fuente canónica para los comandos, archivos de configuración, puertos y resolución de problemas. Acá me interesa explicar por qué la solución terminó diseñada de esta manera, qué cambió desde 2022 y qué aprendizajes pueden aplicarse a otras plataformas.
De log4kibana a log4opensearch: dos razones complementarias
La migración de 2022 tuvo dos ejes: la licencia y la gobernanza del proyecto, por un lado, y su adecuación al propósito de esta herramienta, por otro.
Conviene separarlos porque no ocurrieron con la misma intensidad ni en el mismo momento.
1. Licencia y gobernanza: la razón principal en 2022
En enero de 2021, Elastic dejó de publicar las nuevas versiones de Elasticsearch y Kibana bajo Apache License 2.0 y pasó a distribuir su código bajo SSPL y Elastic License. Ninguna de esas dos licencias era reconocida como open source por la Open Source Initiative.
Cuando cambié el motor en julio de 2022, esa situación llevaba aproximadamente un año y medio. En ese momento, OpenSearch era la alternativa que mantenía toda la base de búsqueda y visualización bajo Apache 2.0, una licencia open source permisiva.
Para un proyecto que quería mantener abierto, modificable y reutilizable —también dentro de soluciones comerciales— la licencia no era un detalle jurídico secundario. Era parte de la arquitectura.
Apache 2.0 ofrece una previsibilidad importante: las versiones publicadas bajo esa licencia pueden utilizarse, modificarse, distribuirse e integrarse en otros productos respetando sus condiciones. Una empresa o una comunidad pueden continuar trabajando sobre ese código aunque más adelante cambie la estrategia de alguno de sus impulsores.
El contexto volvió a evolucionar en 2024:
- en agosto, Elastic agregó AGPLv3 como opción para la parte gratuita del código fuente de Elasticsearch y Kibana, por lo que ambos volvieron a disponer de una licencia aprobada por la OSI;
- en septiembre, OpenSearch pasó a estar bajo la OpenSearch Software Foundation, alojada en la Linux Foundation, con una gobernanza neutral respecto de proveedores.
Por eso hoy no sería correcto afirmar simplemente que Elasticsearch es privativo. La comparación actual es más matizada: Elastic ofrece AGPLv3 junto con ELv2 y SSPL, mientras que OpenSearch mantiene todos sus componentes bajo Apache 2.0 y está respaldado por una fundación independiente.
La decisión de 2022 debe leerse con la información disponible en 2022: en aquel momento, las nuevas versiones de Elasticsearch y Kibana ya no estaban bajo una licencia open source aprobada por la OSI, mientras que OpenSearch sí mantenía una base íntegramente Apache 2.0.
2. Adecuación al propósito: una lectura que se confirmó después
Había además una segunda señal. Elastic orientaba cada vez más su propuesta hacia su nube gestionada y presentaba Elastic Cloud como el camino más directo para acceder a las nuevas capacidades y reducir la operación de la plataforma.
Eso no significa que el despliegue self-managed haya desaparecido ni que sea una alternativa inválida. Significa que los incentivos y la comunicación del producto se fueron concentrando progresivamente en la experiencia gestionada.
Para muchas empresas, esa dirección es razonable: operar un clúster de búsqueda, observabilidad y seguridad a escala no es trivial, y consumirlo como servicio puede ser la mejor decisión.
Pero log4kibana tenía otro propósito. Buscaba ofrecer una plataforma de logs pequeña, comprensible y reproducible, que pudiera levantarse localmente o dentro de una red interna con Docker Compose. No necesitaba convertirse en una plataforma empresarial completa ni depender de un servicio administrado.
La evolución posterior de Elastic confirmó esa diferencia de objetivos. Desde 2023, la compañía amplió su posicionamiento alrededor de una Search AI Platform que integra búsqueda, observabilidad, seguridad, vectores y capacidades de inteligencia artificial. Es una dirección válida para un producto empresarial amplio, pero introduce capacidades, conceptos y decisiones que exceden el objetivo de un stack sencillo para centralizar logs.
No proyecto esa complejidad de 2026 sobre la decisión de 2022 como si ya existiera de la misma forma. En 2022, el argumento determinante fue la licencia y las señales de dirección del producto. La expansión posterior de la plataforma simplemente confirmó que OpenSearch encajaba mejor con el alcance concreto de este proyecto.
Qué migró y qué permaneció
No migré “todo el Elastic Stack”. Esa formulación sería imprecisa.
El cambio fue:
Elasticsearch + Kibana
↓
OpenSearch + OpenSearch DashboardsLogstash permaneció en el pipeline. Su distribución OSS continuó disponible bajo Apache License 2.0 y siguió cumpliendo una función clara: recibir los mensajes, interpretarlos mediante patrones Grok y enviarlos al motor de almacenamiento.
La arquitectura combinó, por lo tanto, componentes con orígenes distintos:
- Logstash para la ingesta y transformación;
- OpenSearch para indexación y búsqueda;
- OpenSearch Dashboards para exploración y visualización;
- Docker Compose para reproducir el entorno.
Esta distinción también explica el nombre actual. log4opensearch no pretende negar el origen del pipeline ni reemplazar cada pieza relacionada con Elastic. Describe el destino principal de los logs y la interfaz desde la que se analizan.
El problema no son los archivos: es la falta de contexto
Mientras una aplicación corre en un único servidor, abrir un archivo de texto puede parecer suficiente. Pero una plataforma real suele tener varios componentes:
- aplicaciones web;
- APIs;
- procesos batch;
- servicios Java y .NET;
- diferentes ambientes;
- contenedores o servidores múltiples;
- aplicaciones GeneXus que conviven con servicios desarrollados en otras tecnologías.
Cuando ocurre un incidente, rara vez alcanza con encontrar una excepción aislada. Lo que necesitamos reconstruir es una secuencia:
- qué aplicación originó el evento;
- en qué ambiente ocurrió;
- qué servidor lo procesó;
- qué operación o entidad estaba involucrada;
- qué sucedió antes y después;
- si el mismo patrón aparece en otros nodos.
Un archivo contiene texto. Una plataforma de observabilidad debería contener eventos con contexto.
Esa diferencia define casi todas las decisiones posteriores.
De una demo funcional a una plataforma reproducible
La arquitectura principal sigue siendo sencilla:
Aplicación .NET / Java / GeneXus
│
│ logs de texto estructurado
▼
Logstash
│
│ documentos indexados
▼
OpenSearch
│
▼
OpenSearch DashboardsOpcionalmente, las aplicaciones instrumentadas con OpenTelemetry utilizan un camino independiente:
Aplicación con OpenTelemetry
│
│ OTLP
▼
Data Prepper
│
▼
OpenSearchEl valor del proyecto no está solamente en poder iniciar esos contenedores. Eso es relativamente fácil. El valor está en automatizar lo que normalmente queda como una serie de configuraciones manuales:
- mappings explícitos;
- política de retención;
- patrones de índices;
- dashboards versionados;
- health checks reales;
- aprovisionamiento idempotente mediante servicios de una sola ejecución;
- separación entre logs tradicionales y telemetría OTLP.
El dashboard se aprovisiona junto con el stack y no depende de una configuración manual posterior a la instalación.
Primera decisión: el formato del log es una API
Muchas implementaciones tratan el formato de los logs como un detalle de presentación. En realidad, cuando existe un pipeline que interpreta esos mensajes, el formato se convierte en un contrato entre la aplicación y la infraestructura.
Un evento útil no debería limitarse a decir:
Error al actualizar clienteDebería transportar información que permita filtrarlo y correlacionarlo:
timestamp | nivel | host | ambiente | aplicación | traceId | programa | entidad | mensajeLa diferencia es operativa. Con el segundo formato podemos responder preguntas concretas:
- todos los errores de producción de una aplicación;
- todos los eventos asociados a un cliente;
- la actividad de un programa determinado;
- los mensajes relacionados con una misma operación;
- los hosts que están generando más fallas.
Dos detalles pequeños suelen producir errores difíciles de detectar.
La zona horaria debe viajar con el evento. Una fecha local sin offset es ambigua. Si el pipeline la interpreta como UTC, el log aparecerá desplazado varias horas y la reconstrucción temporal será incorrecta.
La codificación debe ser explícitamente UTF-8. De lo contrario, los mensajes con tildes, eñes u otros caracteres pueden llegar dañados aunque el flujo parezca funcionar.
Las configuraciones actuales para log4net y log4j2 están mantenidas en la sección Configuring your application del repositorio. Mantenerlas allí evita que este artículo quede desactualizado cuando cambia el contrato técnico.
Segunda decisión: fallar de forma visible, no perder información
Logstash utiliza patrones Grok para convertir una línea de texto en campos estructurados. El proyecto reconoce varios formatos y evalúa primero los más específicos.
El orden importa: un patrón genérico podría aceptar prematuramente una línea más rica y conservar el mensaje, pero perder campos como el programa, la entidad o el identificador de trazabilidad.
También hay otra decisión relevante: cuando una línea no coincide con ningún patrón, el evento no se descarta.
Se conserva el texto original y se agrega una etiqueta de fallo de parseo. De esta manera, un cambio inesperado en el layout no genera un agujero silencioso en los datos. El equipo puede buscar esos eventos, analizar qué formato llegó y corregir el pipeline.
Este principio es aplicable más allá de Logstash:
Cuando una entrada no puede estructurarse, conviene degradar la calidad del dato antes que eliminarlo sin dejar evidencia.
Tercera decisión: los mappings no deberían depender del primer evento
OpenSearch puede inferir automáticamente el tipo de cada campo. Esa comodidad funciona hasta que dos productores utilizan el mismo nombre con estructuras diferentes.
Un ejemplo típico es host:
- una aplicación lo envía como texto;
- otra herramienta compatible con ECS intenta enviarlo como objeto con propiedades internas.
El primer documento define el mapping. El segundo puede terminar rechazado porque un campo no puede ser simultáneamente un texto y un objeto.
Por eso log4opensearch instala mappings explícitos y mantiene un esquema plano para los logs procesados por Logstash. También desactiva la compatibilidad ECS en los puntos del pipeline donde podría transformar automáticamente esos campos.
La lección no es que ECS sea incorrecto. ECS es útil cuando se adopta de forma consistente. El problema aparece cuando se mezclan convenciones dentro del mismo índice sin una decisión consciente.
Un esquema explícito ofrece tres ventajas:
- evita que el primer documento decida la estructura del sistema;
- reduce los conflictos entre productores;
- convierte la evolución del dato en una decisión versionable.
Cuarta decisión: los dashboards también son código
En una prueba inicial es normal crear el patrón de índices y las visualizaciones manualmente. En un entorno que debe reconstruirse, esa configuración manual se convierte en deuda operativa.
Si el conocimiento de la plataforma vive solamente en una instancia de OpenSearch Dashboards, aparecen varios problemas:
- una instalación nueva no reproduce el entorno anterior;
- cada ambiente termina mostrando información diferente;
- los cambios no pasan por revisión;
- nadie sabe exactamente qué configuración es la correcta;
- una reinstalación obliga a repetir una secuencia de clics.
El repositorio exporta y versiona los objetos de Dashboards, y los importa automáticamente cuando el servicio está realmente disponible. Los objetos utilizan identificadores estables, por lo que pueden actualizarse sin crear duplicados.
Esto transforma las visualizaciones en parte del producto.
El dashboard no es un adorno posterior a la infraestructura. Es la interfaz desde la que el equipo investiga incidentes, detecta tendencias y verifica la calidad de los datos recibidos.
Quinta decisión: la retención forma parte del diseño
Toda plataforma de logs tiene un crecimiento acumulativo. Si no existe una política de expiración, la única política real es esperar a que el disco se llene.
log4opensearch crea índices temporales y aplica una política de Index State Management para eliminar información antigua. El período puede ajustarse desde la configuración del entorno.
La cantidad adecuada de días depende de cada organización:
- volumen diario;
- espacio disponible;
- tiempos habituales de investigación;
- requisitos de auditoría;
- sensibilidad de la información;
- políticas contractuales o regulatorias.
La decisión importante es que la retención sea explícita y automática.
También conviene recordar que conservar más no siempre es mejor. Los logs pueden incluir identificadores, parámetros, datos funcionales o información que no debería permanecer indefinidamente. La observabilidad necesita una política de datos, no solamente capacidad de almacenamiento.
Sexta decisión: UDP es un compromiso, no una garantía
El camino tradicional del proyecto recibe logs mediante UDP. La elección tiene ventajas claras:
- configuración sencilla;
- baja sobrecarga;
- la aplicación no queda esperando una respuesta;
- amplio soporte en log4net y log4j2.
Pero UDP no garantiza entrega, orden ni reintentos. Si el puerto está bloqueado, la red falla o Logstash todavía no está escuchando, el emisor no recibe confirmación.
Por eso este mecanismo funciona bien en desarrollo, laboratorios y muchos entornos internos, pero no debería confundirse con una cola durable.
Cuando los eventos tienen valor legal, financiero o de seguridad, conviene evaluar mecanismos con buffering, confirmación y reintento. La arquitectura debe responder al costo de perder un evento, no solamente a la facilidad de enviarlo.
De logs centralizados a trazas distribuidas
Los logs explican qué registró cada componente. Las trazas intentan reconstruir cómo una operación atravesó varios componentes y cuánto tiempo consumió cada tramo.
Por eso el proyecto incorpora OpenTelemetry como un perfil opcional y mantiene sus datos en un camino separado del pipeline tradicional.
Esta separación evita forzar una migración total. Una organización puede tener al mismo tiempo:
- aplicaciones existentes que continúan enviando logs mediante log4net o log4j2;
- servicios nuevos que emiten trazas y logs mediante OTLP;
- una única instancia de OpenSearch para explorar ambos contextos.
La transición hacia OpenTelemetry puede ser gradual, pero hay una distinción conceptual importante: agregar un colector no crea observabilidad por sí solo. La profundidad de una traza depende de los spans que realmente genere la aplicación o su instrumentación.
El stack puede almacenar y visualizar lo que recibe. No puede inventar el contexto que el código nunca emitió.
La precisión importante para aplicaciones GeneXus
El repositorio nació a partir de una implementación GeneXus y mantiene una carpeta con configuraciones y un XPZ de helpers para logging estructurado.
Para aplicaciones GeneXus que utilizan el camino tradicional, el flujo es el mismo que en otras aplicaciones .NET o Java: el logger genera el evento y Logstash lo procesa.
Con OpenTelemetry hay una diferencia que conviene dejar explícita.
GeneXus .NET: OpenTelemetry reemplaza log4net
Cuando el Observability Provider del generador .NET se configura con OpenTelemetry, GeneXus deja de utilizar log4net para esa aplicación.
En consecuencia:
- esa aplicación deja de alimentar el camino UDP de Logstash;
- sus logs y trazas pasan a enviarse mediante OTLP;
- no existen ambos mecanismos simultáneamente dentro de esa misma aplicación .NET.
La coexistencia ocurre entre aplicaciones. Por ejemplo, una plataforma puede mantener aplicaciones antiguas enviando log4net y migrar otras a OpenTelemetry. log4opensearch puede recibir ambos flujos al mismo tiempo porque los procesa por caminos diferentes.
En el generador Java el comportamiento es distinto: log4j2 continúa disponible y puede utilizarse junto con la instrumentación de OpenTelemetry y la correlación por identificadores de traza.
Los pasos concretos, las variables de configuración y los helpers LogAdd y LogAddTag se mantienen en el apéndice GeneXus del README, donde pueden evolucionar junto con el código.
La frontera entre laboratorio y producción
El proyecto prioriza una puesta en marcha sin fricción. De forma predeterminada, la seguridad está deshabilitada y los endpoints no deberían exponerse a una red no confiable.
Antes de utilizar un stack de este tipo en producción hay que considerar, como mínimo:
- autenticación y autorización;
- TLS;
- restricción de puertos mediante firewall;
- acceso privado a Dashboards;
- manejo seguro de credenciales;
- backups cuando el histórico sea importante;
- alertas de disco y memoria;
- revisión de datos sensibles incluidos en los logs.
Una plataforma de observabilidad concentra detalles sobre la arquitectura, los errores y la actividad interna del sistema. Esa información debe protegerse como cualquier otro activo técnico sensible.
Qué pertenece al artículo y qué pertenece al repositorio
Separar responsabilidades también mejora el mantenimiento del contenido.
Este artículo intenta responder preguntas de arquitectura:
- ¿por qué OpenSearch en lugar de mantener Elasticsearch y Kibana?;
- ¿por qué estructurar los logs?;
- ¿por qué definir mappings?;
- ¿por qué conservar los fallos de parseo?;
- ¿por qué versionar los dashboards?;
- ¿qué compromiso implica UDP?;
- ¿cómo convivir con OpenTelemetry?;
El repositorio responde las preguntas operativas:
- cómo levantar el stack;
- qué puertos utiliza;
- cómo configurar log4net y log4j2;
- cómo enviar un evento de prueba;
- cómo ajustar la retención;
- cómo resolver errores frecuentes.
Esa división evita mantener dos manuales que inevitablemente terminarían contradiciéndose.
Para probar la implementación, consultar las configuraciones actuales o revisar el código, el punto de entrada es el README de log4opensearch.
Conclusión
El proyecto comenzó en mayo de 2022 como log4kibana, una forma rápida de enviar logs a Elasticsearch y Kibana. En julio de ese mismo año cambié el motor a OpenSearch y OpenSearch Dashboards, manteniendo Logstash como componente de ingesta.
La razón principal en aquel momento fue la licencia: quería que la base del proyecto permaneciera sobre una tecnología open source permisiva. También había una cuestión de adecuación al propósito: para una plataforma de logs pequeña, local y reproducible, OpenSearch ofrecía una dirección más alineada con lo que quería construir.
La evolución posterior no debe confundirse con el momento de la migración. Entre 2024 y 2026 el proyecto maduró con retención ISM, mappings explícitos, dashboards versionados, aprovisionamiento automático y OpenTelemetry. Esa segunda etapa fue la que terminó de convertir log4kibana en log4opensearch.
La experiencia también mostró que centralizar logs es apenas el comienzo. Una solución sostenible debe definir un contrato de eventos, conservar las entradas que no puede interpretar, controlar el esquema, automatizar la retención, versionar las visualizaciones y establecer una transición clara hacia trazas distribuidas.
log4opensearch deja esas decisiones visibles en un repositorio pequeño, ejecutable y modificable. Puede servir como laboratorio, punto de partida para una implementación interna o referencia para diseñar una plataforma de observabilidad más amplia.