Kaks aastat tagasi tegin juba postituse Lihtne failover veebisaidile kohta okerr. Praegu on projektil toimunud teatav areng ja olen avaldanud okerr-i serveripoolse koodi alla avatud litsentsi alla, seetõttu otsustasin kirjutada Habrisse selle väikese ülevaate.

[ täissuuruses ]

Kellele see võiks huvi pakkuda

See võib teile huvi pakkuda, kui töötate väikese meeskonnaga või olete üldse üksi. Teie käes pole mitte mingit monitooringut ja te pole kindel, kas see on tõeliselt vajalik. Või olete proovinud mõnda tuntud tõsist monitooringut "suurematele poistele", aga see ei ole teie jaoks "õnnestunud" või töötab peaaegu vaikimisi konfiguratsioonis, mis ei olenenud teie elu palju muutnud. Ja veel - kui te ei plaani määrata ühte töötajat (rääkimata osakonnast) selleks, et see veidi aega päevas veedaks monitooringu armatuurlaudade jälgimisega või selle seadistamisega.

Mida eriliseks teeb okerr

Edasi näitan huvitavaid omadusi okerrist, mis eristavad seda mõnest muust monitooringust.

Okerr on hübriidmonitooring

Sisemonitooringu korral töötab jälgitavates masinates "agent", mis edastab andmeid monitooringuserverisse (nt kettaruumi vabadus). Välimise monitooringu puhul teeb server võrgus kontrollimisi (nt ping või veebisaidi kättesaadavus). Igal meetodil on oma piirangud. Okerr kasutab mõlemat varianti. Kontrollimised serverites viiakse läbi väga kergest (30Kb) agendist või teie enda skriptidest ja rakendustest, ning võrgu kontrollimised läbi okerr/i andurite erinevates riikides.

okerr ei ole lihtsalt tarkvara, vaid ka teenus

Iga monitooringu serveripoolne osa on suur ja keeruline teema, mille paigaldamine ja seadistamine on keeruline ning see nõuab ressursse. Okerriga saate paigaldada oma monitooringuserveri (see on tasuta ja avatud lähtekoodiga), või võite lihtsalt kasutada ainult kliendipoolset osa ja kasutada meie serveri teenust. Samuti tasuta.

Kui jälgimine suudab kompenseerida serverite ja rakenduste usaldusväärsuse puudujääke, siis tekib filosoofiline küsimus - kes valvab valvurit? Kuidas jälgimine annab meile teada probleemist, kui see ise on mingil põhjusel „surnud“, kas iseseisvalt või koos teiste teie ressurssidega (näiteks on andmekeskuse kanal kukkunud)? Välise teenuse kasutamisel okerr - lahendatakse see probleem - saate teate isegi siis, kui kogu teie serverite andmekeskus on vooluta või zombie-rünnaku all.

Muidugi on oht, et okerr server ise võib olla kättesaamatu, see on tõsi (nagu teada, saadakse 90% usaldusväärsusest alati lihtsalt ja „tasuta“, 99% - minimaalsete jõupingutustega ja iga järgmine null - eksponentsiaalselt keerulisem). Kuid esiteks on tõenäosus selleks madalam ja teiseks võib probleem jääda märkamatuks vaid siis, kui see langeb ajaliselt kokku meie serverite probleemidega. Kui meil on usaldusväärsus 99,9% ja teil 99,9% (mitte liiga kõrged numbrid), siis on märkamatuks tõrkeks tõenäosus 0,1% 0,1% = 0,0001%. Endale kolme nulli lisamine usaldusväärsusele peaaegu ilma pingutuseta ja kuludeta - see on väga hea!

Veel üks jälgimise teenuse eelis on see, et hostimisettevõte või veebistuudio võib paigaldada endale okerr serveri ja pakkuda klientidele juurdepääsu kui tasulist või tasuta lisateenust. Teie konkurentidel on lihtsalt hostimine ja veebilehed - aga teil on usaldusväärne hostimine koos jälgimisega.

Okerr - see on indikaatorite kohta

Indikaator on „lamp“. Sellel on kaks põhiseisundit - roheline (OK) või punane (ERR). Projektis on palju rühmitatud (näiteks serverite järgi) indikaatoreid. Projekti esilehel näete kohe, kas teil on kõik roheline (ja saate sulgeda) või midagi vilgub punaselt ja vajab parandamist. Need seisundid vahetudes saadetakse teade. Kui olete seadistanud, saadetakse kord päevas projekti kokkuvõte.

