Két éve már írtam egy bejegyzést Egyszerű feladatátvétel egy webhelyhez körülbelül okerr. Most van némi fejlesztés a projektben, és publikáltam is okerr szerveroldali forráskód alatt nyílt licenc, ezért döntöttem úgy, hogy megírom ezt a rövid ismertetőt a Habr.

[ A teljes méretű ]

Akit érdekelhet

Ez érdekelheti Önt, ha kis csapatban vagy egyedül dolgozik. Nincs felügyelete, és nem biztos benne, hogy valóban szüksége van-e rá. Vagy kipróbáltál valami népszerű komoly monitorozást „a nagyfiúk számára”, de valahogy „nem jött be”, vagy szinte alapértelmezett konfigurációban működik, és nem változtatott sokat az életeden. És akkor is - ha határozottan nem tervezi egy teljes alkalmazott (vagy akár egy részleg) kiosztását a felügyeleti műszerfal napi legalább néhány órájának megfigyelésére vagy konfigurálására.

Miért szokatlan az okerr

Ezután az okerra érdekes tulajdonságait mutatom be, amelyek megkülönböztetik néhány más megfigyelőrendszertől.

Az Okerr egy hibrid monitorozás

A belső monitorozás során a felügyelt gépeken egy „ügynök” fut, amely adatokat (például szabad lemezterületet) továbbít a felügyeleti szervernek. Ha külső, a szerver a hálózaton keresztül ellenőrzi (például ping vagy webhely elérhetősége). Mindegyik megközelítésnek megvannak a maga korlátai. Okerr mindkét lehetőséget használja. A szervereken belüli ellenőrzéseket egy nagyon könnyű (30 Kb) ügynök vagy saját szkriptek és alkalmazások végzik, a hálózati ellenőrzéseket pedig okerr érzékelők végzik a különböző országokban.

Az okerr nem csak szoftver, hanem szolgáltatás is

Bármely megfigyelés szerver része nagy és összetett, nehéz telepíteni és konfigurálni, és erőforrásigényes. Az okerr-rel telepítheti saját megfigyelő szerverét (ingyenes és nyílt forráskódú), vagy egyszerűen csak a kliens részt használhatja és igénybe veheti szerverünk szolgáltatását. Szintén ingyenes.

Ha a felügyelet lehetővé teszi a szerverek és alkalmazások megbízhatóságának hiányának kompenzálását és elfedését, akkor felmerül egy filozófiai kérdés - ki az őr? Hogyan fog nekünk a monitorozás tájékoztatni egy problémát, ha az valamilyen okból „meghalt”, külön-külön vagy más erőforrásokkal együtt (például leesett az adatközponthoz vezető csatorna)? Az okerr külső szolgáltatás használatakor - ez a probléma megoldódott - akkor is kap egy figyelmeztetést, ha a teljes adatközpont a szervereivel áram nélkül van, vagy zombik támadják meg.

Természetesen fennáll annak a veszélye, hogy maga az okerr szerver nem lesz elérhető, ez igaz (mint tudod, a megbízhatóság 90%-a mindig egyszerűen és „ingyen” érhető el, 99%-a minimális erőfeszítéssel, és minden további kilenc exponenciálisan nehezebb). De egyrészt ennek kisebb az esélye, másrészt a probléma csak akkor maradhat észrevétlen, ha egybeesik a szervereink problémáival. Ha nekünk 99.9%-os a megbízhatóságunk, Öné pedig 99.9%-os (nem túl magas számok), akkor az észleletlen meghibásodás esélye 0.1% = 0.1% = 0.0001%. Szinte erőfeszítés és költség nélkül három kilences hozzáadásával a megbízhatóság nagyon jó!

A monitorozás, mint szolgáltatás másik előnye, hogy egy tárhelyszolgáltató vagy webstúdió telepíthet egy okerr szervert, és fizetős vagy ingyenes kiegészítő szolgáltatásként hozzáférést biztosít a kliensekhez. Versenytársaidnak csak tárhelyük és weboldalaik vannak, de Önnek megbízható tárhelye van megfigyeléssel.

Az Okerr a mutatókról szól

A jelző egy „villanykörte”. Két fő állapota van - zöld (OK) vagy piros (ERR). A projekt sok csoportosított (például szerver szerint) mutatót tartalmaz. A projekt főoldalán azonnal látod, hogy vagy minden zöld (és be is zárhatod), vagy valami pirosan világít és javítani kell. Amikor ezek között az állapotok között vált át, a rendszer riasztást küld. A beállítás során naponta egyszer elküldjük a projekt összefoglalóját.

