🥇 Onko valvonta kuollut? — Eläköön seuranta

Yrityksemme on vuodesta 2008 lähtien harjoittanut ensisijaisesti infrastruktuurin hallintaa ja ympärivuorokautista verkkoprojektien teknistä tukea: meillä on yli 400 asiakasta, mikä on noin 15 % Venäjän verkkokaupasta. Näin ollen tuetaan hyvin monipuolista arkkitehtuuria. Jos jotain putoaa, olemme velvollisia korjaamaan sen 15 minuutin kuluessa. Mutta ymmärtääksesi, että onnettomuus on tapahtunut, sinun on seurattava projektia ja reagoitava tapahtumiin. Miten tämä tehdään?

Uskon, että oikean seurantajärjestelmän järjestämisessä on ongelma. Jos ongelmia ei olisi ollut, puheeni koostuisi yhdestä opinnäytetyöstä: "Asenna Prometheus + Grafana ja lisäosat 1, 2, 3." Valitettavasti se ei enää toimi niin. Ja suurin ongelma on, että kaikki uskovat edelleen johonkin, mikä oli olemassa vuonna 2008, ohjelmistokomponenttien osalta.

Mitä tulee seurantajärjestelmän organisointiin, uskallan sanoa, että... hankkeita, joissa olisi asiantuntevaa valvontaa, ei ole olemassa. Ja tilanne on niin huono, että jos jotain putoaa, on vaara, että se jää huomaamatta - kaikkihan ovat varmoja, että "kaikkia valvotaan".
Ehkä kaikkea valvotaan. Mutta miten?

Olemme kaikki kohdanneet seuraavanlaisen tarinan: tietty devops, tietty järjestelmänvalvoja työskentelee, kehitystiimi tulee heidän luokseen ja sanoo - "olemme vapautettu, nyt valvo." Valvoa mitä? Kuinka se toimii?

OK. Valvomme vanhanaikaisesti. Ja se on jo muuttumassa, ja kävi ilmi, että valvoit palvelua A, josta tuli palvelu B, joka on vuorovaikutuksessa palvelun C kanssa. Mutta kehitystiimi sanoo: "Asenna ohjelmisto, sen pitäisi valvoa kaikkea!"

Joten mikä on muuttunut? - Kaikki on muuttunut!

2008 Kaikki on hyvin

Siellä on pari kehittäjää, yksi palvelin, yksi tietokantapalvelin. Kaikki lähtee täältä. Meillä on tietoa, asennamme zabbix, Nagios, kaktukset. Ja sitten asetimme selkeät hälytykset suorittimelle, levyn toiminnille ja levytilalle. Teemme myös pari manuaalista tarkistusta varmistaaksemme, että sivusto vastaa ja että tilaukset saapuvat tietokantaan. Ja siinä kaikki – olemme enemmän tai vähemmän suojattuja.

Jos verrataan järjestelmänvalvojan tuolloin tekemän valvonnan työn määrää, 98% siitä oli automaattista: valvojan on ymmärrettävä kuinka Zabbix asennetaan, miten se konfiguroidaan ja hälytykset asetetaan. Ja 2% - ulkoisista tarkastuksista: että sivusto vastaa ja tekee pyynnön tietokantaan, että uusia tilauksia on saapunut.

2010 Kuorma kasvaa

Aloitamme verkon skaalaamisen ja lisäämme hakukoneen. Haluamme varmistaa, että tuoteluettelo sisältää kaikki tuotteet. Ja tuotehaku toimii. Että tietokanta toimii, että tilauksia tehdään, että sivusto vastaa ulkoisesti ja vastaa kahdelta palvelimelta ja käyttäjää ei potkita pois sivustolta, kun se tasapainotetaan toiselle palvelimelle jne. Kokonaisuuksia on enemmän.

Lisäksi infrastruktuuriin liittyvä kokonaisuus on edelleen suurin johtajan päässä. Päässäni pyörii edelleen ajatus, että valvoja on se, joka asentaa zabbixin ja pystyy konfiguroimaan sen.

