Observabilitat per a Startups: Logs, Metriques i Traces sense Arruinar-te

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

Es una situacio mes comuna del que sembla. L'aplicacio cau, un client envia un email furios, l'equip es posa a revisar logs a la consola d'AWS, algu diu "a mi em funciona" i aixi passen dues hores fins que algu troba el problema. Sona familiar, oi?

L'observabilitat no es un luxe d'empreses grans amb equips de SRE dedicats. Es la capacitat d'entendre que esta passant al teu sistema sense haver-ho d'endevinar. I en una startup, on cada incident et pot costar usuaris (i la seguent ronda de financament), es una inversio que retorna el seu cost des del primer dia.

Els tres pilars de l'observabilitat

Hi ha un framework classic que divideix l'observabilitat en tres pilars: logs, metriques i traces. No son intercanviables — cadascun respon a una pregunta diferent.

• Logs: Que ha passat? Son registres d'events discrets. Un usuari va intentar fer login, una transaccio va fallar, un servei es va reiniciar.
• Metriques: Quant i a quina velocitat? Son dades numeriques agregades en el temps. Latencia mitjana, taxa d'errors, us de CPU.
• Traces: On al sistema? Son el recorregut d'una peticio a traves de multiples serveis. La request va entrar per l'API gateway, va passar al servei d'autenticacio, va consultar la base de dades, va cridar el servei de pagaments.

No necessites els tres des del dia u. Pero si que necessites entendre quan incorporar cadascun.

Logs: la base de tot

Tot sistema genera logs. La diferencia esta en si els generes de forma util o si simplement fas console.log("error aqui") i pregues.

Logging estructurat es el primer que hauries d'implementar. En lloc de strings solts, genera logs en format JSON amb camps consistents: timestamp, nivell, servei, missatge, request ID, usuari. Aixo permet buscar, filtrar i agregar automaticament.

