Plataforma d'observabilitat

7 preguntas de exámenes anteriores · 18 min · 2 hermanas, de otra categoría

Alcance decidido por nosotros: el enunciado oficial no acota la materia

Enunciat oficial. Plataforma d'Observabilitat: Components, característiques i reptes d'implantació.

1. Concepte

Observabilitat: capacitat de deduir l'estat intern d'un sistema a partir de les seves sortides externes. El terme prové de la teoria de control: un sistema és observable si es pot determinar el seu estat intern observant-ne les sortides.

Observabilitat ≠ monitoratge, i és la distinció que més cau:

L'observabilitat inclou el monitoratge: no el substitueix. Un sistema observable permet seguir fent monitoratge, però també investigar sense haver de desplegar codi nou per obtenir informació.

2. Els tres pilars

L'observabilitat es construeix sobre tres tipus de telemetria —els tres pilars— que responen a preguntes diferents i no se substitueixen entre si: amb només un dels tres, hi ha vigilància, no diagnòstic.

Cada pilar té un cost i una precisió diferents: les mètriques són barates i agregades, els registres són cars i literals, i les traces són les úniques que reconstrueixen el camí d'una petició concreta. Sovint s'hi afegeixen dos senyals més: els perfils (profiling) —consum de CPU (Central Processing Unit) i memòria per funció, que OpenTelemetry està normalitzant com a quart senyal— i els esdeveniments de negoci.

El que fa útil la plataforma no són els tres pilars per separat, sinó la seva correlació: poder saltar d'un pic d'una mètrica a les traces d'aquell moment i, d'allà, als registres del span concret. Sense correlació hi ha tres eines, no una plataforma d'observabilitat.

3. Components d'una plataforma d'observabilitat

Una plataforma d'observabilitat és una cadena: la telemetria es genera al codi, viatja fins a un magatzem i acaba en una pantalla o en una alerta. Cada baula té productes propis, i el disseny consisteix a triar-los de manera que el pas següent segueixi podent correlacionar.

1. Instrumentació: codi i agents que generen la telemetria. Pot ser manual (biblioteques al codi), automàtica (agents que injecten instrumentació sense tocar el codi) o eBPF (extended Berkeley Packet Filter, a nivell de nucli, sense agent ni canvis al codi). S'hi afegeixen el monitoratge d'usuari real —telemetria del navegador de qui fa servir el servei— i el monitoratge sintètic, que simula transaccions des de fora per detectar caigudes abans que hi hagi cap usuari.
2. Recol·lecció i transport: agents i col·lectors (OpenTelemetry Collector, Fluent Bit, Vector, Logstash, Beats), amb buffering i reintent. La recollida pot ser per extracció (pull: el sistema va a buscar les dades, com fa Prometheus) o per empenta (push: l'aplicació les envia).
3. Processament: enriquiment amb metadades, normalització, mostreig (sampling), filtratge, agregació i correlació mitjançant identificadors comuns (trace id, span id).
4. Emmagatzematge: bases de dades de sèries temporals per a mètriques (Prometheus, VictoriaMetrics, InfluxDB, Mimir), índexs de text per a registres (Elasticsearch/OpenSearch, Loki), i magatzems de traces (Tempo, Jaeger).
5. Consulta i visualització: llenguatges de consulta —PromQL i LogQL (Prometheus i Loki), KQL (Kusto Query Language, Microsoft) i SPL (Search Processing Language, Splunk)— i quadres de comandament (Grafana, Kibana).
6. Alerta i resposta: motor de regles, deduplicació, agrupació, encaminament i guàrdies (Alertmanager, PagerDuty, Opsgenie), i integració amb la gestió d'incidents.
7. Capa d'anàlisi avançada: AIOps — detecció d'anomalies, correlació automàtica, agrupació d'alertes i anàlisi de causa arrel assistida.
8. Govern: retenció, control d'accés, anonimització i control de costos.

OpenTelemetry (OTel): projecte de la CNCF (Cloud Native Computing Foundation) que estandarditza la generació, recol·lecció i exportació de mètriques, registres i traces. És agnòstic de proveïdor: instrumentes un cop i pots canviar de rerefons. Ha absorbit OpenTracing i OpenCensus i és avui l'estàndard de facto. Adoptar OTel és la manera d'evitar el bloqueig de proveïdor en observabilitat.

3.1 SNMP, el protocol clàssic de gestió de xarxa

SNMP (Simple Network Management Protocol) és el protocol estàndard de gestió d'elements de xarxa —encaminadors, commutadors, tallafocs—, anterior a l'observabilitat moderna i encara vigent quan aquests dispositius no exposen telemetria d'OpenTelemetry. Intercanvia informació entre un gestor —el NMS (Network Management System), a la solució d'administració de xarxa— i un agent a cada dispositiu.

L'agent exposa les seves variables en una MIB (Management Information Base), una estructura jeràrquica on cada valor té un OID (Object Identifier) únic; la MIB-II en normalitza els objectes bàsics comuns a qualsevol dispositiu. Tres operacions bàsiques: GET (el gestor llegeix un valor), SET (el gestor el modifica) i TRAP (l'agent notifica un esdeveniment sense que li ho demanin — monitoratge passiu).

