Itaque, vos mensuras colligitis. Et nos quoque. Nos quoque mensuras colligimus. Scilicet, eas quae ad negotia pertinent. Hodie vobis de primo nexu systematis nostri monitorii narrabimus — servo aggregationis statsd-compatibili. , cur id scripserimus et cur Brubeck deseruerimus.
Ex prioribus nostris articulis (, ) invenire potes nos usque ad aliquod tempus antea inscriptiones collegisse utens Lingua C scriptum est. Tam simplex est quam mus (quod magni momenti est cum contribuere vis) et, quod potissimum est, volumen maximum duorum milionum metricorum per secundum (MPS) sine ullis difficultatibus tractat. Documentatio auxilium quattuor milionum MPS cum asterisco affirmat. Hoc significat te numerum dictum adepturum esse si rete recte configuraveris. Linux(Nescimus quot MPS adipisci possis si rete sicut est relinquas.) His commodis non obstantibus, plures querelas graves de Brubeck habuimus.
Assertio 1. Github, auctor proiecti, id sustinere desiit: emendationes et emendationes edendo, nostras petitiones privatas (et aliorum) accipiendo. Actio his mensibus (circa Februarium-Martium 2018) resumpta est, sed antea fere biennium silentii completi fuit. Praeterea, proiectum adhuc in progressu est. , quod impedimentum grave ad novarum functionum implementationem fieri potest.
Assertio 2. Accuratio calculi. Brubeck tantum 65 536 valores ad aggregationem colligit. In nostro casu, pro quibusdam metricis, periodus aggregationis (30 secundis) valores multo plures (1 527 392 ad culmen) accipere potest. Ex hac collectione exemplorum, valores maximi et minimi inutiles apparent. Exempli gratia, sic:
Sicut erat
Quomodo debuisset esse
Ob eandem causam, summae perperam computantur. Adde huc vitium cum redundantiae numeri 32-bit float, quod servitorem in segmentum erratum mittit cum mensuram innocentem accipit, et omnia perfecta fiunt. Obiter, hoc vitium numquam correctum est.
Et tandem, Postulatio XDum haec scribo, parati sumus id contra omnes quattuordecim implementationes statsd plus minusve operantes quas invenimus experiri. Fingamus infrastructuram quandam tantum crevisse ut quattuor miliones MPS consumere non iam sufficiat. Vel, etiamsi nondum creverit, mensurae tibi tam magni momenti sunt ut etiam breves, duorum triumve minutorum descensus in graphis critici fieri possint et impetus depressionis insuperabilis in administratoribus excitare. Cum curatio depressionis sit labor ingratus, solutiones technicae necessariae sunt.
Primum, tolerantia errorum, ne subito problema servi apocalypsin zombificam psychiatricam in officio provocet. Secundum, scalabilitas, ut plus quam quattuor miliones MPS tractare possit sine necessitate alte in acervum retiarium fodiendi. Linux et placide "in latitudine" ad magnitudinem requisitam crescere.
Cum spatium aliquod scalabilitatis haberemus, tolerantia errorum incipere decrevimus. "Oh! Tolerantia errorum! Simplex est, possumus facere," cogitavimus, et duos servos emisimus, exemplar brubeck in utroque currentes. Ad hoc faciendum, commeatum cum metris ad ambos servos copiare et etiam fragmentum codicis pro eo scribere debuimus. Hoc modo quaestionem tolerantiae errorum solvimus, sed... non admodum bene. Primo, omnia bene videbantur: quisque brubeck suam versionem aggregationis colligit, data in Graphite singulis triginta secundis scribit, intervallum vetus superscribens (hoc in parte Graphite fit). Si unus servus deficit, semper secundum cum sua copia datorum aggregatorum habemus. Sed hic est problema: si servus deficit, exemplar "serrae ad serram" in graphis apparet. Hoc ex eo fit quod intervalla triginta secundorum brubeck non synchronizantur, et cum unum eorum deficit, non superscribit. Idem fit cum secundus servus incipit. Tolerabile est, sed meliora volumus! Quaestio scalabilitatis etiam manet. Omnes mensurae adhuc ad unum servum eunt, et ideo ad eosdem 2-4 miliones MPS limitamur, secundum perfunctionem retis.
Si de problemate paulisper cogitas dum nivem palas removes, fortasse manifesta idea tibi in mentem venit: statsd tibi opus est quod modo distributo operari possit. Hoc est, unum quod synchronizationem inter nodos secundum tempus et mensuras efficit. "Certe talis solutio iam existit," diximus, et per Google quaesivimus... Et nihil invenimus. Postquam documenta pro variis statsd perscrutati sumus ( Die undecimo Decembris anni MMXVII, nihil prorsus invenimus. Apparet neque artifices neque usores harum solutionum umquam tot mensuras invenisse, alioquin aliquid certe excogitavissent.
Deinde statum "ludibrium" statsd, bioyino, quod in certamine "Just for Fun" scripsimus (nomen propositi a scripto ante certamen generatum est) recordati sumus et intelleximus statum nostrum proprium statsd urgente egere. Cur?
- quia nimis pauci cloni statsd in mundo sunt,
- quia fieri potest ut tolerantia errorum et scalabilitas optatae vel prope optatae praebeantur (inclusa synchronizatione mensurarum aggregatarum inter servientes et solutione problematis conflictuum in mittendis),
- quia mensuras accuratius quam Brubeck computare potes,
- quia statistica accuratiora ipsi colligere possumus, quae Brubeck nobis paene numquam praebuit,
- quia mihi occasio data est propriam applicationem hyper-performantiae scalae distributae programmandi, quae architecturam alterius talis hyper-performantiae non plene replicaret... bene, intelligis.
In quo scribendum est? In rubigine, scilicet. Cur?
- quia iam prototypum solutionis exstabat,
- quia auctor articuli iam Rust eo tempore noverat et cupidus erat aliquid in eo ad productionem scribere cum possibilitate edendi ut liber,
- quia linguae cum GC nobis non aptae sunt propter naturam commeatus accepti (fere tempore reali) et pausae GC paene intolerabiles sunt,
- quia maximam efficaciam comparabilem C requirimus
- Quia Rust nobis audacem concurrentiam praebet, et si id in C/C++ scribere coeperemus, etiam plura quam "brubeck", "vulnerabilitates", "buffer overflows", "race conditions", et alia verba formidulosa acciperemus.
Argumentum etiam contra Rust ortum est. Societas nullam experientiam in creandis proiectis Rust habebat, et nos non in animo habebamus eo in proiecto nostro principali uti. Itaque graves erant metus ne non proficeret, sed statuimus periculum capere et experiri.
Tempus praeteriit…
Tandem, post complures conatus irritos, prima versio operans parata erat. Quid accidit? Hoc modo apparuit.
Quisque nodus suam mensurarum seriem accipit et eas accumulat, sed mensuras pro illis generibus non aggregat ubi plena series ad aggregationem finalem requireretur. Nodi per protocollum clausurae distributae connectuntur, quod eis permittit unum (hic clamavimus) dignum ad mensuras ad Magnum mittendas eligere. Hoc problema nunc tractatur a... , sed in futuro ambitiones auctoris ad extenduntur Raft, ubi nodus dux consensus, scilicet, dignissimus est. Praeter consensum, nodi frequenter (semel per secundum, per default) vicinis suis partes metricarum praeaggregatarum mittunt quas illo momento collegere potuerunt. Hoc scalabilitatem et tolerantiam errorum servat — quisque nodus adhuc seriem plenam metricarum retinet, sed metricae aggregatae mittuntur, per TCP et in protocollo binario codificatae, sumptus duplicationis significanter minuentes comparatis cum UDP. Quamvis numerus metricorum advenientium relative magnus sit, accumulatio memoriae minimae et CPU etiam minus requirit. Pro nostris metricis bene compressis, hoc ad paucas tantum decem megabytas datorum pertinet. Commodum additum est vitatio rescriptionum datorum superfluarum in Graphite, ut erat casus cum Burbeck.
Fasciculi UDP cum metricis inter nodos in apparatu retiali per simplicem "circuitum rotationem" (round robin) inaequales fiunt. Scilicet, apparatus retialis contenta fasciculorum non interpretatur, ideoque plus quam quattuor miliones fasciculorum per secundum tractare potest, nedum metricas quas ignorat. Cum metricae non singillatim in unoquoque fasciculo recipiantur, nullas difficultates perfunctionis hic praevidemus. Si servus corruit, instrumentum retiale celeriter (intra 1-2 secunda) hoc detegit et servum deficientem e rotatione removet. Propterea, nodi passivi (id est, non-duces) accendi et extingui possunt sine ulla fere notabili lapsu in graphis. Maxime amittimus aliquas ex metricis quae ultimo secundo advenerunt. Subita amissio/mutatio ducis adhuc anomaliam minorem creabit (intervallum 30 secundorum adhuc non synchronizatur), sed si communicatio inter nodos est, hae difficultates minui possunt, exempli gratia, fasciculos synchronizationis mittendo.
Pauca de internis. Applicatio, scilicet, multifilo instructa est, sed architectura filorum ab ea quae in Brubeck adhibetur differt. Fila in Brubeck identica sunt — unumquodque et collectionem et aggregationem datorum curat. In Bioyino, fila operaria in duas partes dividuntur: ea quae processum retialem curant et ea quae aggregationem curant. Haec divisio administrationem applicationis flexibiliorem permittit, secundum genus metricorum: ubi aggregatio intensiva requiritur, aggregatores addi possunt, dum ubi multum commeatus retialis est, plura fila retialia addi possunt. Nunc, octo filis retialibus et quattuor filis aggregationis in nostris servitoribus operamur.
Pars computationis (aggregationis) satis taediosa est. Memoriae intermediae (buffers) fluxibus retialibus repletae inter fila computationis distribuuntur, ubi deinde resolvuntur et aggregantur. Si petuntur, mensurae ad alios nodos mittuntur. Haec omnia, inclusa translatione datorum inter nodos et interactione cum Consule, asynchrone perficiuntur et in structura currunt. .
Pars retialis quae mensuras recipiendis praeerat multo maiores difficultates progressionis praebebat. Finis primarius separandi fluxus retiales in entitates separatas erat tempus quo quisque fluxus insumptus erat reducere. non Ad data ex socket legenda. Optiones utendi UDP asynchrono et recvmsg regulari celeriter in desuetudinem venerunt: prior nimium spatii usoris CPU ad eventus tractandos consumit, dum posterior nimis multas mutationes contextus consumit. Ergo, modus hodiernus est... Cum magnis memoriae intermediae (et memoriae intermediae, viri officiales, non sunt quidlibet!), subsidium pro UDP regulari reservatur casibus parvi oneris ubi recvmmsg non requiritur. Modus multinuntium finem principalem assequitur: filum retiale maximam partem temporis sui consumit purgans ordinem systematis operativi — legens data e socketo et transferens ea ad memoriam intermediam spatii usoris, tantum interdum commutans ad tradendum memoriam intermediam plenam aggregatoribus. Ordo socketorum fere numquam accumulatur, et numerus fasciculorum amissum vix augetur.
illud
Defalta, magnitudo memoriae intermediae satis magna constituitur. Si ipse servitorem experiri constitueris, fortasse invenies, postquam paucas mensuras misisti, eas in Graphite non advenire, sed in memoria intermedia fluminis retialis manere. Ut paucas mensuras tractare possis, valores minores in fasciculis configurationis "bufsize" et "task-queue-size" constituere debes.
Tandem, quaedam tabulae pro amatoribus tabularum.
Statisticae de numero mensurarum advenientium pro quolibet servo: plus quam duo miliones MPS.
Unum e nodis inactivando et mensuras advenientes redistribuendo.
Statistica de mensuris exeuntibus: unus tantum nodus umquam mittit—dux incursionis.
Statistica operationis cuiusque nodi, ratione habita errorum in variis modulis systematis.
Singula de mensuris advenientibus (nomina mensuris celantur).
Quid deinceps cum his omnibus facere in animo habemus? Codicem, id est, scribere, scilicet! Proiectum initio ut apertum destinatum erat et ita per totam vitam manebit. Proxima consilia nostra includunt transitum ad nostram versionem Raft, mutationem protocolli inter pares in unam magis portabilem, additionem statisticarum internarum, novarum typorum metricorum, correctionem errorum, et alias emendationes.
Scilicet, quicumque velit adiuvare ad progressionem incepti benigne recipitur: crea relationes publicas (PRs), quaestiones, et nos eis respondebimus, quotiescumque fieri potest, eas emendabimus, et cetera.
Hoc est totum, amici, ut aiunt, elephantos nostros emite!
Source: www.habr.com
