Dy vjet më parë kam bërë një postim Dështim i thjeshtë për një faqe interneti për okerr. Tani ka një zhvillim të projektit, dhe kam botuar gjithashtu Kodi burimor nga ana e serverit okerr nën licencë e hapur, kjo është arsyeja pse vendosa të shkruaj këtë përmbledhje të shkurtër në Habr.

kujt mund t'i interesojë

Kjo mund të jetë me interes për ju nëse punoni në një ekip të vogël ose vetëm. Ju nuk keni monitorim dhe nuk jeni i sigurt nëse keni vërtet nevojë për të. Ose keni provuar disa monitorime serioze popullore "për djemtë e mëdhenj", por disi "nuk u ngrit" për ju, ose funksionon në një konfigurim pothuajse të paracaktuar dhe nuk e ndryshoi shumë jetën tuaj. Dhe gjithashtu - nëse definitivisht nuk planifikoni të caktoni një punonjës të tërë (ose edhe një departament) për të monitoruar pultin e monitorimit të paktën disa orë në ditë ose ta konfiguroni atë.

Pse okerr është e pazakontë

Më pas do të tregoj veçori interesante të okerrës që e dallojnë atë nga disa sisteme të tjera monitorimi.

Okerr është një monitorim hibrid

Gjatë monitorimit të brendshëm, një "agjent" po funksionon në makinat e monitoruara, i cili transmeton të dhëna në serverin e monitorimit (për shembull, hapësira e lirë në disk). Kur është i jashtëm, serveri kryen kontrolle në rrjet (për shembull, ping ose disponueshmëria e faqes në internet). Çdo qasje ka kufizimet e veta. Okerr përdor të dyja opsionet. Kontrollet brenda serverëve kryhen nga një agjent shumë i lehtë (30 Kb) ose skriptet dhe aplikacionet tuaja, dhe kontrollet e rrjetit kryhen përmes sensorëve okerr në vende të ndryshme.

okerr nuk është vetëm softuer, por edhe shërbim

Pjesa e serverit të çdo monitorimi është e madhe dhe komplekse, është e vështirë për t'u instaluar dhe konfiguruar dhe kërkon burime. Me okerr mund të instaloni serverin tuaj të monitorimit (është falas dhe me burim të hapur), ose thjesht mund të përdorni vetëm pjesën e klientit dhe të përdorni shërbimin e serverit tonë. Gjithashtu falas.

Nëse monitorimi ju lejon të kompensoni dhe mbuloni mungesën e besueshmërisë në serverë dhe aplikacione, atëherë lind një pyetje filozofike - kush është roja? Si do të na tregojë monitorimi për një problem nëse ai vetë "vdiq" për ndonjë arsye, veçmas ose së bashku me burimet tuaja të tjera (për shembull, kanali në qendrën e të dhënave ra)? Kur përdorni shërbimin e jashtëm okerr - ky problem është zgjidhur - do të merrni një alarm edhe nëse e gjithë qendra e të dhënave me serverët tuaj është pa energji ose sulmohet nga zombitë.

Sigurisht, ekziston rreziku që vetë serveri okerr të mos jetë i disponueshëm, kjo është e vërtetë (siç e dini, 90% e besueshmërisë merret gjithmonë thjesht dhe "falas", 99% me një përpjekje minimale, dhe çdo nëntë pasuese është në mënyrë eksponenciale më e vështirë). Por, së pari, shanset që kjo të ndodhë janë më të vogla dhe së dyti, problemi mund të kalojë pa u vënë re vetëm nëse përkon me probleme në serverët tanë. Nëse kemi 99.9% besueshmëri, dhe ju keni 99.9% (numra jo shumë të larta), atëherë mundësia e një dështimi të pazbuluar është 0.1% nga 0.1% = 0.0001%. Shtimi i tre nëntë në besueshmërinë tuaj pothuajse pa mundim dhe pa kosto është shumë mirë!

Një avantazh tjetër i monitorimit si shërbim është se një ofrues pritës ose studio në internet mund të instalojë një server okerr dhe të sigurojë akses për klientët si një shërbim shtesë me pagesë ose falas. Konkurrentët tuaj thjesht kanë host dhe faqe interneti, por ju keni një pritje të besueshme me monitorim.

Okerr ka të bëjë me treguesit

Treguesi është një "llambë dritë". Ka dy gjendje kryesore - jeshile (OK) ose e kuqe (ERR). Projekti përmban shumë tregues të grupuar (për shembull, sipas serverit). Në faqen kryesore të projektit, menjëherë shihni se ose gjithçka është e gjelbër (dhe mund ta mbyllni), ose diçka është ndezur e kuqe dhe duhet korrigjuar. Kur kaloni midis këtyre gjendjeve, dërgohet një alarm. Një herë në ditë ndërsa jeni duke e konfiguruar, dërgohet një përmbledhje e projektit.