Mutta samaan aikaan työskennellään ulkoisten tarkastusten tekemisessä, joukon hakuindeksin kyselykomentosarjan luomisessa, sarjan komentosarjoja sen tarkistamiseksi, että haku muuttuu indeksointiprosessin aikana, sarjan komentosarjoja, jotka tarkistavat, että tavarat siirretään toimituspalvelu jne. ja niin edelleen.

Huomautus: Kirjoitin "sarjan skriptejä" 3 kertaa. Toisin sanoen valvonnasta vastaava henkilö ei ole enää se, joka vain asentaa zabbixin. Tämä on henkilö, joka alkaa koodata. Mutta mikään ei ole vielä muuttunut joukkueen mielissä.

Mutta maailma muuttuu, muuttuu yhä monimutkaisemmaksi. Lisätään virtualisointikerros ja useita uusia järjestelmiä. He alkavat olla vuorovaikutuksessa keskenään. Kuka sanoi "haisee mikropalveluille?" Mutta jokainen palvelu näyttää silti verkkosivustolta erikseen. Voimme kääntyä sen puoleen ja ymmärtää, että se tarjoaa tarvittavat tiedot ja toimii itsestään. Ja jos olet järjestelmänvalvoja jatkuvasti mukana projektissa, joka on kehittynyt 5-7-10 vuotta, tämä tieto kertyy: uusi taso ilmestyy - tajusit sen, toinen taso ilmestyy - tajusit sen...

Mutta harvoin kukaan seuraa projektia 10 vuotta.

Tarkkailijan ansioluettelo

Oletetaan, että tulit uuteen startupiin, joka palkkasi heti 20 kehittäjää, kirjoitti 15 mikropalvelua ja olet järjestelmänvalvoja, jolle sanotaan: "Build CI/CD. Ole kiltti." Olet rakentanut CI/CD:n ja yhtäkkiä kuulet: ”Meidän on vaikeaa työskennellä tuotannon kanssa ”kuutiossa”, ymmärtämättä kuinka sovellus toimii siinä. Tee meille hiekkalaatikko samaan "kuutioon".
Teet hiekkalaatikon tähän kuutioon. He kertovat heti: "Haluamme vaihetietokannan, joka päivitetään päivittäin tuotannosta, jotta ymmärrämme sen toimivan tietokannassa, mutta samalla emme pilaa tuotantotietokantaa."

Elät kaikessa tässä. 2 viikkoa jäljellä ennen julkaisua, he sanovat: "Nyt seurataan tätä kaikkea..." Eli. tarkkaile klusterin infrastruktuuria, seuraa mikropalveluarkkitehtuuria, seuraa työtä ulkoisten palveluiden kanssa...

Ja kollegani poistavat tavanomaisen suunnitelman päässään ja sanovat: "No, täällä kaikki on selvää! Asenna ohjelma, joka valvoo kaikkea tätä." Kyllä, kyllä: Prometheus + Grafana + lisäosat.
Ja he lisäävät: "Sinulla on kaksi viikkoa aikaa, varmista, että kaikki on turvassa."

Monissa näkemissämme projekteissa yksi henkilö on varattu seurantaan. Kuvittele, että haluamme palkata henkilön suorittamaan valvontaa 2 viikoksi ja kirjoitamme hänelle ansioluettelon. Mitä taitoja tällä henkilöllä pitäisi olla, kun otetaan huomioon kaikki, mitä olemme tähän mennessä sanoneet?