SNMPv1 i v2c autentiquen amb una community string que viatja en clar; SNMPv3 hi afegeix autenticació i xifratge, i és l'única versió recomanable en producció.

3.2 Alertes i correlació d'esdeveniments

Una regla d'alerta és una condició sobre una consulta mantinguda un temps mínim: no salta al primer pic, sinó quan la condició persisteix. Sobre això, la plataforma ha de reduir el soroll abans de despertar ningú:

• Deduplicació: la mateixa alerta emesa per vint rèpliques és una sola notificació.
• Agrupació: totes les alertes del mateix servei o del mateix clúster arriben juntes, no una per correu.
• Inhibició: una alerta de rang superior —el clúster sencer ha caigut— silencia les que en deriven.
• Silenciament: finestres de manteniment planificat en què no s'avisa.
• Encaminament i escalat: a quin equip, per quin canal i amb quina guàrdia (Alertmanager, PagerDuty, Opsgenie), amb obertura automàtica de l'incident.

La correlació d'esdeveniments és el pas que agrupa esdeveniments relacionats per topologia (quins components depenen de quins), per temps (què ha passat en la mateixa finestra) i per identificador (mateixa petició, mateix servei), i decideix quin d'ells és la causa i quins són conseqüència. És el que evita que una sola caiguda generi centenars d'alarmes; AIOps hi afegeix detecció d'anomalies sense llindar fix i suggeriment de causa arrel.

Sobre què s'alerta: sobre símptomes visibles per l'usuari —latència, errors— i sobre el ritme de consum (burn rate) del pressupost d'error, no sobre llindars de components («CPU > 80 %»), que salten sovint sense que ningú noti res.

Frontera. La pràctica de gestió d'esdeveniments d'ITIL (Information Technology Infrastructure Library) —què és un esdeveniment, els tipus informatiu, advertència i excepció, i els eixos actiu/passiu i reactiu/proactiu— es desenvolupa al tema 18. Aquí hi ha la plataforma tècnica que els genera i els correlaciona.

4. Característiques d'una plataforma d'observabilitat

Aquestes són les propietats que ha de tenir una plataforma perquè sigui d'observabilitat i no un conjunt d'eines de monitoratge. Les tres primeres són les que marquen la diferència; la resta són exigències d'explotació que decideixen si la plataforma és sostenible.

1. Unificació dels tres pilars en un sol producte: mètriques, registres i traces al mateix lloc, amb el mateix model d'accés i el mateix vocabulari d'etiquetes.
2. Correlació per identificadors comuns: trace id i span id a les traces, exemplars que enllacen una mètrica amb una traça concreta, i camps estructurats als registres. És el que permet la navegació guiada —de la gràfica a la traça i d'aquesta al registre— sense canviar d'eina.
3. Alta cardinalitat i alta dimensionalitat: poder etiquetar la telemetria amb identificador d'usuari, de petició, de versió o de client i segmentar-hi després. La cardinalitat és el nombre de valors diferents que pot prendre una etiqueta; l'observabilitat en necessita molta i és justament el que dispara el cost. És la tensió central del disseny.
4. Consulta exploratòria ad hoc: es poden fer preguntes que no s'havien previst, sense definir una mètrica nova ni desplegar codi.
5. Temps real: ingesta i consulta amb latència de segons, perquè serveixi durant l'incident i no només per a l'anàlisi posterior.
6. Instrumentació estàndard i agnòstica de proveïdor: OpenTelemetry i convencions semàntiques comunes d'atributs.
7. Descobriment automàtic de serveis, de dependències i del mapa de serveis, generat a partir de les traces i no d'un inventari mantingut a mà.
8. Escalabilitat elàstica i multi-inquilí: una sola plataforma per a moltes àrees, amb aïllament de dades, de permisos i de quotes entre elles.
9. Retenció per capes i control del cost: dades detallades poc temps, agregades molt temps, i cost visible per equip.
10. Alertes basades en objectius de servei i integrades amb la gestió d'incidents, en lloc de llindars per component.
11. Govern de les dades: control d'accés per rol, anonimització del que pugui ser dada personal i traçabilitat de qui consulta què.

