Observabilitat i alertes que avisen del que importa
Assabentar-vos d'una caiguda abans que els vostres clients, saber per què ha passat i deixar de rebre alertes que ningú no llig.
Eines habituals
- ClickHouse
- Elasticsearch
- Grafana
- Prometheus
- Graylog
- Kafka
- Matomo
- RabbitMQ
En resum
L'observabilitat és la capacitat de saber què passa dins de la vostra plataforma a partir de les seues mètriques, els seus logs i les seues traces. Muntem Prometheus per a les mètriques, Loki i Alloy per als logs, OpenTelemetry per a les traces i Grafana per als panells, amb alertes de llindars pactats que avisen del que afecta el servei i no de tot.
- Idiomes
- Castellà, català o anglés
- Resposta
- El següent dia feiner, en horari laboral
- Mètode
- Al vostre compte i al vostre repositori, en codi i documentat
Què inclou
- Mètriques d'infraestructura i d'aplicació amb Prometheus.
- Logs centralitzats amb Loki i Grafana Alloy, amb retenció acordada.
- Traces amb OpenTelemetry als serveis que més ho necessiten.
- Panells a Grafana per servei, amb els senyals clau a dalt.
- Alertes amb Alertmanager, llindars pactats i un canal clar.
- Objectius de disponibilitat (SLO) per als serveis crítics.
- Guia breu de què fer amb cada alerta.
- Tot desplegat amb codi, al vostre repositori.
Quan cal revisar l’observabilitat?
Gairebé sempre que algú diu «tenim monitoratge» però les caigudes les continua avisant un client. Els senyals habituals:
- Les caigudes es descobreixen per un correu d’un client o per les xarxes socials.
- Hi ha un canal d’alertes amb centenars de missatges que ningú no llig.
- Per a trobar un error cal entrar per SSH a cada servidor i buscar als logs.
- Ningú no sap dir quina disponibilitat va tindre el servei el mes passat.
- Els panells de Grafana existeixen, però els va fer algú que ja no hi és.
Quin senyal serveix per a què?
Mètriques, logs i traces no són tres maneres de veure el mateix: cadascuna respon una pregunta diferent. Així les repartim:
| Senyal | Pregunta que respon | Eina | Exemple |
|---|---|---|---|
| Mètriques | El servei està bé ara i com evoluciona? | Prometheus | Latència del percentil 95 o errors per minut |
| Logs | Què ha passat exactament en aquest moment? | Loki amb Alloy | L’error i la petició que el va provocar |
| Traces | En quina part de la cadena es perd el temps? | OpenTelemetry | Una petició que tarda a la base de dades |
| Alertes | Ha d’actuar algú ja? | Alertmanager | Errors per damunt del llindar durant 5 minuts |
| SLO | Estem complint el que vam prometre? | Prometheus i Grafana | 99,9 % de peticions correctes en 30 dies |
El mateix val fora de la web: en plataformes IoT, com ThingsBoard o una plataforma IoT amb MQTT, vigilem també la ingesta de dades, les cues de missatges i els dispositius connectats. I si voleu mesurar les visites de la vostra web sense cedir les dades a tercers, muntem Matomo al vostre servidor.
Com dissenyem les alertes?
Una alerta que no porta a una acció és soroll, i el soroll fa que s’ignoren les importants. Seguim tres regles:
- Per símptoma, no per causa: primer el que nota l’usuari (errors, latència, caiguda), després les causes (CPU, disc) com a avisos.
- Amb llindar pactat: el llindar i la finestra es decideixen amb vosaltres, segons el que el vostre servei tolera.
- Amb instruccions: cada alerta enllaça a una guia de què mirar i què fer.
El resultat es mesura: menys alertes, més ràpides d’atendre i cap caiguda que descobrisca abans un client.
Com s’implanta?
Revisió
Què es vigila avui, què es perd i quines alertes s’ignoren.
Mètriques i logs
Prometheus, Loki i Alloy desplegats amb codi, amb retenció i emmagatzematge acordats.
Panells i SLO
Un panell per servei i objectius de disponibilitat per als crítics.
Alertes
Llindars pactats, canal d’avís i guia per a cadascuna.
Quina experiència tenim?
L’observabilitat ha format part de tota la nostra trajectòria. Com a DevOps en un SaaS B2B hem millorat l’observabilitat i la recuperació davant de desastres de la plataforma; des de la direcció tècnica, el 99,9 % de disponibilitat se sostenia amb alertes que avisaven abans que els clients. Treballem cada dia amb Prometheus, Grafana, Loki, Alloy i Alertmanager. Si voleu que algú atenga aquestes alertes cada mes, encaixa amb l’SRE com a servei.
Preguntes freqüents
Per què no fer servir un servei comercial de monitoratge?
Pot ser una bona opció i us ho direm si encaixa. Prometheus, Loki i Grafana solen compensar quan el volum de dades fa car el servei comercial o quan les dades no poden eixir de la vostra infraestructura.
Quantes alertes hauria de tindre?
Poques i accionables. Cada alerta que desperta algú ha de tindre una acció clara; la resta va a un panell o a un resum diari. Comencem per les que afecten els vostres usuaris i n'afegim a partir d'aquí.
Qui atén les alertes?
El vostre equip, amb la guia que deixem, o nosaltres dins de l'SRE com a servei. Les alertes salten a qualsevol hora; la resposta és el següent dia feiner, en horari laboral.
Expliqueu-nos el vostre cas
En una trucada gratuïta de 20 minuts veiem on sou i per on començar. Sense compromís.
Revisat el