Hänen tulee ymmärtää rautainfrastruktuurin valvonta ja toiminnan erityispiirteet.
Hänen on ymmärrettävä Kubernetesin seurannan erityispiirteet (ja kaikki haluavat mennä "kuutioon", koska voit vetäytyä kaikesta, piiloutua, koska järjestelmänvalvoja hoitaa loput) - itse, sen infrastruktuuri ja ymmärtää kuinka seurata sovelluksia sisällä.
Hänen on ymmärrettävä, että palvelut kommunikoivat toistensa kanssa erityisillä tavoilla, ja tunnettava palvelujen vuorovaikutuksen erityispiirteet. On täysin mahdollista nähdä projekti, jossa jotkut palvelut kommunikoivat synkronisesti, koska muuta tapaa ei ole. Esimerkiksi taustaohjelma menee RESTin kautta gRPC:n kautta luettelopalveluun, vastaanottaa tuoteluettelon ja palauttaa sen takaisin. Et voi odottaa täällä. Ja muiden palveluiden kanssa se toimii asynkronisesti. Siirrä tilaus kuljetuspalveluun, lähetä kirje jne.
Olet varmaan jo uinut tästä kaikesta? Ja järjestelmänvalvoja, jonka täytyy valvoa tätä, hämmentyi entisestään.
Hänen on osattava suunnitella ja suunnitella oikein - sitä mukaa kun työtä tulee yhä enemmän.
Siksi hänen on luotava luodusta palvelusta strategia, jotta hän ymmärtää, kuinka sitä voidaan tarkkailla. Hän tarvitsee ymmärrystä projektin arkkitehtuurista ja sen kehityksestä + ymmärrystä kehityksessä käytetyistä teknologioista.

Muistakaamme täysin normaali tapaus: osa palveluista on PHP:ssä, osa Go:ssa, osa palveluista JS:ssä. Ne jotenkin toimivat keskenään. Tästä tulee termi "mikropalvelu": yksittäisiä järjestelmiä on niin paljon, että kehittäjät eivät voi ymmärtää hanketta kokonaisuutena. Yksi osa tiimistä kirjoittaa JS:llä palveluita, jotka toimivat itsestään eivätkä tiedä kuinka muu järjestelmä toimii. Toinen osa kirjoittaa palveluita Pythonissa eikä häiritse muiden palveluiden toimintaa, vaan ne ovat eristyksissä omalla alueellaan. Kolmas on palveluiden kirjoittaminen PHP:llä tai jollain muulla.
Kaikki nämä 20 ihmistä on jaettu 15 palveluun, ja vain yhden järjestelmänvalvojan täytyy ymmärtää tämä kaikki. Lopettaa! jaoimme järjestelmän vain 15 mikropalveluun, koska 20 ihmistä ei ymmärrä koko järjestelmää.

Mutta sitä pitää jotenkin valvoa...

Mikä on tulos? Seurauksena on, että yksi henkilö keksii kaiken, mitä koko kehittäjäryhmä ei voi ymmärtää, ja samalla hänen on myös tiedettävä ja kyettävä tekemään se, mitä yllä ilmoitimme - laitteistoinfrastruktuuri, Kubernetes-infrastruktuuri jne.

Mitä voin sanoa... Houston, meillä on ongelmia.

Nykyaikaisen ohjelmistoprojektin seuranta on ohjelmistoprojekti sinänsä

Siitä väärästä uskomuksesta, että valvonta on ohjelmisto, kehitämme uskoa ihmeisiin. Mutta ihmeitä ei valitettavasti tapahdu. Et voi asentaa zabbixia ja odottaa kaiken toimivan. Ei ole mitään järkeä asentaa Grafanaa ja toivoa, että kaikki on ok. Suurin osa ajasta kuluu palvelujen toiminnan ja niiden keskinäisen vuorovaikutuksen tarkastusten järjestämiseen, ulkoisten järjestelmien toiminnan tarkastamiseen. Itse asiassa 90% ajasta ei käytetä skriptien kirjoittamiseen, vaan ohjelmistojen kehittämiseen. Ja sen tulisi hoitaa tiimi, joka ymmärtää projektin työn.
Jos tässä tilanteessa yksi henkilö heitetään valvontaan, tapahtuu katastrofi. Mitä tapahtuu kaikkialla.

Esimerkiksi Kafkan kautta on useita palveluita, jotka kommunikoivat keskenään. Tilaus saapui, lähetimme tilauksesta viestin Kafkalle. Siellä on palvelu, joka kuuntelee tiedot tilauksesta ja lähettää tavarat. Siellä on palvelu, joka kuuntelee tilauksen tiedot ja lähettää kirjeen käyttäjälle. Ja sitten ilmestyy joukko lisää palveluita, ja alamme hämmentyä.

