docker compose configOpenSearch para centralizar logs (multiplataforma)
Un laboratorio para indexar, buscar y explorar eventos en Windows, Linux, macOS y Docker.
Configura OpenSearch y Dashboards, carga eventos iniciales y valida consultas operativas de logs en cualquier plataforma.
Creada: 6 de abril de 2026
Publicada: 6 de abril de 2026
Docker
Esta guía se ejecuta como laboratorio Docker. Usa los fragmentos de Compose y configuración del artículo como fuente principal y no asumas soporte nativo para otros sistemas operativos si no aparece documentado.
docker compose up -d --builddocker compose psQué levanta esta guía
- Un nodo único de OpenSearch con memoria acotada para desarrollo.
- OpenSearch Dashboards para inspeccionar índices y consultas.
- Un índice de ejemplo con eventos JSON para probar búsquedas y filtros.
Este despliegue sirve para aprender y validar pipelines. No reutilices esta configuración tal cual en producción sin revisar seguridad, persistencia y sizing.
Stack básico con Docker Compose
services:
opensearch:
image: opensearchproject/opensearch:2.17.1
container_name: opensearch
environment:
- discovery.type=single-node
- bootstrap.memory_lock=true
- plugins.security.disabled=true
- OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m
ulimits:
memlock:
soft: -1
hard: -1
ports:
- "9200:9200"
volumes:
- opensearch_data:/usr/share/opensearch/data
dashboards:
image: opensearchproject/opensearch-dashboards:2.17.1
container_name: opensearch-dashboards
environment:
- OPENSEARCH_HOSTS=["http://opensearch:9200"]
ports:
- "5601:5601"
depends_on:
- opensearch
volumes:
opensearch_data:Single-node y seguridad desactivada simplifican el arranque para un laboratorio local reproducible.
Arranca y verifica el nodo
Lanza `docker compose up -d` y espera a que OpenSearch responda en el puerto 9200.
Comprueba con `curl http://localhost:9200` que el clúster está accesible y reporta `green` o `yellow` controlado para single-node.
docker compose up -dCarga eventos de ejemplo
Antes de integrar un shipper real, conviene indexar documentos manualmente. Así verificas mapeos, timestamps y búsquedas sin depender todavía de Fluent Bit, Vector o Beats.
curl -X PUT "http://localhost:9200/app-logs"
curl -X POST "http://localhost:9200/app-logs/_doc" \
-H "Content-Type: application/json" \
-d '{
"@timestamp": "2026-04-06T08:30:00Z",
"service.name": "checkout-api",
"log.level": "error",
"message": "payment provider timeout",
"trace.id": "9f4a62"
}'- Crea un índice explícito para no mezclar datos de arranque y reales.
- Incluye `@timestamp`, `service.name`, `log.level` y `trace.id` para que luego el cruce con otras señales sea viable.
Explora los logs desde Dashboards
Configura el data view
Abre `http://localhost:5601`, crea un data view para `app-logs*` y selecciona `@timestamp` como campo temporal.
Lanza una búsqueda filtrando por `service.name: checkout-api` y luego por `log.level: error`.
Checklist mínima para un pipeline de logs sano
- ✓Todos los documentos tienen timestamp consistente.
- ✓Los servicios usan nombres estables y repetibles.
- ✓Existe al menos un campo para correlación con trazas.
- ○Ya definiste una política de rotación y retención.
¿Por qué usar OpenSearch Dashboards en la guía?
Porque te permite validar de inmediato si el índice y los campos tienen sentido antes de introducir complejidad con pipelines de ingesta más avanzados.
¿Qué hago si OpenSearch tarda mucho en arrancar?
Revisa RAM disponible y límites de memoria. En local, el problema más común es quedarte corto de memoria o arrastrar volúmenes corruptos de ejecuciones anteriores.
Una vez validado el índice, conecta OpenSearch como datasource en Grafana o añade un shipper real desde tus contenedores de aplicación.