Iga okerr indikaatoril on sisseehitatud tingimused, mille alusel see oma seisundit muudab (Zabbixis nimetatakse seda triggeriks). Näiteks peab koormuse keskmine olema mitte üle 2 (loomulikult on see konfigureeritav). Ja iga sisemise kontrolli (koormuse keskmine, vaba ketas jne) jaoks on vahtkond. Kui mingil põhjusel ei saa me määratud ajal eduka kinnituse - registreeritakse viga ja saadetakse teade.

Meie tavapärane töökorraldus hõlmab hommikust e-kirjade kontrollimist, kus vaatame muu hulgas ka ülevaadet (selle aja määrame töö alguseks). Kui seal on kõik korras, tegeleme teiste oluliste asjadega (kuid võime usaldusväärsuse huvides kiiresti üle vaadata ka okerr’i armatuurlaua, et veenduda, et kõik on rohelised). Kui tuleb häiresignaal, reageerime.

Loomulikult on võimalus lihtsalt hoida "teavet" näitavaid indikaatoreid (et näha, kuidas võrk töötab), kuid kõik on loodud nii, et indikaatoreid oleks lihtne, mugav ja kiire luua automaatseks jälgimiseks ning häiresignaalide saatmiseks.

Mõte, miks te seadistate okerr’i, peitub häiresignaalides, et saaksite minutiga luua indikaatori, mis võib aastaid "magada", lihtsalt uuendusi vastu võtta, ja kui aasta pärast juhtub teil midagi katki minema, hakkab see vilkuma ja saadab häire. Üks minut, mille kulutasite kord indikaatori loomise peale, tasus end ära — saite probleemist kohe teada, enne kui keegi teine märkama jõudis. Kiirelt tõstetud ei loeta kukkunuks!

Turvalisus

Oleks kahetsusväärne, kui paneksite jälgimise käima usaldusväärsuse tõstmiseks, aga tulemuseks oleks see, et teid rünnatakse selle kaudu võrgus, ning erinevate jälgimistööriistade puhul on suhteliselt palju võrgu haavatavusi (Zabbix, Nagios).

Agent (okerrmod pakist okerrupdate), mis töötab süsteemis — ei ole võrgu server, vaid klient. Seetõttu ei ole jälgitaval serveril lisatud avatud porte, klient töötab kergesti tulemüürist või NAT-ist taga ning seda on väga keeruline (öeldes "võimatu") võrgu kaudu häkkida, kuna see ei kuula võrgu soketti.

Täielik jälgimise katvus

Meie praegune reegel on — me saame teada kõigist tehnilistest probleemidest okerr-ist. Kui reegel peaks rikkuvama (okerr ei teatanud selle varasemast tulekust (kui see on võimalik) või sellest, et see on juba toimunud) — lisame kontrollid okerr-isse.

Välistab kontrolle

Suhteliselt tavaline komplekt:

• ping
• http staatus
• SSL-sertifikaadi kehtivuse ja värskuse kontroll (teavitab, kui kehtivusaeg varsti lõppeb)
• avatud TCP port ja sellel banner
• http grep (lehe [ei] tohiks olla teatud teksti)
• sha1 hash, et tuvastada lehe muudatused.
• DNS (DNS-kirje peab omama teatud väärtust)
• WHOIS (teavitab, kui domeen varsti aegub)
• Antispam DNSBL (hosti kontroll kohe 50+ rämpsposti musta nimekirja vastu)

Sisene kontroll

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

• df (vaba kettaruumi)
• koormuse keskmine
• opentcp (avatud TCP pistikute kuulamine — teavitab, kui midagi käivitub või kukub ära)
• uptime — lihtsalt serveri tööaeg. Teavitab, kui see muutub madalamaks (st server taaskäivitus)
• client_ip
• dirsize — kasutame seda, et jälgida, kui meil rootfs virtuaalmasinate maht ületab lubatud suuruse, ilma rangete piiranguteta, ja jälgime kasutajate kodu kataloogide suurusi.
• empty ja nonempty — jälgivad faile, mis peavad olema tühjad (või mitte tühjad). Näiteks, serveri error log okerr — peab olema tühi, ja kui seal on vähemalt üks rida — saan teate ja kontrollin. Kuid mail.log meiliserveris ei tohi olla Tühi (N minuti pärast pärast rotatsiooni). Mõnikord oli see meil tühi, pärast süsteemi uuendamist, kui logrotate ei saanud õigesti rsyslog'i taaskäivitada.
• linecount — ridade arv failis (kui wc -l). Kasutame seda pehme asendusena empty'le, kui error log tõesti võib kasvada, kuid ainult aeglaselt (näiteks Googlebot ründab mõningaid suletud lehti). Piirang on 2 rida 20 minuti jooksul. Kui see ületab — tuleb häire.

