Laing sistema sa pagmonitor

16 modem, 4 cellular operators = Outgoing speed 933.45 Mbit/s

Pasiuna

Hello! Kini nga artikulo bahin sa kung giunsa namo pagsulat ang usa ka bag-ong sistema sa pag-monitor alang sa among kaugalingon. Lahi kini sa mga anaa na sa abilidad niini nga makakuha og high-frequency nga synchronous metrics ug ubos kaayo nga konsumo sa kapanguhaan. Ang polling rate mahimong moabot sa 0.1 milliseconds uban sa usa ka synchronization accuracy tali sa metrics sa 10 nanoseconds. Ang tanan nga binary nga mga file nag-okupar sa 6 megabytes.

Mahitungod sa proyekto

Kami adunay usa ka medyo piho nga produkto. Naghimo kami usa ka komprehensibo nga solusyon alang sa pag-summarize sa throughput ug pagtugot sa sayup sa mga channel sa transmission sa data. Kini kung adunay daghang mga kanal, ingnon ta ang Operator1 (40Mbit / s) + Operator2 (30Mbit / s) + Usa pa nga butang (5 Mbit / s), ang sangputanan usa ka lig-on ug paspas nga channel, ang katulin niini mahimong sama sa kini: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

Ang ingon nga mga solusyon gikinahanglan kung ang kapasidad sa bisan unsang usa ka channel dili igo. Pananglitan, ang transportasyon, mga sistema sa pagbantay sa video ug real-time nga video streaming, pagsibya sa live nga telebisyon ug mga sibya sa radyo, bisan unsang pasilidad sa suburban diin taliwala sa mga telecom operator adunay mga representante lamang sa Big Four ug ang katulin sa usa ka modem / channel dili igo. .
Alang sa matag usa niini nga mga lugar, naghimo kami usa ka lahi nga linya sa mga aparato, apan ang ilang bahin sa software hapit parehas ug usa ka taas nga kalidad nga sistema sa pag-monitor ang usa sa mga nag-unang module niini, kung wala ang husto nga pagpatuman diin ang produkto dili mahimo.

Sulod sa pipila ka mga tuig, nakahimo kami sa paghimo sa usa ka multi-level, paspas, cross-platform ug lightweight monitoring system. Kini ang gusto namong ipaambit sa among respetado nga komunidad.

Pagbuot sa problema

Ang sistema sa pagmonitor naghatag ug metrics sa duha ka sukaranang lainlain nga klase: real-time metrics ug uban pa. Ang sistema sa pagmonitor adunay lamang sa mosunod nga mga kinahanglanon:

1. Ang high-frequency synchronous nga pagkuha sa real-time nga mga sukatan ug ang ilang pagbalhin ngadto sa sistema sa pagdumala sa komunikasyon nga walay paglangan.
   Ang taas nga frequency ug pag-synchronize sa lainlaing mga sukatan dili lang hinungdanon, hinungdanon kini alang sa pag-analisar sa entropy sa mga channel sa pagpadala sa datos. Kung sa usa ka channel sa transmission sa data ang kasagaran nga paglangan mao ang 30 milliseconds, nan ang usa ka sayup sa pag-synchronize tali sa nahabilin nga mga sukatan nga usa lang ka millisecond ang hinungdan sa pagkadaot sa katulin sa sangputanan nga channel sa gibana-bana nga 5%. Kung masayop naton ang oras sa 1 millisecond sa 4 nga mga channel, ang katulin nga pagkadaot dali nga mahulog sa 30%. Dugang pa, ang entropy sa mga kanal dali nga nagbag-o, mao nga kung sukdon naton kini nga wala’y kausa sa matag 0.5 millisecond, sa mga paspas nga kanal nga adunay gamay nga paglangan makuha namon ang taas nga tulin nga pagkadaot. Siyempre, ang ingon nga katukma dili kinahanglan alang sa tanan nga mga sukatan ug dili sa tanan nga mga kondisyon. Kung ang paglangan sa channel mao ang 500 milliseconds, ug nagtrabaho kami sa ingon, nan ang usa ka sayup nga 1 millisecond hapit dili mamatikdan. Usab, alang sa mga sukatan sa sistema sa pagsuporta sa kinabuhi, aduna kitay igong polling ug synchronization rates nga 2 segundos, apan ang monitoring system mismo kinahanglang makahimo sa pagtrabaho uban sa ultra-high polling rates ug ultra-precise synchronization sa metrics.
