Para dy vjetësh kam bërë një postim Failover i thjeshtë për website-in për okerr. Tani ka disa zhvillime në projekt, dhe ndryshe, kam publikuar kodin burimor të pjesës serverike të okerr nën licencë të hapur, prandaj vendosa të shkruaj këtë përmbledhje të vogël për Habr.

Kush mund të jetë i interesuar për këtë

Kjo mund t'ju interesojë nëse punoni në një ekip të vogël ose madje vetëm. Nuk keni monitorim dhe nuk jeni të sigurt nëse vërtet ju nevojitet. Ose keni provuar ndonjë monitorim të njohur dhe serioz 'për djemtë e mëdhenj', por për ju si që duket nuk është 'ngjitur', ose funksionon në një konfigurim pothuajse default dhe nuk ka ndryshuar shumë jetën tuaj. Gjithashtu — nëse me siguri nuk planifikoni të angazhoni një punonjës (e madhe) për të monitoruar të paktën disa orë në ditë në dashboard-in e monitorimit ose për ta konfiguruar atë.

Cila është veçoria e jashtëzakonshme e okerr

Më pas do të tregoj karakteristikat interesante të okerr-it, të cilat e dallojnë atë nga disa monitorime të tjera.

Okerr është një monitorim hibrid

Gjatë monitorimit të brendshëm, në makinat e vëzhguara funksionon një "agjent", i cili transmeton të dhënat në serverin e monitorimit (për shembull, hapësira e lirë në disqe). Gjatë monitorimit të jashtëm, serveri kryen verifikime përmes rrjetit (për shembull, ping ose aksesueshmëria e një faqe interneti). Çdo qasje ka kufizimet e saj. Okerr përdor të dyja variantet. Verifikimet brenda serverëve kryhen nga një agjent shumë të lehtë (30Kb) ose nga skriptet dhe aplikacionet tuaja, ndërsa ato rrjetore përmes sensorëve okerr në vende të ndryshme.

okerr — nuk është thjesht një soft, por gjithashtu një shërbim

Pjesa serverike e çdo monitorimi është një gjë e madhe dhe komplekse, e cila është e vështirë për t'u instaluar dhe konfiguruar, dhe kërkon burime. Me okerr mund të vendosni serverin tuaj të monitorimit (ai është falas dhe opensource), ose mund të përdorni vetëm pjesën klientike dhe të shfrytëzoni shërbimin e serverit tonë. Edhe kjo është falas.

Nëse mbikëqyrja lejon të kompensosh, të mbulosh mungesën e besueshmërisë në serverë dhe aplikacione, ngrihet një pyetje filozofike — kush e ruan ruajtësin? Si do na njoftojë mbikëqyrja për një problem, nëse ajo vetë "vdes" për ndonjë arsye, veçmas ose së bashku me burime të tjera tuaja (p.sh., shkëputja e kanalit në qendrën e të dhënave)? Përdorimi i shërbimit të jashtëm okerr zgjidh këtë problem — do të merrni një alert edhe nëse e gjithë qendra e të dhënave me serverët tuaj do të jetë pa energji ose do t'i nënshtrohet një sulmi zombie.

Sigurisht, ka një rrezik që serveri okerr vetë të mos jetë i qasshëm, është e vërtetë (siç dihet, 90% e besueshmërisë arrihen gjithmonë thjesht dhe "falas", 99% — me minimum përpjekjesh, dhe çdo nënshkrim tjetër i nëntë — eksponencialisht më i komplikuar). Por, fillimisht, shanset për këtë janë më të ulta, dhe së dyti, problemi mund të mbetet i paepur vetëm nëse ndodh përkohësisht me problemet në serverët tanë. Nëse ne kemi besueshmëri 99.9% dhe ju keni 99.9% (numra jo shumë të lartë), atëherë shansi për një dështim të paepur — 0.1% nga 0.1% = 0.0001%. Të shtosh tre nëntë në besueshmëri thuajse pa përpjekje dhe pa shpenzime — është shumë e mirë!

Një tjetër përfitim i mbikëqyrjes si shërbim është se ofruesi i hostimit ose studioja e uebit mund të vendosë serverin okerr dhe t'i ofrojë klientëve akses si një shërbim shtesë me pagesë ose falas. Konkurentët tuaj ofrojnë thjesht hostim dhe faqe — ndërsa ju ofroni hostim të besueshëm me mbikëqyrje.

Okerr — kjo është për treguesit

Treguesi është një "dritë". Ai ka dy gjendje kryesore — e gjelbër (OK) ose e kuqe (ERR). Në projekt ka shumë tregues të grumbulluar (p.sh., sipas serverëve). Në faqen kryesore të projektit, ju menjëherë mund të shihni nëse gjithçka është e gjelbërt (dhe mund ta mbyllni), ose nëse diçka është e kuqe dhe duhet të rregullohet. Kur vazhdohet midis këtyre gjendjeve — dërgohet një njoftim. Një herë në ditë, ndërsa e konfiguroni — dërgohet një përmbledhje për projektin.

