Kaks aastat tagasi tegin juba postituse Lihtne veebisaidi tõrkeotsas umbes okerr. Nüüd on projekti arendamine käimas ja ma avaldasin ka okerr serveripoolne lähtekood alla avatud litsents, sellepärast otsustasin kirjutada selle lühikese ülevaate saidil Habr.

[ täissuuruses ]

Kellele see võib huvi pakkuda

See võib teile huvi pakkuda, kui töötate väikeses meeskonnas või üksi. Teil pole jälgimist ja te pole kindel, kas seda tõesti vajate. Kas proovisite mõnda populaarset tõsist jälgimist "suurte poiste jaoks", kuid see kuidagi "ei tõusnud" teie jaoks või töötab see peaaegu vaikekonfiguratsioonis ega muutnud teie elu palju. Ja ka - kui kindlasti ei plaani eraldada tervet töötajat (või isegi osakonda) vähemalt paar tundi päevas jälgimispaneeli jälgima või seadistama.

Miks okerr on ebatavaline

Järgmisena näitan okerra huvitavaid omadusi, mis eristavad seda mõnest teisest seiresüsteemist.

Okerr on hübriidseire

Sisemise monitooringu ajal töötab jälgitavatel masinatel “agent”, mis edastab andmed jälgimisserverisse (näiteks vaba kettaruumi). Kui server on väline, kontrollib server võrgu kaudu (nt ping või veebisaidi saadavus). Igal lähenemisviisil on oma piirangud. Okerr kasutab mõlemat võimalust. Serverite siseseid kontrolle teostab väga kerge (30Kb) agent või teie enda skriptid ja rakendused ning võrgukontrollid tehakse erinevates riikides läbi okerri andurite.

okerr pole ainult tarkvara, vaid ka teenus

Igasuguse monitooringu serveriosa on suur ja keeruline, seda on keeruline paigaldada ja seadistada ning see nõuab ressursse. Okerri abil saate installida oma jälgimisserveri (see on tasuta ja avatud lähtekoodiga) või võite lihtsalt kasutada ainult kliendiosa ja kasutada meie serveri teenust. Samuti tasuta.

Kui monitooring võimaldab kompenseerida ja varjata serverite ja rakenduste töökindluse puudumist, siis tekib filosoofiline küsimus - kes on valvur? Kuidas annab seire meile teada probleemist, kui see ise mingil põhjusel eraldi või koos teie muude ressurssidega "suri" (näiteks andmekeskuse kanal kukkus ära)? Kui kasutate välisteenust okerr - see probleem on lahendatud - saate hoiatuse isegi siis, kui kogu andmekeskus koos teie serveritega on vooluta või zombide poolt rünnatud.

Muidugi on oht, et okerr server ise pole saadaval, see on tõsi (nagu teate, 90% töökindlusest saadakse alati lihtsalt ja "tasuta", 99% minimaalse pingutusega ja iga järgmine üheksa on eksponentsiaalselt raskem). Kuid esiteks on selle juhtumise tõenäosus väiksem ja teiseks võib probleem jääda märkamatuks ainult siis, kui see langeb kokku meie serverite probleemidega. Kui meil on 99.9% usaldusväärsus ja teil on 99.9% (mitte liiga kõrged numbrid), siis on avastamata rikke tõenäosus 0.1% 0.1% = 0.0001%. Kolme üheksa lisamine oma töökindlusele peaaegu ilma pingutuseta ja ilma kuludeta on väga hea!

Jälgimise kui teenuse eeliseks on ka see, et hostingu pakkuja või veebistuudio saab paigaldada okerr serveri ja pakkuda klientidele juurdepääsu tasulise või tasuta lisateenusena. Teie konkurentidel on lihtsalt hostimine ja veebisaidid, kuid teil on usaldusväärne hostimine koos jälgimisega.

Okerr räägib näitajatest

Indikaator on "lambipirn". Sellel on kaks peamist olekut – roheline (OK) või punane (ERR). Projekt sisaldab palju rühmitatud (näiteks serverite kaupa) indikaatoreid. Projekti avalehel näete kohe, et kas kõik on roheline (ja saate selle sulgeda) või midagi põleb punaselt ja vajab parandamist. Nende olekute vahel üleminekul saadetakse hoiatus. Kord päevas, kui te seda seadistate, saadetakse projekti kokkuvõte.

