Observabilitat per a startups: logs, mètriques i traces sense deixar-t'hi la camisa

Si t'assabentes dels problemes en producció pels teus usuaris, no tens observabilitat — tens un canal de suport.

He perdut el compte de les vegades que he vist aquesta escena, tant a startups com durant els meus anys de resposta a incidents en entorns corporatius. L'aplicació cau, un client envia un correu furiós, l'equip es posa a remenar logs a la consola d'AWS, algú diu «a mi em funciona», i dues hores més tard algú troba per fi el problema. Et sona?

L'observabilitat no és un luxe reservat a les grans empreses amb equips d'SRE dedicats. És la capacitat d'entendre què passa al teu sistema sense haver d'endevinar-ho. I en una startup, on cada incident et pot costar usuaris (i la pròxima ronda de finançament), és una inversió que es paga sola des del primer dia.

Tres pilars, tres preguntes diferents

Hi ha un marc clàssic que divideix l'observabilitat en tres pilars: logs, mètriques i traces. No són intercanviables — cadascun respon una pregunta diferent.

• Logs: què ha passat? Són registres d'esdeveniments discrets. Un usuari ha intentat iniciar sessió, una transacció ha fallat, un servei s'ha reiniciat.
• Mètriques: quant i a quina velocitat? Són dades numèriques agregades al llarg del temps. Latència mitjana, taxa d'errors, ús de CPU.
• Traces: a quin punt del sistema? Mostren el camí que segueix una petició a través de diversos serveis. La petició ha entrat per l'API gateway, ha passat pel servei d'autenticació, ha consultat la base de dades, ha cridat el servei de pagaments.

No necessites els tres des del dia u. Però sí que necessites entendre quan incorporar cadascun.

Logs: el fonament de tot

Tots els sistemes generen logs. La diferència és si els generes de manera útil o si fas console.log("error aquí") i creues els dits.

El logging estructurat és la primera cosa que hauries d'implementar. En lloc de cadenes de text soltes, genera logs en format JSON amb camps consistents: timestamp, nivell, servei, missatge, ID de petició, usuari. Això et permet cercar, filtrar i agregar automàticament.

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

Els nivells de log han de voler dir alguna cosa. Si tot és INFO o tot és ERROR, no tens nivells — tens soroll. Defineix una convenció clara: DEBUG per a desenvolupament, INFO per a fluxos normals, WARN per a situacions recuperables, ERROR per a fallades que demanen atenció.

Centralitza els logs. Si has de fer SSH a tres servidors diferents per investigar un problema, ja has perdut. Opcions segons el pressupost:

• Pressupost mínim: Loki + Grafana (open source, lleuger, perfecte per començar)
• Cloud natiu: CloudWatch Logs (AWS), Cloud Logging (GCP)
• Tot en un: Datadog, New Relic (més cars, però més complets)
• Clàssic: ELK Stack (Elasticsearch, Logstash, Kibana) — potent, però demana manteniment

Mètriques: els 4 senyals daurats

Google va definir els 4 senyals daurats del monitoratge, i continuen sent el millor punt de partida:

1. Latència: quant triga el teu servei a respondre? No només la mitjana — els percentils p95 i p99 són els que importen. Si la latència mitjana és de 200 ms però el p99 és de 5 segons, tens un problema que la mitjana amaga.

2. Trànsit: quantes peticions reps? T'ajuda a entendre els patrons d'ús i a detectar anomalies (pics inesperats o caigudes sobtades).

3. Errors: quin percentatge de peticions falla? Tant els errors explícits (HTTP 5xx) com els implícits (respostes correctes però amb dades equivocades).

4. Saturació: fins a quin punt està ple el teu sistema? CPU, memòria, disc, connexions a la base de dades. Quan alguna cosa se satura, la resta comença a degradar-se.

