Kaks aastat tagasi tegin juba postituse Lihtne failover veebisaidile rääkinud okerr. Praegu on projektil toimunud mõningane areng ning ma olen avaldanud okerri serveri osa lähtekoodi all avatud litsentsiga, seetõttu otsustasin kirjutada sellele väikesele ülevaatele habres.

[ täissuuruses ]

Kellele see võib huvi pakkuda

See võib huvi pakkuda, kui töötate väikese meeskonnaga või isegi üksi. Teil ei ole jälgimist ja te ei ole kindel, kas see on tõesti vajalik. Või olete proovinud mõnda populaarset tõsist jälgimist „suurtele poistele”, kuid see ei ole teid kuidagi kaasahaaranud või töötab peaaegu vaikimisi konfiguratsioonis ning ei ole teie elu palju muutnud. Ja ka — kui te tõeliselt ei plaani määrata terve töötaja (või isegi osakonna), et pühendada vähemalt paar tundi päevas jälgimise dashaardi jälgimisele või selle seadistamisele.

Milline on okerra eripära

Järgmises osas näitan huvitavaid omadusi okerra, mis eristavad seda mõnest muust jälgimisest.

Okerr on hübriidne jälgimine

Sisemise jälgimise korral töötab vaadeldavates masinates "agent", mis edastab andmeid jälgimisse Serverisse (näiteks vaba ruumi kettal). Välist jälgimise korral teostab server võrgu kaudu kontrolle (näiteks ping või veebisaidi kättesaadavus). Igal meetodil on omad piirangud. Okerr kasutab mõlemat varianti. Kontrollid serverite sees viiakse läbi väga kerge (30Kb) agendi või teie enda skriptide ja rakenduste kaudu, võrgu kontrollid aga läbi okerr'i sensorite erinevates riikides.

okerr ei ole ainult tarkvara, vaid ka teenus.

Iga jälgimise serveri osa on suur ja keeruline, selle installeerimine ja seadistamine on keeruline ning see nõuab ressursse. Okerr'i abil saate paigaldada oma jälgimisse serveri (see on tasuta ja avatud lähtekoodiga), aga võite lihtsalt kasutada ainult kliendi osa ja kasutada meie serveri teenust. Samuti tasuta.

Kui jälgimine suudab kompenseerida usaldusväärsuse puudujääki serverites ja rakendustes, tekib filosoofiline küsimus — kes valvab valvurit? Kuidas saab jälgimine teavitada meid probleemist, kui see ise on mõne põhjuse tõttu „surnud“, eraldi või koos teiste teie ressurssidega (näiteks andmekeskuse kanal on välja kukkunud)? Välise teenuse okerr kasutamisel lahendatakse see probleem — te saate hoiatuse isegi siis, kui kogu andmekeskus koos teie serveritega on elektrita või on rünnaku all zombide poolt.

Muidugi, on olemas risk, et okerr server ise ei ole kergesti kättesaadav, see on tõsi (nagu teada, saadakse 90% usaldusväärsusest alati lihtsalt ja „tasuta“, 99% — minimaalse vaevaga, ja iga järgmine üheksa on eksponentsiaalselt keerulisem). Kuid, esiteks on selle tõenäosus madalam, ja teiseks võib probleem jääda märkamatuks ainult siis, kui see langeb kokku probleemidega meie serverites. Kui meil on usaldusväärsus 99,9% ja teil on 99,9% (mitte sugugi kõrgemad numbrid), siis on märkamatuks jääva tõrke tõenäosus 0,1% 0,1% = 0,0001%. Endale kolme üheksa lisamine usaldusväärsuses peaaegu ilma vaevata ja kuludeta — see on väga hea!

Veel teine eelis monitooringu teenusena on, et hostingu pakkuja või veebistuudio võib seadistada oma serveri okerr ja pakkuda klientidele ligipääsu tasulise või tasuta lisateenusena. Teie konkurentidel on lihtsalt hosting ja saidid — teil on aga usaldusväärne hosting koos monitooringuga.

Okerr — see on indikaatorite maailm

Indikaator on nagu „lamp”. Tal on kaks peamist olekut — roheline (OK) või punane (ERR). Projektis on palju gruppeeritud (näiteks serverite kaupa) indikaatoreid. Projekti avalehelt näete kohe kas kõik on roheline (siis võib sulgeda) või midagi särab punaselt ja vajab parandamist. Nende olekute vahel liikumisel saadetakse teavitus. Üks kord ööpäevas, kui seadistate — saadetakse projektist kokkuvõte.

