Monitoring, Logging, Tracing: Com fracassen els projectes d'observabilitat i com salvar-los amb SLOs clars

Un projecte d’observabilitat comença en moltes empreses amb un bon impuls: detectar fallades més ràpid, delimitar les causes amb claredat, alleujar l’equip de suport i fer els llançaments més segurs. A la pràctica, però, la iniciativa sovint deriva cap al contrari: massa dashboards sense contingut, massa alarmes sense prioritat, costos d’emmagatzematge i de llicència a l’alça, i al final queda oberta la pregunta de si l’operació millora realment.

L’error fonamental rarament és l’absència d’una eina. Sovint falta una definició d’objectius tècnics clara: què ha de funcionar de manera fiable per a quina cadena de servei o de procés — i com ho mesurem? Precisament aquí ajuden els SLOs (Service Level Objectives, valors objectiu mesurables per a un servei) com a línies mestres. Els SLOs connecten la telemetria tècnica (monitoratge, registre, tracing) amb la realitat operativa, les responsabilitats i els camins de decisió.

Aquesta contribució classifica patrons típics de fallada i mostra com podeu tornar a encaminar l’observabilitat amb SLOs clars — amb mirada a l’operació, l’administració, les dades, les interfícies, el manteniment, la seguretat i el desplegament.

Monitoring, Logging, Tracing: Què és què — i per què «més dades» no és suficient?

L’observabilitat s’utilitza sovint com a terme paraigua. Per a l’operació és important separar clarament els tres tipus de senyals:

• Monitoring/Mètriques: sèries temporals agregades (p. ex. temps de resposta, taxes d’error, longituds de cues). Avantatge: ràpid, econòmic i fàcil de vincular a alertes. Risc: sense context costa d’interpretar.
• Logging: esdeveniments amb context (p. ex. comanda creada, validació fallida, una API externa respon 503). Avantatge: detallat i auditable. Risc: volums de dades, protecció de dades, „sopa de logs“ sense estructura.
• Tracing: traces d’execució distribuïts entre diverses components (distributed tracing). Avantatge: mostra on es perd temps i quina dependència està bloquejant. Risc: instrumentació, estratègia de mostreig, correlació entre sistemes.

Una errada comuna: si només recopilem prou logs i traces, els incidents es resolen gairebé sols. En realitat, al principi augmenta la complexitat. Sense una imatge objectiu i criteris de rellevància, l’observabilitat esdevé un dipòsit de dades — no pas un instrument de gestió.

Per què fracassen els projectes d’observabilitat: els patrons més comuns del dia a dia operatiu

Els patrons següents apareixen amb especial freqüència en paisatges empresarials madurs — és a dir, on el programari empresarial, les interfícies i la infraestructura han crescut durant anys i hi participen diversos equips.

1) Tool-first statt Service-first: Dashboards ohne Betriebsentscheidung

S’introdueix una nova eina APM o de logs i, “per si de cas”, es creen dashboards. El que falta és la pregunta: Quina decisió operativa ha de fer-se més ràpid o millor amb això? Un dashboard que no ajuda durant un incident sovint, en el dia a dia, és només decoració. Símptoma típic: en cas d’avaria els equips salten entre deu vistes sense saber quina d’elles és fiable.

2) Inundació d’alarmes i fatiga d’alertes: Tot és crític, per tant res no ho és

Si cada pic de CPU, cada error HTTP individual i cada advertència d’un agent acaba en alarma, el resultat no és més seguretat sinó embotiment. fatiga d’alertes vol dir: l’on-call respon més tard, les escalades es tornen confuses i les incidències reals passen desapercebudes. Per a la direcció TI això també suposa un risc en termes de compliància i capacitat de justificació: “Hem tingut alarmes” no prova que s’hagi reaccionat de manera dirigida.

3) Cap correlació: tiquets sense Trace-IDs, logs sense context

Precisament en solucions de software properes a processos (workflows propers a ERP, carrils d’integració, portals) els incidents sovint es produeixen a les interficies: REST-APIs, message brokers, imports de fitxers, EDI, proveïdors d’identitat. Sense una ID de correlació (un identificador únic que viatja al llarg de la cadena) no es pot seguir un únic procés de punta a punta. Resultat: molt temps gastat en “és això a casa nostra o al partner?” en lloc d’anàlisi de causa arrel.

4) Explosió de costos per l’augment del volum de logs i traces

El logging i el tracing són intensius en dades. Sense una estratègia de retenció (durada d’emmagatzematge), sampling (mostreig dirigit per a traces) i regles de filtratge, l’emmagatzematge i la ingestió es fan cares ràpidament – tant on-prem com al núvol. Sovint aleshores es retalla de forma precipitada, la qual cosa empitjora la qualitat de les dades. Això crea un cercle viciós: menys confiança → més logging “per seguretat” → costos més alts.