Hi ha una distinció important entre mètriques d'aplicació i mètriques d'infraestructura. Les d'infraestructura (CPU, memòria, disc) et diuen que alguna cosa falla. Les d'aplicació (peticions per segon, taxa d'errors, latència per endpoint) et diuen què falla. Necessites totes dues.

Eines:

• Prometheus + Grafana: l'estàndard open source. Prometheus recull i emmagatzema les mètriques; Grafana les visualitza. Gratuït, potent i amb un ecosistema enorme al darrere.
• Datadog: mètriques, logs i traces en una sola plataforma. Excel·lent però car — vigila la factura.
• New Relic: similar a Datadog. Té un tier gratuït decent per començar.

Traces: quan amb un servei no n'hi ha prou

Si tens un monòlit simple, probablement encara no necessites traces distribuïdes. Però així que tinguis dos o més serveis parlant entre ells, les traces es tornen imprescindibles.

Una traça distribuïda et mostra el recorregut complet d'una petició pel teu sistema. Veus exactament on se'n va el temps, on falla i quin servei provoca el coll d'ampolla.

OpenTelemetry s'ha convertit en l'estàndard d'instrumentació. És open source, neutral respecte del proveïdor, i suporta logs, mètriques i traces. Si has d'invertir temps a instrumentar el teu codi, fes-ho amb OpenTelemetry — així no quedes lligat a cap proveïdor concret.

Eines:

• Jaeger: open source, creat per Uber. Perfecte per començar amb les traces distribuïdes.
• Zipkin: una altra opció open source, més senzilla que Jaeger.
• Datadog APM / New Relic: si ja fas servir la seva plataforma per a les mètriques, afegir-hi traces és el pas natural.

L'stack per a startups: construeix-lo per fases

No intentis implementar-ho tot de cop. Aquesta és una progressió assenyada:

Fase 1 — El mínim viable (des del dia 1):

• Logging estructurat en JSON
• Logs centralitzats (Loki + Grafana o CloudWatch)
• Mètriques bàsiques d'infraestructura (el que el teu proveïdor de cloud et doni gratis)
• Alertes per errors HTTP 5xx i latència

Fase 2 — Maduració (quan tinguis usuaris reals):

• Mètriques d'aplicació amb Prometheus + Grafana
• Dashboards per servei amb els 4 senyals daurats
• Alertes més sofisticades amb nivells de severitat

Fase 3 — Distribució (quan tinguis múltiples serveis):

• OpenTelemetry per a la instrumentació
• Traces distribuïdes amb Jaeger o l'APM que prefereixis
• Correlació entre logs, mètriques i traces (l'ID de petició és la clau)

Optimització de costos: que monitorar no t'arruïni

L'observabilitat es pot encarir de pressa. Datadog és excel·lent fins que arriba la factura. Algunes estratègies:

• Mostreig de traces: no necessites traçar el 100% de les peticions. Amb un 10-20% sol haver-n'hi prou per detectar problemes. Traça sempre les peticions que acaben en error.
• Polítiques de retenció: necessites els logs de fa sis mesos? Per al debugging del dia a dia, probablement no. Defineix retencions curtes per a les dades detallades i llargues per a les mètriques agregades.
• Nivells de log en producció: no enviïs logs de nivell DEBUG a producció. És soroll car. Amb INFO i superiors sol haver-n'hi prou.
• Alertes intel·ligents: cada alerta que no és accionable és un cost — no només econòmic, sinó d'atenció de l'equip.

Alertes: l'art d'evitar la fatiga

Una mala estratègia d'alertes és pitjor que no tenir-ne. Si el teu equip rep 50 notificacions al dia, aprendrà a ignorar-les totes — inclosa la que importa.

Alerta per símptomes, no per causes. Alerta quan la taxa d'errors superi l'1%, no quan la CPU arribi al 80%. Una CPU al 80% pot ser normal sota càrrega; una taxa d'errors del 5% no ho és mai.

Cada alerta necessita un runbook. Si algú rep una alerta a les 3 de la matinada, ha de saber exactament què ha de mirar primer. Sense runbook, tot plegat és pànic + SSH + «què és això».

Classifica per severitat. No tot és urgent. Un error intermitent en un endpoint poc utilitzat pot esperar fins al matí. Una caiguda del servei de pagaments, no.

L'observabilitat com a cultura

L'observabilitat no són només eines — és una mentalitat d'enginyeria. Els equips que l'adopten des del principi depuren més de pressa, despleguen amb més confiança i dormen més tranquils.

A Conectia, els enginyers sènior que integrem al teu equip construeixen sistemes observables per defecte. No com un afegit després de la tercera caiguda en producció, sinó com a part fonamental de l'arquitectura. Perquè quan el sistema creix i la complexitat augmenta, la diferència entre un equip que sap què passa en producció i un que ho endevina és la diferència entre escalar i sobreviure.

---

El teu equip encara s'assabenta dels problemes de producció pels usuaris? Parla amb un CTO — és un problema que té solució.