Kaksi vuotta sitten tein jo postauksen Yksinkertainen vikasieto sivustolle про okerr. Nyt hankkeessa on jonkin verran kehitystä, ja julkaisin myös okerr-palvelinpuolen lähdekoodi alle avoin lisenssi, siksi päätin kirjoittaa tämän lyhyen arvostelun Habr.

[ täysikokoinen ]

Ketä se voi kiinnostaa

Tämä saattaa kiinnostaa sinua, jos työskentelet pienessä ryhmässä tai yksin. Sinulla ei ole valvontaa etkä ole varma, tarvitsetko sitä todella. Joko kokeilit suosittua vakavaa seurantaa "isoille pojille", mutta se jotenkin "ei lähtenyt liikkeelle" sinulle, tai se toimii melkein oletuskokoonpanossa eikä muuttanut elämääsi paljon. Ja myös - jos et ehdottomasti aio allokoida koko työntekijää (tai edes osastoa) valvomaan valvontakojelautaa vähintään pari tuntia päivässä tai määrittämään sitä.

Miksi okerr on epätavallinen

Seuraavaksi näytän okerran mielenkiintoisia ominaisuuksia, jotka erottavat sen joistakin muista valvontajärjestelmistä.

Okerr on hybridivalvonta

Sisäisen valvonnan aikana valvotuissa koneissa on käynnissä "agentti", joka välittää tietoja valvontapalvelimelle (esimerkiksi vapaata levytilaa). Ulkoisena palvelin suorittaa tarkistuksia verkon yli (esimerkiksi ping- tai verkkosivuston saatavuus). Jokaisella lähestymistavalla on rajoituksensa. Okerr käyttää molempia vaihtoehtoja. Tarkistukset palvelimien sisällä tehdään erittäin kevyellä (30Kb) agentilla tai omilla skripteillä ja sovelluksilla ja verkkotarkistukset okerr-anturien kautta eri maissa.

okerr ei ole vain ohjelmisto, vaan myös palvelu

Kaiken seurannan palvelinosa on suuri ja monimutkainen, sen asentaminen ja konfigurointi on vaikeaa ja se vaatii resursseja. Okerrin avulla voit asentaa oman valvontapalvelimesi (se on ilmainen ja avoimen lähdekoodin lähde), tai voit käyttää vain asiakasosaa ja käyttää palvelimemme palvelua. Myös ilmainen.

Jos valvonnan avulla voit kompensoida ja peittää palvelimien ja sovellusten luotettavuuden puutteen, herää filosofinen kysymys - kuka on vartija? Miten valvonta kertoo meille ongelmasta, jos se jostain syystä "kuoli" itse, erikseen tai yhdessä muiden resurssien kanssa (esim. palvelinkeskuksen kanava kaatui)? Kun käytät ulkoista palvelua okerr - tämä ongelma on ratkaistu - saat hälytyksen, vaikka koko datakeskus palvelimineen olisi ilman virtaa tai zombien hyökkäämään.

Tietenkin on olemassa riski, että itse okerr-palvelin ei ole käytettävissä, tämä on totta (kuten tiedätte, 90% luotettavuudesta saadaan aina yksinkertaisesti ja "ilmaiseksi", 99% vähäisellä vaivalla, ja jokainen seuraava yhdeksän on eksponentiaalisesti vaikeampi). Mutta ensinnäkin, tämän tapahtuman todennäköisyys on pienempi, ja toiseksi ongelma voi jäädä huomaamatta vain, jos se osuu yhteen palvelimillamme olevien ongelmien kanssa. Jos meillä on 99.9 % luotettavuus ja sinulla on 99.9 % (ei liian korkeat luvut), havaitsemattoman vian mahdollisuus on 0.1 % 0.1 % = 0.0001 %. Kolmen yhdeksän lisääminen luotettavuuteen lähes ilman vaivaa ja kustannuksia on erittäin hyvä!

Toinen valvonnan etu palveluna on se, että hosting-palveluntarjoaja tai web-studio voi asentaa okerr-palvelimen ja tarjota asiakkaille pääsyn maksullisena tai ilmaisena lisäpalveluna. Kilpailijoillasi on vain hosting ja verkkosivustot, mutta sinulla on luotettava isännöinti ja seuranta.

Okerr on indikaattoreista

Ilmaisin on "lamppu". Siinä on kaksi päätilaa - vihreä (OK) tai punainen (ERR). Projekti sisältää monia ryhmiteltyjä (esimerkiksi palvelimen mukaan) indikaattoreita. Projektin pääsivulla näet heti, että joko kaikki on vihreää (ja voit sulkea sen) tai jotain palaa punaisena ja se on korjattava. Kun siirrytään näiden tilojen välillä, lähetetään hälytys. Kerran päivässä, kun määrität sitä, yhteenveto projektista lähetetään.

Jokaisella okerr-indikaattorilla on sisäänrakennetut ehdot, joilla se muuttaa tilaa (Zabbixissa tätä kutsutaan triggeriksi). Esimerkiksi kuormituksen keskiarvon ei tulisi olla suurempi kuin 2 (tämä on tietysti konfiguroitavissa). Ja jokaiselle sisäiselle tarkastukselle (kuormituksen keskiarvo, levytön ...) on vahtikoira. Jos emme jostain syystä saa onnistunutta vahvistusta sovittuna aikana, kirjataan virhe ja lähetetään hälytys.