5) Les qüestions de seguretat i privadesa es tracten massa tard

Els logs poden contenir ràpidament dades personals (noms, correu electrònic, IP, números de client) o contingut sensible (tokens, Session-IDs, URLs internes). Si la perspectiva legal i de seguretat arriba només després del desplegament, hi ha risc de dues males opcions: apagar-ho o “seguir igual” assumint el risc. L’observability ha d’integrar des del principi la classificació de dades (necessitat de protecció), l’enmascarament/redacció i els conceptes d’accés.

6) Propietat poc clara: qui assumeix la responsabilitat de cada servei?

En moltes empreses l’equip A gestiona la infraestructura, l’equip B l’aplicació, l’equip C la integració i l’equip D la capa de base de dades. L’observability mostra problemes, però sense una clara delimitació de servei i obligacions d’operació la responsabilitat queda difusa. Això acaba en discussions de chat en lloc d’un procés d’incident net amb una transició clara.

SLOs com a salvavides: què aporta un bon SLO

SLOs són valors objectius mesurables per a la qualitat del servei. S’originen a partir de SLIs (Service Level Indicators, l’indicador mesurat). Important: els SLOs no són principalment nombres de màrqueting sobre “disponibilitat”, sinó una eina de govern per a l’operació i la priorització.

Un bon SLO respon per a un servei concret (p. ex. “enregistrament de comandes al portal”, “pujada de documents”, “procés nocturn de facturació”, “API per a enregistraments d’estoc”) tres preguntes:

• Què és “bo” des de la perspectiva de l’usuari? (p. ex. “Resposta < 1,5 s” o “Èxit sense errors”)
• Com ho mesurem de manera objectiva? (SLI, font de dades, finestra de mesura)
• Què succeeix si no s’acompleix? (prioritats, aturada de canvis, mesures de capacitat)

Això transforma l’observabilitat d’un llac de dades en un sistema que recolza la presa de decisions: Què és realment crític ara mateix? On invertim a continuació? Quins riscos acceptem de manera conscient?

Dels SLAs a SLOs i Error Budgets: una classificació pràctica per a decisors

A les empreses sovint existeixen SLAs (Service Level Agreements, acords contractuals o compromisos interns). Els SLOs estan més lligats a la tècnica i a l’operació i poden servir com a palanca interna de control, fins i tot quan un SLA és molt genèric.

Un mecanisme central és l‘Error Budget: si un SLO, p. ex., exigeix un 99,9% d’èxit en 30 dies, s’accepta un petit „pressupost“ d’errors/indisponibilitat. Això pot semblar contraintuïtiu al principi, però és valuós operativament: permet un balanç objectiu entre estabilitat i canvi (releases, migracions, optimització del rendiment).

Important per a la pràctica: els Error Budgets només funcionen si la mesura és justa i l’organització està disposada a tirar endavant les conseqüències. Si no, només es converteix en una altra mètrica més.

Definir SLOs que realment governin el monitoring, logging i tracing

L’error més habitual amb els SLOs és que siguin massa genèrics („99,9% de disponibilitat de l’aplicació“). Més útil és una estructura d’SLO alineada amb les accions d’usuari i els punts d’integració. Un procediment pragmàtic:

Pas 1: Tallar límits de servei al llarg de la cadena de processos

No defineixi els „services“ segons l’organigrama, sinó segons l’efecte: p. ex. „crear comanda“, „procesar pagament“, „registrar comissionament“, „interfície amb el transportista“. Especialment en entorns de programari empresarial a mida, aquests límits són crucials perquè el suport i l’àrea de negoci pensen en aquestes unitats.

Pas 2: Per servei 1–3 SLIs que reflecteixin l’impacte sobre l’usuari

Són recomanables SLIs com:

• Taxa d’èxit d’una transacció (p. ex. HTTP 2xx/3xx, o „Business Success“ segons la lògica de l’aplicació)
• Latència en el camí crític (p95/p99 en comptes de la mitjana)
• Frescor en pipelines de dades („Quina antiguitat tenen les dades al DWH/reporting?“)

La clau: no tota mètrica de sistema és un SLI. Una CPU alta és un símptoma, però no un resultat per a l’usuari. Utilitzeu les mètriques del sistema per al diagnòstic, no com a objectiu.

Pas 3: Definir clarament fines de mesura, exclusions i dependències

Un SLO sense fines de mesura és inútil. Determineu: 28 dies rodó? Per mesos? Només en horari de negoci? I aclarir quines dependències s’inclouen: si una API d’un partner extern cau, compta en el vostre SLO? Per a operació i escalada, aquesta claredat és or.