Ja jos annat tämän myös järjestelmänvalvojalle ja kehittäjille siinä vaiheessa, kun julkaisuun on vähän aikaa, henkilön on ymmärrettävä tämä koko protokolla. Nuo. Tämän mittakaavan projekti vie huomattavan paljon aikaa, ja tämä tulee ottaa huomioon järjestelmän kehittämisessä.
Mutta hyvin usein, varsinkin startup-yrityksissä, näemme kuinka seurantaa lykätään myöhemmäksi. ”Nyt teemme Proof of Conceptin, lanseeraamme sen kanssa, anna sen pudota – olemme valmiita uhraamaan. Ja sitten valvomme kaikkea." Kun (tai jos) projekti alkaa tuottaa rahaa, yritys haluaa lisätä vielä enemmän ominaisuuksia - koska se on alkanut toimia, joten sitä on levitettävä edelleen! Ja olet siinä kohdassa, jossa sinun on ensin seurattava kaikkea edellistä, mikä ei vie 1% ajasta, vaan paljon enemmän. Ja muuten, kehittäjiä tarvitaan seurantaan, ja on helpompi antaa heidän työskennellä uusien ominaisuuksien parissa. Tämän seurauksena uusia ominaisuuksia kirjoitetaan, kaikki menee sekaisin ja olet loputtomassa umpikujassa.

Joten kuinka seurata projektia alusta alkaen ja mitä tehdä, jos saat projektin, jota on seurattava, mutta et tiedä mistä aloittaa?

Ensinnäkin sinun on suunniteltava.

Lyyrinen poikkeama: hyvin usein ne alkavat infrastruktuurin seurannasta. Meillä on esimerkiksi Kubernetes. Aloitetaan asentamalla Prometheus Grafanan kanssa, asentamalla laajennuksia "kuution" valvontaa varten. Ei vain kehittäjien, vaan myös järjestelmänvalvojien valitettava käytäntö: "Asennamme tämän laajennuksen, mutta laajennus luultavasti tietää, miten se tehdään." Ihmiset haluavat aloittaa yksinkertaisista ja yksinkertaisista asioista kuin tärkeistä toimista. Ja infrastruktuurin seuranta on helppoa.

Päätä ensin, mitä ja miten haluat seurata, ja valitse sitten työkalu, koska muut ihmiset eivät voi ajatella puolestasi. Ja pitäisikö heidän? Muut ihmiset ajattelivat itsekseen yleismaailmallisesta järjestelmästä - tai eivät ajatellut ollenkaan, kun tämä laajennus kirjoitettiin. Ja se, että tällä laajennuksella on 5 tuhatta käyttäjää, ei tarkoita, että siitä olisi mitään hyötyä. Ehkä sinusta tulee 5001. yksinkertaisesti siksi, että siellä oli jo 5000 ihmistä aiemmin.

Jos aloitat infrastruktuurin valvomisen ja sovelluksesi taustaohjelma lakkaa vastaamasta, kaikki käyttäjät menettävät yhteyden mobiilisovellukseen. Näkyviin tulee virhe. He tulevat luoksesi ja sanovat "Sovellus ei toimi, mitä teet täällä?" - "Seuraamme." — "Kuinka valvotte, jos et huomaa, että sovellus ei toimi?!"

Uskon, että sinun on aloitettava seuranta tarkalleen käyttäjän sisääntulopisteestä. Jos käyttäjä ei näe, että sovellus toimii, se on se, se on vika. Ja valvontajärjestelmän pitäisi varoittaa tästä ensin.
Ja vasta sitten voimme valvoa infrastruktuuria. Tai tee se rinnakkain. Se on helpompaa infrastruktuurin kanssa - täällä voimme vihdoin asentaa zabbixin.
Ja nyt sinun on mentävä sovelluksen juuriin ymmärtääksesi, missä asiat eivät toimi.

Pääajatukseni on, että seurannan tulisi tapahtua rinnakkain kehitysprosessin kanssa. Jos käännät seurantatiimin huomion muihin tehtäviin (CI/CD:n luominen, hiekkalaatikko, infrastruktuurin uudelleenjärjestely), valvonta alkaa viivästyä, etkä ehkä koskaan saavuta kehitystä (tai ennemmin tai myöhemmin sinun on lopetettava se).