Minden okerr indikátor beépített feltételekkel rendelkezik, amelyekkel megváltoztatja az állapotát (a Zabbixban ezt triggernek hívják). Például a terhelési átlag nem lehet több 2-nél (természetesen ez konfigurálható). És minden belső ellenőrzéshez (átlagos terhelés, lemezmentes, ...) jár egy őrző. Ha valamilyen oknál fogva nem kapunk sikeres visszaigazolást a megjelölt időpontban, hibaüzenetet rögzítünk és riasztást küldünk.

Szokásos munkarendünk az, hogy reggelente megnézzük az e-maileket, és a többi level mellett megnézzük az összefoglalót (munkakezdéskor ütemezzük). Ha minden rendben van benne, akkor más fontos dolgokat csinálunk (de a biztonság kedvéért gyorsan megnézhetjük az okerra műszerfalát, és megbizonyosodhatunk arról, hogy ebben a pillanatban minden zöld). Ha riasztás érkezik, reagálunk.

Természetesen lehetőség van egyszerűen „információs” indikátorok megtartására (a hálózat képének megjelenítésére a monitorozásból), de mindent megtesznek annak érdekében, hogy egyszerűen, egyszerűen és gyorsan készítsenek indikátorokat kifejezetten az automatikus figyeléshez és riasztások küldéséhez.

Az okerr beállítása a riasztások célja, hogy egy perc alatt létrehozhasson egy indikátort, egy évig "aludhat", csak frissítéseket fogad, és ha egy év múlva valami elromlik, akkor világít és küld egy figyelmeztetés. Az a perc, amit egyszer egy indikátor létrehozásával töltöttél, kifizetődő volt; azonnal értesült a problémáról, mindenki más előtt. Lehetséges, hogy kijavították, mielőtt bárki észrevette volna. Amit gyorsan felemelnek, az nem számít leesettnek!

biztonság

Kár lenne, ha a megbízhatóság növelése érdekében monitorozást állítanál be, de ennek eredményeként a hálózaton keresztül támadnak meg rajta keresztül, és elég sok hálózati sérülékenység található a különböző megfigyelő eszközökben (Zabbix, Nagios).

Ügynök (okerrmod a csomagból okerruptate) a rendszeren futó nem hálózati szerver, hanem kliens. Ezért a felügyelt szerveren nincsenek további nyitott portok, a kliens könnyen működik tűzfal vagy NAT mögött, és nagyon nehéz (mondanám "lehetetlen") feltörni a hálózaton keresztül, mivel elvileg nem figyel a hálózatra foglalat.

Teljes felügyeleti lefedettség

Most az a szabályunk, hogy minden technikai problémát az okerr-től tanulunk. Ha hirtelen megsértik a szabályt (az okerr nem figyelmeztetett a küszöbön álló előfordulására (ha ez lehetséges), vagy hogy már megtörtént) - ellenőrzéseket adunk az okerr-hez.

Külső ellenőrzések

Elég tipikus készlet:

• fütyülés
• http állapot
• az SSL-tanúsítvány érvényességének és frissességének ellenőrzése (figyelmeztetni fog, ha hamarosan lejár)
• nyissa meg a TCP portot és a rajta lévő bannert
• http grep (az oldal [nem] tartalmazhat konkrét szöveget)
• sha1 hash, hogy elkapja az oldal változásait.
• DNS (a DNS-rekordnak meghatározott értékkel kell rendelkeznie)
• WHOIS (figyelmeztetni fog, ha a domain megromlik)
• Antispam DNSBL (a gazdagép ellenőrzése egyszerre több mint 50 levélszemétellenes feketelistával)

Belső ellenőrzések

Emellett egy meglehetősen standard készlet (de könnyen bővíthető).

• df (szabad lemezterület)
• terhelési átlag
• opentcp (nyissa meg a TCP figyelő socketeket – értesít, ha valami elindult vagy összeomlott)
• üzemidő – csak üzemidő a szerveren. Értesít, ha lefelé változott (azaz a szerver túlterhelt)
• ügyfél_ip
• dirsize - arra használjuk, hogy nyomon kövessük, ha a virtuális gépünk rootfjai túllépik a megengedett méretet, szigorú korlátozások bevezetése nélkül, valamint a felhasználói saját könyvtárak méretét
• üres és nem üres – figyelje meg azokat a fájlokat, amelyeknek üresnek (vagy nem üresnek) kell lenniük. Pl. magának az okerr szervernek a hibanaplója legyen üres, és ha még egy sor is van benne, akkor kapok értesítést és megnézem. De a levelezőszerveren a mail.log NEM lehet üres (N perccel a forgatás után). És néha üres volt számunkra egy rendszerfrissítés után, amikor a logrotate nem tudta megfelelően újraindítani az rsyslogot.
• sorszám - a sorok száma a fájlban (például wc -l). Az üres puhább helyettesítésére használjuk, amikor a hibanapló még növekedhet, de csak lassan (például a Googlebot elér néhány lezárt oldalt). 2 percben legfeljebb 20 sor állhat. Ha magasabb, akkor riasztás lesz

