Ĉu monitorado estas morta? — Vivu monitorado

Ekde 2008, nia kompanio ĉefe okupiĝas pri infrastruktura administrado kaj daŭra teknika subteno por retprojektoj: ni havas pli ol 400 klientojn, kio estas ĉirkaŭ 15% de rusa elektronika komerco. Sekve, tre diversa arkitekturo estas subtenata. Se io falas, ni devas ripari ĝin ene de 15 minutoj. Sed por kompreni, ke akcidento okazis, vi devas kontroli la projekton kaj respondi al okazaĵoj. Kiel fari ĉi tion?

Mi kredas, ke estas problemo en organizado de taŭga monitora sistemo. Se ne estus problemo, tiam mia parolado konsistus el unu tezo: "Bonvolu instali Prometheus + Grafana kaj kromaĵojn 1, 2, 3." Bedaŭrinde, ĝi ne plu funkcias tiel. Kaj la ĉefa problemo estas, ke ĉiuj daŭre kredas je io, kio ekzistis en 2008, koncerne programajn komponantojn.

Pri la organizado de la monitora sistemo, mi kuraĝus diri, ke... projektoj kun kompetenta monitorado ne ekzistas. Kaj la situacio estas tiel malbona, ke se io falas, ekzistas risko, ke ĝi restos nerimarkita - finfine ĉiuj certas, ke "ĉio estas kontrolata".
Eble ĉio estas kontrolata. Sed kiel?

Ni ĉiuj renkontis rakonton kiel la jena: certa devops, certa administranto funkcias, evolua teamo venas al ili kaj diras - "ni estas liberigitaj, nun monitoras." Monitori kio? Kiel ĝi funkcias?

BONE. Ni kontrolas la malnovan manieron. Kaj ĝi jam ŝanĝiĝas, kaj rezultas, ke vi monitoris la servon A, kiu fariĝis servo B, kiu interagas kun la servo C. Sed la disvolva teamo diras al vi: "Instu la programaron, ĝi devus kontroli ĉion!"

Kio do ŝanĝiĝis? - Ĉio ŝanĝiĝis!

2008 Ĉio estas en ordo

Estas kelkaj programistoj, unu servilo, unu datumbaza servilo. Ĉio iras de ĉi tie. Ni havas kelkajn informojn, ni instalas zabbix, Nagios, kaktojn. Kaj tiam ni starigas klarajn atentigojn pri la CPU, pri diskfunkciado kaj sur diskspaco. Ni ankaŭ faras kelkajn manajn kontrolojn por certigi, ke la retejo respondas kaj ke mendoj alvenas en la datumbazon. Kaj jen ĝi - ni estas pli-malpli protektataj.

Se ni komparas la kvanton da laboro kiun la administranto faris tiam por provizi monitoradon, tiam 98% de ĝi estis aŭtomata: la persono kiu faras la monitoradon devas kompreni kiel instali Zabbix, kiel agordi ĝin kaj agordi atentigojn. Kaj 2% - por eksteraj kontroloj: ke la retejo respondas kaj faras peton al la datumbazo, ke novaj mendoj alvenis.

2010 La ŝarĝo kreskas

Ni komencas grimpi la retejon, aldonante serĉilon. Ni volas certigi, ke la produkta katalogo enhavas ĉiujn produktojn. Kaj tiu produkta serĉo funkcias. Ke la datumbazo funkcias, ke mendoj estas faritaj, ke la retejo respondas ekstere kaj respondas de du serviloj kaj la uzanto ne estas forĵetita el la retejo dum ĝi estas rebalancita al alia servilo, ktp. Estas pli da estaĵoj.

Plie, la ento asociita kun infrastrukturo ankoraŭ restas la plej granda en la kapo de la administranto. Ankoraŭ estas ideo en mia kapo, ke la persono faranta la monitoradon estas la persono, kiu instalos zabbix kaj povos agordi ĝin.