Tavanomainen työtapamme on tarkistaa sähköpostit aamulla ja katsoa siellä olevaa yhteenvetoa muiden sähköpostien joukossa (aikataulutamme sen työn alkaessa). Jos kaikki on kunnossa, teemme muita tärkeitä asioita (mutta varmuuden vuoksi voimme nopeasti katsoa okerran kojelautaa ja varmistaa, että kaikki on tällä hetkellä vihreää). Jos hälytys tulee, reagoimme.

Tietysti on mahdollista säilyttää yksinkertaisesti "informaatio"-indikaattoreita (nähdäksesi verkon kuvan valvonnasta), mutta kaikki tehdään niin, että luodaan yksinkertaisesti, helposti ja nopeasti indikaattoreita erityisesti automaattista valvontaa ja hälytysten lähettämistä varten.

Tarkoitus, jota varten asetat okerrin, on hälytyksiä, jotta voit luoda ilmaisimen minuutissa, se voisi "nukkua" vuoden, vain hyväksyä päivitykset ja kun vuoden kuluttua jokin hajoaa, se syttyy ja lähettää hälytys. Minuutti, jonka kerran käytit indikaattorin luomiseen, tuotti tulosta; sait tietää ongelmasta välittömästi, ennen muita. On mahdollista, että he korjasivat sen ennen kuin kukaan huomasi. Sitä, mikä nousee nopeasti ylös, ei pidetä kaatuneena!

Безопасность

Olisi sääli, jos laittaisit valvonnan käyttöön luotettavuuden lisäämisen vuoksi, mutta seurauksena sinuun hyökätään verkon yli sen kautta ja verkon haavoittuvuuksia on melko paljon erilaisissa valvontatyökaluissa (Zabbix, Nagios).

Agentti (okerrmod paketista okerruptate) järjestelmässä ei ole verkkopalvelin, vaan asiakas. Siksi valvotulla palvelimella ei ole ylimääräisiä avoimia portteja, asiakas toimii helposti palomuurin tai NAT:n takana ja sitä on erittäin vaikea (sanoisin "mahdoton") hakkeroida verkon yli, koska se ei periaatteessa kuuntele verkkoa pistorasia.

Täysi valvontakattavuus

Nyt sääntömme on, että opimme kaikki tekniset ongelmat okerrilta. Jos yhtäkkiä sääntöä rikotaan (okerr ei varoittanut sen välittömästä esiintymisestä (jos tämä on mahdollista) tai että se on jo tapahtunut) - lisäämme tarkistukset okerriin.

Ulkoiset tarkastukset

Aika tyypillinen setti:

• ping
• https-tila
• SSL-varmenteen voimassaolon ja tuoreuden tarkistaminen (varoittaa, jos se on vanhentumassa)
• avaa TCP-portti ja banneri siinä
• http grep (sivu [ei saa] sisältää tiettyä tekstiä)
• sha1 hash sivun muutosten havaitsemiseksi.
• DNS (DNS-tietueella on oltava tietty arvo)
• WHOIS (varoittaa, jos verkkotunnus on huonontumassa)
• Roskapostin esto DNSBL (isäntä tarkistaa 50+ roskapostin eston mustaa listaa vastaan ​​kerralla)

Sisäiset tarkastukset

Myös melko tavallinen sarja (mutta helposti laajennettavissa).

• df (vapaa levytila)
• kuormituksen keskiarvo
• opentcp (avoin TCP-kuuntelupistokkeet - ilmoittaa, jos jokin alkaa tai kaatuu)
• käytettävyys - vain käytettävyys palvelimella. Ilmoittaa, jos se on muuttunut (eli palvelin on ylikuormitettu)
• client_ip
• dirsize - käytämme sitä seuraamaan, milloin virtuaalikoneen juuret ylittävät sallitun koon ilman tiukkoja rajoituksia ja käyttäjien kotihakemistojen kokoa
• tyhjä ja ei-tyhjä - tarkkaile tiedostoja, joiden tulee olla tyhjiä (tai ei tyhjiä). Esimerkiksi itse okerr-palvelimen virhelokin pitäisi olla tyhjä, ja jos siinä on edes rivi, saan ilmoituksen ja tarkistan sen. Mutta postipalvelimen mail.log EI saa olla tyhjä (N minuuttia kierron jälkeen). Ja joskus se oli meille tyhjä järjestelmäpäivityksen jälkeen, kun logrotate ei voinut käynnistää rsyslogia uudelleen oikein.
• rivien määrä - tiedoston rivien määrä (kuten wc -l). Käytämme sitä pehmeämpänä korvaajana tyhjälle, kun virheloki voi vielä kasvaa, mutta vain hitaasti (esim. Googlebot osuu suljetuille sivuille). Raja on 2 riviä 20 minuutissa. Jos se on korkeampi, tulee hälytys

Mielenkiintoisia sisäisiä tarkastuksia

Jos olet tähän asti lukenut "vinosti", nyt on mielenkiintoisempaa lukea tarkemmin.