Kaikki tasoittain

Näin näen seurantajärjestelmän organisoinnin.

1) Sovellustaso:

seurata sovellusten liiketoimintalogiikkaa;
Palveluiden terveysmittausten seuranta;
integraation seuranta.

2) Infrastruktuurin taso:

orkestrointitason seuranta;
järjestelmän ohjelmistojen seuranta;
rautatason seuranta.

3) Jälleen sovellustaso - mutta suunnittelutuotteena:

sovelluslokien kerääminen ja seuranta;
APM;
jäljittäminen.

4) Varoitus:

varoitusjärjestelmän järjestäminen;
velvollisuusjärjestelmän järjestäminen;
"tietokannan" ja työnkulun järjestäminen tapahtumien käsittelyä varten.

On tärkeää: pääsemme hälytykseen ei jälkeen, vaan heti! Ei tarvitse käynnistää valvontaa ja "joskin myöhemmin" selvittää, kuka saa hälytyksiä. Loppujen lopuksi, mikä on seurannan tehtävä: ymmärtää, missä järjestelmässä jokin toimii väärin, ja kertoa siitä oikeille ihmisille. Jos jätät tämän loppuun, oikeat ihmiset tietävät, että jokin menee pieleen vain sanomalla "mikään ei toimi meille".

Sovelluskerros - Business Logic Monitoring

Tässä puhutaan sen tosiasian tarkistamisesta, että sovellus toimii käyttäjän hyväksi.

Tämä taso tulisi tehdä kehitysvaiheessa. Meillä on esimerkiksi ehdollinen Prometheus: se menee palvelimelle, joka tekee tarkistukset, vetää päätepisteen ja päätepiste menee ja tarkistaa API.

Kun ohjelmoijia pyydetään usein valvomaan kotisivua varmistaakseen, että sivusto toimii, ohjelmoijat antavat kahvan, jota voidaan vetää aina, kun he tarvitsevat varmistaakseen, että API toimii. Ja tällä hetkellä ohjelmoijat ottavat ja kirjoittavat edelleen /api/test/helloworld
Ainoa tapa varmistaa, että kaikki toimii? - Ei!

Tällaisten tarkistusten luominen on pohjimmiltaan kehittäjien tehtävä. Yksikkötestit tulee kirjoittaa koodin kirjoittavien ohjelmoijien toimesta. Koska jos vuodat sen järjestelmänvalvojalle: "Kaveri, tässä on luettelo API-protokollasta kaikille 25 toiminnolle, tarkkaile kaikkea!" - mikään ei onnistu.
Jos tulostat "hello world", kukaan ei koskaan tiedä, että API:n pitäisi toimia ja toimii. Jokaisen API-muutoksen on johdettava muutokseen tarkistuksissa.
Jos sinulla on jo tällainen ongelma, pysäytä ominaisuudet ja varaa kehittäjät, jotka kirjoittavat nämä tarkistukset tai hyväksyvät tappiot, hyväksy, että mitään ei tarkisteta ja epäonnistuu.

Teknisiä vinkkejä:

Muista järjestää ulkoinen palvelin tarkastusten järjestämiseksi - sinun on oltava varma, että projektisi on ulkomaailman saatavilla.
Järjestä tarkistukset koko API-protokollalle, ei vain yksittäisille päätepisteille.
Luo prometheus-päätepiste testituloksista.

Sovelluskerros - terveystietojen seuranta

Nyt puhutaan palveluiden ulkoisista terveysmittauksista.

Päätimme valvoa kaikkia sovelluksen "kahvoja" ulkoisten tarkistusten avulla, joita kutsumme ulkoisesta valvontajärjestelmästä. Mutta nämä ovat "kahvat", jotka käyttäjä "näkee". Haluamme olla varmoja, että itse palvelumme toimivat. Tässä on parempi tarina: K8:ssa on terveystarkastukset, jotta ainakin "kuutio" itse voi vakuuttaa palvelun toimivuudesta. Mutta puolet näkemistäni shekeistä on sama printti "hello world". Nuo. Joten hän vetää kerran käyttöönoton jälkeen, hän vastasi, että kaikki on hyvin - siinä kaikki. Ja palvelulla, jos se tarjoaa oman API:n, on valtava määrä pääsypisteitä samalle API:lle, jota on myös seurattava, koska haluamme tietää, että se toimii. Ja me valvomme sitä jo sisällä.