Sed samtempe aperas laboro pri farado de eksteraj kontroloj, pri kreado de aro da serĉaj indeksaj demandaj skriptoj, aro da skriptoj por kontroli, ke la serĉo ŝanĝiĝas dum la indeksa procezo, aro da skriptoj, kiuj kontrolas, ke varoj estas transdonitaj al la livera servo, ktp. kaj tiel plu.

Noto: Mi skribis "aro da skriptoj" 3 fojojn. Tio estas, la respondeca pri monitorado ne plu estas tiu, kiu simple instalas zabbix. Ĉi tiu estas homo, kiu komencas kodigi. Sed nenio ŝanĝiĝis en la menso de la teamo ankoraŭ.

Sed la mondo ŝanĝiĝas, fariĝas pli kaj pli kompleksa. Virtualiga tavolo kaj pluraj novaj sistemoj estas aldonitaj. Ili komencas interagi unu kun la alia. Kiu diris "odoras kiel mikroservoj?" Sed ĉiu servo ankoraŭ aspektas kiel retejo individue. Ni povas turni sin al ĝi kaj kompreni, ke ĝi provizas la necesajn informojn kaj funkcias memstare. Kaj se vi estas administranto konstante engaĝita en projekto kiu disvolviĝas de 5-7-10 jaroj, ĉi tiu scio akumuliĝas: aperas nova nivelo - vi konstatis ĝin, aperas alia nivelo - vi konstatis ĝin...

Sed malofte iu akompanas projekton dum 10 jaroj.

La vivresumo de Monitoringman

Supozu, ke vi venis al nova ekentrepreno, kiu tuj dungis 20 programistojn, skribis 15 mikroservojn, kaj vi estas administranto al kiu oni diras: "Konstruu CI/KD. Bonvolu." Vi konstruis CI/KD kaj subite vi aŭdas: "Estas malfacile por ni labori kun produktado en "kubo", sen kompreni kiel la aplikaĵo funkcios en ĝi. Faru al ni sablokeston en la sama "kubo".
Vi faras sablokeston en ĉi tiu kubo. Ili tuj diras al vi: "Ni volas scenejan datumbazon, kiu estas ĝisdatigita ĉiutage de produktado, por ke ni komprenu, ke ĝi funkcias en la datumbazo, sed samtempe ne difektas la produktan datumbazon."

Vi vivas en ĉio ĉi. Restas 2 semajnoj antaŭ la liberigo, ili diras al vi: "Nun ni kontrolu ĉion ĉi..." Tio estas. monitoru la clusterinfrastrukturon, monitoru la mikroservan arkitekturon, monitoru laboron kun eksteraj servoj...

Kaj miaj kolegoj forprenas de sia kapo la kutiman skemon kaj diras: „Nu, ĉio estas klara ĉi tie! Instalu programon, kiu kontrolos ĉion ĉi." Jes, jes: Prometheus + Grafana + kromaĵojn.
Kaj ili aldonas: "Vi havas du semajnojn, certigu, ke ĉio estas sekura."

En multaj projektoj kiujn ni vidas, unu persono estas asignita por monitorado. Imagu, ke ni volas dungi personon por fari monitoradon dum 2 semajnoj, kaj ni skribas vivresumon por li. Kiajn kapablojn havu ĉi tiu persono, konsiderante ĉion, kion ni diris ĝis nun?

• Li devas kompreni la monitoradon kaj specifaĵojn de la funkciado de la fera infrastrukturo.
• Li devas kompreni la specifaĵojn pri monitorado de Kubernetes (kaj ĉiuj volas iri al la "kubo", ĉar vi povas abstrakti de ĉio, kaŝi, ĉar la administranto traktos la reston) - mem, ĝian infrastrukturon, kaj kompreni kiel kontroli aplikojn. interne.
• Li devas kompreni, ke servoj komunikas unu kun la alia laŭ specialaj manieroj, kaj scii la specifaĵojn de kiel servoj interagas inter si. Estas tute eble vidi projekton, kie iuj servoj sinkrone komunikas, ĉar ne ekzistas alia maniero. Ekzemple, la backend iras per REST, per gRPC al la katalogo-servo, ricevas liston de produktoj kaj resendas ĝin. Vi ne povas atendi ĉi tie. Kaj kun aliaj servoj ĝi funkcias nesinkrone. Transdonu la mendon al la liverservo, sendu leteron ktp.
  Vi verŝajne jam naĝis el ĉio ĉi? Kaj la administranto, kiu bezonas kontroli ĉi tion, iĝis eĉ pli konfuzita.
