Observabilitat a EventHub
Navegació
| ⬅️ Plataforma Eventhub | ➡️ Responsabilitats |
|---|
Quan he d’utilitzar aquesta secció?
Consulta aquesta secció en dos moments clau:
| Moment | Quan | Per què |
|---|---|---|
| Abans del primer desplegament a PRO | Previ a qualsevol CRQ de producció | Garantir monitorització des del primer moment d’estar en PRO |
| Davant d’un canvi significatiu | Abans de desplegar una nova integració o modificació rellevant | Assegurar visibilitat del nou comportament des del primer instant |
| Durant l’operació | Quan cal monitoritzar, detectar o analitzar comportaments anòmals | Disposar de visibilitat end-to-end abans de declarar una incidència |
⚠️ La configuració de l’observabilitat és un prerequisit del desplegament a PRO, no una tasca posterior. Ha d’estar completada i validada abans d’executar la CRQ de producció. Consulteu el punt 8 de la Checklist de validació prèvia al desplegament.
Observabilitat a EventHub
Canigó – Guia operativa
Configuració mínima abans de passar a PRO
Abans de desplegar qualsevol cas d’ús nou a producció, cal verificar que els elements d’observabilitat bàsics estan en lloc:
| Element | Responsable | Verificació |
|---|---|---|
| Accés a Talaia (Grafana) configurat | Equip d’aplicació (via responsable CTTI o Gesines) | Accés actiu amb usuari GICAR |
| Accés a Kibana configurat | Equip d’aplicació (via responsable CTTI o Gesines) | Accés actiu amb usuari GICAR |
| Consumer lag identificat i amb SLA definit | Equip d’aplicació | SLA documentat a la fitxa |
| Alertes bàsiques de connector configurades (si aplica) | Oficina EventHub | Connector en estat RUNNING |
| Procediment d’incidència conegut per l’equip | Equip d’aplicació | Fluxos d’escalat documentats |
Fins que aquests elements no estiguin validats, el desplegament a PRO no es considera complet.
Validació d’observabilitat dins de la CRQ
Quan una aplicació externa desplega un canvi a PRO que afecta fluxos d’EventHub, la CRQ corresponent ha d’incloure una tasca de validació tècnica assignada a l’Oficina EventHub (segons el model de CRQ a EventHub).
Aquesta tasca de validació tècnica ha d’incloure obligatòriament la verificació d’observabilitat:
| Element a verificar | Criteri d’acceptació |
|---|---|
| Mètriques del flux a Talaia (Grafana) | Mètriques visibles i dins dels llindars esperats |
| Logs a Kibana | Sense errors d’escriptura/lectura post-desplegament |
| Consumer lag | Estable o decreixent, sense desviacions sobre l’SLA definit |
| Estat dels connectors implicats | RUNNING (cap en FAILED o PAUSED no previst) |
| Alertes configurades | Actives i no en estat alert |
⚠️ Si la verificació d’observabilitat detecta anomalies post-desplegament que afecten múltiples aplicacions, s’escala com a incidència transversal amb notificació obligatòria al Centre de Control.
Eines de monitorització
| Eina | Ús principal |
|---|---|
| Talaia (Grafana) | Dashboards de mètriques: estat del clúster, sistema operatiu, JVM, indicadors avançats |
| Kibana | Logs d’EventHub, errors de connectors, traces d’aplicacions |
| Control Center | Estat de brokers, connectors, consumer groups, topics (accés restringit a l’Oficina EventHub) |
Com obtenir accés a les eines de monitorització
L’accés a Talaia (Grafana) i Kibana es gestiona a través del responsable del CTTI del projecte o via Gesines:
- Contacta amb el teu responsable de CTTI o obre una petició a Gesines indicant:
- L’eina a la que necessites accés (Talaia i/o Kibana).
- El context del projecte i la necessitat de monitorització.
- L’equip de monitorització crearà o assignarà el rol GICAR corresponent.
- Un cop assignat el rol, l’accés s’activa amb el teu usuari GICAR corporatiu.
Si ja tens un rol de monitorització assignat d’un projecte anterior, pot ser directament aplicable — consulta amb el teu responsable de CTTI.
El Control Center de Confluent és una eina d’operació de plataforma gestionada exclusivament per l’Oficina EventHub. Els equips d’aplicació no hi tenen accés directe.
Què monitoritza l’Oficina EventHub
L’Oficina realitza un check diari que inclou:
Estat del clúster
- Verificació que tots els indicadors estan en verd a Talaia.
- Revisió de les sondes de disponibilitat.
Estat dels brokers
- Ocupació de disc per broker:
| Nivell | Ocupació | Acció |
|---|---|---|
| 🟢 Normal | < 600 GB | Operació normal |
| 🟡 Precaució | 600 - 900 GB | Identificar topics pesants, revisar retencions |
| 🔴 Crític | > 900 GB | Acció urgent: reduir retencions, identificar massius |
| ⛔ Emergència | > 1.2 TB | Reducció immediata de retencions a 1 dia en topics no crítics |
Estat dels connectors
- Verificació que cap connector estigui en estat FAILED.
- Revisió dels consumer groups de connectors (prefix
connect-): tots han d’estar en STABLE.
Mètriques JVM
- Ús de memòria per broker.
- Activitat del Garbage Collector: si l’Old Generation està actiu pot indicar problemes de memòria.
Sistema operatiu
- CPU, memòria, swap, xarxa per a totes les màquines del clúster.
Què ha de monitoritzar l’aplicació
Com a equip d’aplicació, heu de monitoritzar:
| Mètrica | Què buscar | On mirar |
|---|---|---|
| Consumer lag | Si el lag creix, els consumidors no processen prou ràpid | Control Center → Consumers |
| Estat del connector | RUNNING / PAUSED / FAILED | Control Center → Connect |
| Errors de producció | Errors d’escriptura al topic | Logs de l’aplicació + Kibana |
| Errors de consum | Desserialització, timeout, rebalanceig | Logs de l’aplicació + Kibana |
| Throughput | MB/s d’entrada i sortida vs. previsió | Talaia → dashboards de topics |
Umbrals de referència per a aplicacions
| Mètrica | Valor de referència | Acció si se supera |
|---|---|---|
| Consumer lag | Depèn del cas d’ús (definir SLA) | Investigar si el consumidor processa correctament |
| Retenció del topic | Estàndard: 7 dies | Si necessites més, justificar a la fitxa |
| Mida del missatge | Estàndard: ≤ 1 MB | Si supera, utilitzar compressió Zstd |
| Mida màxima acceptable | 10 MB | Per sobre de 10 MB no s’accepta |
Què fer si detectes una anomalia
- Verificar si és un problema de la teva aplicació (logs, consumidors, productors).
- Consultar el model de responsabilitats per determinar qui ha d’actuar.
- Si és un problema de plataforma → obrir tiquet JIRA ACOEVENT.
- Si és una incidència crítica en PRO → seguir el procediment de CRQ d’urgència.
- Per a troubleshooting de connectors → consultar la guia de resolució.