varmuuskopiot

Valvoo hakemistossa olevia varmuuskopioita. Varmuuskopiotiedostoillamme on nimet kuten "PalvelimenNimi-20200530.tar.gz". Jokaiselle okerrin palvelimelle luodaan ilmaisin ServerName-DATE.tar.gz (todellinen päivämäärä muuttuu riviksi "DATE"). Myös tuoreen varmuuskopion läsnäoloa ja sen kokoa valvotaan (esimerkiksi se ei voi olla pienempi kuin 90 % edellisestä varmuuskopiosta).

Mitä on tehtävä, jotta uutta varmuuskopiota voidaan seurata sen jälkeen, kun olemme aloittaneet sen luomisen ja sijoittamisen tähän hakemistoon? Ei mitään! Tämä on erittäin kätevä lähestymistapa, kun sinun ei tarvitse tehdä mitään, koska:

• "Ei mitään" tekeminen on melko nopeaa, se säästää aikaa
• On vaikea unohtaa tehdä "ei mitään"
• On vaikeaa tehdä "ei mitään" väärin, virheen kanssa. Mikään ei ole luotettavin tapa

Jos yhtäkkiä tuoreet varmuuskopiotiedostot lakkaavat näkymästä, annetaan hälytys. Jos olet esimerkiksi poistanut yhden palvelimista käytöstä, eikä varmuuskopioita pitäisi olla enää, sinun on poistettava ilmaisin (verkkokäyttöliittymän kautta tai komentotulkista API:n kautta).

maxfilesz