Igal okerri indikaatoril on sisseehitatud tingimused, mille alusel see olekut muudab (Zabbixis nimetatakse seda trigeriks). Näiteks koormuse keskmine ei tohiks olla suurem kui 2 (see on muidugi konfigureeritav). Ja iga sisekontrolli jaoks (koormus keskmine, kettavaba, ...) on valvekoer. Kui me mingil põhjusel määratud ajal edukat kinnitust ei saa, logitakse tõrge ja saadetakse hoiatus.

Meie tavaline töömuster on hommikuti e-kirjade vaatamine ja kokkuvõte vaatamine muude kirjade hulgas (ajastame selle töö alguses). Kui kõik on selles korras, teeme muid olulisi asju (aga turvalisuse huvides saame kiiresti okerra armatuurlauale vaadata ja veenduda, et kõik on hetkel roheline). Kui saabub hoiatus, reageerime.

Muidugi on võimalik hoida lihtsalt “informatiivseid” indikaatoreid (seirest võrgu pilti näha), kuid tehakse kõik selleks, et luua lihtsalt, lihtsalt ja kiiresti indikaatorid spetsiaalselt automaatse jälgimise ja hoiatuste saatmise jaoks.

Eesmärk, milleks okerri seadistad, on hoiatustes, et saaksid minutiga indikaatori luua, see võiks aasta aega “uinuda”, lihtsalt uuendusi vastu võtta ja kui aasta hiljem midagi katki läheb, süttib ja saadab hoiatus. Minut, mille te kunagi indikaatori loomisele kulutasite, tasus end ära; saite probleemist teada kohe, enne kui keegi teine. Võimalik, et nad parandasid selle enne, kui keegi seda märkas. Midagi, mis tõstetakse kiiresti üles, ei loeta kukkunuks!

turvalisus

Oleks kahju, kui paneksid seire töökindluse suurendamise huvides sisse, kuid selle tulemusena rünnatakse sind selle kaudu üle võrgu ja erinevates jälgimistööriistades on päris palju võrgu haavatavusi (Zabbix, Nagios).

Agent (okerrmod pakendist okerruptate) ei ole süsteemis töötav võrguserver, vaid klient. Seetõttu pole jälgitaval serveril täiendavaid avatud porte, klient töötab hõlpsalt tulemüüri või NAT-i taga ja seda on väga raske (ütleksin "võimatu") võrgu kaudu häkkida, kuna põhimõtteliselt ei kuula ta võrku pistikupesa.

Täielik seire katvus

Nüüd on meie reegel, et me õpime kõik tehnilised probleemid okerrist. Kui ootamatult reeglit rikutakse (okerr ei hoiatanud selle peatse toimumise eest (kui see on võimalik) või et see on juba toimunud) - lisame okerrile kontrollid.

Välised kontrollid

Täiesti tüüpiline komplekt:

ping
http olek
SSL-sertifikaadi kehtivuse ja värskuse kontrollimine (hoiatab, kui see hakkab aeguma)
avage TCP-port ja sellel olev bänner
http grep (leht [ei tohi] sisaldada konkreetset teksti)
sha1 hash, et tabada lehe muudatusi.
DNS (DNS-kirjel peab olema konkreetne väärtus)
WHOIS (hoiatab, kui domeen hakkab halvasti minema)
Rämpspostitõrje DNSBL (hosti kontroll 50+ rämpspostivastase musta nimekirja vastu korraga)

Sisemised kontrollid

Samuti üsna standardne komplekt (aga kergesti laiendatav).

df (vaba kettaruum)
koormus keskmine
opentcp (avatud TCP kuulamispesad – annab teada, kui midagi käivitub või jookseb kokku)
tööaeg – lihtsalt tööaeg serveris. Annab teada, kui see on muutunud (st server on ülekoormatud)
kliendi_ip
dirsize – kasutame seda, et jälgida, millal meie virtuaalmasina juurfailid ületavad lubatud suuruse, ilma rangeid piiranguid kehtestamata ja kasutajate kodukataloogide suurust
tühi ja tühi – jälgige faile, mis peaksid olema tühjad (või mitte tühjad). Näiteks okerr serveri enda vealogi peaks olema tühi ja kui seal on kasvõi rida, siis saan teatise ja vaatan üle. Kuid mail.log EI TOHI meiliserveris olla tühi (N minutit pärast pööramist). Ja mõnikord oli see meie jaoks tühi pärast süsteemi värskendust, kui logrotate ei saanud rsyslogi õigesti taaskäivitada.
ridade arv – ridade arv failis (nagu wc -l). Kasutame seda pehmema asendusena tühjale, kui vealogi võib veel kasvada, kuid aeglaselt (näiteks Googlebot tabab mõnda suletud lehte). 2 minuti jooksul on lubatud 20 rida. Kui see on kõrgem, antakse hoiatus