Çdo tregues okerr ka kushte të integruara me të cilat ai ndryshon gjendjen (në Zabbix kjo quhet shkas). Për shembull, mesatarja e ngarkesës duhet të jetë jo më shumë se 2 (natyrisht, kjo është e konfigurueshme). Dhe për çdo kontroll të brendshëm (mesatarja e ngarkesës, disku pa, ...) ekziston një roje. Nëse për ndonjë arsye nuk marrim një konfirmim të suksesshëm në kohën e caktuar, regjistrohet një gabim dhe dërgohet një alarm.

Modeli ynë i zakonshëm i punës është të kontrollojmë emailet në mëngjes dhe të shikojmë përmbledhjen midis letrave të tjera (ne e planifikojmë atë në fillim të punës). Nëse gjithçka është në rregull në të, ne bëjmë gjëra të tjera të rëndësishme (por për të qenë të sigurt, mund të shikojmë shpejt pultin e okerrës dhe të sigurohemi që gjithçka është e gjelbër në këtë moment). Nëse vjen një alarm, ne reagojmë.

Sigurisht, është e mundur që thjesht të mbahen tregues "informativ" (për të parë foton e rrjetit nga monitorimi), por gjithçka bëhet për të krijuar thjesht, lehtësisht dhe shpejt tregues posaçërisht për monitorimin automatik dhe dërgimin e sinjalizimeve.

Qëllimi për të cilin po konfiguroni okerr është në alarme, në mënyrë që të krijoni një tregues në një minutë, ai mund të "flejë" për një vit, thjesht pranon përditësimet dhe kur një vit më vonë diçka prishet, ai ndizet dhe dërgon një alarm. Minuta që keni shpenzuar dikur duke krijuar një tregues u shpagua; ju mësuat për problemin menjëherë, përpara kujtdo tjetër. Është e mundur që ata e rregulluan atë para se dikush ta vinte re. Diçka që ngrihet shpejt nuk konsiderohet se ka rënë!

siguri

Do të ishte turp nëse vendosni monitorimin për hir të rritjes së besueshmërisë, por si rezultat, ju sulmoheni përmes rrjetit përmes tij dhe ka mjaft dobësi të rrjetit në mjete të ndryshme monitorimi (Zabbix, Nagios).

Agjent (okerrmod nga paketa okerrupdate) që funksionon në sistem nuk është një server rrjeti, por një klient. Prandaj, nuk ka porte shtesë të hapura në serverin e monitoruar, klienti punon lehtësisht pas një muri zjarri ose NAT dhe është shumë e vështirë (Unë do të thoja "e pamundur") të hakohet përmes rrjetit, pasi në parim nuk dëgjon rrjetin prizë.

Mbulim i plotë monitorues

Tani rregulli ynë është që ne mësojmë për të gjitha problemet teknike nga okerr. Nëse papritmas rregulli është shkelur (okerr nuk paralajmëroi për ndodhjen e tij të afërt (nëse kjo është e mundur) ose se ajo ka ndodhur tashmë) - ne shtojmë kontrolle në okerr.

Kontrollet e jashtme

Një grup mjaft tipik:

ping
statusi http
kontrollimi i vlefshmërisë dhe freskisë së certifikatës SSL (do të paralajmërojë nëse është gati të skadojë)
hapni portin TCP dhe flamurin mbi të
http grep (faqja [nuk duhet] të përmbajë tekst specifik)
sha1 hash për të kapur ndryshimet e faqeve.
DNS (rekord DNS duhet të ketë një vlerë specifike)
WHOIS (do të paralajmërojë nëse domeni do të shkojë keq)
Antispam DNSBL (kontrolli i hostit kundër 50+ listave të zeza antispam menjëherë)

Kontrollet e brendshme

Gjithashtu, një grup mjaft standard (por lehtësisht i zgjerueshëm).

df (hapësirë e lirë në disk)
mesatare e ngarkesës
opentcp (hap prizat e dëgjimit TCP - do të njoftojë nëse diçka ka filluar ose ka rënë)
uptime - vetëm koha e funksionimit në server. Do të njoftojë nëse ka ndryshuar (d.m.th. serveri është mbingarkuar)
klient_ip
dirsize - ne e përdorim atë për të gjurmuar kur rrënjët e makinës sonë virtuale tejkalojnë madhësinë e lejuar, pa futur kufizime të rrepta dhe madhësinë e drejtorive kryesore të përdoruesve
bosh dhe jo bosh - monitoroni skedarët që duhet të jenë bosh (ose jo bosh). Për shembull, regjistri i gabimeve të vetë serverit okerr duhet të jetë bosh, dhe nëse ka edhe një rresht në të, unë do të marr një njoftim dhe do ta kontrolloj. Por mail.log në serverin e postës NUK duhet të jetë bosh (N minuta pas rrotullimit). Dhe ndonjëherë ishte bosh për ne pas një përditësimi të sistemit, kur logrotate nuk mund të rifillonte saktë rsyslog.
linecount - numri i rreshtave në skedar (si wc -l). Ne e përdorim atë si një zëvendësim më të butë për bosh, kur regjistri i gabimeve ende mund të rritet, por vetëm ngadalë (për shembull, Googlebot godet disa faqe të mbyllura). Ka një kufi prej 2 rreshtash në 20 minuta. Nëse është më e lartë, do të ketë një alarm