Érdekes belső ellenőrzések

Ha eddig „átlósan” olvasott, most érdekesebb lesz figyelmesebben olvasni.

mentések

Figyeli a biztonsági mentéseket a könyvtárban. Biztonsági mentési fájljaink neve: „Kiszolgálónév-20200530.tar.gz”. Az okerr-ben minden egyes kiszolgálóhoz létrejön a ServerName-DATE.tar.gz jelző (a tényleges dátum a „DATE” sorra változik). A friss biztonsági mentés jelenlétét és méretét is figyeli (például nem lehet kevesebb, mint az előző mentés 90%-a).

Mit kell tenni egy új biztonsági másolat nyomon követéséhez, miután elkezdtük létrehozni és ebbe a könyvtárba helyezni? Semmi! Ez egy nagyon kényelmes megközelítés, amikor „semmit” kell tennie, mert:

• A „semmit” tenni elég gyors, időt takarít meg
• Nehéz elfelejteni a „semmit”
• Nehéz „semmit” rosszul csinálni, hibával. Semmi sem a legmegbízhatóbb módszer

Ha hirtelen leáll a friss biztonsági mentési fájlok megjelenése, akkor figyelmeztetés jelenik meg. Ha például letiltotta az egyik szervert, és nem kellene több biztonsági másolatot készíteni, akkor törölnie kell a jelzőt (a webes felületen vagy a shellből az API-n keresztül).

maxfilesz

