Ni pensis pri krei monitoran sistemon en la stadio de formi produktteamojn. Evidentiĝis, ke nia komerco - ekspluato - ne falas en ĉi tiujn teamojn. Kial estas tio?
La fakto estas, ke ĉiuj niaj teamoj estas konstruitaj ĉirkaŭ individuaj informsistemoj, mikroservoj kaj frontoj, do la teamoj ne vidas la ĝeneralan sanon de la tuta sistemo kiel tutaĵo. Ekzemple, ili eble ne scias kiel iu malgranda parto en la profunda backend influas la antaŭan finaĵon. Ilia amplekso de intereso estas limigita al la sistemoj kun kiuj ilia sistemo estas integrita. Se teamo kaj ĝia servo A preskaŭ ne havas rilaton kun servo B, tiam tia servo estas preskaŭ nevidebla por la teamo.
Nia teamo, siavice, laboras kun sistemoj kiuj estas tre forte integritaj unu kun la alia: estas multaj ligoj inter ili, ĉi tio estas tre granda infrastrukturo. Kaj la funkciado de la reta vendejo dependas de ĉiuj ĉi tiuj sistemoj (el kiuj ni havas, cetere, grandegan nombron).
Do montriĝas, ke nia fako ne apartenas al iu teamo, sed troviĝas iom flanke. En ĉi tiu tuta rakonto, nia tasko estas amplekse kompreni kiel informa sistemoj funkcias, ilia funkcieco, integriĝoj, programaro, reto, aparataro, kaj kiel ĉio ĉi estas konektita unu al la alia.
La platformo sur kiu funkcias niaj interretaj vendejoj aspektas jene:
- antaŭa
- meza oficejo
- dorso
Kiom ajn ni ŝatus, ne okazas, ke ĉiuj sistemoj funkcias glate kaj senriproĉe. La punkto, denove, estas la nombro da sistemoj kaj integriĝoj - kun io kiel la nia, kelkaj okazaĵoj estas neeviteblaj, malgraŭ la kvalito de testado. Krome, kaj ene de aparta sistemo kaj laŭ ilia integriĝo. Kaj vi devas kontroli la staton de la tuta platformo amplekse, kaj ne nur ajna individua parto de ĝi.
Ideale, tutplatforma sanmonitorado devus esti aŭtomatigita. Kaj ni venis al monitorado kiel neevitebla parto de ĉi tiu procezo. Komence, ĝi estis konstruita nur por la frontlinia parto, dum retspecialistoj, programaro kaj aparataro administrantoj havis kaj daŭre havas siajn proprajn tavolo-post-tavola monitoradsistemoj. Ĉiuj tiuj homoj sekvis la monitoradon nur je sia propra nivelo; ankaŭ neniu havis ampleksan komprenon.
Ekzemple, se virtuala maŝino kraŝas, plejofte nur la administranto respondeca pri la aparataro kaj la virtuala maŝino scias pri ĝi. En tiaj kazoj, la unualinia teamo vidis la fakton mem de la aplika kraŝo, sed ĝi ne havis datumojn pri la kraŝo de la virtuala maŝino. Kaj la administranto povas scii kiu estas la kliento kaj havi malglatan ideon pri tio, kio nuntempe funkcias sur ĉi tiu virtuala maŝino, kondiĉe ke ĝi estas ia granda projekto. Li plej verŝajne ne scias pri la etuloj. Ĉiukaze, la administranto devas iri al la posedanto kaj demandi kio estis sur ĉi tiu maŝino, kio devas esti restaŭrita kaj kio devas esti ŝanĝita. Kaj se io vere serioza paneis, ili ekkuris ronde — ĉar neniu vidis la sistemon entute.
Finfine, tiaj malsimilaj rakontoj influas la tutan fasadon, uzantojn kaj nian kerna komerca funkcio - interreta vendo. Ĉar ni ne estas parto de teamo, sed okupiĝas pri la funkciado de ĉiuj elektronikaj aplikoj kiel parto de reta vendejo, ni prenis la taskon krei ampleksan monitoran sistemon por la elektronika platformo.
Sistemstrukturo kaj stako
Ni komencis identigante plurajn monitorajn tavolojn por niaj sistemoj, ene de kiuj ni bezonus kolekti metrikojn. Kaj ĉio ĉi devis esti kombinita, kion ni faris en la unua etapo. Nun en ĉi tiu etapo ni finas la plej altkvalitan kolekton de metrikoj tra ĉiuj niaj tavoloj por konstrui korelacion kaj kompreni kiel sistemoj influas unu la alian.
La manko de ampleksa monitorado ĉe la komencaj etapoj de lanĉo de aplikaĵo (ĉar ni komencis konstrui ĝin kiam la plej multaj el la sistemoj estis en produktado) kondukis al la fakto, ke ni havis gravan teknikan ŝuldon por agordi monitoradon de la tuta platformo. Ni ne povis pagi koncentriĝi pri agordo de monitorado por unu IS kaj detale prilabori monitoradon por ĝi, ĉar la ceteraj sistemoj restus sen monitorado dum iom da tempo. Por solvi ĉi tiun problemon, ni identigis liston de la plej necesaj metrikoj por taksi la staton de la informsistemo laŭ tavolo kaj komencis efektivigi ĝin.
Tial, ili decidis manĝi la elefanton en partoj.
Nia sistemo konsistas el:
- aparataro;
- operaciumo;
- programaro;
- UI-partoj en la monitora aplikaĵo;
- komercaj metrikoj;
- integrigaj aplikoj;
- informa sekureco;
- retoj;
- trafikbalancilo.
En la centro de ĉi tiu sistemo estas kontrolanta sin. Por ĝenerale kompreni la staton de la tuta sistemo, vi devas scii kio okazas kun aplikoj sur ĉiuj ĉi tiuj tavoloj kaj tra la tuta aro de aplikoj.
Do, pri la stako.
Ni uzas liberkodan programon. En la centro ni havas Zabbix, kiun ni uzas ĉefe kiel atentigan sistemon. Ĉiuj scias, ke ĝi estas ideala por monitorado de infrastrukturoj. Kion ĉi tio signifas? Ĝuste tiujn malaltnivelajn metrikojn, kiujn havas ĉiu kompanio, kiu konservas sian propran datumcentron (kaj Sportmaster havas siajn proprajn datumcentrojn) - servila temperaturo, memorstatuso, atako, retaj aparatoj.
Ni integris Zabbix kun la Telegram-mesaĝo kaj Microsoft Teamoj, kiuj estas aktive uzataj en teamoj. Zabbix kovras la tavolon de la fakta reto, aparataro kaj iu programaro, sed ĝi ne estas panaceo. Ni riĉigas ĉi tiujn datumojn de iuj aliaj servoj. Ekzemple, ĉe la aparataro, ni rekte konektas per API al nia virtualiga sistemo kaj kolektas datumojn.
Kion alian. Krom Zabbix, ni uzas Prometheus, kiu ebligas al ni monitori metrikojn en dinamika medio-aplikaĵo. Tio estas, ni povas ricevi aplikajn metrikojn per HTTP-finpunkto kaj ne zorgi pri kiuj metrikoj ŝarĝi en ĝi kaj kiuj ne. Surbaze de ĉi tiuj datumoj, analizaj demandoj povas esti evoluigitaj.
Datumfontoj por aliaj tavoloj, ekzemple, komercaj metrikoj, estas dividitaj en tri komponentojn.
Unue, ĉi tiuj estas eksteraj komercaj sistemoj, Google Analytics, ni kolektas metrikojn de ŝtipoj. De ili ni ricevas datumojn pri aktivaj uzantoj, konvertiĝoj kaj ĉio alia rilata al la komerco. Due, ĉi tio estas UI-monitora sistemo. Ĝi devus esti priskribita pli detale.
Iam ni komencis kun manlibrotestado kaj ĝi kreskis al aŭtomataj testoj de funkcieco kaj integriĝoj. El tio ni faris monitoradon, lasante nur la ĉefan funkciojn, kaj fidis markilojn, kiuj estas kiel eble plej stabilaj kaj ne ofte ŝanĝiĝas laŭlonge de la tempo.
La nova teamstrukturo signifas, ke ĉiuj aplikaj agadoj estas limigitaj al produktaj teamoj, do ni ĉesis fari puran testadon. Anstataŭe, ni faris UI-monitoradon de la testoj, skribitaj en Java, Selenium kaj Jenkins (uzita kiel sistemo por lanĉi kaj generi raportojn).
Ni havis multajn provojn, sed finfine ni decidis iri al la ĉefa vojo, la plej altan metrikon. Kaj se ni havas multajn specifajn provojn, estos malfacile teni la datumojn ĝisdatigitaj. Ĉiu posta eldono signife rompos la tutan sistemon, kaj ĉio, kion ni faros, estas ripari ĝin. Tial ni koncentriĝis pri tre fundamentaj aferoj, kiuj malofte ŝanĝiĝas, kaj ni nur kontrolas ilin.
Fine, trie, la datumfonto estas centralizita registradsistemo. Ni uzas Elastic Stack por ŝtipoj, kaj tiam ni povas tiri ĉi tiujn datumojn en nian monitoran sistemon por komercaj metrikoj. Aldone al ĉio ĉi, ni havas nian propran Monitoring API-servon, skribitan en Python, kiu demandas iujn ajn servojn per API kaj kolektas datumojn de ili en Zabbix.
Alia nemalhavebla atributo de monitorado estas bildigo. La nia baziĝas sur Grafana. Ĝi elstaras inter aliaj bildigaj sistemoj, ĉar ĝi ebligas al vi bildigi metrikojn de malsamaj datumfontoj sur la panelo. Ni povas kolekti altnivelajn metrikojn por reta butiko, ekzemple, la nombro da mendoj faritaj en la lasta horo de la DBMS, agado-metrikoj por la OS, sur kiu ĉi tiu reta vendejo funkcias de Zabbix, kaj metrikoj por ekzemploj de ĉi tiu aplikaĵo. de Prometeo. Kaj ĉio ĉi estos sur unu panelo. Klara kaj alirebla.
Mi rimarku pri sekureco - ni nuntempe finfinas la sistemon, kiun ni poste integros kun la tutmonda monitora sistemo. Laŭ mi, la ĉefaj problemoj, kiujn alfrontas elektronika komerco en la kampo de informa sekureco, rilatas al robotoj, analiziloj kaj krudforto. Ni devas observi ĉi tion, ĉar ĉio ĉi povas kritike influi kaj la funkciadon de niaj aplikaĵoj kaj nian reputacion de komerca vidpunkto. Kaj per la elektita stako ni sukcese kovras ĉi tiujn taskojn.
Alia grava punkto estas, ke la aplika tavolo estas kunvenita de Prometheus. Li mem ankaŭ estas integrita kun Zabbix. Kaj ni ankaŭ havas sitespeed, servon, kiu ebligas al ni vidi parametrojn kiel la ŝarĝo-rapido de nia paĝo, boteloj, paĝa bildigo, ŝarĝo de skriptoj ktp., ĝi ankaŭ estas API integrita. Do niaj metrikoj estas kolektitaj en Zabbix, kaj sekve, ni ankaŭ atentigas de tie. Ĉiuj atentigoj estas nuntempe senditaj al la ĉefaj sendaj metodoj (nuntempe ĝi estas retpoŝto kaj telegramo, MS Teams ankaŭ lastatempe estis konektita). Estas planoj ĝisdatigi atentigon pri tia stato, ke inteligentaj bots funkcias kiel servo kaj provizas monitorajn informojn al ĉiuj interesataj produktteamoj.
Por ni, metrikoj gravas ne nur por individuaj informsistemoj, sed ankaŭ ĝeneralaj metrikoj por la tuta infrastrukturo kiun aplikaĵoj uzas: aretoj de fizikaj serviloj sur kiuj funkcias virtualaj maŝinoj, trafikbalanciloj, Network Load Balancers, la reto mem, utiligo de komunikadkanaloj. . Plus metrikoj por niaj propraj datumcentroj (ni havas plurajn el ili kaj la infrastrukturo estas sufiĉe granda).
La avantaĝoj de nia monitora sistemo estas, ke per ĝia helpo ni vidas la sanan staton de ĉiuj sistemoj kaj povas taksi ilian efikon unu al la alia kaj al komunaj rimedoj. Kaj finfine, ĝi permesas al ni okupiĝi pri planado de rimedoj, kio ankaŭ estas nia respondeco. Ni administras servilresursojn - naĝejon ene de elektronika komerco, komisias kaj malfunkciigas novajn ekipaĵojn, aĉetas aldonajn novajn ekipaĵojn, faras revizion de utiligo de rimedoj ktp. Ĉiujare, teamoj planas novajn projektojn, disvolvas siajn sistemojn, kaj estas grave por ni provizi ilin per rimedoj.
Kaj helpe de metrikoj, ni vidas la tendencon en la konsumo de rimedoj de niaj informsistemoj. Kaj surbaze de ili ni povas plani ion. Sur la nivelo de virtualigo, ni kolektas datumojn kaj vidas informojn pri la disponebla kvanto de rimedoj per datumcentro. Kaj jam ene de la datumcentro vi povas vidi la recikladon, la realan distribuon kaj konsumon de rimedoj. Krome, ambaŭ kun memstaraj serviloj kaj virtualaj maŝinoj kaj aroj de fizikaj serviloj sur kiuj ĉiuj ĉi tiuj virtualaj maŝinoj vigle turniĝas.
Perspektivoj
Nun ni havas la kernon de la sistemo entute preta, sed ankoraŭ estas multaj aferoj pri kiuj ankoraŭ necesas prilabori. Minimume, ĉi tio estas informa sekureca tavolo, sed ankaŭ gravas atingi la reton, disvolvi atentigon kaj solvi la problemon de korelacio. Ni havas multajn tavolojn kaj sistemojn, kaj sur ĉiu tavolo estas multaj pli da metrikoj. Ĝi montriĝas matrioŝko ĝis la grado de matrioŝko.
Nia tasko estas finfine fari la ĝustajn atentigojn. Ekzemple, se estis problemo kun la aparataro, denove, kun virtuala maŝino, kaj estis grava aplikaĵo, kaj la servo neniel subtenis. Ni ekscias, ke la virtuala maŝino mortis. Tiam komercaj metrikoj atentigos vin: uzantoj malaperis ie, ne estas konvertiĝo, la UI en la interfaco estas neatingebla, programaro kaj servoj ankaŭ mortis.
En ĉi tiu situacio, ni ricevos spamon de atentigoj, kaj ĉi tio ne plu taŭgas en la formato de taŭga monitora sistemo. La demando pri korelacio ekestas. Tial, ideale, nia monitora sistemo devus diri: "Knaboj, via fizika maŝino mortis, kaj kune kun ĝi ĉi tiu aplikaĵo kaj ĉi tiuj metrikoj", helpe de unu atentigo, anstataŭ furioze bombardi nin per cent atentigoj. Ĝi devus raporti la ĉefan aferon - la kaŭzon, kiu helpas rapide forigi la problemon pro ĝia lokalizo.
Nia sciiga sistemo kaj atentiga prilaborado estas konstruitaj ĉirkaŭ XNUMX-hora servo de servo. Ĉiuj atentigoj kiuj estas konsiderataj nepraj kaj estas inkluzivitaj en la kontrola listo estas senditaj tie. Ĉiu atentigo devas havi priskribon: kio okazis, kion ĝi efektive signifas, kion ĝi influas. Kaj ankaŭ ligo al la panelo kaj instrukcioj pri tio, kion fari en ĉi tiu kazo.
Ĉi tio temas pri la postuloj por konstrui alarmon. Tiam la situacio povas disvolviĝi en du direktoj - aŭ ekzistas problemo kaj devas esti solvita, aŭ okazis malsukceso en la monitora sistemo. Sed ĉiukaze, vi devas iri kaj eltrovi ĝin.
Averaĝe, ni nun ricevas ĉirkaŭ cent atentigojn tage, konsiderante la fakton, ke la korelacio de atentigoj ankoraŭ ne estis ĝuste agordita. Kaj se ni bezonas fari teknikan laboron, kaj ni perforte malŝaltas ion, ilia nombro signife pliiĝas.
Krom monitori la sistemojn, kiujn ni funkciigas kaj kolekti metrikojn, kiuj estas konsiderataj gravaj de nia flanko, la monitora sistemo permesas al ni kolekti datumojn por produktaj teamoj. Ili povas influi la komponadon de metrikoj ene de la informsistemoj, kiujn ni kontrolas.
Nia kolego povas veni kaj peti aldoni iun metrikon kiu estos utila por kaj ni kaj la teamo. Aŭ, ekzemple, la teamo eble ne havas sufiĉe da la bazaj metrikoj, kiujn ni havas; ili devas spuri iujn specifajn. En Grafana, ni kreas spacon por ĉiu teamo kaj donas administrajn rajtojn. Ankaŭ, se teamo bezonas instrumentpanelojn, sed ili mem ne povas/ne scias kiel fari ĝin, ni helpas ilin.
Ĉar ni estas ekster la fluo de la valorkreado de la teamo, iliaj eldonoj kaj planado, ni iom post iom venas al la konkludo, ke eldonoj de ĉiuj sistemoj estas senjuntaj kaj povas esti lanĉitaj ĉiutage sen kunordigo kun ni. Kaj estas grave por ni kontroli ĉi tiujn eldonojn, ĉar ili eble povus influi la funkciadon de la aplikaĵo kaj rompi ion, kaj ĉi tio estas kritika. Por administri eldonojn, ni uzas Bambuon, de kie ni ricevas datumojn per API kaj povas vidi kiuj eldonoj estis publikigitaj en kiuj informsistemoj kaj ilia stato. Kaj la plej grava afero estas je kioma horo. Ni supermetas liberigajn markilojn sur la ĉefaj kritikaj metrikoj, kio estas vide tre indika en kazo de problemoj.
Tiel ni povas vidi la korelacion inter novaj eldonoj kaj emerĝantaj problemoj. La ĉefa ideo estas kompreni kiel la sistemo funkcias ĉe ĉiuj tavoloj, rapide lokalizi la problemon kaj ripari ĝin same rapide. Ja ofte okazas, ke tio, kio bezonas la plej grandan tempon, ne estas solvi la problemon, sed serĉi la kaŭzon.
Kaj en ĉi tiu areo estonte ni volas koncentriĝi pri proaktiveco. Ideale, mi ŝatus scii pri proksimiĝanta problemo antaŭe, kaj ne post la fakto, por ke mi povu malhelpi ĝin prefere ol solvi ĝin. Kelkfoje okazas falsaj alarmoj de la monitora sistemo, kaj pro homa eraro kaj pro ŝanĝoj en la aplikaĵo.Kaj ni laboras pri tio, elpurigas ĝin kaj provas averti pri tio uzantojn, kiuj uzas ĝin kun ni, antaŭ iu ajn manipulado de la monitora sistemo. , aŭ plenumi ĉi tiujn agadojn en la teknika fenestro.
Do, la sistemo estas lanĉita kaj sukcese funkcias ekde la komenco de printempo... kaj montras tre realajn profitojn. Kompreneble, ĉi tio ne estas ĝia fina versio; ni enkondukos multajn pli utilajn funkciojn. Sed nun, kun tiom da integriĝoj kaj aplikoj, monitorado de aŭtomatigo estas vere neevitebla.
Se vi ankaŭ kontrolas grandajn projektojn kun signifa nombro da integriĝoj, skribu en la komentoj, kian arĝentan kuglon vi trovis por ĉi tio.
fonto: www.habr.com