• Li devas povi ĝuste plani kaj plani – ĉar la laboro fariĝas pli kaj pli.
• Li do devas krei strategion de la kreita servo por kompreni kiel specife kontroli ĝin. Li bezonas komprenon de la arkitekturo de la projekto kaj ĝia evoluo + komprenon de la teknologioj uzitaj en evoluo.

Ni memoru absolute normalan kazon: iuj servoj estas en PHP, iuj servoj estas en Go, iuj servoj estas en JS. Ili iel laboras unu kun la alia. Jen de kie venas la termino "mikroservo": ekzistas tiom da individuaj sistemoj, ke programistoj ne povas kompreni la projekton kiel tuton. Unu parto de la teamo skribas servojn en JS, kiuj funkcias memstare kaj ne scias kiel funkcias la resto de la sistemo. La alia parto skribas servojn en Python kaj ne malhelpas kiel funkcias aliaj servoj; ili estas izolitaj en sia propra areo. La tria estas skribi servojn en PHP aŭ io alia.
Ĉiuj ĉi tiuj 20 homoj estas dividitaj en 15 servojn, kaj ekzistas nur unu administranto, kiu devas kompreni ĉion ĉi. Ĉesu! ni simple dividis la sistemon en 15 mikroservojn ĉar 20 homoj ne povas kompreni la tutan sistemon.

Sed ĝi devas esti kontrolita iel...

Kio estas la rezulto? Kiel rezulto, estas unu homo, kiu eniras en sian kapon ĉion, kion la tuta teamo de programistoj ne povas kompreni, kaj samtempe li ankaŭ devas scii kaj povi fari tion, kion ni indikis supre - aparatara infrastrukturo, Kubernetes-infrastrukturo ktp.

Kion mi povas diri... Houston, ni havas problemojn.

Monitorado de moderna programara projekto estas programara projekto en si mem

De la falsa kredo, ke monitorado estas programaro, ni disvolvas kredon je mirakloj. Sed mirakloj, ve, ne okazas. Vi ne povas instali zabbix kaj atendi ke ĉio funkcios. Ne utilas instali Grafana kaj esperi, ke ĉio estos en ordo. Plejparto de la tempo estos elspezita por organizi kontrolojn pri funkciado de servoj kaj ilia interago inter si, kontrolante kiel funkcias eksteraj sistemoj. Fakte, 90% de la tempo estos elspezitaj ne por verkado de skriptoj, sed por disvolvi programaron. Kaj ĝi devus esti pritraktita de teamo kiu komprenas la laboron de la projekto.
Se en ĉi tiu situacio unu persono estas ĵetita en monitoradon, tiam katastrofo okazos. Kio okazas ĉie.

Ekzemple, ekzistas pluraj servoj kiuj komunikas inter si per Kafka. La mendo alvenis, ni sendis mesaĝon pri la mendo al Kafka. Estas servo, kiu aŭskultas informojn pri la mendo kaj sendas la varojn. Estas servo, kiu aŭskultas informojn pri la mendo kaj sendas leteron al la uzanto. Kaj tiam aro pli da servoj aperas, kaj ni komencas konfuziĝi.