Nyomon követi a legnagyobb fájlok méretét (általában: /var/log/*). Ez lehetővé teszi az előre nem látható problémák, például a brute force jelszavak vagy a kiszolgálón keresztüli spam küldésének észlelését.

runstatus/runline

Ez a két fontos proxy modul más programok futtatásához a kiszolgálón. A Runstatus jelenti a program kilépési kódját az indikátornak. Például az okerr nem (szükség) egy modulra annak ellenőrzéséhez, hogy a systemd szolgáltatások futnak-e. Ez a runstatuson keresztül történik (lásd alább). Runline – jelenti a kiszolgálónak a program által előállított sort. Például, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" a szerverünkön a Runline konfigurációban létrehoz egy szervernév:temp jelzőt a processzor hőmérsékletével.

sql

Numerikus lekérdezést hajt végre a MySQL-nek, és az eredményt jelenti az indikátornak. Egyszerű esetben megteheti például a „SELECT 1” parancsot - ez ellenőrzi, hogy a DBMS egésze működik-e.

De sokkal érdekesebb alkalmazás például a rendelések számának nyomon követése egy webáruházban. Ha tudja, hogy óránként 100 vagy több rendelése van, beállíthatja a minimális korlátot 100-ra vagy 80-ra. Ha az eladások hirtelen csökkennek, akkor kap egy figyelmeztetést, és kitalálhatja.

Vegye figyelembe, hogy nem számít, milyen előre nem látható okból történt ez:

• A szerver egyszerűen nem elérhető (feszültségmentes vagy hálózat nélkül), és a riasztás abból származott, hogy a jelző „rohadt”.
• A szerver túlterhelt valamivel, lassan működik vagy csomagok vesznek el, ez kényelmetlen a felhasználók számára és vásárlás nélkül távoznak
• A szerver szerepel a levélszemét listákon, az onnan érkező leveleket nem fogadják el, a felhasználók nem tudnak regisztrálni
• A reklámkampány költségvetése elfogyott, a bannerek nem pörögnek.

Ennek számos oka lehet, és mindegyik előre nem látható, és technikailag nehéz nyomon követni. De kényelmesen figyelemmel kísérheti a végső paramétert (megrendeléseket), és megállapíthatja belőlük, hogy a helyzet gyanús és megérdemli a kezelést.

Logikai mutatók

Lehetővé teszi logikai kifejezések (Python szintaxis) használatát egy modulon keresztül érvényesíteni(cikk Habréról). A projekt adatai és mutatói rendelkezésre állnak kifejezésre. Például a fenti SQL ellenőrzésről szóló fejezetben észrevehetett egy gyenge pontot - nappal 100 eladásunk lehet óránként, de éjszaka - 20, és ez gyakori, nem probléma. Mit kellene tennem? A jelző folyamatosan pánikba esik éjszaka.

Két mutatót hozhat létre, nappal és éjszaka. Mindkettő legyen „néma” (nem küldenek riasztást). És hozzon létre egy logikai jelzőt, amely megköveteli, hogy a nappali jelző rendben legyen 20:00 előtt, és 20:00 után elég, ha az éjszakai jelző rendben van.

Egy másik példa a logikai indikátor használatára az eszkaláció. Például egy projektmenedzser leiratkozik a riasztásokról (nem kell ezt megtennie, az adminisztrátoroknak reagálniuk kell a normál problémákra), de feliratkozik egy logikai jelzőre, amely pirosra vált, ha a projekt bármely mutatóját nem javítják ki a megadott időn belül.

Ezenkívül beállítható a munkavégzés megengedett ideje, például 3 és 5 óra között. Nem törődünk azzal, ha a szerverek és a webhelyek összeomlanak ez idő alatt. De 5:00-kor dolgozniuk kell. Ha máskor nem működnek - éber. A logikai jelző lehetővé teszi a szerver redundanciájának figyelembevételét is. Ha 5 webszervered van, akkor az adminisztrátorok bármikor kikapcsolhatnak 1-2 szervert. De ha 3 szerverből kevesebb, mint 5 van csatában, akkor riasztás lesz.

A fenti példák nem oker függvények, nem bizonyos funkciók, amelyeket aktiválni és konfigurálni kell. Az Okerra nem rendelkezik mindezekkel a funkciókkal, de van egy logikai modul, amely lehetővé teszi ennek a funkciónak a megvalósítását (kb. mint egy programozási nyelvben - ha vannak aritmetikai operátoraink, akkor nincs szükségünk speciális funkcióra a 20% ÁFA kiszámításához a nyelvből, bármikor megteheti saját maga, hogy az igényeinek megfelelően elkészítse).

A Logic Indicator valószínűleg az okerr néhány viszonylag összetett témakörének egyike, de a jó hír az, hogy nem kell elsajátítanod, amíg nem kell. Ugyanakkor nagymértékben kibővítik a képességeket, miközben magát a rendszert meglehetősen egyszerűvé teszik.

Saját csekk hozzáadása

Nagyon szeretném azt a gondolatot közvetíteni, hogy az okerr nem több ezer kész csekk halmaza minden alkalomra, hanem éppen ellenkezőleg - mindenekelőtt - egy egyszerű motor, amely egyszerűen képes saját csekkeket létrehozni. Saját ellenőrzések létrehozása az okerrben nem hackerek, rendszertársfejlesztők vagy legalábbis haladó okerr felhasználók feladata, hanem minden adminisztrátor számára megvalósítható feladat, aki egy hónapja telepítette először a Linuxot.

A minimálbérek ellenőrzése a modulon keresztül történik runstatus:

Ez a sor a konfigurációban runstatus értesíteni fog, ha a /bin/true hirtelen nem indul el, vagy valami mást ad vissza, mint 0.

true_OK=/bin/true

Csak egy sor – és máris itt vagyunk egy kicsit kiterjesztett funkcionalitás okerr.

Még egy ilyen ellenőrzésnek is megvan a maga értéke: ha a szerver hirtelen összeomlik, az okerr szerver megfelelő jelzője nem frissül kellő időben, és az idő letelte után figyelmeztetés jelenik meg.

Ez az ellenőrzés értesíti, hogy az apache2 szerver összeomlott (soha nem lehet tudni...):

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

Tehát, ha beszélsz bármilyen programozási nyelvet, és legalább tudsz shell szkripteket írni, akkor már hozzáadhatod a saját ellenőrzéseidet.

Nehezebb - megírhatja (bármilyen nyelven) saját modulját az okerrmod számára. A legegyszerűbb esetben így néz ki:

#!/usr/bin/python3

print("STATUS: OK")

Nem nagyon nehéz? A modulnak magának kell elvégeznie az ellenőrzést, és ki kell adnia az eredményeket az STDOUT-ba. Egy bonyolultabb modul például ezt adja:

$ 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

Egyszerre több indikátort frissít (üres sorral elválasztva), szükség esetén létrehozza azokat, jelzi az ellenőrzés részleteit és egy címkét, amellyel könnyen megtalálhatja a szükséges mutatókat a műszerfalon.

Telegram

Van egy Telegram bot @OkerrBot. Nem kell telezsúfolni a telefont különálló alkalmazásokkal (nem szeretem, hogy a Pyaterochka esetében egy alkalmazás kell térképpel, a Lentához egy másik, az MTS-hez egy harmadik, és így tovább mindenkinek, mindenkinek, mindennek). Egy távirat elég. A táviraton keresztül azonnal megkaphatja a riasztásokat, ellenőrizheti a projekt állapotát, és parancsot adhat az összes problémás jelző újraellenőrzésére. Elhagytuk a színházat/repülőt, két órán keresztül nem tartottuk az ujjunkat a pulzuson, bekapcsoltuk a telefont, megnyomtunk egy gombot a chatbotban, és megbizonyosodtunk róla, hogy minden rendben van.

Állapotoldalak

A státuszoldalak ma már szinte kötelezőek minden informatikával, a megbízhatóság iránti felelősségteljes hozzáállással, ügyfeleikkel/felhasználóival tisztelettel bánó vállalkozás számára.

Képzeljen el egy helyzetet – a felhasználó tenni akar valamit, információt szeretne megtekinteni vagy megrendelni szeretne, de valami nem működik. Nem tudja, mi történik, kinek az oldalán áll a probléma, és mikor oldják meg. Lehet, hogy cégének egyszerűen nem működő weboldala van? Vagy hat hónapja elromlott és két év múlva megjavítják? De most hűtőt kell venni, az már a kosárban van... Az pedig teljesen más kérdés, amikor az ember azt látja, hogy valami nincs rendben veled (legalábbis egyértelmű, hogy nem az ő oldalán van a probléma), hogy a problémát fedeztek fel, hogy már dolgoznak rajta, és talán még fel is írták a korrekció hozzávetőleges idejét. A felhasználó feliratkozhat és e-mail értesítést kaphat, ha a probléma megoldódott, és azt tehet, amit akar (hűtőszekrényt vásárolhat).

Problémák és leállások mindenkivel előfordulnak. De a felhasználók és a partnerek jobban bíznak azokban, akik átláthatóbbak és felelősségteljesebbek a témában.

Itt 10 másik projekt áttekintése, amelyek lehetővé teszik állapotoldalak létrehozását. Íme néhány példa arra, hogyan néznek ki ezek a projektoldalak Piton и dropbox. okerr állapotoldal.

Failover

Annak érdekében, hogy ez a cikk ne legyen még hosszabb, még egyszer utalok korábbi cikkemre - Egyszerű feladatátvétel egy webhelyhez . Ha tud duplikált szervert készíteni, akkor a feladatátvétellel alapvetően nem lesz hosszú leállási idő – amint egy problémát észlel, a felhasználók automatikusan átirányítják a működő tartalék szerverre. És számomra úgy tűnik, hogy ez egy nagyon érdekes, fényes funkció, amely ritkán érhető el bárhol.

Alacsony rendszerkövetelmény

Az okerr szerverekhez 2Gb RAM-mal rendelkező gépeket használunk. Hálózati szenzorokhoz még 512Mb is elég. A kliens rész általában majdnem nulla. (Nejlonzacskó okerruptate súlya 26 Kb, de Python3-ra és szabványos könyvtárakra van szükség). A kliens cron parancsfájlból fut, így nulla állandó memóriafelhasználása. Az általunk megfigyelt gépek között vannak szenzoraink (szuperolcsó VPS 512Mb RAM-mal) és egy Raspberry Pi. Ez a kliens rész nélkül is lehetséges frissítések küldése curl segítségével! (lásd alább)

Ezt figyelembe véve - okerr, valószínűleg leginkább ingyenes felügyeleti rendszert a rendelkezésre állók közül, mert még egy másik ingyenes nyílt forráskódú rendszer, mint a Zabbix vagy a Nagios használatához is erőforrásokat (szervert) kell hozzá rendelni, és ez már pénz. Ezen kívül némi szerverkarbantartásra is szükség van. Az okerr-rel ez a rész eltávolítható. Vagy nem kell eltávolítania, és a saját szerverét kell használnia, attól függően, hogy mit szeret a legjobban.

API és integráció védett szoftverbe

Egyszerű és nyitott architektúra. az okerrnek van egy elég egyszerű API, amivel könnyű dolgozni. 1000 mutatót kell létrehoznia? Egy 3-4 soros shell script megteszi ezt. Újra kell konfigurálnia 1000 jelzőt? Ez is nagyon könnyű. Például szeretnénk duplán ellenőrizni az összes HTTPS-tanúsítványunkat egy orosz érzékelőtől:

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

Kliens modulunk segítségével frissítheti az indikátort anélkül is, csak curl segítségével.

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

A mutatókat közvetlenül a programból frissítheti. Például szívverés jelek küldése, hogy az okerr tudja, hogy fut, és riaszt, ha összeomlik vagy lefagy. Mellesleg, az okerr komponensei pontosan ezt teszik – az okerr felügyeli magát, és szinte minden modulban észleli a problémákat, és riasztást generál a problémáról. (És ebben a „majdnem” esetben – másik szerverről ellenőrzik)

Íme a kód (egyszerűsítve) a távirat-botunkban:

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

Van egy könyvtár a Python programok indikátorainak frissítéséhez okerruptate, más nyelvekhez nincsenek könyvtárak, de meghívhatja az okerrupdate szkriptet, vagy HTTP kérést küldhet az okerr szervernek.

Hogyan segít nekünk az okerr

Okerr megváltoztatta az életünket. Valóban. Talán egy másik felügyeleti rendszer is megtehetné ugyanezt, de az okerr-rel való munka könnyű és egyszerű számunkra, és minden olyan funkcióval rendelkezik, amire szükségünk volt (amit nem, azt hozzáadtuk). Egyébként, ha hiányzik néhány funkció, kérdezz és felteszem (nem ígérem, de szeretném, ha az okerr lenne a legjobb megfigyelő rendszer kis-közepes projektekhez). Vagy ami még jobb, add hozzá magad – ez egyszerű.

Sikerült a „Tanulj minden problémáról a kerrából” elv szerint élni. Ha hirtelen olyan probléma lép fel, amiről nem tudtunk meg az okerr-től, akkor csekket adunk az okerr-hez. (jelen esetben a „mi” alatt a rendszer felhasználóiként értünk, nem társfejlesztőként). Eleinte ez általános volt, de mára nagyon ritka.

megfigyelés

Az okerr-n keresztül figyeljük a naplók méretét az összes szerveren. A napló minden sorát persze képtelenség átgondoltan szemmel olvasni, de a növekedési ütem egyszerű nyomon követése már sokat ad. Ezen keresztül felfedeztük a kéretlen levelek küldését és a brute force jelszavas kereséseket, és amikor egyes alkalmazások „megőrülnek”, valami nem megy nekik, és újra és újra megismétlik (minden alkalommal hozzáadnak néhány sort a naplóhoz ).

SSL tanúsítványok. Szinte azonnal indulás után LetsEncrypt ügyfelünk ingyenes SSL-tanúsítványokat kezdett biztosítani ügyfeleinek (kb. ezret). És kiderült, hogy pokol lett az adminisztráció számára! Az a tény, hogy a webhelyek „élőben vannak”, az ügyfelek időnként megkérik őket, hogy tegyenek valamit, a programozók megcsinálják. Teljesen szabadon átvihetik például az oldalt egy másik DocumentRoot-ba. Vagy adjon hozzá egy feltétel nélküli újraírást a virtualhost konfigurációjához. Ezt követően természetesen megszakad a tanúsítványok automatikus megújítása. Mostantól az összes SSL gazdagép automatikusan hozzáadódik az okerr-hez a csomagból egy másik hasznos segédprogramon keresztül a2conf. Csak indítsuk el a2okerr.py — és ha több új oldal is megjelenik a szerveren, azok automatikusan megjelennek az okerrben. Ha hirtelen valamilyen oknál fogva nem újítják meg a tanúsítványt, három héttel a tanúsítvány lejárta előtt, akkor tisztában vagyunk, és kitaláljuk, miért nem frissítik, egy ilyen kutya. a2certbot.py ugyanabból a csomagból - ebben sokat segít (a legvalószínűbb problémákat azonnal leellenőrzi - és jól megírja, hogy mit ellenőriztek, és hol van nagy valószínűséggel probléma).

Figyeljük minden domainünk lejárati idejét. És az összes levelet küldő levelezőszerverünket több mint 50 különböző feketelistán is ellenőrzik. (És néha beléjük esnek). Egyébként tudtad, hogy a Google levelezőszerverei is feketelistán vannak? A mail-wr1-f54.google.com címet önellenőrzés céljából hozzáadtuk a figyelt szerverekhez, és továbbra is a SORBS feketelistáján van! (Ez körülbelül a „levélszemét-elhárítók értékéről” szól)

Biztonsági mentések - fentebb már írtam, hogy okerr-rel mennyire egyszerű figyelni őket. De figyeljük a szerverünkön lévő legújabb biztonsági másolatokat és (egy külön okerr-t használó segédprogram segítségével) az Amazon Glacierre feltöltött biztonsági másolatokat. És igen, időnként előfordulnak problémák. Nem csoda, hogy figyeltek.

Az eszkalációjelzőt használjuk. Megmutatja, ha egy probléma hosszú ideig nem oldódott meg. És én magam is, amikor megoldok néhány problémát, néha elfelejthetem őket. Az eszkaláció jó emlékeztető, még akkor is, ha figyeli magát.

Összességében úgy gondolom, hogy munkánk minősége egy nagyságrenddel javult. Szinte nincs leállás (vagy a megrendelőnek nincs ideje észrevenni. Csak pszt!), miközben a munka mennyisége csökkent, a munkakörülmények nyugodtabbak lettek. A szalagos lyukfoltozású sürgősségi munkákról áttértünk a nyugodt és kimért munkára, amikor sok probléma előre megjósolható és van idő a megelőzésre. Még a megtörtént problémák is könnyebben orvosolhatóak lettek: egyrészt még azelőtt értesülünk róluk, hogy az ügyfelek pánikba esnek, másrészt gyakran előfordul, hogy a probléma a közelmúltban végzett munkával kapcsolatos (miközben egy dolgot csináltam, egy másikat elrontottam) így forró A nyomoknak könnyebb megbirkózni vele.

De volt egy másik eset is...

Tudtad, hogy a népszerű Debian 9-ben (Stretch) egy olyan népszerű csomag, mint a phpmyadmin, még (hosszú hónapok óta!) sebezhető állapotban van? (CVE-2019 6798-). Amikor a sérülékenység felbukkant, gyorsan különböző módokon fedeztük fel. De beállítottam a biztonsági nyomkövető oldal figyelését az okerr-ben, hogy tudjam, mikor jön ki egy „szép” megoldás (a tartalom SHA1 összegén keresztül). A jelző többször is megrándult, az oldal változott, de mint látható, továbbra sem (2019 januárja óta!) nem jelzi, hogy a probléma megoldódott volna. Esetleg esetleg valaki tudja, mi a probléma, hogy egy ilyen fontos csomag még több mint egy éve sebezhető?

Máskor is hasonló helyzetben: az SSH biztonsági rése után az összes szervert frissíteni kellett. És amikor beállít egy feladatot, ellenőriznie kell a végrehajtást. (A beosztottak hajlamosak félreérteni, elfelejteni, összezavarodni és hibázni). Ezért először SSH-verzióellenőrzést adtunk az okerr-hez az összes szerveren, és az okerr-n keresztül gondoskodtunk arról, hogy a frissítések minden szerveren megjelenjenek. (Kényelmes! Én ezt a típusú jelzőt választottam, és azonnal láthatod, hogy melyik szerver melyik verzióval rendelkezik). Amikor megbizonyosodtunk arról, hogy a feladat minden szerveren befejeződött, eltávolítottuk a jelzőket.

Néhányszor volt olyan helyzet, amikor egy bizonyos probléma felmerül, majd magától elmúlik. (valószínűleg mindenkinek ismerős?). Mire észreveszi, mire ellenőrzi – és nincs mit ellenőrizni –, már minden jól működik. De aztán megint eltörik. Ez történt például az Amazon Marketplace-re (MWS) feltöltött termékekkel. Valamikor a betöltött készlet hibás volt (rossz árumennyiség és rossz árak). Kitaláltuk. De ahhoz, hogy kitaláljuk, fontos volt, hogy azonnal tájékozódjunk a problémáról. Sajnos az MWS, mint minden Amazon szolgáltatás, kicsit lassú, így mindig volt egy késés, de ennek ellenére legalább nagyjából meg tudtuk érteni a kapcsolatot a probléma és az azt okozó szkriptek között (ellenőriztük, beragadt az okerrhez, és azonnal ellenőrizte, hogy riasztást kapott).

A közelmúltban egy érdekes tokkal bővítette a gyűjteményt egy nagy és drága európai hoster, amelyet ügyfelünk használ. Hirtelen az ÖSSZES szerverünk eltűnt a radarról! Először maga az ügyfél (gyorsabban, mint okerra!) vette észre, hogy az oldal, amellyel dolgozott, nem nyílik meg, és jegyet tett rá. De nem csak egy oldal szűnt meg, hanem az összes! (Natasha, mindent elejtettünk!). Itt Okerr hosszú lábtekercseket kezdett küldeni az összes jelzővel, ami neki világított. Pánik, pánik, körbe futunk (mit tehetünk még?). Aztán minden felemelkedett. Kiderült, hogy az adatközpontban rutin karbantartás volt (sokévente egyszer), és persze figyelmeztetni kellett volna minket. De valami probléma történt velük, és nem figyelmeztettek minket. Nos, több szívroham, kevesebb szívroham. De miután minden helyreállt, mindent újra kell ellenőriznie! El sem tudom képzelni, hogyan csinálnám a kezemmel. Okerr néhány perc alatt mindent tesztelt. Kiderült, hogy a legtöbb szerver egyszerűen átmenetileg nem elérhető, de működtek. Néhányan túlterheltek voltak, de felálltak, ahogy kellett. Az összes veszteségből két mentést veszítettünk el, amelyeket a korona szerint akkor kellett volna elkészíteni és betölteni, amikor ez a teljes banán ment. Nem is foglalkoztam a létrehozásukkal, csak egy nappal később érkeztek figyelmeztetések, hogy minden rendben van, biztonsági mentések jelentek meg. Nagyon szeretem ezt a példát, mert az okerr nagyon hasznosnak bizonyult egy olyan helyzetben, amelyre nem is gondoltunk előre, de ez a monitorozás célja - hogy ellenálljunk a kiszámíthatatlannak.

Az Okerr szenzorokhoz a lehető legolcsóbb tárhelyet használjuk (ahol a minőség és a megbízhatóság nem fontos, ott biztosítják egymást). Tehát nemrég találtunk egy nagyon jó tárhelyet, és szuper olcsó, a benchmarkok fantasztikusak. De... néha kiderül, hogy a virtuális gépből kimenő kapcsolatok egy másik (szomszédos) IP-ről jönnek létre. Csodák. Client_ip modul with https://diagnostic.opendns.com/myip rossz IP-t kap. Az indikátor szervernaplóiból pedig jól látszik, hogy a frissítés is erről a szomszédos IP-ről érkezett. Most foglalkozzunk a támogatással. Jó, hogy ezt békeidőben észrevettük. De például gyakran előfordul, hogy az IP fehérlista szerint regisztrálják a hozzáférést - és ha a szerver néha így pislog rövid ideig -, akkor ezt a problémát nagyon sokáig lehet elkapni.

Nos, még valami – mivel VPS hostingról beszélünk – mindig olcsókat használunk (hetzner, ovh, scaleway). Nagyon tetszik mind a mércék, mind a stabilitás tekintetében. Más projektekhez is a jóval drágább Amazon EC2-t használjuk. Tehát az okerr-nek köszönhetően megvan a saját megalapozott véleményünk. Mindketten elesnek. És nem mondanám, hogy megfigyeléseink hosszú ideje alatt az olyan olcsó tárhelyek, mint a hetzner, észrevehetően kevésbé stabilnak bizonyultak, mint az EC2. Ezért, ha nem kötődik más Amazon-szolgáltatásokhoz, miért fizetne többet? 🙂

Mi a következő lépés?

Ha ebben a szakaszban még nem riasztottalak el Okerrtől, akkor próbáld ki! Közvetlenül erre a linkre léphet okerr demo számla (Kattintson most!) De ne feledje, hogy mindenkinek csak egy demófiókja van, így ha csinál valamit, akkor ugyanabban a fiókban valaki más zavarhatja meg Önt. Vagy (jobb) regisztráljon a linken keresztül offsite okerr - minden egyszerű, SMS nélkül. Ha nem szereti az igazi e-mailjét használni, használhat eldobhatót, például mailinatort (javaslom getnada.com). Az ilyen fiókok idővel törölhetők, de tesztelésre alkalmasak.

A regisztráció után felkérjük, hogy vegyen részt képzésben (több, nem túl nehéz edzési feladat elvégzése). A kezdeti korlátok nagyon kicsik, de edzéshez vagy egy szerverhez elegendőek. A képzés befejezése után a korlátok (például a mutatók maximális száma) megemelkednek.

A dokumentációból - először is WIKI a szerver oldalon és a kliensen (okerrupdate wiki). De ha valami nem világos, írjon a support (at) okerr.com címre, vagy hagyjon jegyet - megpróbálunk mindent gyorsan megoldani.

Ha komolyan használod és ezek a megemelt limitek nem elegendőek, írj a supportnak és megemeljük (ingyen).

Szeretné telepíteni az okerr szervert a szerverére? Itt okerr-dev adattár. Javasoljuk, hogy tiszta virtuális gépre telepítse, majd egyszerűen megteheti egy telepítő szkripttel. A virtuális gépen - nincs korlátozás :-). Nos, még egyszer, ha bármi történik, mindig megpróbálunk segíteni.

Azt akarjuk, hogy ez a projekt elinduljon, hogy a világ megbízhatóbbá váljon nekünk köszönhetően. Az ingyenes szoftvereknek és szolgáltatásoknak köszönhetően a világ barátságosabbá vált és dinamikusabban fejlődik. A források ingyenes githubban tárolhatók, levelezéshez ingyenes gmail használható. Ingyenesen használjuk friss művek támogatásért. Mindehhez nem kell fizetni a szerverekért, nem kell letölteni és konfigurálni, és nem kell különféle működési problémákat megoldani. Minden új projekt, minden csapat azonnal megkapja a leveleket, a tárolókat és a CRM-et. És mindez nagyon jó minőségű és ingyenes és azonnal. Azt akarjuk, hogy ez a monitorozásnál is így legyen – kis cégek és projektek ingyen használhatnák az okerrt, és még a születési és növekedési szakaszban is a felnőttek komoly projektjeinek megbízhatósága lenne.

Forrás: will.com