{"id":31864,"date":"2019-10-31T21:43:33","date_gmt":"2019-10-31T18:43:33","guid":{"rendered":"https:\/\/prohoster.info\/blog\/monitoring-myortv-da-zdravstvuet-monitoring\/"},"modified":"2019-10-31T21:43:33","modified_gmt":"2019-10-31T18:43:33","slug":"monitoring-myortv-da-zdravstvuet-monitoring","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring","title":{"rendered":"Monitoraggio morto? \u2014 Lunga vita al monitoraggio","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Monitoraggio morto? \u2014 Lunga vita al monitoraggio\" src=\"\/wp-content\/uploads\/2019\/04\/13453bb7025a6bf3d1c7a3dc6d038d16.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa nostra azienda si occupa principalmente della gestione delle infrastrutture e del supporto tecnico 24 ore su 24 per progetti web dal 2008: abbiamo pi\u00f9 di 400 clienti, che rappresentano circa il 15% dell'e-commerce in Russia. Di conseguenza, ci sono architetture molto varie nel supporto. Se qualcosa si guasta, dobbiamo ripararlo entro 15 minuti. Ma per capire che \u00e8 avvenuta un'emergenza, \u00e8 necessario monitorare il progetto e reagire agli incidenti. E come si fa? <\/p>\n<p>Ritengo che, nell'organizzazione di un sistema di monitoraggio adeguato, ci siano problemi. Se non ci fossero problemi, il mio discorso si limiterebbe a un unico punto: \u00abInstallate per favore Prometheus + Grafana e i plugin 1, 2, 3\u00bb. Sfortunatamente, ora non funziona cos\u00ec. E il problema principale \u00e8 che tutti continuano a credere a qualcosa che esisteva nel 2008, in termini di componenti software. <\/p>\n<p>Per quanto riguarda l'organizzazione di un sistema di monitoraggio, mi azzardo a dire che... i progetti con un monitoraggio adeguato non esistono. E la situazione \u00e8 cos\u00ec grave che se qualcosa fallisce, c'\u00e8 il rischio che rimanga inosservato \u2013 tutti sono convinti che \u00abtutto sia monitorato\u00bb.<br \/>\nForse, tutto \u00e8 monitorato. Ma come? <\/p>\n<p>Tutti noi ci siamo imbattuti in storie simili alla seguente: un certo devops, un certo admin, ricevono una squadra di sviluppatori che dice \u2013 \u00ababbiamo fatto il rilascio, ora monitorate\u00bb. Cosa monitoriamo? Come funziona?<\/p>\n<p>Ok. Monitoriamo alla vecchia maniera. Ma nel frattempo tutto cambia, e si scopre che stavi monitorando il servizio A, che \u00e8 diventato il servizio B, che interagisce con il servizio C. Ma la squadra di sviluppatori ti dice: \u00abInstalla il software, dovrebbe monitorare tutto!\u00bb<\/p>\n<p>E quindi, cosa \u00e8 cambiato? \u2013 \u00c8 cambiato tutto!<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h4>2008. Tutto andava bene.<\/h4>\n<p>\nCi sono un paio di sviluppatori, un server, un server DB. Da qui inizia tutto. Abbiamo alcune informazioni, installiamo zabbix, Nagios, cacti. E poi impostiamo avvisi chiari su CPU, sull'attivit\u00e0 dei dischi, sullo spazio disponibile sui dischi. Inoltre, facciamo un paio di controlli manuali, per assicurarci che il sito risponda, che gli ordini arrivino nel database. E poi \u2013 siamo pi\u00f9 o meno protetti. <\/p>\n<p>Se confrontiamo la quantit\u00e0 di lavoro che l'amministratore doveva svolgere allora per garantire il monitoraggio, il 98% era automatizzato: la persona che si occupa del monitoraggio deve capire come installare Zabbix, come configurarlo e impostare le allerte. E il 2% \u00e8 dedicato ai controlli esterni: se il sito risponde e fa richieste al database, se sono arrivati nuovi ordini.<\/p>\n<p><img decoding=\"async\" alt=\"Monitoraggio morto? \u2014 Lunga vita al monitoraggio\" src=\"\/wp-content\/uploads\/2019\/04\/3563dda4d025fd18200d6410d7d065ed.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <\/p>\n<h4>Anno 2010. Aumenta il carico<\/h4>\n<p>\nIniziamo a scalare i web, aggiungiamo un motore di ricerca. Vogliamo essere certi che il catalogo dei prodotti contenga tutti i prodotti. E che la ricerca dei prodotti funzioni. Che il database funzioni, che gli ordini vengano effettuati, che il sito risponda esternamente e risponda da due <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/it\/server\/\"   title=\"server\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1314\">server<\/a> e all'utente non venga espulso dal sito finch\u00e9 non viene riequilibrato su un altro server, e cos\u00ec via. Il numero delle entit\u00e0 aumenta. <\/p>\n<p>Inoltre, l'entit\u00e0 legata all'infrastruttura rimane ancora la pi\u00f9 grande nella testa del manager. L'idea che la persona responsabile del monitoraggio sia quella che installa Zabbix e sa configurarlo continua a persistere.<\/p>\n<p>Ma nel frattempo compaiono lavori per eseguire controlli esterni, per creare un insieme di script per le richieste dell'indice di ricerca, un insieme di script per verificare che la ricerca cambi durante l'indicizzazione, un insieme di script che controllano che i prodotti vengano trasferiti al servizio di consegna, ecc. ecc.<\/p>\n<p><img decoding=\"async\" alt=\"Monitoraggio morto? \u2014 Lunga vita al monitoraggio\" src=\"\/wp-content\/uploads\/2019\/04\/afa94a3156a24a81ab359b430341f27d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNotate: ho scritto \"insieme di script\" tre volte. Quindi chi \u00e8 responsabile del monitoraggio non \u00e8 pi\u00f9 semplicemente chi installa Zabbix. \u00c8 una persona che inizia a programmare. Ma nella testa del team nulla cambia ancora. <\/p>\n<p>Eppure il mondo cambia, diventando sempre pi\u00f9 complesso. Viene aggiunto uno strato di virtualizzazione, diversi nuovi sistemi. Iniziano a interagire tra loro. Chi ha detto \"sembra microservizi?\" Ma ogni servizio continua a sembrare un sito separato. Possiamo accedervi e capire che fornisce le informazioni necessarie e funziona autonomamente. E se sei un amministratore che si occupa continuamente di un progetto che si sviluppa da 5-7-10 anni, queste conoscenze si accumulano: emerge un nuovo livello - lo hai compreso, emerge un ulteriore livello - lo hai compreso\u2026 <\/p>\n<p><img decoding=\"async\" alt=\"Monitoraggio morto? \u2014 Lunga vita al monitoraggio\" src=\"\/wp-content\/uploads\/2019\/04\/3578182594d012732afde7849b75322a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMa raramente qualcuno accompagna un progetto per 10 anni.<\/p>\n<h3>Riepilogo del monitoraggio<\/h3>\n<p>\nSupponiamo che tu sia arrivato in una nuova startup, che ha subito assunto 20 sviluppatori, ha scritto 15 microservizi, e tu \u2014 sei l'amministratore, a cui dicono: \u00abCostruisci CI\/CD. Per favore\u00bb. Hai costruito CI\/CD e all'improvviso senti: \u00ab\u00c8 difficile lavorare con la produzione nel 'cubetto', senza capire come funzioner\u00e0 l'applicazione al suo interno. Fai una sandbox in questo 'cubetto'.<br \/>\n Hai creato una sandbox in questo cubetto. Ti dicono subito: \u00abVogliamo un database di stadio, che si aggiorni ogni giorno dalla produzione, per capire se funziona sul database, ma senza rovinare il database di produzione\u00bb.<\/p>\n<p>Tu vivi tutto questo. Mancano 2 settimane al rilascio, ti dicono: \u00abOra dobbiamo monitorare tutto...\u00bb. Cio\u00e8, monitorare l'infrastruttura cluster, monitorare l'architettura microservizi, monitorare il lavoro con i servizi esterni... <\/p>\n<p>E i colleghi tirano fuori una soluzione abituale e dicono: \u00abMa qui \u00e8 tutto chiaro! Installa un programma che monitori tutto\u00bb. S\u00ec: Prometheus + Grafana + plugin. <br \/>\nE aggiungono: \u00abHai circa due settimane, fai in modo che sia tutto affidabile\u00bb.<\/p>\n<p>In molti progetti che vediamo, sul monitoraggio viene assegnata una sola persona. Immagina di voler assumere qualcuno per 2 settimane che si occupi del monitoraggio, e stiamo preparando il suo curriculum. Quali competenze deve avere questa persona, considerando tutto ci\u00f2 che abbiamo detto finora?<\/p>\n<ul>\n<li>Deve comprendere il monitoraggio e la specificit\u00e0 del lavoro dell'infrastruttura hardware.<\/li>\n<li>Deve capire la specificit\u00e0 del monitoraggio di Kubernetes (tutti vogliono nel 'cubetto', perch\u00e9 si pu\u00f2 astrarsi da tutto, nascondersi, visto che l'amministratore si occuper\u00e0 del resto) \u2014 di per s\u00e9, della sua infrastruttura e capire come monitorare le applicazioni interne.<\/li>\n<li>Deve comprendere che i servizi comunicano tra loro in modi particolari e conoscere le specificit\u00e0 dell'interazione tra i servizi. \u00c8 completamente possibile vedere un progetto in cui parte dei servizi comunicano in modo sincrono, perch\u00e9 non si pu\u00f2 fare diversamente. Ad esempio, il backend va via REST, via gRPC al servizio catalogo, ottiene un elenco di prodotti e restituisce indietro. Qui non si pu\u00f2 aspettare. E con altri servizi lavora in modo asincrono. Trasmettere un ordine al servizio di consegna, inviare un'email e cos\u00ec via.<br \/>\nProbabilmente ti sei gi\u00e0 perso in tutto questo? E l'amministratore, che deve monitorarlo, \u00e8 ancora pi\u00f9 in difficolt\u00e0. <\/li>\n<li>Deve saper pianificare e pianificare correttamente, poich\u00e9 il lavoro sta aumentando sempre di pi\u00f9. <\/li>\n<li>Deve quindi creare una strategia del servizio creato per capire come monitorarlo concretamente. Ha bisogno di comprendere l'architettura del progetto e il suo sviluppo, oltre a avere una comprensione delle tecnologie utilizzate nello sviluppo. <\/li>\n<\/ul>\n<p>\nRicordiamo un caso assolutamente normale: una parte dei servizi \u00e8 scritta in php, un'altra parte in Go, un'altra ancora in JS. Funzionano in qualche modo tra di loro. Da qui deriva il termine \"microservizio\": ci sono cos\u00ec tanti sistemi separati che gli sviluppatori non riescono a comprendere il progetto nel suo insieme. Una parte del team scrive servizi in JS che funzionano autonomamente e non sanno come funziona il resto del sistema. Un'altra parte scrive servizi in Python e non si preoccupa di come funzionano gli altri servizi, sono isolati nel loro ambito. Un terzo gruppo scrive servizi in php o in qualcos'altro. <br \/>\nTutte queste 20 persone sono divise su 15 servizi e c'\u00e8 solo un amministratore che deve capire tutto questo. Stop! abbiamo appena suddiviso il sistema in 15 microservizi, perch\u00e9 20 persone non riescono a comprendere l'intero sistema. <\/p>\n<p>Eppure deve essere monitorato in qualche modo...<\/p>\n<p>Qual \u00e8 il risultato? Alla fine c'\u00e8 una persona che comprende tutto ci\u00f2 che non pu\u00f2 comprendere un intero team di sviluppatori, e che deve anche conoscere e saper fare ci\u00f2 che abbiamo indicato sopra: l'infrastruttura hardware, l'infrastruttura Kubernetes, ecc.<\/p>\n<p>Cosa dire a riguardo... Houston, abbiamo un problema.<\/p>\n<h3>Il monitoraggio di un moderno progetto software \u00e8 di per s\u00e9 un progetto software.<\/h3>\n<p>\nDalla falsa convinzione che il monitoraggio sia un software, nasce la nostra fiducia nei miracoli. E, purtroppo, i miracoli non esistono. Non si pu\u00f2 semplicemente installare zabbix e aspettarsi che tutto funzioni. Non ha senso installare Grafana e sperare che vada tutto bene. La maggior parte del tempo sar\u00e0 dedicata all'organizzazione dei controlli sul funzionamento dei servizi e delle loro interazioni reciproche, e al controllo di come funzionano i sistemi esterni. Infatti, il 90% del tempo non sar\u00e0 dedicato alla scrittura di script, ma allo sviluppo del software. E questo compito deve essere svolto da un team che comprende il funzionamento del progetto. <br \/>\nSe in questa situazione si mette una sola persona a occuparsi del monitoraggio, allora si verifica un disastro. Ed \u00e8 esattamente ci\u00f2 che accade ovunque.<\/p>\n<p>Ad esempio, ci sono diversi servizi che comunicano tra di loro tramite Kafka. Quando arriva un ordine, inviamo il messaggio dell'ordine a Kafka. C'\u00e8 un servizio che ascolta le informazioni sull'ordine e gestisce la spedizione della merce. C'\u00e8 un altro servizio che ascolta le informazioni sull'ordine e invia una email all'utente. Poi ci sono molti altri servizi, e cominciamo a confonderci.<\/p>\n<p>E se poi lo date anche all'amministratore e agli sviluppatori in un momento in cui resta poco tempo fino al rilascio, la persona deve capire tutto questo protocollo. Cio\u00e8, un progetto di tale portata richiede molto tempo, e questo deve essere previsto nello sviluppo del sistema. <br \/>\nMa molto spesso, soprattutto in fase di avvio, vediamo come il monitoraggio venga rimandato. \"Ora faremo un Proof of Concept, lanceremo con quello, anche se cade \u2013 siamo pronti a sacrificare. E poi monitoreremo tutto.\" Quando (o se) il progetto inizia a generare entrate, l'azienda vuole implementare ancora pi\u00f9 funzionalit\u00e0 \u2014 perch\u00e9 ha cominciato a funzionare, quindi bisogna continuare a espandere! Ma ti trovi in un punto in cui all'inizio devi monitorare tutto ci\u00f2 che \u00e8 stato fatto, il che richiede molto pi\u00f9 del 1% del tempo. E, tra l'altro, per il monitoraggio servono sviluppatori, e risulta pi\u00f9 semplice destinarli a nuove funzionalit\u00e0. Alla fine vengono scritte nuove funzionalit\u00e0, tutto si accumula, e ti trovi in un deadlock infinito.<\/p>\n<p>Quindi, come monitorare un progetto fin dall'inizio, e cosa fare se ti capita di dover monitorare un progetto ma non sai da dove cominciare?<\/p>\n<p>Innanzitutto, \u00e8 necessario pianificare. <\/p>\n<p><i>Una nota lirica: molto spesso si inizia con il monitoraggio dell'infrastruttura. Ad esempio, abbiamo Kubernetes. Iniziamo installando Prometheus con Grafana, installiamo plugin per il monitoraggio del 'cubetto'. Non solo gli sviluppatori, ma anche gli amministratori seguono una pratica infelice: 'Installeremo questo plugin, e il plugin sicuramente sa come farlo'. Le persone amano iniziare con cose semplici e comprensibili, piuttosto che con azioni cruciali. E il monitoraggio dell'infrastruttura \u00e8 semplice.<\/i><\/p>\n<p>Per iniziare, determinate cosa e come volete monitorare, e poi scegliete lo strumento giusto, perch\u00e9 altre persone non possono pensare per voi. E devono farlo? Altre persone hanno pensato a se stesse, a un sistema universale \u2014 o non hanno pensato affatto, quando hanno scritto questo plugin. E il fatto che questo plugin abbia 5 mila utenti non significa che porti qualche beneficio. Potreste diventare il 5001\u00b0 solo perch\u00e9 prima di voi ci sono gi\u00e0 stati 5000 utenti. <\/p>\n<p>Se avete iniziato a monitorare l'infrastruttura e il backend della vostra applicazione ha smesso di rispondere, tutti gli utenti perderanno la connessione con l'app mobile. Si verificher\u00e0 un errore. Vi verranno a dire \u00abL'app non funziona, cosa state facendo?\u00bb \u2014 \u00abStiamo monitorando\u00bb. \u2014 \u00abCome potete monitorare se non vedete che l'app non funziona?!\u00bb <\/p>\n<ol>\n<li>Ritengo che il monitoraggio debba iniziare proprio dal punto di ingresso dell'utente. Se l'utente non vede che l'app funziona \u2014 \u00e8 un fallimento. E il sistema di monitoraggio deve avvisare riguardo a ci\u00f2 prima di tutto. <\/li>\n<li>Solo dopo possiamo monitorare l'infrastruttura. O farlo parallelamente. Con l'infrastruttura \u00e8 pi\u00f9 semplice \u2014 qui finalmente possiamo semplicemente installare Zabbix. <\/li>\n<li>E ora dobbiamo andare alla radice dell'applicazione per capire dove qualcosa non funziona.<\/li>\n<\/ol>\n<p>\nIl mio pensiero principale \u00e8 che il monitoraggio deve andare di pari passo con il processo di sviluppo. Se distogliete il team di monitoraggio su altre attivit\u00e0 (creazione di CI\/CD, sandbox, riorganizzazione dell'infrastruttura), il monitoraggio inizier\u00e0 a rimanere indietro e forse non recupererete mai lo sviluppo (o prima o poi dovrete fermarlo).<\/p>\n<h3>Tutto per livelli<\/h3>\n<p>\nEcco come vedo l'organizzazione del sistema di monitoraggio.<\/p>\n<p>1) Livello dell'applicazione:<\/p>\n<ul>\n<li>monitoraggio della logica aziendale dell'applicazione;<\/li>\n<li>monitoraggio delle metriche di salute dei servizi;<\/li>\n<li>monitoraggio dell'integrazione.<\/li>\n<\/ul>\n<p>\n2) Livello dell'infrastruttura:<\/p>\n<ul>\n<li>monitoraggio del livello di orchestrazione;<\/li>\n<li>monitoraggio del software di sistema;<\/li>\n<li>monitoraggio del livello hardware.<\/li>\n<\/ul>\n<p>\n3) Ancora un livello dell'applicazione \u2014 ma come prodotto ingegneristico:<\/p>\n<ul>\n<li>raccolta e osservazione dei log dell'applicazione;<\/li>\n<li>APM;<\/li>\n<li>tracciamento.<\/li>\n<\/ul>\n<p>\n4) Allerta:<\/p>\n<ul>\n<li>organizzazione del sistema di avviso;<\/li>\n<li>organizzazione del sistema di turni;<\/li>\n<li>organizzazione di una \u00abbase di conoscenza\u00bb e workflow per la gestione degli incidenti.<\/li>\n<\/ul>\n<p>\n<b>Importante<\/b>: arriviamo all\u2019allerta non dopo, ma subito! Non bisogna avviare il monitoraggio e poi pensare a chi devono arrivare gli alert \u00abin un secondo momento\u00bb. Infatti, qual \u00e8 l'obiettivo del monitoraggio? Capire dove nel sistema c\u2019\u00e8 qualcosa che non funziona e informare le persone giuste. Se lasci questo per dopo, le persone giuste scopriranno che qualcosa non va solo quando riceveranno una chiamata \u00abnon funziona niente\u00bb.<\/p>\n<h3>Livello applicativo \u2013 monitoraggio della logica aziendale<\/h3>\n<p>\nSi tratta di controllare se l'applicazione funziona per l'utente.<\/p>\n<p>Questo livello deve essere realizzato durante la fase di sviluppo. Per esempio, abbiamo un Prometheus convenzionale: si collega al server che si occupa dei controlli, richiama un endpoint e quest'ultimo verifica l'API.<\/p>\n<p>Quando spesso chiedono di monitorare la homepage per assicurarsi che il sito funzioni, i programmatori forniscono un endpoint che pu\u00f2 essere richiamato ogni volta che \u00e8 necessario verificare che l'API funzioni. E mentre fanno questo, i programmatori scrivono anche \/api\/test\/helloworld <br \/>\nL'unico modo per essere certi che tutto funzioni? \u2013 No!<\/p>\n<ul>\n<li>La creazione di tali controlli \u00e8, in sostanza, compito dei programmatori. I test unitari devono essere scritti dai programmatori che scrivono il codice. Perch\u00e9, se lo affidi a un admin dicendo \u00abEhi, ecco un elenco dei protocolli API per tutte e 25 le funzioni, per favore, monitora tutto!\u00bb \u2013 non servir\u00e0 a nulla. <\/li>\n<li>Se fai print \u201chello world\u201d, nessuno sapr\u00e0 mai che l'API deve e funziona effettivamente. Ogni modifica dell'API deve comportare una modifica dei controlli. <\/li>\n<li>Se hai gi\u00e0 questo problema, interrompi le funzionalit\u00e0 e assegna programmatori che scriveranno questi controlli, oppure rassegnati alle perdite, accettando che nulla venga verificato e che tutto cadr\u00e0.<\/li>\n<\/ul>\n<p>\nConsigli tecnici:<\/p>\n<ul>\n<li>Assicurati di organizzare un server esterno per i controlli \u2013 devi essere certo che il tuo progetto sia accessibile al mondo esterno.<\/li>\n<li>Organizza il monitoraggio di tutto il protocollo API, non solo di singoli endpoint.<\/li>\n<li>Crea un endpoint Prometheus con i risultati dei controlli.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Livello applicativo \u2013 monitoraggio delle metriche di salute<\/h3>\n<p>\nOra si parla delle metriche di salute esterne dei servizi. <\/p>\n<p>Abbiamo deciso che monitoreremo tutte le \"maniglie\" dell'applicazione utilizzando controlli esterni, che chiamiamo da un sistema di monitoraggio esterno. Ma queste sono proprio le \"maniglie\" che l'utente \"vede\". Vogliamo essere sicuri che i servizi stessi funzionino. Qui la situazione \u00e8 migliore: in K8s ci sono controlli di salute, affinch\u00e9 almeno il \"cubo\" possa verificare che il servizio funziona. Ma la met\u00e0 dei controlli che ho visto \u00e8 semplicemente un print \"hello world\". Cio\u00e8, viene richiamato una volta dopo il deploy, riceve la risposta che va tutto bene \u2014 e basta. E per un servizio, se restituisce il proprio API tramite REST, ci sono moltissimi punti di ingresso di quell'API che devono essere monitorati, poich\u00e9 vogliamo sapere che funziona. E noi lo monitoriamo gi\u00e0 internamente. <\/p>\n<p>Come implementarlo correttamente a livello tecnico: ogni servizio espone un endpoint sulla propria attuale operativit\u00e0, e nei grafici di Grafana (o di qualsiasi altra applicazione) vediamo lo stato di tutti i servizi.<\/p>\n<ul>\n<li>Ogni modifica dell'API deve comportare una modifica dei controlli. <\/li>\n<li>Creare un nuovo servizio immediatamente con metriche di salute.<\/li>\n<li>L'amministratore pu\u00f2 andare dagli sviluppatori e chiedere \"scrivete un paio di funzionalit\u00e0 in pi\u00f9, cos\u00ec capisco tutto e posso aggiungere informazioni al mio sistema di monitoraggio\". Ma gli sviluppatori di solito rispondono: \"Due settimane prima del rilascio non scriviamo nulla di nuovo.\"<br \/>\nFacciamo sapere ai manager dello sviluppo che ci saranno delle perdite, e che anche i supervisori dei manager dello sviluppo ne siano a conoscenza. Perch\u00e9, quando tutto crolla, qualcuno chiamer\u00e0 comunque e richieder\u00e0 di monitorare il \"servizio che continua a cadere\" (c) <\/li>\n<li>A proposito, dedicate degli sviluppatori alla scrittura di plugin per Grafana \u2014 sar\u00e0 un grande aiuto per gli amministratori.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Livello dell'applicazione \u2014 Monitoraggio d'integrazione<\/h3>\n<p>\nIl monitoraggio d'integrazione si concentra sul monitoraggio della comunicazione tra sistemi critici per il business.<\/p>\n<p>Ad esempio, ci sono 15 servizi che comunicano tra loro. Non sono pi\u00f9 siti separati. Cio\u00e8, non possiamo richiamare un servizio da solo, ottenere \/helloworld e capire che il servizio funziona. Perch\u00e9 il servizio web per la gestione degli ordini deve inviare informazioni sull'ordine al bus \u2014 dal bus il servizio di gestione del magazzino deve ricevere questo messaggio e lavorare su di esso. E il servizio di invio e-mail deve elaborarlo in un secondo momento, e cos\u00ec via. <\/p>\n<p>Di conseguenza, non possiamo capire, esplorando ogni singolo servizio, se tutto questo funzioni. Perch\u00e9 abbiamo una sorta di bus attraverso cui tutto comunica e interagisce.<br \/>\nPertanto, questa fase dovrebbe rappresentare la fase di test dei servizi in interazione con altri servizi. Non \u00e8 possibile, monitorando il broker di messaggi, organizzare il monitoraggio della comunicazione. Se c'\u00e8 un servizio che fornisce dati e un servizio che li riceve, monitorando il broker vedremo solo i dati che volano avanti e indietro. Anche se in qualche modo riusciamo a monitorare l'interazione di questi dati all'interno \u2014 cio\u00e8 un certo produttore posta dei dati, qualcuno li legge, questo flusso continua a fluire in Kafka \u2014 questo non ci dar\u00e0 comunque informazioni, se un servizio ha inviato un messaggio in una versione e un altro servizio non si aspettava quella versione e l'ha persa. Non lo scopriremo, poich\u00e9 i servizi ci diranno che tutto funziona. <\/p>\n<p>Come consiglio di fare:<\/p>\n<ul>\n<li>Per la comunicazione sincrona: l'endpoint esegue richieste ai servizi collegati. Cio\u00e8, prendiamo questo endpoint, tiriamo un piccolo script all'interno del servizio, che passa attraverso tutti i punti e dice \u00abposso tirare l\u00e0, e tirare l\u00e0, posso tirare l\u00ec\u2026\u00bb<\/li>\n<li>Per la comunicazione asincrona: i messaggi in arrivo \u2014 l'endpoint controlla il bus per la presenza di messaggi di test e restituisce lo stato di elaborazione. <\/li>\n<li>Per la comunicazione asincrona: i messaggi in uscita \u2014 l'endpoint invia messaggi di test sul bus.<\/li>\n<\/ul>\n<p>\nCome avviene di solito: abbiamo un servizio che invia dati sul bus. Andiamo a questo servizio e chiediamo di parlarci della sua salute di integrazione. E se il servizio deve produrre un certo messaggio a un altro luogo (WebApp), allora produce quel messaggio di test. E se tiriamo il servizio dal lato di OrderProcessing, prima posta ci\u00f2 che pu\u00f2 postare in modo indipendente, e se ci sono delle cose dipendenti \u2014 legge dal bus un insieme di messaggi di test, comprende cosa pu\u00f2 elaborare, comunica questo e, se necessario, li posta ulteriormente, e di questo dice \u2014 va tutto bene, sono vivo. <\/p>\n<p>Spesso sentiamo la domanda \u201ccome possiamo testare questi dati in produzione?\u201d Ad esempio, parliamo dello stesso servizio ordini. Un ordine invia messaggi al magazzino, dove i prodotti vengono detratti: non possiamo testare questo sui dati reali, perch\u00e9 \u201ci miei prodotti verranno detratti!\u201d La soluzione: nella fase iniziale pianificare tutto questo test. Hai gi\u00e0 unit test che creano mock. Quindi, fallo a un livello pi\u00f9 profondo, dove avrai un canale di comunicazione che non danneggia l'operativit\u00e0 del business. <\/p>\n<h3>Livello infrastrutturale<\/h3>\n<p>\nIl monitoraggio dell'infrastruttura \u00e8 ci\u00f2 che da tempo viene considerato il monitoraggio stesso. <\/p>\n<ul>\n<li>\u00c8 possibile e necessario avviare il monitoraggio dell'infrastruttura come processo separato.<\/li>\n<li>Non dovresti iniziare con il monitoraggio dell'infrastruttura in un progetto attivo, anche se lo vuoi fortemente. \u00c8 una questione comune per tutti i DevOps. \u201cInizier\u00f2 a monitorare il cluster, monitorer\u00f2 l'infrastruttura\u201d \u2013 cio\u00e8, prima monitorer\u00f2 ci\u00f2 che \u00e8 sotto, senza addentrarmi nell'applicazione. Perch\u00e9 l'applicazione \u00e8 qualcosa di sconosciuto per i DevOps. \u00c8 stata passata a lui e non capisce come funziona. Ma l'infrastruttura, quella la capisce e inizia da l\u00ec. Ma no, \u00e8 sempre necessario monitorare prima l'applicazione. <\/li>\n<li>Non esagerare con il numero di avvisi. Considerando la complessit\u00e0 dei sistemi moderni, gli alert arrivano continuamente e bisogna in qualche modo convivere con questa miriade di alert. E chi \u00e8 di guardia, guardando un centinaio di alert, penser\u00e0 \u201cnon voglio pensarci\u201d. Gli avvisi devono segnalare solo le cose critiche. <\/li>\n<\/ul>\n<p><\/p>\n<h3>Livello dell'applicazione come unit\u00e0 commerciale<\/h3>\n<p>\nPunti chiave:<\/p>\n<ul>\n<li>ELK. Questo \u00e8 uno standard industriale. Se per qualche motivo non stai aggregando i log, inizia a farlo subito.<\/li>\n<li>APM. APM esterni come mezzo per chiudere rapidamente il monitoraggio dell'applicazione (NewRelic, BlackFire, Datadog). Puoi temporaneamente installare questo strumento, per avere almeno un'idea di cosa sta succedendo. <\/li>\n<li>Tracing. In dozzine di microservizi devi tracciare tutto, perch\u00e9 la richiesta non vive pi\u00f9 da sola. Aggiungere in seguito \u00e8 molto difficile, quindi \u00e8 meglio pianificare subito il tracing nello sviluppo \u2013 \u00e8 lavoro e strumento per gli sviluppatori. Se non lo hai gi\u00e0 implementato, fallo! Vedi Jaeger\/Zipkin.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Alerting<\/h3>\n<p><\/p>\n<ul>\n<li>Organizzazione del sistema di avvisi: in condizioni di monitoraggio di un certo numero di oggetti deve esserci un'unica sistema di invio di avvisi. Pu\u00f2 essere in Grafana. In Occidente, tutti usano PagerDuty. Gli avvisi devono essere chiari (ad esempio, da dove provengono\u2026). Ed \u00e8 desiderabile controllare che gli avvisi arrivino effettivamente. <\/li>\n<li>Organizzazione del sistema di turni: gli avvisi non devono arrivare a tutti (altrimenti tutti reagiranno in massa oppure nessuno reagir\u00e0). I sviluppatori devono essere inclusi nella turnistica: \u00e8 fondamentale definire le aree di responsabilit\u00e0, creare un'istruzione chiara e indicare a chi telefonare il luned\u00ec e il mercoled\u00ec, e a chi il marted\u00ec e il venerd\u00ec (altrimenti non chiameranno nessuno nemmeno in caso di grande crisi \u2014 temeranno di svegliare, disturbare: le persone in generale non amano chiamare e svegliare gli altri, soprattutto di notte). E spiegate che chiedere aiuto non \u00e8 un segno di incompetenza (\"chiedo aiuto \u2014 quindi sono un cattivo lavoratore\"), incoraggiate le richieste di aiuto.<\/li>\n<li>Organizzazione della \"base di conoscenze\" e del workflow per la gestione degli incidenti: per ogni serio incidente deve essere pianificato un post-mortem, come misura temporanea devono essere registrate le azioni che risolveranno l'incidente. E avviate la pratica che gli avvisi ripetuti sono un peccato; devono essere corretti nel codice o in lavori infrastrutturali. <\/li>\n<\/ul>\n<p><\/p>\n<h3>Stack tecnologico<\/h3>\n<p>\nImmaginiamo che il nostro stack sia il seguente: <\/p>\n<ul>\n<li>raccolta dei dati \u2014 Prometheus + Grafana;<\/li>\n<li>analisi dei log \u2014 ELK;<\/li>\n<li>per APM o Tracing \u2014 Jaeger (Zipkin).<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Monitoraggio morto? \u2014 Lunga vita al monitoraggio\" src=\"\/wp-content\/uploads\/2019\/04\/af26d3c0ba781cd856d220515788b5eb.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa scelta delle opzioni non \u00e8 critica. Perch\u00e9, se all'inizio hai compreso come monitorare il sistema e hai delineato un piano, poi inizi a scegliere gli strumenti in base alle tue esigenze. La questione \u00e8 quale hai scelto di monitorare all'inizio. Perch\u00e9, forse, lo strumento che hai scelto all'inizio non \u00e8 affatto adatto alle tue esigenze. <\/p>\n<p>Alcuni aspetti tecnici che vedo ovunque ultimamente:<\/p>\n<p><i>Prometheus viene inserito all'interno di Kubernetes \u2014 chi l'ha pensato?!<\/i> Se il tuo cluster va in crash, cosa farai? Se hai un cluster complesso all'interno, deve funzionare un certo sistema di monitoraggio all'interno del cluster, e un altro sistema \u2014 all'esterno, che raccoglier\u00e0 dati da dentro il cluster. <\/p>\n<p><i>All'interno del cluster raccogliamo log e tutto il resto.<\/i> Ma il sistema di monitoraggio deve essere all'esterno. Molto spesso, nel cluster dove c'\u00e8 Prometheus installato internamente, ci sono anche sistemi che effettuano verifiche esterne del funzionamento del sito. E se la tua connessione con il mondo esterno cade e l'applicazione non funziona? Risultato: internamente va tutto bene, ma per gli utenti non \u00e8 facile.<\/p>\n<h3>Conclusioni<\/h3>\n<p><\/p>\n<ul>\n<li>Sviluppare il monitoraggio non significa installare utility, ma sviluppare un prodotto software. Il 98% del monitoraggio attuale consiste in coding. Coding nei servizi, coding delle verifiche esterne, controlli dei servizi esterni, e tanto altro. <\/li>\n<li>Non risparmiate il tempo degli sviluppatori per il monitoraggio: pu\u00f2 assorbire fino al 30% del loro lavoro, ma ne vale la pena.<\/li>\n<li>DevOps, non preoccupatevi se non riuscite a monitorare qualcosa, perch\u00e9 alcune cose richiedono un altro tipo di mentalit\u00e0. Non eravate programmatori, e il lavoro di monitoraggio \u00e8 proprio quello degli sviluppatori.<\/li>\n<li>Se il progetto \u00e8 gi\u00e0 operativo e non \u00e8 monitorato (e voi siete un manager) - allocate risorse per il monitoraggio.<\/li>\n<li>Se il prodotto \u00e8 gi\u00e0 in produzione e voi siete un DevOps a cui \u00e8 stato detto di 'configurare il monitoraggio' - cercate di spiegare alla direzione ci\u00f2 di cui ho parlato.<\/li>\n<\/ul>\n<p>\n<i>Questa \u00e8 una versione estesa della relazione presentata alla conferenza Saint Highload++.<\/i><\/p>\n<p>Se siete interessati alle mie idee e riflessioni sull'IT e temi correlati, potete <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/eapotapov_channel\">leggere il canale <\/a><\/noindex>\ud83d\ude42<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/448602\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041d\u0430\u0448\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f \u0441 2008 \u0433\u043e\u0434\u0430 \u0437\u0430\u043d\u0438\u043c\u0430\u0435\u0442\u0441\u044f \u043f\u0440\u0435\u0438\u043c\u0443\u0449\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435\u043c \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430\u043c\u0438 \u0438 \u043a\u0440\u0443\u0433\u043b\u043e\u0441\u0443\u0442\u043e\u0447\u043d\u043e\u0439 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u043e\u0439 \u0432\u0435\u0431-\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432: \u0443 \u043d\u0430\u0441 \u0431\u043e\u043b\u0435\u0435 400 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432, \u044d\u0442\u043e \u043f\u043e\u0440\u044f\u0434\u043a\u0430 15% \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u043d\u043d\u043e\u0439 \u043a\u043e\u043c\u043c\u0435\u0440\u0446\u0438\u0438 \u0420\u043e\u0441\u0441\u0438\u0438. \u0421\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u043d\u043e, \u043d\u0430 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0435 \u043e\u0447\u0435\u043d\u044c \u0440\u0430\u0437\u043d\u043e\u043e\u0431\u0440\u0430\u0437\u043d\u0430\u044f \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0430. \u0415\u0441\u043b\u0438 \u0447\u0442\u043e-\u0442\u043e \u043f\u0430\u0434\u0430\u0435\u0442, \u043c\u044b \u043e\u0431\u044f\u0437\u0430\u043d\u044b \u0432 \u0442\u0435\u0447\u0435\u043d\u0438\u0435 15 \u043c\u0438\u043d\u0443\u0442 \u044d\u0442\u043e \u043f\u043e\u0447\u0438\u043d\u0438\u0442\u044c. \u041d\u043e \u0447\u0442\u043e\u0431\u044b \u043f\u043e\u043d\u044f\u0442\u044c, \u0447\u0442\u043e \u0430\u0432\u0430\u0440\u0438\u044f \u043f\u0440\u043e\u0438\u0437\u043e\u0448\u043b\u0430, \u043d\u0443\u0436\u043d\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u0442\u044c \u043f\u0440\u043e\u0435\u043a\u0442 \u0438 \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u0438\u043d\u0446\u0438\u0434\u0435\u043d\u0442\u044b. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":23731,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31864","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 \u043c\u0451\u0440\u0442\u0432? \u2014 \u0414\u0430 \u0437\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0435\u0442 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:43:33+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:43:33+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Il monitoraggio \u00e8 morto? - Lunga vita al monitoraggio | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 \u043c\u0451\u0440\u0442\u0432? \u2014 \u0414\u0430 \u0437\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0435\u0442 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 | ProHoster","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:43:33+00:00","article:modified_time":"2019-10-31T18:43:33+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31864","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 17:01:09","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:09:27","updated":"2026-02-09 17:01:09","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/31864","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=31864"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/31864\/revisions"}],"predecessor-version":[{"id":158558,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/31864\/revisions\/158558"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/23731"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=31864"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=31864"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=31864"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}