Saluton ĉiuj!
Nia kompanio okupiĝas pri programaro kaj sekva teknika subteno. Teknika subteno postulas ne nur ripari erarojn, sed kontroli la agadon de niaj aplikoj.
Ekzemple, se unu el la servoj kraŝis, tiam vi devas aŭtomate registri ĉi tiun problemon kaj komenci solvi ĝin, kaj ne atendi ke malkontentaj uzantoj kontaktu teknikan subtenon.
Ni havas malgrandan kompanion, ni ne havas la rimedojn por studi kaj konservi iujn kompleksajn solvojn por monitorado de aplikoj, ni bezonis trovi simplan kaj efikan solvon.
Strategio de monitorado
Ne estas facile kontroli la funkciecon de aplikaĵo; ĉi tiu tasko estas ne bagatela, oni eĉ povus diri kreiva. Estas precipe malfacile kontroli kompleksan plurligan sistemon.
Kiel vi povas manĝi elefanton? Nur en partoj! Ni uzas ĉi tiun aliron por monitori aplikojn.
La esenco de nia monitorada strategio:
Malkonstruu vian aplikon en komponantojn.
Kreu kontrolojn por ĉiu komponanto.
Komponanto estas konsiderita funkcia se ĉiuj ĝiaj kontrolkontroloj estas faritaj sen eraroj. Apliko estas konsiderata sana se ĉiuj ĝiaj komponantoj estas funkciaj.
Tiel, ajna sistemo povas esti reprezentita kiel arbo de komponentoj. Kompleksaj komponantoj estas dividitaj en pli simplajn. Simplaj komponantoj havas ĉekojn.
Komparnormoj ne estas intencitaj plenumi funkciajn provojn, ili ne estas unuopaj testoj. Kontroloj devas kontroli kiel la komponanto sentas en la nuna momento, ĉu ekzistas ĉiuj rimedoj necesaj por ĝia funkciado, kaj ĉu ekzistas problemoj.
Ne estas mirakloj; la plej multaj ĉekoj devos esti evoluigitaj sendepende. Sed ne timu, ĉar plejofte unu ĉeko prenas 5-10 liniojn de kodo, sed vi povas efektivigi ajnan logikon kaj vi klare komprenos kiel la ĉeko funkcias.
Monitora sistemo
Ni diru, ke ni dividis la aplikaĵon en komponantojn, elpensis kaj efektivigis kontrolojn por ĉiu komponanto, sed kion fari kun la rezultoj de ĉi tiuj kontroloj? Kiel ni scias, ĉu iu kontrolo malsukcesis?
Ni bezonos monitoran sistemon. Ŝi plenumos la sekvajn taskojn:
- Ricevu testrezultojn kaj uzu ilin por determini la staton de komponantoj.
Vide, ĉi tio aspektas kiel reliefigi la komponan arbon. Funkciaj komponantoj fariĝas verdaj, problemaj fariĝas ruĝaj. - Faru ĝeneralajn kontrolojn el la skatolo.
La monitora sistemo povas mem fari iujn kontrolojn. Kial reinventi la radon, ni uzu ilin. Ekzemple, vi povas kontroli, ke retpaĝo malfermiĝas aŭ la servilo pingas. - Sendu sciigojn pri problemoj al interesitoj.
- Bildigo de monitoraj datumoj, provizo de raportoj, grafikaĵoj kaj statistikoj.
Mallonga priskribo de la ASMO-sistemo
Plej bone estas klarigi per ekzemplo. Ni rigardu kiel estas organizita monitorado de la agado de la sistemo ASMO.
ASMO estas aŭtomatigita meteologia subtena sistemo. La sistemo helpas specialistojn pri vojservoj kompreni kie kaj kiam necesas trakti la vojon per malglaciaj materialoj. La sistemo kolektas datumojn de vojkontrolpunktoj. Voja kontrolpunkto estas loko sur la vojo kie ekipaĵo estas instalita: veterstacio, vidbenda kamerao, ktp. Por antaŭdiri danĝerajn situaciojn, la sistemo ricevas veterprognozojn de eksteraj fontoj.
Do, la konsisto de la sistemo estas sufiĉe tipa: retejo, agento, ekipaĵo. Ni komencu monitoradon.
Rompi la sistemon en komponantojn
La sekvaj komponentoj povas esti distingitaj en la ASMO-sistemo:
1. Persona konto
Ĉi tio estas retejo-aplikaĵo. Minimume, vi devas kontroli, ke la aplikaĵo disponeblas en la interreto.
2. Datumaro
La datumbazo konservas datumojn, kiuj estas gravaj por raportado, kaj vi devas certigi, ke datumbazaj sekurkopioj estas kreitaj sukcese.
3. Servilo
Per servilo ni signifas la aparataron sur kiu aplikaĵoj funkcias. Necesas kontroli la staton de HDD, RAM, CPU.
4. Agento
Ĉi tio estas Vindoza servo, kiu plenumas multajn malsamajn taskojn laŭ horaro. Minimume, vi devas kontroli, ke la servo funkcias.
5. Tasko de agento
Nur scii, ke agento laboras, ne sufiĉas. Agento povas labori, sed ne plenumi siajn asignitajn taskojn. Ni dividu la agentan komponanton en taskojn kaj kontrolu ĉu ĉiu agenta tasko funkcias sukcese.
6. Vojkontrolaj punktoj (ujo de ĉiuj MPC)
Estas multaj vojkontrolpunktoj, do ni kombinu ĉiujn MPC-ojn en unu komponento. Ĉi tio igos ĝin pli oportuna legi monitorajn datumojn. Vidante la staton de la ASMO-sistemkomponento, tuj estos klare kie estas la problemoj: en aplikoj, aparataro aŭ en la maksimuma kontrolsistemo.
7. Voja kontrolpunkto (unu maksimuma limo)
Ni konsideros ĉi tiun komponanton utila se ĉiuj aparatoj sur ĉi tiu MPC estas funkcieblaj.
8. Aparato
Ĉi tio estas vidbenda kamerao aŭ veterstacio, kiu estas instalita ĉe la maksimuma koncentriĝa limo. Necesas kontroli, ke la aparato funkcias ĝuste.
En la monitora sistemo, la kompona arbo aspektos jene:
Monitorado de TTT-apliko
Do, ni dividis la sistemon en komponantojn, nun ni devas elpensi ĉekojn por ĉiu komponanto.
Por monitori TTT-aplikaĵon ni uzas la jenajn kontrolojn:
1. Kontrolante la malfermon de la ĉefa paĝo
Ĉi tiu kontrolo estas farita de la monitora sistemo. Por ekzekuti ĝin, ni indikas la paĝan adreson, la atendatan respondfragmenton kaj la maksimuman petan ekzekuttempon.
2. Kontrolante la domajnan pagolimdaton
Tre grava kontrolo. Kiam domajno restas senpaga, uzantoj ne povas malfermi la retejon. Solvi la problemon povas daŭri plurajn tagojn, ĉar... DNS-ŝanĝoj ne estas aplikataj tuj.
3. Kontrolante la SSL-atestilon
Nuntempe preskaŭ ĉiuj retejoj uzas la https protokolon por aliro. Por ke la protokolo funkciu ĝuste, vi bezonas validan SSL-atestilon.
Malsupre estas la komponanto "Persona Konto" en la monitora sistemo:
Ĉiuj ĉi-supraj kontroloj funkcios por plej multaj aplikoj kaj ne postulas kodigon. Ĉi tio estas tre bonega ĉar vi povas komenci monitori ajnan retejon en 5 minutoj. Malsupre estas pliaj kontroloj, kiuj povas esti faritaj por TTT-apliko, sed ilia efektivigo estas pli kompleksa kaj specifa aplikaĵo, do ni ne kovros ilin en ĉi tiu artikolo.
Kion alian vi povas kontroli?
Por pli plene kontroli vian retejon, vi povas fari la sekvajn kontrolojn:
- Nombro da JavaScript-eraroj per periodo
- Nombro da eraroj ĉe la TTT-aplikflanko (malantaŭa finaĵo) por la periodo
- Nombro de malsukcesaj respondoj pri TTT-apliko (respondkodo 404, 500, ktp.)
- Meza tempo de ekzekuto de demandoj
Monitorado de vindoza servo (agento)
En la ASMO-sistemo, la agento ludas la rolon de taskoplanisto, kiu efektivigas planitajn taskojn en la fono.
Se ĉiuj agentaj taskoj finiĝas sukcese, la agento funkcias ĝuste. Rezultas, ke por kontroli agenton, vi devas kontroli ĝiajn taskojn. Tial ni dividas la komponanton "Agente" en taskojn. Por ĉiu tasko, ni kreos apartan komponanton en la monitora sistemo, kie la "Agent" komponanto estos la "gepatro".
Ni disigas la Agentkomponenton en infanajn komponantojn (taskoj):
Do, ni malkonstruis kompleksan komponanton en plurajn simplajn. Nun ni devas elpensi ĉekojn por ĉiu simpla komponanto. Bonvolu noti, ke la gepatra komponanto "Agent" ne havos neniujn kontrolojn, ĉar la monitora sistemo kalkulos sian statuson sendepende surbaze de la stato de siaj infanaj komponantoj. Alivorte, se ĉiuj taskoj estas kompletigitaj sukcese, tiam la agento funkcias sukcese.
Estas pli ol cent taskoj en la ASMO-sistemo, ĉu vere necesas elpensi unikajn kontrolojn por ĉiu tasko? Kompreneble, kontrolo estos pli bona se ni elpensos kaj efektivigos niajn proprajn specialajn kontrolojn por ĉiu agenta tasko, sed plejofte sufiĉas uzi universalajn kontrolojn.
La ASMO-sistemo uzas nur universalajn kontrolojn por taskoj kaj tio sufiĉas por kontroli la agadon de la sistemo.
Kontrolante progreson
La plej simpla kaj efika kontrolo estas la ekzekutkontrolo. La kontrolo kontrolas, ke la tasko estas finita sen eraroj. Ĉiuj taskoj havas ĉi tiun kontrolon.
Kontrola algoritmo
Post ĉiu tasko-ekzekuto, vi devas sendi la rezulton de la SUKCESA kontrolo al la monitora sistemo se la tasko-ekzekuto estis sukcesa, aŭ ERARO se la ekzekuto finiĝis kun eraro.
Ĉi tiu kontrolo povas detekti la sekvajn problemojn:
- La tasko funkcias sed malsukcesas kun eraro.
- La tasko ĉesis funkcii, ekzemple ĝi frostiĝis.
Ni rigardu kiel ĉi tiuj problemoj estas solvitaj pli detale.
Problemo 1 - La tasko funkcias sed malsukcesas kun eraro
Malsupre estas kazo kie la tasko funkcias sed malsukcesas inter 14:00 kaj 16:00.
La figuro montras, ke kiam tasko malsukcesas, signalo estas tuj sendita al la monitora sistemo kaj la stato de la responda kontrolo en la monitora sistemo fariĝas alarmo.
Bonvolu noti, ke en la monitora sistemo, la statuso de la komponanto dependas de la konfirma statuso. La alarmstato de la ĉeko ŝanĝos ĉiujn pli altnivelajn komponentojn al alarmo, vidu la figuron sube.
Problemo 2 - La tasko ĉesis ekzekuti (frostiĝis)
Kiel la monitora sistemo komprenos, ke tasko estas blokita?
La kontrolrezulto havas validecperiodon, ekzemple, 1 horo. Se pasas horo kaj ne estas nova testrezulto, la monitora sistemo agos la teststatuson al alarmo.
En la supra bildo, la lumoj estis estingitaj je 14:00 p.m. Je 15:00, la monitora sistemo detektos, ke la testrezulto (de 14:00) estas putra, ĉar La koncerna tempo eksvalidiĝis (unu horo), sed ne estas nova rezulto, kaj ŝanĝos la ĉekon al alarmstato.
Je 16:00 la lumoj denove ŝaltas, la programo kompletigos la taskon kaj sendos la ekzekutrezulton al la monitora sistemo, la testa stato denove sukcesos.
Kian kontrolon de gravectempo mi uzu?
La gravectempo devas esti pli granda ol la taska ekzekutperiodo. Mi rekomendas agordi la gravectempon 2-3 fojojn pli longan ol la taskekzekuta periodo. Ĉi tio estas necesa por eviti ricevi falsajn sciigojn kiam, ekzemple, tasko daŭris pli longe ol kutime aŭ iu reŝargis la programon.
Kontrolante progreson
La ASMO-sistemo havas taskon "Ŝargi Prognozon", kiu provas elŝuti novan prognozon de ekstera fonto unufoje hore. La preciza tempo kiam nova prognozo aperas en la ekstera sistemo ne estas konata, sed oni scias, ke tio okazas 2 fojojn tage. Montriĝas, ke se ne ekzistas nova prognozo dum pluraj horoj, tiam ĉi tio estas normala, sed se ne ekzistas nova prognozo dum pli ol tago, tiam io rompiĝis ie. Ekzemple, la datumformato en ekstera prognoza sistemo povas ŝanĝiĝi, tial ASMO ne vidos novan prognozan eldonon.
Kontrola algoritmo
La tasko sendas la rezulton de la SUKKA ĉeko al la monitora sistemo kiam ĝi sukcesas akiri progreson (elŝutante novan veterprognozon). Se ne estas progreso aŭ okazas eraro, tiam nenio estas sendita al la monitora sistemo.
La ĉeko devas havi gravecan intervalon tia ke dum ĉi tiu tempo ĝi estas garantiita ricevi novan progreson.
Bonvolu noti, ke ni lernos pri la problemo kun malfruo, ĉar la monitora sistemo atendas ĝis la validecperiodo de la lasta skana rezulto eksvalidiĝas. Tial, la validecperiodo de la ĉeko ne bezonas esti tro longa.
Monitorado de datumbazoj
Por kontroli la datumbazon en la sistemo ASMO, ni faras la sekvajn kontrolojn:
- Kontrolante rezervan kreadon
- Kontrolante liberan diskspacon
Kontrolante rezervan kreadon
En la plej multaj aplikoj, estas grave havi ĝisdatigitajn datumbazajn sekurkopiojn por ke se la servilo malsukcesas, vi povas deploji la programon al nova servilo.
ASMO kreas rezervan kopion unufoje semajne kaj sendas ĝin al stokado. Kiam ĉi tiu proceduro estas kompletigita sukcese, la rezulto de la sukcesa kontrolo estas sendita al la monitora sistemo. La konfirmrezulto validas dum 9 tagoj. Tiuj. Por kontroli la kreadon de sekurkopioj, la mekanismo "progreskontrolo", kiun ni diskutis supre, estas uzata.
Kontrolante liberan diskspacon
Se ne estas sufiĉe libera spaco sur la disko, la datumbazo ne povos funkcii ĝuste, do gravas kontroli la kvanton de libera spaco.
Estas oportune uzi metrikojn por kontroli nombrajn parametrojn.
Metriko estas nombra variablo, kies valoro estas transdonita al la monitora sistemo. La monitora sistemo kontrolas la sojmajn valorojn kaj kalkulas la metrikan statuson.
Malsupre estas bildo pri kiel aspektas la komponanto "Datumbazo" en la monitora sistemo:
Monitorado de serviloj
Por monitori la servilon ni uzas la sekvajn kontrolojn kaj metrikojn:
1. Libera diskospaco
Se la diskospaco elĉerpiĝas, la aplikaĵo ne povos funkcii. Ni uzas 2 sojlaj valoroj: la unua nivelo estas AVERTO, la dua nivelo estas ALARM.
2. Meza RAM-valoro en procentoj por horo
Ni uzas la horan mezumon ĉar... ni ne interesiĝas pri maloftaj rasoj.
3. Meza CPU-procento por horo
Ni uzas la horan mezumon ĉar... ni ne interesiĝas pri maloftaj rasoj.
4. Ping-kontrolo
Kontrolas ke la servilo estas enreta. La monitora sistemo povas fari ĉi tiun kontrolon; ne necesas skribi kodon.
Malsupre estas bildo pri kiel aspektas la komponanto "Servilo" en la monitora sistemo:
Monitorado de ekipaĵoj
Mi rakontos al vi kiel la datumoj estas akiritaj. Por ĉiu vojkontrolpunkto (MPC) estas tasko en la taskoplanilo, ekzemple, "Enketo MPC M2 km 200". La tasko ricevas datumojn de ĉiuj MPC-aparatoj ĉiujn 30 minutojn.
Problemo pri komunika kanalo
Plejparto de la ekipaĵo situas ekster la urbo; GSM-reto estas uzata por transdono de datumoj, kiu ne funkcias stabile (estas reto, aŭ ne ekzistas).
Pro oftaj retaj fiaskoj, unue, kontroli la MPC-enketon en monitorado aspektis jene:
Evidentiĝis, ke ĉi tio ne estas funkcia eblo, ĉar estis multaj falsaj sciigoj pri problemoj. Tiam oni decidis uzi "progreskontrolon" por ĉiu aparato, t.e. Nur la sukcessignalo estas sendita al la monitora sistemo se la aparato estas enketita sen eraro. La releva tempo estis fiksita al 5 horoj.
Nun monitorado sendas sciigojn pri problemoj nur kiam la aparato ne povas esti enketita dum pli ol 5 horoj. Kun alta grado de probableco, ĉi tiuj ne estas falsaj alarmoj, sed realaj problemoj.
Malsupre estas bildo pri kiel aspektas la ekipaĵo en la monitora sistemo:
Grava!
Kiam la GSM-reto ĉesas funkcii, ĉiuj MDC-aparatoj ne estas enketitaj. Por redukti la nombron da retpoŝtoj de la monitora sistemo, niaj inĝenieroj abonas sciigojn pri komponentaj problemoj kun la tipo "MPC" anstataŭ "Aparato". Ĉi tio ebligas al vi ricevi unu sciigon por ĉiu MPC, anstataŭ ricevi apartan sciigon por ĉiu aparato.
Fina ASMO-monitoradskemo
Ni kunigu ĉion kaj vidu kian monitoran skemon ni havas.
konkludo
Ni resumu.
Kion donis al ni monitorado de la agado de ASMO?
1. La tempo de elimino de difektoj malpliiĝis
Ni antaŭe aŭdis pri difektoj de uzantoj, sed ne ĉiuj uzantoj raportas difektojn. Okazis, ke ni eksciis pri misfunkcio de sistema komponanto semajnon post kiam ĝi aperis. Nun la monitora sistemo sciigas nin pri problemoj tuj kiam problemo estas detektita.
2. Sistemstabileco pliiĝis
Ĉar difektoj komencis esti eliminitaj pli frue, la sistemo entute komencis funkcii multe pli stabile.
3. Reduktante la nombron da vokoj al teknika subteno
Multaj problemoj nun estas solvitaj antaŭ ol uzantoj eĉ scias pri ili. Uzantoj komencis kontakti teknikan subtenon malpli ofte. Ĉio ĉi havas bonan efikon al nia reputacio.
4. Pliigante klienton kaj uzanto-lojalecon
La kliento rimarkis pozitivajn ŝanĝojn en la stabileco de la sistemo. Uzantoj renkontas malpli da problemoj uzante la sistemon.
5. Redukti teknikajn subtenajn kostojn
Ni ĉesis fari iujn ajn manajn kontrolojn. Nun ĉiuj kontroloj estas aŭtomatigitaj. Antaŭe, ni eksciis pri problemoj de uzantoj; ofte estis malfacile kompreni, pri kiu problemo la uzanto parolas. Nun, la plej multaj problemoj estas raportitaj de la monitora sistemo; sciigoj enhavas teknikajn datumojn, kiuj ĉiam klarigas kio misfunkciis kaj kie.
Grava!
Vi ne povas instali la monitoran sistemon sur la sama servilo, kie viaj aplikaĵoj funkcias. Se la servilo malfunkcias, aplikaĵoj ĉesos funkcii kaj estos neniu por sciigi pri ĝi.
La monitora sistemo devas funkcii per aparta servilo en alia datumcentro.
Se vi ne volas uzi dediĉitan servilon en nova datumcentro, vi povas uzi nuban monitoran sistemon. Nia kompanio uzas la sistemon de monitorado de nubo Zidium, sed vi povas uzi ajnan alian monitoran sistemon. La kosto de nuba monitora sistemo estas pli malalta ol luado de nova servilo.
Rekomendoj:
- Malkonstruu aplikojn kaj sistemojn en la formo de arbo de komponantoj kiel eble plej detale, do estos oportune kompreni kie kaj kio estas rompita, kaj kontrolo estos pli kompleta.
- Por kontroli la funkciecon de komponanto, uzu testojn. Pli bone estas uzi multajn simplajn kontrolojn ol unu kompleksan.
- Agordu metrikajn sojlojn flanke de la monitora sistemo, anstataŭ skribi ilin en kodo. Ĉi tio savos vin de devi rekompili, reagordi aŭ rekomenci la aplikaĵon.
- Por kutimaj kontroloj, uzu marĝenon de graveca tempo por eviti ricevi falsajn sciigojn ĉar iuj kontroloj daŭris iom pli longe ol kutime.
- Provu ruĝigi la komponantojn en la monitora sistemo nur kiam certe estas problemo. Se ili ruĝiĝas por nenio, tiam vi ĉesos atenti la sciigojn de la monitora sistemo, ĝia signifo perdiĝos.
Se vi ankoraŭ ne uzas monitoran sistemon, komencu! Ĝi ne estas tiel malfacila kiel ŝajnas. Bonvolu rigardi la verdan ingrediencan arbon, kiun vi mem kreskigis.
Bonŝancon.
fonto: www.habr.com