Observabilidad para Startups: Logs, Métricas y Trazas sin Arruinarte

Si te enteras de los problemas en producción por tus usuarios, no tienes observabilidad — tienes un canal de soporte.

Es una situación más común de lo que parece. La aplicación se cae, un cliente manda un email furioso, el equipo se pone a revisar logs en la consola de AWS, alguien dice "a mí me funciona" y así pasan dos horas hasta que alguien encuentra el problema. Suena familiar, ¿no?

La observabilidad no es un lujo de empresas grandes con equipos de SRE dedicados. Es la capacidad de entender qué está pasando en tu sistema sin tener que adivinarlo. Y en una startup, donde cada incidente puede costarte usuarios (y la siguiente ronda de financiación), es una inversión que devuelve su coste desde el primer día.

Los tres pilares de la observabilidad

Hay un framework clásico que divide la observabilidad en tres pilares: logs, métricas y trazas. No son intercambiables — cada uno responde a una pregunta diferente.

• Logs: ¿Qué pasó? Son registros de eventos discretos. Un usuario intentó hacer login, una transacción falló, un servicio se reinició.
• Métricas: ¿Cuánto y a qué velocidad? Son datos numéricos agregados en el tiempo. Latencia media, tasa de errores, uso de CPU.
• Trazas: ¿Dónde en el sistema? Son el recorrido de una petición a través de múltiples servicios. El request entró por el API gateway, pasó al servicio de autenticación, consultó la base de datos, llamó al servicio de pagos.

No necesitas los tres desde el día uno. Pero sí necesitas entender cuándo incorporar cada uno.

Logs: la base de todo

Todo sistema genera logs. La diferencia está en si los generas de forma útil o si simplemente haces console.log("error aquí") y rezas.

Logging estructurado es lo primero que deberías implementar. En lugar de strings sueltos, genera logs en formato JSON con campos consistentes: timestamp, nivel, servicio, mensaje, request ID, usuario. Esto permite buscar, filtrar y agregar automáticamente.

{
  "timestamp": "2024-06-04T10:23:45Z",
  "level": "error",
  "service": "payment-api",
  "message": "Payment processing failed",
  "requestId": "abc-123",
  "userId": "user-456",
  "errorCode": "GATEWAY_TIMEOUT"
}

Los niveles de log deben significar algo. Si todo es INFO o todo es ERROR, no tienes niveles — tienes ruido. Define una convención clara: DEBUG para desarrollo, INFO para flujos normales, WARN para situaciones recuperables, ERROR para fallos que necesitan atención.

Centraliza tus logs. Si tienes que hacer SSH a tres servidores diferentes para investigar un problema, ya perdiste. Opciones según presupuesto:

• Presupuesto mínimo: Loki + Grafana (open source, ligero, perfecto para empezar)
• Cloud nativo: CloudWatch Logs (AWS), Cloud Logging (GCP)
• Todo en uno: Datadog, New Relic (más caro, pero más completo)
• Clásico: ELK Stack (Elasticsearch, Logstash, Kibana) — potente pero requiere mantenimiento

Métricas: las 4 señales doradas

Google definió las 4 señales doradas de monitorización, y siguen siendo el mejor punto de partida:

1. Latencia: ¿Cuánto tarda tu servicio en responder? No solo la media — los percentiles p95 y p99 son los que importan. Si tu latencia media es 200ms pero el p99 es 5 segundos, tienes un problema que la media esconde.

2. Tráfico: ¿Cuántas peticiones estás recibiendo? Te ayuda a entender patrones de uso y detectar anomalías (picos inesperados o caídas repentinas).

3. Errores: ¿Qué porcentaje de peticiones fallan? Tanto errores explícitos (HTTP 5xx) como implícitos (respuestas correctas pero con datos erróneos).

4. Saturación: ¿Cómo de lleno está tu sistema? CPU, memoria, disco, conexiones a base de datos. Cuando algo se satura, todo lo demás empieza a degradarse.

Hay una distinción importante entre métricas de aplicación y métricas de infraestructura. Las de infraestructura (CPU, memoria, disco) te dicen que algo va mal. Las de aplicación (peticiones por segundo, tasa de errores, latencia por endpoint) te dicen qué va mal. Necesitas ambas.

Herramientas:

• Prometheus + Grafana: El estándar open source. Prometheus recolecta y almacena métricas, Grafana las visualiza. Gratis, potente, y con un ecosistema enorme.
• Datadog: Métricas, logs y trazas en una sola plataforma. Excelente pero caro — cuidado con la factura.
• New Relic: Similar a Datadog. Tiene un tier gratuito decente para empezar.

Trazas: cuando un servicio no es suficiente

Si tienes un monolito simple, probablemente no necesitas trazas distribuidas todavía. Pero en cuanto tengas dos o más servicios comunicándose entre sí, las trazas se vuelven esenciales.

Una traza distribuida te muestra el recorrido completo de una petición a través de tu sistema. Ves exactamente dónde se gasta el tiempo, dónde falla y qué servicio está causando el cuello de botella.

OpenTelemetry se ha consolidado como el estándar para instrumentación. Es open source, vendor-neutral, y soporta logs, métricas y trazas. Si vas a invertir tiempo en instrumentar tu código, hazlo con OpenTelemetry — así no te atas a ningún vendor específico.

Herramientas:

• Jaeger: Open source, creado por Uber. Perfecto para empezar con trazas distribuidas.
• Zipkin: Otra opción open source, más simple que Jaeger.
• Datadog APM / New Relic: Si ya usas su plataforma para métricas, añadir trazas es natural.

El stack amigable para startups

No intentes implementar todo a la vez. Esta es una progresión sensata:

Fase 1 — Lo mínimo viable (desde el día 1):

• Logging estructurado en JSON
• Logs centralizados (Loki + Grafana o CloudWatch)
• Métricas básicas de infraestructura (lo que te da tu cloud provider gratis)
• Alertas sobre errores HTTP 5xx y latencia

Fase 2 — Maduración (cuando tengas usuarios reales):

• Métricas de aplicación con Prometheus + Grafana
• Dashboards por servicio con las 4 señales doradas
• Alertas más sofisticadas con severidades

Fase 3 — Distribución (cuando tengas múltiples servicios):

• OpenTelemetry para instrumentación
• Trazas distribuidas con Jaeger o tu APM de preferencia
• Correlación entre logs, métricas y trazas (el request ID es la clave)

Optimización de costes: no te arruines monitorizando

La observabilidad puede volverse cara rápidamente. Datadog es excelente hasta que ves la factura. Aquí van algunas estrategias:

• Sampling en trazas: No necesitas trazar el 100% de las peticiones. Un 10-20% suele ser suficiente para detectar problemas. Traza siempre las peticiones con errores.
• Políticas de retención: ¿Necesitas logs de hace 6 meses? Probablemente no para el debugging del día a día. Define retenciones cortas para datos detallados y largas para métricas agregadas.
• Niveles de log en producción: No envíes logs de nivel DEBUG a producción. Es ruido caro. INFO y superiores suelen ser suficientes.
• Alertas inteligentes: Cada alerta que no es accionable es un coste — no solo económico, sino de atención del equipo.

Alertas: el arte de no generar fatiga

Una mala estrategia de alertas es peor que no tener alertas. Si tu equipo recibe 50 notificaciones al día, aprenderán a ignorarlas todas — incluida la que importa.

Alerta sobre síntomas, no sobre causas. Alerta cuando la tasa de errores sube por encima del 1%, no cuando la CPU llega al 80%. La CPU al 80% puede ser normal bajo carga; una tasa de errores del 5% nunca lo es.

Cada alerta necesita un runbook. Si alguien recibe una alerta a las 3 de la mañana, debería saber exactamente qué mirar primero. Sin runbook, es pánico + SSH + "qué es esto".

Clasifica por severidad. No todo es urgente. Un error intermitente en un endpoint poco usado puede esperar a mañana. Una caída del servicio de pagos, no.

La observabilidad como cultura

La observabilidad no es solo herramientas — es una mentalidad de ingeniería. Los equipos que la adoptan desde el inicio debuggean más rápido, despliegan con más confianza y duermen mejor.

En Conectia, los ingenieros senior que integramos en tu equipo construyen sistemas observables por defecto. No como un add-on después de la tercera caída en producción, sino como parte fundamental de la arquitectura. Porque cuando tu sistema crece y la complejidad aumenta, la diferencia entre un equipo que sabe lo que pasa en producción y uno que adivina es la diferencia entre escalar y sobrevivir.

---

¿Tu equipo se entera de los problemas en producción por los usuarios? Habla con un CTO — integramos ingenieros senior que construyen observabilidad desde el primer deploy.