Nimeni on Anton Baderin. Työskentelen High Technology Centerissä ja teen järjestelmähallintoa. Kuukausi sitten päättyi yrityskonferenssimme, jossa jaoimme kertyneet kokemuksemme kaupunkimme IT-yhteisön kanssa. Puhuin verkkosovellusten valvonnasta. Materiaali oli tarkoitettu juniori- tai keskitasolle, jotka eivät rakentaneet tätä prosessia tyhjästä.
Kaikkien valvontajärjestelmien kulmakivi on liiketoiminnan ongelmien ratkaiseminen. Valvonta seurannan vuoksi ei kiinnosta ketään. Mitä yritys haluaa? Joten kaikki toimii nopeasti ja ilman virheitä. Yritykset haluavat olla ennakoivia, jotta tunnistamme itse palvelussa olevat ongelmat ja korjaamme ne mahdollisimman nopeasti. Itse asiassa nämä ovat ongelmia, jotka ratkaisin koko viime vuoden yhden asiakkaamme projektissa.
О проекте
Hanke on yksi maan suurimmista kanta-asiakasohjelmista. Autamme kauppaketjuja lisäämään myyntitiheyttä erilaisilla markkinointityökaluilla, kuten bonuskorteilla. Kaikkiaan projekti sisältää 14 sovellusta, jotka toimivat kymmenellä palvelimella.
Haastatteluprosessin aikana huomasin toistuvasti, että ylläpitäjät eivät aina lähesty verkkosovellusten valvontaa oikein: monet keskittyvät edelleen käyttöjärjestelmän mittareihin ja valvovat silloin tällöin palveluita.
Minun tapauksessani asiakkaan valvontajärjestelmä perustui aiemmin Icingaan. Se ei ratkaissut yllä olevia ongelmia millään tavalla. Usein asiakas itse ilmoitti meille ongelmista, ja useimmiten meillä ei yksinkertaisesti ollut tarpeeksi tietoa syiden selvittämiseksi.
Lisäksi oli selkeä käsitys sen jatkokehityksen hyödyttömyydestä. Luulen, että Icinan tuntevat ymmärtävät minua. Joten päätimme suunnitella projektin verkkosovellusten seurantajärjestelmän kokonaan uudelleen.
Prometheus
Valitsimme Prometheuksen kolmen pääindikaattorin perusteella:
- Valtava määrä käytettävissä olevia mittareita. Meidän tapauksessamme niitä on 60 tuhatta. Tietenkin on syytä huomata, että emme käytä suurinta osaa niistä (luultavasti noin 95 %). Toisaalta ne ovat kaikki suhteellisen halpoja. Meille tämä on toinen ääripää verrattuna aiemmin käytettyyn Icingaan. Siinä mittareiden lisääminen oli erityisen tuskaa: nykyiset olivat kalliita (katso vain minkä tahansa laajennuksen lähdekoodia). Mikä tahansa laajennus oli Bashissa tai Pythonissa oleva komentosarja, jonka käynnistäminen on kulutettujen resurssien kannalta kallista.
- Tämä järjestelmä kuluttaa suhteellisen vähän resursseja. 600 Mt RAM-muistia, 15 % yhdestä ytimestä ja pari tusinaa IOPS:a riittää kaikkiin mittareihimme. Tietenkin sinun on käytettävä mittareiden viejiä, mutta ne kaikki on kirjoitettu Go-kielellä eivätkä myöskään ole kovin nälkäisiä. En usko, että nykytodellisuudessa tämä on ongelma.
- Tarjoaa mahdollisuuden siirtyä Kubernetesiin. Asiakkaan suunnitelmat huomioon ottaen valinta on ilmeinen.
HIRVI
Aiemmin emme keränneet tai käsitelleet lokeja. Puutteet ovat selvät kaikille. Valitsimme ELK:n, koska meillä oli jo kokemusta tästä järjestelmästä. Tallennamme sinne vain sovelluslokit. Tärkeimmät valintakriteerit olivat kokotekstihaku ja sen nopeus.
Сlickhouse
Aluksi valinta osui InfluxDB:hen. Ymmärsimme tarpeen kerätä Nginx-lokeja, tilastoja pg_stat_statementsista ja tallentaa Prometheus-historiatietoja. Emme pitäneet Influxista, koska se alkoi ajoittain kuluttaa paljon muistia ja kaatui. Lisäksi halusin ryhmitellä kyselyt remote_addr:n mukaan, mutta ryhmittely tässä DBMS:ssä tapahtuu vain tunnisteiden mukaan. Tunnisteet ovat kalliita (muisti), niiden määrä on ehdollisesti rajoitettu.
Aloitimme etsinnän uudelleen. Tarvittiin analyyttinen tietokanta, joka kuluttaa mahdollisimman vähän resursseja, mieluiten tietojen pakkaus levyllä.
Clickhouse täyttää kaikki nämä kriteerit, emmekä ole koskaan katuneet valintaamme. Emme kirjoita siihen mitään poikkeuksellisia tietomääriä (lisäysten määrä on vain noin viisi tuhatta minuutissa).
UusiRelic
NewRelic on historiallisesti ollut kanssamme, koska se oli asiakkaan valinta. Käytämme sitä APM:nä.
Zabbix
Käytämme Zabbixia yksinomaan erilaisten sovellusliittymien Black Boxin valvontaan.
Valvontalähestymistavan määrittely
Halusimme hajottaa tehtävän ja siten systematisoida lähestymistavan seurantaan.
Tätä varten jaoin järjestelmämme seuraaviin tasoihin:
- laitteisto ja VMS;
- käyttöjärjestelmä;
- järjestelmäpalvelut; ohjelmisto pino;
- sovellus;
- bisneslogiikkaa.
Miksi tämä lähestymistapa on kätevä:
- tiedämme kuka on vastuussa kunkin tason työstä ja tämän perusteella voimme lähettää hälytyksiä;
- voimme käyttää rakennetta hälytyksiä vaimentaessa - olisi outoa lähettää hälytys tietokannan epäkäytettävyydestä, kun virtuaalikone kokonaisuudessaan ei ole käytettävissä.
Koska tehtävämme on tunnistaa rikkomukset järjestelmän toiminnassa, meidän on kullakin tasolla nostettava esiin tietty joukko mittareita, joihin kannattaa kiinnittää huomiota hälytyssääntöjä kirjoitettaessa. Seuraavaksi käydään läpi tasot "VMS", "Käyttöjärjestelmä" ja "Järjestelmäpalvelut, ohjelmistopino".
Virtuaalikoneet
Hosting varaa meille prosessorin, levyn, muistin ja verkon. Ja meillä oli ongelmia kahden ensimmäisen kanssa. Eli mittarit:
CPU varastettu aika - kun ostat virtuaalikoneen Amazonista (esimerkiksi t2.micro), sinun tulee ymmärtää, että sinulle ei ole varattu koko prosessoriydintä, vaan vain kiintiö sen ajasta. Ja kun käytät sen loppuun, prosessori otetaan sinulta pois.
Tämän mittarin avulla voit seurata tällaisia hetkiä ja tehdä päätöksiä. Onko esimerkiksi tarpeen ottaa paksumpi tariffi tai jakaa taustatehtävien ja API-pyyntöjen käsittely eri palvelimille?
IOPS + CPU:n odotusaika – jostain syystä monet pilvipalvelimet tekevät syntiä, koska ne eivät tarjoa tarpeeksi IOPS:ia. Lisäksi aikataulu, jossa IOPS on alhainen, ei ole peruste heille. Siksi kannattaa kerätä CPU iowait. Tällä kaavioparilla - matalalla IOPS:llä ja korkealla I/O-odotuksella - voit jo keskustella isännöinnin kanssa ja ratkaista ongelman.
Käyttöjärjestelmä
Käyttöjärjestelmän mittarit:
- käytettävissä olevan muistin määrä %;
- swap-käyttötoiminta: vmstat swapin, swapout;
- käytettävissä olevien inodien määrä ja vapaa tila tiedostojärjestelmässä %
- keskimääräinen kuormitus;
- yhteyksien määrä tw-tilassa;
- conntrack taulukon täyteys;
- Verkon laatua voidaan seurata ss-apuohjelmalla, iproute2-paketilla - saa sen lähdöstä indikaattorin RTT-yhteyksistä ja ryhmittele se kohdeportin mukaan.
Myös käyttöjärjestelmätasolla meillä on tällainen kokonaisuus prosesseina. On tärkeää tunnistaa järjestelmästä joukko prosesseja, joilla on tärkeä rooli sen toiminnassa. Jos sinulla on esimerkiksi useita pgpooleja, sinun on kerättävä tiedot jokaisesta niistä.
Mittarisarja on seuraava:
- PROSESSORI;
- muisti on ensisijaisesti pysyvä;
- IO - mieluiten IOPS:ssä;
- FileFd - avoin ja raja;
- merkittäviä sivuvirheitä - näin voit ymmärtää, mitä prosessia vaihdetaan.
Otamme kaiken seurannan käyttöön Dockerissa ja käytämme Advisoria kerätäksemme mittatietoja. Muissa koneissa käytämme prosessivientiä.
Järjestelmäpalvelut, ohjelmistopino
Jokaisella sovelluksella on omat erityispiirteensä, ja on vaikeaa erottaa tiettyjä mittareita.
Universaali sarja on:
- pyyntö korko;
- virheiden määrä;
- viive;
- kylläisyys.
Silmiinpistävimmät esimerkimme valvonnasta tällä tasolla ovat Nginx ja PostgreSQL.
Järjestelmämme ladatuin palvelu on tietokanta. Aiemmin meillä oli usein vaikeuksia selvittää, mitä tietokanta teki.
Näimme suuren kuormituksen levyillä, mutta hitaat lokit eivät oikeastaan näyttäneet mitään. Ratkaisimme tämän ongelman käyttämällä pg_stat_statements, näkymää, joka kerää kyselytilastoja.
Siinä kaikki, mitä järjestelmänvalvoja tarvitsee.
Rakennamme kaavioita luku- ja kirjoituspyyntöjen toiminnasta:
Kaikki on yksinkertaista ja selkeää, jokaisella pyynnöllä on oma värinsä.
Yhtä silmiinpistävä esimerkki ovat Nginx-lokit. Ei ole yllättävää, että harvat ihmiset jäsentävät niitä tai mainitsevat ne must-have-luettelossa. Vakiomuoto ei ole kovin informatiivinen ja sitä on laajennettava.
Henkilökohtaisesti lisäsin request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Piirrämme vastausajan ja virheiden määrän:
Rakennamme kaavioita vasteajasta ja virheiden määrästä. Muistaa? Puhuinko liiketoiminnan tavoitteista? Nopeasti ja ilman virheitä? Olemme jo käsitelleet näitä asioita kahdella kaaviolla. Ja niitä käyttämällä voi jo soittaa päivystävälle järjestelmänvalvojalle.
Mutta vielä yksi ongelma on jäljellä - varmistaa tapahtuman syiden nopea poistaminen.
Tapahtuman ratkaisu
Koko prosessi tunnistamisesta ongelman ratkaisemiseen voidaan jakaa useisiin vaiheisiin:
- tunnistaa ongelma;
- ilmoitus päivystäjälle;
- vastaus tapahtumaan;
- syiden poistaminen.
On tärkeää, että meidän on tehtävä tämä mahdollisimman nopeasti. Ja jos ongelman tunnistamisen ja ilmoituksen lähettämisen vaiheissa emme voi saada paljon aikaa - niihin kuluu joka tapauksessa kaksi minuuttia, niin seuraavat ovat yksinkertaisesti kyntämätön pelto parannuksia varten.
Kuvitellaanpa, että päivystäjän puhelin soi. Mitä hän aikoo tehdä? Etsi vastauksia kysymyksiin - mikä meni rikki, missä se meni rikki, miten reagoida? Näin vastaamme näihin kysymyksiin:
Sisällytämme yksinkertaisesti kaikki nämä tiedot ilmoituksen tekstiin, annamme sille linkin wikisivulle, joka kuvaa, kuinka tähän ongelmaan voidaan vastata, kuinka se ratkaistaan ja eskaloidaan.
En ole vieläkään sanonut mitään sovellustasosta ja liiketoimintalogiikasta. Valitettavasti sovelluksemme eivät vielä ota käyttöön mittareiden keräämistä. Ainoa tietolähde näiltä tasoilta on lokit.
Pari pistettä.
Kirjoita ensin jäsennellyt lokit. Viestin tekstiin ei tarvitse sisällyttää kontekstia. Tämä tekee niistä vaikeaksi ryhmitellä ja analysoida. Logstashilla kestää kauan normalisoida tämä kaikki.
Toiseksi, käytä vakavuustasoja oikein. Jokaisella kielellä on oma standardinsa. Henkilökohtaisesti erotan neljä tasoa:
- ei virhettä;
- asiakaspuolen virhe;
- virhe on meidän puolellamme, emme menetä rahaa, emme ota riskejä;
- Virhe on meidän puolellamme, menetämme rahaa.
Anna minun tehdä yhteenveto. Sinun on yritettävä rakentaa seurantaa liiketoimintalogiikassa. Yritä seurata itse sovellusta ja käyttää sellaisia mittareita kuin myyntien määrä, uusien käyttäjien rekisteröitymiset, tällä hetkellä aktiivisten käyttäjien määrä ja niin edelleen.
Jos koko yrityksesi on yksi painike selaimessa, sinun on seurattava, napsahtaako se ja toimiiko se oikein. Kaikella muulla ei ole väliä.
Jos sinulla ei ole tätä, voit yrittää löytää sen sovelluksen lokeissa, Nginx-lokeissa ja niin edelleen, kuten teimme. Sinun tulee olla mahdollisimman lähellä sovellusta.
Käyttöjärjestelmän mittarit ovat tietysti tärkeitä, mutta ne eivät kiinnosta liike-elämää, meille ei makseta niistä.
Lähde: will.com