Pitää kirjaa suurimpien tiedostojen koosta (yleensä: /var/log/*). Näin voit saada kiinni arvaamattomista ongelmista, kuten brute force -salasanoista tai roskapostin lähettämisestä palvelimen kautta.

runstatus/runline

Nämä ovat kaksi tärkeää välityspalvelinmoduulia muiden palvelimen ohjelmien suorittamiseen. Runstatus ilmoittaa ohjelman poistumiskoodin ilmaisimelle. Esimerkiksi okerr ei (edellyttää) moduulia tarkistaakseen, että systemd-palvelut ovat käynnissä. Tämä tehdään runstatusin kautta (katso alla). Runline - raportoi palvelimelle ohjelman tuottaman rivin. Esimerkiksi, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" palvelimemme Runline-kokoonpanossa luo indikaattorin servername:temp prosessorin lämpötilalla.

sql

Suorittaa numeerisen kyselyn MySQL:lle ja raportoi tuloksen indikaattorille. Yksinkertaisessa tapauksessa voit tehdä esimerkiksi "SELECT 1" - tämä tarkistaa, että DBMS kokonaisuudessaan toimii.

Mutta paljon mielenkiintoisempi sovellus on esimerkiksi tilausten määrän seuranta verkkokaupassa. Jos tiedät, että sinulla on 100 tai enemmän tilauksia tunnissa, voit asettaa vähimmäisrajaksi 100 tai 80. Sitten jos myyntisi putoaa yhtäkkiä, saat hälytyksen ja voit selvittää sen.

Huomaa, että sillä ei ole väliä, mistä arvaamattomasta syystä tämä tapahtui:

• Palvelin ei yksinkertaisesti ole käytettävissä (virraton tai ilman verkkoa), ja hälytys tuli siitä, että ilmaisin oli "mätä".
• Palvelin on ylikuormitettu jollakin, se toimii hitaasti tai paketteja katoaa, se on epämukavaa käyttäjille ja he lähtevät tekemättä ostoksia
• Palvelin on mukana roskapostiluetteloissa, eikä sen postia oteta vastaan, käyttäjät eivät voi rekisteröityä
• Mainoskampanjan budjetti on lopussa, bannerit eivät pyöri.

Syitä voi olla useita, eikä niitä kaikkia voi ennakoida etukäteen, ja niiden jäljittäminen on teknisesti vaikeaa. Mutta voit kätevästi valvoa lopullista parametria (tilauksia) ja päättää niistä, että tilanne on epäilyttävä ja ansaitsee käsitellä.

Loogiset indikaattorit

Mahdollistaa Boolen lausekkeiden (Python-syntaksi) käytön moduulin kautta arvioida(artikkeli Habresta). Hankkeen tiedot ja sen indikaattorit ovat käytettävissä ilmaisua varten. Esimerkiksi yllä olevassa SQL-tarkistusta käsittelevässä luvussa olet saattanut huomata heikkouden - päivällä meillä voi olla 100 myyntiä tunnissa, mutta yöllä - 20, ja tämä on yleistä, ei ongelma. Mitä minun pitäisi tehdä? Indikaattori panikoi jatkuvasti yöllä.

Voit luoda kaksi indikaattoria, päivä ja yö. Tee molemmat "hiljaisiksi" (he eivät lähetä hälytyksiä). Ja luo looginen ilmaisin, joka edellyttää, että päiväilmaisin on OK ennen klo 20:00 ja kello 20:00 jälkeen riittää, että yöilmaisin on kunnossa.

Toinen esimerkki loogisen indikaattorin käytöstä on kiihtymisestä. Esimerkiksi projektipäällikkö peruuttaa hälytyksiä (hänen ei tarvitse tehdä tätä, järjestelmänvalvojien tulee reagoida normaaleihin ongelmiin), mutta tilaa loogisen ilmaisimen, joka muuttuu punaiseksi, jos jotakin projektin ilmaisinta ei korjata varatun ajan kuluessa.

Lisäksi on mahdollista asettaa sallittu työaika esimerkiksi klo 3-5. Emme välitä, jos palvelimet ja sivustot kaatuvat tänä aikana. Mutta klo 5 heidän on tehtävä töitä. Jos ne eivät toimi muina aikoina - hälytys. Loogisen ilmaisimen avulla voit myös ottaa huomioon palvelimen redundanssin. Jos sinulla on 00 verkkopalvelinta, järjestelmänvalvojat voivat sammuttaa 5-1 palvelinta milloin tahansa. Mutta jos taistelussa on vähemmän kuin 2 palvelimesta viidestä, tulee hälytys.

Yllä olevat esimerkit eivät ole oker-toimintoja, eivät joitain ominaisuuksia, jotka on aktivoitava ja määritettävä. Okerralla ei ole kaikkia näitä toimintoja, mutta siellä on looginen moduuli, jonka avulla voit toteuttaa tämän toiminnon (Suurin kuin ohjelmointikielessä - jos meillä on aritmeettisia operaattoria, emme tarvitse erityistä toimintoa 20% ALV:n laskemiseen kielestä, voit aina tehdä sen itse tehdäksesi sen tarpeidesi mukaan).

Logic Indicator on luultavasti yksi harvoista suhteellisen monimutkaisista aiheista okerrissä, mutta hyvä uutinen on, että sinun ei tarvitse hallita sitä ennen kuin sinun tarvitsee. Mutta samaan aikaan ne laajentavat huomattavasti ominaisuuksia pitäen itse järjestelmän melko yksinkertaisena.

Omien shekkien lisääminen

Haluaisin todella välittää ajatuksen siitä, että okerr ei ole joukko tuhansia valmiita shekkejä kaikkiin tilanteisiin, vaan päinvastoin - ensinnäkin - yksinkertainen moottori, jolla on yksinkertainen kyky luoda omia shekkejä. Omien shekkien luominen okerrissä ei ole hakkereiden, järjestelmän kehittäjien tai ainakaan edistyneiden okerr-käyttäjien tehtävä, vaan jokaisen järjestelmänvalvojan tehtävä, joka asensi Linuxin ensimmäistä kertaa kuukausi sitten.

Vähimmäispalkkojen tarkastukset tehdään moduulin kautta runstatus:

Tämä rivi asetuksissa runstatus ilmoittaa sinulle, jos /bin/true ei yhtäkkiä käynnisty tai palauttaa jotain muuta kuin 0.

true_OK=/bin/true

Vain yksi rivi - ja tässä ollaan jo vähän laajennettu toiminnallisuus okerr.

Jopa sellaisella tarkistuksella on jo arvonsa: jos palvelimesi yhtäkkiä kaatuu, okerr-palvelimen vastaavaa ilmaisinta ei päivitetä ajoissa, ja ajan kuluttua ilmestyy hälytys.

Tämä tarkistus ilmoittaa, että apache2-palvelin on kaatunut (no, et koskaan tiedä...):

apache_OK="systemctl is-active --quiet apache2"

Joten jos puhut mitä tahansa ohjelmointikieltä ja ainakin osaat kirjoittaa shell-skriptejä, voit jo lisätä omat shekit.

Vaikeampi - voit kirjoittaa (millä tahansa kielellä) oman moduulisi okerrmodille. Yksinkertaisimmassa tapauksessa se näyttää tältä:

#!/usr/bin/python3

print("STATUS: OK")

Eikö se ole kovin vaikeaa? Moduulin on suoritettava tarkistus itse ja tulostettava tulokset STDOUTiin. Monimutkaisempi moduuli antaa esimerkiksi tämän:

$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G used, 13.0G free
STATUS: 49.52

NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M used, 9.9M free
STATUS: 84.32

Se päivittää useita indikaattoreita kerralla (tyhjällä rivillä erotettuina), luo niitä tarvittaessa, osoittaa varmennustiedot ja tagin, jonka avulla on helppo löytää tarvittavat indikaattorit kojelaudalta.

Telegram

Siellä on Telegram-botti @OkerrBot. Sinun ei tarvitse sotkea puhelintasi erillisillä sovelluksilla (en pidä siitä, että Pyaterochkalle tarvitset yhden sovelluksen kartalla, Lentalle toisen, MTS:lle kolmannen ja niin edelleen kaikille, kaikille, kaikille). Yksi sähke riittää. Sähkeen kautta voit vastaanottaa välittömästi hälytyksiä, tarkistaa projektin tilan ja antaa komennon tarkistaa kaikki ongelmalliset ilmaisimet uudelleen. Poistuimme teatterista/lentokoneesta, emme pitäneet sormea ​​pulssilla kahteen tuntiin, käynnistimme puhelimen, painoimme yhtä painiketta chatbotissa ja varmistimme, että kaikki oli hyvin.

Tilasivut

Nykyään statussivut ovat lähes pakollisia jokaiselle yritykselle, jolla on IT, vastuullinen asenne luotettavuuteen ja joka kohtelee asiakkaitaan/käyttäjiään kunnioittavasti.

Kuvittele tilanne - käyttäjä haluaa tehdä jotain, tarkastella tietoja tai tehdä tilauksen, mutta jokin ei toimi. Hän ei tiedä mitä tapahtuu, kenen puolella ongelma on ja milloin se ratkaistaan. Ehkä yritykselläsi on vain toimimaton verkkosivusto? Vai menikö se rikki kuusi kuukautta sitten ja se korjataan kahdessa vuodessa? Mutta sinun täytyy ostaa jääkaappi nyt, se on jo kärryssä... Ja se on aivan eri asia, kun ihminen näkee, että sinulla on jotain vialla (ainakin on selvää, että ongelma ei ole hänen puolellaan), että ongelma on havaittu, että olet jo työstämässä sitä, ja ehkä jopa kirjoitit muistiin likimääräisen korjausajan. Käyttäjä voi tilata ja saada sähköposti-ilmoituksen, kun ongelma on korjattu ja hän voi tehdä mitä haluaa (ostaa jääkaapin).

Ongelmia ja seisokkeja sattuu kaikille. Mutta käyttäjät ja kumppanit luottavat enemmän niihin, jotka suhtautuvat asiaan avoimemmin ja vastuullisemmin.

Täällä katsaus 10 muuhun projektiin, joiden avulla voit luoda tilasivuja. Tässä on esimerkkejä siitä, miltä nämä projektisivut näyttävät Python и dropbox. okerr-tilasivu.

Vara

Jotta tästä artikkelista ei tulisi vielä pitempi, viittaan jälleen edelliseen artikkeliini - Yksinkertainen vikasieto sivustolle . Jos pystyt tekemään päällekkäisen palvelimen, vikasietoa käytettäessä sinulla ei periaatteessa ole pitkää seisonta-aikaa - heti kun ongelma havaitaan, käyttäjät ohjataan automaattisesti toimivalle varapalvelimelle. Ja minusta näyttää siltä, ​​​​että tämä on erittäin mielenkiintoinen, kirkas ominaisuus, joka on harvoin saatavilla missään.

Matalat järjestelmävaatimukset

Okerr-palvelimissa käytämme koneita, joissa on RAM-muistia alkaen 2 Gt. Verkkoantureille riittää jopa 512Mb. Asiakasosuus on yleensä lähes nolla. (Muovipussi okerruptate painaa 26 kt, mutta vaatii Python3:n ja vakiokirjastot). Asiakas käyttää cron-skriptiä, joten sillä ei ole jatkuvaa muistinkulutusta. Seuraamistamme koneista meillä on antureita (superhalpa VPS 512 Mt RAM-muistilla) ja Raspberry Pi. Se on mahdollista myös ilman asiakasosaa lähetä päivityksiä curlin kautta! (Katso alempaa)

Kun tämä otetaan huomioon - okerr, luultavasti eniten ilmaisia seurantajärjestelmä käytettävissä olevista, koska jopa käyttääksesi toista ilmaista avoimen lähdekoodin järjestelmää, kuten Zabbix tai Nagios, sinun on allokoitava resurssit (palvelin) sille, ja tämä on jo rahaa. Lisäksi jonkin verran palvelinhuoltoa tarvitaan edelleen. Okerrilla tämä osa voidaan poistaa. Tai sinun ei tarvitse poistaa sitä ja käyttää omaa palvelintasi sen mukaan, mistä pidät eniten.

API ja integrointi omaan ohjelmistoon

Yksinkertainen ja avoin arkkitehtuuri. okerrillä on melko yksinkertainen API, jonka kanssa on helppo työskennellä. Tarvitsetko 1000 indikaattoria? Yksi 3-4 rivin komentosarja tekee tämän. Tarvitseeko 1000 ilmaisinta uudelleen? Se on myös erittäin helppoa. Haluamme esimerkiksi tarkistaa kaikki HTTPS-sertifikaattimme venäläiseltä anturilta:

#!/bin/sh

for indicator in `okerrclient --api-filter sslcert`
do
    echo set location for $indicator
    okerrclient --api-set location=ru retest=1 --name $indicator
done

Voit päivittää ilmaisimen asiakasmoduulillamme, myös ilman sitä, vain curlin kautta.

# short and nice (using okerrupdate and config file)
$ okerrupdate MyIndicator OK

# only curl is enough!
$ curl -d 'textid=MyProject&name=MyIndicator&secret=MySecret&status=OK' https://bravo.okerr.com/

Voit päivittää indikaattoreita suoraan ohjelmastasi. Esimerkiksi sykesignaalien lähettäminen, jotta okerr tietää, että se on käynnissä, ja hälyttää, jos se kaatuu tai jäätyy. Muuten, okerr-komponentit tekevät juuri niin - okerr valvoo itseään ja lähes minkä tahansa moduulin ongelmat havaitaan ja luovat hälytyksen ongelmasta. (Ja tässä "melkein" tapauksessa ne on ristiintarkistettu toiselta palvelimelta)

Tässä on koodi (yksinkertaistettu) sähkebotissamme:

from okerrupdate import OkerrProject, OkerrExc

op = OkerrProject()
uptimei = op.indicator("{}:telebot_uptime".format(hostname))
...
uptimei.update('OK', 'pid: {} Uptime: {} cmds: {}'.format(
        os.getpid(), dhms(uptime), commands_cnt))

Python-ohjelmien indikaattoreiden päivittämistä varten on kirjasto okerruptate, muilla kielillä ei ole kirjastoja, mutta voit joko kutsua okerrupdate-komentosarjan tai tehdä HTTP-pyynnön okerr-palvelimelle.

Kuinka okerr auttaa meitä

Okerr muutti elämämme. Todellakin. Ehkä toinen valvontajärjestelmä voisi tehdä samoin, mutta okerrin kanssa työskentely on meille helppoa ja yksinkertaista ja siinä on kaikki tarvitsemamme toiminnot (lisäsimme sen, mitä sillä ei ollut). Muuten, jos joitain ominaisuuksia puuttuu, kysy ja lisään ne (en lupaa, mutta haluan, että okerr on paras seurantajärjestelmä pienille ja keskisuurille projekteille). Tai vielä parempaa, lisää se itse – se on helppoa.

Onnistuimme elämään periaatteella "Opi kerrasta kaikista ongelmista". Jos yhtäkkiä ilmenee ongelma, josta emme ole oppineet okerristä, lisäämme okerriin shekin. (tässä tapauksessa "me" tarkoitan meitä järjestelmän käyttäjinä, en yhteiskehittäjiä). Aluksi tämä oli yleistä, mutta nyt siitä on tullut erittäin harvinaista.

seuranta

Okerrin kautta valvomme lokikokoja kaikilla palvelimilla. Tukin jokaista riviä on tietysti mahdotonta lukea ajatuksella silmin, mutta pelkkä kasvunopeuden seuraaminen antaa jo paljon. Tämän avulla löysimme roskapostin ja brute force -salasanahaun, ja kun jotkut sovellukset "menevät hulluiksi", jokin ei toimi niille ja he toistavat sen uudestaan ​​​​ja uudestaan ​​(joka kerta lisäämällä pari riviä lokiin ).

SSL-sertifikaatit. Melkein heti käynnistyksen jälkeen LecEncrypt asiakkaamme alkoi tarjota ilmaisia ​​SSL-varmenteita asiakkailleen (noin tuhat). Ja se osoittautui pelkkää helvettiä hallinnolle! Tosiasia on, että sivustot ovat "eläviä", asiakkaat pyytävät heitä ajoittain tekemään jotain, ohjelmoijat tekevät sen. He voivat siirtää sivuston täysin vapaasti esimerkiksi toiseen DocumentRootiin. Tai lisää ehdoton uudelleenkirjoitus virtualhost-kokoonpanoon. Luonnollisesti tämän jälkeen varmenteiden automaattinen uusiminen katkeaa. Nyt meillä on kaikki SSL-isännät lisätty okerriin automaattisesti toisen hyödyllisen apuohjelman kautta paketista a2conf. Aloitetaan vain a2okerr.py — ja jos palvelimelle ilmestyy useita uusia sivustoja, ne näkyvät automaattisesti okerrissä. Jos yhtäkkiä jostain syystä sertifikaattia ei uusita, kolme viikkoa ennen sertifikaatin voimassaolon päättymistä, olemme tiedossa ja selvitämme, miksi sitä ei päivitetä, tällainen koira. a2certbot.py samasta paketista - se auttaa paljon tässä (tarkistaa heti todennäköisemmät ongelmat - ja kirjoittaa tarkastetun hyvin ja missä todennäköisimmin on ongelma).

Seuraamme kaikkien verkkotunnustemme vanhenemispäivää. Ja kaikki postipalvelimemme, jotka lähettävät sähköpostia, tarkistetaan yli 50 eri mustalla listalla. (Ja joskus ne putoavat niihin). Tiesitkö muuten, että myös Googlen sähköpostipalvelimet ovat mustalla listalla? Lisäsimme mail-wr1-f54.google.com valvotuille palvelimille vain itsetestauksen vuoksi, ja se on edelleen SORBS:n mustalla listalla! (Tämä on noin "roskapostittajien vastaisten" arvo)

Varmuuskopiot - Kirjoitin jo yllä, kuinka helppoa on seurata niitä okerrin avulla. Mutta seuraamme sekä uusimpia varmuuskopioita palvelimellamme että (käyttäen erillistä okerr-apuohjelmaa) Amazon Glacieriin ladattavia varmuuskopioita. Ja kyllä, ongelmia tulee silloin tällöin. Ei ihme, että he katsoivat.

Käytämme eskalaatioindikaattoria. Se näyttää, jos jotakin ongelmaa ei ole korjattu pitkään aikaan. Ja minä itse, kun ratkaisen joitain ongelmia, voin joskus unohtaa ne. Eskalointi on hyvä muistutus, vaikka tarkkailet itseäsi.

Kaiken kaikkiaan uskon, että työmme laatu on parantunut suuruusluokkaa. Seisonta-aikoja ei juuri ole (tai asiakas ei ehdi huomata sitä. Tshh!), kun taas työn määrä on pienentynyt ja työolot rauhoittuneet. Olemme siirtyneet hätätyöstä teippausreikien paikkaustyöstä rauhalliseen ja mitattuun työhön, jolloin monet ongelmat ennakoidaan etukäteen ja niiden ennaltaehkäisyyn on aikaa. Myös sattuneet ongelmat ovat helpottuneet korjaamaan: ensinnäkin saamme niistä selvää ennen kuin asiakkaat panikoivat, ja toiseksi usein käy niin, että ongelma liittyy viimeaikaiseen työhön (kun tein yhtä asiaa, rikki toista) - joten se on kuuma Jälkien on helpompi käsitellä sitä.

Mutta oli toinenkin tapaus...

Tiesitkö, että suositussa Debian 9:ssä (Stretch) niin suosittu paketti kuin phpmyadmin on edelleen (monien kuukausien ajan!) haavoittuvaisessa tilassa? (CVE-2019-6798). Kun haavoittuvuus ilmestyi, peitimme sen nopeasti eri tavoilla. Mutta asetin okerrin turvaseurantasivun valvonnan tietääkseni milloin "kaunis" ratkaisu tulee ulos (sisällön SHA1-summan kautta). Ilmaisin nykisi minua useita kertoja, sivu vaihtui, mutta kuten näette, se ei silti (tammikuusta 2019 lähtien!) osoita, että ongelma olisi ratkaistu. Ehkä joku muuten tietää mikä ongelma on, että niin tärkeä paketti on edelleen haavoittuvainen yli vuoden?

Toinen kerta samanlaisessa tilanteessa: SSH:n haavoittuvuuden jälkeen oli tarpeen päivittää kaikki palvelimet. Ja kun asetat tehtävän, sinun on valvottava sen suorittamista. (Alaisten taipumus ymmärtää väärin, unohtaa, hämmentyä ja tehdä virheitä). Siksi lisäsimme ensin SSH-version tarkistuksen okerriin kaikilla palvelimilla ja okerrin kautta varmistimme, että päivitykset on otettu käyttöön kaikilla palvelimilla. (Kätevä! Valitsin tämän tyyppisen ilmaisimen, ja näet heti, millä palvelimella on mikä versio). Kun olimme varmoja, että tehtävä on suoritettu kaikilla palvelimilla, poistimme ilmaisimet.

Pari kertaa on ollut tilanne, jossa tietty ongelma ilmaantuu ja menee sitten ohi itsestään. (luultavasti kaikille tuttua?). Kun huomaat, kun tarkistat – eikä mitään tarkistettavaa ole – kaikki toimii jo hyvin. Mutta sitten se taas katkeaa. Näin kävi esimerkiksi Amazon Marketplaceen (MWS) ladatuille tuotteille. Jossain vaiheessa ladattu varasto oli väärä (väärät tavaramäärät ja väärät hinnat). Selvitimme sen. Mutta sen selvittämiseksi oli tärkeää saada ongelma heti selville. Valitettavasti MWS, kuten kaikki Amazon-palvelut, on hieman hidas, joten viivettä oli aina, mutta silti pystyimme ainakin karkeasti ymmärtämään yhteyden ongelman ja sen aiheuttavien komentosarjojen välillä (teimme tarkistuksen, jumissa se okerrille ja tarkisti sen heti saatuaan hälytyksen).

Mielenkiintoisen kotelon lisäsi kokoelmaan hiljattain iso ja kallis eurooppalainen isännöitsijä, jota asiakkaamme käyttää. Yhtäkkiä KAIKKI palvelimemme katosivat tutkasta! Ensin asiakas itse (nopeammin kuin okerra!) huomasi, että hänen työskentelypaikkansa ei avautunut ja teki siitä lipun. Mutta ei vain yksi sivusto, vaan ne kaikki! (Natasha, pudotimme kaiken!). Täällä Okerr alkoi lähettää pitkiä jalkakääreitä kaikkien hänelle syttyvien merkkivalojen kanssa. Paniikki, paniikki, juoksemme ympyröitä (mitä muuta voimme tehdä?). Sitten kaikki nousi. Kävi ilmi, että konesalissa oli rutiinihuoltoa (kerran monessa vuodessa) ja tietysti meitä olisi pitänyt varoittaa. Mutta heille tapahtui jonkinlainen ongelma, eivätkä he varoittaneet meitä. No, enemmän sydänkohtauksia, vähemmän sydänkohtauksia. Mutta kun kaikki on palautettu, sinun on tarkistettava kaikki! En voi kuvitella kuinka tekisin sen käsilläni. Okerr testasi kaiken muutamassa minuutissa. Kävi ilmi, että suurin osa palvelimista oli yksinkertaisesti väliaikaisesti poissa käytöstä, mutta ne toimivat. Jotkut olivat ylikuormitettuja, mutta myös nousivat pystyyn niin kuin piti. Kaikista menetyksistä menetimme kaksi varmuuskopiota, jotka kruunun mukaan olisi pitänyt luoda ja ladata tämän täyden banaanin ollessa käynnissä. En edes vaivautunut luomaan niitä, vain päivää myöhemmin saapui varoitus, että kaikki oli kunnossa, varmuuskopiot olivat ilmestyneet. Pidän tästä esimerkistä todella paljon, koska okerr osoittautui erittäin hyödylliseksi tilanteessa, jota emme olleet edes ajatelleet etukäteen, mutta se on seurannan tarkoitus - vastustaa arvaamatonta.

Okerr-antureille käytämme halvinta mahdollista isännöintiä (jos laatu ja luotettavuus eivät ole tärkeitä, ne vakuuttavat toisensa). Joten löysimme äskettäin erittäin hyvän isännöinnin ja erittäin halvan, vertailuarvot ovat mahtavia. Mutta... joskus käy ilmi, että virtuaalikoneen lähtevät yhteydet tehdään toisesta (naapuri-) IP:stä. Ihmeitä. Client_ip-moduulin kanssa https://diagnostic.opendns.com/myip saa väärän IP:n. Ja indikaattorin palvelinlokeista selviää, että päivitys tuli myös tältä naapuri-IP:ltä. Hoidetaan tuki nyt. Hyvä, että huomasimme tämän rauhan aikana. Mutta esimerkiksi usein tapahtuu, että pääsy rekisteröidään IP-valkoisen listan mukaan - ja jos palvelin joskus vilkkuu tällä tavalla lyhyen aikaa - voit yrittää saada tämän ongelman kiinni hyvin pitkään.

No, vielä yksi asia - koska puhumme VPS-isännöinnistä - käytämme aina edullisia (hetzner, ovh, scaleway). Pidän siitä todella niin vertailuarvojen kuin vakauden suhteen. Käytämme myös paljon kalliimpaa Amazon EC2:ta muihin projekteihin. Joten, kiitos okerrin, meillä on oma tietoinen mielipiteemme. Molemmat putoavat. Enkä sanoisi, että pitkän havaintoidemme aikana halvat hosting-palvelut, kuten hetzner, osoittautuivat huomattavasti vähemmän vakaiksi kuin EC2. Siksi, jos et ole sidottu muihin Amazonin ominaisuuksiin, miksi maksaa enemmän? 🙂

Mitä seuraavaksi?

Jos en ole vielä tässä vaiheessa pelottanut sinua pois Okerrista, kokeile sitä! Voit siirtyä suoraan tähän linkkiin okerr demotili (Klikkaa nyt!) Muista kuitenkin, että kaikille on vain yksi demotili, joten jos teet jotain, joku muu samalla tilillä voi häiritä sinua samanaikaisesti. Tai (parempi) rekisteröidy linkin kautta offsite okerr - kaikki on yksinkertaista, ilman tekstiviestejä. Jos et halua käyttää oikeaa sähköpostiasi, voit käyttää kertakäyttöistä sähköpostia, kuten mailinator (suosittelen getnada.com). Tällaiset tilit voidaan poistaa ajan myötä, mutta ne ovat hyviä testaukseen.

Ilmoittautumisen jälkeen sinua pyydetään koulutukseen (suorita useita ei kovin vaikeita harjoitustehtäviä). Alkurajoitukset ovat hyvin pienet, mutta koulutukseen tai yhdelle palvelimelle ne riittävät. Koulutuksen päätyttyä rajoja (esimerkiksi indikaattoreiden enimmäismäärää) nostetaan.

Asiakirjoista - ensinnäkin WIKI palvelinpuolella ja asiakkaalla (okerrupdate wiki). Mutta jos jokin on epäselvää, kirjoita osoitteeseen support (at) okerr.com tai jätä lippu - yritämme ratkaista kaiken nopeasti.

Jos käytät sitä vakavasti ja nämä korotetut limiitit eivät riitä, kirjoita tukeen, niin korotamme sitä (ilmaiseksi).

Haluatko asentaa okerr-palvelimen palvelimellesi? Tässä okerr-dev-arkisto. Suosittelemme asentamista puhtaaseen virtuaalikoneeseen, jonka jälkeen voit tehdä sen yksinkertaisesti asennusskriptillä. Virtuaalikoneesi - ei rajoituksia :-). No, jälleen kerran, jos jotain tapahtuu, yritämme aina auttaa.

Haluamme tämän projektin lähtevän vauhtiin, jotta maailma muuttuu luotettavammaksi meidän ansiosta. Ilmaisten ohjelmistojen ja palveluiden ansiosta maailma on muuttunut ystävällisemmäksi ja kehittyy dynaamisemmin. Lähteet voidaan tallentaa ilmaiseen githubiin, ja sähköpostiin voit käyttää ilmaista gmailia. Käytämme ilmaiseksi freshworks tueksi. Tätä varten sinun ei tarvitse maksaa palvelimista, sinun ei tarvitse ladata ja määrittää, eikä sinun tarvitse ratkaista erilaisia ​​toimintaongelmia. Jokaisella uudella projektilla, jokaisella tiimillä on välittömästi sähköposti, arkistot ja CRM. Ja kaikki tämä on erittäin laadukasta ja ilmaista ja välittömästi. Haluamme, että seurantaan on sama - pienet yritykset ja projektit voisivat käyttää okerria ilmaiseksi ja jo syntymä- ja kasvuvaiheessa on aikuisten vakavien projektien luotettavuutta.

Lähde: will.com