Huvitavad sisemised kontrollid

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

bäkupid

Jälgib varukoopiaid kataloogis. Meil on varukoopiafailide nimed nagu „ServerName-20200530.tar.gz”. Iga serveri jaoks luuakse okerris indikaator ServerName-DATE.tar.gz (reaalne kuupäev asendatakse sõnaga „DATE”). Jälgib mitte ainult värske varukoopia olemasolu, vaid ka selle suurust (nt see ei saa olla väiksem kui 90% eelmisest varukoopiast).

Mida peab tegema, et uus varukoopia hakkaks jälgima, pärast seda, kui oleme selle loonud ja sellesse kataloogi paigutanud? Mitte midagi! See on väga mugav lähenemine, kui on vaja teha „mitte midagi”, sest:

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

Kui ootamatult ei hakka värskeid varukoopiafaile ilmuma — tuleb häire. Kui näiteks olete ühe serveri välja lülitanud ja selle varukoopiaid enam ei tohiks olla — peate indikaatori kustutama (kas veebiliidese kaudu või shellis API kaudu).

maxfilesz

Jälgib suurimaid faile (tavaliselt: /var/log/*). See võimaldab tabada ettearvamatuid probleeme, nagu näiteks paroolide ülevool või serveri kaudu spämmimise korral.

runstatus/runline

Need on kaks olulist proxy moodulit, et käivitada teisi programme serveris. Runstatus edastab indikaatoris programmi väljumiskoodi. Näiteks, okerr ei vaja moodulit, et kontrollida, kas systemd teenused töötavad. Seda tehakse runstatus'i kaudu (vt allpool). Runline — edastab serverile rea, mille programm genereerib. Näiteks, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" Runline'i konfiguratsioon meie serveris loob indikaatori servername:temp koos protsessori temperatuuriga.

sql

Teeb numbrilise päringu MySQL-le ja edastab tulemuse indikaatorisse. Lihtsaim näide oleks näiteks „SELECT 1“ — see kontrollib, et andmebaas tervikuna töötab.

Aga palju huvitavam rakendus — näiteks jälgida tellimuste arvu veebipoes. Kui tead, et tunnis tuleb 100 tellimust, saad seadistada minimaalsete piirideks 100 või 80. Siis, kui müük äkitselt langeb — saad alerti ja saad asjale läheneda.

Pange tähele — ei ole oluline, mis ettearvamatul põhjusel see juhtus:

• Server on lihtsalt kätketehituselt (ilma vooluta või ilma võrguta) ja alert tuli sellest, et indikaator „kukkus ära“.
• Server on mingil põhjusel ülekoormatud, töötab aeglaselt või pakette kaob, kasutajad tunnevad ebamugavust ja lahkuvad ilma ostudeta.
• Server on satunud spämmilisti ja tema e-kirju ei aktsepteerita, kasutajad ei saa registreeruda.
• Reklaamikampaania eelarve on lõppenud, bännerid ei jookse.

Põhjuseid võib olla palju, ja neid ei saa ette näha, ning tehniliselt on seda keeruline jälgida. Kuid saab mugavalt jälgida lõppparameetrit (tellimusi) ja selle põhjal määrata, et olukord on kahtlane ja vajab tähelepanu.

Loogilised indikaatorid

Lubab kasutada loogilisi väljendusi (Python süntaks) mooduli kaudu evalidate(artikkel habras). Väljendusele on saadaval projekti ning tema indikaatorite andmed. Näiteks, SQL kontrollimise lõigus, mida eespool mainiti, võisite märgata nõrkust — päeval on meil 100 müüki tunnis, aga öösel — 20, ja see on normaalne, mitte probleem. Kuidas olla? Indikaator ju paneb öösiti pidevalt häiret.

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

Teine näide loogilise indikaatori kasutamisest on eskalatsioon. Näiteks projektijuht loobub teavitustest (sest tal pole seda vaja, administraatorid peavad reageerima tavapärastele probleemidele), kuid liitub loogilise indikaatoriga, mis muutub punaseks, kui ükskõik milline indikaator projektis pole määratud ajaks parandatud.

Samuti on võimalus määrata lubatud tööaeg, näiteks kell 3–5 hommikul. Meid ei huvita, kui serverid ja saidid sellel ajal "kukuvad". Kuid kell 5:00 peavad nad tööle hakkama. Kui nad ei tööta muul ajal - teade. Samuti võimaldab loogiline indikaator arvesse võtta serverite varundamist. Kui teil on 5 veebiserverit, saavad administraatorid 1-2 serverit igal ajal välja lülitada. Kuid kui võitlusboonis on vähem kui 3 viiest serverist - tuleb teade.

Ülaltoodud näited ei ole okerri funktsioonid, ei ole need mingid funktsioonid, mida tuleb aktiveerida ja seadistada. Kõiki neid funktsioone okerril ei ole, kuid on olemas loogiline moodul, mis võimaldab seda funktsionaalsust rakendada (ligikaudu nagu programmeerimiskeeles - kui meil on aritmeetilised operaatorid, siis ei vaja me keelest erilist funktsiooni 20% käibemaksu arvutamiseks, seda saab alati ise teha oma vajaduste kohaselt).

Loogiline indikaator on võib-olla üks väheseid suhteliselt keerulisi teemasid okerris, kuid hea uudis on see, et te ei pea neid valdama, kuni see pole vajalik. Kuid sellegipoolest laiendavad nad võimalusi oluliselt, säilitades samas süsteemi piisavalt lihtsana.

Oma kontrollide lisamine

Ma sooviksin väga rõhutada, et okerr ei ole tuhat valmiskontrolli igaks juhuks, vaid vastupidi - see on eelkõige lihtne mootor koos lihtsa võimalusega luua oma kontrollid. Oma kontrollide loomine okerris ei ole häkkerite, süsteemi kaasarendajate või vähemalt edasijõudnud okerri kasutajate ülesanne, vaid igasuguse administraatori kergesti teostatav ülesanne, kes kuu aega tagasi esmakordselt Linuxi paigaldas.

Minimaalsete kontrollide tegemine toimub mooduli kaudu runstatus:

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

true_OK=\/bin\/true

Ainult üks rida – ja juba oleme natuke laiendanud funktsionaalsust okerr.

Isegi selline kontroll – omab juba väärtust: kui teie server peaks alla minema – vastav indikaator serveris okerr ei uuene õigeaegselt ja aja möödudes tekib häire.

See kontroll teavitab, et server apache2 on kokku kukkunud (noh, juhtub ka):

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

Seega, kui teil on teadmisi mõnest programmeerimiskeelest, vähemalt oskate shell skripte kirjutada – siis saate juba lisada enda kontrollid.

Raskem on kirjutada (mõnes keeles) oma moodul okerrmod jaoks. Lihtsamal juhul näeb see välja järgmine:

#!/usr/bin/python3

print("STATUS: OK")

Tõsi, pole ju väga keeruline? Moodul peab teostama ise kontrolli ja andma tulemused STDOUT-ile. Raskem moodul annab näiteks sellise:

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

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

See uuendab korraga mitut indikaatorit (eraldatud tühja reaga), vajadusel loob need, näitab kontrolli detaile ja silte, mille järgi on dashboardil kerge leida vajalikke indikaatoreid.

Telegram

On Telegrami bot @OkerrBot. Te ei pea telefoni tülikas aplikatsioonidega täitma (ise ei armasta, et näiteks Paateriks vajab ühte aplikatsiooni kaardiga, Lenta teist, MTS kolmandat jne). Üks Telegram on piisav. Telegrami kaudu saate kohe häireid ja kontrollida projekti seisu ning anda käsu kõigi probleemsete indikaatorite järelevalveks. Väljusite teatrist/lennukist, kaks tundi ei hoidnud pulsil, lülitasite tele välja, vajutasite chat-boti nupule ja veendusite, et kõik on korras.

Olekulehed

Meie ajal on olekuhed juba peaaegu must have iga äri jaoks, mis tegeleb IT-ga, on vastutustundlik usaldusväärsuse osas ja austab oma kliente/kasutajaid.

Kujutage ette olukorda — kasutaja tahab midagi teha, vaadata infot või esitada tellimust, kuid midagi ei toimi. Ta ei tea, mis on vale, kellel on probleem ja millal see lahendatakse. Kas teie ettevõtte veebisait on lihtsalt maas? Või see kahjustati kuus kuud tagasi ja parandatakse kahe aasta pärast? Aga külmkapp peab ostma juba praegu, see on juba ostukorvis… Ja täiesti teine asi on see, kui inimene näeb, et teil on midagi valesti (olgu või selge, et probleem ei ole tema poolel), et probleem on tuvastatud, et te töötate selle kallal ja võib-olla on isegi kirjutatud ligikaudne parandamise aeg. Kasutaja võib tellida ja saada e-posti teel teate, kui probleem on lahendatud ja saab teha, mida ta soovis (osta külmkapp).

Probleemid, seisakud — juhtub kõigil. Kuid kasutajad ja partnerid usaldavad rohkem neid, kes on rohkem läbipaistvad ja vastutustundlikud.

Siin ülevaade 10 teisest projektist, mis võimaldavad luua staatuslehti. Siin on näited, millised need lehed on projektides Python ja Dropbox. staatusleht okerr.

Failover

Et mitte muuta seda artiklit veelgi pikemaks, viitan veel kord oma eelnevale artiklile — Lihtne failover veebisaidile . Kui saate teha varuserveri, siis failoveri kasutamine tähendab, et teil ei ole põhimõtteliselt pikki seisakuid — kohe, kui probleem on tuvastatud, suunatakse kasutajad automaatselt töötavale varuserverile. Ja mulle tundub, et see on väga huvitav, silmatorkav funktsioon, mida pole paljudes kohtades.

Madala süstemaatilised nõuded

Okerr-serverite jaoks — kasutame masinaid, kus on RAM alates 2Gb. Võrgusensorite jaoks piisab isegi 512Mb-st. Klient osa — praktiliselt null. (Pakett okerrupdate kaalub 26 Kb, kuid nõuab Python3 ja standardteeke). Klient käivitatakse kront skripti kaudu, seega on selle pidev mälu tarbimine null. Jälgitavate masinate seas on meil sisendseadmed (ülimalt odavad VPS-id 512Mb RAM-iga) ja Raspberry Pi. Isegi ilma kliendi osata saab värskendusi saata curliga!(vt allpool)

Selle arvesse võttes — okerr on tõenäoliselt kõige tasuta Kasutatavad jälgimissüsteemi, sest isegi teise tasuta avatud lähtekoodiga süsteemi nagu Zabbix või Nagios kasutamiseks tuleb sellele eraldada ressursid (server), ja see on juba raha. Lisaks on ikkagi vajalik serveri hooldus. okerr'iga saab seda osa jätta välja. Või saab ka mitte välja jätta ja kasutada oma serverit — kuidas teile rohkem meeldib.

API ja integreerimine oma tarkvarasse

Lihtne ja avatud arhitektuur. okerr'il on üsna lihtne API, millega on lihtne töötada. Kas soovite luua 1000 indikaatorit? Üks shell-skript 3-4 rida teeb selle ära. Kas peate 1000 indikaatorit ümber seadistama? See on samuti väga lihtne. Näiteks tahame uuesti kontrollida kõiki meie HTTPS sertifikaate Venemaa sensoriga:

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

Indikaatori uuendamine on võimalik kas meie kliendimooduli abil või isegi 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 aktiivne, ja tõstaks alarmi, kui see kukub või hangub. Muide, okerr'i komponendid teevadki nii — okerr jälgib iseennast, ja probleemid peaaegu igas moodulis avastatakse ning genereeritakse teatis probleemist. (Ja selle 'peaaegu' jaoks — neid kontrollitakse kruvise ülesanne teise serveriga)

Siin on selline kood (lihtsustatud) meie Telegram'i 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))

Indikaatorite uuendamiseks Python programmide kaudu on olemas raamatukogu okerrupdate, teiste keelte jaoks ei ole raamatukogu, kuid saate kas kutsuda okerrupdate skripti või teha HTTP päringu okerr serverisse.

Kuidas okerr meid aitab

Okerr on muutnud meie elu. Tõepoolest. Usu mind, teine jälgimissüsteem oleks ka seda suutnud, kuid okerr'iga on meil lihtsalt mugav töötada ja seal on kõik funktsioonid, mida me vajasime (mida puudu oli — kirjutasime ise juurde). Üks asi veel, kui mõni funktsioon puudub — küsige, ja ma lisan selle (ei lubada, kuid mulle meeldiks, et okerr oleks parim jälgimissüsteem väikese- ja keskmise suurusega projektide jaoks). Või, mis veelgi parem, lisage ise — see on lihtne.

Meil on õnnestunud elada põhimõtte järgi «kõigist probleemidest teada okerrist». Kui juhtub probleem, millest me ei saanud teada okerrist — lisame kontrolli okerrisse. (selle all mõistan 'me' kasutajatena süsteemis, mitte kaasarendajatena). Alguses juhtus see tihti, kuid nüüd on see väga harv.

Jälgimine

Okerri kaudu jälgime logide suurust kõigil serveritel. Iga logirida silmadega hoolikalt lugeda — see on muidugi võimatu, kuid lihtsalt kasvu jälgimine annab juba palju. Selle kaudu oleme avastanud nii spämmiläkitamisi kui ka bruteforce paroolide katsetamis, ja kui mõned rakendused 'hulluks lähevad', siis nad ei suuda midagi ja kordavad ikka ja jälle (iga kord lisades paar rida logisse).

SSL sertifikaadid. Peaaegu kohe pärast käivitamist LetsEncrypt meie klient hakkas oma klientidele pakkuma tasuta SSL sertifikaate (umbes tuhat neist). Ja see osutus lihtsalt administratsiooniks põrguks! Asi on selles, et saidid on 'elavad', kliendid küsivad neilt pidevalt midagi teha, arendajad teevad. Nad võivad vabalt liigutada saidi teise DocumentRoot'i näiteks. Või lisada tingimusteta Rewrite virtuaalhosti konfiguratsiooni. Loomulikult, pärast seda rikutakse automaatne sertifikaatide uuendamine. Nüüd lisatakse kõik meie SSL hostid okerrisse automaatselt läbi veel ühe meie kasuliku tööriista paketist a2conf. Lihtsalt käivitame a2okerr.py — ja kui serveris ilmuvad mitu uut saiti — need ilmuvad automaatselt okerrisse. Kui mingil põhjusel sertifikaat ei uuene, kolme nädala jooksul enne sertifikaadi aegumist — oleme kursis ja uurime, miks see ei uuene, kurat. a2certbot.py sama paketist — aitab sellele väga palju (kontrollib kohe kõige tõenäolisemaid probleeme — ja kirjutab, mis on hästi kontrollitud ja kus on tõenäoliselt probleem).

Jälgime kõikide meie domeenide aegumistähtaegu. Ja kõik meie postiserverid, mis saadavad postit, kontrollitakse ka 50+ erineva musta nimekirja alusel. (Ja mõnikord satuvad sinna). Muide, kas teadsite, et ka google’i postiserverid on mustades nimekirjades? Lihtsalt enesetestsimiseks lisasime mail-wr1-f54.google.com jälgitavate serverite hulka ja see on tõepoolest SORBS-i mustas nimekirjas! (See on seotud 'antispämmide' väärtuse küsimusega)

Varukoopiad – ma juba kirjutasin, kui lihtne on neid jälgida okerriga. Kuid me jälgime ka värskeid varukoopiaid meie serveris ja (kasutades eraldi tööriista, mis kasutab okerrit) – varukoopiaid, mille me üles laadime Amazon Glacierisse. Ja jah – aeg-ajalt juhtub probleeme. Mitte asjata ei jälgita.

Kasutame eskaleerimise indikaatorit. Selle järgi on näha, kui mõni probleem ei ole pikka aega lahendatud. Ja isegi mina, kui lahendan mõningaid ülesandeid, võin vahel unustada need. Eskaleerimine – hea meeldetuletus, isegi kui jälgid iseennast.

Üldiselt arvan, et meie töö kvaliteet on tõusnud kordades. Peaaegu pole seisakuid (noh, või klient ei saagi neid märgata. Ainult tšsss!), samas on töömaht vähenenud ja töötingimused – rahulikumad. Oleme liikunud hädaolukordadest, kus lappisime auke teibiga, rahulikku ja mõõdetud tööle, kus paljusid probleeme ennustatakse ette ja on aega neid ennetada. Isegi toimunud probleeme – on kergem parandada: esiteks kuuleme neist enne, kui kliendid paanikat korraldavad, teiseks juhtub sageli, et probleem on seotud hiljutise tööga (kui tegin ühte, rikkusin teise) – seega on kergem sellega kuumadel jälgedel tegutseda.

Ja veel üks juhtum…

Kas teadsite, et populaarseks saanud Debian 9 (Stretch) populaarne pakett phpmyadmin on endiselt (juba mitu kuud!) olukorras vulnerable? (CVE-2019-6798). Kui haavatavus ilmus – katsetasime kiiresti erinevaid viise, et seda varjata. Kuid seadsin okerrisse jälgimise security-tracker'i lehe jaoks, et teada, millal ilmub "ilus" lahendus (SHA1 sisu summa kaudu). Mitu korda indikaator tõmbas mind, leht muutus, kuid nagu näete – siiani (alates jaanuarist 2019!) ei ole seal näidatud, et probleem on lahendatud. Võib-olla teavad mõned, mis probleem seal on, et selline oluline pakett on juba üle aasta vulnerable?

Teine kord sarnases olukorras: pärast SSH haavatavust tuli kõik serverid uuendada. Ja kui sa annad ülesande, tuleb kontrollida selle täitmist. (Alamordenid kipuvad mitte nii aru saama, unustavad, segadusse minema, eksima). Seetõttu lisasime esmalt okerr'i, et kontrollida SSH versiooni kõigis serverites, ja okerr'i kaudu jälgisime, et uuendused oleksid kõigisse serveritesse paigaldatud. (Mugav! Valisin selle indikaatori tüübi ja kohe on näha, millises serveris milline versioon). Kui me veendusime, et ülesanne on kõigis serverites täidetud, eemaldasime indikaatorid.

Mõni kord oli olukord, kus mingi probleem esines, kuid siis lahendas end ise. (tõenäoliselt on see kõigile tuttav?). Kuni sa märkad, kuni sa kontrollid — ja seal pole enam midagi kontrollida — kõik töötab juba hästi. Aga siis puruneb see jälle. Meil oli see näiteks Amazon Marketplace'is (MWS) laaditud toodetega. Mingil hetkel olid laetud varud valed (vale kogus kaupu ja vale hind). Sain aru. Kuid et aru saada — oli oluline probleemi kohe märgata. Kahjuks on MWS, nagu kõik Amazoni teenused — natuke aeglane, seetõttu oli alati viivitus, kuid siiski — suutsime vähemalt enam-vähem tabada seose probleemi ja skriptide vahel, mis seda põhjustavad (tegin kontrolli, lisasin selle okerr'i ja kontrollisin kohe pärast häire saamist).

Hiljuti lisas suur ja kallis Euroopa hostiteenuse pakkuja, mida kasutab meie klient, oma kogemuste kolleksiooni huvitava juhtumi. Ühtäkki kadusid meie radarilt KÕIK meie serverid! Esiteks, klient ise märkis, et tema tööleht ei lae, ja saatis selle kohta pilet. Aga probleem ei olnud ainult ühes veebilehes, vaid kõikides! (Natasha, me oleme kõik ära kukkunud!). Siis hakkas Okerr saatma pikki teateid kõikide indikaatorite kohta, mis tal põlema leidsid. Häda, häda, ringi jooksmine (mis sa veel teed?). Hiljem kõik taastus. Selgus, et andmekeskuses olid regulaarsete tööde tõttu (üks kord mitme aasta jooksul) meid, loomulikult, pidanuks ette lööma. Aga neil oli mingi sõnk ja ei hoiatatud meid. Aga see on sama palju infarkti, rohkem või vähem. Kuid pärast kõike taastumist - peab kõik üle kontrollima! Ma ei suuda ette kujutada, kuidas ma seda käsitsi teeksin. Okerr katsetas kõik paarikümne minutiga läbi. Selgus, et suurem osa serveritest oli lihtsalt ajutiselt kättesaamatu, kuid töötas. Mõned - ülekoormatud, kuid taastusid samuti. Kõikidest kaotustest - me kaotasime kaks varukoopiat, mis pidid cron'iga looma ja laadima just sel ajal, kui see täielik jama käis. Ma ei hakanud neid looma, lihtsalt tunni pärast tulid teated, et kõik on korras, varukoopiad ilmusid. Mulle meeldib see näide väga, kuna Okerr osutus keerulises olukorras väga kasulikuks, millest me isegi eelnevalt ei mõelnud, kuid see ongi monitooringu ülesanne - vastanduda ettearvamatule.

Okerri sensorite jaoks kasutame maksimaalselt odavaid hostiteenuseid (seal ei ole kvaliteet ja usaldusväärsus olulised, nad katab üksteist). Noh, hiljuti leidsime väga elava hostinguteenuse ja super odava, tõhusus oli fantastiline. Kuid... mõnikord osutub, et välised ühendused virtuaalserverist teostatakse teise (naabri) IP kaudu. Imeline. Moodul client_ip https://diagnostic.opendns.com/myip saab vale IP. Ja serveri logid näitavad, et uuendus tuli samuti sellest naabri IP-st. Hetkel tegeleme toega. Hea, et me märkame seda rahuajal. Kuid näiteks, tihti on nii, et ligipääs on määratud valge IP nimekirja järgi - ja kui server mõnikord lühikese aja jooksul nii vilgub - siis võib olla väga pikk aeg, kuni seda probleemi tabada.

Ja veel — kui me räägime VPS-hostingutest — me kasutame alati odavaid (hetzner, ovh, scaleway). Ja nii jõudluse kui ka stabiilsuse osas — meeldib väga. Kasutame ka kallimat Amazon EC2 teiste projektide jaoks. Nii et tänu okerr'ile on meil oma põhjendatud arvamus. Mõlemad kukuvad vahel. Ja ma ei ütleks, et meie pikaajaliste tähelepanekute põhjal oleksid odavad hostingud nagu hetzner oluliselt ebastabiilsemad kui EC2. Seega, kui te ei ole seotud Amazoni muude funktsioonidega — miks maksta rohkem? 🙂

Mis edasi?

Kui ma teid sel etapil veel okerr'ist liiga palju eemale ei peitanud — siis proovige! Otse sellel lingil saate siseneda okerr'i demo kontole (Klõpsake kohe!). Kuid pidage meeles — et demokonto on kõigi jaoks üks, seega, kui te teete midagi — võib keegi teine samal ajal teie tegevusele takistada. Või (parem) registreerige end lingi kaudu okerr'i ametlikul lehel — kõik on lihtne, ilma SMSita. Kui te ei soovi kasutada oma tegelikku e-posti — võite valida ühekordse, näiteks mailinator'i (soovitan ma getnada.com). Sellised kontod võivad aja jooksul kaduda — kuid testimiseks sobib.

Pärast registreerimist pakutakse teile koolitust (mitme mitte eriti keerulise õppeülesande täitmist). Algse limiidid on väga väikesed, kuid koolituse või ühe serveri jaoks on neid piisavalt. Pärast koolituse läbimist — limiidid (näiteks maksimaalne indikaatorite arv) tõstetakse.

Dokumentatsioonis — kõigepealt WIKI serveri osa ja kliendi jaoks (okerrupdate wiki). Kuid kui midagi on arusaamatu — kirjutage aadressile support (at) okerr.com või jätke pilet — püüame kiiresti kõik lahendada.

Kui hakkate tõsiselt kasutama ja neid suurendatud limite ei piisa — kirjutage ka support'i, suurendame (tasuta).

Soovite installida okerr'i serveri oma serverisse? Siin on okerr-dev repositoorium. Soovitame installida puhtale virtuaalkeskkonnale, siis saate selle hõlpsasti installimis skripti abil teha. Oma virtuaalkeskkonnas — ei ole mingeid piiranguid :-). Ja jälle — kui on midagi — püüame alati abiks olla.

Me tahame, et see projekt õnnestuks, et maailm muutuks meie abiga usaldusväärsemaks. Tasuta tarkvara ja teenuste abil on maailm sõbralikum ja areneb dünaamilisemalt. Allikaid saab tasuta hoida github'is, e-posti jaoks kasutada tasuta gmaili. Me kasutame tasuta freshworks klienditoe jaoks. Ükski neist ei nõua serverite eest tasumist, ei ole vaja alla laadida ja konfigureerida ega tegeleda erinevate haldusprobleemidega. Iga uus projekt, iga meeskond — kõik on kohe varustatud nii e-posti, hoidlate kui ka CRM-iga. Ja kõik see on väga kvaliteetne, tasuta ja koheselt kättesaadav. Me tahame, et ka monitooring oleks nii — väikesed ettevõtted ja projektid saaksid tasuta kasutada okerr'i ja isegi sünni ja kasvu faasis omada usaldusväärsust nagu suurte tõsiste projektide seas.

Allikas: habr.com