Kaj se vi ankaŭ donas ĉi tion al la administranto kaj programistoj en la stadio kiam restas mallonga tempo antaŭ la liberigo, la persono devos kompreni ĉi tiun tutan protokolon. Tiuj. Projekto de ĉi tiu skalo prenas signifan kvanton da tempo, kaj ĉi tio devus esti enkalkulita en la sistema evoluo.
Sed tre ofte, precipe en noventreprenoj, ni vidas kiel monitorado estas prokrastita ĝis poste. "Nun ni faros Pruvon de Koncepto, ni lanĉos kun ĝi, lasu ĝin fali - ni pretas oferi. Kaj tiam ni kontrolos ĉion." Kiam (aŭ se) la projekto komencas gajni monon, la komerco volas aldoni eĉ pli da funkcioj - ĉar ĝi ekfunkciis, do ĝi devas esti lanĉita plu! Kaj vi estas ĉe la punkto, kie vi unue bezonas kontroli ĉion antaŭan, kio prenas ne 1% de la tempo, sed multe pli. Kaj cetere, programistoj estos bezonataj por monitorado, kaj estas pli facile lasi ilin labori pri novaj funkcioj. Kiel rezulto, novaj funkcioj estas skribitaj, ĉio fiaskis, kaj vi estas en senfina blokiĝo.

Do kiel kontroli projekton ekde la komenco, kaj kion fari se vi ricevas projekton, kiu devas esti monitorita, sed vi ne scias kie komenci?

Unue, vi devas plani.

Lirika deturniĝo: tre ofte ili komenciĝas per infrastruktura monitorado. Ekzemple, ni havas Kubernetes. Ni komencu instalante Prometheus kun Grafana, instalante kromaĵojn por monitori la "kubon". Ne nur programistoj, sed ankaŭ administrantoj havas la malfeliĉan praktikon de: "Ni instalos ĉi tiun kromaĵon, sed la kromaĵo verŝajne scias kiel fari ĝin." Homoj ŝatas komenci per la simpla kaj simpla, prefere ol per la gravaj agoj. Kaj infrastruktura monitorado estas facila.

Unue, decidu kion kaj kiel vi volas kontroli, kaj poste elektu ilon, ĉar aliaj homoj ne povas pensi por vi. Kaj ili devus? Aliaj homoj pensis al si mem, pri universala sistemo - aŭ tute ne pensis kiam tiu ĉi kromaĵo estis verkita. Kaj nur ĉar ĉi tiu kromaĵo havas 5 mil uzantojn ne signifas, ke ĝi utilas. Eble vi fariĝos la 5001-a simple ĉar jam antaŭe estis 5000 homoj tie.

Se vi komencas monitori la infrastrukturon kaj la malantaŭo de via aplikaĵo ĉesos respondi, ĉiuj uzantoj perdos konekton kun la poŝtelefona aplikaĵo. Eraro aperos. Ili venos al vi kaj diros "La aplikaĵo ne funkcias, kion vi faras ĉi tie?" - "Ni kontrolas." — "Kiel vi kontrolas se vi ne vidas, ke la aplikaĵo ne funkcias?!"

1. Mi kredas, ke vi devas komenci monitoradon ĝuste de la enirpunkto de la uzanto. Se la uzanto ne vidas, ke la aplikaĵo funkcias, tio estas, ĝi estas fiasko. Kaj la monitora sistemo unue devas averti pri tio.
2. Kaj nur tiam ni povas kontroli la infrastrukturon. Aŭ faru ĝin paralele. Estas pli facile kun infrastrukturo - ĉi tie ni povas finfine simple instali zabbix.
3. Kaj nun vi devas iri al la radikoj de la aplikaĵo por kompreni, kie aferoj ne funkcias.

Mia ĉefa ideo estas, ke monitorado devus iri paralele kun la evoluprocezo. Se vi distras la monitoran teamon por aliaj taskoj (kreado de CI/KD, sandboxing, reorganizo de infrastrukturo), monitorado komencos malfrui kaj vi eble neniam atingos evoluon (aŭ pli aŭ malpli frue vi devos haltigi ĝin).

Ĉio laŭ niveloj

Jen kiel mi vidas la organizon de monitora sistemo.

1) Aplika nivelo:

• monitorado de aplikaĵa komerca logiko;
• monitorado de sanmetrikoj de servoj;
• monitorado de integriĝo.

2) Infrastruktura nivelo:

• monitorado de nivelo de orkestrado;
• monitorado de sistema programaro;
• monitorado de fernivelo.

3) Denove la aplika nivelo - sed kiel inĝenieristikprodukto:

• kolektado kaj monitorado de aplikaĵaj protokoloj;
• APM;
• paŭsaĵo.

4) Atentigo:

• organizo de averta sistemo;
• organizo de devosistemo;
• organizo de "sciobazo" kaj laborfluo por okazaĵprilaborado.

gravaj: ni venas al la alarmo ne post, sed tuj! Ne necesas lanĉi monitoradon kaj "iel poste" eltrovi, kiu ricevos atentigojn. Post ĉio, kio estas la tasko de monitorado: kompreni kie en la sistemo io funkcias malbone, kaj sciigi la ĝustajn homojn pri tio. Se vi lasas ĉi tion ĝis la fino, tiam la ĝustaj homoj scios, ke io misfunkcias nur nomante "nenio funkcias por ni."

Aplika Tavolo - Komerca Logika Monitorado

Ĉi tie ni parolas pri kontrolo de la fakto mem, ke la aplikaĵo funkcias por la uzanto.

Ĉi tiu nivelo devas esti farita dum la evolufazo. Ekzemple, ni havas kondiĉan Prometeon: ĝi iras al la servilo kiu faras la kontrolojn, tiras la finpunkton, kaj la finpunkto iras kaj kontrolas la API.

Kiam ofte petas kontroli la ĉefpaĝon por certigi, ke la retejo funkcias, programistoj donas tenilon, kiu povas esti tirita ĉiufoje kiam ili bezonas certigi, ke la API funkcias. Kaj programistoj ĉi-momente ankoraŭ prenas kaj skribas /api/test/helloworld
La sola maniero certigi, ke ĉio funkcias? - Ne!

• Krei tiajn kontrolojn estas esence la tasko de programistoj. Unuaj testoj devas esti skribitaj de la programistoj, kiuj skribas la kodon. Ĉar se vi likas ĝin al la administranto, "Ho, jen listo de API-protokoloj por ĉiuj 25 funkcioj, bonvolu kontroli ĉion!" — nenio funkcios.
• Se vi presas "saluton mondon", neniu iam scios, ke la API devas kaj funkcias. Ĉiu API-ŝanĝo devas konduki al ŝanĝo en ĉekoj.
• Se vi jam havas tian problemon, ĉesigu la funkciojn kaj asignu programistojn, kiuj skribos ĉi tiujn ĉekojn, aŭ akceptos la perdojn, akceptu, ke nenio estas kontrolita kaj malsukcesos.

Teknikaj Konsiletoj:

• Nepre organizu eksteran servilon por organizi kontrolojn - vi devas esti certa, ke via projekto estas alirebla por la ekstera mondo.
• Organizu kontrolojn tra la tuta API-protokolo, ne nur individuaj finpunktoj.
• Kreu prometheus-finpunkton kun la testrezultoj.

Aplika tavolo - sano-metrika monitorado

Nun ni parolas pri eksteraj sanmetrikoj de servoj.

Ni decidis, ke ni kontrolas ĉiujn "tenilojn" de la aplikaĵo per eksteraj kontroloj, kiujn ni nomas de ekstera monitora sistemo. Sed ĉi tiuj estas la "teniloj", kiujn la uzanto "vidas". Ni volas certigi, ke niaj servoj mem funkcias. Estas pli bona rakonto ĉi tie: K8s havas sankontrolojn, tiel ke almenaŭ la "kubo" mem povas esti konvinkita, ke la servo funkcias. Sed duono de la ĉekoj, kiujn mi vidis, estas la sama presaĵo “saluton mondo”. Tiuj. Do li tiras unufoje post deplojo, li respondis, ke ĉio estas en ordo - jen ĉio. Kaj la servo, se ĝi disponigas sian propran API, havas grandegan nombron da enirpunktoj por tiu sama API, kiu ankaŭ devas esti monitorita, ĉar ni volas scii ke ĝi funkcias. Kaj ni jam kontrolas ĝin interne.

