Ew 2019 e, û me hîn jî çareseriyek standard ji bo berhevkirina têketinê li Kubernetes nîne. Di vê gotarê de, em dixwazin, nimûneyên ji pratîka rastîn bikar bînin, lêgerînên xwe, pirsgirêkên ku hatine û çareseriyên wan parve bikin.
Lêbelê, pêşî, ez ê rezervasyonek bikim ku xerîdarên cûda bi berhevkirina têketin tiştên pir cûda fam dikin:
- kesek dixwaze têketinên ewlehiyê û kontrolê bibîne;
- kesek - têketina navendî ya tevahiya binesaziyê;
- û ji bo hinekan, bes e ku meriv tenê têketinên serîlêdanê berhev bike, ji bo nimûne, hevsengkeran ji holê rabike.
Li jêr qutkirina jêrîn li ser ka me çawa "lîsteyên xwestekên" cihêreng bicîh anîn û em rastî çi zehmetiyan hatin.
Teorî: li ser amûrên têketinê
Paşîn li ser pêkhateyên pergala têketinê
Têketin rêyek dirêj derbas bûye, di encamê de metodolojiyên berhevkirin û analîzkirina têketin hatine pêşve xistin, ya ku em îro bikar tînin ev e. Vegere di salên 1950-an de, Fortran analogek pêlên têketin / derketinê yên standard destnîşan kir, ku ji bernameçêker re bû alîkar ku bernameya xwe debuke. Ev yekem têketinên komputerê bûn ku jiyan ji bo bernamenûsên wan deman hêsantir kir. Îro em di wan de beşa yekem a pergala têketinê dibînin - çavkanî an "hilberînerê" têketin.
Zanista kompîturê li ber xwe neda: şebekeyên kompîturê xuya bûn, komikên pêşîn... Sîstemên tevlihev ku ji çend komputeran pêk tên dest bi xebatê kirin. Naha rêvebirên pergalê neçar bûn ku têketin ji gelek makîneyan berhev bikin, û di rewşên taybetî de ew dikaribûn peyamên kernel OS-ê zêde bikin heke hewce bike ku têkçûnek pergalê lêkolîn bikin. Ji bo danasîna pergalên berhevkirina têketinên navendî, di destpêka salên 2000-an de hate weşandin , ku remote_syslog standard kir. Bi vî rengî pêkhateyek din a girîng xuya bû: berhevkarê têketinê û depokirina wan.
Bi zêdebûna hêjmara têketin û danasîna berfireh a teknolojiyên malperê re, pirs derket holê ka çi têketin hewce ye ku bi hêsanî ji bikarhêneran re werin xuyang kirin. Amûrên konsolê yên hêsan (awk/sed/grep) bi yên pêşkeftî hatine guheztin temaşevanên têketinê - pêkhateya sêyemîn.
Ji ber zêdebûna qebareya têketinê, tiştek din eşkere bû: têketin hewce ne, lê ne hemî. Û têketinên cûda hewceyê astên cûda yên parastinê hene: hin dikarin di rojekê de winda bibin, lê yên din hewce ne ku ji bo 5 salan bêne hilanîn. Ji ber vê yekê, hêmanek ji bo parzûnkirin û rêvekirina herikîna daneyan li pergala têketinê hate zêdekirin - em jê re bibêjin parzûn.
Storage di heman demê de gavek mezin çêkir: ji pelên birêkûpêk berbi databasên têkildar, û dûv re berbi hilanîna belge-oriented (mînak, Elasticsearch). Ji ber vê yekê depo ji kolektorê hate veqetandin.
Di dawiyê de, têgeha têgihiştinê berbi celebek bûyerek razber a ku em dixwazin ji bo dîrokê biparêzin berfireh bûye. An jî, heke hûn hewce ne ku lêkolînek bikin an raporek analîtîk amade bikin ...
Wekî encamek, di demek kin de, berhevkirina têketinê di binepergalek girîng de pêşve çû, ku bi rast dikare yek ji beşan di Daneyên Mezin de were binav kirin.
Ger carekê çapên asayî ji bo "pergalek têketinê" bes be, naha rewş pir guherî ye.
Kubernetes û têketin
Dema ku Kubernetes hat binesaziyê, pirsgirêka heyî ya berhevkirina têketin jî ew derbas nekir. Bi hin awayan, ew hê bêtir bi êş bû: birêvebirina platforma binesaziyê ne tenê hêsan bû, lê di heman demê de tevlihev bû. Gelek karûbarên kevin dest bi koçkirina mîkro-servîsan kirine. Di çarçoweya têketinan de, ev di zêdebûna hejmara çavkaniyên têketinê, çerxa jiyana wan a taybetî de, û hewcedariya şopandina têkiliyên hemî pêkhateyên pergalê bi têketin tê xuyang kirin ...
Li pêş çavê min, ez dikarim bibêjim ku naha, mixabin, ji bo Kubernetes vebijarkek têketinê ya standardkirî tune ku bi hemî yên din re xweş were berhev kirin. Di nav civakê de planên herî populer ev in:
- kesek stikê vedike EFK (Elasticsearch, Fluentd, Kibana);
- kesek hewl dide ku vê dawiyê serbest hat berdan an bikar tîne ;
- me (û dibe ku ne tenê em?..) Ez bi gelemperî ji pêşkeftina xwe razî me - ...
Wekî qaîdeyek, em di komikên K8s de pakêtên jêrîn bikar tînin (ji bo çareseriyên xwemalî):
- ;
- .
Lêbelê, ez ê li ser rêwerzên ji bo sazkirin û veavakirina wan nesekinim. Di şûna wê de, ez ê li ser kêmasiyên wan û encamên gerdûnîtir di derbarê rewşa têketin bi gelemperî de bisekinim.
Bi têketinên di K8s de pratîk bikin
"Ketên rojane", çend ji we hene?..
Komkirina navendîkirî ya têketinên ji binesaziyek pir mezin pêdivî bi çavkaniyên girîng heye, ku dê ji bo berhevkirin, hilanîn û hilanîna têketin were xerc kirin. Di dema xebitandina gelek projeyên cuda de, em bi gelek hewcedarî û pirsgirêkên xebitandinê yên ku ji wan derdiketin re rû bi rû man.
Ka em ClickHouse biceribînin
Ka em li ser projeyek bi serîlêdanek ku têketinek bi rengek çalak çêdike li hilanînek navendî binihêrin: ji 5000 xêzan di çirkeyê de. Ka em bi têketinên wî re dest bi xebatê bikin, wan li ClickHouse zêde bikin.
Mîna ku herî zêde dema rast hewce be, servera 4-bingehîn a bi ClickHouse dê berê li ser binepergala dîskê were barkirin:
Ev celeb barkirin ji ber vê yekê ye ku em hewl didin ku bi zûtirîn dem li ClickHouse binivîsin. Û databas bi zêdebûna barkirina dîskê re bertek nîşan dide, ku dikare bibe sedema xeletiyên jêrîn:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
Rast e ku di ClickHouse de (ew daneyên têketinê dihewîne) di dema operasyonên nivîsandinê de dijwariyên xwe hene. Daneyên ku di nav wan de têne danîn dabeşek demkî diafirîne, ku paşê bi tabloya sereke re tê yek kirin. Wekî encamek, tomar derdikeve ku li ser dîskê pir daxwazkar e, û ew di heman demê de bi sînorkirina ku me li jor agahdarî wergirtiye ve girêdayî ye: di 1 çirkeyê de ji 300 dabeşan zêdetir nikarin werin yek kirin (bi rastî, ev 300 insert e her çirke).
Ji bo ku ji vê tevgerê dûr bikevin, di perçeyên bi qasî ku pêkan de ye û ji her 1 saniyeyan carekê 2 carî zêdetir nebe. Lêbelê, nivîsandina bi teqînên mezin pêşniyar dike ku divê em kêm caran li ClickHouse binivîsin. Ev, di encamê de, dibe sedema zêdebûnek tampon û windakirina têketin. Çareserî zêdekirina tampona Fluentd e, lê wê hingê dê mezaxtina bîranînê jî zêde bibe.
bingotin: Aliyekî din ê pirsgirêkê yê çareseriya me ya bi ClickHouse re bi vê yekê ve girêdayî bû ku dabeşkirina di doza me de (loghouse) bi tabloyên derveyî ve girêdayî tête bicîh kirin. . Ev rê li ber vê yekê vedike ku dema nimûneyên navberên demkî yên mezin, RAM-a zêde hewce ye, ji ber ku metable di nav hemî dabeşan de dubare dibe - tewra yên ku eşkere daneyên pêwîst nagirin. Lêbelê, naha ev nêzîkatî dikare bi ewlehî ji bo guhertoyên heyî yên ClickHouse (c ).
Wekî encamek, eşkere dibe ku ne her proje çavkaniyên têra xwe hene ku di wextê rast de li ClickHouse têketin berhev bike (bi rastî, belavkirina wan dê ne guncaw be). Herweha, hûn ê hewce ne ku bikar bînin aktîv, ku em ê paşê vegerin. Doza ku li jor hatî behs kirin rast e. Û di wê demê de me nekarî çareseriyek pêbawer û bi îstîqrar pêşkêşî bikin ku li gorî xerîdar be û rê bide me ku em bi derengiya hindiktirîn têketin berhev bikin…
Li ser Elasticsearch çi ye?
Elasticsearch tête zanîn ku karên giran dike. Ka em wê di heman projeyê de biceribînin. Niha barkirin wiha xuya dike:
Elasticsearch karîbû ku çemê daneyê bişewitîne, lêbelê, nivîsandina cildên weha jê re pir CPU-yê bikar tîne. Ev bi organîzekirina komekê tê biryar. Ji hêla teknîkî ve, ev ne pirsgirêkek e, lê diqewime ku tenê ji bo xebitandina pergala berhevkirina têketinê em jixwe nêzî 8 core bikar tînin û di pergalê de hêmanek pir zêde barkirî heye ...
Rêza jêrîn: ev vebijark dikare rastdar be, lê tenê heke proje mezin be û rêveberiya wê amade ye ku çavkaniyên girîng li ser pergalek têketinek navendî xerc bike.
Wê demê pirsek xwezayî derdikeve holê:
Çi têketin bi rastî hewce ne?
Ka em hewl bidin ku nêzîkatiya xwe biguhezînin: têketin divê di heman demê de agahdar bin û ne veşêrin herkes bûyer di pergalê de.
Ka em bêjin firotgehek serhêl a me ya serketî heye. Çi têketin girîng in? Berhevkirina bi qasî ku gengaz dibe, mînakî, ji dergehek dravdanê, ramanek mezin e. Lê ne hemî têketinên ji karûbarê kişandina wêneyê di kataloga hilberê de ji me re krîtîk in: tenê xeletî û çavdêriya pêşkeftî bes in (mînak, rêjeya 500 xeletiyên ku ev pêkhate çêdike).
Ji ber vê yekê em gihîştin wê encamê têketina navendî her gav ne rastdar e. Pir caran xerîdar dixwaze hemî têketin li yek cîhek berhev bike, her çend bi rastî, ji tevahî têketinê, tenê 5% ji peyamên ku ji bo karsaziyê krîtîk in hewce ne:
- Carinan bes e ku meriv bêje, tenê mezinahiya têketina konteynerê û berhevkarê xeletiyê mîheng bike (mînak, Sentry).
- Agahiyek xeletî û têketinek herêmî ya mezin bixwe dibe ku pir caran ji bo lêkolînkirina bûyeran bes be.
- Projeyên me hebûn ku tenê bi ceribandinên fonksiyonel û pergalên berhevkirina xeletiyan pêk dihat. Pêşdebir ne hewceyî têketinên weha bû - wan her tişt ji şopên xeletiyê dît.
Illustration ji jiyanê
Çîrokek din dikare wekî mînakek baş be. Me daxwazek ji tîmê ewlehiyê yê yek ji xerîdarên me wergirt ku berê çareseriyek bazirganî ya ku demek dirêj berî danasîna Kubernetes hatî pêşve xistin bikar tîne.
Pêwîst bû ku bi senzora tespîtkirina pirsgirêka pargîdanî - QRadar re pergala berhevkirina têketinê ya navendî "heval" çêbikin. Ev pergal dikare têketinên bi protokola syslogê werbigire û wan ji FTP bistîne. Lêbelê, tavilê ne gengaz bû ku wê bi pêveka remote_syslog-ê ya ji bo fluentd re were yek kirin. (wek ku derket holê, ). Pirsgirêkên bi sazkirina QRadar re derket holê ku ji hêla tîmê ewlehiya xerîdar ve ye.
Wekî encamek, beşek ji têketinên karsaziyê-krîtîk li FTP QRadar hate barkirin, û beşa din bi riya syslog-a dûr ve rasterast ji girêkan hate veguheztin. Ji bo vê jî me nivîsand - belkî ew ê ji kesekî re bibe alîkar ku pirsgirêkek bi vî rengî çareser bike... Bi saya pilana encamdan, xerîdar bixwe têketinên krîtîk (bi karanîna amûrên xweyên bijare) wergirtin û analîz kirin, û me karî mesrefa pergala têketinê kêm bikin, û tenê meha borî.
Mînakek din bi tevahî nîşan dide ku meriv çi neke. Yek ji xerîdarên me ji bo pêvajoyê ji her yekê bûyerên ku ji bikarhêner têne, pirzimanî çêkir hilbera nesazkirî agahî di têketinê de. Wekî ku hûn texmîn dikin, têketinên weha hem ji bo xwendin û hem jî ji bo hilanînê zehf nerehet bûn.
Pîvanên ji bo têketin
Mînakên weha rê li ber vê encamê digirin ku ji bilî hilbijartina pergala berhevkirina têketinê, hûn hewce ne jî dîzaynkirina têketin bi xwe! Pêdiviyên li vir çi ne?
- Pêdivî ye ku têketin di formata makîne-xwendinê de bin (mînak, JSON).
- Pêdivî ye ku têketin tevlihev bin û jêhatîbin ku asta têketinê biguhezînin da ku pirsgirêkên muhtemel ji holê rakin. Di heman demê de, di hawîrdorên hilberînê de divê hûn pergalên bi astek têketinê mîna rêve bibin Gazî an Şaşî.
- Pêdivî ye ku têketin normalîze bibin, ango di objeyek têketinê de, divê hemî rêzik xwediyê heman celebê zeviyê bin.
Têketinên nesazkirî dikare bibe sedema pirsgirêkan di barkirina têketin li hilanînê û rawestana bêkêmasî ya pêvajoya wan de. Wekî mînakek, li vir mînakek bi xeletiya 400 heye, ya ku pir kes bê guman di têketinên herikbar de rastî wan hatine:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
Çewtî tê vê wateyê ku hûn zeviyek ku celebê wê nestêbar e bi nexşeyek amade dişîne navnîşê. Mînaka herî hêsan zeviyek di têketina nginx de bi guhêrbar e $upstream_status. Ew dikare hejmarek an rêzek hebe. Bo nimûne:
{ "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"}
Têketin destnîşan dikin ku server 10.100.0.10 bi xeletiyek 404 bersiv da û daxwaz ji hilanîna naverokek din re hate şandin. Wekî encamek, nirxa di qeydan de weha bû:
"upstream_response_time": "0.001, 0.007"
Ev rewş ew qas gelemperî ye ku ji hev cuda jî heq dike .
Li ser pêbaweriyê çi ye?
Dem hene ku hemî têketin bêyî îstîsna girîng in. Û bi vê yekê re, nexşeyên berhevkirina têketinê yên tîpîk ên ji bo K8-ên ku li jor hatine pêşniyar kirin / nîqaş kirin pirsgirêk hene.
Mînakî, fluentd nikare têketin ji konteynirên demkurt berhev bike. Di yek ji projeyên me de, konteynera koçberiya databasê ji 4 çirkeyan kêmtir jiya û dûv re hate jêbirin - li gorî şîroveya têkildar:
"helm.sh/hook-delete-policy": hook-succeeded
Ji ber vê yekê, têketina darvekirina koçberiyê di hilanînê de nebû. Siyaset dikare di vê rewşê de bibe alîkar. before-hook-creation.
Mînakek din zivirîna têketinê ya Docker e. Ka em bibêjin serîlêdanek heye ku bi rengek çalak li têketin dinivîse. Di bin şert û mercên normal de, em rê didin ku hemî têketin pêvajoyê bikin, lê gava ku pirsgirêkek xuya dike - mînakî, wekî ku li jor bi formatek xelet hatî destnîşan kirin - pêvajo disekine, û Docker pelê dizivirîne. Encam ev e ku dibe ku têketinên karsaziyê-krîtîk winda bibin.
Ji ber vê yekê Girîng e ku çîmên têketinê ji hev veqetînin, şandina yên herî hêja rasterast di serîlêdanê de vedihewîne da ku ewlehiya wan misoger bike. Wekî din, çêkirina hinan dê ne zêde be "Acumulator" ya têketin, ku dikare dema ku peyamên krîtîk hilîne ji ber tunebûna hilanîna kurt bijî.
Di dawiyê de, divê em vê yekê ji bîr nekin Girîng e ku meriv her bine pergalê bi rêkûpêk çavdêrî bike. Wekî din, hêsan e ku meriv bikeve rewşek ku tê de fluentd di rewşek de ye CrashLoopBackOff û tiştek naşîne, û ev soz dide windakirina agahdariya girîng.
vebiguherin
Di vê gotarê de, em li çareseriyên SaaS yên mîna Datadog nanihêrin. Gelek pirsgirêkên ku li vir têne diyar kirin jixwe ji hêla pargîdaniyên bazirganî yên ku di berhevkirina têketinê de pispor in bi rengekî an din hatine çareser kirin, lê her kes nikare ji ber sedemên cihêreng SaaS bikar bîne. (Yên sereke lêçûn û lihevhatina 152-FZ ne).
Berhevkirina têketinê ya navendî di destpêkê de wekî karekî hêsan xuya dike, lê ew ne wusa ye. Pêdivî ye ku ji bîr mekin ku:
- Tenê hêmanên krîtîk hewce ne ku bi hûrgulî bêne tomar kirin, dema ku çavdêrî û berhevkirina xeletiyan dikare ji bo pergalên din were mîheng kirin.
- Têketinên di hilberînê de divê hindik werin girtin da ku barek nehewce zêde neke.
- Pêdivî ye ku têketin bi makîneyê bêne xwendin, normalîzekirin, û xwedan formatek hişk bin.
- Pêdivî ye ku têketinên bi rastî krîtîk di çemek cûda de bêne şandin, ku divê ji yên sereke bêne veqetandin.
- Hêja ye ku meriv berhevkerek têketinê bifikire, ku dikare we ji teqînên bargiraniya bilind xilas bike û barê li ser hilanînê yekrengtir bike.
Van qaîdeyên sade, ger li her deverê werin sepandin, dê rê bidin ku çerxên ku li jor hatine destnîşan kirin bixebitin - her çend ew hêmanên girîng winda nebin (batarya). Ger hûn li gorî prensîbên weha tevnegerin, peywir dê bi hêsanî we û binesaziyê berbi hêmanek din a pergalê ya pir barkirî (û di heman demê de bêbandor) ve bibe.
PS
Li ser bloga me jî bixwînin:
- «»;
- «»;
- «".
Source: www.habr.com