Iga okerr indikaator sisaldab sisseehitatud tingimusi, mille alusel ta muudab olekut (Zabbixis nimetatakse seda triggeriks). Näiteks peab koormuse keskmine olema mitte rohkem kui 2 (loomulikult on see seadistatav). Ja iga sisemise kontrolli (koormuse keskmine, vabade kettaruumi jne) jaoks on watchdog. Kui mingil põhjusel ei saa me määratud ajaks edukat kinnitust, registreeritakse viga ja saadetakse teade.

Meie tavapärane tööplaan on hommikune e-kirjade kontrollimine, seal vaatame teiste seas üle kokkuvõtte (selle ajastame töö algusesse). Kui seal on kõik korras, toimetame edasi muude oluliste asjadega (aga saame usaldusväärsuse huvides kiirelt okerr juhtehku vaadata, et veenduda, et ka sel hetkel on kõik roheline). Kui tuleb teade, siis reageerime.

Muidugi on võimalik lihtsalt hoida „teavitavaid“ indikaatoreid (et näha võrgu seisundit jälgimise kaudu), kuid kõik on tehtud nii, et oleks lihtne, kerge ja kiire luua indikaatoreid automaatse jälgimise ja teavituste saatmise jaoks.

Mõte, miks te okerr'i seadistate, seisneb häired selles, et saate minutiga luua indikaatori. See võib aasta jooksul lihtsalt 'magada', vastu võttes uuendusi, ja kui aasta pärast teil midagi katki läheb, süttib see ja saadab häire. Üks minut, mille kulutasite indikaatori loomisele, tasus end ära — saite probleemist kohe teada, enne kui keegi teine seda märkab. Võib-olla olete isegi selle enne ära parandatud, kui keegi märkab. Kiiresti püstitatud ei loeta langenuks!

Ohutus

Oleks kahju, kui seate jälgimise usaldusväärsuse suurendamiseks, kuid tulemusena ründavad teid läbi selle võrgu, ja erinevate jälgimistööriistade võrgu haavatavusi on üsna palju (Zabbix, Nagios).

Agendi (okerrmod paketist okerrupdate), mis töötab süsteemis — see ei ole võrgu server, vaid klient. Seetõttu ei ole jälgitava serveri peal lisaportaale avatud, klient töötab kergesti tulemüüri või NAT'i taga ja seda on väga raske (ütleksin, et 'võimatu') võrgu kaudu häkkida, kuna see põhimõtteliselt ei kuula võrgu soket.

Täielik jälgimise katvus

Meil on nüüd reegel — me saame kõik tehnilised probleemid teada okerrist. Kui reegel peaks rikkuma (okerr ei teatanud selle eelseisvast saabumisest (kui see on võimalik) või et see on juba saabunud) — lisame okerrisse kontrollid.

Välish kontrollid

Üsna tüüpiline komplekt:

• ping
• http staatus
• SSL tunnistuse kehtivuse ja värskuse kontroll (hoiatab, kui aeg hakkab lõppema)
• avatud TCP port ja banner sellel
• http grep (lehe [mitte] peaks sisaldama teatud teksti)
• sha1 hash, et lehekülje muutust tuvastada.
• DNS (DNS kirje peab olema kindla väärtusega)
• WHOIS (hoiatab, kui domeen hakkab peagi aeguma)
• Antispam DNSBL (kontrollib hosti samal ajal 50+ rämpspostiblokeerimise nimekirjade järgi)

Sisemised kontrollid

Samuti, üsna tüüpiline komplekt (aga kergesti laiendatav).

• df (vaba ruum kettal)
• koormus keskmine
• opentcp (avatud kuulavad TCP sokid — teavitab, kui midagi on käivitunud või kukkunud)
• uptime — lihtsalt serveri tööaeg. Teavitab, kui see on vähenenud (st. server taaskäivitati)
• client_ip
• dirsize — me kasutame seda, et jälgida, kui meie rootfs virtuaalid ületavad lubatud suuruse, ilma et kehtestaksime karmid piirangud, ja jälgime kasutajate kodukataloogide suurusi.
• empty ja nonempty — jälgivad faile, mis peaksid olema tühjad (või mitte tühjad). Näiteks, serveri error log okerr — peaks olema tühi, ning kui seal on vähemalt üks rida, saan teate ja kontrollin. Aga mail.log meiliserveris ei tohi olla TÜHI (N minuti pärast pärast rotatsiooni). Mõnikord on see meil tühi olnud pärast süsteemi uuendamist, kui logrotate ei suutnud rsyslogi õigesti taaskäivitada.
• linecount — faili ridade arv (nagu wc -l). Me kasutame seda pehme asendajana empty jaoks, kui error log siiski võib kasvada, aga ainult aeglaselt (meil, näiteks, googlebot üritab siseneda mõningatele suletud lehtedele). Piirang on 2 rida 20 minuti jooksul. Kui see on kõrgem — tuleb häire.