5. Arquitectura per a microserveis

En una arquitectura de microserveis, l'observabilitat escalable requereix:

• Traçat distribuït obligatori: sense traces, una petició que travessa vint serveis és impossible de diagnosticar. Cal propagació de context amb capçaleres W3C (World Wide Web Consortium) Trace Context: traceparent, tracestate.
• Instrumentació estandarditzada amb OpenTelemetry a tots els serveis, amb convencions semàntiques comunes d'atributs.
• Recol·lecció desacoblada: un col·lector com a intermediari (patró sidecar o daemonset), perquè les aplicacions no depenguin del rerefons.
• Mostreig intel·ligent: mostreig de cap (head-based) decideix a l'inici de la traça; mostreig de cua (tail-based) decideix un cop completa, i permet conservar totes les traces amb error o lentes i descartar les normals. El de cua és el que dona escalabilitat sense perdre els casos interessants.
• Emmagatzematge escalable i per capes, amb retencions diferents per pilar, i mapa de serveis derivat de les traces.
• Malla de serveis (service mesh) —Istio, Linkerd—: una capa que envolta cada servei i li aporta telemetria uniforme de totes les crides sense tocar-ne el codi. És l'arquitectura que fa escalable l'observabilitat en microserveis, perquè no depèn que cada equip instrumenti bé el seu servei. Es desenvolupa al tema 47.

6. Eines de visualització

Grafana és l'eina de referència per visualitzar mètriques, registres i traces en temps real en entorns d'observabilitat: és de codi obert, agnòstica de font de dades i s'integra amb Prometheus, Loki, Tempo, Elasticsearch, InfluxDB i desenes més. Alternatives: Kibana (per a l'Elastic Stack), Chronograf i les consoles pròpies dels productes comercials.

Un quadre de comandament tècnic útil no és una paret de gràfiques: porta les senyals daurades de cada servei, un panell d'estat dels objectius de servei amb el pressupost d'error consumit, el mapa de serveis, i enllaços de baixada que porten de la gràfica a la traça i d'aquesta al registre. Les variables de quadre —entorn, servei, versió— eviten haver de mantenir un panell per equip.

Piles habituals:

Plataforma d'observabilitat o eina de monitoratge? Són plataformes d'observabilitat en sentit ple Dynatrace, Datadog, New Relic, Instana (IBM), Splunk Observability, Elastic Observability i Grafana Cloud. Són eines de monitoratge clàssic —comproven disponibilitat i llindars de components, sovint per SNMP o amb agent, i no correlacionen els tres pilars— Nagios, Icinga, Zabbix, Checkmk, Centreon, PRTG (Paessler Router Traffic Grapher), Cacti, LibreNMS i SolarWinds. I no són ni una cosa ni l'altra Ansible o Jenkins, que són d'automatització i integració contínua.

El criteri no és la marca sinó la capacitat: diversos fabricants de monitoratge clàssic venen avui línies pròpies d'«observabilitat», i el que decideix és si el producte correlaciona els tres pilars o només vigila llindars.

Substituir una plataforma de monitorització comercial per codi obert al núvol. Quan el contracte d'administració i manteniment de la plataforma actual de monitorització està proper a finalitzar i es considera que els seus costos econòmics no compensen el rendiment que proporciona, l'opció que cal plantejar als caps és establir una solució similar de monitorització al núvol, on els costos són inferiors i l'administració és més àgil. La solució de codi obert que pot cobrir aquesta necessitat és la pila Prometheus + Grafana: Prometheus per a la recol·lecció i l'emmagatzematge de mètriques, i Grafana com a plataforma de visualització que crea panells combinant les mètriques recollides a diverses fonts en un sol quadre de comandament. Aquesta és la formulació literal que ha caigut, i la resposta són aquestes dues eines.

