Mi chiamo Anton Baderin. Lavoro al Centro di Alta Tecnologia e mi occupo di amministrazione di sistema. Un mese fa si è conclusa la nostra conferenza aziendale, dove abbiamo condiviso la nostra esperienza accumulata con la comunità IT della nostra città. Ho parlato del monitoraggio delle applicazioni web. Il materiale era destinato al livello junior o medio, che non ha costruito questo processo da zero.
La pietra angolare alla base di qualsiasi sistema di monitoraggio è la risoluzione dei problemi aziendali. Il monitoraggio fine a se stesso non interessa a nessuno. Cosa vogliono le imprese? In modo che tutto funzioni rapidamente e senza errori. Le aziende vogliono essere proattive, in modo che noi stessi identifichiamo i problemi nel servizio e li risolviamo il più rapidamente possibile. Questi, infatti, sono i problemi che ho risolto tutto lo scorso anno su un progetto per un nostro cliente.
Sul progetto
Il progetto è uno dei più grandi programmi fedeltà del paese. Aiutiamo le catene di vendita al dettaglio ad aumentare la frequenza delle vendite attraverso vari strumenti di marketing come le carte bonus. In totale, il progetto comprende 14 applicazioni che girano su dieci server.
Durante il processo di intervista, ho notato più volte che gli amministratori non sempre affrontano correttamente il monitoraggio delle applicazioni web: molti si concentrano ancora sulle metriche del sistema operativo e occasionalmente monitorano i servizi.
Nel mio caso il sistema di monitoraggio del cliente era precedentemente basato su Icinga. Non ha risolto in alcun modo i problemi di cui sopra. Spesso era il cliente stesso a informarci dei problemi e, il più delle volte, semplicemente non avevamo dati sufficienti per andare a fondo del motivo.
Inoltre, c'era una chiara comprensione dell'inutilità del suo ulteriore sviluppo. Penso che chi conosce Icinga mi capirà. Pertanto, abbiamo deciso di riprogettare completamente il sistema di monitoraggio delle applicazioni web per il progetto.
Prometeo
Abbiamo scelto Prometeo sulla base di tre indicatori principali:
- Un numero enorme di metriche disponibili. Nel nostro caso sono 60mila. Naturalmente, vale la pena notare che non ne utilizziamo la stragrande maggioranza (probabilmente circa il 95%). D'altra parte, sono tutti relativamente economici. Per noi questo è l'estremo opposto rispetto all'Icinga utilizzata in precedenza. In esso, aggiungere metriche era una seccatura particolare: quelle esistenti erano costose (basta guardare il codice sorgente di qualsiasi plugin). Qualsiasi plugin era uno script in Bash o Python, il cui lancio è costoso in termini di risorse consumate.
- Questo sistema consuma una quantità relativamente piccola di risorse. 600 MB di RAM, il 15% di un core e un paio di dozzine di IOPS sono sufficienti per tutti i nostri parametri. Naturalmente, devi eseguire esportatori di metriche, ma sono tutti scritti in Go e inoltre non sono molto assetati di energia. Non penso che nelle realtà moderne questo sia un problema.
- Fornisce la possibilità di migrare a Kubernetes. Considerando i piani del cliente, la scelta è ovvia.
ALCE
In precedenza, non raccoglievamo né elaboravamo i log. Le carenze sono evidenti a tutti. Abbiamo scelto ELK perché avevamo già esperienza con questo sistema. Qui archiviamo solo i registri delle applicazioni. I principali criteri di selezione erano la ricerca full-text e la sua velocità.
Сlickhouse
Inizialmente la scelta è caduta su InfluxDB. Ci siamo resi conto della necessità di raccogliere log Nginx, statistiche da pg_stat_statements e archiviare dati storici di Prometheus. Influx non ci è piaciuto perché periodicamente iniziava a consumare una grande quantità di memoria e si bloccava. Inoltre, volevo raggruppare le query per remote_addr, ma il raggruppamento in questo DBMS avviene solo per tag. I tag sono costosi (memoria), il loro numero è limitato condizionatamente.
Abbiamo ricominciato la nostra ricerca. Ciò che serviva era un database analitico con un consumo minimo di risorse, preferibilmente con compressione dei dati su disco.
Clickhouse soddisfa tutti questi criteri e non ci siamo mai pentiti della nostra scelta. Non vi scriviamo quantità straordinarie di dati (il numero di inserimenti è solo di circa cinquemila al minuto).
NewRelic
NewRelic è storicamente con noi perché è stata la scelta del cliente. Lo usiamo come APM.
Zabbix
Utilizziamo Zabbix esclusivamente per monitorare la Black Box di varie API.
Definizione di un approccio di monitoraggio
Volevamo scomporre il compito e quindi sistematizzare 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.
Perché questo approccio è conveniente:
- sappiamo chi è responsabile del lavoro di ciascun livello e, in base a ciò, possiamo inviare avvisi;
- possiamo usare la struttura quando sopprimiamo gli avvisi: sarebbe strano inviare un avviso sull'indisponibilità del database quando la macchina virtuale nel suo insieme non è disponibile.
Poiché il nostro compito è identificare le violazioni nel funzionamento del sistema, dobbiamo evidenziare ad ogni livello un certo insieme di parametri a cui vale la pena prestare attenzione quando scriviamo regole di avviso. Successivamente, esaminiamo i livelli “VMS”, “Sistema operativo” e “Servizi di sistema, stack software”.
Macchine virtuali
L'hosting ci assegna un processore, un disco, una memoria e una rete. E abbiamo avuto problemi con i primi due. Quindi, le metriche:
Tempo rubato alla CPU: quando acquisti una macchina virtuale su Amazon (t2.micro, ad esempio), dovresti capire che non ti viene assegnato un intero core del processore, ma solo una quota del suo tempo. E quando lo esaurisci, il processore ti verrà portato via.
Questa metrica ti consente di monitorare tali momenti e prendere decisioni. Ad esempio, è necessario applicare una tariffa più elevata o distribuire l'elaborazione delle attività in background e delle richieste API su server diversi?
IOPS + tempo di attesa della CPU: per qualche motivo, molti hosting cloud peccano non fornendo abbastanza IOPS. Inoltre, una pianificazione con IOPS bassi non è un argomento a loro favore. Pertanto, vale la pena raccogliere CPU iowait. Con questa coppia di grafici - con IOPS bassi e attesa I/O elevata - puoi già parlare con l'hosting e risolvere il problema.
Sistema operativo
Metriche del sistema operativo:
- quantità di memoria disponibile in %;
- attività di utilizzo dello scambio: vmstat swapin, swapout;
- numero di inode disponibili e spazio libero sul file system in %
- carico medio;
- numero di connessioni nello stato tw;
- controllare la pienezza della tabella;
- La qualità della rete può essere monitorata utilizzando l'utilità ss, il pacchetto iproute2: ottieni un indicatore delle connessioni RTT dal suo output e raggruppalo per porta di destinazione.
Anche a livello del sistema operativo abbiamo entità come i processi. È importante identificare nel sistema un insieme di processi che svolgono un ruolo importante nel suo funzionamento. Se, ad esempio, disponi di diversi pgpool, devi raccogliere informazioni per ciascuno di essi.
L'insieme delle metriche è il seguente:
- PROCESSORE;
- la memoria è principalmente residente;
- IO - preferibilmente in IOPS;
- FileFd: apri e limita;
- errori di pagina significativi: in questo modo puoi capire quale processo viene scambiato.
Distribuiamo tutto il monitoraggio in Docker e utilizziamo Advisor per raccogliere dati sulle metriche. Su altre macchine utilizziamo l'esportatore di processi.
Servizi di sistema, stack software
Ogni applicazione ha le sue specifiche ed è difficile individuare un insieme specifico di parametri.
Il set universale è:
- tasso di richiesta;
- numero di errori;
- latenza;
- saturazione.
I nostri esempi più eclatanti di monitoraggio a questo livello sono Nginx e PostgreSQL.
Il servizio più caricato nel nostro sistema è il database. In passato, spesso avevamo difficoltà a capire cosa stesse facendo il database.
Abbiamo riscontrato un carico elevato sui dischi, ma i registri lenti non hanno mostrato nulla. Abbiamo risolto questo problema utilizzando pg_stat_statements, una vista che raccoglie le statistiche delle query.
Questo è tutto ciò di cui l'amministratore ha bisogno.
Costruiamo grafici dell'attività delle richieste di lettura e scrittura:
Tutto è semplice e chiaro, ogni richiesta ha il suo colore.
Un esempio altrettanto sorprendente sono i log di Nginx. Non sorprende che poche persone li analizzino o li menzionino nell'elenco dei must-have. Il formato standard non è molto informativo e necessita di essere ampliato.
Personalmente ho aggiunto request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Tracciamo il tempo di risposta e il numero di errori:
Costruiamo grafici sui tempi di risposta e sul numero di errori. Ricordare? Ho parlato di compiti aziendali? In modo rapido e senza errori? Abbiamo già trattato questi temi con due grafici. E puoi già chiamare gli amministratori di turno utilizzandoli.
Ma rimane ancora un problema: garantire la rapida eliminazione delle cause dell'incidente.
Risoluzione dell'incidente
L’intero processo dall’identificazione alla risoluzione di un problema può essere suddiviso in una serie di passaggi:
- identificare il problema;
- notifica all'amministratore di turno;
- risposta a un incidente;
- eliminazione delle cause.
È importante farlo il più rapidamente possibile. E se nelle fasi di identificazione del problema e invio di una notifica non possiamo guadagnare molto tempo - in ogni caso verranno dedicati due minuti, quelli successivi sono semplicemente un campo non arato per miglioramenti.
Immaginiamo solo che squilli il telefono dell'ufficiale di turno. Che cosa farà? Cerca risposte alle domande: cosa si è rotto, dove si è rotto, come reagire? Ecco come rispondiamo a queste domande:
Includiamo semplicemente tutte queste informazioni nel testo della notifica, forniamo un collegamento a una pagina wiki che descrive come rispondere a questo problema, come risolverlo e segnalarlo.
Non ho ancora detto nulla sul livello applicativo e sulla logica aziendale. Sfortunatamente, le nostre applicazioni non implementano ancora la raccolta delle metriche. L'unica fonte di informazioni da questi livelli sono i log.
Un paio di punti.
Innanzitutto, scrivi log strutturati. Non è necessario includere il contesto nel testo del messaggio. Ciò li rende difficili da raggruppare e analizzare. Logstash impiega molto tempo per normalizzare tutto questo.
In secondo luogo, utilizzare correttamente i livelli di gravità. Ogni lingua ha il proprio standard. Personalmente distinguo quattro livelli:
- nessun errore;
- errore lato client;
- l’errore è dalla nostra parte, non perdiamo soldi, non corriamo rischi;
- L'errore è dalla nostra parte, perdiamo soldi.
Vorrei riassumere. È necessario provare a creare un monitoraggio basato sulla logica aziendale. Prova a monitorare l'applicazione stessa e ad operare con parametri quali il numero di vendite, il numero di registrazioni di nuovi utenti, il numero di utenti attualmente attivi e così via.
Se tutta la tua attività è un pulsante nel browser, devi monitorare se fa clic e funziona correttamente. Tutto il resto non conta.
Se non lo disponi, puoi provare a recuperarlo nei log dell'applicazione, nei log di Nginx e così via, come abbiamo fatto noi. Dovresti essere il più vicino possibile all'applicazione.
Le metriche del sistema operativo sono ovviamente importanti, ma le aziende non sono interessate a loro, non siamo pagati per loro.
Fonte: habr.com