Kuinka toteuttaa tämä oikein teknisesti: jokainen palvelu paljastaa päätepisteen sen nykyisestä suorituskyvystä, ja Grafanan (tai minkä tahansa muun sovelluksen) kaavioissa näemme kaikkien palveluiden tilan.

Jokaisen API-muutoksen on johdettava muutokseen tarkistuksissa.
Luo heti uusi palvelu terveysmittareilla.
Järjestelmänvalvoja voi tulla kehittäjien luo ja kysyä "lisää minulle pari ominaisuutta, jotta ymmärrän kaiken ja lisää tästä tietoa valvontajärjestelmääni." Mutta kehittäjät vastaavat yleensä: "Emme lisää mitään kaksi viikkoa ennen julkaisua."
Kerro kehityspäälliköille, että tällaisia menetyksiä tulee, kerro myös kehitysjohtajien johdolle. Koska kun kaikki kaatuu, joku silti soittaa ja vaatii valvomaan "jatkuvasti putoavaa palvelua" (c)
Muuten, anna kehittäjät kirjoittaa laajennuksia Grafanalle - tämä on hyvä apu järjestelmänvalvojille.

Sovelluskerros - Integraation valvonta

Integraatioseuranta keskittyy liiketoiminnalle kriittisten järjestelmien välisen viestinnän seurantaan.

Esimerkiksi 15 palvelua kommunikoivat keskenään. Nämä eivät ole enää erillisiä sivustoja. Nuo. emme voi vetää palvelua itsestään, saada /helloworld ja ymmärtää, että palvelu on käynnissä. Koska tilausverkkopalvelun on lähetettävä tilaustiedot linja-autoon - linja-autosta, varastopalvelun tulee vastaanottaa tämä viesti ja työskennellä sen kanssa. Ja sähköpostin jakelupalvelun täytyy käsitellä tätä jotenkin eteenpäin jne.

Näin ollen emme voi ymmärtää jokaisessa yksittäisessä palvelussa, että se kaikki toimii. Koska meillä on tietty väylä, jonka kautta kaikki kommunikoi ja on vuorovaikutuksessa.
Siksi tämän vaiheen tulisi merkitä palveluiden testausvaihetta vuorovaikutusta varten muiden palvelujen kanssa. Viestinnän seurantaa on mahdotonta järjestää seuraamalla viestivälittäjää. Jos on palvelu, joka antaa tietoja ja palvelu, joka vastaanottaa niitä, välittäjää valvoessa näemme vain tiedot, jotka lentävät puolelta toiselle. Vaikka olisimme jotenkin onnistuneet valvomaan näiden tietojen vuorovaikutusta sisäisesti - että tietty tuottaja julkaisee tiedot, joku lukee sen, tämä virta menee edelleen Kafkaan - tämä ei silti anna meille tietoa, jos yksi palvelu lähetti viestin yhdessä versiossa , mutta toinen palvelu ei odottanut tätä versiota ja ohitti sen. Emme tiedä tästä, koska palvelut kertovat meille, että kaikki toimii.

Mitä suosittelen tekemään:

Synkroninen viestintä: päätepiste tekee pyyntöjä asiaan liittyville palveluille. Nuo. otamme tämän päätepisteen, vedämme palvelun sisään skriptin, joka menee kaikkiin pisteisiin ja sanoo "Voin vetää sinne, ja vedä sinne, voin vetää sinne..."
Asynkroninen viestintä: saapuvat viestit - päätepiste tarkistaa väylän testiviestit ja näyttää käsittelyn tilan.
Asynkroninen viestintä: lähtevät viestit - päätepiste lähettää testiviestit väylään.

