Vi funderade på att skapa ett övervakningssystem när vi bildade produktteam. Det blev tydligt att vår verksamhet - exploatering - inte faller i dessa team. Varför är det så?
Faktum är att alla våra team är uppbyggda kring individuella informationssystem, mikrotjänster och fronter, så teamen ser inte den övergripande hälsan för hela systemet som helhet. Till exempel kanske de inte vet hur någon liten del i den djupa bakdelen påverkar frontänden. Deras intresse är begränsat till de system som deras system är integrerat med. Om ett team och dess tjänst A nästan inte har något samband med tjänst B, så är en sådan tjänst nästan osynlig för teamet.
Vårt team jobbar i sin tur med system som är väldigt starkt integrerade med varandra: det finns många kopplingar mellan dem, det här är en väldigt stor infrastruktur. Och driften av onlinebutiken beror på alla dessa system (av vilka vi förresten har ett stort antal).
Så det visar sig att vår avdelning inte tillhör något lag, utan ligger lite vid sidan av. I hela den här historien är vår uppgift att heltäckande förstå hur informationssystem fungerar, deras funktionalitet, integrationer, mjukvara, nätverk, hårdvara och hur allt detta är kopplat till varandra.
Plattformen som våra nätbutiker verkar på ser ut så här:
- främre
- mellankontor
- back-office
Hur mycket vi än skulle vilja så händer det inte att alla system fungerar smidigt och felfritt. Poängen är återigen antalet system och integrationer - med något som vårt är vissa incidenter oundvikliga, trots kvaliteten på testerna. Dessutom både inom ett separat system och när det gäller deras integration. Och du måste övervaka tillståndet för hela plattformen heltäckande, och inte bara någon enskild del av den.
Helst bör plattformsövergripande hälsoövervakning automatiseras. Och vi kom till övervakning som en oundviklig del av denna process. Från början byggdes den bara för frontlinjen, medan nätverksspecialister, mjukvaru- och hårdvaruadministratörer hade och fortfarande har sina egna lager-för-lager-övervakningssystem. Alla dessa personer följde övervakningen endast på sin egen nivå, ingen hade heller en heltäckande förståelse.
Till exempel, om en virtuell maskin kraschar är det i de flesta fall bara administratören som är ansvarig för hårdvaran och den virtuella maskinen som vet om det. I sådana fall såg frontlinjeteamet själva faktumet att applikationen kraschade, men den hade inga data om kraschen för den virtuella maskinen. Och administratören kan veta vem kunden är och ha en ungefärlig uppfattning om vad som för närvarande körs på denna virtuella maskin, förutsatt att det är något slags stort projekt. Han vet förmodligen inte om de små. I vilket fall som helst måste administratören gå till ägaren och fråga vad som fanns på den här maskinen, vad som behöver återställas och vad som behöver ändras. Och om något riktigt allvarligt gick sönder började de springa runt i cirklar – för ingen såg systemet som en helhet.
I slutändan påverkar sådana olika historier hela frontend, användare och vår kärnverksamhetsfunktion - onlineförsäljning. Eftersom vi inte ingår i ett team, utan är engagerade i driften av alla e-handelsapplikationer som en del av en webbutik, tog vi på oss uppdraget att skapa ett heltäckande övervakningssystem för e-handelsplattformen.
Systemstruktur och stack
Vi började med att identifiera flera övervakningslager för våra system, inom vilka vi skulle behöva samla in mätvärden. Och allt detta behövde kombineras, vilket var vad vi gjorde i det första skedet. Nu i detta skede slutför vi samlingen av mätvärden av högsta kvalitet över alla våra lager för att bygga en korrelation och förstå hur system påverkar varandra.
Bristen på heltäckande övervakning i de inledande stadierna av applikationslanseringen (sedan vi började bygga den när de flesta av systemen var i produktion) ledde till att vi hade betydande tekniska skulder för att sätta upp övervakning av hela plattformen. Vi hade inte råd att fokusera på att sätta upp övervakning för en IS och utarbeta övervakning för den i detalj, eftersom resten av systemen skulle stå utan övervakning under en tid. För att lösa detta problem identifierade vi en lista över de mest nödvändiga måtten för att bedöma informationssystemets tillstånd efter lager och började implementera det.
Därför bestämde de sig för att äta elefanten i delar.
Vårt system består av:
- hårdvara;
- operativ system;
- programvara;
- UI-delar i övervakningsapplikationen;
- affärsmått;
- integrationsapplikationer;
- informationssäkerhet;
- nätverk;
- trafikbalanserare.
I centrum för detta system är övervakningen av sig själv. För att generellt förstå tillståndet för hela systemet måste du veta vad som händer med applikationer på alla dessa lager och över hela uppsättningen applikationer.
Så, om traven.
Vi använder programvara med öppen källkod. I centrum har vi Zabbix som vi framför allt använder som larmsystem. Alla vet att den är idealisk för infrastrukturövervakning. Vad betyder det här? Exakt de där lågnivåmåtten som varje företag som underhåller sitt eget datacenter har (och Sportmaster har sina egna datacenter) – servertemperatur, minnesstatus, raid, mätvärden för nätverksenheter.
Vi har integrerat Zabbix med Telegram messenger och Microsoft Teams, som aktivt används i team. Zabbix täcker lagret av det faktiska nätverket, hårdvaran och viss mjukvara, men det är inget universalmedel. Vi berikar denna data från vissa andra tjänster. Till exempel på hårdvarunivå ansluter vi direkt via API till vårt virtualiseringssystem och samlar in data.
Vad annars. Förutom Zabbix använder vi Prometheus, vilket gör att vi kan övervaka mätvärden i en dynamisk miljöapplikation. Det vill säga att vi kan ta emot applikationsstatistik via en HTTP-slutpunkt och inte oroa oss för vilka mätvärden som ska laddas in i den och vilka som inte. Baserat på dessa data kan analytiska frågor utvecklas.
Datakällor för andra lager, till exempel affärsmått, är uppdelade i tre komponenter.
För det första är det externa affärssystem, Google Analytics, vi samlar in mätvärden från loggar. Från dem får vi data om aktiva användare, konverteringar och allt annat relaterat till verksamheten. För det andra är detta ett UI-övervakningssystem. Det bör beskrivas mer detaljerat.
En gång i tiden började vi med manuell testning och det växte till automatiska tester av funktionalitet och integrationer. Från detta gjorde vi övervakning, lämnade bara huvudfunktionaliteten, och förlitade oss på markörer som är så stabila som möjligt och inte ändras ofta över tiden.
Den nya teamstrukturen innebär att alla applikationsaktiviteter är begränsade till produktteam, så vi slutade göra rena tester. Istället gjorde vi UI-övervakning från testerna, skrivna i Java, Selenium och Jenkins (används som ett system för att starta och generera rapporter).
Vi hade många tester, men till slut bestämde vi oss för att gå till huvudvägen, den högsta nivån. Och om vi har många specifika tester blir det svårt att hålla data uppdaterad. Varje efterföljande utgåva kommer avsevärt att förstöra hela systemet, och allt vi kommer att göra är att fixa det. Därför fokuserade vi på mycket grundläggande saker som sällan förändras, och vi övervakar dem bara.
Slutligen, för det tredje, är datakällan ett centraliserat loggningssystem. Vi använder Elastic Stack för loggar, och sedan kan vi dra in denna data till vårt övervakningssystem för affärsmått. Utöver allt detta har vi vår egen Monitoring API-tjänst, skriven i Python, som frågar efter alla tjänster via API och samlar in data från dem till Zabbix.
En annan oumbärlig egenskap för övervakning är visualisering. Vår är baserad på Grafana. Det sticker ut bland andra visualiseringssystem genom att det låter dig visualisera mätvärden från olika datakällor på instrumentpanelen. Vi kan samla in mätvärden på toppnivå för en onlinebutik, till exempel antalet beställningar som gjorts under den senaste timmen från DBMS, prestandastatistik för operativsystemet som denna onlinebutik körs på från Zabbix och mätvärden för instanser av denna applikation från Prometheus. Och allt detta kommer att finnas på en instrumentpanel. Tydlig och tillgänglig.
Låt mig notera om säkerhet - vi håller för närvarande på att slutföra systemet, som vi senare kommer att integrera med det globala övervakningssystemet. Enligt min åsikt är de största problemen som e-handeln möter inom informationssäkerhetsområdet relaterade till bots, parsers och brute force. Vi måste hålla ett öga på detta, eftersom allt detta kan kritiskt påverka både driften av våra applikationer och vårt rykte ur affärsmässig synvinkel. Och med den valda stacken täcker vi framgångsrikt dessa uppgifter.
En annan viktig punkt är att appliceringsskiktet är sammansatt av Prometheus. Själv är han också integrerad med Zabbix. Och vi har även sitespeed, en tjänst som låter oss se parametrar som laddningshastigheten på vår sida, flaskhalsar, sidrendering, laddning av skript, etc., den är också API integrerad. Så våra mätvärden samlas in i Zabbix, och därför larmar vi också därifrån. Alla varningar skickas för närvarande till de viktigaste sändningsmetoderna (för nu är det e-post och telegram, MS Teams har också nyligen kopplats). Det finns planer på att uppgradera varningen till ett sådant tillstånd att smarta bots fungerar som en tjänst och tillhandahåller övervakningsinformation till alla intresserade produktteam.
För oss är mätvärden viktiga inte bara för enskilda informationssystem, utan också generella mätvärden för hela infrastrukturen som applikationer använder: kluster av fysiska servrar på vilka virtuella maskiner körs, trafikbalanserare, Network Load Balancers, själva nätverket, utnyttjande av kommunikationskanaler . Plus mätvärden för våra egna datacenter (vi har flera av dem och infrastrukturen är ganska stor).
Fördelarna med vårt övervakningssystem är att vi med dess hjälp ser hälsotillståndet för alla system och kan bedöma deras inverkan på varandra och på gemensamma resurser. Och i slutändan tillåter det oss att engagera oss i resursplanering, vilket också är vårt ansvar. Vi hanterar serverresurser - en pool inom e-handel, tar i drift och avvecklar ny utrustning, köper ytterligare ny utrustning, genomför en revision av resursutnyttjandet m.m. Varje år planerar teamen nya projekt, utvecklar sina system och det är viktigt för oss att förse dem med resurser.
Och med hjälp av mätvärden ser vi trenden i resursförbrukningen av våra informationssystem. Och utifrån dem kan vi planera något. På virtualiseringsnivå samlar vi in data och ser information om den tillgängliga mängden resurser per datacenter. Och redan inne i datacentret kan du se återvinningen, den faktiska distributionen och förbrukningen av resurser. Dessutom, både med fristående servrar och virtuella maskiner och kluster av fysiska servrar på vilka alla dessa virtuella maskiner snurrar kraftigt.
Utsikter
Nu har vi kärnan i systemet som helhet klar, men det är fortfarande en hel del saker som fortfarande måste jobbas på. Detta är åtminstone ett informationssäkerhetslager, men det är också viktigt att nå nätverket, utveckla larm och lösa frågan om korrelation. Vi har många lager och system, och på varje lager finns det många fler mått. Det visar sig vara en matryoshka till graden av en matryoshka.
Vår uppgift är att i slutändan göra de rätta varningarna. Till exempel, om det fanns ett problem med hårdvaran, igen, med en virtuell maskin, och det fanns en viktig applikation, och tjänsten säkerhetskopierades inte på något sätt. Vi får reda på att den virtuella maskinen har dött. Då kommer affärsmått varna dig: användare har försvunnit någonstans, det finns ingen konvertering, gränssnittet i gränssnittet är inte tillgängligt, programvara och tjänster har också dött.
I den här situationen kommer vi att ta emot skräppost från varningar, och detta passar inte längre in i formatet för ett korrekt övervakningssystem. Frågan om korrelation uppstår. Därför borde vårt övervakningssystem helst säga: "Gubbar, din fysiska maskin har dött, och tillsammans med den den här applikationen och dessa mätvärden," med hjälp av en varning, istället för att rasande bombardera oss med hundra varningar. Det bör rapportera det viktigaste - orsaken, vilket hjälper till att snabbt eliminera problemet på grund av dess lokalisering.
Vårt aviseringssystem och varningshantering är uppbyggd kring en XNUMX-timmars hotline-tjänst. Alla varningar som anses vara ett måste och som finns med i checklistan skickas dit. Varje varning måste ha en beskrivning: vad som hände, vad det faktiskt betyder, vad det påverkar. Och även en länk till instrumentpanelen och instruktioner om vad man ska göra i det här fallet.
Allt handlar om kraven för att skapa en varning. Då kan situationen utvecklas åt två håll – antingen finns det ett problem och måste lösas, eller så har det blivit fel i övervakningssystemet. Men i alla fall måste du gå och lista ut det.
I genomsnitt får vi nu ett hundratal varningar per dag, med hänsyn till att korrelationen av varningar ännu inte har konfigurerats korrekt. Och om vi behöver utföra tekniskt arbete, och vi tvångsstänger av något, ökar deras antal avsevärt.
Förutom att övervaka de system som vi driver och samla in mätvärden som anses viktiga på vår sida, tillåter övervakningssystemet oss att samla in data för produktteam. De kan påverka sammansättningen av mått inom de informationssystem som vi övervakar.
Vår kollega kan komma och be om att få lägga till någon statistik som kommer att vara användbar för både oss och teamet. Eller till exempel kanske teamet inte har tillräckligt med de grundläggande mätvärdena som vi har, de måste spåra några specifika. I Grafana skapar vi ett utrymme för varje lag och ger administratörsrättigheter. Dessutom, om ett team behöver instrumentpaneler, men de själva inte kan/vet inte hur man gör det, hjälper vi dem.
Eftersom vi är utanför flödet av teamets värdeskapande, deras releaser och planering, kommer vi gradvis till slutsatsen att releaser av alla system är sömlösa och kan rullas ut dagligen utan samordning med oss. Och det är viktigt för oss att övervaka dessa utgåvor, eftersom de potentiellt kan påverka applikationens funktion och bryta något, och detta är avgörande. För att hantera releaser använder vi Bamboo, varifrån vi tar emot data via API och kan se vilka releaser som har släppts i vilka informationssystem och deras status. Och det viktigaste är vid vilken tidpunkt. Vi överlagrar utgivningsmarkörer på de viktigaste kritiska måtten, vilket är visuellt mycket vägledande vid problem.
På så sätt kan vi se sambandet mellan nya releaser och nya problem. Huvudtanken är att förstå hur systemet fungerar i alla lager, snabbt lokalisera problemet och åtgärda det lika snabbt. När allt kommer omkring händer det ofta att det som tar mest tid inte är att lösa problemet, utan att söka efter orsaken.
Och inom detta område vill vi i framtiden fokusera på proaktivitet. Helst skulle jag vilja veta om ett annalkande problem i förväg, och inte i efterhand, så att jag kan förhindra det snarare än att lösa det. Ibland uppstår falska larm av övervakningssystemet, både på grund av mänskliga fel och på grund av ändringar i applikationen. Och vi arbetar med detta, felsöker det och försöker varna användare som använder det med oss om detta innan någon manipulation av övervakningssystemet , eller utför dessa aktiviteter i det tekniska fönstret.
Så systemet har lanserats och har fungerat framgångsrikt sedan början av våren... och visar mycket verkliga vinster. Naturligtvis är detta inte den slutliga versionen, vi kommer att introducera många fler användbara funktioner. Men just nu, med så många integrationer och applikationer, är övervakningsautomatisering verkligen oundviklig.
Om du dessutom övervakar stora projekt med ett betydande antal integrationer, skriv i kommentarerna vilken silverkula du hittade för detta.
Källa: will.com