Pas 4: Vincular l’alerting a la SLO-Burn-Rate

En lloc de „Alarma quan errors > X en 5 minuts“, en la pràctica sovint funciona millor un enfocament de burn-rate: a quina velocitat es consumeix l’Error Budget? Això permet prioritzar les alarmes segons el risc per l’assoliment de l’objectiu, no segons el volum d’una mètrica individual. Resultat: menys alarmes, però més rellevants.

Conseqüències arquitectòniques: què cal planificar tècnicament per a una observabilitat fiable

SLOs són governança, però necessiten una base tècnica. En entorns madurs rarament és «només configurar». Components típics d’arquitectura:

Pipeline de telemetria: recollida, transformació, emmagatzematge, exposició

Ja sigui on-prem o Cloud: necessiteu una cadena clara de com la telemetria entra al sistema. Això inclou Agenten/Collector, Transport (Queue/Buffer), Prozessierung (Parsing, Enrichment, Redaction), emmagatzematge i accés. Precisament en logging i tracing és important un búfer per absorbir pics de càrrega i, en cas d’incidència, no carregar els sistemes productius.

Identitäten und Zugriffe: Wer darf welche Daten sehen?

Les dades d’observability sovint són sensibles. Planegeu rols i conceptes de tenant: l’operació veu mètriques d’infraestructura, el suport veu esdeveniments correlacionats, el departament funcional rep només vistes de servei agregades. Afegiu audit-logs per l’accés als logs/traces quan hi hagi requisits regulatoris rellevants.

Datenhygiene im Logging: Struktur, Redaction, Retention

«Registrem-ho tot» no és un pla. Són recomanables logs estructurats (lectura per màquina), camps definits (p. ex. servei, entorn, ID de correlació, classe d’error) i un mascarament sistemàtic. Establiu la retenció segons l’objectiu: curta per a debug (p. ex. 7–14 dies), més llarga per a esdeveniments de seguretat o requisits d’auditoria — però separada, perquè costos i drets d’accés siguin gestionables.

Tracing gezielt, nicht flächig: Sampling und kritische Pfade

El Distributed Tracing és especialment valuós en trams d’integració i problemes de rendiment. El tracing al 100% a tota la superfície rarament és assumible i sovint no és necessari. Establiu regles de sampling (p. ex. més traces en cas d’errors o de latències inusuals) i focalitzeu-vos en el camí crític: Login/SSO, Upload, desar encàrrec, crida a la interfície, processament de la cua.

Konkrete Beispiele: SLOs für typische Unternehmenssoftware-Szenarien

Perquè els SLOs no restin teòrics, aquí tres exemples que apareixen sovint en solucions de programari pròximes al procés. Les xifres són deliberadament marcadors de posició – els valors objectiu han d’adaptar-se a l’ús, el perfil de càrrega i el risc del procés.

Beispiel A: Kundenportal „Auftrag anlegen“

• SLI Erfolgsrate: percentatge d’operacions de creació d’encàrrec finalitzades amb èxit (èxit de negoci) per període de 30 dies.
• SLI Latenz: p95 del temps end-to-end per a la creació d’encàrrecs (incl. DB-Commit i resposta de confirmació).
• Diagnose-Signale: DB-Deadlocks/Timeouts, longituds de la cua per al processament posterior, classes d’error en el log d’aplicació (validació vs. infraestructura).

Important: El SLO hauria de mesurar el flux d’usuari, no només „HTTP 200“. Altrament, es poden passar per alt casos en què una petició va ser tècnicament correcta però es va cancel·lar des del punt de vista funcional.

Exemple B: Interfície amb un proveïdor d’enviament (REST/EDI)

• SLI: Percentatge dels registres d’enviament que són confirmats amb èxit dins de X minuts (incl. reintents).
• Dependències: endpoint extern, ruta de xarxa, certificats, límits de taxa.
• Diagnosi: codis d’error per categories, taxa de reintents, Dead-Letter-Queue (emmagatzematge per a missatges que després de diversos intents no es van poder processar).

Aquí es veu el valor afegit dels SLO per a l’operació: podeu separar clarament si un incident afecta el vostre propi processament (p. ex. certificat caducat) o principalment el soci (p. ex. errors 5xx). Això redueix el temps de War-Room i millora la comunicació amb l’àrea funcional i els socis.

Exemple C: Execució nocturna «Facturació/Processament per lots»

• SLI: Percentatge dels batch-jobs que finalitzen amb èxit abans de l’hora límit definida.
• SLI: Nombre d’intervencions manuals per execució (operacions que desencadenen Runbooks).
• Diagnosi: patrons de lock/deadlock a la base de dades, colls d’ampolla de recursos, temps d’espera d’E/S, valors atípics en subjobs.