Registro centralizado: Parte 3 — OpenSearch

OpenSearch — un sistema abierto de búsqueda y análisis de datos, que se usa con mayor frecuencia para el almacenamiento centralizado de logs. Es un fork de Elasticsearch y Kibana: en 2021, después de que Elastic cambió la licencia a SSPL y Elastic License, Amazon Web Services creó OpenSearch a partir de las últimas versiones bajo Apache 2.0 — Elasticsearch 7.10.2 y Kibana 7.10.2.

Desde el 16 de septiembre de 2024 el proyecto lo gestiona la OpenSearch Software Foundation dentro de la Linux Foundation. Los fundadores de la fundación son AWS, SAP y Uber; antes de eso el proyecto se desarrollaba bajo la dirección de AWS. La licencia se mantuvo — Apache 2.0.

Componentes

• OpenSearch — almacenamiento y motor de búsqueda: índices, búsqueda de texto completo, agregaciones, clúster de varios nodos.
• OpenSearch Dashboards — interfaz web para búsqueda, visualización, dashboards y administración.
• Plugins, que entran en la distribución estándar: seguridad (usuarios, roles, TLS, registro de auditoría), alertas (Alerting), detección de anomalías, SQL y PPL, gestión del ciclo de vida de índices (ISM).

La principal diferencia práctica con Elastic Stack es que todo lo anterior está disponible gratuitamente, sin suscripción aparte.

Versiones

En abril de 2025 salió OpenSearch 3.0 — la primera versión mayor en tres años y la primera bajo la gestión de la fundación. Desde entonces se publican versiones de la rama 3.x. No se recomienda usar la rama 1.x para instalaciones nuevas: su soporte está siendo retirado y productos de terceros, por ejemplo Graylog, también la dejan de soportar.

Cómo enviar los logs

Aquí está la diferencia principal con ELK, que es fácil de olvidar. Los agentes de Elastic de las versiones más recientes no funcionan con OpenSearch: según la documentación de OpenSearch, Beats posteriores a 7.12.x no son compatibles. Los clientes de las versiones 7.x–7.12.x que verifican la versión del servidor deben activar en OpenSearch el modo de compatibilidad. Por ello, para instalaciones nuevas se usan otras herramientas:

• Data Prepper — herramienta propia del proyecto para la recepción, procesamiento y enrutamiento de datos. La documentación de OpenSearch lo nombra como el método preferido para cargar datos. Esquema típico: Fluent Bit en los servidores envía los logs a Data Prepper por HTTP; este analiza las líneas con el procesador grok y escribe el resultado en OpenSearch.
• Fluent Bit — agente ligero con salida integrada opensearch: envía registros por lotes usando la API _bulk, soporta TLS.
• Logstash con el plugin de salida logstash-output-opensearch — si ya se usa Logstash y no se quiere reescribir los pipelines. Esquema frecuente al migrar desde ELK: Filebeat se queda en los servidores, y Logstash con el plugin OpenSearch actúa como puente.

Salida mínima de Fluent Bit en el formato clásico de configuración:

[OUTPUT]
    Name        opensearch
    Match       *
    Host        opensearch.internal
    Port        9200
    HTTP_User   fluentbit
    HTTP_Passwd ${OPENSEARCH_PASSWORD}
    tls         On
    Index       logs
    Suppress_Type_Name On

El parámetro Suppress_Type_Name es necesario para OpenSearch 2.x y posteriores: en estas versiones el campo _type en las solicitudes ya no se usa.

Lenguajes de consulta

Además de las consultas DSL heredadas de Elasticsearch, en OpenSearch hay dos lenguajes prácticos para trabajar con logs:

• SQL — consultas familiares SELECT … FROM … WHERE;
• PPL (Piped Processing Language) — cadena de comandos separada por la barra vertical:

source = logs-*
| where level = 'error'
| stats count() by service

La consulta cuenta errores por servicio. PPL es un lenguaje propio de OpenSearch; Elasticsearch tiene su propio lenguaje con una idea parecida — ES|QL.

Retención: ISM

Los índices de logs se gestionan con Index State Management (ISM). Una política describe los estados del índice y las transiciones entre ellos: un índice vive en el estado hot, al alcanzar cierta edad o tamaño pasa a otros estados y finalmente se elimina. Ejemplo de política de la documentación: el índice se elimina tras 30 días.

PUT _plugins/_ism/policies/logs-30d
{
  "policy": {
    "description": "Eliminación de logs después de 30 días",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [],
        "transitions": [
          { "state_name": "delete", "conditions": { "min_index_age": "30d" } }
        ]
      },
      {
        "name": "delete",
        "actions": [ { "delete": {} } ]
      }
    ]
  }
}

En esencia ISM equivale a ILM en Elasticsearch, pero la sintaxis de las políticas es diferente: al migrar las políticas hay que reescribirlas.

Instalación

Las imágenes oficiales son opensearchproject/opensearch y opensearchproject/opensearch-dashboards. Desde la versión 2.12 al primer arranque es obligatorio establecer la contraseña del administrador en la variable OPENSEARCH_INITIAL_ADMIN_PASSWORD; sin ella el contenedor no arrancará. Para un solo nodo se indica discovery.type=single-node. Para un entorno de producción la documentación describe un clúster de varios nodos en Docker Compose, instalación desde paquetes y charts de Helm para Kubernetes.

Al igual que Elasticsearch, OpenSearch requiere aumentar en el host el parámetro del kernel vm.max_map_count y asignar suficiente memoria para la JVM.

Ventajas

• Licencia abierta Apache 2.0 y gestión mediante una fundación independiente.
• Seguridad y alertas gratis — sin suscripción.
• Compatibilidad de API con Elasticsearch 7.10: muchas herramientas y consultas se trasladan sin cambios.
• SQL y PPL — la barrera de entrada es menor que con el DSL.

Inconvenientes

• Recursos. Los requisitos de memoria, CPU y disco son del mismo orden que los de Elasticsearch.
• Divergencia con Elastic. Desde 2021 los proyectos se desarrollan por separado: las nuevas funciones de Elastic no aparecen en OpenSearch, y las integraciones y agentes de Elastic no funcionan con él.
• Mantenimiento del clúster — shards, políticas, actualizaciones, snapshots — recaen en usted.

Errores típicos

• Filebeat de la última versión conectado directamente a OpenSearch. La conexión no se establece o se rompe después de actualizar el agente. Se necesitan Fluent Bit, Data Prepper o Logstash con el plugin.
• Plugin de seguridad deshabilitado. En ejemplos de Internet a menudo se desactiva por simplicidad y luego lo dejan así en producción.
• Sin política ISM. Los índices se acumulan hasta que se agota el espacio.
• Un solo nodo sin snapshots. Las copias de seguridad se hacen mediante snapshot en un repositorio separado, por ejemplo en un almacenamiento compatible con S3.

Cuándo elegir OpenSearch

OpenSearch es apropiado para quienes necesitan capacidades al nivel de ELK — búsqueda de texto completo, dashboards, alertas, control de acceso — bajo una licencia abierta y sin suscripción de pago. Si ya trabajan con Elastic Stack y usan Elastic Agent e integraciones predefinidas, la migración requerirá reemplazar agentes y políticas de retención; conviene tenerlo en cuenta con antelación.