Twee jaar gelede het ek reeds 'n plasing gemaak Eenvoudige failover vir 'n webwerf oor okerr. Nou is daar 'n mate van ontwikkeling van die projek, en ek het ook gepubliseer okerr bediener kant bronkode onder oop lisensie, daarom het ek besluit om hierdie kort resensie oor Habr.

[ volle grootte ]

Vir wie dit mag interesseer

Dit kan vir jou van belang wees as jy in 'n klein span of alleen werk. Jy het nie monitering nie en jy is nie seker of jy dit regtig nodig het nie. Óf jy het 'n paar gewilde ernstige monitering "vir die groot seuns" probeer, maar dit het op een of ander manier "nie vir jou opgestyg nie", of dit werk in 'n byna verstekkonfigurasie en het nie jou lewe veel verander nie. En ook - as jy beslis nie van plan is om 'n hele werknemer (of selfs 'n departement) toe te wys om die moniteringspaneelbord ten minste 'n paar uur per dag te monitor of dit op te stel nie.

Hoekom okerr is ongewoon

Volgende sal ek interessante kenmerke van die okerra wys wat dit van sommige ander moniteringstelsels onderskei.

Okerr is 'n hibriede monitering

Tydens interne monitering loop 'n "agent" op die gemonitorde masjiene, wat data na die moniteringsbediener oordra (byvoorbeeld vrye skyfspasie). Wanneer dit ekstern is, voer die bediener kontrole oor die netwerk uit (byvoorbeeld ping of webwerf beskikbaarheid). Elke benadering het sy beperkings. Okerr gebruik albei opsies. Kontroles binne bedieners word uitgevoer deur 'n baie ligte (30Kb) agent of jou eie skrifte en toepassings, en netwerkkontroles word deur okerr-sensors in verskillende lande uitgevoer.

okerr is nie net sagteware nie, maar ook 'n diens

Die bedienerdeel van enige monitering is groot en kompleks, dit is moeilik om te installeer en op te stel, en dit vereis hulpbronne. Met okerr kan jy jou eie moniteringsbediener installeer (dit is gratis en oopbron), of jy kan eenvoudig net die kliëntdeel gebruik en die diens van ons bediener gebruik. Ook gratis.

As monitering jou in staat stel om die gebrek aan betroubaarheid in bedieners en toepassings te vergoed en te bedek, dan ontstaan ​​'n filosofiese vraag - wie is die wag? Hoe sal monitering ons vertel van 'n probleem as dit self om een ​​of ander rede "gesterf" het, afsonderlik of saam met jou ander hulpbronne (byvoorbeeld, die kanaal na die datasentrum het geval)? Wanneer u die eksterne diens okerr gebruik - hierdie probleem is opgelos - sal u 'n waarskuwing ontvang selfs al is die hele datasentrum met u bedieners sonder krag of word deur zombies aangeval.

Natuurlik is daar 'n risiko dat die okerr-bediener self nie beskikbaar sal wees nie, dit is waar (soos u weet, word 90% van betroubaarheid altyd eenvoudig en "gratis" verkry, 99% met 'n minimum moeite, en elke daaropvolgende nege is eksponensieel moeiliker). Maar eerstens is die kanse dat dit gebeur minder, en tweedens kan die probleem slegs onopgemerk bly as dit saamval met probleme op ons bedieners. As ons 99.9% betroubaarheid het, en jy het 99.9% (nie te hoë getalle nie), dan is die kans op 'n onopgemerkte mislukking 0.1% van 0.1% = 0.0001%. Om amper sonder moeite en kosteloos drie nege by jou betroubaarheid te voeg, is baie goed!

Nog 'n voordeel van monitering as 'n diens is dat 'n gasheerverskaffer of webateljee 'n okerr-bediener kan installeer en toegang aan kliënte kan bied as 'n betaalde of gratis bykomende diens. Jou mededingers het net hosting en webwerwe, maar jy het betroubare hosting met monitering.

Okerr gaan oor aanwysers

Die aanwyser is 'n "gloeilamp". Dit het twee hooftoestande - groen (OK) of rooi (ERR). Die projek bevat baie gegroepeerde (byvoorbeeld volgens bediener) aanwysers. Op die hoofblad van die projek sien jy dadelik dat óf alles groen is (en jy kan dit toemaak), óf iets is rooi verlig en moet reggemaak word. Wanneer tussen hierdie state oorgeskakel word, word 'n waarskuwing gestuur. Een keer per dag terwyl jy dit opstel, word 'n opsomming van die projek gestuur.

