Sense monitorització, la teva app està en producció a cegues

El teu equip ha treballat setmanes en una nova funcionalitat. La heu testejat, ha passat el pipeline de CI/CD i està en producció des d'aquest matí. Tot sembla anar bé. Fins que un usuari escriu al suport dient que lapp va lenta. Sense monitorització, aquest és el teu sistema d'alertes: els mateixos usuaris.

La monitorització de la teva app en producció no és un luxe que pots posposar quan el projecte sigui més gran. És el que separa un equip que reacciona d'un equip que se n'assabenta. Sense monitorització, la teva estratègia de detecció de problemes és “esperar que algú es queixi”. I quan algú es queixa, el problema fa hores o dies que hi és.

No necessites una sala de control amb pantalles gegants. Necessites els senyals correctes, els llindars adequats i un sistema que t'avisi quan alguna cosa surt del normal.

Què significa monitoritzar (sense el soroll enterprise)

Monitoritzar una aplicació en producció és observar-ne el comportament de forma contínua i automatitzada. L'objectiu: detectar problemes abans que els notin els usuaris. No és Big Data, no és observabilitat nivell NASA i no requereix un equip de SRE dedicat.

A la pràctica, monitoritzar es redueix a tres preguntes que el teu sistema hauria de poder respondre en qualsevol moment. L'app funciona? Està funcionant bé? Alguna cosa ha canviat respecte a ahir?

Si pots respondre aquestes tres preguntes sense connectar-te a un servidor ni obrir els logs a mà, la teva monitorització és funcional. Si no pots, tens un punt cec que tard o d'hora et costarà usuaris, diners o tots dos.

Les quatre mètriques que importen de debò

Hi ha desenes de mètriques que pots monitoritzar. Ús de CPU, memòria, disc, xarxa, connexions a base de dades, volies per segon, mida de cua, latència de DNS. La llista és interminable i vet aquí el problema: si ho vigiles tot, no vigiles res.

Per a un equip que gestiona un projecte en producció amb recursos limitats, hi ha quatre mètriques que cobreixen el 90% del que cal saber.

Disponibilitat (uptime). La teva app respon? No si respon ràpid o bé, simplement si respon. Un check cada minut que fa una petició HTTP al teu endpoint principal i verifica que torna un 200. Si deixa de respondre, t'assabentes en 60 segons, no en 60 minuts. Per a un backend Django desplegat a AWS oa un VPS, això és tan senzill com un healthcheck endpoint que verifica que l'app i la base de dades són vius.

Temps de resposta (latència). La teva app respon en un temps raonable? El temps mitjà és útil però enganyós. Si el 95% de les peticions triguen 200ms i el 5% triga 8 segons, la mitjana sembla acceptable. Però aquest 5% dels usuaris tenen una experiència terrible. Monitoritza el percentil 95 (p95): el temps que triga el 95% de les peticions. Si el p95 es dispara, alguna cosa va malament encara que la mitjana no es mogui.

Taxa derrors. Quin percentatge de peticions torna un error? Un 0,1% d'errors 500 en un dia normal pot ser acceptable. Un 2% és un senyal clar que s'ha trencat alguna cosa. L'important no és el nombre absolut sinó el canvi: si ahir tenies un 0.1% i avui en tens un 1.5%, alguna cosa ha passat entre mitges. Probablement el darrer desplegament.

Saturació. Els teus recursos són a prop del límit? CPU a 90%, memòria a 95%, disc ple, connexions a base de dades exhaurides. Aquestes mètriques no et diuen que alguna cosa ha fallat, et diuen que alguna cosa fallarà. Són les úniques que et fan marge per actuar abans de l'incident, no després.

Aquestes quatre mètriques no són invenció nostra. Google les va formalitzar com les Four Golden Signals al seu llibre de SRE. S'han convertit en l'estàndard de facto per a monitorització de serveis.

Logs, mètriques i traces: què és cada cosa

Si comenceu amb el monitoratge, aquests tres conceptes es barregen fàcilment. Però són eines diferents per a problemes diferents.