{
  "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 significar alguna cosa. Si tot es INFO o tot es ERROR, no tens nivells — tens soroll. Defineix una convencio clara: DEBUG per a desenvolupament, INFO per a fluxos normals, WARN per a situacions recuperables, ERROR per a fallades que necessiten atencio.

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

• Pressupost minim: Loki + Grafana (open source, lleuger, perfecte per comencar)
• Cloud natiu: CloudWatch Logs (AWS), Cloud Logging (GCP)
• Tot en un: Datadog, New Relic (mes car, pero mes complet)
• Classic: ELK Stack (Elasticsearch, Logstash, Kibana) — potent pero requereix manteniment

Metriques: les 4 senyals daurades

Google va definir les 4 senyals daurades de monitoritzacio, i segueixen sent el millor punt de partida:

1. Latencia: Quant tarda el teu servei a respondre? No nomes la mitjana — els percentils p95 i p99 son els que importen. Si la teva latencia mitjana es 200ms pero el p99 es 5 segons, tens un problema que la mitjana amaga.

2. Trafic: Quantes peticions estas rebent? T'ajuda a entendre patrons d'us i detectar anomalies (pics inesperats o caigudes sobtades).

3. Errors: Quin percentatge de peticions fallen? Tant errors explicits (HTTP 5xx) com implicits (respostes correctes pero amb dades erronies).

4. Saturacio: Com de ple esta el teu sistema? CPU, memoria, disc, connexions a base de dades. Quan alguna cosa se satura, tot el demes comenca a degradar-se.

Hi ha una distincio important entre metriques d'aplicacio i metriques d'infraestructura. Les d'infraestructura (CPU, memoria, disc) et diuen que alguna cosa va malament. Les d'aplicacio (peticions per segon, taxa d'errors, latencia per endpoint) et diuen que va malament. Necessites totes dues.

Eines:

• Prometheus + Grafana: L'estandard open source. Prometheus recol·lecta i emmagatzema metriques, Grafana les visualitza. Gratuit, potent, i amb un ecosistema enorme.
• Datadog: Metriques, logs i traces en una sola plataforma. Excel·lent pero car — compte amb la factura.
• New Relic: Similar a Datadog. Te un tier gratuit decent per comencar.

Traces: quan un servei no es suficient

Si tens un monolit simple, probablement no necessites traces distribuides encara. Pero en quant tinguis dos o mes serveis comunicant-se entre si, les traces es tornen essencials.

Una traca distribuida et mostra el recorregut complet d'una peticio a traves del teu sistema. Veus exactament on es gasta el temps, on falla i quin servei esta causant el coll d'ampolla.

OpenTelemetry s'ha consolidat com l'estandard per a instrumentacio. Es open source, vendor-neutral, i suporta logs, metriques i traces. Si invertiras temps en instrumentar el teu codi, fes-ho amb OpenTelemetry — aixi no et lliges a cap vendor especific.

Eines:

• Jaeger: Open source, creat per Uber. Perfecte per comencar amb traces distribuides.
• Zipkin: Una altra opcio open source, mes simple que Jaeger.
• Datadog APM / New Relic: Si ja fas servir la seva plataforma per a metriques, afegir traces es natural.

L'stack amigable per a startups

No intentis implementar-ho tot de cop. Aquesta es una progressio sensata:

Fase 1 — El minim viable (des del dia 1):

• Logging estructurat en JSON
• Logs centralitzats (Loki + Grafana o CloudWatch)
• Metriques basiques d'infraestructura (el que et dona el teu cloud provider gratuit)
• Alertes sobre errors HTTP 5xx i latencia

Fase 2 — Maduracio (quan tinguis usuaris reals):

• Metriques d'aplicacio amb Prometheus + Grafana
• Dashboards per servei amb les 4 senyals daurades
• Alertes mes sofisticades amb severitats

Fase 3 — Distribucio (quan tinguis multiples serveis):

• OpenTelemetry per a instrumentacio
• Traces distribuides amb Jaeger o el teu APM de preferencia
• Correlacio entre logs, metriques i traces (el request ID es la clau)

Optimitzacio de costos: no t'arruinis monitoritzant

L'observabilitat pot tornar-se cara rapidament. Datadog es excel·lent fins que veus la factura. Aqui van algunes estrategies:

• Sampling en traces: No necessites tracar el 100% de les peticions. Un 10-20% sol ser suficient per detectar problemes. Traca sempre les peticions amb errors.
• Politiques de retencio: Necessites logs de fa 6 mesos? Probablement no per al debugging del dia a dia. Defineix retencions curtes per a dades detallades i llargues per a metriques agregades.
• Nivells de log en produccio: No enviis logs de nivell DEBUG a produccio. Es soroll car. INFO i superiors solen ser suficients.
• Alertes intel·ligents: Cada alerta que no es accionable es un cost — no nomes economic, sino d'atencio de l'equip.

Alertes: l'art de no generar fatiga

Una mala estrategia d'alertes es pitjor que no tenir alertes. Si el teu equip rep 50 notificacions al dia, aprendran a ignorar-les totes — inclosa la que importa.

Alerta sobre simptomes, no sobre causes. Alerta quan la taxa d'errors puja per sobre de l'1%, no quan la CPU arriba al 80%. La CPU al 80% pot ser normal sota carrega; una taxa d'errors del 5% no ho es mai.

Cada alerta necessita un runbook. Si algu rep una alerta a les 3 de la matinada, hauria de saber exactament que mirar primer. Sense runbook, es panic + SSH + "que es aixo".

Classifica per severitat. No tot es urgent. Un error intermitent en un endpoint poc usat pot esperar a dema. Una caiguda del servei de pagaments, no.

L'observabilitat com a cultura

L'observabilitat no es nomes eines — es una mentalitat d'enginyeria. Els equips que l'adopten des de l'inici debuggen mes rapid, despleguen amb mes confianca i dormen millor.

A Conectia, els enginyers senior que integrem al teu equip construeixen sistemes observables per defecte. No com un add-on despres de la tercera caiguda en produccio, sino com a part fonamental de l'arquitectura. Perque quan el teu sistema creix i la complexitat augmenta, la diferencia entre un equip que sap el que passa en produccio i un que endevina es la diferencia entre escalar i sobreviure.

---

El teu equip s'assabenta dels problemes en produccio pels usuaris? Parla amb un CTO — integrem enginyers senior que construeixen observabilitat des del primer deploy.