2. Minimal nga konsumo sa kapanguhaan ug usa ka stack.
   Ang end device mahimo nga usa ka gamhanan nga on-board complex nga mahimong mag-analisar sa sitwasyon sa dalan o magpahigayon og biometric recording sa mga tawo, o usa ka palm-sized nga single-board nga kompyuter nga gisul-ob sa usa ka espesyal nga pwersa nga sundalo ubos sa iyang armor sa lawas aron ipadala ang video sa tinuod nga panahon sa dili maayo nga kahimtang sa komunikasyon. Bisan pa sa lainlaing mga arkitektura ug gahum sa pag-compute, gusto namon nga adunay parehas nga stack sa software.
3. Arkitektura sa payong
   Ang mga sukatan kinahanglang kolektahon ug igrupo sa end device, lokal nga gitipigan, ug makita sa tinuod nga panahon ug sa retrospectively. Kung adunay koneksyon, ibalhin ang data sa sentral nga sistema sa pag-monitor. Kung walay koneksyon, ang pagpadala nga pila kinahanglan nga magtigum ug dili mokonsumo sa RAM.
4. API alang sa paghiusa sa sistema sa pag-monitor sa kustomer, tungod kay wala’y usa nga nanginahanglan daghang mga sistema sa pag-monitor. Ang kustomer kinahanglan nga mangolekta og datos gikan sa bisan unsang mga aparato ug network sa usa ka pag-monitor.

Unsay nahitabo

Aron dili mabug-atan ang impresibo na nga dugay na nga pagbasa, dili ako maghatag mga pananglitan ug mga sukod sa tanan nga mga sistema sa pag-monitor. Kini motultol sa laing artikulo. Isulti lang nako nga wala kami makit-an ang usa ka sistema sa pag-monitor nga makahimo sa pagkuha sa duha nga mga sukatan nga dungan nga adunay usa ka sayup nga wala’y 1 millisecond ug parehas nga epektibo nga nagtrabaho pareho sa arkitektura sa ARM nga adunay 64 MB nga RAM ug sa arkitektura sa x86_64 nga adunay 32 GB sa RAM. Busa, nakahukom kami sa pagsulat sa among kaugalingon, nga makahimo niining tanan. Ania ang among nakuha:

Pag-summarize sa throughput sa tulo ka mga channel alang sa lain-laing mga topologies sa network

Pagtan-aw sa pipila ka hinungdanon nga mga sukatan

arkitektura

Gigamit namo ang Golang isip pangunang programming language, sa device ug sa data center. Gipasimple kaayo niini ang kinabuhi sa pagpatuman niini sa multitasking ug ang abilidad nga makakuha og usa ka statically linked executable binary file alang sa matag serbisyo. Isip resulta, makadaginot kaayo mi sa mga kahinguhaan, mga pamaagi ug trapiko para sa pagdeploy sa serbisyo aron tapuson ang mga device, oras sa pag-develop ug pag-debug sa code.

Ang sistema gipatuman sumala sa klasiko nga modular nga prinsipyo ug adunay daghang mga subsystem:

1. Pagparehistro sa metrics.
   Ang matag metric giserbisyuhan sa kaugalingon nga thread ug gi-synchronize sa mga channel. Nakab-ot namon ang katukma sa pag-synchronize hangtod sa 10 nanoseconds.
2. Pagtipig sa mga sukatan
   Nagpili kami tali sa pagsulat sa among kaugalingon nga pagtipig alang sa serye sa oras o paggamit sa usa ka butang nga magamit na. Ang database gikinahanglan alang sa retrospective data nga gipailalom sa sunod nga visualization. Sa ato pa, wala kini naglangkob sa data sa mga paglangan sa channel matag 0.5 milliseconds o error nga mga pagbasa sa transport network, apan adunay speed sa matag interface matag 500 milliseconds. Dugang pa sa taas nga mga kinahanglanon alang sa cross-platform ug ubos nga konsumo sa kapanguhaan, kini mao ang hilabihan ka importante alang kanato nga makahimo sa pagproseso. data mao ang dapit diin kini gitipigan. Kini makadaginot ug dako kaayong kahinguhaan sa kompyuter. Gigamit namon ang Tarantool DBMS sa kini nga proyekto sukad sa 2016 ug hangtod karon wala kami makakita nga kapuli niini sa kapunawpunawan. Flexible, nga adunay labing maayo nga konsumo sa kapanguhaan, labaw pa sa igo nga teknikal nga suporta. Ang Tarantool nagpatuman usab og GIS module. Siyempre, kini dili sama ka gamhanan sa PostGIS, apan kini igo na alang sa atong mga buluhaton sa pagtipig sa pipila ka mga sukatan nga may kalabutan sa lokasyon (may kalabutan sa transportasyon).
3. Pagtan-aw sa mga sukatan
   Ang tanan yano ra dinhi. Gikuha namo ang datos gikan sa bodega ug gipakita kini sa tinuod nga panahon o sa retrospectively.
