Mi chiamo Anton Baderin. Lavoro al Centro Tecnologie Avanzate e mi occupo di amministrazione di sistema. Un mese fa si è conclusa la nostra conferenza aziendale, dove abbiamo condiviso esperienze con la comunità IT della nostra città. Ho parlato del monitoraggio delle applicazioni web. Il materiale era rivolto a un pubblico di livello junior o middle, che non ha strutturato questo processo da zero.
Il fondamento di qualsiasi sistema di monitoraggio è risolvere le esigenze del business. Monitorare solo per farlo non interessa a nessuno. E cosa desidera il business? Che tutto funzioni rapidamente e senza errori. Il business vuole proattività, che possiamo identificare i problemi nel servizio e risolverli nel minor tempo possibile. Queste, in sostanza, sono le sfide che ho affrontato nell'ultimo anno su un progetto di uno dei nostri clienti.
Informazioni sul progetto
Il progetto è uno dei più grandi programmi di fidelizzazione nel paese. Aiutiamo le catene di vendita al dettaglio a incrementare la frequenza delle vendite attraverso vari strumenti di marketing come le carte fedeltà. In totale, il progetto comprende 14 applicazioni che funzionano su dieci server.
Durante il processo di colloqui ho notato più volte che gli amministratori non sempre approcciano correttamente il monitoraggio delle applicazioni web: molti si fermano ancora alle metriche del sistema operativo e monitorano sporadicamente i servizi.
Nel mio caso, in precedenza il sistema di monitoraggio del cliente si basava su Icinga. Questo non risolveva i problemi menzionati sopra. Spesso il cliente ci segnalava i problemi e frequentemente ci mancavano i dati per risalire alla causa.
Inoltre, era chiaro che lo sviluppo futuro di questo sistema non era promettente. Penso che chi conosca Icinga capirà. Così, abbiamo deciso di riprogettare completamente il sistema di monitoraggio delle applicazioni web per il progetto.
Prometheus
Abbiamo scelto Prometheus sulla base di tre indicatori principali:
- Un'enorme quantità di metriche disponibili. Nel nostro caso sono 60.000. Ovviamente, va notato che la stragrande maggioranza di esse non viene utilizzata (probabilmente circa il 95%). D'altra parte, sono tutte relativamente economiche. Per noi è una situazione completamente diversa rispetto a Icinga, che utilizzavamo in precedenza. In essa l'aggiunta di metriche era particolarmente dolorosa: quelle esistenti costavano care (basta guardare il codice sorgente di qualsiasi plugin). Qualsiasi plugin era uno script in Bash o Python, il cui avvio non è economico in termini di risorse consumate.
- Questo sistema consuma una quantità relativamente ridotta di risorse. Per tutte le nostre metriche bastano 600 MB di RAM, il 15% di un core e una manciata di IOPS. Certo, occorre avviare gli esportatori di metriche, ma sono tutti scritti in Go e non sono neppure particolarmente affamati di risorse. Non credo che oggi sia un problema.
- Consente la transizione a Kubernetes. Considerando i piani del cliente, la scelta è ovvia.
ELK
In precedenza non raccogevamo né trattavamo i log. Gli svantaggi sono evidenti a tutti. Abbiamo scelto ELK, avendo già esperienza con questo sistema. Conserviamo solo i log delle applicazioni. I criteri principali per la scelta sono stati la ricerca full-text e la sua velocità.
Clickhouse
Inizialmente la nostra scelta era caduta su InfluxDB. Eravamo consapevoli della necessità di raccogliere i log di Nginx, le statistiche da pg_stat_statements e conservare i dati storici di Prometheus. Non ci piaceva Influx, poiché occasionalmente iniziava a consumare grandi quantità di memoria e crollava. Inoltre, volevamo raggruppare le richieste per remote_addr, ma il raggruppamento in questo DBMS è solo per tag. I tag sono costosi (dal punto di vista della memoria) e il loro numero è limitato.
Abbiamo iniziato a cercare di nuovo. Avevamo bisogno di una base analitica con un consumo minimo di risorse e, preferibilmente, con compressione dei dati sul disco.
Clickhouse soddisfa tutti questi criteri e non ci siamo mai pentiti della scelta. Non scriviamo volumi eccezionali di dati in esso (il numero di inserimenti è di circa cinquemila al minuto).
NewRelic
NewRelic è storicamente con noi, essendo stata la scelta del cliente. Lo usiamo come APM.
Zabbix
Utilizziamo Zabbix esclusivamente per il monitoraggio del Black Box di varie API.
Definizione dell'approccio al monitoraggio
Desideravamo decomporre il compito e sistematizzare così l'approccio al monitoraggio.
Per fare ciò, ho suddiviso il nostro sistema nei seguenti livelli:
- «hardware» e VMS;
- sistema operativo;
- servizi di sistema, stack software;
- applicazione;
- logica di business.
La comodità di questo approccio è che:
- sappiamo chi è responsabile del funzionamento di ciascun livello e, in base a questo, possiamo inviare gli alert;
- possiamo utilizzare la struttura per sopprimere gli alert: sarebbe strano inviare un alert sulla mancata disponibilità del database quando l'intera macchina virtuale non è disponibile.
Poiché il nostro compito è identificare le anomalie nel funzionamento del sistema, dobbiamo, a ogni livello, definire un insieme di metriche a cui prestare attenzione durante la scrittura delle regole di allerta. Procederemo ora a esaminare i livelli "VMS", "Sistema operativo" e "Servizi di sistema, stack software".
Macchine virtuali
Hosting ci assegna CPU, disco, memoria e rete. E con i primi due abbiamo avuto problemi. Quindi, le metriche sono:
CPU stolen time — quando si acquista una macchina virtuale su Amazon (ad esempio, t2.micro), è importante capire che non si ottiene un intero core di CPU, ma solo una quota del suo tempo. E quando si esaurisce, il processore inizia a essere sottratto.
Questa metrica consente di monitorare questi momenti e prendere decisioni. Per esempio, è necessario passare a un piano più ricco oppure distribuire l'elaborazione delle attività in background e delle richieste API su diversi livelli. server.
IOPS + CPU iowait time — per qualche motivo, molti provider di cloud hosting hanno il vizio di non fornire IOPS sufficienti. Inoltre, un grafico con bassi IOPS per loro non è un'argomentazione. Pertanto, è opportuno raccogliere anche i dati su CPU iowait. Con questa coppia di grafici — con bassi IOPS e alta latenza di input/output — possiamo già dialogare con il provider di hosting e risolvere il problema.
Il sistema operativo
Metriche del sistema operativo:
- percentuale di memoria disponibile;
- attività di utilizzo dello swap: vmstat swapin, swapout;
- numero di inode disponibili e spazio libero sul file system in %.
- carico medio;
- numero di connessioni in stato tw;
- percentuale di riempimento della tabella conntrack;
- La qualità del lavoro della rete può essere monitorata tramite l'utilità ss, includendo il pacchetto iproute2 — per ottenere dal suo output il valore RTT delle connessioni e raggrupparlo per porta di destinazione.
Inoltre, a livello di sistema operativo, abbiamo l'entità chiamata processi. È importante identificare nella sistema un insieme di processi che svolgono un ruolo cruciale nel funzionamento. Se, ad esempio, si dispone di più istanze di pgpool, è necessario raccogliere informazioni su ciascuna di esse.
L'insieme delle metriche è il seguente:
- CPU;
- memoria — principalmente, quella residente;
- IO — preferibilmente in IOPS;
- FileFd — aperti e limite;
- importanti errori di pagina — in questo modo è possibile comprendere quale processo sta utilizzando lo swap.
Tutta la nostra attività di monitoraggio è eseguita in Docker, utilizziamo Cadvisor per raccogliere i dati delle metriche. Negli altri server impieghiamo process-exporter.
Servizi di sistema, stack software
Ogni applicazione ha la sua specificità ed è difficile identificare un insieme di metriche universale.
Un insieme di metriche universali include:
- il tasso di richieste;
- numero di errori;
- latenza;
- saturazione.
I più evidenti esempi di monitoraggio a questo livello sono Nginx e PostgreSQL.
Il servizio più carico nel nostro sistema è il database. In passato avevamo spesso problemi nel capire cosa stesse facendo il database.
Notavamo un alto carico sui dischi, ma i log non fornivano informazioni utili. Abbiamo risolto questo problema usando pg_stat_statements, una vista che raccoglie statistiche sulle richieste.
Questo è tutto ciò che serve all'amministratore.
Costruiamo grafici sull'attività delle richieste di lettura e scrittura:
È tutto chiaro e diretto, ogni richiesta ha un colore distinto.
Un altro esempio significativo sono i log di Nginx. Non sorprende che pochi li analizzino o li menzionino come obbligatori. Il formato standard non è molto informativo e deve essere ampliato.
Ho personalmente aggiunto request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Costruiamo grafici sul tempo di risposta e sul numero di errori:
Costruiamo grafici sul tempo di risposta e sul numero di errori. Ricordate? Ho parlato delle necessità aziendali? Per agire rapidamente e senza errori? Questi due grafici risolvono già queste problematiche. E su di essi possiamo già contattare gli amministratori in turno.
Ma resta un'ulteriore sfida: garantire una rapida risoluzione delle cause dell'incidente.
Risoluzione degli incidenti
L'intero processo dall'identificazione alla risoluzione del problema può essere suddiviso in vari passaggi:
- identificazione del problema;
- notifica all'amministratore di turno;
- reazione all'incidente;
- risoluzione delle cause.
È fondamentale che facciamo il tutto nel minor tempo possibile. E se per le fasi di identificazione del problema e di invio della notifica non possiamo guadagnare tempo — ci vorranno comunque due minuti, le fasi successive rappresentano un campo fertile per miglioramenti.
Immaginiamo semplicemente che il telefono dell'amministratore di turno squilli. Cosa farà? Cercherà le risposte alle domande: cosa è andato storto, dove è andato storto, come reagire? Ecco come rispondiamo a queste domande:
Includiamo semplicemente tutte queste informazioni nel testo della notifica, fornendo un link alla pagina della wiki che spiega come reagire a questo problema, come risolverlo e come escalation.
Non ho ancora parlato del livello dell'applicazione e della logica aziendale. Sfortunatamente, nelle nostre applicazioni non è ancora implementata la raccolta di metriche. L'unica fonte di informazioni, ancorché limitata, da questi livelli sono i log.
Alcuni aspetti.
In primo luogo, scrivete log strutturati. Non includete il contesto nel testo del messaggio. Questo rende difficile la loro aggregazione e analisi. Logstash richiede molto tempo per normalizzare tutto ciò.
In secondo luogo, usate correttamente i livelli di severità. Ogni linguaggio ha il proprio standard. Personalmente, identifico quattro livelli:
- nessun errore;
- errore client;
- errore nostro, non perdiamo soldi, non ci sono rischi;
- errore nostro, perdiamo soldi.
In sintesi, bisogna cercare di costruire il monitoraggio a partire dalla logica di business. Dobbiamo monitorare l'applicazione stessa e operare con metriche come il numero di vendite, il numero di nuove registrazioni degli utenti, il numero di utenti attivi in quel momento e così via.
Se tutto il vostro business è un pulsante nel browser, è necessario monitorare se viene cliccato, se funziona correttamente. Tutto il resto non è importante.
Se non avete questo, potete cercare di recuperarlo nei log dell'applicazione, nei log di Nginx e così via, come abbiamo fatto noi. Dovete essere il più vicino possibile all'applicazione.
Le metriche del sistema operativo sono sicuramente importanti, ma non interessano al business, non siamo pagati per esse.
Fonte: habr.com
