Saber què monitoritzar és tan important com disposar d’un bon sistema de monitoratge. Una infraestructura sobrecarregada d’indicadors irrellevants pot generar soroll i fatiga d’alertes; una amb massa poca visibilitat pot passar per alt incidències crítiques fins que ja és massa tard.

Per garantir el bon funcionament dels sistemes TI, cal identificar els indicadors clau de rendiment i disponibilitat (KPI i KRI) que tenen realment impacte sobre l’estabilitat del servei, la satisfacció de l’usuari final i el compliment dels SLA.

A continuació repassem els principals paràmetres que caldria tenir sota control en qualsevol plataforma de monitorització ben dissenyada.

1. Disponibilitat i estat dels serveis (Service Uptime)

Què indica?

Si un servei (web, base de dades, aplicació interna, API, etc.) està funcionant correctament o no.

Per què és clau?

És el nucli del monitoratge. Tots els altres indicadors han de contextualitzar-se en funció de l’impacte real sobre el servei. Un CPU al 100% pot ser inofensiu si no afecta el servei. Però un servei caigut, encara que tot sembli “verd”, és un problema real.

Com es mesura?

Amb checks actius i passius des de diferents punts de vista: ping, connexió de port, transaccions completes, mètriques de resposta, etc.

2. Temps de resposta (Response Time / Latència)

Què indica?

La rapidesa amb què un servei respon a una petició.

Per què és clau?

Una aplicació pot estar "activa", però si tarda més de 2-3 segons en respondre, és probable que l'usuari ho consideri una mala experiència o fins i tot una interrupció.

Com es monitoritza?

Amb proves sintètiques i plugins específics per serveis web, APIs REST, DNS, LDAP, etc. També és habitual incloure proves multi-passos (login + consulta + resposta).

3. Ús de recursos: CPU, RAM, disc i xarxa

CPU & RAM

  • Alta ocupació constant pot indicar processos ineficients, problemes d’escalabilitat o atac per denegació de servei.
  • És rellevant més per tendència que per pics puntuals.

Disc

  • Capacitat lliure: no només evitar que el sistema falli, sinó prevenir pèrdua de dades o bloqueig de serveis.
  • Temps d’accés a disc (IOPS, latència): afecta directament el rendiment de serveis intensius com bases de dades.

Xarxa

  • Ample de banda consumit, paquets descartats, latències entre nodes o switches.
  • Ideal per a detectar saturació, errors de configuració o anomalies.

4. Estat de processos i serveis interns

Què indica?

Si els processos crítics del sistema estan actius i operatius (per exemple, mysqld, nginx, tomcat, docker, systemd targets, etc.).

Per què és clau?

Alguns serveis poden fallar sense que el sistema operatiu en general presenti errors. Supervisar els processos clau és essencial per mantenir la integritat funcional.

Com es monitoritza?

Amb agents com Zabbix Agent, SNMP, NRPE o scripts personalitzats. També es pot fer via systemd o supervisió de logs.

5. Logs i esdeveniments

Què indica?

Incidències, errors i alertes que no apareixen a les mètriques convencionals.

Per què és clau?

Els logs aporten el context qualitatiu de l’estat del sistema. Poden revelar errors de codi, intents de connexió fallits, problemes d’autenticació o senyals de ciberatacs.

Eines associades

Monitorització de logs via Elastic Stack (ELK), Graylog, Syslog-ng, etc., integrats amb alertes personalitzades.

6. Estats de backup i rèpliques

Què indica?

Si les còpies de seguretat s’han realitzat correctament, si s’han validat, i si les rèpliques (per exemple, de BBDD) estan sincronitzades.

Per què és clau?

La restauració d’un sistema caigut depèn del backup. I no tenir-ne visibilitat pot provocar pèrdues greus.

Com monitoritzar-ho?

Amb scripts de validació de backups, plugins per BBDD com PostgreSQL, MySQL o MongoDB, i estats de sincronització (per exemple, en entorns HA).

7. Estat de l’entorn (hardware, energia, temperatura)

Què indica?

Condicions físiques que poden afectar els sistemes: temperatura elevada, ventiladors defectuosos, fonts d’alimentació en fallada, etc.

Per què és clau?

Especialment important en entorns on premien l’estabilitat i el temps de resposta. Una fallada de hardware pot ser més destructiva que un error lògic.

Eines habituals

SNMP, IPMI, sensors de fabricants, integrats dins el sistema de monitoratge principal.

I sobretot… el context

Un bon sistema de monitoratge no només mostra mètriques: les contextualitza i prioritza segons el servei, els usuaris afectats i la criticitat. Per això, a Solucions‑IM dissenyem solucions a mida que no només recullen dades, sinó que ajuden a prendre decisions informades.

Des d’una supervisió bàsica fins a entorns distribuïts amb milers de serveis i nodes, l’objectiu no és només veure què falla, sinó anticipar què pot fallar.

Monitoritzar tot no és una estratègia. Monitoritzar bé sí. Identificar quins indicadors són rellevants per a la teva infraestructura i com monitoritzar-los de manera eficient és el primer pas cap a una TI fiable, predictiva i preparada per créixer.

A Solucions‑IM t’ajudem a fer aquesta selecció amb criteri, basant-nos en l'experiència, l'escalabilitat i les necessitats concretes de cada entorn.