7. Beneficis

• Reducció del MTTR (Mean Time To Repair, temps mitjà de reparació): es passa d'hores de correlació manual a minuts de navegació guiada. És el benefici directe —diagnosticar més de pressa—, i no s'ha de confondre amb la reducció de costos o la millora de la seguretat, que com a molt en són conseqüències indirectes.
• Diagnòstic de problemes no previstos (unknown unknowns), impossibles de detectar amb llindars predefinits.
• Visibilitat extrem a extrem de la transacció, incloent-hi dependències de tercers.
• Detecció proactiva: anomalies i degradacions abans que l'usuari les percebi.
• Base objectiva per a la gestió de problemes, la capacitat i les decisions d'arquitectura. Les mateixes mesures tècniques alimenten els KPI de servei i la millora contínua → tema 22, i el dimensionament de recursos → tema 21.
• Suport als objectius de servei i al pressupost d'error: l'observabilitat és el que fa mesurable la fiabilitat.
• Alineació entre desenvolupament i operació: la mateixa telemetria serveix a tots dos.

8. Reptes d'implantació

1. Volum i cost: la telemetria creix més de pressa que el negoci. Cal mostreig, retencions per capes, agregació i control actiu de la cardinalitat. El cost de l'observabilitat pot superar el de la infraestructura observada si no es governa.
2. Instrumentació del programari heretat: aplicacions antigues sense instrumentació ni codi disponible; solucions parcials amb agents, eBPF o intermediaris.
3. Heterogeneïtat: entorns híbrids amb mainframe, màquines virtuals, contenidors i SaaS, cadascun amb els seus formats.
4. Estandardització: sense convencions comunes de noms, etiquetes i identificadors, la correlació no funciona. És més un problema de govern que tècnic.
5. Fatiga d'alertes: alertes no accionables, duplicades o sense propietari fan que s'ignorin. Cal alertar sobre símptomes visibles per l'usuari i basar-se en objectius de servei, no en llindars de components.
6. Cultura i competències: l'observabilitat exigeix que els equips de desenvolupament instrumentin el seu codi i mirin les dades. Sense això, la plataforma queda com una eina d'operacions.
7. Privadesa i seguretat: els registres i les traces poden contenir dades personals; cal minimització, emmascarament i control d'accés conforme al RGPD, art. 5 i a l'ENS, amb polítiques de retenció alineades.
8. Bloqueig de proveïdor: la instrumentació propietària dificulta el canvi. La mitigació és OpenTelemetry.
9. Governança del cicle de vida: qui crea els quadres de comandament, qui els manté, qui esborra els obsolets.
10. Impacte de la instrumentació: agents i mostreig consumeixen CPU, memòria i xarxa del sistema observat; una plataforma mal dimensionada degrada allò que havia de vigilar.

9. Observabilitat i SRE

L'enginyeria de fiabilitat del servei —SRE (Site Reliability Engineering), formulada per Google— gestiona la fiabilitat amb mètodes d'enginyeria en comptes de per criteri. Fixa objectius mesurables sobre el servei i decideix amb dades quan cal deixar de desplegar canvis i posar-se a estabilitzar. És el vocabulari que millor connecta l'observabilitat amb la gestió de serveis, perquè és el que converteix la telemetria en un criteri de decisió.

• SLI (Service Level Indicator): la mesura concreta —per exemple, el percentatge de peticions ateses en menys de 300 ms.
• SLO (Service Level Objective): l'objectiu intern sobre l'SLI —99,9 % mensual.
• SLA (Service Level Agreement): el compromís extern amb el client, l'únic dels tres que porta penalització.
• Pressupost d'error (error budget): el marge d'incompliment permès (100 % − SLO). Mentre queda pressupost, es pot innovar i desplegar; quan s'esgota, es congela el canvi i es prioritza la fiabilitat.
• Les quatre senyals daurades (golden signals): latència, trànsit, errors i saturació. Són el mínim que s'ha de mesurar de qualsevol servei.
• Mètode RED (Rate, Errors, Duration) per a serveis i mètode USE (Utilization, Saturation, Errors) per a recursos.

SLI ≠ SLO ≠ SLA: l'SLI és la mesura, l'SLO l'objectiu intern i l'SLA el compromís extern. L'SLO s'ha de fixar sempre més exigent que l'SLA, perquè és el marge que avisa abans d'incomplir el contracte.

