Cómo simplificar la observabilidad adoptando OpenObserve en lugar de Grafana + ELK

Problema

Muchas organizaciones gestionan la observabilidad con pilas dispares: Grafana para dashboards, Elasticsearch para búsqueda, Logstash o Beats para ingestión, Kibana para visualización y Prometheus/Loki para métricas y trazas. Cada componente tiene su propio ciclo de vida, configuración y requisitos de recursos. Cuando el número de microservicios crece, el número de integraciones también lo hace, y aparecen síntomas típicos:

• Duplicación de pipelines de ingestión (por ejemplo, un agente que envía datos a Loki y a Elasticsearch simultáneamente).
• Latencias de búsqueda inconsistentes porque los índices están repartidos entre varios clústeres.
• Costos de almacenamiento que escalan de forma no lineal al usar discos locales para Elasticsearch y volúmenes separados para métricas.
• Equipo de operaciones que debe mantener al menos tres repositorios de configuración (Grafana, ELK y Prometheus) y sus respectivas actualizaciones.

El problema no es solo “tener muchas herramientas”, sino la fricción operativa que impide responder rápidamente a incidentes y dificulta la adopción de prácticas como el “shift‑left” en observabilidad.

Causa

1. Arquitectura fragmentada – Cada capa (logs, métricas, trazas) está diseñada como un proyecto independiente. La falta de un modelo de datos común obliga a traducir etiquetas y campos entre sistemas.
2. Integraciones manuales – Los pipelines de recolección (Filebeat, Promtail, OpenTelemetry Collector) se configuran a mano para cada destino. Un cambio en el esquema de logs requiere tocar varios archivos de configuración.
3. Escalado desalineado – Elasticsearch necesita nodos de datos intensivos en CPU y RAM, mientras que Prometheus escala mejor con sharding. Coordinar el escalado de ambos sistemas genera decisiones de capacidad complejas.
4. Almacenamiento redundante – Los datos se replican en discos locales y, a veces, en S3 por separado, lo que duplica el gasto de almacenamiento y complica la política de retención.
5. Visibilidad discontinua – Los dashboards de Grafana pueden consumir métricas de Prometheus pero no logs de Elasticsearch sin plugins adicionales, lo que obliga a saltar entre UI para obtener una visión completa de un incidente.

Estos factores se combinan para crear una carga operativa que supera el valor que aporta la observabilidad distribuida.

Solución

Una alternativa viable es migrar a una plataforma unificada que gestione logs, métricas y trazas bajo el mismo motor de ingestión y búsqueda. OpenObserve ofrece esa consolidación sin requerir licencias propietarias y con soporte nativo para OpenTelemetry. La solución se divide en tres fases: evaluación, despliegue y migración.

1. Evaluación preliminar

Responder estas preguntas con datos de Prometheus, Loki y Elasticsearch ayuda a dimensionar los recursos de OpenObserve antes de cualquier cambio.

2. Despliegue rápido

OpenObserve se puede lanzar en dos modos habituales:

• Docker Compose – Ideal para pruebas de concepto o entornos de desarrollo.
• Helm chart en Kubernetes – Recomendado para producción, permite escalar componentes (ingestión, storage, query) de forma independiente.

En ambos casos la configuración mínima incluye:

• Un collector que exponga los endpoints OTLP (:4317 para gRPC, :4318 para HTTP) y acepte métricas Prometheus (/metrics).
• Un backend que almacene datos en un bucket S3‑compatible (MinIO, AWS S3, GCS).
• Un frontend accesible vía HTTP para dashboards y alertas.

3. Migración de datos