Logs són registres desdeveniments individuals. "L'usuari X va intentar fer login i va fallar", "La petició a /api/orders va trigar 3.2 segons", "Error en connectar amb la passarel·la de pagament". Són el nivell més detallat i el més útil per diagnosticar un problema concret. Django genera logs per defecte, però configurar bé (format estructurat, nivells adequats, rotació d'arxius) marca la diferència entre logs útils i soroll.

Mètriques són valors numèrics agregats en el temps. "Peticions per segon", "ús de memòria", "errors per minut". No et diuen què va passar exactament, però et diuen quan va canviar alguna cosa. Són el sistema d'alarma: les mètriques us desperten a les 3 del matí, els logs us diuen per què.

Traces segueixen una petició de principi a fi a través del sistema. L'usuari fa clic a "comprar". La petició passa pel servidor web, arriba a Django, consulta la base de dades i truca a la passarel·la de pagament. Una traça et mostra on es va embussar el procés. Per a un monòlit Django, les traces són menys crítiques que per a una arquitectura de microserveis. Però si la teva app parla amb serveis externs (pagaments, email, APIs de tercers), saber on es perd el temps és valuós.

Per començar, els logs ben configurats i quatre mètriques bàsiques són suficients. Les traces poden venir després, quan la complexitat del teu sistema ho justifiqui.

Eines sense overkill

Hi ha eines de monitoratge per a totes les butxaques i nivells de complexitat. L'error més comú és triar l'eina enterprise quan el teu projecte necessita alguna cosa pragmàtica.

Per a uptime i alertes bàsiques: UptimeRobot o Better Stack (abans Uptime) tenen plans gratuïts que monitoren endpoints HTTP i t'avisen per email, Slack o SMS si la teva app deixa de respondre. Es configuren en cinc minuts i cobreixen la necessitat més bàsica: saber que la teva app és viva.

Per a mètriques de servidor i aplicació: Si la teva infraestructura està a AWS, CloudWatch ve inclòs i et dóna mètriques de CPU, memòria i disc sense instal·lar res. Si utilitzes un VPS (Hetzner o similar), Prometheus amb Grafana és la combinació open source de referència. Requereix més configuració inicial, però és gratuïta i escala bé. Per a alguna cosa intermèdia, Datadog i New Relic tenen plans gratuïts limitats que són suficients per a projectes petits.

Per a logs: En un projecte Django, la configuració de logging de Python ja et dóna una base sòlida. Envia els logs a un servei centralitzat (Papertrail, Logtail o el mateix CloudWatch Logs) per poder buscar i filtrar sense connectar-te al servidor. Revisar logs per SSH funciona per a un servidor. Quan en tens dos o tres, necessites un lloc central.

Per a errors d'aplicació: Sentry és l'estàndard de captura d'excepcions. S'integra amb Django i Flutter en minuts i us mostra cada error amb el seu stack trace, l'usuari afectat i el context de la petició. El pla gratuït cobreix de sobres un projecte en fase de creixement. Si un error salta en producció, el veus a Sentry abans que lusuari escrigui al suport.

La regla: comença amb el mínim que et doni visibilitat. Un healthcheck, Sentry per a errors i mètriques bàsiques del servidor. Podeu iterar després.

Alertes: l'art de no saturar-se

El monitoratge sense alertes és un dashboard que ningú no mira. Però les alertes mal configurades són pitjors que no tenir alertes: generen fatiga, l'equip les comença a ignorar i quan arriba una alerta real, ningú reacciona.

Alerta només el que requereix acció. Si una alerta salta i la resposta de l'equip és "ja ho veiem demà", aquesta alerta no hi hauria d'haver. Cada alerta ha de tenir una acció clara associada: reiniciar un servei, investigar-ne un desplegament recent, escalar recursos.

Distingeix entre urgent i informatiu. L'app no ​​respon és urgent: Slack, SMS, cosa que faci falta perquè algú ho vegi en minuts. L'ús de CPU ha pujat un 15% respecte ahir és informatiu: un correu electrònic o un missatge en un canal de monitorització que algú revisarà en horari laboral. Barrejar tots dos nivells al mateix canal és la forma més ràpida que l'equip ho ignori tot.

Fes servir llindars amb context. Un temps de resposta de 500ms pot ser normal per a una petició que genera un informe PDF i un desastre per a un endpoint que torna un JSON de 10 camps. Els llindars han de reflectir allò que és normal per a cada servei, no un nombre arbitrari aplicat a tot.

Menys és més. Un equip petit hauria de tenir entre cinc i deu alertes actives, no pas cinquanta. Cada alerta nova que afegeixes dilueix latenció de les existents. Segons l' informe DORA , els equips d'alt rendiment tenen menys alertes, però més rellevants. Responen més ràpid precisament perquè no estan saturats de soroll.

Què monitoritzar segons el tipus de projecte

No tots els projectes necessiten el mateix monitoratge. Allò que vigiles depèn del que pot fallar i de l'impacte que té aquesta decisió.

E-commerce o app amb pagaments. El flux de compra és sagrat. Monitoritza la taxa d'èxit de transaccions, la latència de la passarel·la de pagament i qualsevol error al checkout. Un 1% de fallades en el pagament poden significar milers d'euros perduts al mes. Aquí un test end-to-end que simula una compra cada cinc minuts val el pes en or.

App amb autenticació i dades dusuari. Monitoritza el flux de login (taxa d'èxit, latència), els errors de permisos i qualsevol anomalia a l'accés a dades sensibles. Un pic d'errors 403 pot ser un bug o pot ser pitjor.

API o backend que serveix a un frontend o app mòbil. Monitoritza la latència per endpoint, la taxa derrors per versió de client i la compatibilitat amb versions anteriors. Si desplegues una nova versió del backend i l'app Flutter en producció comença a fallar, cal saber-ho abans que ho sàpiga l'usuari.

CMS o plataforma de contingut. Monitoritza els temps de càrrega de les pàgines públiques, el rendiment del panell d'administració i l'estat de les tasques programades (importacions, enviaments de correu electrònic, generació de contingut). Un CMS amb Wagtail pot funcionar perfectament per als editors i tenir les pàgines públiques lentes per una query mal optimitzada que només apareix amb volum real de contingut.

L'error de monitoritzar després

La majoria d'equips munten el monitoratge després del primer incident greu. Un divendres a la nit l'app cau, ningú se n'assabenta fins dilluns, els usuaris es queixen i algú diu: "cal posar monitorització". És un patró tan comú com evitable.

La monitorització hauria d'arribar just després del primer desplegament automatitzat. Si ja tens un pipeline de CI/CD que desplega a producció, el pas natural següent és saber si el que has desplegat funciona. No la setmana que ve. No quan el projecte sigui més gran. Ara.

Muntar un monitoratge bàsic fa menys de mig dia: un healthcheck amb UptimeRobot, Sentry per a errors i les mètriques de servidor que el teu proveïdor ja t'ofereix (CloudWatch a AWS, les mètriques natives de Hetzner o les del teu panell de VPS). Amb això, la propera vegada que alguna cosa falli, t'assabentaràs tu primer.

I aquesta és la diferència entre un equip professional i un que funciona a força de sort: no que res falli, sinó que quan falla, ho saps abans que ningú.