{"id":33632,"date":"2019-10-31T21:53:52","date_gmt":"2019-10-31T18:53:52","guid":{"rendered":"https:\/\/prohoster.info\/blog\/eshhe-odna-sistema-monitoringa\/"},"modified":"2019-10-31T21:53:52","modified_gmt":"2019-10-31T18:53:52","slug":"eshhe-odna-sistema-monitoringa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/eshhe-odna-sistema-monitoringa","title":{"rendered":"Un altro sistema di monitoraggio","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Un
\n16 modem, 4 operatori mobili = Velocit\u00e0 in uscita 933.45 Mbit\/s<\/em> <\/p>\n

<\/p>\n

Introduzione<\/h2>\n

<\/p>\n

Ciao! Questo \u00e8 un articolo su come abbiamo sviluppato un nuovo sistema di monitoraggio. Si distingue da quelli esistenti per la possibilit\u00e0 di ottenere metriche ad alta frequenza in modo sincrono e per il suo bassissimo consumo di risorse. La frequenza di interrogazione pu\u00f2 arrivare a 0.1 millisecondi con una precisione di sincronizzazione tra le metriche di 10 nanosecondi. Tutti i file binari occupano 6 megabyte. <\/p>\n

<\/a><\/noindex><\/p>\n

Il progetto<\/h2>\n

<\/p>\n

Abbiamo un prodotto piuttosto specifico. Produciamo una soluzione completa per il sommario della larghezza di banda e la tolleranza ai guasti dei canali di trasmissione dei dati. \u00c8 quando ci sono diversi canali, ad esempio Operatore1 (40 Mbit\/s) + Operatore2 (30 Mbit\/s) + Qualcosa d'altro (5 Mbit\/s); il risultato \u00e8 un unico canale stabile e veloce, la cui velocit\u00e0 sar\u00e0 circa: (40+30+5)x0.92=75×0.92=69 Mbit\/s. <\/p>\n

<\/p>\n

Queste soluzioni sono richieste dove la capacit\u00e0 di un singolo canale non \u00e8 sufficiente. Ad esempio, nei trasporti, nei sistemi di videosorveglianza e nelle trasmissioni video in tempo reale, per le trasmissioni in diretta di programmi televisivi e radiofonici, in qualsiasi luogo isolato dove gli operatori di telecomunicazione sono solo rappresentanti delle big four e le velocit\u00e0 su un modem\/canale non sono sufficienti.
\nPer ciascuno di questi settori produciamo una linea separata di dispositivi, tuttavia la loro parte software \u00e8 quasi identica e un sistema di monitoraggio di qualit\u00e0 \u00e8 uno dei suoi moduli principali, senza una corretta implementazione, il prodotto sarebbe impossibile.<\/p>\n

<\/p>\n

In pochi anni, siamo riusciti a creare un sistema di monitoraggio multilivello, veloce, multipiattaforma e leggero. Questo \u00e8 ci\u00f2 che vogliamo condividere con la rispettata comunit\u00e0.<\/p>\n

<\/p>\n

Definizione del compito<\/h2>\n

<\/p>\n

Il sistema di monitoraggio garantisce l'ottenimento di metriche di due classi fondamentalmente diverse: metriche in tempo reale e tutte le altre. Al sistema di monitoraggio sono state poste solo le seguenti richieste:<\/p>\n

<\/p>\n

    \n
  1. Ricezione sincrona di metriche in tempo reale ad alta frequenza e loro trasmissione al sistema di gestione della comunicazione senza ritardi.
    \nUn'alta frequenza e la sincronizzazione di diverse metriche non sono semplicemente importanti, ma sono vitali per analizzare l'entropia dei canali di trasmissione dati. Se in un canale di trasmissione dati il ritardo medio \u00e8 di 30 millisecondi, un errore di sincronizzazione tra le altre metriche di solo un millisecondo porter\u00e0 a una degradazione della velocit\u00e0 del canale risultante di circa il 5%. Se sbagliamo nella sincronizzazione di 1 millisecondo in 4 canali, la degradazione della velocit\u00e0 potrebbe scendere fino al 30%. Inoltre, l'entropia nei canali cambia molto rapidamente, quindi se la misuriamo meno di una volta ogni 0,5 millisecondi, nei canali veloci con bassa latenza otterremo un'alta degradazione della velocit\u00e0. Ovviamente, tale precisione non \u00e8 necessaria per tutte le metriche e in tutte le condizioni. Quando la latenza nel canale sar\u00e0 di 500 millisecondi, e lavoriamo anche con tali canali, un errore di 1 millisecondo sar\u00e0 quasi impercettibile. Inoltre, per le metriche dei sistemi di supporto vitale, ci basta una frequenza di polling e sincronizzazione di 2 secondi, tuttavia il sistema di monitoraggio stesso deve essere in grado di lavorare con frequenze di polling estremamente elevate e sincronizzazioni estremamente precise delle metriche.<\/li>\n
  2. Minimo consumo di risorse e stack unificato.
    \nIl dispositivo finale pu\u00f2 rappresentare sia un potente complesso di bordo, in grado di analizzare la situazione sulla strada o di eseguire la registrazione biometrica delle persone, sia un computer a scheda singola delle dimensioni di un palmo, che un soldato delle forze speciali porta sotto il giubbotto antiproiettile per trasmettere video in tempo reale in condizioni di cattiva connettivit\u00e0. Nonostante questa variet\u00e0 di architetture e potenze di calcolo, ci piacerebbe avere uno stack software uniforme.<\/li>\n
  3. Architettura a ombrello
    \nLe metriche devono essere raccolte e aggregate sul dispositivo finale, avere un sistema di archiviazione locale e visualizzazione in tempo reale e retrospettiva. In caso di connettivit\u00e0 \u2014 i dati devono essere trasmessi al sistema centrale di monitoraggio. Quando non c'\u00e8 connessione \u2014 la coda per l'invio deve accumularsi e non consumare memoria operativa. <\/li>\n
  4. API per l'integrazione nel sistema di monitoraggio del cliente, perch\u00e9 a nessuno servono molti sistemi di monitoraggio. Il cliente deve raccogliere dati da qualsiasi dispositivo e rete in un unico monitoraggio.<\/li>\n<\/ol>\n

    <\/p>\n

    Risultato ottenuto<\/h2>\n

    <\/p>\n

    Per non sovraccaricare ulteriormente questo lungo articolo, non fornir\u00f2 esempi e misurazioni di tutti i sistemi di monitoraggio. Questo richiederebbe un altro articolo. Dir\u00f2 solo che non siamo riusciti a trovare un sistema di monitoraggio in grado di acquisire simultaneamente due metriche con un errore inferiore a 1 millisecondo e che funzioni altrettanto bene sia su architettura ARM con 64MB di RAM, sia su architettura x86_64 con 32GB di RAM. Pertanto, abbiamo deciso di scrivere il nostro, in grado di fare tutto questo. Ecco cosa abbiamo ottenuto:<\/p>\n

    <\/p>\n

    Sommatoria della larghezza di banda di tre canali per diverse topologie di rete<\/h3>\n

    \n

    \r\n \"Guarda\r\n
    <\/div>\r\n <\/div><\/center>
    \n
    \r\n \"Guarda\r\n
    <\/div>\r\n <\/div><\/center><\/p>\n

    Visualizzazione di alcune metriche chiave<\/h3>\n

    \n\"Un
    \n\"Un
    \n\"Un
    \n\"Un<\/p>\n

    Architettura<\/h2>\n

    <\/p>\n

    Come linguaggio di programmazione principale, sia sui dispositivi che nei data center, utilizziamo Golang. Questo ha semplificato notevolmente la vita grazie alla sua implementazione del multithreading e alla possibilit\u00e0 di ottenere un singolo file binario eseguibile staticamente collegato per ciascun servizio. Di conseguenza, risparmiamo notevolmente in risorse, metodi e traffico nella distribuzione del servizio sui dispositivi finali, nonch\u00e9 nel tempo di sviluppo e debug del codice. <\/p>\n

    <\/p>\n

    Il sistema \u00e8 stato implementato secondo un classico principio modulare e comprende diverse sottosistemi:<\/p>\n

    <\/p>\n

      \n
    1. Registrazione delle metriche.
      \nOgni metrica \u00e8 gestita da un proprio thread e sincronizzata tramite canali. Siamo riusciti a ottenere una precisione di sincronizzazione fino a 10 nanosecondi.<\/li>\n
    2. Archiviazione delle metriche
      \nAbbiamo valutato se scrivere il nostro repository per le serie temporali o utilizzare qualcosa di esistente. Il database \u00e8 necessario per i dati retrospettivi, che saranno successivamente visualizzati. Cio\u00e8, non contiene dati sui ritardi nel canale ogni 0,5 millisecondi o sui messaggi di errore nella rete di trasporto, ma registra la velocit\u00e0 su ogni interfaccia ogni 500 millisecondi. Oltre all'alta necessit\u00e0 di compatibilit\u00e0 cross-platform e a un basso consumo di risorse, \u00e8 per noi estremamente importante poter elaborare i dati l\u00e0 dove vengono memorizzati. Questo riduce notevolmente il consumo di risorse computazionali. Da quando abbiamo iniziato nel 2016, utilizziamo il database Tarantool per questo progetto e non vediamo ancora alternative all'orizzonte. \u00c8 flessibile, con un consumo di risorse ottimale e un supporto tecnico pi\u00f9 che adeguato. Inoltre, Tarantool implementa un modulo GIS. Certo, non \u00e8 potente come PostGIS, ma \u00e8 sufficiente per le nostre esigenze di archiviazione di alcune metriche legate alla posizione (importante per i trasporti). <\/li>\n
    3. Visualizzazione delle metriche
      \nQui \u00e8 tutto relativamente semplice. Prendiamo i dati dal repository e li mostriamo sia in tempo reale che retrospettivamente. <\/li>\n
    4. Sincronizzazione dei dati con il sistema centrale di monitoraggio.
      \nIl sistema centrale di monitoraggio raccoglie i dati da tutti i dispositivi, li memorizza con il periodo di retrospettiva impostato e attraverso API li restituisce al sistema di monitoraggio del Cliente. A differenza dei sistemi di monitoraggio classici, in cui la «testa» si muove e raccoglie i dati \u2014 nel nostro caso funziona al contrario. I dispositivi inviano i dati da soli quando c'\u00e8 connessione. Questo \u00e8 un punto molto importante, poich\u00e9 consente di ottenere dati dai dispositivi nei periodi di tempo in cui non erano disponibili e di non sovraccaricare i canali e le risorse quando il dispositivo non \u00e8 accessibile. Come sistema centrale di monitoraggio utilizziamo il server di monitoraggio Influx. A differenza degli analoghi, \u00e8 in grado di importare dati retrospettivi (cio\u00e8 con un timestamp diverso dal momento in cui viene ricevuta la metrica). Le metriche raccolte vengono visualizzate da un Grafana rifinito. Questo stack standard \u00e8 stato scelto anche perch\u00e9 ha API di integrazione pronte praticamente per qualsiasi sistema di monitoraggio del cliente.<\/li>\n
    5. Sincronizzazione dei dati con il sistema centrale di gestione dei dispositivi.
      \nIl sistema di gestione dei dispositivi implementa il Zero Touch Provisioning (aggiornamento del firmware, configurazione, ecc.) e, a differenza del sistema di monitoraggio, riceve solo problemi dai dispositivi. Questi sono i trigger per il funzionamento dei servizi di sorveglianza hardware di bordo e tutte le metriche dei sistemi di supporto vitale: temperatura della CPU e dell'SSD, carico della CPU, spazio libero e stato S.M.A.R.T dei dischi. Lo storage della sottosistema \u00e8 costruito anch'esso su Tarantool. Questo ci offre una notevole velocit\u00e0 nell'aggregazione delle serie temporali su migliaia di dispositivi, e risolve completamente il problema della sincronizzazione dei dati con questi dispositivi. Tarantool ha un'eccellente sistema di code e consegna garantita. Abbiamo ricevuto questa importante funzionalit\u00e0 pronta all'uso, fantastico!<\/li>\n<\/ol>\n

      <\/p>\n

      Sistema di gestione della rete<\/h3>\n

      \n\"Un<\/p>\n

      E ora?<\/h2>\n

      <\/p>\n

      Attualmente, il nostro punto pi\u00f9 debole \u00e8 il sistema centrale di monitoraggio. \u00c8 implementato al 99,9% su un stack standard e presenta una serie di svantaggi:<\/p>\n

      <\/p>\n

        \n
      1. InfluxDB perde dati in caso di mancanza di alimentazione. Di solito, il cliente raccoglie rapidamente tutto ci\u00f2 che riceve dai dispositivi e nel database non ci sono dati pi\u00f9 vecchi di 5 minuti, tuttavia, in futuro questo potrebbe diventare un problema.<\/li>\n
      2. Grafana ha una serie di problemi con l'aggregazione dei dati e la sincronizzazione della loro visualizzazione. Il problema pi\u00f9 comune \u00e8 quando nel database c'\u00e8 una serie temporale con un intervallo di 2 secondi a partire da ad esempio le 00:00:00, mentre Grafana inizia a mostrare i dati in aggregazione con +1 secondo. Di conseguenza, l'utente vede un grafico a zig-zag.<\/li>\n
      3. Eccesso di codice per l'integrazione API con sistemi di monitoraggio di terze parti. Pu\u00f2 essere reso molto pi\u00f9 compatto e certamente riscritto in Go)<\/li>\n<\/ol>\n

        <\/p>\n

        Suppongo che tutti voi abbiate gi\u00e0 visto come appare Grafana e conoscete i suoi problemi, quindi non voglio sovraccaricare il post con immagini.<\/p>\n

        <\/p>\n

        Conclusione<\/h2>\n

        <\/p>\n

        Ho volutamente evitato di descrivere dettagli tecnici, limitandomi a delineare il design di base di questo sistema. In primo luogo, sarebbe necessaria un'altra articolo per descrivere tecnicamente il sistema in modo completo. In secondo luogo, non tutti potrebbero trovarlo interessante. Scrivete nei commenti quali dettagli tecnici vi piacerebbe sapere. <\/p>\n

        <\/p>\n

        Se qualcuno ha domande oltre a quest'articolo, pu\u00f2 contattarmi all'indirizzo a.rodin @ qedr.com<\/p>\n

        Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

        16 \u043c\u043e\u0434\u0435\u043c\u043e\u0432, 4 \u0441\u043e\u0442\u043e\u0432\u044b\u0445 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430= \u0418\u0441\u0445\u043e\u0434\u044f\u0449\u0430\u044f \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c 933.45 \u041c\u0431\u0438\u0442\/\u0441 \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u041f\u0440\u0438\u0432\u0435\u0442! \u042d\u0442\u043e \u0441\u0442\u0430\u0442\u044c\u044f \u043f\u0440\u043e \u0442\u043e, \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u043f\u0438\u0441\u0430\u043b\u0438 \u0434\u043b\u044f \u0441\u0435\u0431\u044f \u043d\u043e\u0432\u0443\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430. \u041e\u0442 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u043e\u043d\u0430 \u043e\u0442\u043b\u0438\u0447\u0430\u0435\u0442\u0441\u044f \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c\u044e \u0432\u044b\u0441\u043e\u043a\u043e\u0447\u0430\u0441\u0442\u043e\u0442\u043d\u043e\u0433\u043e \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u043d\u043e\u0433\u043e \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f \u043c\u0435\u0442\u0440\u0438\u043a \u0438 \u043e\u0447\u0435\u043d\u044c \u043c\u0430\u043b\u0435\u043d\u044c\u043a\u0438\u043c \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u0435\u043d\u0438\u0435\u043c \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432. \u0427\u0430\u0441\u0442\u043e\u0442\u0430 \u043e\u043f\u0440\u043e\u0441\u0430 \u043c\u043e\u0436\u0435\u0442 \u0434\u043e\u0441\u0442\u0438\u0433\u0430\u0442\u044c 0.1 \u043c\u0438\u043b\u043b\u0438\u0441\u0435\u043a\u0443\u043d\u0434\u044b \u0441 \u0442\u043e\u0447\u043d\u043e\u0441\u0442\u044c\u044e \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0435\u0442\u0440\u0438\u043a\u0430\u043c\u0438 \u0432 10 \u043d\u0430\u043d\u043e\u0441\u0435\u043a\u0443\u043d\u0434. \u0412\u0441\u0435 \u0431\u0438\u043d\u0430\u0440\u043d\u044b\u0435 \u0444\u0430\u0439\u043b\u044b \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25323,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33632","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Un altro sistema di monitoraggio | ProHoster","description":"16 modem, 4 operatori mobili = Velocit\u00e0 in uscita 933,45.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/eshhe-odna-sistema-monitoringa","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\u0415\u0449\u0435 \u043e\u0434\u043d\u0430 \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 | ProHoster","og:description":"16 \u043c\u043e\u0434\u0435\u043c\u043e\u0432, 4 \u0441\u043e\u0442\u043e\u0432\u044b\u0445 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430= \u0418\u0441\u0445\u043e\u0434\u044f\u0449\u0430\u044f \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c 933.45.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/eshhe-odna-sistema-monitoringa","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:53:52+00:00","article:modified_time":"2019-10-31T18:53:52+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33632","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-01-21 16:05:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:19:51","updated":"2026-01-21 16:05:20","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\/33632","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=33632"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/33632\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/25323"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=33632"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=33632"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=33632"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}