Jag heter Anton Baderin. Jag jobbar på Högteknikcentrum och sysslar med systemadministration. För en månad sedan avslutades vår företagskonferens, där vi delade med oss av vår samlade erfarenhet med IT-gemenskapen i vår stad. Jag pratade om att övervaka webbapplikationer. Materialet var avsett för junior- eller mellannivå, som inte byggde upp denna process från grunden.
Hörnstenen bakom varje övervakningssystem är att lösa affärsproblem. Övervakning för övervakningens skull är inte av intresse för någon. Vad vill näringslivet? Så att allt fungerar snabbt och felfritt. Företag vill vara proaktiva, så att vi själva identifierar problem i tjänsten och åtgärdar dem så snabbt som möjligt. Det här är faktiskt de problem som jag löste hela förra året i ett projekt för en av våra kunder.
О проекте
Projektet är ett av de största lojalitetsprogrammen i landet. Vi hjälper butikskedjor att öka försäljningsfrekvensen genom olika marknadsföringsverktyg som bonuskort. Totalt omfattar projektet 14 applikationer som körs på tio servrar.
Under intervjuprocessen märkte jag upprepade gånger att administratörer inte alltid närmar sig övervakning av webbapplikationer korrekt: många fokuserar fortfarande på operativsystemsmått och övervakar ibland tjänster.
I mitt fall var kundens övervakningssystem tidigare baserat på Icinga. Det löste inte ovanstående problem på något sätt. Ofta har klienten själv informerat oss om problem, och oftare än inte hade vi helt enkelt inte tillräckligt med data för att gå till botten med orsaken.
Dessutom fanns det en klar förståelse för det meningslösa i dess vidareutveckling. Jag tror att de som är bekanta med Icinga kommer att förstå mig. Så vi bestämde oss för att helt omforma övervakningssystemet för webbapplikationer för projektet.
Prometheus
Vi valde Prometheus baserat på tre huvudindikatorer:
- Ett stort antal tillgängliga mätvärden. I vårt fall finns det 60 tusen av dem. Naturligtvis är det värt att notera att vi inte använder de allra flesta av dem (förmodligen cirka 95%). Å andra sidan är de alla relativt billiga. För oss är detta den andra ytterligheten jämfört med den tidigare använda Icinga. I den var det svårt att lägga till mätvärden: de befintliga var dyra (se bara på källkoden för alla plugin-program). Varje plugin var ett skript i Bash eller Python, vars lansering är dyrt i termer av förbrukade resurser.
- Detta system förbrukar en relativt liten mängd resurser. 600 MB RAM, 15 % av en kärna och ett par dussin IOPS räcker för alla våra mätvärden. Naturligtvis måste du köra statistikexportörer, men de är alla skrivna i Go och är inte heller särskilt strömsugna. Jag tror inte att detta är ett problem i moderna verkligheter.
- Ger möjlighet att migrera till Kubernetes. Med tanke på kundens planer är valet självklart.
ÄLG
Tidigare har vi inte samlat in eller bearbetat loggar. Bristerna är tydliga för alla. Vi valde ELK eftersom vi redan hade erfarenhet av detta system. Vi lagrar bara applikationsloggar där. De huvudsakliga urvalskriterierna var fulltextsökning och dess hastighet.
Slickhouse
Inledningsvis föll valet på InfluxDB. Vi insåg behovet av att samla in Nginx-loggar, statistik från pg_stat_statements och lagra Prometheus historiska data. Vi gillade inte Influx eftersom det periodvis började förbruka en stor mängd minne och kraschade. Dessutom ville jag gruppera frågor efter remote_addr, men gruppering i detta DBMS sker bara efter taggar. Taggar är dyra (minne), deras antal är villkorligt begränsat.
Vi började leta igen. Det som behövdes var en analytisk databas med minimal resursåtgång, gärna med datakomprimering på disk.
Clickhouse uppfyller alla dessa kriterier, och vi har aldrig ångrat vårt val. Vi skriver inte in några extraordinära mängder data i den (antalet infogningar är bara cirka fem tusen per minut).
NewRelic
NewRelic har historiskt sett varit med oss eftersom det var kundens val. Vi använder det som en APM.
Zabbix
Vi använder Zabbix exklusivt för att övervaka Black Box för olika API:er.
Definiera en övervakningsmetod
Vi ville bryta ner uppgiften och därigenom systematisera tillvägagångssättet för övervakning.
För att göra detta delade jag upp vårt system i följande nivåer:
- hårdvara och VMS;
- operativ system;
- systemtjänster, programvara stack;
- Ansökan;
- företagslogik.
Varför detta tillvägagångssätt är bekvämt:
- vi vet vem som är ansvarig för arbetet på varje nivå och baserat på detta kan vi skicka varningar;
- vi kan använda strukturen när vi undertrycker varningar - det skulle vara konstigt att skicka en varning om databasens otillgänglighet när den virtuella maskinen som helhet inte är tillgänglig.
Eftersom vår uppgift är att identifiera överträdelser i driften av systemet måste vi på varje nivå lyfta fram en viss uppsättning mätvärden som är värda att uppmärksamma när man skriver varningsregler. Låt oss sedan gå igenom nivåerna "VMS", "Operativsystem" och "Systemtjänster, mjukvarustack".
Virtuella maskiner
Hosting tilldelar oss en processor, disk, minne och nätverk. Och vi hade problem med de två första. Så, måtten:
CPU stulen tid - när du köper en virtuell maskin på Amazon (t2.micro, till exempel), bör du förstå att du inte tilldelas en hel processorkärna, utan bara en kvot av dess tid. Och när du har tömt den kommer processorn att tas ifrån dig.
Detta mått låter dig spåra sådana ögonblick och fatta beslut. Är det till exempel nödvändigt att ta en fetare tariff eller distribuera behandlingen av bakgrundsuppgifter och API-förfrågningar till olika servrar?
IOPS + CPU iväntningstid - av någon anledning syndar många molnvärdar genom att inte tillhandahålla tillräckligt med IOPS. Dessutom är ett schema med låg IOPS inget argument för dem. Därför är det värt att samla CPU iowait. Med detta par av grafer - med låg IOPS och hög I/O-väntetid - kan du redan prata med hostingen och lösa problemet.
Operativsystem
Operativsystemstatistik:
- mängd tillgängligt minne i %;
- swap användningsaktivitet: vmstat swapin, swapout;
- antal tillgängliga inoder och ledigt utrymme på filsystemet i %
- genomsnittlig belastning;
- antal anslutningar i två tillstånd;
- conntrack tabell fullhet;
- Nätverkets kvalitet kan övervakas med hjälp av ss-verktyget, iproute2-paketet - få en indikator på RTT-anslutningar från dess utgång och gruppera den efter målport.
Även på operativsystemnivå har vi en sådan enhet som processer. Det är viktigt att i systemet identifiera en uppsättning processer som spelar en viktig roll i dess drift. Om du till exempel har flera pgpooler måste du samla in information för var och en av dem.
Uppsättningen mätvärden är som följer:
- CPU:er;
- minnet är primärt inhemskt;
- IO - helst i IOPS;
- FileFd - öppna och begränsa;
- betydande sidfel - på så sätt kan du förstå vilken process som byts ut.
Vi distribuerar all övervakning i Docker, och vi använder Advisor för att samla in mätdata. På andra maskiner använder vi process-exporter.
Systemtjänster, mjukvarustack
Varje applikation har sina egna detaljer och det är svårt att peka ut en specifik uppsättning mätvärden.
Det universella setet är:
- begäran rate;
- antal misstag;
- latens;
- mättnad.
Våra mest slående exempel på övervakning på denna nivå är Nginx och PostgreSQL.
Den mest laddade tjänsten i vårt system är databasen. Tidigare hade vi ofta problem med att lista ut vad databasen gjorde.
Vi såg en hög belastning på diskarna, men de långsamma loggarna visade egentligen ingenting. Vi löste det här problemet med pg_stat_statements, en vy som samlar in frågestatistik.
Det är allt som administratören behöver.
Vi bygger grafer över aktiviteten för läs- och skrivförfrågningar:
Allt är enkelt och tydligt, varje förfrågan har sin egen färg.
Ett lika slående exempel är Nginx-loggar. Det är inte förvånande att få människor analyserar dem eller nämner dem i listan över måste-has. Standardformatet är inte särskilt informativt och behöver utökas.
Personligen lade jag till request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Vi plottar svarstid och antal fel:
Vi bygger grafer över svarstid och antal fel. Kom ihåg? Pratade jag om affärsmål? För att snabbt och utan fel? Vi har redan täckt dessa problem med två diagram. Och du kan redan nu ringa till tjänstgörande administratörer med hjälp av dem.
Men ytterligare ett problem kvarstår - att säkerställa en snabb eliminering av orsakerna till incidenten.
Incidentupplösning
Hela processen från att identifiera till att lösa ett problem kan delas in i ett antal steg:
- identifiera problemet;
- underrättelse till tjänstgöringsadministratören;
- svar på en incident;
- eliminering av orsaker.
Det är viktigt att vi måste göra detta så snabbt som möjligt. Och om vi inte kan vinna mycket tid i stadierna av att identifiera ett problem och skicka ett meddelande - två minuter kommer att spenderas på dem i alla fall, då är de efterföljande helt enkelt upplogade fält för förbättringar.
Låt oss bara tänka oss att vakthavarens telefon ringde. Vad ska han göra? Leta efter svar på frågor - vad gick sönder, var gick det sönder, hur skulle man reagera? Så här svarar vi på dessa frågor:
Vi inkluderar helt enkelt all denna information i meddelandets text, ger den en länk till en wikisida som beskriver hur man svarar på detta problem, hur man löser det och eskalerar det.
Jag har fortfarande inte sagt något om applikationslagret och affärslogiken. Tyvärr implementerar våra applikationer ännu inte insamling av mätvärden. Den enda källan till all information från dessa nivåer är loggar.
Ett par punkter.
Skriv först strukturerade loggar. Det finns inget behov av att inkludera sammanhang i meddelandets text. Detta gör dem svåra att gruppera och analysera. Logstash tar lång tid att normalisera allt detta.
För det andra, använd svårighetsgraden korrekt. Varje språk har sin egen standard. Personligen skiljer jag fyra nivåer:
- inget fel;
- fel på klientsidan;
- misstaget är på vår sida, vi förlorar inte pengar, vi bär inga risker;
- Misstaget är på vår sida, vi förlorar pengar.
Låt mig sammanfatta. Du måste försöka bygga övervakning baserad på affärslogik. Försök att övervaka själva applikationen och arbeta med sådana mätvärden som antalet försäljningar, antalet nya användarregistreringar, antalet för närvarande aktiva användare och så vidare.
Om hela din verksamhet är en knapp i webbläsaren måste du övervaka om den klickar och fungerar som den ska. Allt annat spelar ingen roll.
Om du inte har detta kan du försöka komma ikapp med det i applikationsloggar, Nginx-loggar och så vidare, som vi gjorde. Du bör vara så nära ansökan som möjligt.
Operativsystemsmått är naturligtvis viktiga, men företagen är inte intresserade av dem, vi får inte betalt för dem.
Källa: will.com