Abbiamo iniziato a pensare alla creazione di un sistema di monitoraggio durante la fase di formazione dei team di prodotto. È diventato chiaro che la nostra funzione, cioè l'operatività, non rientra in questi team. Perché?
Il fatto è che tutti i nostri team sono costruiti attorno a sistemi informatici separati, microservizi e front-end, quindi non vedono lo stato di salute complessivo dell'intero sistema. Ad esempio, potrebbero non sapere come una piccola parte nel profondo del back-end influisca sulla parte frontale. Il loro ambito di interesse è limitato ai sistemi con cui il loro sistema è integrato. Se il team e il suo servizio A non sono quasi affatto collegati al servizio B, allora quest'ultimo è praticamente invisibile per il team.
La nostra squadra, d'altra parte, lavora con sistemi che sono fortemente integrati tra loro: ci sono molte interconnessioni, e si tratta di un'infrastruttura piuttosto ampia. E il funzionamento di questi sistemi (che, a proposito, sono in gran numero) è fondamentale per il lavoro del negozio online.
E così scopriamo che il nostro dipartimento non appartiene a nessuna squadra, ma si trova un po' in disparte. In tutta questa situazione, il nostro compito è comprendere nel complesso come funzionano i sistemi informatici, le loro funzionalità, integrazioni, software, rete, hardware, e come tutto ciò sia interconnesso.
La piattaforma su cui funzionano i nostri negozi online appare così:
- front
- middle-office
- back-office
Per quanto ci piacerebbe, non esiste una situazione in cui tutti i sistemi funzionino senza intoppi e perfettamente. Questo, di nuovo, è dovuto al numero di sistemi e integrazioni: in una realtà come la nostra, alcuni incidenti sono inevitabili, nonostante la qualità dei test. Questo vale sia per una singola sistema che in termini di integrazione. E bisogna monitorare lo stato dell'intera piattaforma in modo globale, non solo una sua parte.
Idealmente, il monitoraggio dello stato di salute dell'intera piattaforma dovrebbe essere automatizzato. Abbiamo considerato il monitoraggio come una parte inevitabile di questo processo. Inizialmente, era stato progettato solo per il front-end, mentre i sistemi di monitoraggio interni per i vari strati erano e sono in uso da parte dei professionisti di rete, gli amministratori software e dell'hardware. Tutti questi team monitoravano solo il proprio livello, senza una comprensione complessiva da parte di nessuno.
Ad esempio, se una macchina virtuale si guasta, nella maggior parte dei casi solo l'amministratore responsabile dell'hardware e della macchina virtuale ne è a conoscenza. Il team del front-end in queste situazioni ha visto solo il fatto che l'applicazione è caduta, ma non ha informazioni sul guasto della macchina virtuale. L'amministratore potrebbe sapere chi è il cliente e avere un'idea di cosa stia girando su quella macchina virtuale, a patto che si tratti di un grande progetto. Per i progetti più piccoli, probabilmente non ne è a conoscenza. In ogni caso, l'amministratore deve rivolgersi al proprietario, chiedere cosa c'era su quella macchina, cosa necessita di essere ripristinato e cosa deve essere cambiato. E se il problema fosse qualcosa di veramente grave, si iniziava a correre in tondo — perché nessuno aveva una visione d'insieme del sistema.
Alla fine, queste storie frammentate influenzano l'intero front-end, gli utenti e la nostra funzione aziendale principale — le vendite online. Poiché non ci integriamo nei team, ma gestiamo tutte le applicazioni ecommerce all'interno del negozio online, ci siamo presi l'incarico di creare un sistema di monitoraggio completo per la piattaforma ecommerce.
Struttura del sistema e stack
Abbiamo iniziato identificando diversi livelli di monitoraggio per i nostri sistemi, attraverso i quali dovremo raccogliere metriche. E tutto questo doveva essere unito, il che abbiamo realizzato nella prima fase. Attualmente, in questa fase, stiamo perfezionando la raccolta delle metriche per ottimizzare la qualità su tutti i nostri livelli, per stabilire correlazioni e comprendere come i sistemi si influenzano a vicenda.
L'assenza di un monitoraggio completo nelle fasi iniziali di avvio delle applicazioni (poiché abbiamo iniziato a costruirlo quando la maggior parte dei sistemi era già in funzione) ha portato a un significativo debito tecnico nella configurazione del monitoraggio dell'intera piattaforma. Non potevamo permetterci di concentrarci sulla configurazione del monitoraggio di un singolo IS e di lavorare in dettaglio su di essa, poiché gli altri sistemi sarebbero rimasti per un certo periodo senza monitoraggio. Per affrontare questa questione, abbiamo definito un elenco delle metriche più necessarie per valutare lo stato del sistema informativo per i vari livelli e abbiamo iniziato a implementarlo.
Pertanto, abbiamo deciso di affrontare il problema a pezzi.
Il nostro sistema è composto da:
- hardware;
- sistema operativo;
- software;
- Componenti UI nell'app di monitoraggio;
- metriche aziendali;
- applicazioni di integrazione;
- sicurezza delle informazioni;
- reti;
- bilanciatore di carico.
Al centro di questo sistema c'è il monitoraggio stesso. Per avere una visione generale dello stato dell'intero sistema, è necessario sapere cosa succede alle applicazioni su tutti questi livelli e attraverso l'intero insieme di applicazioni.
Ecco a cosa serve lo stack.
Utilizziamo software open source. Al centro abbiamo Zabbix, che utilizziamo principalmente come sistema di alerting. È ben noto che è perfetto per monitorare l'infrastruttura. Cosa si intende qui? Proprio quelle metriche a basso livello che ogni azienda con un proprio data center possiede (e Sportmaster ha i propri data center) — temperatura del server, stato della memoria, RAID, metriche dei dispositivi di rete.
Abbiamo integrato Zabbix con i messenger Telegram e Microsoft Teams, ampiamente utilizzati nei team. Zabbix copre il livello effettivo della rete, dell'hardware e parzialmente del software, ma non è una panacea. Arricchiamo questi dati da alcuni altri servizi. Ad esempio, a livello hardware ci connettiamo direttamente tramite API nel nostro sistema di virtualizzazione e recuperiamo i dati.
In aggiunta, utilizziamo Prometheus, che consente di monitorare le metriche nelle applicazioni di ambienti dinamici. Ciò significa che possiamo ottenere le metriche dell'applicazione tramite endpoint HTTP senza preoccuparci di quali metriche caricare e quali no. Sulla base di questi dati possiamo sviluppare richieste analitiche.
Le fonti di dati per gli altri strati, ad esempio le metriche di business, si suddividono in tre componenti.
In primo luogo, ci sono sistemi di business esterni, Google Analytics, raccogliamo metriche dai log. Da questi otteniamo dati sugli utenti attivi, sulle conversioni e su tutto ciò che riguarda il business. In secondo luogo, c'è il sistema di monitoraggio dell'interfaccia utente. Di questo vale la pena parlare più nel dettaglio.
Un tempo siamo partiti dai test manuali, che si sono evoluti in test automatici per funzionalità e integrazioni. Da questo abbiamo sviluppato un sistema di monitoraggio, mantenendo solo le funzionalità principali e legandoci a marker che sono il più stabili possibile e cambiano raramente nel tempo.
La nuova struttura dei team prevede che tutte le attività relative alle applicazioni siano gestite dai team di prodotto, quindi abbiamo smesso di concentrarci esclusivamente sui test. Invece, abbiamo trasformato i test in monitoraggio UI, scritto in Java, Selenium e Jenkins (utilizzato come sistema di avvio e generazione di report).
Avevamo molti test, ma alla fine abbiamo deciso di puntare a metriche più generali. Se avessimo molti test specifici, sarebbe stato difficile mantenere l'accuratezza dei dati. Ogni nuova versione romperebbe significativamente l'intero sistema, e noi ci limiteremmo a ripararlo. Pertanto, ci siamo concentrati su aspetti completamente fondamentali, che cambiano raramente, monitorando solo quelli.
Infine, in terzo luogo, la fonte dei dati è un sistema centralizzato di logging. Utilizziamo Elastic Stack per i log e poi possiamo trasferire questi dati nel nostro sistema di monitoraggio delle metriche di business. In aggiunta a tutto ciò, funziona il nostro servizio Monitoring API, scritto in Python, che interroga tramite API qualsiasi servizio e raccoglie i dati da essi in Zabbix.
Un altro attributo indispensabile del monitoraggio è la visualizzazione. La nostra è basata su Grafana. Tra gli altri sistemi di visualizzazione, spicca per la possibilità di visualizzare metriche provenienti da diverse fonti di dati sul dashboard. Possiamo raccogliere metriche di alto livello di un negozio online, ad esempio, il numero di ordini effettuati nell'ultima ora dal DBMS, metriche sulle prestazioni del sistema operativo su cui è in esecuzione questo negozio online da Zabbix, e le metriche degli istanze di questa applicazione da Prometheus. E tutto questo sarà su un unico dashboard. Chiaro e accessibile.
Riguardo alla sicurezza, stiamo attualmente perfezionando un sistema che in seguito integreremo con un sistema di monitoraggio globale. A mio avviso, le principali problematiche che affronta l'e-commerce nel campo della sicurezza informatica sono legate ai bot, ai parser e agli attacchi di brute force. È importante monitorare questi aspetti, poiché possono avere un impatto critico sia sul funzionamento delle nostre applicazioni che sulla reputazione aziendale. Con la stack tecnologico scelto, affrontiamo con successo queste sfide.
Un altro punto importante è che il livello delle applicazioni è monitorato da Prometheus. È integrato anche con Zabbix. Inoltre, abbiamo sitespeed, un servizio che ci consente di monitorare parametri come la velocità di caricamento delle nostre pagine, i colli di bottiglia, il rendering della pagina, il caricamento degli script e altro ancora, tutto tramite API. Le metriche vengono raccolte in Zabbix e di conseguenza gestiamo gli alert da lì. Attualmente, tutti gli avvisi vengono inviati attraverso i metodi principali (per ora email e telegram, abbiamo anche recentemente integrato MS Teams). Abbiamo in programma di migliorare il sistema di alerting affinché bot intelligenti possano funzionare come un servizio, fornendo informazioni sul monitoraggio a tutti i team di prodotto interessati.
Per noi sono importanti non solo le metriche delle singole sistemi informativi, ma anche le metriche generali su tutta l'infrastruttura utilizzata dalle applicazioni: cluster server fisici, che ospitano le macchine virtuali, bilanciatori di carico, Network Load Balancers, la rete stessa, l'utilizzo delle linee di comunicazione. Inoltre, metriche relative ai nostri centri di elaborazione dati (ne abbiamo diversi e l'infrastruttura è di dimensioni considerevoli).
I vantaggi del nostro sistema di monitoraggio consentono di vedere lo stato operativo di tutti i sistemi, valutare il loro impatto reciproco e sulle risorse complessive. In ultima analisi, permette di pianificare le risorse, che è anche una nostra responsabilità. Gestiamo le risorse server — un pool nell'ambito dell'e-commerce, introduciamo ed estraiamo dalla produzione nuove attrezzature, acquistiamo nuovo materiale, e conduciamo audit sull'uso delle risorse e altro ancora. Ogni anno i team pianificano nuovi progetti, sviluppano i propri sistemi, e per noi è importante fornire loro le risorse necessarie.
Attraverso le metriche possiamo osservare le tendenze nel consumo di risorse da parte dei nostri sistemi informativi. E già sulla base di queste, possiamo pianificare. A livello di virtualizzazione, raccogliamo dati e vediamo informazioni sulla quantità di risorse disponibili suddivise per Data Center. All'interno del Data Center, osserviamo sia l'utilizzo che la distribuzione effettiva, il consumo delle risorse. Questo vale sia per i server standalone che per le macchine virtuali e i cluster di server fisici su cui girano queste virtual machine.
Prospettive
Attualmente abbiamo pronto il nucleo del sistema nel suo complesso, ma ci sono ancora molti aspetti su cui dobbiamo lavorare. Almeno questo riguarda il livello di sicurezza informatica, ma è anche fondamentale arrivare alla rete, sviluppare l'allerta e risolvere la questione della correlazione. Abbiamo molti livelli e sistemi, e su ciascun livello ci sono molteplici metriche. Si tratta di una matrioska elevata alla potenza di una matrioska.
Il nostro obiettivo finale è creare allerta adeguate. Ad esempio, se si verifica un problema con l'hardware, di nuovo con la macchina virtuale, e lì c'era un'applicazione importante, e il servizio non era in alcun modo riservato. Scopriremo che la macchina virtuale è caduta. Successivamente, saranno allertate le metriche aziendali: gli utenti sono scomparsi, non ci sono conversioni, l'interfaccia utente non è disponibile, anche il software e i servizi sono caduti.
In questo scenario, ci ritroveremmo sommersi da spam di avvisi, il che non si adatta a un sistema di monitoraggio efficace. La questione della correlazione diventa cruciale. Idealmente, il nostro sistema di monitoraggio dovrebbe dire: «Ragazzi, il vostro server fisico è andato, e insieme a esso questa applicazione e queste metriche», con un solo avviso invece di sommergerci con un centinaio di allerta. Deve comunicare l'essenziale — la causa, che aiuta a risolvere il problema rapidamente grazie alla sua localizzazione.
Il nostro sistema di notifiche e gestione degli avvisi è strutturato attorno a un servizio di hotline attivo 24 ore su 24. Tutti gli avvisi considerati essenziali e inclusi nella nostra checklist vengono inviati lì. Ogni avviso deve necessariamente contenere una descrizione: cosa è successo, cosa significa, su cosa influisce. Inoltre, deve includere un link al dashboard e le istruzioni su cosa fare in questo caso.
Queste sono le nostre esigenze per la configurazione degli avvisi. Da qui, la situazione può evolversi in due direzioni — o il problema esiste e deve essere risolto, oppure c'è stato un guasto nel sistema di monitoraggio. In ogni caso, bisogna andare e indagare.
Attualmente, riceviamo in media circa un centinaio di avvisi al giorno, considerando che la correlazione degli avvisi non è ancora impostata correttamente. Se è necessario eseguire lavori tecnici e disattiviamo qualcosa forzatamente, il numero aumenta notevolmente.
Oltre al monitoraggio dei sistemi che gestiamo e alla raccolta di metriche considerate importanti da parte nostra, il sistema di monitoraggio consente di raccogliere dati per i team di prodotto. Questi possono influenzare la composizione delle metriche all'interno dei sistemi informativi che monitoriamo.
Un nostro collega può venire e chiedere di aggiungere una metrica che risulterà utile sia a noi che al team. Oppure, ad esempio, al team potrebbero mancare le metriche di base che abbiamo, e necessitano di monitorare qualcosa di specifico. In Grafana, creiamo uno spazio per ogni team e forniamo diritti di amministratore. Inoltre, se un team ha bisogno di dashboard, ma non può/non sa come farlo, li assistiamo.
Poiché siamo al di fuori del flusso di creazione di valore del team, delle loro release e della pianificazione, stiamo progressivamente arrivando a un punto in cui le release di tutti i sistemi sono senza soluzione di continuità e possono essere pubblicate quotidianamente, senza necessità di accordo con noi. È importante per noi monitorare queste release, poiché potrebbero potenzialmente influenzare il funzionamento dell'applicazione e danneggiare qualcosa, e questo è critico. Per gestire le release utilizziamo Bamboo, da cui otteniamo i dati tramite API e possiamo vedere quali release sono state effettuate e il loro stato nei vari sistemi informativi. E la cosa più importante è: a che ora. Applichiamo i marker sulle release alle metriche critiche principali, il che è visivamente molto indicativo in caso di problemi.
In questo modo possiamo vedere la correlazione tra le nuove release e i problemi emergenti. L'idea principale è capire come funziona il sistema a tutti i livelli, localizzare rapidamente il problema e risolverlo altrettanto velocemente. Infatti, spesso il più tempo viene speso non per risolvere il problema, ma per trovare la causa.
In this area, we plan to focus on proactivity in the future. Ideally, we would like to know about an impending issue in advance, rather than after it occurs, so we can prevent it instead of just resolving it. Sometimes there are false alarms from the monitoring system, both due to human error and changes in the application. We are working on this, fine-tuning it, and trying to notify users who use the monitoring system alongside us about any manipulations beforehand, or to carry out these activities during maintenance windows.
So, the system is up and running successfully since the beginning of spring... and is showing quite a real profit. Of course, this is not its final version; we will implement many more useful features. But right now, given the large number of integrations and applications, we really cannot do without automated monitoring.
If you are also monitoring large projects with a significant number of integrations — please share in the comments what silver bullet you have found for this.
Fonte: habr.com