Çdo indikator okerr ka kushte të integruara, sipas të cilave ndryshon gjendja e tij (në Zabbix kjo quhet trigger). Për shembull, ngarkesa mesatare nuk duhet të jetë më shumë se 2 (sigurisht, kjo është e konfigurueshme). Dhe për secilën kontrollim të brendshëm (ngarkesa mesatare, hapësira e diskut, …) — ka një watchdog. Nëse për ndonjë arsye nuk kemi marrë një konfirmim të suksesshëm në kohën e caktuar — regjistrohet një gabim dhe dërgohet një alert.

Schemi i zakonshëm i punës për ne është — kontrolli i mëngjesit të postës, ku mes e-maileve të tjera shikojmë përmbledhjen (koha e saj caktuar në fillim të punës). Nëse gjithçka është në rregull në të — merren me punë të tjera të rëndësishme (por mund të shikojmë shpejt në dashboard-in e okerr-it për siguri, për t'u siguruar se gjithçka është e gjelbër në atë minutë). Nëse vjen një alert — reagojmë.

Sigurisht, ka mundësinë për të mbajtur thjesht indikatorë ‘informativë’ (për të parë pamjen e rrjetit nga monitorimi), por gjithçka është bërë për të lehtësuar, thjeshtuar dhe për të krijuar shpejt indikatorë për vëzhgimin automatik dhe dërgimin e alerteve.

Qëllimi për të cilin po konfiguroni okerr — është në alerte, që të mund të krijoni një tregues brenda një minute. Ai mund të ketë «fjetur» për një vit, thjesht duke pranuar përditësime, dhe kur pas një viti diçka ju dëmtohet — ai ndizet dhe dërgon alarmin. Koha që keni shpenzuar një herë për të krijuar treguesin është shpërblyer; ju e mësuat probleme menjëherë, para të gjithëve. Mund të keni edhe rregulluar, përpara se dikush ta vërejë. E ngritur shpejt nuk konsiderohet e rënë!

Siguria

Do të ishte keq nëse vendosni monitorimin për të rritur besueshmërinë, dhe si rezultat — ju sulmoheni përmes tij, dhe ka shumë vulnerabilitete në rrjet të mjeteve të ndryshme të monitorimit (Zabbix, Nagios).

Agjenti (okerrmod nga paketa okerrupdate), që funksionon në sistem — nuk është një server rrjeti, por një klient. Prandaj në serverin e monitoruar nuk ka porte të hapura shtesë; klienti punon lehtësisht pas një firewall-i ose NAT-i dhe është shumë e vështirë (do ta quaja «të pamundur») ta thyejësh në rrjet, pasi nuk dëgjon asnjë socket rrjeti.

Diagnozë e plotë e monitorimit

Tani kemi një rregull — ne zbulojmë të gjithë problemet teknike nga okerr. Nëse ndonjëherë rregulli shkelet (okerr nuk njofton për ndodhinë e saj të afërt (nëse kjo është e mundur) ose për atë që ka ndodhur tashmë) — ne shtojmë kontrollime në okerr.

Kontrollime të jashtme

Një grup i zakonshëm:

ping
http status
kontrolli i vlefshmërisë dhe freskisë së certifikatës SSL (do të njoftojë nëse afati skadon së shpejti)
TCP port i hapur dhe banner mbi të
http grep (në faqe [nuk] duhet të ketë një tekst të caktuar)
sha1 hash për të kapur ndryshimin e faqeve.
DNS (regjistri DNS duhet të ketë një vlerë të caktuar)
WHOIS (do të njoftojë nëse domeni skadon së shpejti)
Antispam DNSBL (kontrolli i hostit në 50+ lista të zezë antispam)

Kontrollime të brendshme

Po ashtu, një grup i zakonshëm (por i lehtë për t'u zgjeruar).

df (hapësira e lirë në disqe)
load average
opentcp (TCP socket të hapur — do të njoftojë nëse diçka ka filluar ose ka rënë)
uptime — thjesht uptime në server. Do të njoftojë nëse ndryshon për poshtë (dmth. serveri është ri-ngarkuar)
client_ip
dirsize — e përdorim për të monitoruar kur virtualkët rootfs përjashtohen nga madhësia e lejuar, pa vendosur kufizime të rrepta, dhe për madhësitë e katalogëve të përdoruesve.
empty dhe nonempty — monitorojnë skedarët që duhet të jenë të zbrazët (ose jo të zbrazët). Për shembull, regjistri i gabimeve të shërbimit të serverit okerr — duhet të jetë i zbrazët, dhe nëse ka edhe një rresht — do të marr një njoftim dhe do ta kontrolloj. Ndërsa mail.log në serverin e postës duhet të JETË JO i zbrazët (pas N minutash pas rotacionit). Disa herë na ka ndodhur të jetë të zbrazët, pas përditësimit të sistemit, kur logrotate nuk arriti të rihapë saktësisht rsyslog.
linecount — numri i rreshtave në skedar (si wc -l). E përdorim si një zëvendësim më të butë për empty, kur regjistri i gabimeve mund të rritet, por vetëm ngadalë (p.sh., googlebot përpiqet të hyjë në disa faqe të mbyllura). Ka një limit prej 2 rreshtash në 20 minuta. Nëse përfundojmë mbi këtë — do të ketë një alarme.

Kontrollime interesante të brendshme.

Nëse derisa lexuat deri në këtë pikë e bëtë «në diagonale», tani do të jetë më interesante të lexoni me kujdes.

backups

Ndjek backup-et në katalog. Ndër ne, skedarët e backup-it kanë emra si «ServerName-20200530.tar.gz». Për çdo server në okerr krijohet një indikator ServerName-DATE.tar.gz (data aktuale ndryshohet me rreshtin «DATE»). Ndjeket edhe prania e një backup-i të ri dhe madhësia e tij (p.sh., nuk mund të jetë më e vogël se 90% e backup-it të mëparshëm).

Çfarë duhet të bëjmë që një backup i ri të fillojë të ndiqet, pasi e kemi filluar ta krijojmë dhe ta vendosim në këtë katalog? Asgjë! Ky është një qasje shumë e përshtatshme, kur duhet të bëni «asgjë», sepse:

Të bësh «asgjë» është mjaft e shpejtë, kursen kohë
E vështirë që të harrosh të bësh «asgjë»
E vështirë që të bësh «asgjë» gabim. Asgjë – është metoda më e besueshme

Nëse ndodhi që të mos shfaqen më skedarë të rinj të backup-it – do të ketë një alarme. Nëse, për shembull, keni çaktivizuar një nga serverët dhe backup-et e tij nuk duhet të jenë më – do t'ju nevojitet të fshini indikatorin (nëpërmjet ndërfaqes së internetit ose nga shell përmes API).

maxfilesz

Ndjek madhësinë e skedarëve më të mëdhenj (zakonisht: /var/log/*). Kjo lejon kapjen e problemeve të paparashikueshme, p.sh., tentativat për të thyer fjalëkalimet ose shpërndarjen e spamit përmes serverit.

runstatus/runline

Këto janë dy module proxy të rëndësishme për të ekzekutuar programe të tjera në server. Runstatus raporton statusin e daljes së programit. Për shembull, në okerr nuk ka (nuk kërkohet) një modul për të kontrolluar nëse shërbimet systemd funksionojnë. Kjo bëhet përmes runstatus (shih më poshtë). Runline raporton në server rreshtin që jep programi. Për shembull, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" në konfigurimin e Runline në serverin tonë krijon një tregues servername:temp me temperaturën e procesorit.

sql

Ekzekuton një pyetje numerike në MySQL dhe raporton rezultatin në tregues. Në rastin më të thjeshtë, mund të bëni, për shembull, «SELECT 1» — kjo do të kontrollojë nëse në përgjithësi DBMS funksionon.

Por një aplikim shumë më interesant — për shembull, të ndjekësh numrin e porosive në një dyqan online. Nëse e dini që çdo orë keni 100 porosi, mund të vendosni një kufi minimal prej 100 ose 80. Atëherë nëse papritur ju bien shitjet — do të merrni një alarëm dhe do të mund të zgjidhni çështjen.

Vini re — nuk ka rëndësi për arsyen e paparashikueshme përse ka ndodhur kjo:

Serveri thjesht nuk është i aksesueshëm (i pa energji ose pa rrjet), dhe alarami ka ardhur sepse treguesi është 'prishur'.
Serveri është i ngarkuar, punon ngadalë, ose paketat po humbasin, përdoruesit ndihen të pakënaqur dhe largohen pa blerë.
Serveri është futur në listat e spam-it dhe postat nga ai nuk pranohen, përdoruesit nuk mund të regjistrohen.
Buxheti i fushatës reklamuese është mbaruar, banneret nuk po shfaqen.

Mund të ketë shumë arsye dhe nuk mund të parashikohet gjithçka paraprakisht, ndërsa është teknikisht e vështirë të monitorohet. Por mund të monitorohet lehtë parametri përfundimtar (porositë) dhe në bazë të tyre të përcaktohet se situata është e dyshimtë dhe kërkon verifikim.

Të dhënat logjike

Lejon përdorimin e shprehjeve logjike (përgjegjshmëria Python) përmes modulit evalidate(artikulli në Habrë). Për shprehjen, të dhënat e projektit dhe treguesve të tij janë në dispozicion. Për shembull, në kapitullin më lart mbi verifikimin SQL, ndoshta e keni vënë re një pikë të dobët — gjatë ditës kemi deri në 100 shitje në orë, por natën — 20, dhe kjo është normale, nuk është problem. Si të veprojmë? Treguesi do të panikonte vazhdimisht natën.

Mund të krijoni dy indikatorë, një të ditës dhe një të natës. Të dy t'i bëni «të qetë» (nuk do të dërgojnë njoftime). Po ashtu, të krijoni një indikator logjik, i cili kërkon që deri në orën 20:00 indikatorët e ditës të jenë në rregull, dhe pas orës 20:00, mjafton që indikatori i natës të jetë OK.

Një shembull tjetër i përdorimit të indikatorit logjik është eskalimi. Për shembull, menaxheri i projektit hiqet nga njoftimet (ai nuk e ka nevojën, administratorët duhet të reagojnë ndaj problemeve normale), por lidhet me indikatorin logjik, i cili nxjerr ngjyrë të kuqe nëse ndonjë indikator në projekt nuk është rregulluar brenda kohës së caktuar.

Po ashtu, ekziston mundësia për të caktuar një kohë të lejuar për punë, për shembull, nga ora 3 deri në 5 të mëngjesit. Nuk na shqetëson nëse serverët dhe faqet bien në këtë kohë. Por në orën 5:00, ato duhet të funksionojnë. Nëse nuk funksionojnë në ndonjë kohë tjetër—do të ketë një alerter. Gjithashtu, indikatorët logjikë lejojnë të merret parasysh rezervimi i serverëve. Nëse keni 5 serverë web, atëherë administratorët mund të fikën 1-2 serverë në çdo kohë. Por nëse në funksion do të ketë më pak se 3 nga 5 serverët—do të ketë një alerter.

Shembujt më sipër nuk janë funksione të okerr, as ndonjë tipar që duhet aktivizuar dhe konfiguruar. Të gjitha këto funksione nuk i gjenden në okerr, por ekziston një modul logjik që mundëson realizimin e këtij funksionaliteti (Mund të krahasohet me një gjuhë programuese — nëse kemi operatorë aritmetikë, atëherë nuk na nevojitet një funksion i veçantë për llogaritjen e 20% TVSH, sepse mund ta bëjmë vetë sipas nevojave tona).

Indikatori logjik, ndoshta, është një nga temat relativisht të ndërlikuara në okerr, por lajm i mirë është se nuk keni nevojë t'i mësoni ato derisa të lindë nevoja. Megjithatë, ato zgjasin shumë mundësitë, duke e mbajtur sistemin vetë mjaft të thjeshtë.

Shtimi i kontrollit tuaj

Doja të theksoja se okerr nuk është një grup me mijëra kontrolle të gatshme për çdo rast, por përkundrazi — në radhë të parë — një motor i thjeshtë me mundësinë e thjeshtë për të krijuar kontrollet tuaja. Krijimi i kontrolleve tuaja në okerr nuk është një detyrë për hakerët, bashkë-zhvilluesit e sistemit, ose të paktën për përdoruesit e avancuar të okerr, por është një detyrë e realizueshme për çdo administrator që një muaj më parë ka instaluar për herë të parë linux.

Kontrollat në minimum bëhen përmes modulit statusi:

Kjo rresht në konfigurim statusi do të njoftojë nëse ndonjëherë "/bin/true" nuk fillon ose kthehet me jo 0.

true_OK="/bin/true"

Një rresht i vetëm — dhe ja ku ne kemi zgjeruar pak funksionalitetin okerr. Madje edhe kjo kontrolle — ka vlerën e saj: nëse ndonjëherë serveri juaj bie — treguesi përkatës në serverin okerr nuk do të përditësohet në kohë, dhe pas kalimit të kohës do të shfaqet një alarme.

Ky kontroll do të njoftojë që serveri apache2 ka rënë (së paku…):

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

Pra, nëse zotëroni ndonjë gjuhë programimi, të paktën mund të shkruani skripte shell — atëherë ju mund të shtoni kontroll të tuajat.

Më komplekse — mund të shkruani (në çfarëdo gjuhe) modul tuaj për okerrmod. Në rastin më të thjeshtë duket kështu:

E vërtetë, nuk është shumë e ndërlikuar? Moduli duhet të bëjë kontrollin vetë dhe të japë rezultatet në STDOUT. Një modul më kompleks jep, për shembull, këtë:

#!/usr/bin/python3

print("STATUS: OK")

$ okerrmod --dump df NAME: pi:df-/ TAGS: df METHOD: numerical|maxlim=90 DETAILS: 49.52%, 13.9G/28.2G përdorur, 13.0G të lirë STATUS: 49.52NAME: pi:df-/boot TAGS: df METHOD: numerical|maxlim=90 DETAILS: 84.32%, 53.1M/62.9M përdorur, 9.9M të lirë STATUS: 84.32

$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G përdorur, 13.0G të lirë
STATUS: 49.52

NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M përdorur, 9.9M të lirë
STATUS: 84.32

Ai përditëson disa tregues menjëherë (të ndara me një linjë të bardhë), dhe nëse është e nevojshme, krijon ato, përcakton detajet e kontrollit dhe etiketën, e cila lehtëson gjetjen e treguesve të nevojshëm në panelin e kontrollit.

Ka një bot Telegram @OkerrBot. Nuk keni nevojë të mbushni telefonin me aplikacione të veçanta (as për vete nuk më pëlqen që për Pjatën nevojitet një aplikacion me hartën, për Lenten një tjetër, për MTS një të tretë, dhe kështu me radhë për të gjithë). Një Telegram është i mjaftueshëm. Përmes Telegramit mund të merrni alarmin menjëherë, të kontrolloni statusin e projektit dhe të jepni komandën për të kontrolluar përsëri të gjithë treguesit problematikë. Dola nga teatri/avioni, dy orë nuk e mbajta dorën në pulsin e situatës, aktivizova telefonin, shtypa një buton në chatbot, dhe u sigurova që gjithçka ishte në rregull.

Faqet e statusit

Në kohën tonë, faqet e statusit janë tashmë një must-have për çdo biznes që ka IT, një qëndrim të përgjegjshëm ndaj besueshmërisë dhe që respekton klientët/përdoruesit e vet.

Imagjinoni një situatë – një përdorues dëshiron të bëjë diçka, të shikojë informacion ose të bëjë një porosi, dhe diçka nuk funksionon. Ai nuk e di se çfarë është problemi, në anën e kujt është problemi dhe kur do të zgjidhet. Ndoshta kompania juaj ka një faqe të paekzekutueshme? Ose është prishur gjashtë muaj më parë dhe do të riparohen pas dy vitesh? Por frigoriferi duhet blerë tani, është në shportë… Dhe është diçka shumë ndryshe kur dikush sheh që diçka nuk është në rregull me ju (të paktën është e qartë se problemi nuk është në anën e tij), që problemi është zbuluar, se ju po punoni mbi të, dhe ndoshta madje keni shkruar një kohë të përafërt për riparimin. Përdoruesi mund të abonoheshe dhe të marrë një njoftim në email kur problemi të zgjidhet dhe të mund të bëjë atë që dëshiron (të blejë frigoriferin).

Problemet, downtime – janë të pranishme për të gjithë. Por përdoruesit dhe partnerët i besojnë më shumë atyre që janë më të hapur dhe e trajtojnë këtë në mënyrë të përgjegjshme.

Këtu është përmbledhje e 10 projekteve të tjera që lejojnë krijimin e faqeve të statusit. Këtu janë disa shembuj se si duken këto faqe te projektet Python dhe Dropbox. Faqja e statusit okerr.

Failover

Për të mos e bërë këtë artikull edhe më të gjatë, do t'i referohem sërish artikullit tim të mëparshëm — Failover i thjeshtë për website-in . Nëse mund të krijoni një server rezervë, atëherë duke përdorur failover, në thelb nuk do të keni downtime të gjatë — sa herë që problemi të zbulohet, përdoruesit automatikisht do të redirektohen në serverin rezervë në punë. Më duket se kjo është një tipar shumë interesant e tërheqës, që pak vende e kanë.

Kërkesat e ulëta për sistemin

Për serverat okerr — ne përdorim makina me RAM nga 2Gb. Për sensorët rrjetërore — madje edhe 512Mb janë të mjaftueshme. Pjesa klienti — pothuajse zero. (Pakoja okerrupdate peshon 26 Kb, por kërkon Python3 dhe bibliotekat standarde). Klienti ekzekutohet nga një skenar krone, kështu që ka konsum të vazhdueshëm zero të memories. Në mesin e makinave që po vëzhgojmë, kemi sensorë (VPS shumë të lira me 512Mb RAM) dhe Raspberry Pi. Është e mundur madje të dërgoni përditësime pa pjesën klient. përdor duke curl! (shih më poshtë)

Duke pasur parasysh këtë — okerr, ndoshta, është më e lirë Sistemi i monitorimit nga ato që kemi, sepse për të përdorur një sistem tjetër falas me burës të hapur si Zabbix ose Nagios, duhet t'i kushtoni atij burime (server), dhe kjo është tashmë një kosto. Për më tepër, kërkohet disa mirëmbajtje për serverin. Me okerr — mund ta hiqni këtë pjesë. Dhe mund ta ruani dhe të përdorni serverin tuaj, në varësi të preferencave tuaja.

API dhe integrimi në programin tuaj

Arkitekturë e thjeshtë dhe e hapur. Me okerr, kemi një API, i cili është lehtë i përdorshëm. Duhet të krijoni 1000 tregues? Një shell-skript në 3-4 rreshta mund ta bëjë këtë. Duhet të ripërruani 1000 tregues? Po ashtu shumë lehtë. Për shembull, ne duam të kontrollojmë të gjitha certifikatat tona HTTPS saktësisht nga sensori rus:

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

Për të përditësuar një tregues, mund ta bëni atë duke përdorur modulin tonë klient, ose madje edhe pa të, thjesht përmes curl.

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

Mund të përmirësoni treguesit drejtpërdrejt nga programi juaj. Për shembull, duke dërguar sinjale heartbeat, në mënyrë që okerr të dijë se është aktiv, dhe të aktivizojë alarmin nëse ka rënë ose është ngrirë. Për më tepër, komponentët e okerr e bëjnë këtë — okerr monitoron vetveten, dhe problemet në pothuajse çdo modul do të zbulohen dhe do të gjenerojnë njoftime për problemin. (Dhe për rastin e këtij «pothuajse» — ato kontrollohen gjithashtu nga një server tjetër)

Ja një kod (i thjeshtuar) në botin tonë të telegramit:

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

Për të përmirësuar treguesit nga programet Python — ekziston një bibliotekë okerrupdate, për gjuhë të tjera — nuk ka biblioteka, por mund të thërrisni skenarin okerrupdate, ose të shkrepni një kërkesë HTTP në serverin okerr.

Si na ndihmon okerr

Okerr e ka ndryshuar jetën tonë. Në të vërtetë. Mund të kishte një sistem tjetër monitorimi po ashtu, por është lehtë dhe thjeshtë të punosh me okerr dhe ofron të gjitha funksionalitetet që na duheshin (ato që mungonin — ne i shtuam). Për më tepër, nëse ndonjë funksionalitet nuk është i pranishëm — pyesni, dhe do ta shtoj (nuk premtoj, por kam dëshirë që okerr të jetë sistemi më i mirë i monitorimit për projektet e vogla dhe të mesme). Apo, më mirë akoma, shtoni vetë — është e thjeshtë.

Kemi arritur të jetojmë sipas parimit "të mësojmë për të gjitha problemet nga okerr". Nëse ndodhi ndonjë problem, për të cilin nuk mësuam nga okerr — e shtojmë kontrollin në okerr. (në këtë rast, me "ne" kam parasysh përdoruesit e sistemit, jo bashkë-zhvilluesit). Fillimisht ndodhte shpesh, por tani është bërë shumë e rrallë.

Monitorimi

Me përmes okerr ne ndjekim madhësitë e logëve në të gjitha serverët. Leximi me kujdes i çdo rreshti të logut është në fakt i pamundur, por thjesht ndjekja e shpejtësisë së rritjes ofron shumë informacion. Në këtë mënyrë zbulojmë dërgimin e spamit dhe bruta-forcimin e fjalëkalimeve, si dhe kur ndonjë nga aplikacionet "çmendet", kur diçka shkon keq dhe ato përsërisin vazhdimisht (çdo herë duke shtuar disa rreshta në log).

Certifikatat SSL. Pothuajse menjëherë pas lançimit LetsEncrypt klienti ynë filloi të ofrojë certifikata SSL falas për klientët e tij (afro një mijë të tillë). Dhe kjo u tregua një makth për administrimin! Problemi është se faqet janë "aktive", klientët herë pas here kërkojnë që t'u bëhet diçka, programuesit e bëjnë. Ata mund të transferojnë lirisht faqen në një DocumentRoot tjetër, për shembull. Ose të shtojnë një Rewrite të pa kushtëzuar në konfigurimin e virthostit. Natyrisht, pas një ndryshimi të tillë, automatikisht prishet rinovimi i certifikatave. Tani të gjithë hostët SSL shtohen në okerr automatikisht përmes një tjetër utilitari të dobishëm nga paketa a2conf. Thjesht e ekzekutojmë a2okerr.py — dhe nëse në server janë shfaqur disa faqe të reja — ato do të shfaqen automatikisht në okerr. Nëse për ndonjë arsye certifikata nuk rinovohet, ne e dimë dhe merremi me të tre javë para se të skadojë certifikata. a2certbot.py nga e njëjta paketë — ndihmon shumë në këtë (verifikon menjëherë problemet më të mundshme — dhe tregon se çfarë ka kaluar mirë dhe ku ka ndoshta një problem).

Ne ndjekim afatin e skadimit të të gjitha domenëve tanë. Të gjithë serverët tanë të postës, të cilët dërgojnë postë — kontrollohen gjithashtu në mbi 50 lista të ndryshme të zeza. (Dhe herë pas here kalojnë në to). Nga ana tjetër, a e dini se serverët e postës së google gjithashtu janë në lista të zeza? Thjesht për vetëtestim, e kemi shtuar mail-wr1-f54.google.com në serverat që ndjekim, dhe ai është në listën e zezë SORBS! (Kjo është për pyetjen mbi vlerën e "anti-spam".)

Bëbackup — më lart e kam shkruar se sa e lehtë është të ndjekim ato me okerr. Por ne gjithashtu ndjekim backupet e freskëta në serverin tonë, dhe (me ndihmën e një utiliteti të veçantë që përdor okerr) — backupet që ngarkojmë në Amazon Glacier. Dhe, po — herë pas here ndodhin probleme. Nuk është për t'u habitur që po i ndjekim.

Ne përdorim një indikator eskalimi. Ai tregon nëse ndonjë problem nuk është zgjidhur për një kohë të gjatë. Edhe unë, kur zgjidh disa detyra, ndonjëherë mund të harroj për to. Eskalimi është një kujtesë e mirë, veçanërisht nëse i ndiqni vetë.

Në përgjithësi, unë mendoj se cilësia e punës sonë ka rritur ndjeshëm. Ka shumë pak ndërprerje (ose klienti as që arrin ta vërejë atë. Vetëm bllok!), ndërsa vëllimi i punës është zvogëluar dhe kushtet e punës janë bërë më të qetë. Ne kaluam nga puna e ngutshme me sëndylar të çarjeve me ngjitës në një punë të qetë dhe të përmirësuar, ku shumë çështje parashikohen më parë dhe ka kohë për t'i parandaluar ato. Edhe problemet e ndodhura janë bërë më të lehta për t'u zgjidhur: së pari, ne përpiqemi të informohemi për to para se klientët të krijojnë panik, së dyti, shpesh ndodh që problemi lidhet me punën e fundit (ndërkohë që bëja diçka, prisha diçka tjetër) - kështu që është më e lehtë të trajtojmë atë në momentin e ngjarjes.

Ja, kishte edhe një rast…

A e dini se në Debian 9 të njohur (Stretch) një paketë shumë të njohur si phpmyadmin është ende (që prej muajsh!) në statusin vulnerable?CVE-2019-6798). Kur doli vulnerabiliteti — ne shpejt e bllokuam atë në disa mënyra. Por unë vendosa që në okerr të vendosja ndjekjen e faqes security-tracker’it, për të ditur kur do të dilte zgjidhja 'e bukur' (nëpërmjet SHA1 të përmbajtjes). Disa herë indikatorët më tërhiqnin vëmendjen, faqja ndryshonte, por siç e shihni — deri më sot (që nga janari 2019!) nuk është njoftuar asgjë për zgjidhjen e problemit. Ndoshta, qofshin, dikush e di se çfarë problemi është që ky paketë ka qenë vulnerable për më shumë se një vit?

Një herë tjetër në një situatë të ngjashme: pas një dobësie në SSH, duhej të përditësoheshin të gjitha serverët. Kur vendos një detyrë, duhet ta kontrollosh ekzekutimin. (Nënshtruarit kanë tendencën të kuptojnë ndryshe, të harrojnë, të ngatërrohen, të bëjnë gabime). Prandaj, fillimisht në okerr shtuam kontrollin e versionit të SSH në të gjitha serverët, dhe përmes okerr ndoqëm që përditësimet të aplikohej në të gjitha serverët. (E përshtatshme! Zgjodha këtë lloj treguesi, dhe menjëherë shihet në cilin server cila version është). Kur u siguruam që detyra ishte përfunduar në të gjithë serverët, ne hoqëm treguesit.

Disa herë ka ndodhur që ndonjë problem të shfaqet, e më pas vetë të zhduket. (sigurisht që është e njohur për të gjithë?). Ndërsa e vëren, derisa të kontrollosh — e aty nuk ka çfarë të kontrollosh më — gjithçka funksionon mirë. Por pastaj prapë dështues. Kjo na ka ndodhur, për shembull, me produktet që ngarkonim në Amazon Marketplace (MWS). Në një moment të caktuar, inventari i ngarkuar ishte i gabuar (nuk ishin ato sasi produktesh dhe nuk ishin ato çmime). E kuptuam. Por për të kuptuar — ishte e rëndësishme të dinim për problemin menjëherë. Fatkeqësisht, MWS si të gjitha shërbimet e Amazon-it — është paksa ngadalësuese, prandaj gjithmonë kishte vonesë, por megjithatë — arritëm të kapnim së paku lidhjen mes problemit dhe skripteve që e shkaktojnë atë (bëmë një kontroll, e lidhëm me errorin dhe kontrollonim menjëherë pas marrjes së alertit).

Një rast interesant së fundmi u shtua në koleksionin tim nga një ofrues i madh dhe i shtrenjtë evropian i hostimit, të cilin e përdor klienti ynë. Papritmas, të gjithë serverët tanë u zhdukën nga radarët! Fillimisht, klienti vetë e vuri re (shumë shpejt, si Okerr!) që сайти me të cilin po punonte nuk hapte më dhe hapi një ticket për këtë. Por, jo vetëm një sit, por të gjitha! (Natasha, ne i patëm të gjithë!). Kështu, Okerr filloi të dërgonte mesazhe të gjata me të gjithë treguesit që u ndezën. Panikë-panike, vrapojmë rreth (çfarë tjetër të bëjmë?). Më pas, gjithçka u rikthye. U duk se në/data qendër kishte punime të programuar (një herë çdo shumë vjet) dhe, natyrisht, duhej të na kishin paralajmëruar. Por ndodhi që ata patën ndonjë problem dhe nuk na paralajmëruan. Një infarkt më shumë, një infarkt më pak. Por pas rikthimit të gjithçkaje — duhet ta kontrollosh gjithçka! Nuk mund ta imagjinoj si do ta bëja me duar. Okerr e testoi gjithçka brenda disa minutash. Doli se një pjesë e madhe e serverëve thjesht ishte përkohësisht e papërballueshme, por punonte. Disa — u ngarkuan, por gjithashtu u vendosën siç duhej. Nga të gjitha humbjet — humbëm dy backup-e, të cilat sipas orarit duhej të ishin krijuar dhe ngarkuar në atë kohë, ndërkohë që ndodhi ky haos. As që i krijova, thjesht pas një dite morëm njoftime se gjithçka ishte në rregull, backup-et shfaqen. Më pëlqen shumë ky rast, sepse Okerr u tregua shumë i dobishëm në një situatë për të cilën nuk kishim menduar paraprakisht, por kjo është gjithashtu detyra e monitorimit — të përballojë të paparashikueshmin.

Për sensorët Okerr, ne përdorim hostet më të lira (atje cilësia dhe besueshmëria nuk janë të rëndësishme, ato sigurojnë njëri-tjetrin). Së fundmi, gjetëm një host shumë të mirë dhe super të lirë, benchmark-et janë mahnitëse. Por... ndonjëherë ndodh që lidhjet e daljes nga virtualka realizohen me një IP tjetër (fqinje). Mrekulli. Moduli client_ip https://diagnostic.opendns.com/myip merr një IP të gabuar. Madje, edhe nga log-et e serverit të indikatorit duket se përditësimi ka ardhur gjithashtu nga kjo IP fqinje. Tani po merremi me suportin. Është mirë që e vëmë re këtë në një kohë paqësore. Por, p.sh., shpesh ndodh që qasja të registrohet në listën e bardhë të IP-ve — dhe nëse serveri ndonjëherë do të dridhë për një kohë të shkurtër — mund të përpiqemi shumë gjatë për ta kapur këtë problem.

Dhe dhe një herë — kur flasim për hostimin VPS — ne gjithmonë përdorim shërbime të përballueshme (hetzner, ovh, scaleway). Dhomat nga benchmark-et dhe stabiliteti — na pëlqen shumë. Përdorim dhe shërbime më të shtrenjta si Amazon EC2 për projekte të tjera. Kështu që, falë okerr kemi një opinion të justifikuar. Ndeshje ndodhin — të dy janë të tillë. Dhe nuk do të thosha që gjatë periudhës sonë të gjatë të vëzhgimit, hostet e lirë si hetzner rezultuan të ishin dukshëm më pak të qëndrueshëm se EC2. Prandaj, nëse nuk jeni të lidhur nga funksione të tjera të Amazon — përse të paguani më shumë? 🙂

Çfarë ndodh më tej?

Nëse në këtë fazë nuk ju kam frikësuar shumë nga Okerr, provoni! Direket përmes këtij linku mund të hyni në llogarinë demonstrative të okerr (Klikoni tani!). Por mbani parasysh — që llogaria demo është një për të gjithë, kështu që, nëse bëni diçka — dikush tjetër në të njëjtën llogari mund t'ju pengojë. Ose (më mirë) regjistrohuni përmes lidhjes në faqen kryesore të okerr — është e thjeshtë, pa SMS. Nëse nuk ju pëlqen të përdorni email-in tuaj të vërtetë — mund të përdorni një të përkohshëm, si mailinator (Unë rekomandoj getnada.com). Këto llogari me kalimin e kohës mund të fshihen — por për testimin është në rregull.

Pas regjistrimit do t'ju ofrohet të kaloni një trajnim (të realizoni disa detyra të thjeshta edukative). Kufijtë fillestarë janë shumë të vogël, por për trajnim ose një server janë të mjaftueshëm. Pas kalimit të trajnimit — kufijtë (p.sh., numri maksimal i indikatorëve) do të rriten.

Nga dokumentacioni — në radhë të parë WIKI për pjesën e serverit dhe për klientin (okerrupdate wiki). Por nëse diçka nuk është e qartë — shkruani në support (at) okerr.com ose lëreni një biletë — do të përpiqemi të zgjidhim gjithçka shpejt.

Nëse do të përdorni me seriozitet dhe këta kufij të rritur nuk do të mjaftojnë — gjithashtu, shkruani në suport, do t'i rrisim (pa pagesë).

Dëshironi të vendosni server okerr në serverin tuaj? Ja repoziotori okerr-dev. Ne rekomandojmë të vendosni në një virtualizim të pastër, kështu që do të jetë e lehtë ta bëni këtë me skenarin e instalimit. Në virtualizimin tuaj — asnjë kufizim :-). Dhe përsëri — nëse ka ndonjë problem — do të përpiqemi gjithmonë të ndihmojmë.

Ne duam që ky projekt të fluturojë, që bota të bëhet më e sigurt falë nesh. Falë softuerit dhe shërbimeve të lira, bota është bërë më miqësore dhe zhvillohet më shpejt. Burimet mund të ruhen në GitHub falas, për postë të përdoret Gmail falas. Ne përdorim Freshworks për mbështetje. Asnjëra nga këto nuk kërkon pagesa për serverë, nuk është e nevojshme të shkarkoni dhe konfiguroni dhe të zgjidhni probleme të ndryshme operacionale. Çdo projekt i ri, çdo ekip — menjëherë ka postë, repo dhe CRM. Dhe gjithçka është shumë cilësore, falas dhe menjëherë. Ne duam që për monitorimin të jetë ashtu siç është — kompanitë e vogla dhe projektet të mund të përdorin okerr falas dhe madje në fazën e lindjes dhe rritjes të kenë besueshmërinë si projektet serioze. Freshworks për mbështetje. Asnjëra nga këto nuk kërkon pagesa për servera, nuk është e nevojshme të shkarkoni dhe konfiguroni dhe të zgjidhni probleme të ndryshme operacionale. Çdo projekt i ri, çdo ekip — menjëherë ka postë, repo dhe CRM. Dhe gjithçka është shumë cilësore, falas dhe menjëherë. Ne duam që për monitorimin të jetë ashtu siç është — kompanitë e vogla dhe projektet të mund të përdorin okerr falas dhe madje në fazën e lindjes dhe rritjes të kenë besueshmërinë si projektet serioze.

Burimi: habr.com