Kuten yleensä tapahtuu: meillä on palvelu, joka heittää dataa väylään. Tulemme tähän palveluun ja pyydämme sinua kertomaan meille sen integraation terveydestä. Ja jos palvelun on tuotettava viesti jossain kauempana (WebApp), se tuottaa tämän testiviestin. Ja jos käytämme palvelua OrderProcessing-puolella, se ensin lähettää sen, mitä se voi lähettää itsenäisesti, ja jos on joitain riippuvaisia asioita, se lukee joukon testiviestejä väylästä, ymmärtää, että se voi käsitellä ne, raportoida ja , postaa niitä tarvittaessa lisää, ja tästä hän sanoo - kaikki on ok, olen elossa.

Hyvin usein kuulemme kysymyksen "miten voimme testata tätä taistelutiedoilla?" Puhumme esimerkiksi samasta tilauspalvelusta. Tilaus lähettää viestejä varastoon, jossa tavarat poistetaan: emme voi testata tätä taistelutiedoilla, koska "tavarani poistetaan!" Ratkaisu: Suunnittele koko testi heti alussa. Sinulla on myös yksikkötestejä, jotka tekevät pilkkaa. Tee se siis syvemmällä tasolla, jossa sinulla on viestintäkanava, joka ei vahingoita yrityksen toimintaa.

Infrastruktuurikerros

Infrastruktuurin seuranta on asia, jota on pitkään pidetty itsevalvonnana.

Infrastruktuurin seuranta voidaan ja pitää käynnistää erillisenä prosessina.
Sinun ei pitäisi aloittaa infrastruktuurin valvonnasta käynnissä olevassa projektissa, vaikka todella haluaisi. Tämä on tuskaa kaikille devoille. ”Ensin seuraan klusteria, seuraan infrastruktuuria” – ts. Ensinnäkin se tarkkailee, mitä alla on, mutta ei mene sovellukseen. Koska sovellus on käsittämätön asia devopsille. Se on vuotanut hänelle, eikä hän ymmärrä, miten se toimii. Ja hän ymmärtää infrastruktuurin ja aloittaa siitä. Mutta ei - sinun on aina ensin valvottava sovellusta.
Älä mene liioittele hälytysten määrän kanssa. Kun otetaan huomioon nykyaikaisten järjestelmien monimutkaisuus, hälytykset lentävät jatkuvasti, ja sinun on jotenkin elettävä tämän hälytysjoukon kanssa. Ja päivystävä henkilö, joka on katsonut sata seuraavaa hälytystä, päättää "En halua ajatella sitä". Hälytysten tulisi ilmoittaa vain kriittisistä asioista.

Sovellustaso liiketoimintayksikkönä

Keskeiset kohdat:

HIRVI. Tämä on alan standardi. Jos et jostain syystä kokoa lokeja, aloita se välittömästi.
APM. Ulkoiset APM:t tapana sulkea nopeasti sovellusten valvonta (NewRelic, BlackFire, Datadog). Voit asentaa tämän asian väliaikaisesti ymmärtääksesi ainakin jotenkin, mitä sinulle tapahtuu.
Jäljitys. Kymnissä mikropalveluissa kaikkea pitää jäljittää, koska pyyntö ei enää elä itsestään. Sitä on erittäin vaikea lisätä myöhemmin, joten on parempi ajoittaa jäljitys heti kehitykseen - tämä on kehittäjien työ ja hyöty. Jos et ole vielä ottanut sitä käyttöön, ota se käyttöön! Katso Jaeger/Zipkin

Varoittaa