Kiel efektivigi ĉi tion ĝuste teknike: ĉiu servo elmontras finpunkton pri sia nuna agado, kaj en la grafikaĵoj de Grafana (aŭ ajna alia aplikaĵo) ni vidas la staton de ĉiuj servoj.

• Ĉiu API-ŝanĝo devas konduki al ŝanĝo en ĉekoj.
• Kreu novan servon tuj kun sanaj mezuroj.
• Administranto povas veni al la programistoj kaj demandi "aldonu al mi kelkajn funkciojn por ke mi komprenu ĉion kaj aldonu informojn pri tio al mia monitora sistemo." Sed programistoj kutime respondas, "Ni aldonos nenion du semajnojn antaŭ la liberigo."
  Sciigu la evoluadmanaĝerojn, ke estos tiaj perdoj, sciu ankaŭ la administrado de la disvolvaj administrantoj. Ĉar kiam ĉio falos, iu ankoraŭ vokos kaj postulos kontroli la "konstante falantan servon" (c)
• Cetere, asignu programistojn por verki kromaĵojn por Grafana - ĉi tio estos bona helpo por administrantoj.

Aplika Tavolo - Integriĝa Monitorado

Integriĝmonitorado temigas monitoradon de komunikadoj inter komerc-kritikaj sistemoj.

Ekzemple, estas 15 servoj kiuj komunikas inter si. Ĉi tiuj ne plu estas apartaj retejoj. Tiuj. ni ne povas tiri la servon memstare, akiri /helloworld kaj kompreni ke la servo funkcias. Ĉar la menda retservo devas sendi informojn pri la mendo al la buso - de la buso, la magazena servo devas ricevi ĉi tiun mesaĝon kaj labori kun ĝi plu. Kaj la retpoŝta distribuservo devas prilabori ĉi tion iel plu, ktp.

Sekve, ni ne povas kompreni, pikante ĉiun individuan servon, ke ĉio funkcias. Ĉar ni havas certan buson, per kiu ĉio komunikas kaj interagas.
Tial ĉi tiu etapo devus marki la stadion de testado de servoj por interago kun aliaj servoj. Estas neeble organizi komunikadan monitoradon monitorante la mesaĝmakleriston. Se ekzistas servo, kiu eldonas datumojn kaj servon, kiu ricevas ĝin, kiam vi kontrolas la makleriston, ni nur vidos datumojn, kiuj flugas de flanko al flanko. Eĉ se ni iel sukcesis kontroli la interagadon de ĉi tiuj datumoj interne - ke certa produktanto afiŝas la datumojn, iu legas ĝin, ĉi tiu fluo daŭre iras al Kafka - ĉi tio ankoraŭ ne donos al ni informojn, se unu servo sendis la mesaĝon en unu versio. , sed la alia servo ne atendis ĉi tiun version kaj preterlasis ĝin. Ni ne scios pri tio, ĉar la servoj diros al ni, ke ĉio funkcias.

Kion mi rekomendas fari:

• Por sinkrona komunikado: la finpunkto faras petojn al rilataj servoj. Tiuj. ni prenas ĉi tiun finpunkton, tiras skripton ene de la servo, kiu iras al ĉiuj punktoj kaj diras "Mi povas tiri tien, kaj tiri tien, mi povas tiri tien ..."
• Por nesinkrona komunikado: envenantaj mesaĝoj - la finpunkto kontrolas la buson por testmesaĝoj kaj montras la pretigan staton.
• Por nesinkrona komunikado: eksiĝintaj mesaĝoj - la finpunkto sendas testmesaĝojn al la buso.