Kontrolle interesante të brendshme

Nëse deri në këtë pikë keni lexuar "diagonalisht", tani do të jetë më interesante të lexoni më me kujdes.

backups

Monitoron kopjet rezervë në drejtori. Skedarët tanë rezervë kanë emra si "ServerName-20200530.tar.gz". Për çdo server në okerr, krijohet treguesi ServerName-DATE.tar.gz (data aktuale ndryshon në rreshtin "DATA"). Vetë prania e një kopje rezervë të freskët dhe madhësia e tij monitorohen gjithashtu (për shembull, nuk mund të jetë më pak se 90% e rezervës së mëparshme).

Çfarë duhet bërë që një kopje rezervë e re të fillojë të gjurmohet pasi të kemi filluar ta krijojmë dhe ta vendosim në këtë direktori? Asgjë! Kjo është një qasje shumë e përshtatshme kur ju duhet të bëni "asgjë" sepse:

Të bësh "asgjë" është shumë e shpejtë, kursen kohë
Është e vështirë të harrosh të bësh "asgjë"
Është e vështirë të bësh "asgjë" të gabuar, me një gabim. Asgjë nuk është metoda më e besueshme

Nëse papritmas skedarët e freskët rezervë ndalojnë së shfaquri, do të ketë një alarm. Nëse, për shembull, keni çaktivizuar një nga serverët dhe nuk duhet të ketë më kopje rezervë, do t'ju duhet të fshini treguesin (përmes ndërfaqes në internet ose nga guaska përmes API-së).

maxfilesz