Elke okerr-aanwyser het ingeboude toestande waardeur dit van toestand verander (in Zabbix word dit 'n sneller genoem). Byvoorbeeld, lasgemiddelde moet nie meer as 2 wees nie (natuurlik is dit konfigureerbaar). En vir elke interne kontrole (laai gemiddelde, skyfvry, ...) is daar 'n waghond. As ons om een ​​of ander rede nie 'n suksesvolle bevestiging op die vasgestelde tyd ontvang nie, word 'n fout aangeteken en 'n waarskuwing word gestuur.

Ons gewone werkpatroon is om soggens e-posse na te gaan en na die opsomming onder ander briewe te kyk (ons skeduleer dit aan die begin van werk). As alles in orde is, doen ons ander belangrike dinge (maar om veilig te wees, kan ons vinnig na die okerra-paneelbord kyk en seker maak dat alles op hierdie oomblik groen is). As 'n waarskuwing opdaag, reageer ons.

Natuurlik is dit moontlik om bloot "inligting"-aanwysers te hou (om die prentjie van die netwerk van monitering te sien), maar alles word gedoen om eenvoudig, maklik en vinnig aanwysers te skep spesifiek vir outomatiese monitering en die stuur van waarskuwings.

Die doel waarvoor jy okerr opstel, is in waarskuwings, sodat jy binne 'n minuut 'n aanwyser kan skep, dit kan vir 'n jaar "slaap", net opdaterings aanvaar, en wanneer 'n jaar later iets breek, brand dit en stuur 'n waarskuwing. Die minuut wat jy een keer spandeer het om 'n aanwyser te skep, het vrugte afgewerp; jy het dadelik van die probleem geleer, voor enigiemand anders. Dit is moontlik dat hulle dit reggemaak het voordat iemand opgemerk het. Iets wat vinnig opgewek word, word nie as geval beskou nie!

sekuriteit

Dit sal jammer wees as jy monitering opstel ter wille van die verhoging van betroubaarheid, maar as gevolg daarvan word jy daardeur oor die netwerk aangeval, en daar is heelwat netwerkkwesbaarhede in verskillende moniteringsnutsmiddels (Zabbix, Nagios).

Agent (okerrmod vanaf pakket okerrupdate) wat op die stelsel loop, is nie 'n netwerkbediener nie, maar 'n kliënt. Daarom is daar geen bykomende oop poorte op die gemonitorde bediener nie, die kliënt werk maklik agter 'n firewall of NAT en is baie moeilik (ek sou sê "onmoontlik") om oor die netwerk te hack, aangesien dit in beginsel nie na die netwerk luister nie sok.

Volledige moniteringsdekking

Nou is ons reël dat ons van okerr van alle tegniese probleme leer. As die reël skielik oortree word (okerr het nie gewaarsku oor sy dreigende voorkoms nie (indien dit moontlik is) of dat dit reeds plaasgevind het) - voeg ons tjeks by okerr.

Eksterne tjeks

Nogal 'n tipiese stel:

• ping
• http status
• kontroleer die geldigheid en varsheid van die SSL-sertifikaat (sal waarsku as dit op die punt staan ​​om te verval)
• oop TCP-poort en banier daarop
• http grep (die bladsy [moet nie] spesifieke teks bevat nie)
• sha1 hash om bladsyveranderinge op te vang.
• DNS (DNS-rekord moet 'n spesifieke waarde hê)
• WHOIS (sal waarsku as die domein op die punt is om sleg te gaan)
• Antispam DNSBL (gasheerkontrole teen 50+ antispam-swartlyste gelyktydig)

Interne tjeks

Ook 'n redelik standaard stel (maar maklik uitbreibaar).

• df (vrye skyfspasie)
• las gemiddelde
• opentcp (maak TCP-luistervoet oop - sal in kennis stel as iets begin of neergestort het)
• uptyd - net uptyd op die bediener. Sal in kennis stel as dit verander het (m.a.w. die bediener het oorlaai)
• kliënt_ip
• dirsize - ons gebruik dit om op te spoor wanneer ons virtuele masjien rootfs die toegelate grootte oorskry, sonder om streng beperkings in te stel, en die grootte van gebruiker tuisgidse
• leeg en nie leeg - monitor lêers wat leeg (of nie leeg) moet wees. Byvoorbeeld, die foutlogboek van die okerr-bediener self moet leeg wees, en as daar selfs 'n reël daarin is, sal ek 'n kennisgewing ontvang en dit kontroleer. Maar mail.log op die posbediener moet NIE leeg wees nie (N minute na rotasie). En soms was dit vir ons leeg na 'n stelselopdatering, wanneer logrotate nie rsyslog korrek kon herbegin nie.
• lyntelling - aantal reëls in die lêer (soos wc -l). Ons gebruik dit as 'n sagter plaasvervanger vir leeg, wanneer die foutlogboek nog kan groei, maar net stadig (byvoorbeeld, Googlebot tref sommige geslote bladsye). Daar is 'n beperking van 2 reëls in 20 minute. As dit hoër is, sal daar 'n waarskuwing wees

Interessante interne tjeks

As jy tot op hierdie punt "skuins" gelees het, sal dit nou interessanter wees om noukeuriger te lees.

rugsteun

Monitor rugsteun in die gids. Ons rugsteunlêers het name soos "ServerName-20200530.tar.gz". Vir elke bediener in okerr word die aanwyser ServerName-DATE.tar.gz geskep (die werklike datum verander na die reël "DATE"). Die teenwoordigheid van 'n nuwe rugsteun en die grootte daarvan word ook gemonitor (dit kan byvoorbeeld nie minder as 90% van die vorige rugsteun wees nie).

Wat moet gedoen word vir 'n nuwe rugsteun om opgespoor te word nadat ons dit begin skep het en dit in hierdie gids geplaas het? Niks! Dit is 'n baie gerieflike benadering wanneer jy "niks" moet doen nie, want:

• Om "niks" te doen is redelik vinnig, dit spaar tyd
• Dit is moeilik om te vergeet om "niks" te doen nie
• Dit is moeilik om "niks" verkeerd te doen met 'n fout nie. Niks is die mees betroubare metode nie

As vars rugsteunlêers skielik ophou om te verskyn, sal daar 'n waarskuwing wees. As jy byvoorbeeld een van die bedieners gedeaktiveer het, en daar behoort geen rugsteun meer te wees nie, sal jy die aanwyser moet uitvee (via die webkoppelvlak of vanaf die dop via die API).

maksimum lêers

Hou tred met die grootte van die grootste lêers (gewoonlik: /var/log/*). Dit laat jou toe om onvoorspelbare probleme op te vang, byvoorbeeld brute force-wagwoorde of die stuur van strooipos deur die bediener.

runstatus/runline

Dit is twee belangrike proxy-modules om ander programme op die bediener te laat loop. Runstatus rapporteer die programuitgangskode aan die aanwyser. Okerr (vereis) byvoorbeeld nie 'n module om seker te maak dat systemd-dienste loop nie. Dit word gedoen via runstatus (sien hieronder). Runline - rapporteer aan die bediener die lyn wat die program produseer. Byvoorbeeld, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" in die Runline-konfigurasie op ons bediener skep 'n aanwyser bedienernaam:temp met die verwerkertemperatuur.

sql

Voer 'n numeriese navraag na MySQL uit en rapporteer die resultaat aan die aanwyser. In 'n eenvoudige geval kan jy byvoorbeeld "SELECT 1" doen - dit sal seker maak dat die DBBS as geheel werk.

Maar 'n baie interessanter toepassing is byvoorbeeld om die aantal bestellings in 'n aanlynwinkel na te spoor. As jy weet dat jy 100 of meer bestellings per uur het, kan jy die minimum limiet op 100 of 80 stel. As jou verkope dan skielik daal, sal jy 'n waarskuwing ontvang en jy kan dit uitvind.

Let daarop dat dit nie saak maak vir watter onvoorspelbare rede dit gebeur het nie:

• Die bediener is eenvoudig nie beskikbaar nie (kragloos of sonder 'n netwerk), en die waarskuwing kom van die feit dat die aanwyser "vrot" was.
• Die bediener is oorlaai met iets, dit werk stadig of pakkies is verlore, dit is ongerieflik vir gebruikers en hulle vertrek sonder om aankope te doen
• Die bediener is by die strooiposlyste ingesluit en e-pos daarvan word nie aanvaar nie, gebruikers kan nie registreer nie
• Die advertensieveldtog se begroting het opgeraak, die baniere draai nie.

Daar kan 'n aantal redes wees, en almal kan nie vooraf voorsien word nie, en dit is tegnies moeilik om op te spoor. Maar jy kan gerieflik die finale parameter (bestellings) monitor en daaruit bepaal dat die situasie verdag is en verdien om hanteer te word.

Logiese aanwysers

Laat die gebruik van Boole-uitdrukkings (Python-sintaksis) via 'n module toe evalueer(artikel oor hub). Data van die projek en sy aanwysers is beskikbaar vir uitdrukking. Byvoorbeeld, in die hoofstuk oor SQL-kontrolering hierbo, het jy dalk 'n swak punt opgemerk - gedurende die dag kan ons 100 verkope per uur hê, maar in die nag - 20, en dit is algemeen, nie 'n probleem nie. Wat moet ek doen? Die aanwyser sal voortdurend in die nag paniekerig raak.

Jy kan twee aanwysers skep, dag en nag. Maak albei "stil" (hulle sal nie waarskuwings stuur nie). En skep 'n logiese aanwyser wat vereis dat die dagaanwyser voor 20:00 in orde is, en na 20:00 is dit genoeg dat die nagaanwyser OK is.

Nog 'n voorbeeld van die gebruik van 'n logiese aanwyser is eskalasie. Byvoorbeeld, 'n projekbestuurder teken uit van waarskuwings (hy hoef dit nie te doen nie, admins moet op normale probleme reageer), maar teken in op 'n logiese aanwyser wat rooi word as enige aanwyser in die projek nie binne die toegelate tyd reggestel word nie.

Dit is ook moontlik om die toegelate tyd vir werk in te stel, byvoorbeeld van 3 tot 5 vm. Ons gee nie om of bedieners en werwe in hierdie tyd ineenstort nie. Maar om 5:00 moet hulle werk. As hulle nie op enige ander tyd werk nie - waarskuwing. Die logiese aanwyser laat jou ook toe om bedieneroortolligheid in ag te neem. As jy 5 webbedieners het, kan admins te eniger tyd 1-2 bedieners afskakel. Maar as daar minder as 3 uit 5 bedieners in die geveg is, sal daar 'n waarskuwing wees.

Die voorbeelde hierbo is nie oker funksies nie, nie sommige kenmerke wat geaktiveer en gekonfigureer moet word nie. Okerra het nie al hierdie funksies nie, maar daar is 'n logiese module wat jou toelaat om hierdie funksionaliteit te implementeer (Ongeveer soos in 'n programmeertaal - as ons rekenkundige operateurs het, het ons nie 'n spesiale funksie nodig om 20% BTW te bereken nie uit die taal, kan jy dit altyd self doen, maak dit om jou behoeftes te pas).

Logic Indicator is waarskynlik een van die min relatief komplekse onderwerpe in okerr, maar die goeie nuus is dat jy dit nie hoef te bemeester totdat jy dit nodig het nie. Maar terselfdertyd brei hulle die vermoëns aansienlik uit, terwyl die stelsel self redelik eenvoudig gehou word.

Voeg u eie tjeks by

Ek wil regtig graag die idee oordra dat okerr nie 'n stel van duisende klaargemaakte tjeks vir alle geleenthede is nie, maar inteendeel - eerstens - 'n eenvoudige enjin met 'n eenvoudige vermoë om jou eie tjeks te skep. Die skep van jou eie tjeks in okerr is nie 'n taak vir hackers, stelsel mede-ontwikkelaars, of ten minste gevorderde okerr gebruikers nie, maar 'n uitvoerbare taak vir enige administrateur wat Linux vir die eerste keer 'n maand gelede geïnstalleer het.

Kontrole op minimum lone word deur die module gedoen hardloopstatus:

Hierdie reël in die config hardloopstatus sal jou in kennis stel as /bin/true skielik nie begin nie of iets anders as 0 gee.

true_OK=/bin/true

Net een reël - en hier is ons al 'n bietjie uitgebrei funksionaliteit okerr.

Selfs so 'n tjek het reeds sy waarde: as u bediener skielik ineenstort, sal die ooreenstemmende aanwyser op die okerr-bediener nie betyds opgedateer word nie, en nadat die tyd verby is, sal 'n waarskuwing verskyn.

Hierdie kontrole sal in kennis stel dat die apache2-bediener neergestort het (wel, jy weet nooit...):

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

Dus, as jy enige programmeertaal praat en ten minste skulpskrifte kan skryf, dan kan jy reeds jou eie tjeks byvoeg.

Moeiliker - jy kan (in enige taal) jou eie module vir okerrmod skryf. In die eenvoudigste geval lyk dit so:

#!/usr/bin/python3

print("STATUS: OK")

Is dit nie baie moeilik nie? Die module moet self die kontrole doen en die resultate na STDOUT uitstuur. 'n Meer komplekse module gee byvoorbeeld die volgende:

$ 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

Dit werk verskeie aanwysers tegelyk op (geskei deur 'n leë lyn), skep dit indien nodig, dui verifikasiebesonderhede aan en 'n merker waarmee dit maklik is om die nodige aanwysers in die dashboard te vind.

telegram

Daar is 'n Telegram-bot @OkerrBot. Jy hoef nie jou foon met aparte toepassings te vul nie (ek hou nie daarvan dat jy vir Pyaterochka een toepassing met 'n kaart nodig het nie, vir Lenta 'n ander, vir MTS 'n derde, ensovoorts vir almal, almal, almal). Een telegram is genoeg. Deur middel van telegram kan u onmiddellik waarskuwings ontvang, die status van die projek nagaan en 'n opdrag gee om alle problematiese aanwysers weer na te gaan. Ons het die teater/vliegtuig verlaat, vir twee ure nie ons vinger op die pols gehou nie, die foon aangeskakel, een knoppie in die chatbot gedruk en seker gemaak dat alles reg is.

Statusbladsye

Deesdae is statusbladsye amper 'n moet vir enige besigheid wat IT het, 'n verantwoordelike houding teenoor betroubaarheid en wat sy kliënte/gebruikers met respek behandel.

Stel jou 'n situasie voor - 'n gebruiker wil iets doen, inligting bekyk of 'n bestelling plaas, en iets werk nie. Hy weet nie wat aangaan, aan wie se kant die probleem is en wanneer dit opgelos sal word nie. Miskien het jou maatskappy bloot 'n nie-funksionele webwerf? Of het dit ses maande gelede gebreek en dit sal oor twee jaar reggemaak word? Maar jy moet nou 'n yskas koop, dit is reeds in die kar... En dit is 'n heel ander saak as 'n mens sien iets is fout met jou (dis darem duidelik dat die probleem nie aan sy kant is nie), dat die probleem ontdek is, dat jy reeds daaraan werk, en dalk selfs die benaderde tyd vir regstelling neergeskryf. Die gebruiker kan inteken en 'n e-poskennisgewing ontvang wanneer die probleem opgelos is en hy kan doen wat hy wil (koop 'n yskas).

Probleme en stilstand gebeur met almal. Maar gebruikers en vennote vertrou meer diegene wat meer deursigtig en verantwoordelik is in hul benadering hiertoe.

Hier hersiening van 10 ander projekte wat jou toelaat om statusbladsye te skep. Hier is voorbeelde van hoe hierdie projekbladsye lyk Python и Dropbox. okerr status bladsy.

fail

Om hierdie artikel nie nog langer te maak nie, sal ek weer na my vorige artikel verwys - Eenvoudige failover vir 'n webwerf . As jy 'n duplikaatbediener kan maak, sal jy basies nie 'n lang stilstand hê nie, met gebruik van failover - sodra 'n probleem opgespoor word, sal gebruikers outomaties na 'n werkende rugsteunbediener herlei word. En dit lyk vir my of dit 'n baie interessante, helder kenmerk is wat selde oral beskikbaar is.

Lae stelselvereistes

Vir okerr-bedieners gebruik ons ​​masjiene met RAM vanaf 2Gb. Vir netwerksensors is selfs 512Mb genoeg. Die kliënt deel is oor die algemeen amper nul. (Plastiese sak okerrupdate weeg 26 Kb, maar vereis Python3 en standaardbiblioteke). Die kliënt loop vanaf 'n cron script, so dit het geen aanhoudende geheueverbruik nie. Onder die masjiene wat ons gemonitor het, het ons sensors (super-goedkoop VPS met 512 Mb RAM) en 'n Raspberry Pi. Dit is moontlik selfs sonder die kliënt deel stuur opdaterings via krul! (sien onder)

As jy dit in ag neem - okerr, waarskynlik mees gratis moniteringstelsel van die beskikbare, want selfs om 'n ander gratis oopbronstelsel soos Zabbix of Nagios te gebruik, moet jy hulpbronne (bediener) daaraan toewys, en dit is reeds geld. Daarbenewens is 'n mate van bedieneronderhoud steeds nodig. Met okerr kan hierdie deel verwyder word. Of jy hoef dit nie te verwyder en jou eie bediener te gebruik nie, afhangende van waarvan jy die beste hou.

API en integrasie in eie sagteware

Eenvoudige en oop argitektuur. okerr het 'n redelik eenvoudige een API, wat maklik is om mee te werk. Moet 1000 aanwysers skep? Een dopskrif van 3-4 reëls sal dit doen. Moet 1000 aanwysers herkonfigureer? Dit is ook baie maklik. Ons wil byvoorbeeld al ons HTTPS-sertifikate vanaf 'n Russiese sensor dubbelkontroleer:

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

U kan die aanwyser opdateer met behulp van ons kliëntmodule, selfs daarsonder, net via krul.

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

U kan aanwysers direk vanaf u program opdateer. Stuur byvoorbeeld hartklopseine sodat okerr weet dat dit aan die gang is en 'n alarm maak as dit ineenstort of vries. Terloops, okerr-komponente doen presies dit - okerr monitor homself, en probleme in byna enige module sal opgespoor word en 'n waarskuwing oor die probleem genereer. (En in die geval van hierdie "amper" - hulle word gekruis nagegaan vanaf 'n ander bediener)

Hier is die kode (vereenvoudig) in ons telegrambot:

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

Daar is 'n biblioteek vir die opdatering van aanwysers vanaf Python-programme okerrupdate, vir enige ander tale is daar geen biblioteke nie, maar jy kan óf die okerrupdate-skrip bel óf 'n HTTP-versoek aan die okerr-bediener rig.

Hoe okerr ons help

Okerr het ons lewens verander. Inderdaad. Miskien kan 'n ander moniteringstelsel dieselfde doen, maar om met okerr te werk is maklik en eenvoudig vir ons en dit het al die funksies wat ons nodig gehad het (ons het bygevoeg wat dit nie gehad het nie). Terloops, as daar 'n paar kenmerke ontbreek, vra en ek sal dit byvoeg (ek belowe nie, maar ek wil hê okerr moet die beste moniteringstelsel vir klein-medium projekte wees). Of nog beter, voeg dit self by – dit is maklik.

Ons het daarin geslaag om te leef volgens die beginsel "leer oor alle probleme van die kerra." As daar skielik 'n probleem opduik waaroor ons nie van okerr geleer het nie, voeg ons 'n tjek by okerr. (in hierdie geval, met "ons" bedoel ek ons ​​as gebruikers van die stelsel, nie mede-ontwikkelaars nie). Aanvanklik was dit algemeen, maar nou het dit baie skaars geword.

Monitering

Deur okerr monitor ons die loggroottes op alle bedieners. Dit is natuurlik onmoontlik om elke reël van die log met jou oë bedagsaam te lees, maar om bloot die groeikoers te monitor, gee reeds baie. Hierdeur het ons gemorspos en brute force wagwoordsoektogte ontdek, en wanneer sommige van die toepassings "mal word", werk iets nie vir hulle uit nie en herhaal hulle dit weer en weer (elke keer voeg hulle 'n paar reëls by die logboek ).

SSL-sertifikate. Byna onmiddellik na bekendstelling Laat ons enkripteer ons kliënt het begin om gratis SSL-sertifikate aan sy kliënte te verskaf (ongeveer duisend van hulle). En dit blyk net hel vir administrasie te wees! Die feit is dat webwerwe "lewendig" is, kliënte vra hulle periodiek om iets te doen, programmeerders doen dit. Hulle kan byvoorbeeld die webwerf heeltemal vrylik na 'n ander DocumentRoot oordra. Of voeg 'n onvoorwaardelike herskryf by die virtualhost-konfigurasie. Natuurlik, hierna, breek die outomatiese hernuwing van sertifikate af. Nou het ons alle SSL-gashere outomaties by okerr gevoeg deur nog een van ons nuttige nutsprogramme uit die pakket a2conf. Kom ons begin net a2okerr.py - en as verskeie nuwe werwe op die bediener verskyn, sal hulle outomaties in okerr verskyn. As skielik om een ​​of ander rede die sertifikaat nie hernu word nie, drie weke voor die sertifikaat verval, is ons in die wete, en ons sal uitvind hoekom dit nie opgedateer word nie, so 'n hond. a2certbot.py uit dieselfde pakket - dit help baie hiermee (dit kontroleer dadelik die mees waarskynlike probleme - en skryf goed wat nagegaan is, en waar daar heel waarskynlik 'n probleem is).

Ons monitor die vervaldatum van al ons domeine. En al ons e-posbedieners wat e-pos stuur, word ook gekontroleer teen 50+ verskillende swartlyste. (En soms val hulle in hulle). Terloops, het jy geweet dat Google-posbedieners ook op die swartlys is? Net vir selftoetsing het ons mail-wr1-f54.google.com by die gemonitorde bedieners gevoeg, en dit is steeds op die SORBS-swartlys! (Dit gaan oor die waarde van "teen strooiposers")

Rugsteune - ek het reeds hierbo geskryf hoe maklik dit is om dit met okerr te monitor. Maar ons monitor beide die nuutste rugsteun op ons bediener en (met 'n aparte nutsprogram wat okerr gebruik) die rugsteun wat ons na Amazon Glacier oplaai. En, ja, probleme gebeur van tyd tot tyd. Geen wonder hulle het gekyk nie.

Ons gebruik die eskalasie-aanwyser. Dit wys of die een of ander probleem vir 'n lang tyd nie reggestel is nie. En ek self, wanneer ek 'n paar probleme oplos, kan ek soms daarvan vergeet. Eskalasie is 'n goeie herinnering, selfs al monitor jy jouself.

Oor die algemeen glo ek dat die kwaliteit van ons werk met 'n orde van grootte toegeneem het. Daar is amper geen stilstand nie (of die kliënt het nie tyd om dit raak te sien nie. Net shh!), terwyl die hoeveelheid werk kleiner geword het en die werksomstandighede rustiger geword het. Ons het oorbeweeg van noodwerk met die lap van gate met kleefband na kalm en afgemete werk, wanneer baie probleme vooraf voorspel word en daar tyd is om dit te voorkom. Selfs probleme wat gebeur het, het ook makliker geword om reg te stel: eerstens vind ons daarvan uit voordat kliënte paniekerig raak, en tweedens gebeur dit dikwels dat die probleem verband hou met onlangse werk (terwyl ek een ding gedoen het, het ek 'n ander gebreek) - so dit is warm Dis makliker vir spore om dit te hanteer.

Maar daar was 'n ander geval ...

Het jy geweet dat so 'n gewilde pakket soos phpmyadmin in die gewilde Debian 9 (Stretch) steeds (vir baie maande!) die kwesbare status is? (CVE-2019-6798). Toe die kwesbaarheid na vore gekom het, het ons dit vinnig op verskillende maniere gedek. Maar ek het die monitering van die sekuriteitspoor-bladsy in okerr opgestel om te weet wanneer 'n "pragtige" oplossing sal uitkom (via die SHA1-som van die inhoud). Die aanwyser het my verskeie kere geruk, die bladsy het verander, maar soos jy kan sien, dui dit steeds (sedert Januarie 2019!) nie aan dat die probleem opgelos is nie. Miskien, terloops, weet iemand wat die probleem is dat so 'n belangrike pakket nog vir meer as 'n jaar kwesbaar is?

Nog 'n keer in 'n soortgelyke situasie: na 'n kwesbaarheid in SSH, was dit nodig om alle bedieners op te dateer. En wanneer jy 'n taak opstel, moet jy die uitvoering beheer. (Ondergeskiktes is geneig om verkeerd te verstaan, te vergeet, verward te raak en foute te maak). Daarom het ons eers 'n SSH-weergawekontrole by okerr op alle bedieners gevoeg, en deur okerr het ons seker gemaak dat opdaterings op alle bedieners ontplooi is. (Gerieflik! Ek het hierdie tipe aanwyser gekies, en jy kan dadelik sien watter bediener watter weergawe het). Toe ons seker was dat die taak op alle bedieners voltooi is, het ons die aanwysers verwyder.

'n Paar keer was daar 'n situasie waar 'n sekere probleem opduik, en dan vanself verdwyn. (waarskynlik aan almal bekend?). Teen die tyd dat jy agterkom, teen die tyd dat jy nagaan - en daar is niks om na te gaan nie - werk alles reeds goed. Maar dan breek dit weer. Ons het dit byvoorbeeld gehad met produkte wat ons na Amazon Marketplace (MWS) opgelaai het. Op 'n stadium was die gelaaide voorraad verkeerd (verkeerde hoeveelhede goedere en verkeerde pryse). Ons het dit uitgepluis. Maar om dit uit te vind, was dit belangrik om dadelik oor die probleem uit te vind. Ongelukkig is MWS, soos alle Amazon-dienste, 'n bietjie stadig, so daar was altyd 'n vertraging, maar tog kon ons ten minste die verband tussen die probleem en die skrifte wat dit veroorsaak, verstaan ​​(ons het 'n kontrole gedoen, vas dit aan die okerr, en nagegaan dit onmiddellik ontvang 'n waarskuwing).

'n Interessante saak is onlangs by die versameling gevoeg deur 'n groot en duur Europese gasheer, wat ons kliënt gebruik. Skielik het AL ons bedieners van die radar verdwyn! Eerstens het die kliënt self (vinniger as okerra!) opgemerk dat die webwerf waarmee hy gewerk het nie oopmaak nie en het 'n kaartjie daaroor gemaak. Maar nie net een webwerf het afgegaan nie, maar almal van hulle! (Natasha, ons het alles laat val!). Hier het Okerr begin om lang voet-omhulsels te stuur met al die aanwysers wat vir hom opgelig het. Paniek, paniek, ons hardloop in sirkels (wat anders kan ons doen?). Toe het alles opgestaan. Dit blyk dat daar roetine-instandhouding in die datasentrum was (een keer elke baie jaar) en ons moes natuurlik gewaarsku gewees het. Maar 'n soort probleem het met hulle gebeur en hulle het ons nie gewaarsku nie. Wel, meer hartaanvalle, minder hartaanvalle. Maar nadat alles herstel is, moet jy alles dubbel kontroleer! Ek kan nie dink hoe ek dit met my hande sou doen nie. Okerr het alles binne 'n paar minute getoets. Dit het geblyk dat die meeste van die bedieners eenvoudig tydelik onbeskikbaar was, maar hulle het gewerk. Sommige was oorlaai, maar het ook opgestaan ​​soos hulle moes. Van al die verliese het ons twee rugsteun verloor, wat volgens die kroon geskep en gelaai moes gewees het terwyl hierdie vol piesang aan die gang was. Ek het nie eers die moeite gedoen om hulle te skep nie, net 'n dag later het waarskuwings gekom dat alles in orde is, rugsteun het verskyn. Ek hou baie van hierdie voorbeeld omdat okerr baie nuttig geblyk het in 'n situasie waaraan ons nie eers vooraf gedink het nie, maar dit is die doel van monitering - om die onvoorspelbare te weerstaan.

Vir Okerr-sensors gebruik ons ​​die goedkoopste moontlike hosting (waar kwaliteit en betroubaarheid nie belangrik is nie, verseker hulle mekaar). So, ons het onlangs 'n baie goeie gasheer en super goedkoop gevind, die maatstawwe is fantasties. Maar ... soms blyk dit dat uitgaande verbindings vanaf die virtuele masjien van 'n ander (naburige) IP gemaak word. Wonderwerke. Client_ip module met https://diagnostic.opendns.com/myip kry die verkeerde IP. En uit die bedienerlogboeke van die aanwyser is dit duidelik dat die opdatering ook van hierdie naburige IP gekom het. Kom ons hanteer die ondersteuning nou. Dis goed dat ons dit in vredestyd opgemerk het. Maar dit gebeur byvoorbeeld dikwels dat toegang volgens die IP-witlys geregistreer word - en as die bediener soms vir 'n kort rukkie so flikker - kan jy hierdie probleem baie lank probeer opvang.

Wel, nog een ding – aangesien ons oor VPS-hosting praat – gebruik ons ​​altyd goedkoops (hetzner, ovh, scaleway). Ek hou baie daarvan, beide wat maatstawwe en stabiliteit betref. Ons gebruik ook die baie duurder Amazon EC2 vir ander projekte. So, danksy okerr, het ons ons eie ingeligte mening. Hulle altwee val. En ek sou nie sê dat goedkoop hostings soos hetzner oor die lang tydperk van ons waarnemings merkbaar minder stabiel geblyk het te wees as EC2 nie. Daarom, as jy nie gekoppel is aan ander Amazon-kenmerke nie, hoekom meer betaal? 🙂

Wat is volgende?

As ek jou op hierdie stadium nog nie van Okerr weggeskrik het nie, probeer dit dan! Jy kan direk na hierdie skakel gaan okerr demo rekening (Klik nou!) Maar hou in gedagte dat daar net een demo-rekening vir almal is, so as jy iets doen, kan iemand anders in dieselfde rekening met jou inmeng op dieselfde tyd. Of (beter) registreer via die skakel na offsite okerr - alles is eenvoudig, sonder SMS. As jy nie daarvan hou om jou regte e-pos te gebruik nie, kan jy 'n weggooibare een gebruik, soos mailinator (ek beveel aan getnada.com). Sulke rekeninge kan mettertyd uitgevee word, maar dit sal goed wees om te toets.

Na registrasie sal jy gevra word om opleiding te ondergaan (vertel verskeie nie baie moeilike opleidingstake). Die aanvanklike limiete is baie klein, maar vir opleiding of een bediener is dit genoeg. Na voltooiing van die opleiding sal die limiete (byvoorbeeld die maksimum aantal aanwysers) verhoog word.

Uit die dokumentasie - eerstens WIKI aan die bedienerkant en op die kliënt (okerrupdate wiki). Maar as iets onduidelik is, skryf aan support (by) okerr.com of los 'n kaartjie - ons sal probeer om alles vinnig op te los.

As jy dit ernstig gebruik en hierdie verhoogde limiete is nie genoeg nie, skryf aan ondersteuning en ons sal dit verhoog (gratis).

Wil jy die okerr-bediener op jou bediener installeer? Hier okerr-dev-bewaarplek. Ons beveel aan om op 'n skoon virtuele masjien te installeer, dan kan u dit eenvoudig met 'n installasieskrip doen. Op jou virtuele masjien - geen beperkings :-). Wel, weer, as iets gebeur, sal ons altyd probeer om te help.

Ons wil hê hierdie projek moet opstyg, sodat die wêreld danksy ons meer betroubaar word. Danksy gratis sagteware en dienste het die wêreld vriendeliker geword en ontwikkel dit meer dinamies. Die bronne kan in die gratis github gestoor word, en vir pos kan jy die gratis gmail gebruik. Ons gebruik gratis varswerke vir ondersteuning. Vir enige hiervan hoef jy nie vir bedieners te betaal nie, jy hoef nie af te laai en op te stel nie, en jy hoef nie verskeie operasionele probleme op te los nie. Elke nuwe projek, elke span het onmiddellik pos, bewaarplekke en CRM. En dit alles is van baie hoë gehalte en gratis en onmiddellik. Ons wil hê dit moet dieselfde wees vir monitering - klein maatskappye en projekte kan okerr gratis gebruik en selfs in die stadium van geboorte en groei het die betroubaarheid van volwasse ernstige projekte.

Bron: will.com