Ilmoitusjärjestelmän organisointi: monien asioiden seurannan olosuhteissa pitäisi olla yhtenäinen järjestelmä ilmoitusten lähettämiseen. Voit Grafanassa. Lännessä kaikki käyttävät PagerDutya. Varoitusten tulee olla selkeitä (esim. mistä ne tulivat...). Ja on suositeltavaa valvoa, että ilmoituksia vastaanotetaan ollenkaan
Päivystysjärjestelmän organisointi: kaikille ei pidä lähettää hälytyksiä (joko kaikki reagoivat joukkoon tai kukaan ei reagoi). Kehittäjien on myös oltava päivystys: muista määritellä vastuualueet, tehdä selkeät ohjeet ja kirjoittaa siihen kenelle tarkalleen soittaa maanantaina ja keskiviikkona ja kenelle soittaa tiistaina ja perjantaina (muuten he eivät soita kenellekään edes suuren ongelman sattuessa - he pelkäävät herättää sinut tai häiritä sinua: ihmiset eivät yleensä halua soittaa ja herättää muita ihmisiä, etenkään yöllä). Ja selitä, että avun pyytäminen ei ole osoitus epäpätevyydestä ("Pyydän apua, se tarkoittaa, että olen huono työntekijä"), rohkaise avunpyyntöjä.
"Tietopohjan" ja työnkulun järjestäminen tapahtumien käsittelyä varten: jokaiselle vakavalle vaaratilanteelle on suunniteltava post mortem ja väliaikaisena toimenpiteenä tapahtuman ratkaisemiseksi tehtävät toimet. Ja tee siitä käytäntö, että toistuvat hälytykset ovat syntiä; ne on korjattava koodissa tai infrastruktuurityössä.

Teknologiapino

Kuvitellaan, että pinomme on seuraava:

tiedonkeruu - Prometheus + Grafana;
lokianalyysi - ELK;
APM:lle tai Tracingille - Jaeger (Zipkin).

Vaihtoehtojen valinta ei ole kriittinen. Koska jos alussa ymmärsit järjestelmän valvomisen ja kirjoitit suunnitelman, alat valita työkaluja tarpeidesi mukaan. Kysymys kuuluu, mitä päätit valvoa alun perin. Koska ehkä alussa valitsemasi työkalu ei vastaa vaatimuksiasi ollenkaan.

Muutama tekninen seikka, jotka olen nähnyt kaikkialla viime aikoina:

Prometheusta työnnetään Kubernetesiin - kuka tämän keksi?! Jos klusterisi kaatuu, mitä teet? Jos sisällä on monimutkainen klusteri, klusterin sisällä pitäisi olla jonkinlainen valvontajärjestelmä ja sen ulkopuolella jokin valvontajärjestelmä, joka kerää tietoja klusterin sisältä.

Klusterin sisällä keräämme lokit ja kaiken muun. Mutta valvontajärjestelmän on oltava ulkopuolella. Hyvin usein klusterissa, jossa Promtheus on asennettu sisäisesti, on myös järjestelmiä, jotka suorittavat ulkoisia tarkastuksia sivuston toiminnasta. Entä jos yhteytesi ulkomaailmaan ovat katkenneet eikä sovellus toimi? Osoittautuu, että kaikki on sisällä hyvin, mutta se ei tee asioista yhtään helpompaa käyttäjien kannalta.

Tulokset

Kehityksen seuranta ei ole apuohjelmien asennusta, vaan ohjelmistotuotteen kehittämistä. 98 % tämän päivän valvonnasta on koodausta. Koodaus palveluissa, ulkoisten tarkistusten koodaus, ulkoisten palvelujen tarkistaminen ja siinä kaikki.
Älä tuhlaa kehittäjien aikaa seurantaan: se voi viedä jopa 30 % heidän työstään, mutta se on sen arvoista.
Devops, älä ole huolissasi siitä, että et voi valvoa jotain, koska jotkut asiat ovat täysin erilainen ajattelutapa. Et ollut ohjelmoija, ja valvontatyö on juuri heidän tehtävänsä.
Jos projekti on jo käynnissä eikä sitä valvota (ja olet johtaja), varaa resurssit seurantaan.
Jos tuote on jo tuotannossa ja olet devops, jolle käskettiin "asettaa valvonta" - yritä selittää johdolle, mistä kirjoitin tämän kaiken.

Tämä on laajennettu versio Saint Highload++ -konferenssin raportista.

Jos olet kiinnostunut ideoistani ja ajatuksistani siitä ja siihen liittyvistä aiheista, niin täällä voit tehdä sen lue kanava 🙂

Lähde: will.com

Onko valvonta kuollut? – Eläköön seuranta