AXENTED — Blog Article
Slug: /blog-posts/observability-stack-small-teams |
Meta description: Un equipo de ingeniería pequeño necesita logs, métricas y trazas — no una función de FinOps. Un stack de observabilidad práctico que cubre las necesidades de producción a un costo casi nulo. |
Target keywords: stack observabilidad equipo pequeño, monitoreo startup, logging métricas tracing, prometheus grafana startup |
Los equipos de ingeniería grandes tienen la observabilidad integrada en su función de platform engineering. New Relic o Datadog con APM completo, distributed tracing en cada servicio, dashboards personalizados para cada equipo y un SRE dedicado que monitorea los dashboards. Ese stack cuesta decenas de miles de dólares al mes y requiere un ingeniero de tiempo completo para operarlo.
Nada de eso es apropiado para un equipo de cuatro a ocho ingenieros construyendo su primer sistema en producción. Pero operar sin observabilidad es peor. Aquí hay un stack práctico.
Todo sistema en producción necesita tres cosas para ser observable: logs (qué ocurrió), métricas (cómo está funcionando el sistema) y trazas (cómo se movió una solicitud a través del sistema). Un equipo pequeño no necesita los tres al mismo nivel de profundidad que un equipo grande, pero las brechas son costosas cuando ocurren problemas en producción.
El fallo de observabilidad más común en equipos pequeños es tener logs pero no métricas ni trazas. Los logs te dicen que algo salió mal. Las métricas te dicen cuándo el sistema comenzó a degradarse antes de convertirse en un error. Las trazas te dicen dónde, en una solicitud multi-servicio, se originó la latencia o el fallo. Sin los tres, depurar problemas de producción es mucho más lento de lo que debería ser.
Las líneas de log no estructuradas — texto plano en un archivo — son peores que no tener logs en el momento en que necesitas buscar en ellos. Los logs estructurados (JSON, pares clave-valor) son consultables: puedes filtrar por user ID, por request ID, por tipo de error. La inversión para escribir logs estructurados es pequeña al principio y devuelve valor cada vez que depuras un problema de producción.
Para equipos pequeños, Cloudwatch Logs (si estás en AWS) o un servicio gestionado de agregación de logs cubre las necesidades sin sobrecarga operativa. La configuración importante es enviar logs estructurados con campos consistentes en todos los servicios: timestamp, nombre del servicio, nivel de log, request ID, user ID cuando sea relevante. Los campos consistentes hacen posibles las consultas entre servicios.
Un equipo pequeño no necesita 40 dashboards de métricas. Necesita cuatro: request rate (cuántas solicitudes por segundo), error rate (qué porcentaje de solicitudes están devolviendo errores), latencia (tiempos de respuesta p50, p95, p99) y utilización de recursos (uso de CPU y memoria en los hosts de producción). Esas cuatro métricas detectan el 90% de los problemas de producción antes de que se conviertan en interrupciones.
Para la mayoría de los equipos pequeños, Prometheus con Grafana es la elección open-source correcta. La inversión de configuración es de uno o dos días; el costo operativo es mínimo en infraestructura pequeña. Si el self-hosting es una carga, Grafana Cloud tiene un nivel gratuito generoso que cubre el uso de equipos pequeños.
El distributed tracing tiene alto valor cuando tienes múltiples servicios manejando una sola solicitud de usuario y necesitas entender qué servicio es responsable de la latencia o los fallos. Para una arquitectura simple (una API, una base de datos), el tracing agrega sobrecarga sin valor proporcional.
Agrega tracing cuando tienes tres o más servicios en una ruta de solicitud y te encuentras diciendo "sé que el API es lento pero no sé si es la base de datos, el caché o el servicio downstream." En ese punto, OpenTelemetry instrumentado hacia un backend Jaeger o Tempo resuelve el problema de forma eficiente y a bajo costo.
Un stack de observabilidad sin alertas es un stack que tienes que monitorear manualmente. Las alertas deben dispararse cuando las tasas de error superen un umbral, cuando la latencia supere un umbral, o cuando un servicio deje de reportar métricas por completo (lo que generalmente significa que crashó). Esas tres categorías de alertas detectan la gran mayoría de los problemas de producción.
La fatiga de alertas — demasiadas alertas, demasiados falsos positivos — es lo que destruye la cultura de observabilidad. Establece los umbrales de alerta de forma conservadora: deben dispararse cuando un humano necesita actuar, no cada vez que una métrica se mueve. Si una alerta se dispara más de una vez a la semana y nunca requiere acción, el umbral es incorrecto.
Un stack de observabilidad práctico para equipos pequeños a un costo casi nulo: logs estructurados hacia Cloudwatch o Loki, métricas Prometheus con dashboards de Grafana, PagerDuty u OpsGenie para enrutamiento de alertas (los niveles gratuitos cubren equipos pequeños), y tracing con OpenTelemetry cuando el número de servicios lo justifica. Todo el stack puede estar funcionando en una semana con un ingeniero que ya lo ha hecho antes.
%20(1)-2.svg)
