{"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\/nl\/blog\/administrirovanie\/eshhe-odna-sistema-monitoringa","title":{"rendered":"Nog een monitorsprakend systeem","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Nog
\n16 modems, 4 mobiele operators = Uitgaande snelheid 933,45 Mbit\/s<\/em> <\/p>\n

<\/p>\n

Inleiding<\/h2>\n

<\/p>\n

Hallo! Dit is een artikel over hoe we onszelf een nieuw monitoring systeem hebben geschreven. Het verschilt van de bestaande systemen doordat het de mogelijkheid biedt voor hoogfrequente synchronisatie van metriekgegevens en een zeer laag verbruik van middelen. De pollfrequentie kan 0,1 milliseconde bereiken met een synchronisatieprecisie tussen de metriek van 10 nanoseconden. Alle binaire bestanden nemen 6 megabyte in beslag. <\/p>\n

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

Over het project<\/h2>\n

<\/p>\n

We have a rather specific product. We offer a comprehensive solution for aggregating bandwidth and fault tolerance of data transmission channels. This is when there are several channels, for example, Operator1 (40 Mbps) + Operator2 (30 Mbps) + Something else (5 Mbps), resulting in one stable and fast channel with a speed of approximately: (40+30+5)x0.92=75×0.92=69 Mbps. <\/p>\n

<\/p>\n

Dergelijke oplossingen zijn gewild waar de capaciteit van elk afzonderlijk kanaal onvoldoende is. Bijvoorbeeld in transport, bewakingssystemen en realtime streaming van video's, live uitzendingen van televisie- en radio-uitzendingen, elke landelijke locatie waar alleen vertegenwoordigers van de grote vier telecommunicatiebedrijven zijn en de snelheid op \u00e9\u00e9n modem\/kanaal onvoldoende is.
\nVoor elk van deze richtingen brengen we een aparte lijn van apparaten uit, maar de softwarecomponent is bijna identiek en een kwaliteitsmonitoringsysteem is een van de belangrijkste modules. Zonder de juiste implementatie daarvan zou het product onmogelijk zijn.<\/p>\n

<\/p>\n

In de loop van de jaren zijn we erin geslaagd een meerlaagse, snelle, cross-platform en lichtgewicht monitoring systeem te cre\u00ebren. Dit willen we graag delen met de gewaardeerde gemeenschap.<\/p>\n

<\/p>\n

Taakstelling<\/h2>\n

<\/p>\n

Het monitoring systeem zorgt voor het verkrijgen van metriekgegevens van twee fundamenteel verschillende klassen: realtime metriek en alle andere. Het monitoringsysteem had slechts de volgende vereisten:<\/p>\n

<\/p>\n

    \n
  1. Hoogfrequente synchronisatie van realtime metriek en overdracht naar het communicatiebeheersysteem zonder vertraging.
    \nEen hoge frequentie en synchronisatie van verschillende metrics is niet alleen belangrijk, maar absoluut noodzakelijk voor de analyse van de entropie van datatransmissiekanalen. Als de gemiddelde vertraging in \u00e9\u00e9n datatransmissiekanaal 30 milliseconden bedraagt, zal een synchronisatiefout van slechts \u00e9\u00e9n milliseconde tussen de overige metrics leiden tot een snelheidsdegradatie van ongeveer 5% van het resultaatkanaal. Als we de synchronisatie in 4 kanalen met 1 milliseconde missen, kan de snelheid gemakkelijk met 30% verminderen. Bovendien verandert de entropie in de kanalen zeer snel, dus als deze minder vaak dan eens in de 0,5 milliseconde wordt gemeten, zullen we bij snelle kanalen met lage vertraging een hoge snelheidsdegradatie tegenkomen. Uiteraard is een dergelijke precisie niet voor alle metrics en niet onder alle omstandigheden nodig. Wanneer de vertraging in een kanaal 500 milliseconden is, en we werken ook met dergelijke, is een fout van 1 milliseconde vrijwel onopgemerkt. Eveneens volstaat voor de metrics van vitale systemen een polling- en synchronisatiefrequentie van 2 seconden, maar het monitoringsysteem zelf moet in staat zijn om met zeer hoge pollingfrequenties en uiterst nauwkeurige metricsynchronisatie te werken.<\/li>\n
  2. Minimale middelen en een uniforme stack.
    \nHet eindapparaat kan zowel een krachtige boordcomputer zijn die de situatie op de weg analyseert of biometrische gegevens van mensen vastlegt, als een single-board computer ter grootte van een hand die een speciale eenheid onder een kogelwerend vest draagt om real-time video door te geven onder slechte verbindingseisen. Ondanks deze verscheidenheid aan architecturen en rekencapaciteiten willen wij een uniforme softwarestack hebben.<\/li>\n
  3. Umbrella-architectuur
    \nMetrics moeten verzameld en geaggregeerd worden op het eindapparaat, met een lokaal opslagsysteem en visualisatie in real-time en retrospectief. Bij aanwezigheid van een verbinding moeten de gegevens naar het centrale monitoring systeem worden verzonden. Wanneer er geen verbinding is, moet de verzendwachtrij zich ophopen en geen RAM gebruiken. <\/li>\n
  4. API voor integratie in het monitoring systeem van de klant, omdat niemand behoefte heeft aan meerdere monitoring systemen. De klant moet gegevens van alle apparaten en netwerken in \u00e9\u00e9n monitoringsysteem verzamelen.<\/li>\n<\/ol>\n

    <\/p>\n

    Wat we hebben verkregen<\/h2>\n

    <\/p>\n

    Om de al uitgebreide longread niet te belasten, zal ik geen voorbeelden en metingen van alle monitoringsystemen geven. Dat zou een extra artikel vereisen. Ik zal gewoon zeggen dat we geen monitoringsysteem konden vinden dat in staat is om twee metrics tegelijkertijd te meten met een foutmarge van minder dan 1 milliseconde, en dat zowel op ARM-architectuur met 64 MB RAM als op x86_64-architectuur met 32 GB RAM even effectief werkt. Daarom hebben we besloten om de onze te schrijven, die in staat is om dit alles te doen. Dit is wat we hebben bereikt:<\/p>\n

    <\/p>\n

    Som van de bandbreedte van drie kanalen voor verschillende netwerktopologie\u00ebn<\/h3>\n

    \n

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

    Visualisatie van enkele belangrijke metrics<\/h3>\n

    \n\"Nog
    \n\"Nog
    \n\"Nog
    \n\"Nog<\/p>\n

    Architectuur<\/h2>\n

    <\/p>\n

    Als primaire programmeertaal, zowel op het apparaat als in de datacenters, gebruiken we Golang. Het heeft ons leven aanzienlijk vereenvoudigd door de implementatie van multitasking en de mogelijkheid om \u00e9\u00e9n statisch gelinkte uitvoerbare binaire bestand voor elke service te genereren. Hierdoor besparen we aanzienlijk op middelen, methoden en dataverkeer bij de deployment van services naar eindapparaten, en ook op ontwikkel- en debugtijd van de code. <\/p>\n

    <\/p>\n

    Het systeem is gerealiseerd op basis van het klassieke modulaire principe en bevat verschillende subsysteemcomponenten:<\/p>\n

    <\/p>\n

      \n
    1. Registratie van metrics.
      \nElke metric wordt beheerd door een eigen thread en wordt gesynchroniseerd via kanalen. We hebben een synchronisatieprecisie van tot 10 nanoseconden weten te bereiken.<\/li>\n
    2. Opslag van metrics
      \nWij stonden voor de keuze om onze eigen opslag voor tijdreeksen te schrijven of iets bestaands te gebruiken. De database is nodig voor retrospectieve gegevens die voor latere visualisatie moeten worden gebruikt. Dat wil zeggen, er zijn geen gegevens over vertragingen in het kanaal elke 0,5 milliseconden of foutmeldingen in het transportsysteem, maar er is snelheid op elke interface elke 500 milliseconden. Naast de hoge eisen voor cross-platform compatibiliteit en laag verbruik van middelen, is het voor ons van cruciaal belang om de gegevens daar te kunnen verwerken waar ze worden opgeslagen. Dit bespaart enorm op rekenkracht. Sinds 2016 gebruiken we de database Tarantool in dit project en tot nu toe zien we geen vervanging daarvoor in de nabije toekomst. Flexibel, met een optimaal middelenverbruik en meer dan voldoende ondersteuning. Daarnaast heeft Tarantool een GIS-module. Deze is natuurlijk niet zo krachtig als PostGIS, maar voldoende voor onze behoeften bij het opslaan van enkele metriek verbonden aan locaties (relevant voor transport). <\/li>\n
    3. Visualisatie van metriek
      \nHier is alles relatief eenvoudig. We halen gegevens uit de opslag en tonen ze ofwel in realtime of retrospectief. <\/li>\n
    4. Synchronisatie van gegevens met het centrale monitoringsysteem.
      \nThe central monitoring system receives data from all devices, stores it with a specified retention period, and provides it to the Client's monitoring system via API. Unlike traditional monitoring systems, where a 'head' moves around to collect data \u2014 we have the opposite scheme. Devices send data themselves when they have a connection. This is a very important point, as it allows us to obtain data from the device during the times it was unavailable and avoids overloading channels and resources when the device is unreachable. For the central monitoring system, we use the Influx monitoring server. Unlike its counterparts, it can import retrospective data (i.e., data with a timestamp different from the moment of metric retrieval). The collected metrics are visualized using a refined version of Grafana. This standard stack was also chosen because it has ready-made API integrations practically with any of the client's monitoring systems.<\/li>\n
    5. Synchronisatie van gegevens met het centrale apparaatbeheer systeem.
      \nHet apparaatbeheersysteem implementeert Zero Touch Provisioning (firmware-updates, configuraties, enz.) en ontvangt in tegenstelling tot het monitoringssysteem alleen meldingen van problemen met apparaten. Dit zijn triggers voor de werking van interne hardware-bewakingsservices en alle metrics van de levensondersteunende systemen: temperatuur van de CPU en SSD, CPU-belasting, vrije ruimte en S.M.A.R.T. gezondheid van de schijven. De opslag van de subsysteem is ook gebouwd op Tarantool. Dit stelt ons in staat om aanzienlijke snelheid te behalen bij het aggregeren van tijdreeksen van duizenden apparaten, en lost volledig het probleem van gegevenssynchronisatie met deze apparaten op. Tarantool beschikt over een uitstekend queuesysteem en gegarandeerde levering. Deze belangrijke functie hebben we direct uit de doos gekregen, prachtig!<\/li>\n<\/ol>\n

      <\/p>\n

      Netwerkbeheersysteem<\/h3>\n

      \n\"Nog<\/p>\n

      Hier was eigenlijk een praktische sectie gepland met demonstratie van drie projecten op STM32 en STM8, speciaal voor dit artikel gemaakt met behulp van datasheets, met lampen, SPI, timers, PWM en interrupts:<\/h2>\n

      <\/p>\n

      Op dit moment is ons zwakste punt het centrale monitoringssysteem. Dit is voor 99,9% gerealiseerd op een standaard stack en heeft een aantal tekortkomingen:<\/p>\n

      <\/p>\n

        \n
      1. InfluxDB verliest gegevens bij stroomuitval. Gewoonlijk haalt de klant snel alles op wat van de apparaten komt en in de database zijn geen gegevens ouder dan 5 minuten, maar in de toekomst kan dit een probleem worden.<\/li>\n
      2. Grafana heeft een aantal problemen met de aggregatie van gegevens en de synchroniciteit van hun weergave. Het meest voorkomende probleem is wanneer er een tijdreeks in de database staat met een interval van 2 seconden, beginnend vanaf bijvoorbeeld 00:00:00, maar Grafana begint gegevens te tonen in aggregatie met +1 seconde. Als resultaat ziet de gebruiker een onregelmatige grafiek.<\/li>\n
      3. Overmatige hoeveelheid code voor API-integratie met externe monitoringsystemen. Dit kan veel compacter worden gemaakt en natuurlijk herschreven in Go :)<\/li>\n<\/ol>\n

        <\/p>\n

        Ik neem aan dat jullie allemaal wel weten hoe Grafana eruitziet en haar problemen zonder mijn tussenkomst, daarom zal ik de post niet belasten met afbeeldingen.<\/p>\n

        <\/p>\n

        Conclusie<\/h2>\n

        <\/p>\n

        Ik heb bewust ervoor gekozen om geen technische details te beschrijven, maar alleen het basisontwerp van dit systeem. Ten eerste, om het systeem technisch volledig te beschrijven, zou een ander artikel nodig zijn. Ten tweede zal dit niet voor iedereen interessant zijn. Laat in de comments weten welke technische details je graag zou willen weten. <\/p>\n

        <\/p>\n

        Als iemand vragen heeft buiten dit artikel, kan je me bereiken op a.rodin @ qedr.com<\/p>\n

        Bron: 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\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\udd47Nog een monitoringsysteem | ProHoster","description":"16 modems, 4 mobiele operators = Uitgaande snelheid 933,45.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/eshhe-odna-sistema-monitoringa","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/33632","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=33632"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/33632\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/25323"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=33632"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=33632"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=33632"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}