Mban gjurmët e madhësisë së skedarëve më të mëdhenj (zakonisht: /var/log/*). Kjo ju lejon të kapni probleme të paparashikueshme, për shembull, fjalëkalime me forcë brutale ose dërgimin e postës së padëshiruar përmes serverit.

runstatus/runline

Këto janë dy module të rëndësishme proxy për ekzekutimin e programeve të tjera në server. Runstatus raporton kodin e daljes nga programi në tregues. Për shembull, okerr nuk (kërkon) një modul për të kontrolluar nëse shërbimet systemd janë duke u ekzekutuar. Kjo bëhet përmes statusit të ekzekutimit (shih më poshtë). Runline - i raporton serverit linjën që prodhon programi. Për shembull, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" në konfigurimin Runline në serverin tonë krijon një tregues emri i serverit: temp me temperaturën e procesorit.

sql

Ekzekuton një pyetje numerike në MySQL dhe raporton rezultatin tek treguesi. Në një rast të thjeshtë, mund të bëni, për shembull, "SELECT 1" - kjo do të kontrollojë që DBMS në tërësi po funksionon.

Por një aplikacion shumë më interesant është, për shembull, gjurmimi i numrit të porosive në një dyqan online. Nëse e dini se keni 100 ose më shumë porosi në orë, mund të vendosni kufirin minimal në 100 ose 80. Më pas, nëse shitjet tuaja bien papritur, do të merrni një alarm dhe mund ta kuptoni.

Vini re se nuk ka rëndësi për çfarë arsye të paparashikueshme ndodhi kjo:

Serveri është thjesht i padisponueshëm (i çaktivizuar ose pa rrjet), dhe alarmi erdhi nga fakti se treguesi ishte "i kalbur".
Serveri është i mbingarkuar me diçka, funksionon ngadalë ose humbasin paketat, është i papërshtatshëm për përdoruesit dhe ata largohen pa bërë blerje
Serveri është i përfshirë në listat e spamit dhe posta prej tij nuk pranohet, përdoruesit nuk mund të regjistrohen
Buxheti i fushatës reklamuese ka mbaruar, pankartat nuk po rrotullohen.

Mund të ketë një numër arsyesh, dhe të gjitha nuk mund të parashikohen paraprakisht, dhe teknikisht është e vështirë të gjurmohen. Por ju mund të monitoroni me lehtësi parametrin përfundimtar (urdhrat) dhe të përcaktoni prej tyre se situata është e dyshimtë dhe meriton të trajtohet.

Treguesit logjikë

Lejon përdorimin e shprehjeve Boolean (sintaksë Python) nëpërmjet një moduli vërtetoj(artikull në Habré). Të dhënat nga projekti dhe treguesit e tij janë në dispozicion për shprehje. Për shembull, në kapitullin për kontrollin e SQL më sipër, mund të keni vënë re një pikë të dobët - gjatë ditës mund të kemi 100 shitje në orë, por gjatë natës - 20, dhe kjo është e zakonshme, jo problem. Cfare duhet te bej? Treguesi do të jetë vazhdimisht në panik gjatë natës.

Mund të krijoni dy tregues, ditën dhe natën. Bëjini të dyja "të heshtura" (ata nuk do të dërgojnë sinjalizime). Dhe krijoni një tregues logjik që kërkon që treguesi i ditës të jetë në rregull para orës 20:00, dhe pas orës 20:00 mjafton që treguesi i natës të jetë në rregull.

Një shembull tjetër i përdorimit të një treguesi logjik është përshkallëzimi. Për shembull, një menaxher projekti çabonohet nga sinjalizimet (ai nuk ka nevojë ta bëjë këtë, administratorët duhet t'i përgjigjen problemeve normale), por pajtohet në një tregues logjik që bëhet i kuq nëse ndonjë tregues në projekt nuk korrigjohet brenda kohës së caktuar.

Gjithashtu, është e mundur të caktohet koha e lejuar për punë, për shembull, nga 3 deri në 5 të mëngjesit. Nuk na intereson nëse serverët dhe faqet prishen gjatë kësaj kohe. Por në orën 5:00 duhet të punojnë. Nëse nuk funksionojnë në asnjë moment tjetër - vigjilent. Treguesi logjik gjithashtu ju lejon të merrni parasysh tepricën e serverit. Nëse keni 5 serverë ueb, atëherë administratorët mund të çaktivizojnë 1-2 serverë në çdo kohë. Por nëse ka më pak se 3 nga 5 serverë në betejë, do të ketë një alarm.

Shembujt e mësipërm nuk janë funksione oker, jo disa veçori që duhet të aktivizohen dhe konfigurohen. Okerra nuk i ka të gjitha këto funksione, por ekziston një modul logjik që ju lejon të zbatoni këtë funksionalitet (Përafërsisht si në një gjuhë programimi - nëse kemi operatorë aritmetikë, atëherë nuk kemi nevojë për një funksion të veçantë për llogaritjen e TVSH-së 20% nga gjuha, ju gjithmonë mund ta bëni vetë, për t'iu përshtatur nevojave tuaja).

Treguesi Logic është ndoshta një nga temat e pakta relativisht komplekse në okerr, por lajmi i mirë është se nuk keni nevojë ta zotëroni atë derisa të keni nevojë. Por në të njëjtën kohë, ato zgjerojnë shumë aftësitë, duke e mbajtur vetë sistemin mjaft të thjeshtë.

Shtimi i çeqeve tuaja

Do të doja shumë të përcjell idenë se okerr nuk është një grup me mijëra çeqe të gatshme për të gjitha rastet, por përkundrazi - para së gjithash - një motor i thjeshtë me një aftësi të thjeshtë për të krijuar çeqet tuaja. Krijimi i çeqeve tuaja në okerr nuk është një detyrë për hakerat, bashkë-zhvilluesit e sistemit, ose të paktën përdoruesit e avancuar të okerr, por një detyrë e realizueshme për çdo administrator që instaloi Linux për herë të parë një muaj më parë.

Kontrollet për pagat minimale bëhen përmes modulit statusi i ekzekutimit:

Kjo linjë në konfigurim statusi i ekzekutimit do t'ju njoftojë nëse /bin/true papritmas nuk fillon ose kthen diçka tjetër përveç 0.

true_OK=/bin/true

Vetëm një rresht - dhe këtu jemi tashmë pak zgjeruar funksionaliteti okerr.

Edhe një kontroll i tillë tashmë ka vlerën e tij: nëse papritmas serveri juaj rrëzohet, treguesi përkatës në serverin okerr nuk do të përditësohet në kohën e duhur dhe pasi të ketë kaluar koha, do të shfaqet një alarm.

Ky kontroll do të njoftojë se serveri apache2 është rrëzuar (epo, nuk e dini kurrë ...):

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

Pra, nëse flisni ndonjë gjuhë programimi dhe të paktën mund të shkruani skriptet e guaskës, atëherë tashmë mund të shtoni kontrollet tuaja.

Më e vështirë - mund të shkruani (në çdo gjuhë) modulin tuaj për okerrmod. Në rastin më të thjeshtë duket kështu:

#!/usr/bin/python3

print("STATUS: OK")

A nuk është shumë e vështirë? Moduli duhet të bëjë vetë kontrollin dhe të nxjerrë rezultatet në STDOUT. Një modul më kompleks jep, për shembull, këtë:

$ 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

Përditëson disa tregues njëherësh (të ndarë nga një rresht bosh), i krijon ato nëse është e nevojshme, tregon detajet e verifikimit dhe një etiketë me të cilën është e lehtë të gjesh treguesit e nevojshëm në panelin e kontrollit.

Ekziston një bot Telegram @OkerrBot. Ju nuk keni nevojë ta rrëmoni telefonin tuaj me aplikacione të veçanta (nuk më pëlqen që për Pyaterochka keni nevojë për një aplikacion me një hartë, për Lenta një tjetër, për MTS një të tretën dhe kështu me radhë për të gjithë, të gjithë, të gjithë). Mjafton një telegram. Përmes telegramit mund të merrni menjëherë sinjalizime, të kontrolloni statusin e projektit dhe të jepni një komandë për të rishikuar të gjithë treguesit problematikë. U larguam nga teatri/avioni, nuk e mbajtëm gishtin në pulsin për dy orë, ndezëm telefonin, shtypëm një buton në chatbot dhe u siguruam që gjithçka ishte në rregull.

Faqet e statusit

Në ditët e sotme, faqet e statusit janë pothuajse të domosdoshme për çdo biznes që ka IT, një qëndrim të përgjegjshëm ndaj besueshmërisë dhe që i trajton klientët/përdoruesit e tij me respekt.

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ë po ndodh, në anën e kujt është problemi dhe kur do të zgjidhet. Ndoshta kompania juaj thjesht ka një faqe interneti jofunksionale? Apo u prish gjashtë muaj më parë dhe do të rregullohet për dy vjet? Por ju duhet të blini një frigorifer tani, ai tashmë është në karrocë... Dhe është një çështje krejtësisht tjetër kur një person sheh se diçka nuk shkon me ju (të paktën është e qartë se problemi nuk është në anën e tij), që problemi është zbuluar, se ju tashmë jeni duke punuar në të, dhe ndoshta keni shkruar edhe kohën e përafërt për korrigjim. Përdoruesi mund të abonohet dhe të marrë një njoftim me email kur problemi të zgjidhet dhe ai mund të bëjë atë që dëshiron (të blejë një frigorifer).

Problemet dhe pushimet i ndodhin të gjithëve. Por përdoruesit dhe partnerët u besojnë më shumë atyre që janë më transparentë dhe të përgjegjshëm në qasjen e tyre ndaj kësaj.

Këtu rishikim i 10 projekteve të tjera që ju lejojnë të krijoni faqe statusi. Këtu janë shembuj se si duken këto faqe projekti Piton и Dropbox. faqja e statusit okerr.

Failover

Për të mos e zgjatur edhe më shumë këtë artikull, do t'i referohem edhe një herë artikullit tim të mëparshëm - Dështim i thjeshtë për një faqe interneti . Nëse mund të bëni një server të kopjuar, atëherë duke përdorur dështimin, në thelb nuk do të keni një kohë të gjatë joproduktive - sapo të zbulohet një problem, përdoruesit do të ridrejtohen automatikisht në një server rezervë që funksionon. Dhe më duket se ky është një tipar shumë interesant, i ndritshëm që rrallë gjendet askund.

Kërkesa të ulëta të sistemit

Për serverët okerr, ne përdorim makina me RAM nga 2 Gb. Për sensorët e rrjetit, mjafton edhe 512 Mb. Pjesa e klientit në përgjithësi është pothuajse zero. (Qese plastike okerrupdate peshon 26 Kb, por kërkon Python3 dhe biblioteka standarde). Klienti funksionon nga një skrip cron, kështu që ka zero konsum të vazhdueshëm të memories. Ndër makinat që monitoruam, kemi sensorë (VPS super të lirë me 512 Mb RAM) dhe një Raspberry Pi. Është e mundur edhe pa pjesën e klientit dërgoni përditësime përmes curl! (Shikoni më poshtë)

Duke marrë parasysh këtë - okerr, ndoshta më të lira sistem monitorimi nga ato të disponueshme, sepse edhe për të përdorur një sistem tjetër me burim të hapur falas si Zabbix ose Nagios, duhet të ndani burime (server) për të, dhe kjo tashmë është para. Përveç kësaj, kërkohet ende një mirëmbajtje e serverit. Me okerr, kjo pjesë mund të hiqet. Ose nuk keni pse ta hiqni dhe të përdorni serverin tuaj, në varësi të asaj që ju pëlqen më së miri.

API dhe integrimi në softuer të pronarit

Arkitekturë e thjeshtë dhe e hapur. okerr ka një shumë të thjeshtë API, me të cilin është e lehtë të punohet. Duhet të krijoni 1000 tregues? Një skrip shell prej 3-4 rreshtash do ta bëjë këtë. Keni nevojë të rikonfiguroni 1000 tregues? Është gjithashtu shumë e lehtë. Për shembull, ne duam të kontrollojmë dy herë të gjitha certifikatat tona HTTPS nga një sensor 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

Mund ta përditësoni treguesin duke përdorur modulin tonë të klientit, edhe pa të, vetëm nëpërmjet 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/

Ju mund të përditësoni treguesit direkt nga programi juaj. Për shembull, dërgimi i sinjaleve të rrahjeve të zemrës në mënyrë që okerr të dijë se po funksionon dhe të ngre një alarm nëse përplaset ose ngrin. Nga rruga, komponentët okerr bëjnë pikërisht këtë - okerr monitoron vetë, dhe problemet në pothuajse çdo modul do të zbulohen dhe do të gjenerojnë një alarm për problemin. (Dhe në rastin e kësaj "pothuajse" - ato kontrollohen nga një server tjetër)

Këtu është kodi (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))

Ekziston një bibliotekë për përditësimin e treguesve nga programet Python okerrupdate, për asnjë gjuhë tjetër nuk ka biblioteka, por mund të telefononi skriptin okerrupdate ose të bëni një kërkesë HTTP në serverin okerr.

Si na ndihmon okerr

Okerr ndryshoi jetën tonë. Me të vërtetë. Ndoshta një sistem tjetër monitorimi mund të bëjë të njëjtën gjë, por puna me okerr është e lehtë dhe e thjeshtë për ne dhe ka të gjitha funksionet që na duheshin (shtuam atë që nuk kishte). Meqë ra fjala, nëse mungojnë disa veçori, pyesni dhe do t'i shtoj (nuk ju premtoj, por dua që okerr të jetë sistemi më i mirë i monitorimit për projektet e vogla dhe të mesme). Ose më mirë akoma, shtoni vetë - është e lehtë.

Ne arritëm të jetonim sipas parimit "të mësojmë për të gjitha problemet nga kerra". Nëse papritmas shfaqet një problem për të cilin nuk kemi mësuar nga okerr, ne i shtojmë një kontroll okerr. (në këtë rast, me "ne" nënkuptoj ne si përdorues të sistemit, jo si bashkëzhvillues). Në fillim kjo ishte e zakonshme, por tani është bërë shumë e rrallë.

Monitorimi

Nëpërmjet okerr ne monitorojmë madhësitë e regjistrave në të gjithë serverët. Sigurisht, është e pamundur të lexoni me kujdes çdo rresht të regjistrit me sytë tuaj, por thjesht monitorimi i shkallës së rritjes tashmë jep shumë. Nëpërmjet kësaj, ne zbuluam postimet e padëshiruara dhe kërkimet e fjalëkalimeve me forcë brutale, dhe kur disa nga aplikacionet "çmenden", diçka nuk funksionon për ta dhe ata e përsërisin atë përsëri dhe përsëri (çdo herë duke shtuar disa rreshta në regjistër ).

Certifikatat SSL. Pothuajse menjëherë pas nisjes Le të Encrypt klienti ynë filloi të ofrojë certifikata SSL falas për klientët e tij (rreth një mijë prej tyre). Dhe doli të ishte vetëm ferr për administrimin! Fakti është se faqet janë "live", klientët periodikisht u kërkojnë atyre të bëjnë diçka, programuesit e bëjnë atë. Ata mund ta transferojnë plotësisht faqen në një tjetër DocumentRoot, për shembull. Ose shtoni një Rishkrim të pakushtëzuar në konfigurimin e virtualhost-it. Natyrisht, pas kësaj prishet rinovimi automatik i certifikatave. Tani ne kemi të gjithë hostet SSL të shtuara në okerr automatikisht përmes një tjetër prej shërbimeve tona të dobishme nga paketa a2konf. Le të fillojmë a2okerr.py — dhe nëse në server shfaqen disa sajte të reja, ato do të shfaqen automatikisht në okerr. Nëse papritmas për ndonjë arsye certifikata nuk rinovohet, tre javë para skadimit të certifikatës, ne jemi në dijeni dhe do të kuptojmë pse nuk është përditësuar, një qen i tillë. a2certbot.py nga e njëjta paketë - ndihmon shumë me këtë (kontrollon menjëherë problemet më të mundshme - dhe shkruan atë që u kontrollua mirë dhe ku ka shumë të ngjarë të ketë një problem).

Ne monitorojmë datën e skadimit të të gjitha domeneve tona. Dhe të gjithë serverët tanë të postës që dërgojnë postë janë gjithashtu të kontrolluar kundrejt 50+ listave të zeza të ndryshme. (Dhe ndonjëherë ata bien në to). Nga rruga, a e dini se serverët e postës së Google janë gjithashtu në listën e zezë? Vetëm për vetë-testim, ne shtuam mail-wr1-f54.google.com në serverët e monitoruar dhe është ende në listën e zezë SORBS! (Kjo ka të bëjë me vlerën e "anti-spammers")

Rezervimet - Unë kam shkruar tashmë më lart se sa e lehtë është t'i monitorosh ato me okerr. Por ne monitorojmë si kopjet rezervë të fundit në serverin tonë ashtu edhe (duke përdorur një mjet të veçantë që përdor okerr) kopjet rezervë që ngarkojmë në Amazon Glacier. Dhe, po, problemet ndodhin herë pas here. Nuk është çudi që ata po shikonin.

Ne përdorim treguesin e përshkallëzimit. Tregon nëse ndonjë problem nuk është rregulluar për një kohë të gjatë. Dhe unë vetë, kur zgjidh disa probleme, ndonjëherë mund t'i harroj ato. Përshkallëzimi është një kujtesë e mirë, edhe nëse jeni duke monitoruar veten.

Në përgjithësi, besoj se cilësia e punës sonë është rritur me një renditje të përmasave. Nuk ka pothuajse asnjë kohë joproduktive (ose klienti nuk ka kohë ta vërejë. Thjesht shh!), ndërkohë që sasia e punës është bërë më e vogël dhe kushtet e punës janë bërë më të qeta. Nga puna emergjente me arnimin e vrimave me shirit kemi kaluar në punë të qetë dhe të matur, kur shumë probleme parashikohen paraprakisht dhe ka kohë për t'i parandaluar. Edhe problemet që kanë ndodhur janë bërë gjithashtu më të lehta për t'u rregulluar: së pari, ne i zbulojmë ato përpara se klientët të hyjnë në panik, dhe së dyti, shpesh ndodh që problemi të lidhet me punën e fundit (ndërsa bëja një gjë, prisha një tjetër) - kështu që është vapë Është më e lehtë që gjurmët të merren me të.

Por ka pasur një rast tjetër...

A e dini se në Debian 9 (Stretch) popullor një paketë kaq e njohur si phpmyadmin është ende (për shumë muaj!) në statusin e cenueshëm? (CVE-2019-6798). Kur u shfaq dobësia, ne e mbuluam shpejt atë në mënyra të ndryshme. Por unë vendosa monitorimin e faqes së gjurmuesit të sigurisë në okerr për të ditur se kur do të dalë një zgjidhje "e bukur" (përmes shumës SHA1 të përmbajtjes). Treguesi më tronditi disa herë, faqja ndryshoi, por siç e shihni, ende (që nga janari 2019!) nuk tregon se problemi është zgjidhur. Ndoshta, meqë ra fjala, dikush e di se cili është problemi që një paketë kaq e rëndësishme është ende e pambrojtur për më shumë se një vit?

Një herë tjetër në një situatë të ngjashme: pas një cenueshmërie në SSH, ishte e nevojshme të përditësoheshin të gjithë serverët. Dhe kur vendosni një detyrë, duhet të kontrolloni ekzekutimin. (Vartësit priren të keqkuptojnë, të harrojnë, të ngatërrohen dhe të bëjnë gabime). Prandaj, së pari shtuam një kontroll të versionit SSH në okerr në të gjithë serverët, dhe përmes okerr u siguruam që përditësimet të shpërndaheshin në të gjithë serverët. (I përshtatshëm! Zgjodha këtë lloj treguesi, dhe ju mund të shihni menjëherë se cili server ka cilin version). Kur ishim të sigurt që detyra ishte përfunduar në të gjithë serverët, ne hoqëm treguesit.

Disa herë ka pasur një situatë ku lind një problem i caktuar, dhe më pas kalon vetë. (ndoshta e njohur për të gjithë?). Në kohën kur vini re, në kohën kur kontrolloni - dhe nuk ka asgjë për të kontrolluar - gjithçka tashmë funksionon mirë. Por pastaj prishet përsëri. Kjo na ndodhi, për shembull, me produktet që ngarkuam në Amazon Marketplace (MWS). Në një moment, inventari i ngarkuar ishte i pasaktë (sasi të gabuara të mallrave dhe çmime të gabuara). E kuptuam. Por, për ta kuptuar atë, ishte e rëndësishme të zbulohej problemi menjëherë. Fatkeqësisht, MWS, si të gjitha shërbimet e Amazon, është paksa i ngadalshëm, kështu që gjithmonë kishte një vonesë, por megjithatë, ne ishim në gjendje të paktën të kuptonim afërsisht lidhjen midis problemit dhe skripteve që e shkaktojnë atë (ne bëmë një kontroll, mbërthyen atë tek okerr dhe e kontrolloi menjëherë duke marrë një alarm).

Një rast interesant i është shtuar koleksionit së fundmi nga një host i madh dhe i shtrenjtë evropian, të cilin klienti ynë e përdor. Papritur, të gjithë serverët tanë u zhdukën nga radari! Së pari, vetë klienti (më shpejt se okerra!) vuri re që faqja me të cilën punonte nuk po hapej dhe bëri një biletë për të. Por jo vetëm një faqe u rrëzua, por të gjitha! (Natasha, ne hoqëm gjithçka!). Këtu Okerr filloi të dërgonte mbështjellje të gjata këmbësh me të gjithë treguesit që ndriçonin për të. Panik, panik, vrapojmë në rrathë (çfarë mund të bëjmë tjetër?). Pastaj gjithçka u ngrit. Rezulton se ka pasur mirëmbajtje rutinë në qendrën e të dhënave (një herë në shumë vite) dhe, natyrisht, ne duhet të ishim paralajmëruar. Por atyre u ndodhi një lloj problemi dhe ata nuk na paralajmëruan. Epo, më shumë sulme në zemër, më pak sulme në zemër. Por pasi gjithçka është restauruar, duhet të kontrolloni dy herë gjithçka! Nuk mund ta imagjinoj se si do ta bëja me duart e mia. Okerr testoi gjithçka në pak minuta. Doli që shumica e serverëve ishin thjesht përkohësisht të padisponueshëm, por ata funksionuan. Disa u mbingarkuan, por edhe u ngritën si duhej. Nga të gjitha humbjet, humbëm dy kopje rezervë, të cilat sipas kurorës duhet të ishin krijuar dhe ngarkuar ndërkohë që kjo banane e plotë po vazhdonte. As që u mundova t'i krijoja ato, vetëm një ditë më vonë mbërritën alarmet se gjithçka ishte në rregull, ishin shfaqur kopje rezervë. Më pëlqen shumë ky shembull sepse okerr doli të ishte shumë i dobishëm në një situatë që as nuk e kishim menduar më parë, por ky është qëllimi i monitorimit - t'i rezistojmë të paparashikueshmes.

Për sensorët Okerr, ne përdorim hostimin më të lirë të mundshëm (ku cilësia dhe besueshmëria nuk janë të rëndësishme, ato sigurojnë njëra-tjetrën). Pra, kohët e fundit gjetëm një pritje shumë të mirë dhe super të lirë, standardet janë të mrekullueshme. Por... ndonjëherë del se lidhjet dalëse nga makina virtuale bëhen nga një IP tjetër (fqinj). Mrekullitë. Moduli Client_ip me https://diagnostic.opendns.com/myip merr IP të gabuar. Dhe nga regjistrat e serverit të treguesit është e qartë se përditësimi erdhi gjithashtu nga kjo IP fqinje. Le të merremi me mbështetjen tani. Është mirë që e vumë re këtë në kohë paqeje. Por, për shembull, shpesh ndodh që qasja të regjistrohet sipas listës së bardhë të IP - dhe nëse serveri ndonjëherë pulson kështu për një kohë të shkurtër - mund të përpiqeni ta kapni këtë problem për një kohë shumë të gjatë.

Epo, një gjë tjetër – meqenëse po flasim për hostimin VPS – ne përdorim gjithmonë ato të lira (hetzner, ovh, scaleway). Më pëlqen shumë si nga pikëpamja e standardeve ashtu edhe nga stabiliteti. Ne përdorim gjithashtu Amazon EC2 shumë më të shtrenjtë për projekte të tjera. Pra, falë okerr, ne kemi opinionin tonë të informuar. Ata të dy bien. Dhe nuk do të thoja që gjatë periudhës së gjatë të vëzhgimeve tona, hostet e lirë si hetzner doli të ishin dukshëm më pak të qëndrueshme se EC2. Prandaj, nëse nuk jeni të lidhur me veçoritë e tjera të Amazon, pse të paguani më shumë? 🙂

Çka më tej?

Nëse në këtë fazë nuk ju kam frikësuar ende nga Okerr, atëherë provojeni! Mund të shkoni direkt në këtë lidhje llogari demo okerr (Kliko tani!) Por mbani në mend se ekziston vetëm një llogari demo për të gjithë, kështu që nëse bëni diçka, dikush tjetër në të njëjtën llogari mund të ndërhyjë me ju në të njëjtën kohë. Ose (më mirë) regjistrohuni përmes lidhjes për offsite okerr - gjithçka është e thjeshtë, pa SMS. Nëse nuk ju pëlqen të përdorni emailin tuaj të vërtetë, mund të përdorni një të disponueshme, si mailinator (unë rekomandoj getnada.com). Llogari të tilla mund të fshihen me kalimin e kohës, por ato do të jenë të mira për testim.

Pas regjistrimit, do t'ju kërkohet të kaloni trajnime (kryeni disa detyra trajnimi jo shumë të vështira). Kufijtë fillestarë janë shumë të vegjël, por për trajnim ose një server janë të mjaftueshëm. Pas përfundimit të trajnimit, kufijtë (për shembull, numri maksimal i treguesve) do të rriten.

Nga dokumentacioni - para së gjithash WIKI nga ana e serverit dhe nga klienti (okerrupdate wiki). Por nëse diçka është e paqartë, shkruani në mbështetje (në) okerr.com ose lini një biletë - ne do të përpiqemi të zgjidhim gjithçka shpejt.

Nëse e përdorni seriozisht dhe nuk mjaftojnë këto limite të rritura, shkruani në mbështetje dhe ne do ta rrisim atë (falas).

Dëshironi të instaloni serverin okerr në serverin tuaj? Këtu depo okerr-dev. Ne rekomandojmë instalimin në një makinë virtuale të pastër, atëherë thjesht mund ta bëni atë me një skript instalimi. Në makinën tuaj virtuale - pa kufizime :-). Epo, përsëri, nëse ndodh ndonjë gjë, ne gjithmonë do të përpiqemi të ndihmojmë.

Ne duam që ky projekt të fillojë, në mënyrë që bota të bëhet më e besueshme falë nesh. Falë softuerit dhe shërbimeve të lira, bota është bërë më miqësore dhe po zhvillohet në mënyrë më dinamike. Burimet mund të ruhen në github falas, për postën mund të përdorni gmail falas. Ne përdorim falas punimet e freskëta për mbështetje. Për ndonjë nga këto, nuk keni nevojë të paguani për serverët, nuk keni nevojë të shkarkoni dhe konfiguroni dhe nuk keni nevojë të zgjidhni probleme të ndryshme operacionale. Çdo projekt i ri, çdo ekip ka menjëherë postë, depo dhe CRM. Dhe e gjithë kjo është shumë cilësore dhe falas dhe menjëherë. Ne duam që të jetë e njëjtë për monitorimin - kompanitë dhe projektet e vogla mund të përdorin okerr falas dhe madje edhe në fazën e lindjes dhe rritjes kanë besueshmërinë e projekteve serioze për të rritur.

Burimi: www.habr.com

Pasqyrë e sistemit hibrid të monitorimit Okerr