Huvitavad sisekontrollid

Kui olete seni lugenud "diagonaalselt", on nüüd huvitavam lugeda hoolikamalt.

varukoopiaid

Jälgib varukoopiaid kataloogis. Meie varufailidel on sellised nimed nagu "ServeriNimi-20200530.tar.gz". Iga serveri jaoks okerris luuakse indikaator ServerName-DATE.tar.gz (tegelik kuupäev muutub reale “KUUPÄEV”). Samuti jälgitakse värske varukoopia olemasolu ja selle suurust (näiteks ei tohi see olla väiksem kui 90% eelmisest varukoopiast).

Mida tuleb teha, et uut varukoopiat hakataks jälgima pärast seda, kui oleme alustanud selle loomist ja sellesse kataloogi lisamist? Mitte midagi! See on väga mugav lähenemine, kui teil on vaja mitte midagi teha, kuna:

"Mitte midagi" tegemine on üsna kiire, see säästab aega
Raske on unustada mitte midagi teha
Raske on teha "midagi" valesti, veaga. Miski pole kõige usaldusväärsem meetod

Kui värskete varukoopiate ilmumine äkki lakkab, kuvatakse hoiatus. Kui olete näiteks ühe serveri keelanud ja varukoopiaid enam ei tohiks olla, peate indikaatori kustutama (veebiliidese kaudu või API kaudu kestast).

maxfilesz