1. Redirige los agentes – Cambia la salida de Filebeat, Promtail o el OpenTelemetry Collector a la URL del nuevo collector (http://openobserve-collector:4317).
2. Reindexa históricos – Exporta índices de Elasticsearch (elasticdump) y re‑importa con la herramienta ooctl import que OpenObserve provee.
3. Replica dashboards – Exporta los JSON de Grafana y conviértelos a la sintaxis de OpenObserve (el UI incluye un importador).
4. Recrea alertas – Traduce las reglas de Prometheus (alertmanager.yml) a la definición de alertas de OpenObserve, que usa la misma sintaxis de PromQL.

4. Operación y mantenimiento

• Escalado horizontal – Añade réplicas al deployment openobserve-ingester cuando la tasa de ingestión supera el 70 % de la CPU.
• Política de retención – Configura el bucket con ciclo de vida que elimine objetos mayores a 30 días para logs y a 90 días para métricas, ajustando según SLA.
• Monitoreo interno – Usa los propios endpoints /metrics de OpenObserve para observar la latencia de ingestión y el uso de disco.

Cuándo aplicar esta solución

Señales de que la solución unificada es adecuada

• Equipos pequeños a medianos (≤ 15 ingenieros) que no pueden dedicar recursos a mantener varios clústeres.
• Volúmenes de datos crecientes donde el costo de almacenamiento en discos locales supera el presupuesto.
• Necesidad de correlación rápida entre logs, métricas y trazas en un solo dashboard.
• Política de “single source of truth” para auditorías y cumplimiento.

Escenarios donde no es la mejor opción

• Infraestructura altamente regulada que obliga a usar versiones certificadas de Elasticsearch o a mantener datos en discos encriptados bajo control directo.
• Implementaciones con pipelines personalizados que dependen de plugins exclusivos de Logstash o de scripts de ingestión que aún no tienen equivalentes en OpenObserve.
• Entornos con latencias de red críticas donde la separación física de componentes (por ejemplo, logs en una zona y métricas en otra) es un requisito de arquitectura.

Código

# Docker Compose rápido para pruebas locales
cat > docker-compose.yml <<'EOF'
version: "3.8"
services:
  openobserve:
    image: public.ecr.aws/openobserve/openobserve:latest
    ports:
      - "5080:5080"   # UI
      - "5081:5081"   # API
    environment:
      - OO_STORAGE_TYPE=s3
      - OO_S3_ENDPOINT=minio:9000
      - OO_S3_BUCKET=observability
      - OO_S3_ACCESS_KEY=minioadmin
      - OO_S3_SECRET_KEY=minioadmin
    depends_on:
      - minio

  minio:
    image: minio/minio:latest
    command: server /data
    ports:
      - "9000:9000"
    environment:
      - MINIO_ROOT_USER=minioadmin
      - MINIO_ROOT_PASSWORD=minioadmin
    volumes:
      - minio-data:/data

volumes:
  minio-data:
EOF

docker compose up -d

# Helm install en Kubernetes (asume Helm repo ya añadido)
helm repo add openobserve https://charts.openobserve.com
helm repo update

helm upgrade --install openobserve openobserve/openobserve \
  --namespace observability --create-namespace \
  --set storage.type=s3 \
  --set storage.s3.endpoint=s3.amazonaws.com \
  --set storage.s3.bucket=observability \
  --set storage.s3.accessKey=YOUR_KEY \
  --set storage.s3.secretKey=YOUR_SECRET

Verificación

1. Ingestión – Envía un mensaje de prueba con curl:

   curl -X POST http://localhost:5081/api/v1/logs -d '{"message":"test log","level":"info"}' -H "Content-Type: application/json"
   

   Luego verifica en la UI que el registro aparece en menos de 2 s.

2. Consulta – Ejecuta una consulta PromQL desde la UI o con curl:

   curl 'http://localhost:5081/api/v1/query?query=up{job="openobserve"}'
   

   La respuesta debe contener al menos un vector con valor 1.

3. Retención – Crea un objeto con timestamp de hace 31 días y comprueba que el bucket lo elimina automáticamente después de la política de ciclo de vida configurada.

4. Alertas – Define una regla simple:

   groups:
     - name: test
       rules:
         - alert: HighErrorRate
           expr: rate(openobserve_logs_total{level="error"}[5m]) > 0.1
           for: 2m
           labels:
             severity: critical
   

   Verifica que la alerta aparece en la sección de alerts después de cumplir la condición.

Notas adicionales

• Ajuste de buffers – En entornos con picos de ingestión, aumenta OO_INGEST_BUFFER_SIZE para evitar pérdidas de datos.
• Seguridad – Habilita TLS en el collector y en el bucket S3; OpenObserve permite especificar certificados mediante variables de entorno OO_TLS_CERT y OO_TLS_KEY.
• Backup de índices – Aunque los datos res