Kiel kutime okazas: ni havas servon, kiu ĵetas datumojn en la buson. Ni venas al ĉi tiu servo kaj petas vin rakonti al ni pri ĝia integriga sano. Kaj se la servo bezonas produkti mesaĝon ie plu (WebApp), tiam ĝi produktos ĉi tiun provan mesaĝon. Kaj se ni prizorgas servon ĉe la flanko de OrderProcessing, ĝi unue afiŝas tion, kion ĝi povas afiŝi sendependa, kaj se estas iuj dependaj aferoj, tiam ĝi legas aron da testaj mesaĝoj de la buso, komprenas, ke ĝi povas prilabori ilin, raporti ĝin kaj , se necese, afiŝu ilin plu, kaj pri tio li diras - ĉio estas en ordo, mi vivas.

Tre ofte ni aŭdas la demandon "kiel ni povas testi ĉi tion sur batalaj datumoj?" Ekzemple, ni parolas pri la sama menda servo. La mendo sendas mesaĝojn al la magazeno, kie la varoj estas forigitaj: ni ne povas testi ĉi tion sur batalaj datumoj, ĉar "miaj varoj estos forigitaj!" Solvo: Planu ĉi tiun tutan provon komence. Vi ankaŭ havas unuajn testojn, kiuj faras mokojn. Do, faru ĝin je pli profunda nivelo, kie vi havas komunikan kanalon, kiu ne damaĝas la operacion de la komerco.

Infrastruktura nivelo

Monitorado de infrastrukturo estas io, kio estis delonge konsiderita monitorado mem.

• Infrastrukturmonitorado povas kaj devas esti lanĉita kiel aparta procezo.
• Vi ne devus komenci per infrastruktura monitorado en funkcianta projekto, eĉ se vi vere volas. Ĉi tio estas doloro por ĉiuj devopoj. "Unue mi kontrolos la areton, mi kontrolos la infrastrukturon" - t.e. Unue, ĝi kontrolos tion, kio troviĝas sube, sed ne eniros la aplikaĵon. Ĉar la aplikaĵo estas nekomprenebla afero por devopoj. Ĝi estis likita al li, kaj li ne komprenas kiel ĝi funkcias. Kaj li komprenas la infrastrukturon kaj komencas per ĝi. Sed ne - vi ĉiam devas kontroli la aplikaĵon unue.
• Ne transiru kun la nombro da atentigoj. Konsiderante la kompleksecon de modernaj sistemoj, atentigoj konstante flugas, kaj vi devas iel vivi kun ĉi tiu aro da atentigoj. Kaj la alvoka persono, rigardinte cent el la sekvaj atentigoj, decidos "Mi ne volas pensi pri tio." Atentigoj devas sciigi nur pri kritikaj aferoj.

Apliknivelo kiel komerca unuo

Esencaj punktoj:

• ELK. Ĉi tio estas la industria normo. Se ial vi ne agregas protokolojn, komencu fari tion tuj.
• APM. Eksteraj APM-oj kiel maniero rapide fermi aplikaĵan monitoradon (NewRelic, BlackFire, Datadog). Vi povas instali ĉi tiun aferon provizore por almenaŭ iel kompreni, kio okazas kun vi.
• Spurado. En dekoj da mikroservoj, vi devas spuri ĉion, ĉar la peto ne plu vivas memstare. Estas tre malfacile aldoni poste, do pli bone estas tuj plani spuradon en evoluo - ĉi tio estas la laboro kaj utileco de la programistoj. Se vi ankoraŭ ne efektivigis ĝin, efektivigu ĝin! Vidu Jaeger/Zipkin

Alerta