Jälgib suurimate failide suurust (tavaliselt: /var/log/*). See võimaldab teil tabada ettearvamatuid probleeme, näiteks brute force paroole või rämpsposti saatmist serveri kaudu.

runstatus/runline

Need on kaks olulist puhverserveri moodulit serveris muude programmide käitamiseks. Runstatus teatab indikaatorile programmi väljumiskoodi. Näiteks okerr ei vaja (nõua) moodulit, mis kontrolliks, kas systemd teenused töötavad. Seda tehakse runstatusi kaudu (vt allpool). Runline – teatab serverile rea, mille programm toodab. Näiteks, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" loob meie serveri Runline konfiguratsioonis indikaatori servername:temp koos protsessori temperatuuriga.

SQL

Täidab numbripäringu MySQL-ile ja edastab tulemuse indikaatorile. Lihtsamal juhul saate teha näiteks "SELECT 1" - see kontrollib, kas DBMS tervikuna töötab.

Kuid palju huvitavam rakendus on näiteks veebipoe tellimuste arvu jälgimine. Kui tead, et sul on 100 või rohkem tellimust tunnis, võid seada miinimumlimiidiks 100 või 80. Kui siis müük ootamatult langeb, saad hoiatuse ja saad selle välja mõelda.

Pange tähele, et pole vahet, mis ettearvamatul põhjusel see juhtus:

Server pole lihtsalt saadaval (pingeta või ilma võrguta) ja hoiatus tuli sellest, et indikaator oli "mäda".
Server on millegagi üle koormatud, töötab aeglaselt või paketid lähevad kaduma, see on kasutajatele ebamugav ja nad lahkuvad ostmata
Server on kantud rämpspostiloenditesse ja sealt pärit kirju ei võeta vastu, kasutajad ei saa registreeruda
Reklaamikampaania eelarve on otsas, bännerid ei keerle.

Põhjuseid võib olla palju ja kõiki neid ei saa ette näha ning seda on tehniliselt raske jälgida. Kuid saate mugavalt jälgida lõppparameetrit (tellimusi) ja nende põhjal otsustada, et olukord on kahtlane ja väärib käsitlemist.

Loogilised näitajad

Võimaldab kasutada Boole'i avaldisi (Pythoni süntaks) mooduli kaudu kinnitama(artikkel Habré kohta). Projekti andmed ja selle näitajad on väljendamiseks saadaval. Näiteks ülaltoodud peatükis SQL-i kontrollimise kohta võisite märgata nõrka kohta - päeval võib meil olla 100 müüki tunnis, kuid öösel - 20 ja see on tavaline, mitte probleem. Mida ma peaksin tegema? Indikaator satub öösel pidevalt paanikasse.

Saate luua kaks indikaatorit, päeval ja öösel. Muutke mõlemad vaikseks (nad ei saada hoiatusi). Ja luua loogiline indikaator, mis nõuab, et päevanäidik oleks korras enne kella 20:00 ja pärast 20:00 piisab, kui öönäidik on korras.

Teine näide loogilise indikaatori kasutamisest on eskalatsioon. Näiteks projektijuht loobub hoiatustest (ta ei pea seda tegema, administraatorid peaksid tavaprobleemidele reageerima), kuid tellib loogilise indikaatori, mis muutub punaseks, kui projektis mõnda indikaatorit ettenähtud aja jooksul ei parandata.

Samuti on võimalik määrata töötamiseks lubatud aeg näiteks kella 3-5. Meid ei huvita, kui serverid ja saidid selle aja jooksul kokku jooksevad. Aga kell 5:00 peavad nad tööd tegema. Kui nad muul ajal ei tööta – hoiatus. Loogiline indikaator võimaldab arvestada ka serveri koondamisega. Kui teil on 5 veebiserverit, saavad administraatorid igal ajal 1-2 serverit välja lülitada. Aga kui lahingus on vähem kui 3 serverit viiest, antakse hoiatus.

Ülaltoodud näited ei ole okeri funktsioonid, mitte mõned funktsioonid, mida tuleb aktiveerida ja konfigureerida. Okerral pole kõiki neid funktsioone, kuid seal on loogiline moodul, mis võimaldab teil seda funktsiooni rakendada (ligikaudu nagu programmeerimiskeeles - kui meil on aritmeetilised operaatorid, siis ei vaja me 20% käibemaksu arvutamiseks spetsiaalset funktsiooni keelest, saate seda alati ise teha, et see oma vajadustele vastaks).

Loogikaindikaator on ilmselt üks väheseid suhteliselt keerulisi teemasid okerris, kuid hea uudis on see, et te ei pea seda valdama enne, kui seda vajate. Kuid samal ajal laiendavad nad oluliselt võimalusi, hoides süsteemi enda üsna lihtsana.

Enda tšekkide lisamine

Tahaksin tõesti edasi anda mõtet, et okerr ei ole tuhandete valmistšekkide kogum igaks juhuks, vaid vastupidi - esiteks - lihtne mootor, millel on lihtne võimalus ise tšekke luua. Enda kontrollide loomine okerris ei ole häkkerite, süsteemi kaasarendajate või vähemalt kogenud okerri kasutajate ülesanne, vaid iga administraatori jaoks, kes installis Linuxi kuu aega tagasi esimest korda.

Miinimumpalkade kontroll toimub mooduli kaudu runstatus:

See rida konfiguratsioonis runstatus teavitab teid, kui /bin/true äkki ei käivitu või tagastab midagi muud kui 0.

true_OK=/bin/true

Ainult üks rida - ja siin me oleme juba natuke laiendatud funktsionaalsus okerr.

Isegi sellisel kontrollil on juba oma väärtus: kui teie server äkki jookseb kokku, ei värskendata okerr serveri vastavat indikaatorit õigel ajal ja pärast aja möödumist ilmub hoiatus.

See kontroll annab teada, et apache2 server jooksis kokku (noh, kunagi ei tea...):

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

Seega, kui räägite mis tahes programmeerimiskeelt ja oskate vähemalt shelliskripte kirjutada, saate juba oma tšekke lisada.

Keerulisem - okerrmodi jaoks saate kirjutada (mis tahes keeles) oma mooduli. Lihtsamal juhul näeb see välja järgmine:

#!/usr/bin/python3

print("STATUS: OK")

Kas pole väga raske? Moodul peab ise kontrolli tegema ja tulemused STDOUT-i väljastama. Keerulisem moodul annab näiteks järgmise:

$ 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

See värskendab mitut indikaatorit korraga (eraldatuna tühja reaga), vajadusel loob need, näitab kontrollimise üksikasju ja sildi, mille abil on armatuurlaual lihtne leida vajalikke indikaatoreid.

Telegramm

Seal on Telegrami robot @OkerrBot. Te ei pea oma telefoni eraldi rakendustega segama (mulle ei meeldi, et Pyaterochka jaoks on vaja ühte kaardiga rakendust, Lenta jaoks teist, MTS-i jaoks kolmandat ja nii edasi kõigile, kõigile, kõigile). Piisab ühest telegrammist. Telegrami kaudu saate koheselt teateid, kontrollida projekti olekut ja anda käsu kõiki probleemseid indikaatoreid uuesti kontrollida. Lahkusime teatrist/lennukist, ei hoidnud kaks tundi näppu pulsil, lülitasime telefoni sisse, vajutasime chatbotis ühte nuppu ja veendusime, et kõik on korras.

Olekulehed

Tänapäeval on olekulehed peaaegu kohustuslikud igale ettevõttele, kus on IT, vastutustundlik suhtumine usaldusväärsusesse ja mis kohtleb oma kliente/kasutajaid austusega.

Kujutage ette olukorda – kasutaja soovib midagi teha, teavet vaadata või tellimust esitada ja midagi ei tööta. Ta ei tea, mis toimub, kelle poolel probleem on ja millal see lahendatakse. Võib-olla on teie ettevõttel lihtsalt mittetoimiv veebisait? Või läks see katki kuus kuud tagasi ja kahe aasta pärast saab korda? Aga külmkapp on vaja kohe osta, see on juba kärus... Ja hoopis teine asi on see, kui inimene näeb, et sinuga on midagi valesti (vähemalt on selge, et probleem pole tema poolel), et probleem on avastatud, et te juba töötate selle kallal ja võib-olla kirjutasite isegi ligikaudse parandamise aja. Kasutaja saab tellida ja saada meiliteate, kui probleem on lahendatud ja ta saab teha, mida ta tahtis (osta külmkapp).

Probleeme ja seisakuid juhtub kõigil. Kuid kasutajad ja partnerid usaldavad rohkem neid, kes on oma lähenemisviisis läbipaistvamad ja vastutustundlikumad.

siin on ülevaade 10 muust projektist, mis võimaldavad teil luua olekulehti. Siin on näited selle kohta, kuidas need projektilehed välja näevad Python и edastuskast. okerri olekuleht.

Failover

Et mitte seda artiklit veelgi pikemaks muuta, viitan veel kord oma eelmisele artiklile - Lihtne veebisaidi tõrkeotsas . Kui saate teha duplikaatserveri, siis tõrkesiirde kasutamisel ei ole teil põhimõtteliselt pikka seisakut – niipea, kui probleem avastatakse, suunatakse kasutajad automaatselt ümber töötavasse varuserverisse. Ja mulle tundub, et see on väga huvitav, särav funktsioon, mis on harva saadaval.

Madalad süsteeminõuded

Okerr serverite jaoks kasutame masinaid RAM-iga alates 2Gb. Võrguandurite jaoks piisab isegi 512Mb-st. Kliendi osa on üldiselt peaaegu null. (Kilekott okerruptate kaalub 26 Kb, kuid nõuab Python3 ja standardseid teeke). Klient töötab cron-skriptist, seega ei tarbi see püsivat mälu. Jälgitavatest masinatest on meil sensorid (üliodav VPS 512Mb RAM-iga) ja Raspberry Pi. See on võimalik ka ilma kliendiosata saata uuendusi curli kaudu! (vt allpool)

Seda arvesse võttes - okerr, ilmselt kõige tasuta jälgimissüsteemi olemasolevatest, sest isegi mõne muu tasuta avatud lähtekoodiga süsteemi nagu Zabbix või Nagios kasutamiseks tuleb sellele eraldada ressursse (serverit) ja see on juba raha. Lisaks on vaja veel mõningast serverihooldust. Okerri abil saab selle osa eemaldada. Või ei pea te seda eemaldama ja kasutama oma serverit, olenevalt sellest, mis teile kõige rohkem meeldib.

API ja integreerimine patenteeritud tarkvarasse

Lihtne ja avatud arhitektuur. okerril on üsna lihtne API, millega on lihtne töötada. Kas peate looma 1000 näitajat? Seda teeb üks 3-4-realine shelliskript. Kas peate 1000 indikaatorit ümber seadistama? See on ka väga lihtne. Näiteks tahame veelkord kontrollida kõiki meie HTTPS-i sertifikaate Venemaa andurilt:

#!/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 saate värskendada meie kliendimooduli abil, 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/

Näitajaid saate värskendada otse oma programmist. Näiteks südamelöögi signaalide saatmine, et okerr teaks, et see töötab, ja annab häire, kui see kokku jookseb või külmub. Muide, okerr komponendid just seda teevad – okerr jälgib ennast ning peaaegu iga mooduli probleemid tuvastatakse ja genereeritakse probleemi kohta hoiatus. (Ja selle "peaaegu" puhul - neid kontrollitakse teisest serverist)

Siin on kood (lihtsustatud) meie telegrammi robotis:

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))

Pythoni programmide indikaatorite värskendamiseks on raamatukogu okerruptate, teiste keelte jaoks pole teeke, kuid saate helistada skriptile okerrupdate või teha HTTP-päringu okerr-serverile.

Kuidas okerr meid aitab

Okerr muutis meie elu. Tõepoolest. Võib-olla saaks sama teha ka mõni teine seiresüsteem, kuid meie jaoks on okerriga töötamine lihtne ja lihtne ning sellel on kõik vajalikud funktsioonid (lisasime selle, mida tal polnud). Muide, kui mõni funktsioon on puudu, küsige ja lisan need (ma ei luba, aga ma tahan, et okerr oleks parim jälgimissüsteem väikeste ja keskmiste projektide jaoks). Või veel parem, lisage see ise – see on lihtne.

Meil õnnestus elada põhimõtte järgi "õppige kõigist probleemidest kerrast". Kui äkki ilmneb probleem, millest me okerrist teada ei saanud, lisame okerrile tšeki. (antud juhul pean "meie" all silmas meid kui süsteemi kasutajaid, mitte kaasarendajaid). Alguses oli see tavaline, kuid nüüd on see muutunud väga haruldaseks.

Jälgimine

Okerri kaudu jälgime logide suurusi kõigis serverites. Iga palgi rida mõtlikult silmaga lugeda on muidugi võimatu, aga lihtsalt kasvutempo jälgimine annab juba palju. Selle kaudu avastasime rämpsposti ja brute force parooliotsingud ning kui mõni rakendus "hulluks läheb", siis midagi ei õnnestu neil ja nad kordavad seda ikka ja jälle (iga kord lisades logisse paar rida ).

SSL-sertifikaadid. Peaaegu kohe pärast käivitamist LetsEcrypt meie klient hakkas oma klientidele (umbes tuhandele) tasuta SSL-sertifikaate pakkuma. Ja see osutus haldamise jaoks lihtsalt põrguks! Fakt on see, et saidid on "reaalajas", kliendid paluvad neil perioodiliselt midagi teha, programmeerijad teevad seda. Nad võivad saidi täiesti vabalt üle kanda näiteks teisele DocumentRootile. Või lisage virtualhosti konfiguratsioonile tingimusteta ümberkirjutamine. Loomulikult katkeb pärast seda sertifikaatide automaatne uuendamine. Nüüd oleme kõik SSL-hostid lisatud okerri automaatselt mõne muu kasuliku utiliidi kaudu paketis a2conf. Käivitame lihtsalt a2okerr.py — ja kui serverisse ilmub mitu uut saiti, ilmuvad need automaatselt okerris. Kui äkki mingil põhjusel sertifikaati ei uuendata, siis kolm nädalat enne sertifikaadi kehtivusaja lõppu oleme kursis ja selgitame välja, miks seda ei uuendata, selline koer. a2certbot.py samast paketist - see aitab selle vastu palju (kontrollib kohe kõige tõenäolisemad probleemid - ja kirjutab hästi, mida kontrolliti ja kus on kõige tõenäolisem probleem).

Jälgime kõigi oma domeenide aegumiskuupäevi. Ja kõiki meie meiliservereid, mis kirju saadavad, kontrollitakse 50+ erineva musta nimekirja alusel. (Ja mõnikord kukuvad nad neisse). Muide, kas teadsite, et ka Google'i meiliserverid on mustas nimekirjas? Lihtsalt enesetestimiseks lisasime jälgitavatesse serveritesse aadressi mail-wr1-f54.google.com ja see on endiselt SORBSi mustas nimekirjas! (See on umbes rämpspostivastaste väärtus)

Varukoopiad - ma juba eespool kirjutasin, kui lihtne on neid okerriga jälgida. Kuid me jälgime nii oma serveri uusimaid varukoopiaid kui ka (kasutades eraldi utiliiti, mis kasutab okerr) varukoopiaid, mille Amazon Glacieri üles laadime. Ja jah, probleeme tuleb aeg-ajalt ette. Pole ime, et nad vaatasid.

Kasutame eskalatsiooniindikaatorit. See näitab, kui mõnda probleemi pole pikka aega lahendatud. Ja ma ise, kui ma lahendan mingeid probleeme, võin need mõnikord unustada. Eskaleerimine on hea meeldetuletus, isegi kui jälgite ennast.

Üldiselt usun, et meie töö kvaliteet on suurusjärgus tõusnud. Seisakuid peaaegu pole (või pole kliendil aega seda märgata. Lihtsalt psh!), samas on töömaht vähenenud ja töötingimused rahulikumaks muutunud. Oleme teibiga aukude lappimisega avariitöödelt liikunud rahulikule ja mõõdetud tööle, mil palju probleeme ennustatakse ette ja on aega neid ennetada. Ka juhtunud probleeme on lihtsam parandada: esiteks saame neist teada enne, kui kliendid satuvad paanikasse, teiseks juhtub sageli, et probleem on seotud hiljutise tööga (ühe asja tegemisel rikkusin teise ära) - nii et see on kuum Jälgedel on sellega lihtsam toime tulla.

Aga oli veel üks juhtum...

Kas teadsite, et populaarses versioonis Debian 9 (Stretch) on selline populaarne pakett nagu phpmyadmin endiselt (palju kuid!) haavatavas olekus? (CVE-2019-6798). Kui haavatavus ilmnes, katsime selle kiiresti erinevatel viisidel. Kuid seadistasin okerris turvajälgija lehe jälgimise, et teada saada, millal "ilus" lahendus välja tuleb (sisu SHA1 summa kaudu). Indikaator tõmbles mind mitu korda, leht muutus, aga nagu näha, siis see ikkagi (alates jaanuarist 2019!) ei näita, et probleem oleks lahenenud. Äkki keegi teab, muide, milles probleem on, et nii oluline pakett on veel üle aasta haavatav?

Teine kord sarnases olukorras: pärast SSH haavatavust oli vaja kõiki servereid värskendada. Ja kui määrate ülesande, peate täitmist kontrollima. (Aluvad kipuvad valesti aru saama, unustavad, satuvad segadusse ja teevad vigu). Seetõttu lisasime esmalt kõigis serverites okerrile SSH versioonikontrolli ja okerri kaudu veendusime, et värskendused on kõigis serverites kasutusele võetud. (Mugav! Valisin seda tüüpi indikaatori ja kohe on näha, millisel serveril mis versioon on). Kui olime kindlad, et ülesanne on kõigis serverites täidetud, eemaldasime indikaatorid.

Paar korda oli olukord, kus mingi probleem tekib ja läheb siis ise üle. (ilmselt kõigile tuttav?). Selleks ajaks, kui märkad, kontrollimise ajaks – ja pole midagi kontrollida – töötab kõik juba hästi. Aga siis läheb jälle katki. Meil juhtus see näiteks toodetega, mille laadisime üles Amazon Marketplace'i (MWS). Mingil hetkel oli laetud laovaru vale (valed kaubakogused ja valed hinnad). Me mõtlesime selle välja. Kuid selle väljaselgitamiseks oli oluline probleemist kohe teada saada. Kahjuks on MWS, nagu kõik Amazoni teenused, veidi aeglane, nii et alati oli viivitus, kuid siiski suutsime vähemalt umbkaudselt mõista seost probleemi ja seda põhjustavate skriptide vahel (tegime kontrolli, jäime kinni selle okerrile ja kontrollis seda kohe, saades hoiatuse).

Huvitava korpuse lisas hiljuti kollektsiooni üks suur ja kallis Euroopa hoster, mida meie klient kasutab. Järsku kadusid radarilt KÕIK meie serverid! Esiteks märkas klient ise (kiirem kui okerra!), et sait, millega ta töötas, ei avane ja tegi selle kohta pileti. Kuid mitte ainult üks sait ei langenud alla, vaid kõik! (Nataša, me jätsime kõik maha!). Siin hakkas Okerr saatma pikki jalamähiseid koos kõigi talle süttivate indikaatoritega. Paanika, paanika, jookseme ringides (mida veel teha saab?). Siis kõik tõusis. Selgub, et andmekeskuses toimus rutiinne hooldus (kord mitme aasta tagant) ja loomulikult oleks pidanud meid hoiatama. Kuid nendega juhtus mingi probleem ja nad ei hoiatanud meid. Noh, rohkem infarkte, vähem infarkte. Kuid pärast seda, kui kõik on taastatud, peate kõike veel kord üle kontrollima! Ma ei kujuta ette, kuidas ma seda oma kätega teeksin. Okerr testis kõike mõne minutiga. Selgus, et enamus serveritest olid lihtsalt ajutiselt kättesaamatud, kuid töötasid. Mõned olid ülekoormatud, aga tõusid ka püsti nagu pidi. Kõigist kaotustest jäime ilma kahest varukoopiast, mis kroonu järgi oleks pidanud tekkima ja laadima sel ajal, kui see täis banaan käis. Ma isegi ei viitsinud neid luua, vaid päev hiljem saabusid teated, et kõik on korras, varukoopiad on ilmunud. Mulle see näide väga meeldib, sest okerr osutus väga kasulikuks olukorras, millele me isegi ei olnud ette mõelnud, aga see ongi jälgimise eesmärk - vastu seista ettearvamatule.

Okerri andurite puhul kasutame võimalikult odavat hostimist (kus kvaliteet ja töökindlus ei ole olulised, siis need kindlustavad üksteist). Niisiis, leidsime hiljuti väga hea ja üliodava hostimise, etalonid on ägedad. Aga... vahel tuleb välja, et virtuaalmasinast väljuvad ühendused tehakse teisest (naaber-) IP-st. Imed. Client_ip moodul koos https://diagnostic.opendns.com/myip saab vale IP. Ja indikaatori serverilogidest on selgelt näha, et uuendus tuli ka sellelt naaber-IP-lt. Tegeleme nüüd toetusega. Hea, et rahuajal seda märkasime. Aga näiteks tihti juhtub, et ligipääs registreeritakse IP valge nimekirja järgi – ja kui server vahel niimoodi lühikest aega vilksatab – siis võib väga pikalt proovida seda probleemi tabada.

Noh, veel üks asi – kuna me räägime VPS-i hostimisest – kasutame alati odavaid (hetzner, ovh, scaleway). Mulle väga meeldib nii etalonide kui ka stabiilsuse poolest. Kasutame ka teiste projektide jaoks palju kallimat Amazon EC2. Nii et tänu okerrile on meil oma teadlik arvamus. Mõlemad kukuvad. Ja ma ei ütleks, et meie vaatluste pika aja jooksul osutusid odavad hostid nagu hetzner märgatavalt vähem stabiilseks kui EC2. Seega, kui te pole seotud muude Amazoni funktsioonidega, siis miks maksta rohkem? 🙂

Mis edasi?

Kui ma pole teid selles etapis veel Okerrist eemale peletanud, siis proovige seda! Võite minna otse sellele lingile okerr demokonto (Klõpsake kohe!) Kuid pidage meeles, et kõigi jaoks on ainult üks demokonto, nii et kui teete midagi, võib keegi teine samal kontol teid samal ajal segada. Või (parem) registreeruge lingi kaudu väljastpoolt okerr - kõik on lihtne, ilma SMS-ita. Kui teile ei meeldi kasutada oma päris e-posti, võite kasutada ühekordset e-posti, näiteks mailinaatorit (soovitan getnada.com). Sellised kontod võidakse aja jooksul kustutada, kuid need sobivad testimiseks.

Pärast registreerimist palutakse teil läbida koolitus (sooritada mitu mitte väga rasket treeningülesannet). Esialgsed limiidid on väga väikesed, kuid koolituseks või ühe serveri jaoks neist piisab. Peale koolituse läbimist tõstetakse limiite (näiteks maksimaalne näitajate arv).

Dokumentatsioonist – esiteks WIKI serveri poolel ja kliendil (okerrupdate wiki). Kui aga midagi jääb arusaamatuks, kirjuta support (at) okerr.com või jäta pilet – proovime kõik kiiresti lahendada.

Kui kasutate seda tõsiselt ja nendest suurenenud limiitidest ei piisa, kirjutage toele ja me suurendame seda (tasuta).

Kas soovite installida okerr serveri oma serverisse? Siin okerr-dev hoidla. Soovitame installida puhtasse virtuaalmasinasse, siis saate seda teha lihtsalt installiskriptiga. Teie virtuaalmasinas - piiranguid pole :-). Jällegi, kui midagi juhtub, püüame alati aidata.

Tahame, et see projekt saaks hoogu, et maailm muutuks tänu meile usaldusväärsemaks. Tänu tasuta tarkvarale ja teenustele on maailm muutunud sõbralikumaks ja areneb dünaamilisemalt. Allikaid saab salvestada tasuta githubi, posti jaoks saate kasutada tasuta gmaili. Kasutame tasuta värsked tööd toetuse eest. Selle jaoks ei pea te serverite eest maksma, ei pea alla laadima ja konfigureerima ega lahendama mitmesuguseid tööprobleeme. Igal uuel projektil, igal meeskonnal on kohe post, hoidlad ja CRM. Ja kõik see on väga kvaliteetne ja tasuta ja kohe. Tahame, et nii oleks ka monitooringuga - väikefirmad ja projektid saaksid okerrit tasuta kasutada ning isegi sünni- ja kasvufaasis omaksid täiskasvanute tõsiste projektide usaldusväärsust.

Allikas: www.habr.com

Okerri hübriidseiresüsteemi ülevaade