Huvitavad sisemised kontrollid

Kui olete siiani lugenud „diagonaalis“, siis nüüd on huvitavam lugeda tähelepanelikumalt.

backups

Jälgib varukoopiaid kataloogis. Meie varukoopiafailid kannavad nimesid nagu „ServerName-20200530.tar.gz“. Iga serveri jaoks luuakse okerris indikaator ServerName-DATE.tar.gz (tõeline kuupäev asendatakse stringiga „DATE“). Jälgitakse nii värske varukoopia olemasolu kui ka selle suurust (näiteks ei tohi see olla väiksem kui 90% eelmisest varukoopiast).

Mida peab tegema, et uus varukoopia hakkaks jälgima, pärast seda kui oleme selle looma hakanud ja sellesse katalooge paigutanud? Mitte midagi! See on väga mugav lähenemine, kui ei pea midagi tegema, sest:

• Midagi tegemine — on üsna kiire, see säästab aega.
• Raske on unustada midagi mitte teha.
• Raske on midagi mitte teha valesti, eksimuseta. Mitte midagi tegemine — on kõige usaldusväärsem meetod.

Kui äkki ei hakka ilmuma uusi varukoopiafaile — tuleb häire. Kui olete näiteks välja lülitanud ühe serveritest, mille varukoopiaid ei peaks enam olema — peate indikaatori kustutama (kas veebiliidese kaudu või shelli API kaudu).

maxfilesz