• Organizo de sciiga sistemo: en kondiĉoj de monitorado de amaso da aferoj, devus ekzisti unuigita sistemo por sendi sciigojn. Vi povas en Grafana. En la Okcidento, ĉiuj uzas PagerDuty. Atentigoj estu klaraj (ekz. de kie ili venis...). Kaj estas konsilinde kontroli ke sciigoj estas ricevitaj entute
• Organizo de devosistemo: ne estu senditaj atentigoj al ĉiuj (aŭ ĉiuj reagos en amaso, aŭ neniu reagos). Programistoj ankaŭ devas esti ĉeestantaj: nepre difinu respondecajn kampojn, faru klarajn instrukciojn kaj skribu en ĝi, kiun ĝuste voki lundon kaj merkredon, kaj kiun voki marde kaj vendrede (alie ili ne vokos iun ajn eĉ en la evento de granda problemo - ili timos veki vin aŭ ĝeni: homoj ĝenerale ne ŝatas voki kaj veki aliajn homojn, precipe nokte). Kaj klarigu, ke peti helpon ne estas indikilo de nekompetenteco ("Mi petas helpon, tio signifas, ke mi estas malbona laboristo"), instigu petojn por helpo.
• Organizo de "scio-bazo" kaj laborfluo por okazaĵa prilaborado: por ĉiu grava okazaĵo, postmortem devus esti planita, kaj kiel provizora mezuro, agoj kiuj solvos la okazaĵon devus esti registritaj. Kaj faru ĝin praktiko, ke ripetaj atentigoj estas peko; ili devas esti fiksitaj en kodo aŭ infrastruktura laboro.

Teknologia stako

Ni imagu, ke nia stako estas jena:

• kolekto de datumoj - Prometheus + Grafana;
• log analysis - ELK;
• por APM aŭ Tracing - Jaeger (Zipkin).

La elekto de elektoj ne estas kritika. Ĉar se komence vi komprenis kiel kontroli la sistemon kaj skribis planon, tiam vi komencas elekti ilojn laŭ viaj postuloj. La demando estas, kion vi elektis kontroli unue. Ĉar eble la ilo, kiun vi elektis komence, tute ne konvenas al viaj postuloj.

Kelkajn teknikajn punktojn, kiujn mi vidas ĉie lastatempe:

Prometeo estas puŝita enen Kubernetes - kiu elpensis ĉi tion?! Se via areto kraŝas, kion vi faros? Se vi havas kompleksan areton interne, tiam devus ekzisti ia monitora sistemo ene de la areto, kaj iuj ekstere, kiu kolektos datumojn de ene de la areto.

Ene de la areto ni kolektas ŝtipojn kaj ĉion alian. Sed la monitora sistemo devas esti ekstere. Tre ofte, en areto kie estas Promtheus instalita interne, ekzistas ankaŭ sistemoj, kiuj faras eksterajn kontrolojn de la funkciado de la retejo. Kio se viaj konektoj al la ekstera mondo falis kaj la aplikaĵo ne funkcias? Montriĝas, ke ĉio estas en ordo, sed ĝi ne faciligas aferojn por uzantoj.

trovoj

• Monitorado de disvolviĝo ne estas la instalado de utilecoj, sed la disvolviĝo de programaro. 98% de la hodiaŭa monitorado estas kodigo. Kodigo en servoj, kodi eksterajn ĉekojn, kontroli eksterajn servojn, kaj jen ĉio.
• Ne malŝparu la tempon de viaj programistoj pri monitorado: ĝi povas preni ĝis 30% de ilia laboro, sed ĝi valoras ĝin.
• Devops, ne zorgu, ke vi ne povas monitori ion, ĉar iuj aferoj estas tute alia pensmaniero. Vi ne estis programisto, kaj monitorado de laboro estas ĝuste ilia tasko.
• Se la projekto jam funkcias kaj ne kontrolas (kaj vi estas administranto), asignu rimedojn por monitorado.
• Se la produkto jam estas en produktado, kaj vi estas devop, al kiu oni diris "agordi monitoradon" - provu klarigi al administrado pri kio mi skribis ĉion ĉi.

Ĉi tio estas plilongigita versio de la raporto ĉe la Saint Highload++-konferenco.

Se vi interesiĝas pri miaj ideoj kaj pensoj pri ĝi kaj rilataj temoj, tiam ĉi tie vi povas legi la kanalon 🙂

fonto: www.habr.com