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.

He visto esta escena más veces de las que puedo contar — tanto en startups como durante mis años de respuesta a incidentes en entornos enterprise. 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 dos horas después alguien por fin encuentra el problema. ¿Te suena?

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 se amortiza desde el primer día.

Tres pilares, tres preguntas distintas

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é ha pasado? 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: ¿En qué punto del sistema? Muestran el recorrido de una petición a través de múltiples servicios. La petición entró por el API gateway, pasó por el 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.

El 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 distintos para investigar un problema, ya has perdido. 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 solo servicio ya no basta

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

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 para una startup: constrúyelo por fases

No intentes implementarlo 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 tu proveedor de cloud te da 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 se encarece deprisa. Datadog es excelente hasta que ves la factura. 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 ninguna. Si tu equipo recibe 50 notificaciones al día, aprenderá 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. Quien recibe una alerta a las 3 de la madrugada debería saber exactamente qué mirar primero. Sin runbook, es pánico + SSH + "¿y esto qué es?".

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 principio depuran 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 todavía se entera de los problemas en producción por sus usuarios? Habla con un CTO — es un problema con solución.