SRE ≠ DevOps: DevOps enuncia què cal aconseguir —unir desenvolupament i operació—; SRE és una manera concreta i mesurable de fer-ho, amb l'SLO i el pressupost d'error com a mecanisme d'arbitratge entre canviar i estabilitzar.

Claus d'examen

• «Elements de xarxa no monitoritzats, cal un protocol d'intercanvi amb els dispositius» és sempre SNMP, no SSH (Secure Shell: accés remot xifrat, no gestió de xarxa) ni SMTP (Simple Mail Transfer Protocol: correu) (TS-TIC 2023 pràctica, p. 5).
• La parella Prometheus + Grafana cau junta i en aquest ordre: «solució de monitorització al núvol i de codi obert» → Prometheus; «plataforma de visualització amb panells de diverses fonts» i «visualitzar mètriques, logs i traces en temps real» → Grafana. Les distractores no són del ram (JHipster, Angular, MinIO, Velero, Squid) o són eines d'informes de negoci (Power BI (Business Intelligence), Tableau, Excel) (TS-TIC 2023 pràctica, p. 6 i p. 30; TS-TIC 2025 pràctica, p. 14).
• «Quin producte és una plataforma d'observabilitat?» → Instana, d'IBM, davant d'un client de xarxa privada virtual (GlobalProtect), una eina de bases de dades (SqlDeveloper) i un magatzem d'objectes (MinIO): la tècnica és descartar els que fan una altra cosa (TS-TIC 2023 específic, p. 72).
• «Quina arquitectura facilita una observabilitat escalable en microserveis?» → arquitectura en malla de serveis (service mesh). Les altres tres opcions —monolítica, client-servidor i d'igual a igual— descriuen com es reparteix l'aplicació, no com se n'obté la telemetria (TS-TIC 2025 específic, p. 28).
• El benefici que es demana és el diagnòstic, no l'estalvi: «facilitat per diagnosticar errors i temps de resposta més ràpids» guanya a «augment de la productivitat», «millora de la seguretat» i «reducció de costos», que són conseqüències indirectes (TS-TIC 2025 pràctica, p. 13).
• Monitoratge vs. observabilitat: si l'opció diu «comprovar condicions conegudes amb llindars», és monitoratge; si diu «explorar preguntes no previstes», és observabilitat. I Nagios, Zabbix, Centreon, PRTG, Cacti o SolarWinds són eines de monitoratge, no plataformes d'observabilitat: la distinció és la correlació entre els tres pilars.

Per recordar

• Monitoratge = «funciona?» amb condicions conegudes; observabilitat = «per què?» amb exploració de l'inesperat. L'observabilitat inclou el monitoratge.
• Tres pilars: mètriques, registres i traces — i el valor és la correlació entre ells.
• Les tres característiques que fan plataforma: pilars unificats, correlació per identificadors comuns i alta cardinalitat. La resta —temps real, escalabilitat, retenció per capes, govern— decideixen si és sostenible.
• Components, en cadena: instrumentació → recol·lecció → processament → emmagatzematge → consulta i visualització → alerta i resposta.
• OpenTelemetry és l'estàndard obert de generació i exportació de telemetria; evita el bloqueig de proveïdor.
• En microserveis: traçat distribuït amb propagació de context (W3C Trace Context), mostreig de cua i malla de serveis, que és la resposta oficial a «quina arquitectura facilita l'observabilitat escalable».
• Grafana visualitza i Prometheus recull i guarda. Nagios, Zabbix, Centreon, PRTG i SolarWinds són monitoratge; Instana, Dynatrace, Datadog i New Relic són plataformes d'observabilitat.
• Reptes: cost i cardinalitat, heretat sense instrumentar, estandardització, fatiga d'alertes, cultura i dades personals als logs.
• Senyals daurades: latència, trànsit, errors i saturació. RED per a serveis, USE per a recursos.
• SLI = la mesura, SLO = l'objectiu intern, SLA = el compromís extern amb penalització. L'SLO és més exigent que l'SLA.
• SNMP: gestor, agent i MIB; v3 afegeix autenticació i xifratge; TRAP és la notificació no sol·licitada de l'agent; GET/SET consulten i modifiquen.
• Migrar de contracte comercial a codi obert al núvol → Prometheus + Grafana.

Practicar este tema