Ons het daaraan gedink om 'n moniteringstelsel te skep tydens die vorming van produkspanne. Dit het duidelik geword dat ons besigheid – uitbuiting – nie in hierdie spanne val nie. Hoekom is dit?
Die feit is dat al ons spanne rondom individuele inligtingstelsels, mikrodienste en fronte gebou is, sodat die spanne nie die algehele gesondheid van die hele stelsel as geheel sien nie. Byvoorbeeld, hulle weet dalk nie hoe een of ander klein deel in die diep agterkant die voorkant beïnvloed nie. Hul omvang van belangstelling is beperk tot die stelsels waarmee hul stelsel geïntegreer is. As 'n span en sy diens A byna geen verband met diens B het nie, dan is so 'n diens byna onsigbaar vir die span.
Ons span werk op sy beurt met stelsels wat baie sterk met mekaar geïntegreer is: daar is baie verbindings tussen hulle, dit is 'n baie groot infrastruktuur. En die werking van die aanlynwinkel hang af van al hierdie stelsels (waarvan ons, terloops, 'n groot aantal het).
Dit blyk dus dat ons departement aan geen span behoort nie, maar 'n bietjie aan die kant geleë is. In hierdie hele storie is ons taak om omvattend te verstaan hoe inligtingstelsels werk, hul funksionaliteit, integrasies, sagteware, netwerk, hardeware, en hoe dit alles met mekaar verbind is.
Die platform waarop ons aanlynwinkels werk, lyk soos volg:
- voor
- middel kantoor
- terug kantoor
Maak nie saak hoe graag ons wil hê nie, dit gebeur nie dat alle stelsels glad en foutloos werk nie. Die punt is weereens die aantal stelsels en integrasies - met iets soos ons s'n is sommige voorvalle onvermydelik, ten spyte van die kwaliteit van toetsing. Verder, beide binne 'n aparte stelsel en in terme van hul integrasie. En jy moet die toestand van die hele platform omvattend monitor, en nie net enige individuele deel daarvan nie.
Ideaal gesproke moet platformwye gesondheidsmonitering geoutomatiseer word. En ons het by monitering gekom as 'n onvermydelike deel van hierdie proses. Aanvanklik is dit net vir die voorlyn-deel gebou, terwyl netwerkspesialiste, sagteware- en hardeware-administrateurs hul eie laag-vir-laag-moniteringstelsels gehad het en steeds het. Al hierdie mense het die monitering slegs op hul eie vlak gevolg; niemand het ook 'n omvattende begrip gehad nie.
Byvoorbeeld, as 'n virtuele masjien ineenstort, weet in die meeste gevalle net die administrateur verantwoordelik vir die hardeware en die virtuele masjien daarvan. In sulke gevalle het die frontlinie-span die feit van die toepassing-ongeluk gesien, maar dit het nie data oor die ongeluk van die virtuele masjien gehad nie. En die administrateur kan weet wie die kliënt is en 'n rowwe idee hê van wat tans op hierdie virtuele masjien loop, mits dit 'n soort groot projek is. Hy weet heel waarskynlik nie van die kleintjies nie. In elk geval moet die administrateur na die eienaar gaan en vra wat op hierdie masjien was, wat herstel moet word en wat verander moet word. En as iets regtig ernstig gebreek het, het hulle in sirkels begin rondhardloop – want niemand het die stelsel as geheel gesien nie.
Uiteindelik raak sulke uiteenlopende stories die hele frontend, gebruikers en ons kernbesigheidsfunksie – aanlynverkope. Aangesien ons nie deel van 'n span is nie, maar betrokke is by die bedryf van alle e-handelstoepassings as deel van 'n aanlynwinkel, het ons die taak aangepak om 'n omvattende moniteringstelsel vir die e-handelsplatform te skep.
Stelselstruktuur en stapel
Ons het begin deur verskeie moniteringslae vir ons stelsels te identifiseer, waarbinne ons statistieke sal moet insamel. En dit alles moes gekombineer word, en dit is wat ons in die eerste stadium gedoen het. Nou finaliseer ons op hierdie stadium die hoogste gehalte versameling van metrieke oor al ons lae om 'n korrelasie te bou en te verstaan hoe stelsels mekaar beïnvloed.
Die gebrek aan omvattende monitering in die aanvanklike stadiums van toepassingbekendstelling (sedert ons dit begin bou het toe die meeste van die stelsels in produksie was) het daartoe gelei dat ons aansienlike tegniese skuld gehad het om monitering van die hele platform op te stel. Ons kon nie bekostig om te fokus op die opstel van monitering vir een IS en die monitering daarvoor in detail uit te werk nie, aangesien die res van die stelsels vir 'n geruime tyd sonder monitering gelaat sou word. Om hierdie probleem op te los, het ons 'n lys van die mees nodige maatstawwe vir die beoordeling van die toestand van die inligtingstelsel vir laag geïdentifiseer en begin om dit te implementeer.
Daarom het hulle besluit om die olifant in dele te eet.
Ons stelsel bestaan uit:
- hardeware;
- bedryfstelsel;
- sagteware;
- UI dele in die monitering aansoek;
- besigheids statistieke;
- integrasietoepassings;
- inligtings sekuriteit;
- netwerke;
- verkeersbalanseerder.
Die middel van hierdie stelsel is om homself te monitor. Om die toestand van die hele stelsel oor die algemeen te verstaan, moet jy weet wat met toepassings op al hierdie lae en oor die hele stel toepassings gebeur.
So, oor die stapel.
Ons gebruik oopbronsagteware. By die sentrum het ons Zabbix, wat ons hoofsaaklik as 'n waarskuwingstelsel gebruik. Almal weet dat dit ideaal is vir infrastruktuurmonitering. Wat beteken dit? Presies daardie laevlak-statistieke wat elke maatskappy wat sy eie datasentrum onderhou het (en Sportmaster het sy eie datasentrums) – bedienertemperatuur, geheuestatus, klopjag, netwerktoestelmetrieke.
Ons het Zabbix geïntegreer met die Telegram-boodskapper en Microsoft-spanne, wat aktief in spanne gebruik word. Zabbix dek die laag van die werklike netwerk, hardeware en sommige sagteware, maar dit is nie 'n wondermiddel nie. Ons verryk hierdie data van sommige ander dienste. Byvoorbeeld, op hardeware-vlak koppel ons direk via API aan ons virtualiseringstelsel en versamel data.
Wat nog. Benewens Zabbix, gebruik ons Prometheus, wat ons in staat stel om metrieke in 'n dinamiese omgewingstoepassing te monitor. Dit wil sê, ons kan toepassingsstatistieke via 'n HTTP-eindpunt ontvang en nie bekommerd wees oor watter maatstawwe om daarin te laai en watter nie. Op grond van hierdie data kan analitiese navrae ontwikkel word.
Databronne vir ander lae, byvoorbeeld besigheidsmetrieke, word in drie komponente verdeel.
Eerstens, dit is eksterne besigheidstelsels, Google Analytics, ons versamel maatstawwe uit logs. Van hulle kry ons data oor aktiewe gebruikers, omskakelings en alles wat met die besigheid verband hou. Tweedens, dit is 'n UI-moniteringstelsel. Dit moet in meer besonderhede beskryf word.
Eens op 'n tyd het ons begin met handmatige toetsing en dit het gegroei tot outomatiese toetse van funksionaliteit en integrasies. Hieruit het ons monitering gemaak, net die hooffunksionaliteit gelaat, en staatgemaak op merkers wat so stabiel as moontlik is en nie dikwels met verloop van tyd verander nie.
Die nuwe spanstruktuur beteken dat alle toepassingsaktiwiteite tot produkspanne beperk is, so ons het opgehou om suiwer toetse te doen. In plaas daarvan het ons UI-monitering gemaak uit die toetse, geskryf in Java, Selenium en Jenkins (wat gebruik word as 'n stelsel vir die bekendstelling en generering van verslae).
Ons het baie toetse gehad, maar op die ou end het ons besluit om na die hoofweg te gaan, die topvlak-metriek. En as ons baie spesifieke toetse het, sal dit moeilik wees om die data op datum te hou. Elke daaropvolgende vrystelling sal die hele stelsel aansienlik breek, en al wat ons sal doen is om dit reg te stel. Daarom het ons gefokus op baie fundamentele dinge wat selde verander, en ons monitor dit net.
Ten slotte, derdens, is die databron 'n gesentraliseerde aantekenstelsel. Ons gebruik Elastic Stack vir logs, en dan kan ons hierdie data in ons moniteringstelsel vir besigheidsstatistieke intrek. Benewens dit alles, het ons ons eie Monitoring API-diens, geskryf in Python, wat enige dienste via API navrae en data van hulle in Zabbix insamel.
Nog 'n onontbeerlike eienskap van monitering is visualisering. Ons s'n is gebaseer op Grafana. Dit staan uit onder ander visualiseringstelsels deurdat dit jou toelaat om statistieke van verskillende databronne op die dashboard te visualiseer. Ons kan topvlak-statistieke vir 'n aanlyn winkel insamel, byvoorbeeld die aantal bestellings wat in die laaste uur van die DBMS geplaas is, prestasiemaatstawwe vir die bedryfstelsel waarop hierdie aanlyn winkel vanaf Zabbix loop, en statistieke vir gevalle van hierdie toepassing van Prometheus. En dit alles sal op een dashboard wees. Duidelik en toeganklik.
Laat ek kennis neem oor sekuriteit - ons is tans besig om die stelsel te finaliseer, wat ons later met die globale moniteringstelsel sal integreer. Na my mening hou die hoofprobleme wat e-handel in die gesig staar op die gebied van inligtingsekuriteit verband met bots, ontleders en brute force. Ons moet 'n ogie hieroor hou, want dit alles kan beide die werking van ons toepassings en ons reputasie vanuit 'n besigheidsoogpunt krities beïnvloed. En met die gekose stapel dek ons hierdie take suksesvol.
Nog 'n belangrike punt is dat die toedieningslaag deur Prometheus saamgestel word. Hy is self ook geïntegreer met Zabbix. En ons het ook sitespeed, 'n diens wat ons toelaat om parameters te sien soos die laaispoed van ons bladsy, knelpunte, bladsyweergawe, laaiskrifte, ens., dit is ook API-geïntegreer. Ons statistieke word dus in Zabbix ingesamel, en dienooreenkomstig waarsku ons ook van daar af. Alle waarskuwings word tans na die hoofstuurmetodes gestuur (vir nou is dit e-pos en telegram, MS Teams is ook onlangs gekoppel). Daar is planne om waarskuwing op te gradeer na so 'n toestand dat slim bots as 'n diens werk en moniteringsinligting aan alle belangstellende produkspanne verskaf.
Vir ons is maatstawwe nie net belangrik vir individuele inligtingstelsels nie, maar ook algemene maatstawwe vir die hele infrastruktuur wat toepassings gebruik: groepe fisiese bedieners waarop virtuele masjiene loop, verkeersbalanseerders, Netwerk Load Balanseerders, die netwerk self, benutting van kommunikasiekanale . Plus statistieke vir ons eie datasentrums (ons het verskeie van hulle en die infrastruktuur is redelik groot).
Die voordele van ons moniteringstelsel is dat ons met sy hulp die gesondheidstatus van alle stelsels sien en die impak daarvan op mekaar en op gedeelde hulpbronne kan evalueer. En uiteindelik laat dit ons toe om by hulpbronbeplanning betrokke te raak, wat ook ons verantwoordelikheid is. Ons bestuur bedienerhulpbronne - 'n poel binne e-handel, stel nuwe toerusting in gebruik en stel nuwe toerusting in werking, koop bykomende nuwe toerusting, doen 'n oudit van hulpbronbenutting, ens. Elke jaar beplan spanne nuwe projekte, ontwikkel hul stelsels, en dit is vir ons belangrik om hulle van hulpbronne te voorsien.
En met behulp van maatstawwe sien ons die neiging in hulpbronverbruik deur ons inligtingstelsels. En op grond van hulle kan ons iets beplan. Op die virtualisasievlak versamel ons data en sien ons inligting oor die beskikbare hoeveelheid hulpbronne per datasentrum. En reeds binne die datasentrum kan jy die herwinning, die werklike verspreiding en verbruik van hulpbronne sien. Verder, beide met selfstandige bedieners en virtuele masjiene en groepe fisiese bedieners waarop al hierdie virtuele masjiene kragtig draai.
Vooruitsigte
Nou het ons die kern van die stelsel as geheel gereed, maar daar is nog baie dinge waaraan nog gewerk moet word. Dit is ten minste 'n inligtingsekuriteitslaag, maar dit is ook belangrik om die netwerk te bereik, waarskuwing te ontwikkel en die kwessie van korrelasie op te los. Ons het baie lae en stelsels, en op elke laag is daar baie meer metrieke. Dit blyk 'n matrioshka te wees in die mate van 'n matrioshka.
Ons taak is om uiteindelik die regte waarskuwings te maak. Byvoorbeeld, as daar 'n probleem met die hardeware was, weer, met 'n virtuele masjien, en daar was 'n belangrike toepassing, en die diens is op geen manier gerugsteun nie. Ons vind uit dat die virtuele masjien dood is. Dan sal besigheidsstatistieke jou waarsku: gebruikers het iewers verdwyn, daar is geen omskakeling nie, die UI in die koppelvlak is nie beskikbaar nie, sagteware en dienste het ook gesterf.
In hierdie situasie sal ons strooipos van waarskuwings ontvang, en dit pas nie meer in die formaat van 'n behoorlike moniteringstelsel nie. Die kwessie van korrelasie ontstaan. Daarom, ideaal gesproke, moet ons moniteringstelsel sê: "Manne, julle fisiese masjien is dood, en daarmee saam hierdie toepassing en hierdie statistieke," met die hulp van een waarskuwing, in plaas daarvan om ons verwoed met honderd waarskuwings te bombardeer. Dit moet die belangrikste ding rapporteer - die oorsaak, wat help om die probleem vinnig uit te skakel as gevolg van die lokalisering daarvan.
Ons kennisgewingstelsel en waarskuwingsverwerking is gebou rondom 'n XNUMX-uur blitslyndiens. Alle waarskuwings wat as 'n moet-hê beskou word en by die kontrolelys ingesluit is, word daarheen gestuur. Elke waarskuwing moet 'n beskrywing hê: wat gebeur het, wat dit eintlik beteken, wat dit raak. En ook 'n skakel na die dashboard en instruksies oor wat om in hierdie geval te doen.
Dit gaan alles oor die vereistes vir die bou van 'n waarskuwing. Dan kan die situasie in twee rigtings ontwikkel - óf daar is 'n probleem en moet opgelos word, óf daar was 'n mislukking in die moniteringstelsel. Maar in elk geval moet jy dit gaan uitpluis.
Gemiddeld ontvang ons nou ongeveer honderd waarskuwings per dag, met inagneming van die feit dat die korrelasie van waarskuwings nog nie behoorlik opgestel is nie. En as ons tegniese werk moet uitvoer en ons iets met geweld afskakel, neem hul getal aansienlik toe.
Benewens die monitering van die stelsels wat ons bedryf en die insamel van maatstawwe wat aan ons kant as belangrik beskou word, stel die moniteringstelsel ons in staat om data vir produkspanne in te samel. Hulle kan die samestelling van maatstawwe binne die inligtingstelsels wat ons monitor, beïnvloed.
Ons kollega kan dalk kom vra om 'n maatstaf by te voeg wat vir beide ons en die span nuttig sal wees. Of, byvoorbeeld, die span het dalk nie genoeg van die basiese maatstawwe wat ons het nie; hulle moet 'n paar spesifieke opspoor. In Grafana skep ons 'n spasie vir elke span en gee ons admin regte. Ook, as 'n span dashboards nodig het, maar hulle self kan/weet nie hoe om dit te doen nie, help ons hulle.
Aangesien ons buite die vloei van die span se waardeskepping, hul vrystellings en beplanning is, kom ons geleidelik tot die gevolgtrekking dat vrystellings van alle stelsels naatloos is en daagliks sonder koördinering met ons uitgerol kan word. En dit is vir ons belangrik om hierdie vrystellings te monitor, want dit kan moontlik die werking van die toepassing beïnvloed en iets breek, en dit is van kritieke belang. Om vrystellings te bestuur, gebruik ons Bamboo, vanwaar ons data via API ontvang en kan sien watter vrystellings in watter inligtingstelsels vrygestel is en hul status. En die belangrikste is op watter tyd. Ons plaas vrystellingsmerkers op die belangrikste kritieke maatstawwe, wat visueel baie aanduidend is in geval van probleme.
Op hierdie manier kan ons die korrelasie tussen nuwe vrystellings en opkomende probleme sien. Die hoofgedagte is om te verstaan hoe die stelsel by alle lae werk, die probleem vinnig te lokaliseer en net so vinnig reg te stel. Dit gebeur immers dikwels dat dit wat die meeste tyd verg, nie die probleem oplos nie, maar soek na die oorsaak.
En op hierdie gebied wil ons in die toekoms op proaktiwiteit fokus. Ideaal gesproke wil ek graag vooraf weet van 'n naderende probleem, en nie agterna nie, sodat ek dit kan voorkom eerder as om dit op te los. Soms kom vals alarms van die moniteringstelsel voor, beide as gevolg van menslike foute en as gevolg van veranderinge in die toepassing. En ons werk hieraan, ontfout dit en probeer gebruikers wat dit saam met ons gebruik hieroor waarsku voor enige manipulasie van die moniteringstelsel , of voer hierdie aktiwiteite in die tegniese venster uit.
So, die stelsel is van stapel gestuur en werk suksesvol sedert die begin van die lente ... en toon baie werklike winste. Dit is natuurlik nie die finale weergawe daarvan nie; ons sal baie meer nuttige funksies bekendstel. Maar op die oomblik, met soveel integrasies en toepassings, is monitering-outomatisering regtig onvermydelik.
As jy ook groot projekte met 'n aansienlike aantal integrasies monitor, skryf in die kommentaar watter silwer koeël jy hiervoor gevind het.
Bron: will.com