MMXIX est, et adhuc non habemus solutionem regulae pro logis aggregationis in Kubernetes. In hoc articulo volumus, exemplis adhibitis de usu reali, inquisitiones nostras, problemata congressa eorumque solutiones communicare.
Prius tamen reservandum dabo quod diversae clientes intelligant res longe diversas colligendo omnia:
- aliquis videre cupit securitatem et audit acta;
- aliquis - centralized logging of the entire infrastructure;
- et pro aliquibus, sufficit ad colligendas tantum appositiones, exclusis puta librariis.
Infra cut infra de quomodo varias "voluntates indices" implevimus et quas difficultates invenimus.
Theoria: de instrumentorum logging
Background in components systema logging
Logging longissima via venit, ex quibus methodologiae colligendae et examinandae materias ortae sunt, quae hodie utimur. Retro in 1950s, Fortran analogum vexillum input/output fluminum induxit, qui programmatorem suum programmatis debug adiuvit. Haec omnia computatoria primi fuerunt quae vitam programmatibus illorum temporum faciliorem reddebant. Hodie in illis videmus primum systematis colligationis - fons vel "productor" lignorum.
Scientia computatrum non stetit: retiacula computatralia apparuerunt, primum ligaturae... Systemata complexa pluribus computatoribus constans laborare incepit. Nunc administratores systematis ex pluribus machinis ligna colligere coacti sunt et in casibus specialibus nuntiis nucleos OS addere poterant si opus esset ad defectum systematis investigandi. Ad centralem tabulam collectionis systematis describendam, in primis 2000s publicatum est quae normae sunt remotae_syslog. Hoc modo alia pars magna apparuit: iniuriarum collector ac reposita.
Crescente in volumine lignorum et diffusae technologiarum interretialium introductio, quaesitum est quidnam indices usoribus commode ostendantur. Instrumenta simplicia consolatoria (awk/sed/grep) substituta sunt a provectis log viewers β Tertia pars.
Aucto codice, aliquid aliud patuit: omnia opus sunt, sed non omnia. Et alia ligna requirunt diversos gradus conservationis: alii uno die amitti possunt, alii per 5 annos condi. Ita, elementum eliquandi et emittendi notitiae profluvia, systematis logging addita est - illud invocemus filter.
Repono etiam plus saltum fecit: ex fasciculis regularibus ad databases relationum, et deinde ad tabulam repositam ordinandam (exempli gratia: Elasticsearch). Ita tabularium a collectore separatum est.
Postremo conceptus ipse stipes ad quendam abstractum rerum cursum dilatavit, quem historiae servare volumus. Vel potius, si opus est investigationem ducere vel relationem analyticam conficere.
Quam ob rem, secundum breve temporis spatium, collectio stipes in subsystem notabile processit, quod merito unum ex ordinibus in Big Data dici potest.
Si olim vulgares vestigia satis esse possent ad "logging system", nunc condicio multum mutata est.
Kubernetes et acta
Cum Kubernetes ad infrastructuram accesserunt, problema iam existens de lignis colligendis non praetermittebat. Nonnullis modis etiam acerbius factum est: administrandi suggestum infrastructurae non solum simpliciores, sed etiam simul complicatae. Multa vetera officia in microservias migrare inceperunt. In contextu lignorum, hoc relucet in crescente numero fontium stipatorum, peculiaris vitae cycli, ac necessitatem investigare relationes omnium systematis partium per tigna...
Prospiciens, affirmare nunc, proh dolor, nullam esse optionis logentiae normae Kubernetes quae cum omnibus aliis benigne compararet. Maxime populares technae in communitate sunt hae:
- evolvit aliquem ACERVUS EFK (Elasticsearch, Fluentd, Kibana);
- aliquis quaerit nuper dimisit seu usus ;
- Π½Π°Ρ (et fortasse non solum nos? Valde contentus sum progressu meo - ...
Pro regula utimur fasciculis sequentibus in ligaturas K8s (pro solutionibus auto-hostilibus);
- ;
- .
In mandatis tamen institutionis et configurationis eorum non moror. Sed vitia eorum et conclusiones magis globales de situ cum lignis in genere intendam.
Exercere trabes in K8s
"Quotidie omnia", quot sunt ibi?..
Collectio lignorum centralised ex magno infrastructura magnas opes requirit, quae in colligendis, thesauris et dispensandis expendendae erunt. In operatione variis inceptis, variis postulationibus et operationibus quaestionibus ex eis ortis.
ClickHouse scriptor experiri
Intueamur in repositione centralised in consilio cum applicatione quae ligna omnino activo modo gignit: plus quam quinque lineas per secundam. Incipiamus opus cum suis lignis, addendo ad ClickHouse.
Cum primum realis tempus maximum requiritur, 4-coris server cum ClickHouse iam in orbe subsystem cumulabitur:
Hoc genus onerationis ex eo est quod conamur quam celerrime in crypta scribere. Et datorum ad hoc redundat cum onere orbis aucto, quod sequentes errores causare potest:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
Punctum est, in ClickHouse (insunt notitias stipes) suas difficultates habent inter operationes scribendas. Notitia illis inserta generat temporariam partitionem, quae tunc cum tabula principalis coalescit. Quam ob rem memoria evenit ut multum exigat in orbe, et etiam limitationi subiecta est, quam supra noticiam recepimus: non plus quam 1 subpartitiones in secunda 300 immergi possunt (re vera haec 300 adiiciunt. secundo).
Hoc vitare mores, in quam maximas partes quam maxime et non plus quam 1 tempus omne 2 seconds. Sed scriptura in magnis prorumpitur, ut minus saepe in ClickHouse scribere debeamus. Hoc vicissim potest ad quiddam redundantia et detrimentum lignorum ducere. Solutio est quiddam Fluentd augere, sed memoria tabem etiam augere.
illud: Alia ratio problematica solutionis nostrae cum ClickHouse relata est ad hoc quod partitio in casu nostro (loghouse) impletur per tabulas externas connexas. . Hinc apparet, quod, cum magna temporis intervalla sampling, superfluus RAM exigitur, cum per omnes saepta metabilis iteratur - etiam ea quae necessarias notitias manifesto non continent. Nunc tamen hic accessus tuto obsoleta declarari potest pro emendationibus ClickHouse currentis (c ).
Quam ob rem patefacit non omne consilium sufficere facultates ad colligendas res in tempore reali in ClickHouse ( planius, earum distributio non congruens erit). Praeterea, necesse est uti altiliumad quod postea revertemur. Casus suprascriptus est verus. Et tunc non potuimus offerre solutionem certam et stabilem quod emptori conveniret et nos permitteremus ligna colligere minima mora...
Quid de Elasticsearch?
Investigatio elastica notum est ad onera gravia tractare. Experiamur in eodem documento. Nunc onus hoc spectat;
Investigatio elastica notitias fluminis concoquere potuit, attamen tales codices scribens ad CPU valde utetur. hoc est botrum ordinando. Technice, hoc problema non est, sed evenit ut iusta operantur stipes collectionis systematis quo iam circiter 8 coros utimur et additam habent partem in systemate onerato valde oneratam...
Fundus linea: haec optio iustificari potest, sed tantum consilium magnum est et eius administratio parata est ut significantes facultates in systemate centralizato colligationis expendat.
Deinde oritur quaestio naturalis;
Quae omnia opus sunt?
Studeamus ipsum accessum mutare: tigna simul informativa et non opercula sint quisque res in systemate.
Dicamus nos prosperos habere online copia. Quae omnia magni momenti sunt? Nullam quam quam, enim vel, pretium porta, magna elit. Sed non omnia tigna ex imagine slicing muneris in producto catalogo critica nobis sunt: ββtantum errores et vigilantia provecta satis sunt (exempli gratia, recipis 500 errores quos haec pars generat).
Venimus igitur ad conclusionem centralized logging non semper iustificatur. Saepius cliens omnia ligna in unum locum colligere vult, re vera ex toto stipite, conditionalis tantum 5% epistularum quae ad rem criticam requiruntur;
- Aliquando satis est configurare, dicere, quantitatem tantum continentis stipes et errorem collectoris (exempli gratia: Sentry).
- Error notificatio et index ipse locus magnus saepe satis erit ad res investigandas.
- Incepta habuimus quae fecimus cum probationibus solum functionibus et errorum systematum collectorum. Elit tigna non egebat ut talia - vestigia errorum omnia videbant.
Illustratio de vita
Alia fabula bono exemplo inservire potest. Petitionem accepimus a quadrigis securitatis unius clientium nostrorum qui iam solutione commerciali utebantur quae multo ante Kubernetes inducta est.
Necesse erat "amicos facere" systematis collectionis centralised logorum cum problematum corporatum detectionis sensorem - QRadar. Haec ratio omnia per sysloga protocollo recipere potest et ab FTP recuperare. Sed statim non potuit eam integrare cum plugin remote_syslog pro fluente (Sicut accidit, ). Problemata erigens QRadar evasit ex parte quadrigis securitatis huius.
Quam ob rem pars tignorum negotiatorum criticorum ad FTP QRadar immissa est, et altera pars per syslogam remotam directe a nodis directa est. Hoc enim et nos scripsimus - fortasse iuvabit aliquem similem problema solvendi... Propter propositum consequens, ipse cliens omnia critica (utendo instrumentis dilectis suis instrumenta) accepit et enucleavit, et sumptus logging systematis minuere poteramus, excepto modo. mensem ultimum.
Aliud exemplum satis indicatum est quid non faciamus. Unus e nostris clientibus pro dispensando quisque certe ex usuario multilineo facta unstructured output information in log. Cum coniecturam faceres, talia ligna valde incommodi erant tam legere quam reponunt.
Criteria ad omnia
Exempla huiusmodi conclusionem ducunt quod praeter rationem collectionis stipem eligendo, debes et excogitant omnia ipsa! Quid hic opus est?
- Acta publica omnia in forma legendi apparatus esse debent (exempli gratia JSON).
- Tigna pacta esse debent et cum facultate logging mutare gradum ut problemata possibilia debug. Simul in ambitus productionis systemata currere debes cum gradu colligationis sicut Admonitio aut Error.
- Tigna normalizari debent, id est, in obiecto stipes, omnes lineae eiusdem generis campi habere debent.
Tigna informia ducere possunt ad difficultates cum oneratione lignorum in repositione ac sistenda completa in eorum processu. Ad illustrationem, hic est exemplum erroris 400, quem multi in disertis lignis definite invenerunt;
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
Error significat eum agrum mittis, cuius generis indicem cum destinatione prompta est inconstans. Simplicissimum exemplum est ager in nginx stipes cum variabili $upstream_status. Continere potest vel numerum vel chorda. Exempli gratia:
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}
Haec omnia ostendunt servo 10.100.0.10 respondisse cum 404 errore et rogatu misso ad aliud repositorium contentum. Quam ob rem talis valor in lignis factus est;
"upstream_response_time": "0.001, 0.007"
Haec condicio tam communis est ut etiam separatum meretur .
Quid de fide?
Aliquando sunt omnia ligna sine exceptione vitalia. Et cum hoc, technicae collectionis typicae stipes K8s propositae/disputatae habent difficultates.
Exempli causa, disertus ligna ex brevibus vasis colligere non potest. In una inceptis nostris, migratio datorum continens minus quam 4 secundis vixit et postea deleta est - secundum respondentem annotationem:
"helm.sh/hook-delete-policy": hook-succeeded
Propter hoc, migratio exsecutionis stipes in repositione non inclusa est. Politica hoc casu iuvare potest. before-hook-creation.
Aliud exemplum est Docker log rotationis. Dicamus applicationem esse quae scribit ad acta actuose. Sub normalibus conditionibus omnia ligna disponere procuramus, sed statim ut quaestio apparet - exempli gratia, sicut supra descripsimus cum forma recta - processus clausuris, et Docker tabellam rotat. Ita fit ut omnia negotia critica pereant.
Hoc est cur refert separare iniuriarum fluminumimmerentes pretiosissimas directe in applicatione ad eorum salutem. Praeterea non esset superfluum aliquid creare "Accumulator" lignorumquae supervivere possunt breves repositiones necessariae dum nuntii critici servati sunt.
Denique oblivisci non debemus Aliquam sit amet recte subsystem ad Monitor. Alioquin facile est incurrere in condicionem, in qua fluens est in statu CrashLoopBackOff et non mittit aliquid, et iacturam magnarum rerum promittit.
Inventiones
In hoc articulo, solutiones Saas sicut Datadog non spectamus. Multae problematum hic descriptorum iam uno vel alio modo solutae sunt a societatibus commercialibus specialiter in colligendis lignis, sed non omnes variis de causis Saas uti possunt. (Principales sunt sumptus et obsequio cum 152-FZ).
Collectio stipes centralised primum ut simplex negotium spectat, sed minime. Is est maximus ut meminerint;
- Sola elementa critica singillatim incipienda sunt, dum vigilantia et errorum collectio pro aliis systematibus configurari potest.
- Tigna in productione minima servanda sunt ne onus superfluum adiciatur.
- Tigna necesse est esse machinam lectabilem, normalizatam, et strictam formam habere.
- Res criticae in rivum separatum mitti debent, qui ab praecipuis secerni debent.
- Operae pretium est considerare truncum accumulatorem, qui te ab eruptionibus magni oneris liberare potest et onus in repositoria magis aequabilius facere.
Hae regulae simplices, si ubique applicantur, permittunt ambitus supra descriptos ad operandum, etsi desunt momenti partes (in altilium). Si talibus principiis non adhaeres, negotium facile te ducet et substructurae ad aliam rem onustam (et simul inefficacem) componentes systematis ducet.
PS
Lege etiam in nostro diario:
- Β«";
- Β«";
- Β«".
Source: www.habr.com