Videbimus quomodo Zabbix opera datorum TimescaleDB ut tergum. Ostendemus tibi quomodo ab integro incipias et quomodo ex PostgreSQL migrare debeas. Etiam probationes comparativae duarum figurarum providebimus.
HighLoad++ Siberia 2019. Tomsk Hall. Iunii 24, 16:00. thesibus et . Proxima HighLoad ++ colloquium habendum est die 6 mensis Aprilis anno 7 in St. Petersburg. Singula ac tesseras .
Andrey Gushchin (infra – AG); – Sum ZABBIX machinator technicus (infra postea ut “Zabbix”), exercitator. In subsidiis technicis plus quam VI annos laboravi et experientiam directam habui cum effectu. Hodie de observantia loqui potest quod TimescaleDB cum regularibus PostgreSQL comparatum providere potest 6. Item, pars quaedam introductoria quomodo in genere operatur.
Top productivity challenges: from the data collection to data emundation
In primis, certae operationis provocationes sunt quae omnis ratio vigilantia facies. Prima productiva provocatio est celeriter colligendi et expediendi notitias.
Systema vigilantia bona cito, opportune omnia data recipiat, eam pro processu secundum expressiones felis, id est, secundum aliquas normas (hoc differt in diversis systematibus) eamque conservare in database ut hac notitia utatur in futurum.
Secunda provocatio perficientur est historia repono. Repone in database saepe et facilem et opportunam accessum habe ad haec metrica quae per aliquod temporis spatium collecta sunt. Praecipuum est quod haec notitia commodius obtinetur, uti in relationibus, graphis, triggers, in quibusdam valoribus limine, pro summis, etc.
Tertia provocatio perficiendi est historiae defensionem, hoc est, cum eo perveneris ubi non opus est singula metrica quae supra 5 annos collecta sunt (etiam menses vel duos menses). Nodi retis nonnullae deletae sunt, vel aliquae catervae, metricae iam non sunt necessariae, quia iam sunt outdated et non amplius collectae sunt. Haec omnia purganda sunt ut tuum database non nimis augeatur. In genere, historiae purgandae frequentius est grave experimentum pro repositione - saepe validissima ictum in effectu habet.
Quomodo caching quaestiones solvere?
Nunc specialiter de Zabbix dicam. In Zabbix, prima et secunda vocat caching solvuntur usura.
Data collectione et dispensando - RAM utimur ut omnia haec notitia congregem. Haec notitia nunc fusius discutietur.
Etiam in parte datorum est quaedam caching praecipuarum lectionum, pro graphis et aliis rebus.
Caching in parte ipsius servientis Zabbix: habemus ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Quid est?
ConfigurationCache est latibulum principale in quo condimus metricos, hostias, datas res, triggers; omnia quae opus est ad processum prae- cedens, notitias colligendas, unde exercitus colligendi, qua frequentia. Haec omnia in Configuratione Cache condita sunt ut ad res datorum non accedat et interrogationes necessarias creet. Post initium server, hunc cella renovamus (creamus) et per intervalla renovamus (prout in uncinis configurationis).
Caching in Zabbix. Notitia collectio
Hic schema satis magnum est.
Praecipuae in schemate sunt hi collectores;
Hi sunt processus ipsius conventus, varii "pollones", qui diversis generibus coetuum responsales sunt. Data per icmp, ipmi, variaque protocolla colligunt, omnia ad praeprocessionem transferunt.
PreProcessing HistoryCache
Item, si elementa calculata (qui Zabbix norunt nota), id est calculi, aggregationis elementorum notitia, ea immediate a ValueCache accipimus. Dicam quomodo postea impleta est. Omnes hi collectores ConfigurationisCache utuntur ad sua opera recipienda et postea ad praeprocessionem transmittunt.
Praeprocessione etiam utitur ConfigurationCache ad obtinendum praeprocessionem gradus et processus huius notitiae variis modis. Incipientes a versione 4.2, eam ad procuratorem movimus. Et hoc valde commodum est, quia ipsa prae- cedens operatio difficilior est. Et si amplissimum Zabbixum habes, cum magna elementorum notitia et frequentia collectio magna, hoc opus valde simplicificat.
Proinde, postquam haec notitia aliquo modo praeprocessione usus est, eam in HistoryCache servamus ut ulterius progrediamur. Inde colligitur notitia collectionis. Nos ad processum principalis.
Syncer scriptor opus historia
Processus principalis in Zabbix (quia est architectura monolithica) est syncer historia. Hic est praecipuus processus qui speciatim agit de processu atomico cuiuslibet elementi notitiae, id est, uniuscuiusque valoris;
- valor (ex HistoryCache accipit);
- sistit in Configuratione synceris: an quae sint triggeres ad calculandum, eas reputet;
si est - creat eventus, propagationem facit ad excitandum, si opus est secundum figuram; - records triggers for subsequent processing, collection; si aggregatis super ultimam horam et sic deinceps, huius valoris memoria a ValueCache ut non accedat ad tabulam historicam; Ita, ValueCache, impletur notitia necessariis quae ad calculandum, elementa calculata, etc.
- tunc Syncer Historia scribit omnia data datorum;
- database scribens eos ad disci - hoc est ubi processus processus terminatur.
Database. Caching
In parte datorum, cum graphas vel aliquas relationes de eventis inspicere vis, variae sunt cella. Sed in hac fama non loquor.
Pro MySQL est Innodb_buffer_pool, et fasciculum cellarum diversorum quae etiam configurari possunt.
Sed haec sunt praecipua:
- shared_buffers;
- effective_cache_size;
- shared_pool.
Pro omnibus databases dixi esse quosdam thesauros qui te condere in RAM permittunt notitias quae pro quaestionibus saepe necessariae sunt. Suas technologias ad hoc habent.
De Database euismod
Proinde ambitus auctoris est, id est, servo Zabbix collectas notitias et monumenta habet. Cum restarted, etiam ex historia legit ut ValueCache impleat et cetera. Hic habere potes scripta et nuntia quae Zabbix API utuntur, quae in interface tela fabricatur. Zabbix API datorum datorum ingreditur et necessarias notitias accipit ad graphas, relationes, vel aliquos indicem rerum recentium quaestionum.
Etiam solutio visualizationis popularis Grafana est, qua utentes nostri utuntur. Potest directe log in utroque per Zabbix API et per datorum. Certam etiam quandam gignit pro notitia obtinenda: subtilius, melius, aptior datorum necessarius est ad obsequium celeris exitus eventuum et probationum.
Historiam defensionem. Zabbix habet vilicum
Tertia vocatio, quae Zabbix in usu est, historiae usus cavet custodis. Villarius omnes occasus sequitur, id est, elementa nostra notitiae nostrae indicant quam longum est condere (in diebus), quousque ad trends recondere et dynamicas mutationes.
Non loqui de TrendCache, quod muscam computamus: advenit notitia, id aggregatur una hora (plerumque hi numeri sunt horae ultimae), moles mediocris est/ minima et semel horae commemoramus in mensa dynamicorum mutationum ("Trends"). "Vilitorium" incipit et delet notitias ex delectis regularibus datorum, quod non semper est efficax.
Quomodo intelligere inefficax est? Videre potes hanc imaginem in graphs processus internorum perficiendi:
Syncer Historiae tuae constanter occupatus (rubrum graph). Et "rubrum" graph quod superne pergit. Hic "hospes" est qui incipit et exspectat datorum ad omnes ordines delendos quos definitum est.
Item ID sumamus aliquid: postrema 5 milia delere debes; nimirum indices. Solet autem dataset satis ampla est - datorum adhuc ex orbe legit eamque in cella mittit, et haec operandi causa datorum valde pretiosa est. Secundum suam magnitudinem, hoc ad quasdam difficultates perficiendas ducere potest.
Potes simplici ratione hospitari disable - interface telam familiarem habemus. Occasus in Administratione generali (occasus pro "Housekeeper") inactivamus interna domestica pro historia et trends interna. Itaque tabernarius hoc amplius non regit;
Quid facias deinde? Avertisti, graphes tuas exaequasti... Quaenam adhuc in hoc casu difficultates oriri potuerunt? Quid juvat?
Partiare (sectioning)
Typice hoc configuratur diversimode in singulis database relationibus quas enumeravi. MySQL ars sua habet. Sed altiore simillima sunt cum fit ad PostgreSQL 10 et MySQL. Nimirum internae differentiae sunt multum quomodo actum est omnia et quomodo effectus afficit. At generaliter creatio novae partitionis saepe etiam quasdam difficultates inducit.
Prout in tuo setup (quantum notitias in uno die creas), solent minimum ponere - hoc est 1 dies / batch, et pro "trends", dynamica mutationum - 1 mensis / novas massam. Hoc potest mutare si amplissimum paro.
Dicamus statim de magnitudine paroeciae: usque ad 5 milia valorum novorum per alterum (nvps sic dicti) - hoc parvum "setup" habebitur. Mediocris — ab 5 ad 25 milia valorum secundo. Omnia, quae supra sunt, iam sunt magna et amplissima officinae quae diligentissimam datorum conformationem requirunt.
In amplissimis officinae, 1 dies non potest esse optima. Partitiones in MySQL de 40 gigabytis per diem personaliter vidi (et plura esse possunt). Magna haec notitiarum copia est, quae ad aliquas difficultates ducere potest. Revocandum est.
Cur partitionibus opus est?
Quid partitionem praebet, ut opinor, omnes sciunt, tabula partitionis. Saepe hae files separati sunt in petitionibus orbis et spatii. Partitionem unam optime eligit si partitio normali sit.
Nam Zabbix speciatim usurpatur a range, iugi, id est, indicatione temporis utimur (numerus regularis, ab initio epochae). Initium definis diei/finem diei, et haec est divisio. Proinde, si postulas notitias quae biduum est, omnia e database citius redduntur, quia solum necesse est unum fasciculum in cella onerare et illam (quam magnam mensam reddere).
Multi etiam databases accelerant inserta (insertio in unam tabulam puerilem). Abstracte pro nunc loquor, sed hoc quoque fieri potest. Partiendo saepe adiuvat.
Elastica investigationis pro NoSQL
Nuper, in 3.4, solutionem NosQL implevimus. Facultatem ad scribendum in Elasticsearch addidit. Genera quaedam scribere potes: elige vel scribere numeros vel aliqua signa; textum nervum habemus, ligna ad Elastica investigationem scribere potes... Proinde interfacies interfaciendi etiam ad Elasticam inquisitionem accedet. Hoc in quibusdam magna operatur, sed in momento adhiberi potest.
TimescaleDB. Hypertables
4.4.2 Nam sicut TimescaleDB unum intendimus. Quid est? Haec extensio est pro PostgreSQL, hoc est, indigena PostgreSQL interfaciem habet. Plus, haec extensio permittit ut multo efficacius in data temporariis elaborare et in ipso partitione habere. Quod is vultus amo;
Hoc hypertabile est - talis notio in Timescale est. Hoc est hypertable quod tu creas, et chunks continet. Chunks partitiones sunt, hae tabulae infantum sunt, ni fallor. Praesent sit amet elit.
TimescaleDB et PostgreSQL
Ut artifices TimescaleDB certiores faciunt, rectius algorithmo utuntur ad interrogationes expediendas, in particulari adiiciunt, quae permittit ut fere assidue perficiendi cum incremento notitiarum insertarum magnitudine. Hoc est, post 200 miliones versuum Postgresrum, consuetum valde incipit sentire et ad nullam litteram perficiendam amittit, dum Timescale permittit te inserere quam efficacissime quavis notitiarum copia.
Quomodo install TimescaleDB? Simplex est!
Id est in documentis, descriptus est - id instituere potes ex fasciculis quibusvis... Pendet ex fasciculis officialibus Postgres. Componi potest manually. Accidit ut pro datorum componere debebam.
In Zabbix simpliciter extensionem imus. Puto eos qui Extensione in Postgres usi sunt... Extensionem simpliciter excitant, efficiunt pro database Zabbix, quod uteris.
Et ultimum gradum...
TimescaleDB. Donec adipiscing tabulae historiae
Hypertable creare debes. Munus speciale est huic - hypertable crea. In ea primus parameter est mensa quae in hoc database opus est (pro qua hyperabilem creare debes).
Ager quo creare et intervalescere (hoc est rimarum intervallum (partitiones quibus utendum est) 86, 400 dies unus est.
Parameter Migrate_data: Si vera inseres, haec omnia current notitia ad chunkos praecreatos migrabit.
Ego ipse usus sum migrate_data - tantum temporis accipit, secundum quam magnum datorum tuorum est. Super a terabyte habui — eam horam creare cepit. In nonnullis casibus, in probatione, notitias historicas pro textu (history_text) et filo (history_str) delevi ut eas non transferrem - mihi revera non erant iucunda.
Novissima renovatio in nostra db_extentione facimus: temporacaledb instituimus ut database et praesertim Zabbix noster intelligat db_extentionem esse. Eam actuat et rectam syntaxin et interrogationes datorum utitur, utitur illis "plumis" quae ad TimescaleDB necessaria sunt.
Servo configuratione
Servientibus duobus usus sum. Prima server satis parva est virtualis apparatus, 20 processors, 16 gigabytes RAM. Postgres 10.8 conformatus sum in ea:
Ratio operandi erat Debian, ratio tabella xfs erat. Minimas occasus feci ut hoc datorum particulari utar, minus quibus ipsa Zabbix utetur. In eadem machina erat servo Zabbix, PostgreSQL et onere agentium.
L agentium activorum usus sum qui LoadableModule utuntur ad diversos eventus cito generandos. Isti sunt qui generant chordas, numeros et cetera. Ego implevi database cum multa data. Initio, figuratio quinque milia elementorum per exercitum continebat, et circa singula elementa data felis continebat, ut hoc verum esse habeat. Etiam eget quam quis felis interdum egestas.
Renovationem intervallum et ipsum onus temperavi non solum utendo 50 agentibus (plus additis), sed etiam elementis dynamicis utens et renovationem intervallum ad 4 secundas reducens.
Euismod elit. PostgreSQL: XXXVI milia NVPs
Prima launch, primum paroecialem quam habui in auro PostreSQL 10 in hoc ferramento (35 milia valorum secundo). In genere, ut videre potes in velo, notitias inserentes fractiones secundae sumit - omnia bona et ieiunium, SSD agitet (200 gigabytes). Sola res est quae 20 GB satis cito implet.
Satis multum erit talis graphs in futurum. Hoc signum est Zabbix servo ashboardday perficiendi.
Prima graphia est numerus valorum per alterum (hyacintho, top left), 35 milia valorum in hoc casu. Haec oneratio processuum aedificandi est, et haec oneratio processuum internorum est: syncerorum historia et vilicus, qui hic (imo centrum) aliquantum temporis currit.
Hoc graphum (imo centrum) ostendit ValueCache usum - quot ValueCache hits pro triggers (plures milia valorum secundo). Alia graphi momenti alia quarta est (ima supersunt), quae usum HistoryCache ostendit, de quo dixi, quod quiddam est antequam in datorum inseratur.
Euismod elit. PostgreSQL: XXXVI milia NVPs
Deinde onus ad 50 milia valorum secundo eodem ferramento augevi. Cum oneratus a Housekeeper, 10 milia valorum in secundis 2-3 computatis scripti sunt. Quid vero in sequenti screenshot ostenditur;
"Viliarius" iam coepit impedire labori, sed in generali, onus fris historici-perscrutatoris adhuc est in gradu 60% (tertiae graphae, top ius). HistoryCache iam incipit active dum currit tabernarius (fundum relictum est). Circiter erat dimidium gigabyte, 20% plenum.
Euismod elit. PostgreSQL: XXXVI milia NVPs
Deinde ampliavi eam ad 80 milia valorum secundo;
Erat circiter quadringentorum millium elementorum notitia, CCLXXX mille triggerum. Inserta, ut vides, iam satis alta erat in verbis oneris historiae. Inde varios parametros auxit: historiam demersi, cache... Hoc ferramento, onus historiae mersorum augere coepit ad maximum, paene "in pluteo" - proinde History Cache in altissimum onus perrexit;
Hoc tempore totum parametri systematis (quomodo processus RAM usus est) percepi et disco utendo maximum esse deprehendi - maximam capacitatem huius orbis consecutus sum in hoc ferramento, in hac machina virtuali. "Postgres" notitia satis strenue in tantum ardore emittere coepit, et orbis non iam tempus erat scribere, legere...
Aliud servo tuli quod iam habebat 48 processores et 128 gigabytes de RAM;
Ego quoque "concinnus" eam - instituerunt Syncer Historiam (60 frusta) et ad effectum gratum obtinendum. Reapse non sumus "in pluteo", sed hic fortasse finis fructibus, ubi iam necesse est aliquid de eo agere.
Euismod elit. TimescaleDB: LXXX milia NVPs
Praecipuum mihi opus erat uti TimescaleDB. Quisque graph ostendit intinge:
Haec mala sunt praecise migrationis notitiae. Postea, in servo Zabbix, figura onerata demersorum historiae, ut videre potes, multum mutavit. Permittit te ut notitias 3 fere ocius inserere et minus HistoryCache utere - proinde notitias in tempore traditas habebis. Iterum, 80 milia valorum secundorum satis altae sunt (sane non pro Yandex). Super hoc est maiusculum propositum, uno ministro.
PostgreSQL perficientur test: CXX milia NVPs
Deinde quanti elementorum notitiae ad dimidium decies centena milia accessi et valorem computatum 125 milium per alterum accepi;
Et haec graphs accepi:
In principio, haec est operativa utilitas, satis diu operari potest. Sed quia tantum 1,5 orbis terabyte habebat, eo biduo usus sum. Praecipuum est quod simul novae partitiones in TimescaleDB creatae sunt, et hoc ad perficiendum prorsus ignorabatur, quod de MySQL dici non potest.
De more, partitiones noctu creantur, quia haec plerumque impedit insertionem et opus cum tabulis et servitutis degradationem ducere potest. In hoc casu non ita est! Praecipuum munus erat experiendi facultates TimescaleDB. Ex quo fiebat talis figura: CXX milia valorum in secundo.
Exempla etiam sunt in communi;
Persona etiam in TimescaleDB vertitur et onus per io. pondus in processu decidit; et usus elementorum internorum etiam minuitur propter inclusionem TimescaleDB. Hi autem sunt discos ordinarii subcinericii, id est, apparatus virtualis ordinarius in disco ordinario (non SSDs)!
Aliquot parvae setups, quae per orbem obeundo limitantur, TimescaleDB, ut opinor, optima est solutio. Licebit tibi pergere prius quam migrare ad ferramenta celerius database operando.
Ad nostros eventus omnes vos invitamus: Conferentia Moscuae, Culmen in Riga. Utere canalibus nostris - Telegram, forum, IRC. Si quaestiones habes, ad mensam nostram veni, omnia loqui possumus.
Audientia quaestionum
Quaestio ex auditorio (infra - A): - Si TimescaleDB tam facile est configurare, et talem boosti perficiendi dat, tunc fortasse hoc adhiberi debet ut praxis optima ad configurandum Zabbix cum Postgres? Suntne aliquae foveae et incommoda solutionis huius, vel demum, si Zabbix mihi facere decrevi, facile possum Postgres capere, illic ilicet Timescale instituere, ea uti nec de ullis quaestionibus cogitare?
AG: – Ita dico hanc bonam commendationem esse: uti Postgres statim cum extensione TimescaleDB. Ut iam dixi, multa bonae recensiones, non obstante hoc "pluma" experimentum est. Sed revera probat hanc esse magnam solutionem (cum TimescaleDB) et puto evolvendam! Nos vigilantes sumus quomodo haec extensio progreditur et mutationes quae opus faciunt faciamus.
Etiam in evolutione, unam ex notis suis "linimentis" innitentes sumus: fieri potuit cum chunkis paulo aliter. Sed tunc in proximo emissione exciderunt, et in hoc codice freti subsistere debebamus. Suadeo utendo hac solutione in multis setups. Si MySQL uteris ... Pro mediocris setups, quaevis solutio bene operatur.
A: — In ultimis graphis e conventu, grapha erat cum "hospitario":
Operatus est. Quid facit vilicus cum TimescaleDB?
AG: - Nunc pro certo dicere non possum - codicem inspiciam et accuratius tibi dicam. Utitur TimescaleDB queritur non ad chunkos delere, sed aliquo modo eas aggregare. Non paratus sum respondere huic quaestioni technicae adhuc. Plura apud stantem hodie vel cras invenies.
A: - Similem quaestionem habeo - de operatione deletae in Timescale perficienda.
A (respondere ab audientibus): – Cum datam ex tabula delere, si per dele, tunc debes ire per mensam - dele, munda, omnia in vacuum futurum nota. In Timescale, cum chunks habeas, stillare potes. Dure loquendo, simpliciter indica tabellam quae est in magna notitia: "Delere!"
Timescale simpliciter intellegit talem FRUSTUM non amplius existere. Et cum in consilium interrogationis inseritur, hamis utitur ad tuas condiciones in selectis aliisve operibus capiendis et statim intellegit hunc FRUSTUM non amplius esse - "non eo amplius ibimus!" (Notitia not available). Ita est! Hoc est, scapula tabulae fasciculi binarii deletionis substituitur, ut ieiunium est.
A: – Iam tractavimus locum non-SQL. Quantum intelligo, Zabbix notitias mutare non vere opus est, et haec omnia sicut truncum habent. Licetne specialibus databases uti, qui notitias suas mutare non possunt, sed simul salvare, cumulare, et multo citius distribuere - Clickhouse, exempli gratia, aliquid Kafka-similis?.. Kafka est etiam tigillum! Licetne ea aliquo modo integrare?
AG: - Exonerare potest fieri. Certum est "pluma" cum versione 3.4: scribere potes omnia historica, eventus, omnia alia ad fasciculos; et tunc mitte cuilibet alteri datorum utendo aliquo tracto. In facto, multi reficiunt et directe ad datorum scribunt. In musca, historia mersorum haec omnia in scriniis scribe, has fasciculos gyrari, et sic porro, et hoc in CPU transferre potes. De consiliis dicere non possum, sed fortasse ulteriora subsidia solutionum NosSQL (ut Clickhouse) perseveret.
A: – Fere evenit ut postgres omnino carere possis?
AG: - Utique difficillima pars Zabbix est tabulae historicae, quae maxime difficultates et eventa efficiunt. In hoc casu, si eventus non repones diu ac historiam cum trends in aliqua alia repositione jejunii, tunc generatim, ut opinor, nullae erunt difficultates.
A: – Potesne aestimare quanto citius omnia operabuntur si ad Clickhouse vertas, exempli gratia?
AG: - Non probavi. Eosdem saltem numeros omnino simpliciter effici posse existimo, cum Clickhouse suum interfacetum habeat, sed certo dicere non possum. Melius praesent probare. Totum in schemate, quot virtutes habes, et cetera. Unum est interserens, sed etiam opus est ut hanc notationem capias - Grafana vel aliquid aliud.
A: – Sic loquimur de pari pugna, et non de magno horum jejuniorum database commodo?
AG: – Puto cum integramus, accuratior probatio erit.
A: - Ubi bonus RRD senex ibimus? Quid tu vertas ad SQL databases? Initio omnia metrica in RRD collecta sunt.
AG: — Zabbix RRD habuit, fortasse in versione perantiqua. Semper database SQL fuerunt - ordo classicus. Ordo accessus est MySQL, PostgreSQL (extiterunt diutissime). Fere numquam usi sumus communi instrumento pro databases SQL et RRD.
Quidam ads
Gratias tibi ago pro manendo nobiscum. Placetne tibi vasa nostra? Vis videre plus interesting contentus? Suscipe nos ponendo ordinem vel commendando amicos; , unicum analogum de ingressu servientibus, quod a nobis pro vobis est inventum: (praesto cum RAID1 et RAID10, usque ad 24 coros et usque ad 40GB DDR4).
Dell R730xd 2x vilius in Equinix Tier IV centri Amstelodami? Tantum hic in Belgio! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - from $99! Read about
Source: www.habr.com