Jälgib suurimaid faile (tavaliselt: /var/log/*). See võimaldab tabada ettenägematuid probleeme, näiteks paroolide üritusi või spämmimist serveri kaudu.

runstatus/runline

Need kaht olulist proxy moodulit, et käivitada teisi programme serveris. Runstatus edastab programmi väljundkoodi indikaatorisse. Näiteks ei ole okerr'is (mitte vajalik) moodulit, mis kontrollib, kas systemd teenused töötavad. Seda teostatakse runstatus'i kaudu (vt allpool). Runline edastab serverisse rea, mille programm annab. Näiteks, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" konfiguratsioonis Runline meie serveris loob indikaatori servername:temp koos protsessori temperatuuriga.

sql

Täidab numbrilise päringu MySQL-le ja edastab tulemuse indikaatorisse. Lihtsas olukorras võib teha näiteks 'SELECT 1' — see kontrollib, et andmebaas töötab üldiselt.

Aga palju huvitavam rakendus on näiteks jälgida tellimuste arvu veebipoes. Kui tead, et tunnis on sul 100 tellimust, saad seada miinimumpiiriks 100 või 80. Siis, kui äkki müük järsult langeb — saad häire, ja saad aru saada.

Pane tähele — pole tähtis, mis ettearvamatu põhjus selle jaoks on:

• Server on lihtsalt kättesaamatu (elektrit ei ole või võrku ei ole), ja häire tuli sellest, et indikaator "aegus".
• Server on occasion experiences high load, operates slowly or has packet loss, leading to user dissatisfaction and abandonment of purchases.
• The server has landed on spam lists, resulting in emails being rejected, preventing user registrations.
• The budget for the advertising campaign has run out, and the banners are not displaying.

There can be countless reasons, and it's impossible to foresee all of them in advance; tracking them technically can be complex. However, it's possible to conveniently monitor the ultimate parameter (orders) and determine from them whether the situation seems suspicious and warrants further investigation.

Logical indicators

Enables the use of logical expressions (Python syntax) through the module evalidate(article on Habr). Data from the project and its indicators are available for the expression. For example, in the chapter on SQL checks above, you might have noticed a weakness — during the day we can have 100 sales an hour, but at night it's 20, and that's normal, not a problem. What to do? The indicator will panic constantly at night.

Saate luua kaks indikaatorit, päevane ja öine. Mõlemad teha 'vaikseks' (nad ei saadeta teateid). Ja luua loogiline indikaator, mis nõuab, et enne kella 20:00 oleks päevane indikaator korras, ja pärast kella 20:00 piisab, kui öine indikaator oleks OK.

Teine näide loogilise indikaatori kasutamisest on eskaleerimine. Näiteks projektijuht loobub häirete teavitamisest (tal pole seda vaja, adminnid peavad reageerima tavapärastele probleemidele), kuid liitub loogilise indikaatori teavitustega, mis muutub punaseks, kui ükskõik milline indikaator projektis ei ole määratud ajaks parandatud.

Veelgi enam, on võimalik määrata lubatud tööaeg, näiteks kella 3-5 hommikul. Meid ei huvita, kui serverid ja saidid sel ajal 'kukuvad'. Kuid kell 5:00 peavad nad töötama. Kui nad ei tööta mistahes muul ajal — häire. Samuti võimaldab loogiline indikaator arvesse võtta serverite varundamist. Kui teil on 5 veebiserverit, võivad adminnid välja lülitada 1-2 serverit igal ajal. Kuid kui lahingus on vähem kui 3 5 serverist — tuleb häire.

Ülaltoodud näited ei ole okerri funktsioonid ega mingid funktsioonid, mida tuleb aktiveerida ja konfigureerida. Okerris nende funktsioonide pole, kuid seal on loogikamoodul, mis võimaldab seda funktsionaalsust rakendada (nagu programmeerimiskeeles — kui meil on aritmeetilised operaatorid, ei vaja me keelt eraldi funktsiooni 20% KM arvutamiseks, selle saate alati ise oma vajaduste järgi luua).

Loogiline indikaator on ilmselt üks väheseid suhteliselt keerulisi teemasid okerri maailmas, kuid hea uudis on see, et te ei pea neid valdama, kuni see ei osutu vajalikuks. Samas laiendavad need väga oluliselt võimalusi, hoides süsteemi üldiselt piisavalt lihtsana.

Oma kontrollide lisamine

Tahaksin tõesti rõhutada, et okerr ei ole tuhat valmis kontrolli kõikide elusituatsioonide jaoks, vaid vastupidi — see on eelkõige lihtne mootor, mis pakub lihtsat võimalust luua oma kontrollid. Oma kontrollide loomine okerris ei ole ülesanne häkkeritele, süsteemi kaasautoritele või isegi arenenud kasutajatele, vaid teostatav ülesanne igale adminile, kes kuu aega tagasi esmakordselt Linuxi paigaldas.

Minimaalsete kontrollide läbiviimine toimub mooduli kaudu runstatus:

See rida konfiguratsioonis runstatus teavitab, kui äkki /bin/true ei käivitu või annab tagasi mitte 0.

true_OK=/bin/true

Ainult üks rida — ja olemegi juba veidi laiendanud okerr funktsionaalsust.

Isegi selline kontroll — omab juba oma väärtust: kui teie server äkki kukub, siis vastav indikaator serveris okerr ei uuene õigel ajal, ja aja möödudes tekib alert.

See kontroll teavitab, et server apache2 on kukkunud (noh, igaks juhuks…):

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

Nii et, kui te oskate vähemalt ühte programmeerimiskeelt või saate kirjutada shell-skripte — siis juba võite lisada oma kontrollid.

Raskem — saate kirjutada (igal keelel) oma mooduli okerrmod jaoks. Lihtsaimal juhul näeb see välja nii:

#!/usr/bin/python3

print("STATUS: OK")

Ei ole ju väga keeruline? Moodul peab tegema kontrolli ja andma tulemused STDOUT. Raskem moodul annab näiteks sellist:

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

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

See on korraga mitu indikaatorit (eraldatud tühja reaga), vajadusel loob neid, määrab kontrollimise üksikasjad ja sildi, mille järgi on juhitabelis lihtne leida soovitud indikaatoreid.

Telegram

On olemas Telegrami bot @OkerrBot. Te ei pea oma telefoni eraldi rakendustega üle koormama (ma ise ei armasta, et Pjatjorikule on üks rakendus kaardiga, Lenta jaoks teine, MTS-i jaoks kolmas ja nii edasi). Üks Telegram on piisav. Telegrami kaudu saab kohe saada teateid ja kontrollida projekti olekut ning anda käsu kõikide probleemsete indikaatorite uuesti kontrollimiseks. Astudes teater/lenukist välja, kui kaks tundi ei olnud kät pulsil, sisse lülitatud, vajutada ühte nuppu чат-ботis ja veenduda, et kõik on korras.

Olekulehed

Meie ajal on olekuhed peaaegu kohustuslikud iga äri jaoks, millel on IT, vastutustundlik suhtumine usaldusväärsusesse ja kes austab oma kliente/kasutajaid.

Kujutage ette olukorda — kasutaja soovib midagi teha, vaadata informatsiooni või tellimust vormistada, kuid midagi ei tööta. Ta ei tea, mis toimub, kellel on probleem ja millal see lahendatakse. Kas teie firma veebisait on lihtsalt maas? Või on see läbi kukkunud kuus kuud tagasi ja taastatakse kahe aasta jooksul? Aga külmkapp tuleb osta just nüüd, see on juba ostukorvis… Ja hoopis teine asi on see, kui inimene näeb, et teil on midagi valesti (kuigi on vähemalt selge, et probleem ei ole tema poolel), et probleem on avastatud, et te juba tegelete sellega ning võib-olla olete isegi kirjutanud umbkaudse ajakava parandamiseks. Kasutaja saab tellida ja saada e-postile teate, kui probleem on lahendatud ja saab teha seda, mida ta soovis (osta külmkapp).

Probleemid, seisakud — neid juhtub kõigil. Kuid kasutajad ja partnerid usaldavad rohkem neid, kes on läbipaistvamad ja vastutustundlikumad selle suhtes.

Siin on ülevaade 10 teisest projektist, mis võimaldavad luua staatuse lehti. Siin on näited, kuidas need lehed välja näevad projektides Python ja Dropbox. Staatuse leht okerr.

Failover

Ette muuta seda artiklit veel pikemaks, viitan taas oma varasemale artiklile — Lihtne failover veebisaidile . Kui suudate luua varundusserveri, siis failover'i kasutamine tähendab, et teil ei ole sisuliselt pikka seisakut — kohe, kui probleem tuvastatakse, suunatakse kasutajad automaatselt töötavale varu-serverile. Tahan öelda, et see on väga huvitav ja eriline funktsioon, mida leidub harva.

Madalaid süsteeminõudeid

Okerr-serverite jaoks kasutame masinate RAM-i alates 2GB. Võrgusensorite jaoks piisab isegi 512MB-st. Klientide osa on peaaegu olematu. (Pakett okerrupdate kaalub 26 Kb, kuid vajab Python3 ja standardteeke). Klient käivitatakse krontasku kaudu, seega on selle pidev mälutarbimine null. Meie jälgitavate masinate seas on sensoreid (üliodavad VPS-id 512MB RAM-iga) ja Raspberry Pi. Võimalik on isegi edastada värskendusi ilma kliendi osata curl'i kaudu! (vt allpool)

Seda arvesse võttes — okerr on tõenäoliselt kõige tasuta jälgimisseade, mille saab valida, sest isegi kui kasutada teist tasuta avatud lähtekoodiga süsteemi nagu Zabbix või Nagios, peab sellele määrama ressursid (server), ja see on juba kulutused. Lisaks on vajalik serveri hooldus. Okerriga saab selle osa kõrvaldada. Võite ka mitte kõrvaldada ja kasutada enda serverit — olenevalt sellest, kuidas teile sobib.

API ja integreerimine oma tarkvarasse

Lihtne ja avatud arhitektuur. Okerril on üsna lihtne API, millega on lihtne töötada. Kas peate looma 1000 indikaatorit? Ühe shell-skripti abil 3-4 rida teeb selle ära. Kas peate ümber seadistama 1000 indikaatorit? See on samuti väga lihtne. Näiteks tahame kontrollida kõiki meie HTTPS-sertifikaate just Venemaa sensori kaudu:

#!/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

Indikaatorit saab uuendada nii, kasutades meie kliendimoodulit, kui ka ilma selleta, lihtsalt curl'i kaudu.

# 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/

Indikaatoreid saab uuendada otse oma programmist. Näiteks saates heartbeat signaale, et okerr teaks, et see on käivitatud, ja tõsta alarmi, kui see on kokku kukkunud või hangunud. Muide, okerr komponendid teevad just seda — okerr jälgib end ise, ja probleemid peaaegu igas moodulis tuvastatakse ning genereerivad probleemiteate. (Ja selle 'peaaegu' puhul — nad kontrollitakse risttsekkimisega teiselt serverilt)

Siin on selline kood (lihtsustatud) meie Telegrami botis:

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 programmidest indikaatorite uuendamiseks on olemas raamatukogu okerrupdate, teiste programmeerimiskeelte jaoks raamatukogud puuduvad, kuid saate kas käivitada skripti okerrupdate või teha HTTP päringu okerr serverisse.

Kuidas okerr meid aitab

Okerr on põhjalikult muutnud meie elu. Tõeliselt. Võib-olla suudaks mõni teine seire süsteem samuti, kuid okerriga on meil lihtne ja mugav töötada ning selles on kõik vajalikud funktsioonid (need, mida polnud — oleme ise lisanud). Muide, kui mõnda funktsiooni pole — küsige, ja ma lisame selle (ma ei lubanud, kuid tahan, et okerr oleks parim seiresüsteem väikeste ja keskmise suurusega projektide jaoks). Või veel parem, lisage ise — see on lihtne.

Meil on õnnestunud elada põhimõttel „kõigist probleemidest teada okerrist”. Kui juhtus probleem, millest me ei kuulnud okerrist — lisame kontrolli okerrisse. (selles kontekstis mõistan „me” kui süsteemi kasutajaid, mitte kaas-arendajaid). Alguses juhtus seda tihti, kuid nüüd on see väga harv.

Jälgimine

Okerr kaudu jälgime logide mahtusid kõigis serverites. Iga logirida silmadega läbi lugeda on loomulikult võimatu, kuid kasvukiirusest jälgimine annab juba palju. Selle kaudu oleme avastanud nii rämpsposti saatmist kui ka bruteforce paroolide katsetamist, ja ka siis, kui mõned rakendused "kaotavad kontrolli" – nad ei suuda midagi teha ja korrake seda ikka ja jälle (iga kord lisades paar rida logisse).

SSL sertifikaadid. Peaaegu kohe pärast käivitamist LetsEncrypt algas meie kliendi tasuta SSL sertifikaatide pakkumine oma klientidele (umbes tuhat neist). Ja see osutus lihtsalt haledaks haldamiseks! Asi on selles, et veebisaidid on "elavad", kliendid küsivad aeg-ajalt, et midagi ära teha, programmid teevad. Nad võivad näiteks vabalt veebisaidi teisele DocumentRootile viia. Või lisada tingimusteta Rewrite virtuaalhosti konfiguratsiooni. Loomulikult lõhub see automaatse sertifikaatide uuendamise. Nüüd lisatakse kõik SSL hostid okerrisse automaatselt veel ühe meie kasuliku tööriista kaudu paketist a2conf. Lihtsalt käivitame a2okerr.py — ja kui serveris on mitu uut veebisaiti, siis need ilmuvad automaatselt okerrisse. Kui sertifikaadi uuendamine mingil põhjusel ebaõnnestub, siis kolme nädala jooksul enne selle aegumist — me oleme sellest teadlikud ja uurime, miks see ei uuene. a2certbot.py sama paketi seest — see aitab väga palju (kontrollib kohe kõige tõenäolisemaid probleeme ja näitab, mis on hästi kontrollitud ning kus on tõenäoliselt probleem).

Me jälgime kõigi meie domeenide aegumist. Ja kõik meie e-posti serverid, mis saadavad e-kirju, kontrollitakse ka 50+ erineva musta nimekirja vastu. (Ja mõned sisenevad nendesse). Muide, kas teadsite, et ka google'i e-posti serverid on mustades nimekirjades? Lihtsalt enesetestimise huvides lisasime mail-wr1-f54.google.com jälgitavate serverite hulka ja see on tõepoolest mustas nimekirjas SORBS! (See seondub ülevaate väärtusele «antispammerite» kohta).

Varukoopiad — seal üleval mainisin juba, kuidas neid okerriga lihtsalt jälgida. Kuid me jälgime värskeid varukoopiaid ka meie serveris ning (erineva utiliidi abil, mis kasutab okerrit) — varukoopiaid, mida me laadime Amazon Glacierisse. Ja jah — perioodiliselt esinevad probleemid. Mitte ilma põhjuseta me jälgisime.

Kasutame eskaleerimise indikaatorit. Selle abil on nähtav, kui mõni probleem on juba kaua aega lahendamata. Isegi mina, kui lahendan mingeid ülesandeid, unustan vahel neist. Eskaleerimine on hea meeldetuletus, isegi kui jälgid iseennast.

Üldiselt arvan, et meie töö kvaliteet on tõusnud järsult. Peaaegu pole kaheks ei (no või klient ei jõua seda märgata. Ainult tššš!), samas on töömaht vähenenud ja töötingimused rahulikumad. Oleme läinud hädaolukorrast, kui lappame auke teibiga, rahulikuma ja tasakaalustatumate töövormide juurde, kus paljusid probleeme ennustatakse ette ja on aega, et need ära hoida. Isegi juba juhtunud probleemide lahendamine on nüüd lihtsam: esiteks kuuleme neist enne, kui kliendid paanikat teevad, ja teiseks juhtub sageli, et probleem on seotud hiljutise tööga (kui tegin üht, rikki teise) — seega on kuumad jäljed kergem peatada.

Ja veel üks juhtum oli ...

Kas te teadsite, et populaarne Debian 9 (Stretch) on saanud tuntud paketi phpmyadmin, mis on olnud halvasti hoitud (juba mitu kuud!) haavatavaks? (CVE-2019-6798). Kui haavatavus avanes - katsetasime selle kiiresti erinevate meetoditega varjata. Kuid ma seadistasin okerr'isse jälgimise security-tracker'i lehe jaoks, et teada, millal tuleb "ilus" lahendus (SHA1 sisu summa kaudu). Mitmel korral tõmbas indikaator mind tähelepanu, leht muutus, kuid nagu näha - kuni tänaseni (alates jaanuarist 2019!) ei ole seal näidatud, et probleem on lahendatud. Võib-olla mõni teab, mis probleem seal on, et see oluline pakett on rohkem kui aasta haavatav?

Teine kord sarnases olukorras: pärast SSH haavatavust tuli kõik serverid uuendada. Ja kui seadistad ülesande - tuleb kontrollida täitmist. (Alluvad kipuvad mõistma asju valesti, unustama, segadusse minema, vigu tegema). Seetõttu lisasime kõigepealt okerr'isse SSH versiooni kontrollimise kõigis serverites ja jälgisime okerr'i kaudu, et uuendused oleksid kõigis serverites rakendatud. (Mugav! Valisin selle tüüpi indikaatori ja kohe on näha, millises serveris on milline versioon). Kui olime veendunud, et ülesanne on täidetud kõigis serverites - eemaldasime indikaatorid.

Mõned korrad on olnud olukord, kus mingi probleem ilmneb ja siis lahendub iseenesest. (ilmselt on see kõigile tuttav?). Kui sa lõpuks märkad ja kontrollima hakkad — siis on juba kõik hästi ja polegi seal enam midagi kontrollida. Kuid hiljem võib probleem jälle tagasi tulla. Meie kogesime seda näiteks toodetega, mida laadisime üles Amazon Marketplace (MWS). Ühel hetkel olid üles laaditud varud vale info (vale toodete kogus ja vale hind). Käisime selle üle. Kuid et sellest aru saada — oli oluline probleemist kohe teada saada. Kahjuks on MWS nagu kõik Amazoni teenused — natuke aeglane, seega oli alati viivitusi, ent lõpuks õnnestus meil siiski luua umbes seos probleemi ja skriptide vahel, mis seda põhjustavad (teostasime kontrolli, sidusime selle tõrkega ja kontrollisime kohe, kui häiret saime).

Huvitav juhtum, mille lisasin hiljuti oma mälestuste kausta, tuli suurelt ja kallilt Euroopa hostimiselt, mida kasutab meie klient. Ühel hetkel kadusid äkki kõik meie serverid radarilt! Alguses märkis klient ise käsitsi (kiiremini kui seadus!), et veebileht, millega ta töötas, ei avane ja tegi tiketi selle kohta. Kuid ei katkenud mitte ainult üks veebileht, vaid tegelikult kõik! (Natasha, me oleme kõik kukkunud!). Siis hakkas ka Okerr saatma pikki raporteid kõigi näidikute kohta, mis tal põlesid. Paanikapaanikana, jooksime ringi (mida muud teha?). Siis kõik tõusis jälle püsti. Selgus, et andmekeskuses olid regulatsioonitööd (üks kord mitme aasta jooksul) ja meid pidid muidugi ette hoiatama. Kuid mingisugune segadus juhtus neil ja ei hoiatatud. No, infarkt rohkem, infarkt vähem. Aga pärast kõike taastamist — peab ju kõik ümber kontrollima! Ma ei kujuta ette, kuidas ma seda käsitsi teeksin. Okerr testis kõik mõne minutiga. Selgus, et suurem osa serveritest oli lihtsalt ajutiselt kättesaamatu, kuid töötas. Mõned ülekoormati, kuid ka need tõusid tõusutsüklisse nagu vaja. Kõikide kaotuste seast — kaotasime kaks varukoopiat, mis pidid cron'i järgi tekkima ja laadima selle ajaga, mil toimus see täielik kaos. Ma isegi ei hakanud neid looma, lihtsalt 24 tunni pärast saabusid hoiatusteated, et kõik on korras, varukoopiad ilmusid. Mulle see näide väga meeldib, sest okerr osutus situatsioonis, millest me isegi eelnevalt ei mõelnud, väga kasulikuks, kuid monitorimise ülesanne ongi - seista vastu ettearvamatusele.

Okerr sensoreid arendades kasutame me võimalikult odavaid hosting'uid (seal ei ole kvaliteet ja usaldusväärsus olulised, nad katavad üksteist). Hiljuti oleme leidnud väga usaldusväärse hosting'u ja super odava hinnaga, tulemused on suurepärased. Kuid... mõnikord juhtub, et väljaminevad ühendused virtuaalserverist toimuvad teise (kõrval) IP kaudu. Imed. Moodul client_ip https://diagnostic.opendns.com/myip saab vale IP. Ja serveri logidest on näha, et uuendus tuli samuti sellelt kõrval olevalt IP-lt. Praegu selgitame seda tehnilise toega. Hea, et märkasin seda rahulikus olukorras. Kuid näiteks juhtub tihti, et juurdepääs lisatakse IP valge nimekirja — ja kui server mõnikord lühikeseks ajaks vilgub — võib selle probleemi tuvastamine võtta väga kaua aega.

Ja veel — kui juba VPS-hostingutest räägime — siis kasutame alati soodsaid (hetzner, ovh, scaleway). Nii jõudluse kui ka stabiilsuse poolest — need meeldivad väga. Kasutame ka kallimat Amazon EC2 teiste projektide jaoks. Ühesõnaga, tänu okerr-le on meil oma põhjendatud arvamus. Vaatamata sellele, et mõlemad kukuvad. Ja ma ei ütleks, et meie pikka aega kestnud jälgimise põhjal on odavad hostingud nagu hetzner oluliselt vähem stabiilsed kui EC2. Seega, kui te ei ole Amazon'i muude omadustega seotud — miks maksta rohkem? 🙂

Mis edasi?

Kui ma teid selle etapi jooksul okerr'ist veel tõsiselt ei ära hirmutanud — proovige! Otse sellel lingil saate sisse logida okerr'i demo kontole (Klõpsake kohe!). Kuid pidage meeles, et demo konto on kõigile ühine, seega, kui te midagi teete — võib keegi teine samaaegselt teid segada. Või (parem) registreeruge läbi lingi okerr'i ametlikul lehel — kõik on lihtne, ilma SMS-ita. Kui te ei soovi kasutada oma tõelist e-posti — võite võtta ühekordse, näiteks mailinator'ilt (soovitan getnada.com). Sellised kontod võivad ajaga kustutada — aga testimiseks sobivad.

Registreerimise järel pakutakse võimalust läbida lühike koolitus (teha mõne lihtsa harjutuse mõne minutiga). Esialgsed piirangud on üsna madalad, kuid koolituse või ühe serveri jaoks piisavad. Pärast koolituse läbimist tõstetakse piirangud (näiteks maksimaalne indikaatorite arv).

Dokumentatsioonist — kõigepealt WIKI serveri ja kliendi kohta (okerrupdate wiki). Kui aga midagi jääb arusaamatuks, kirjutage support (at) okerr.com või jätke pilet — püüame kiiresti lahendada.

Kui hakkate tõsiselt kasutama ja sellest kõrgeimatest piirangutest ei piisa — kirjutage samuti supporti, suurendame (ilma kuludeta).

Kas soovite installida okerr oma serverisse? Siin on okerr-dev repo. Soovitame paigaldada puhtale virtuaalmasinale, siis suudate selle lihtsalt teha installimisekskripti kaudu. Oma virtuaalmasinas — mingeid piiranguid ei ole :-). Ja kui midagi — püüame alati aidata.

Meile meeldib, et see projekt õnnestuks, et maailm oleks meie tõttu usaldusväärsem. Tasuta tarkvara ja teenuste abil muutub maailm sõbralikumaks ja areneb dünaamilisemalt. Koodiallikat saab hoida tasuta GitHubis, e-posti jaoks kasutada tasuta Gmaili. Me kasutame tasuta freshworks toetuseks. Selleks ei ole vaja serverite eest maksta, ei ole vaja alla laadida ja seadistada ega lahendada erinevaid kasutusprobleeme. Iga uus projekt, iga meeskond — saavad kohe nii e-posti kui ka koosolekute ja CRM-i. Kõik see on väga kvaliteetne, tasuta ja kohe saadaval. Me tahame, et ka jälgimine oleks sama — väiksed ettevõtted ja projektid võiksid tasuta kasutada okerr’i ning isegi kasvu ja arenguetapis oleksid usaldusväärsed nagu suurte tõsiste projektide puhul.

Allikas: habr.com