4. Pag-synchronize sa datos sa sentral nga sistema sa pag-monitor.
   Ang sentral nga sistema sa pag-monitor makadawat mga datos gikan sa tanan nga mga aparato, gitipigan kini sa usa ka piho nga kasaysayan ug gipadala kini sa sistema sa pag-monitor sa Customer pinaagi sa API. Dili sama sa klasiko nga mga sistema sa pag-monitor, diin ang "ulo" naglakaw-lakaw ug nagkolekta sa datos, kami adunay kaatbang nga laraw. Ang mga aparato mismo nagpadala sa datos kung adunay koneksyon. Kini usa ka hinungdanon kaayo nga punto, tungod kay gitugotan ka nga makadawat mga datos gikan sa aparato alang sa mga yugto sa panahon nga wala kini magamit ug wala mag-load sa mga channel ug mga kapanguhaan samtang ang aparato dili magamit. Gigamit namo ang Influx monitoring server isip sentral nga sistema sa pagmonitor. Dili sama sa mga analogue niini, maka-import kini og retrospective data (nga mao, uban ang time stamp nga lahi sa higayon nga nadawat ang metrics). Kini nga sumbanan nga stack gipili usab tungod kay kini adunay andam nga mga panagsama sa API sa hapit bisan unsang sistema sa pag-monitor sa kostumer.
5. Pag-synchronize sa datos sa usa ka sentral nga sistema sa pagdumala sa aparato.
   Ang sistema sa pagdumala sa device nagpatuman sa Zero Touch Provisioning (pag-update sa firmware, configuration, ug uban pa) ug, dili sama sa monitoring system, makadawat lang og mga problema kada device. Kini ang mga trigger sa operasyon sa on-board nga hardware watchdog nga mga serbisyo ug ang tanang metrics sa life support system: CPU ug SSD temperature, CPU load, free space ug SMART health sa mga disk. Ang pagtipig sa subsystem gitukod usab sa Tarantool. Naghatag kini kanamo hinungdanon nga katulin sa pagtipon sa mga serye sa oras sa libu-libo nga mga aparato, ug hingpit usab nga nasulbad ang isyu sa pag-synchronize sa data sa kini nga mga aparato. Ang Tarantool adunay maayo kaayo nga pagpila ug garantiya nga sistema sa pagpadala. Nakuha namo kining importante nga bahin gikan sa kahon, maayo!

Sistema sa pagdumala sa network

Unsa ang sunod

Sa pagkakaron, ang among pinakahuyang nga sumpay mao ang sentral nga sistema sa pagmonitor. Gipatuman kini sa 99.9% sa usa ka standard stack ug adunay daghang mga disadvantages:

1. Ang InfluxDB nawad-an sa datos kung nawala ang gahum. Ingon sa usa ka lagda, ang Kustomer dali nga nagkolekta sa tanan nga gikan sa mga aparato ug ang database mismo wala maglangkob sa datos nga mas tigulang kaysa 5 minuto, apan sa umaabot mahimo kini nga usa ka kasakit.
2. Ang Grafana adunay daghang mga problema sa data aggregation ug pag-synchronize sa display niini. Ang labing kasagaran nga problema mao kung ang database adunay usa ka serye sa oras nga adunay gilay-on nga 2 segundos sugod sa, ingnon ta, 00:00:00, ug ang Grafana nagsugod sa pagpakita sa datos sa panagsama gikan sa +1 segundo. Ingon usa ka sangputanan, ang tiggamit nakakita usa ka graph sa pagsayaw.
3. Sobra nga kantidad sa code para sa API integration sa mga third-party monitoring system. Mahimo kini nga labi ka compact ug siyempre gisulat pag-usab sa Go)

Sa akong hunahuna kamong tanan nakakita sa hingpit kung unsa ang hitsura sa Grafana ug nahibal-an ang mga problema niini kung wala ako, mao nga dili nako ma-overload ang post nga adunay mga litrato.

konklusyon

Tinuyo nga wala nako ihulagway ang teknikal nga mga detalye, apan gihulagway lamang ang batakang disenyo niini nga sistema. Una, aron hingpit nga mahulagway sa teknikal ang sistema, gikinahanglan ang laing artikulo. Ikaduha, dili tanan interesado niini. Isulat sa mga komento kung unsang mga teknikal nga detalye ang gusto nimong mahibal-an.

Kung adunay bisan kinsa nga adunay mga pangutana nga lapas sa sulud sa kini nga artikulo, mahimo ka magsulat kanako sa a.rodin @ qedr.com

Source: www.habr.com