Két évvel ezelőtt már írtam egy bejegyzést a . Jelenleg van néhány fejlődés a projekten, és közzétettem alá esnek , ezért döntöttem úgy, hogy írok a hHubra erről a kis áttekintésről.
[ ]
Kinek lehet ez érdekes
Önnek ez érdekes lehet, ha kisebb csapattal dolgozik, vagy akár egyedül. Nincs monitoringja, és nem biztos abban, hogy pontosan szüksége van rá. Vagy lehet, hogy kipróbált egy népszerű, komoly monitoringot "nagyfiúk" számára, de az valahogy nem jött be, vagy csak majdnem alapértelmezett konfigurációban működik, és nem változtatta meg sokat az életét. Továbbá - ha biztosan nem tervezi, hogy egy alkalmazottat (vagy akár egy osztályt) állítson be arra, hogy naponta legalább pár órát a monitoring dashboardon figyeljen vagy konfiguráljon.
Miben különleges az okerr
Később megmutatom az okerr érdekes tulajdonságait, amelyek megkülönböztetik más monitorozóktól.
Okerr - ez egy hibrid monitorozás
Belső monitorozás esetén a megfigyelt gépeken egy "ügynök" fut, amely átadja az adatokat a monitoring szervernek (például a lemez szabad helyét). Külső monitorozásnál a szerver ellenőrzéseket végez a hálózaton (például ping, vagy weboldal elérhetősége). Mindkét megközelítésnek megvannak a saját korlátai. Az okerr mindkét módszert alkalmazza. A szerverek belső ellenőrzéseit nagyon könnyű (30Kb) ügynök végzi, vagy a saját szkriptjei és alkalmazásai, míg a hálózati ellenőrzéseket az okerr érzékelői különböző országokban.
Az okerr nem csupán szoftver, hanem egy szolgáltatás is
A monitoring szerveroldala nagy és összetett dolog, nehezen telepíthető és konfigurálható, erőforrásokat igényel. Az okerr révén saját monitoring szerverét telepítheti (ez ingyenes és nyílt forráskódú), vagy egyszerűen csak használhatja az ügyféloldali részt, és élvezheti a mi szerverünk szolgáltatását. Ez is ingyenes.
Ha a monitorozás lehetővé teszi a szerverek és alkalmazások megbízhatatlanságának kompenzálását, akkor felmerül a filozófiai kérdés – ki vigyáz a vigyázóra? Hogyan fog a monitorozás értesíteni minket a problémáról, ha ő maga „meghalt” valamilyen okból, egyedül vagy más forrásokkal együtt (például leállt a csatorna az adatközpontba)? A külső szolgáltatás, az okerr használatával ez a probléma megoldódik – figyelmeztetést kap, még akkor is, ha az összes szervere az adatközpontban áramtalanítva van vagy zombi támadásnak van kitéve.
Természetesen van kockázat, hogy az okerr szerver maga is elérhetetlenné válik, ez igaz (mint tudjuk, a megbízhatóság 90%-a mindig egyszerűen és „ingyen” érhető el, a 99% minimális erőfeszítéssel, és minden további kilences exponenciálisan nehezebb). De először is, ennek az esélye alacsonyabb, másodszor pedig a probléma csak akkor maradhat észrevétlen, ha egybeesik a mi szervereink problémáival. Ha nekünk 99,9%-os megbízhatóságunk van, és neked is 99,9% (ami nem túlságosan magas szám), akkor az észrevétlen hibák esélye – 0,1% a 0,1%-ból = 0,0001%. Három kilencest hozzáadni a megbízhatósághoz szinte erőfeszítés és költségek nélkül – ez igazán kedvező!
A monitoring mint szolgáltatás egy újabb előnye, hogy a hosting szolgáltató vagy webstúdió telepítheti az okerr szervert és ügyfeleinek hozzáférést biztosíthat fizetett vagy ingyenes kiegészítő szolgáltatásként. Versenytársaidnak csak hostingjuk és weboldalaik vannak – míg nálad megbízható hosting monitoringgal.
Az okerr az indikátorokról szól.
Az indikátor egy „izzó lámpa”. Két alapvető állapota van – zöld (OK) vagy piros (ERR). A projektben több csoportosított (például szerverek szerint) indikátor található. A projekt főoldalán azonnal láthatod, hogy minden zöld (és le lehet zárni) vagy hogy valami éppen pirosan világít, és javítani kell. Az állapotok közötti váltásnál értesítést küldenek. Naponta egyszer, ahogy beállítod – összefoglalót küldenek a projektről.
Minden okerr indikátor beépített feltételekkel rendelkezik, amelyek alapján megváltoztatja állapotát (a Zabbix-ban ezt trigger-nek hívják). Például a load average nem lehet több mint 2 (természetesen ez testreszabható). És minden belső ellenőrzéshez (load average, szabad lemez, ...) van watchdog. Ha valamilyen okból nem kaptunk sikeres megerősítést a megadott időben – hiba kerül regisztrálásra, és értesítést küldenek.
A munka szokásos menete nálunk - reggeli e-mail ellenőrzés, ahol a többi levél mellett megnézzük az összefoglalót (ennek az időpontját a munkakezdés kezdetére állítjuk be). Ha minden rendben van benne, akkor fontosabb dolgokkal foglalkozunk (de a megbízhatóság kedvéért gyorsan ránézhetünk az okerr irányítópultjára, megbizonyosodva arról, hogy ebben a pillanatban is minden zöld). Ha érkezik figyelmeztetés, reagálunk.
Természetesen van lehetőség arra, hogy egyszerűen csak információs mutatókat tartsunk (hogy láthassuk a monitorozási hálózat képét), de minden úgy van elkészítve, hogy egyszerűen, könnyen és gyorsan készíthessünk mutatókat automatikus megfigyelésre és figyelmeztetések küldésére.
Az az értelme, amiért beállítja az okerr-t - a figyelmeztetések, hogy egy perc alatt létrehozhasson egy mutatót, ami egy évig "aludhatott", csak fogadta az frissítéseket, és amikor egy év múlva valami elromlik - felgyullad és figyelmeztetést küld. Az a perc, amit egyszer költött a mutató létrehozására, megtérült, azonnal tudomást szerzett a problémáról, még mielőtt mások. Lehetséges, hogy meg is javította, mielőtt bárki észrevette volna. A gyorsan felemelt nem számít leesettnek!
Biztonság
Sajnálatos lenne, ha a megbízhatóság növelése érdekében állít be monitorozást, és ennek eredményeként - rajta keresztül támadások érkeznek az Ön hálózatára, és a különböző monitorozó eszközöknek számos hálózati sebezhetősége van (, ).
Az ügynök (okerrmod a csomagból ), amely a rendszeren működik - nem hálózati szerver, hanem kliens. Ezért a megfigyelt szerveren nincsenek extra nyitott portok, a kliens könnyen működik a tűzfal vagy NAT mögött, és nagyon nehéz (mondhatnám, hogy "lehetetlen") feltörni hálózaton, mivel alapvetően nem hallgat hálózati socketen.
Teljes monitoring lefedettség
Most már van egy szabályunk - minden technikai problémát az okerr-ből tudunk meg. Ha váratlanul megsérül a szabály (az okerr nem figyelmeztetett a hamarosan bekövetkező eseményről (ha ez lehetséges) vagy arról, hogy az már megtörtént) - további ellenőrzéseket adunk hozzá az okerr-hez.
Külső ellenőrzések
Eléggé tipikus készlet:
- ping
- http státusz
- SSL tanúsítvány érvényességének és frissességének ellenőrzése (figyelmeztet, ha a lejárat közeleg)
- nyitott TCP port és banner rajta
- http grep (az oldalon [nem] szabad egy bizonyos szövegnek szerepelnie)
- sha1 hash az oldal változásának észlelésére.
- DNS (a DNS rekordnak meg kell hogy legyen egy bizonyos értéke)
- WHOIS (figyelmeztet, ha a domain hamarosan lejár)
- Antispam DNSBL (a gazdagép azonnali ellenőrzése 50+ spamellenes fekete listán)
Belső ellenőrzések
Ez is egy meglehetősen tipikus készlet (de könnyen bővíthető).
- df (szabad terület a lemezeken)
- load average
- opentcp (nyitott, hallgatózó TCP socketek - értesít, ha valami elindul vagy leáll)
- uptime - egyszerűen a szerver uptime-ja. Értesít, ha csökken (azaz a szerver újraindul)
- client_ip
- dirsize - ezt használjuk a virtuális gépek rootfs-ének engedélyezett méret feletti nyomon követésére, anélkül, hogy szigorú korlátozásokat vezetnénk be, és a felhasználók otthoni mappáinak méretét is figyelemmel kísérjük.
- empty és nonempty - figyelik azokat a fájlokat, amelyeknek üresnek (vagy nem üresnek) kell lenniük. Például a szerver error logja, az okerr, üresnek kell lennie, és ha van benne egyetlen sor is, értesítést kapok és ellenőrzöm. Ezzel szemben a mail.log a levelezőszerveren NEM lehet üres (P néhány perccel a rotáció után). Néha üres volt, amikor a rendszer frissítése miatt a logrotate nem tudta helyesen újraindítani a rsyslog-ot.
- linecount - a fájl sorainak száma (mint a wc -l). Ezt egy lágyabb alternatívaként használjuk az empty helyett, amikor az error log növekedhet, de csak lassan (például a Googlebot elérhet néhány zárt oldalt). 2 sor 20 perc alatt a limitem. Ha túllépik - riasztás.
Érdekes belső ellenőrzések
Ha eddig „átfutottad” ezt a részt, most érdemesebb figyelmesebben olvasni.
backups
Figyeli a mappában található biztonsági mentéseket. A biztonsági mentési fájljaink nevei hasonlóak, mint például „ServerName-20200530.tar.gz”. Minden szerverhez készül egy indikátor okerr rendszerben a ServerName-DATE.tar.gz (a tényleges dátum a „DATE” sorra változik). Figyelünk a friss biztonsági mentés jelenlétére és méretére is (például nem lehet kisebb, mint a korábbi biztonsági mentés 90%-a).
Mit kell tennünk, hogy az új biztonsági mentés nyomon követésre kerüljön, miután elkezdtük létrehozni és elhelyezni ebben a könyvtárban? Semmit! Ez egy nagyon kényelmes megközelítés, amikor „semmit” kell tenni, mivel:
- A „semmi” gyorsan elvégezhető, ami időt takarít meg.
- Nehéz elfelejteni, hogy „semmit” kell tenni.
- Nehéz helytelenül, hibásan „semmit” tenni. A semmi a legmegbízhatóbb módszer.
Ha pedig hirtelen nem jelennek meg frissebb biztonsági mentési fájlok - lesz riasztás. Ha például leállítottál egy szervert, és annak biztonsági mentései nem is kellene már meglennie - törölnöd kell az indikátort (a webes felületen vagy a shellből API-n keresztül).
maxfilesz
Figyelemmel kíséri a legnagyobb fájlok méretét (általában: /var/log/*). Ez lehetővé teszi a váratlan problémák, például a jelszavak kipróbálásának vagy a spam küldésének a kiszűrését a szerveren.
runstatus/runline
Ezek két fontos proxy modul, más programok indításához a szerveren. A runstatus tájékoztat a program kilépési kódjáról. Például az okerr nem igényel modult annak ellenőrzésére, hogy a systemd szolgáltatások működnek. Ezt a runstatus kezeli (lásd alább). A runline pedig arról tájékoztat a szerveren, hogy a program milyen sort ad ki. Például, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" a Runline konfigurációjában a szerverünk létrehoz egy temp indikátort a processzor hőmérsékletével, amelynek neve servername:temp.
sql
Numerikus lekérdezést hajt végre a MySQL-en, és az eredményt jelzőt mutatja. Egyszerű esetben például kérdezhetjük: „SELECT 1” – ez ellenőrzi, hogy alapvetően a DBMS működik.
De sokkal érdekesebb alkalmazás, például nyomon követni az internetes bolt rendelések számát. Ha tudja, hogy óránként 100 rendelése van, beállíthat egy minimális küszöböt 100-ra vagy 80-ra. Akkor ha hirtelen csökkennek az eladások, riasztást kap, és utánanézhet.
Vegye észre — nem számít, miért történt ez váratlanul:
- A szerver egyszerűen nem elérhető (áramkimaradás vagy hálózati probléma miatt), a riasztást pedig az indította, hogy a 'lejárt' indikátor.
- A szerver valamilyen terhelés alatt van, lassan működik vagy csomagok vesznek el, a felhasználóknak kényelmetlen és elhagyják a vásárlást.
- A szervert spamlistákra tették fel, és az üzeneteit nem fogadják el, a felhasználók nem tudnak regisztrálni.
- Lejárt a reklámkampány költségvetése, a bannerek nem futnak.
Sok oka lehet, és ezeket előre nem lehet megjósolni, technikailag nehéz nyomon követni. De kényelmesen figyelemmel kísérheti a végső paramétert (rendelések), és ezen keresztül megállapíthatja, hogy a helyzet gyanús, és érdemes foglalkozni vele.
Logikai indikátorok
Lehetővé teszi logikai kifejezések használatát (Python szintaxis) a modulon keresztül. (). A kifejezéshez elérhetők a projekt és annak indikátorainak adatai. Például a fenti SQL ellenőrzés fejezetéből talán észrevette a gyenge pontot — nappal óránként 100 eladásunk lehet, de éjszaka 20, és ez normális dolog, nem probléma. Mit tegyünk? Az indikátor éjszaka folyamatosan pánikba esne.
Két indikátor hozható létre, napközi és éjszakai. Mindkettőt „csendesre” állíthatjuk (nem fognak értesítéseket küldeni). És létrehozhatunk egy logikai indikátort, amely megköveteli, hogy 20:00-ig a napközi indikátor rendben legyen, és 20:00 után elegendő, ha az éjszakai indikátor rendben van.
Egy másik példa a logikai indikátor használatára — escaláció. Például egy projektmenedzser leiratkozik az értesítésekről (nincs rá szüksége, az adminisztrátoroknak kell reagálniuk a normál problémákra), de feliratkozik egy logikai indikátorra, amely pirosra vált, ha bármely indikátor a projektben nincs javítva az előírt időn belül.
Továbbá — lehetőség van engedélyezett időszakokat kijelölni, például hajnal 3-tól 5-ig. Nem zavar minket, ha a szerverek és oldalak ebben az időszakban „leesnek”. De 5:00-ra működniük kell. Ha bármikor más időpontban nem működnek — értesítés. A logikai indikátor lehetővé teszi a szerverek tartalékainak figyelembevételét is. Ha 5 webkiszolgálója van, az adminisztrátorok bármikor leállíthatnak 1-2 szervert. De ha a harcban kevesebb mint 3 az 5 szerver működik — értesítés lesz.
A fentiek példák nem az okerr funkcionalitásai, nem olyan funkciók, amelyeket aktiválni és beállítani kell. Ezek a funkciók az okerrben nem találhatók, de van egy logikai modul, amely lehetővé teszi ezek megvalósítását (Olyan, mint a programozási nyelvben — ha van aritmetikai operátorunk, akkor nincs szükségünk a nyelvtől egy külön funkcióra, amely kiszámítja a 20% ÁFA-t, azt mindig meg lehet csinálni saját igények szerint).
A logikai indikátor talán az okerr egyik viszonylag bonyolult témája, de a jó hír az, hogy nem szükséges elsajátítani őket, amíg nincs rá szükség. De ugyanakkor jelentősen bővítik a lehetőségeket, megőrizve a rendszert egyszerűnek.
Saját ellenőrzések hozzáadása
Nagyon szeretném közvetíteni azt a gondolatot, hogy az okerr nem egy ezer kész ellenőrzésből álló csomag minden esetre, hanem éppen ellenkezőleg — elsősorban egy egyszerű motor, amely lehetővé teszi a saját ellenőrzések létrehozását. A saját ellenőrzések létrehozása az okerrben nem hacker, a rendszer együttműködő fejlesztői vagy legalább haladó okerr felhasználók feladata, hanem bármely adminisztrátorra vonatkozó, aki egy hónappal ezelőtt először telepítette a linuxot.
A minimális ellenőrzések a :
Ez a sor a konfigurációban értesítést küld, ha esetleg a /bin/true nem indul el, vagy nem 0-val tér vissza.
true_OK=\/bin\/trueEgyetlen sor, és máris egy kicsit bővítettük a funkcionalitást okerr. Még egy ilyen ellenőrzés is értékkel bír: ha a szerver leáll, a megfelelő jelző az okerr szerveren nem frissül időben, és az idő leteltével riasztás keletkezik.
Ez az ellenőrzés értesít, hogy az apache2 szerver leállt (sosem lehet tudni...):
apache_OK="systemctl is-active --quiet apache2"
Tehát, ha bármilyen programozási nyelvet ismersz, legalább shell szkripteket tudsz írni – akkor már tudsz saját ellenőrzéseket hozzáadni.Bonyolultabb: írhatsz (bármilyen nyelven) saját modult az okerrmodhoz. A legegyszerűbb esetben így néz ki:
Nem nehéz, igaz? A modulnak végre kell hajtania az ellenőrzést, és az eredményeket STDOUT-ra kell kiadnia. A bonyolultabb modul például így néz ki:
#!/usr/bin/python3
print("STATUS: OK")$ okerrmod --dump df NAME: pi:df-\/ TAGS: df METHOD: numerical|maxlim=90 DETAILS: 49.52%, 13.9G\/28.2G használt, 13.0G szabad STATUS: 49.52NAME: pi:df-\/boot TAGS: df METHOD: numerical|maxlim=90 DETAILS: 84.32%, 53.1M\/62.9M használt, 9.9M szabad STATUS: 84.32
Ez több jelzőt frissít egyszerre (üres sorokkal elválasztva), szükség esetén létrehozza azokat, és megadja az ellenőrzés részleteit és a címkét, amellyel a műszerfalon könnyen megtalálhatóak a szükséges jelzők.Van Telegram bot
Telegram
@OkerrBot Státusz oldalak
Manapság a státusz oldalak már szinte kötelezők minden olyan üzlet számára, amelynek van IT-ja, felelősségteljes bejárás a megbízhatóság iránt és tiszteletteljes hozzáállás ügyfeleihez/felhasználóihoz.
Manapság a státuszoldalak szinte kötelezőek azok számára, akiknek van IT-juk, felelősségteljesen kezelik a megbízhatóságot, és tiszteletteljesen bánnak ügyfeleikkel/felhasználóikkal.
Képzelje el a helyzetet: a felhasználó szeretne valamit tenni, információt keresni vagy rendelést leadni, de valami nem működik. Nem tudja, hol van a probléma, kinek a hibája és mikor oldódik meg. Lehet, hogy a cégének épp nem működik a weboldala? Vagy hat hónapja elromlott, és majd két év múlva javul meg? Pedig a hűtőt már most meg kellene venni, az már a kosárban van... És egészen más, amikor az ember látja, hogy nálatok valami nincs rendben (legalábbis nyilvánvaló, hogy a probléma nem az ő oldalán van), hogy a probléma észlelve lett, hogy már dolgoztok rajta, és lehet, hogy még egy kb. időpontot is írtatok a javításra. A felhasználó feliratkozhat, és értesítést kaphat e-mailben, amikor a probléma megoldódik, és megteheti azt, amit akart (megveheti a hűtőt).
Problémák, leállások — mindenkivel megtörténnek. De a felhasználók és a partnerek jobban bíznak azokban, akik átláthatóbbak és felelősségteljesebben kezelik ezeket a helyzeteket.
Íme . Íme példák, hogyan néznek ki ezek az oldalak más projekteknél és . .
Failover
Annak érdekében, hogy ez a cikk ne legyen még hosszabb, még egyszer hivatkozok a korábbi cikkemre — . Ha tudtok létrehozni egy tartalék szervert, akkor a failover használatával alapvetően nem lesz hosszú leállás — amint a probléma észlelve lett, automatikusan a felhasználók egy működő tartalék szerverre lesznek átirányítva. És szerintem ez egy nagyon érdekes, figyelemfelkeltő funkció, ami sehol máshol nem elérhető.
Alacsony rendszerkövetelmények
Az okerr szerverekhez — 2 Gb RAM-os gépeket használunk. A hálózati érzékelőkhez — még 512 Mb is elegendő. Az ügyféloldal — szinte nulla. (A csomag 26 Kb nagyságú, de Python3-at és a standard könyvtárakat igényel). Az ügyfél egy cron scriptből indul, így nullára csökkentett folyamatos memóriafogyasztással bír. Az általunk figyelt gépek között találhatók érzékelők (szuper olcsó VPS-ek 512 Mb RAM-mal) és Raspberry Pi. Még az ügyfélarc nélkül is ! (lásd lent)
Ezeket figyelembe véve — az okerr valószínűleg a leginkább ingyenes A meglévő monitorozási rendszerek közül, hiszen ahhoz, hogy egy másik ingyenes open-source rendszert, mint például a Zabbix vagy a Nagios használjunk, erőforrásokat (szervert) kell allokálnunk, ami már pénzbe kerül. Emellett a szerver karbantartása is szükséges. Az okerr-rel ezt a részt eltávolíthatjuk. De akár meg is tarthatjuk a saját szerverünket, attól függően, hogy mi a kényelmesebb számunkra.
API és integráció a saját szoftverbe
Egyszerű és nyitott architektúra. Az okerr meglehetősen egyszerű , amellyel könnyű dolgozni. 1000 mutatót kell létrehozni? Egy 3-4 soros shell-skripttel megoldható. 1000 mutatót kell újrakonfigurálni? Az is nagyon egyszerű. Például, ha azt akarjuk ellenőrizni, hogy minden HTTPS tanúsítványunk rendben van egy orosz szenzorral:
#!/bin/sh
for indicator in `okerrclient --api-filter sslcert`
do
echo set location for $indicator
okerrclient --api-set location=ru retest=1 --name $indicator
doneA mutatót frissíthetjük akár az ügyfélmodulunkkal, akár anélkül, egyszerűen curl-en keresztül is.
# 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 saját programunkból is frissíthetjük. Például, küldve heartbeat jeleket, hogy az okerr tudja, hogy fut, és riasztást küldjön, ha leállt vagy fagyott. Egyébként az okerr komponensei pontosan így működnek — az okerr figyeli saját magát, és bármelyik modul problémáit észleli, és értesítést generál a problémáról. (A 'majdnem' esetre — másik szerverről is keresztellenőrzik őket)
Ilyen kód (egyszerűsítve) a Telegram 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))Python programokból a mutatók frissítésére — van könyvtár , más nyelvekhez — nincs könyvtár, de hívhatjuk az okerrupdate skriptet, vagy HTTP kérést küldhetünk az okerr szerverhez.
Hogyan segít nekünk az okerr
Az okerr megváltoztatta az életünket. Valójában. Lehet, hogy egy másik monitorozási rendszer is tette volna, de az okerr-rel nagyon könnyű és egyszerű dolgozni, és minden funkció benne van, amire szükségünk volt (amit nem találtunk, megírtuk). Egyébként, ha hiányzik egy funkció — kérdezd, és én hozzáadom (nem ígérem, de szeretném, ha az okerr lenne a legjobb monitorozási rendszer kis- és közepes projektekhez). Vagy még jobb, ha te magad adod hozzá — ez egyszerű.
Sikerült élnünk az „összes probléma a [okerr]”-ből elnevezésű elv szerint. Ha hirtelen felmerült egy probléma, amelyről nem a [okerr]-ből értesültünk, akkor azt automatikusan hozzáadjuk a [okerr]-hez. (Ebben az esetben a „mi” alatt a rendszer felhasználóit értem, nem a fejlesztőpartnereinket). Eleinte gyakran történt ez, de mostanra nagyon ritkává vált.
Monitorozás
A [okerr]-en keresztül nyomon követjük a naplók méretét az összes szerveren. Persze, hogy minden egyes naplósort figyelmesen elolvasni lehetetlen, de csak a növekedés sebességének figyelemmel kísérése már sokat segít. Ezen keresztül fedeztük fel a spamküldést és a jelszóbrute-force támadásokat is, és amikor egyes alkalmazások „megőrülnek”, valami elromlik, és megállás nélkül próbálkoznak (minden alkalommal pár sort hozzáadva a naplóhoz).
SSL tanúsítványok. Szinte az indulás után megrendelőnk elkezdte ingyenes SSL tanúsítványokat biztosítani az ügyfeleinek (kb. ezer darabot). És ez egyszerűen pokoli volt az adminisztráció számára! A lényeg, hogy a weboldalak „életképesek”, az ügyfelek időnként valamit kérnek tőlük, a programozók pedig megvalósítják. Szabadon áthelyezhetik például a weboldalt egy másik DocumentRoot-ra. Vagy feltétlen Rewrite-ot adhatnak a virtuális hoszt konfigurációjához. Természetesen, egy ilyen lépés után az SSL tanúsítványok automatikus frissítése megszakad. Most minden SSL hoszton automatikusan hozzáadódik a [okerr]-hez a csomagunkba tartozó újabb használható segédprogramon keresztül. . Csak elindítjuk a2okerr.py — és ha a szerveren új weboldalak jelennek meg, automatikusan megjelennek a [okerr]-ben. Ha valamiért a tanúsítvány nem frissül, három héttel a lejárata előtt — tudatában vagyunk, és megvizsgáljuk, miért nem frissül, hogy ez a kutya. a2certbot.py ugyanebből a csomagból — nagyon segít ebben (azonnal ellenőrzi a legvalószínűbb problémákat — és írja, hogy mi ellenőrizve lett, és hol van valószínűleg probléma).
Figyelemmel kísérjük az összes domainünk lejárati idejét. Az összes levelezőszerverünk, amely levelet küld — további 50+ különböző fekete listán is ellenőrzésre kerül. (És néha ezen fekete listákra kerülnek). Egyébként tudjátok, hogy a Google levelezőszerverei is fekete listákon vannak? Csak a saját tesztelésünk érdekében hozzáadtuk a mail-wr1-f54.google.com-t a figyelemmel kísérhető szerverekhez, és tényleg a SORBS fekete listáján van! (Ez a „spamellenes” szolgáltatók értékességéről szól.)
A biztonsági másolatokat könnyedén nyomon követhetjük az okerr segítségével. Figyeljük a friss biztonsági másolatokat a szerverünkön, és (egy külön segédprogram segítségével, amely az okerr-re támaszkodik) figyeljük az Amazon Glacier-re feltöltött másolatokat is. Igen, időnként előfordulnak problémák. Nem véletlenül figyelünk rájuk.
Escalációs indikátort használunk. Ez megmutatja, ha egy probléma hosszú ideig nincs megoldva. Néha én magam is elfelejtek bizonyos feladatokat, amikor dolgozom rajtuk. Az eszkaláció jó emlékeztető, még akkor is, ha magam figyelek rá.
Összességében úgy gondolom, hogy a munkánk minősége jelentősen javult. Majdnem nincs leállás (vagy a kliens nem is veszi észre. Csak sssss!), miközben a munka mennyisége csökkent és a munkakörülmények nyugodtabbá váltak. Átálltunk a kapkodó munkáról a nyugodt és tervezett munkára, ahol sok problémát előre meg lehet jósolni, és van idő azok megelőzésére. Még a már bekövetkezett problémák kijavítása is egyszerűbb lett: egyrészt hamarabb értesülünk róluk, mint hogy a kliensek pánikba esnének, másrészt gyakran fordul elő, hogy a probléma kapcsolódik egy korábbi munkához (míg az egyikkel foglalkoztam, a másikat elrontottam) – ezért könnyebb kezelni, ha frissen ránézünk.
Egy másik eset is volt...
Tudja, hogy a népszerű Debian 9 (Stretch) olyan népszerű csomagja, mint a phpmyadmin, még mindig (már hónapok óta!) vulnerábilis állapotban van? (). Amikor a sebezhetőség megjelent – gyorsan különböző módokon fedeztük fel. De beállítottam az okerr-ben a security-tracker oldalának nyomon követését, hogy tudjam, mikor jelenik meg a „szép” megoldás (SHA1 tartalomösszeg alapján). Többször is riasztott az indikátor, az oldal változott, de ahogy látja – azóta (2019 januárja óta!) még mindig nem jelezték, hogy a probléma megoldódott. Lehetséges, hogy valaki tudja, mi a probléma, hogy egy ilyen fontos csomag több mint egy éve vulnerábilis?
Második alkalommal hasonló helyzetben: az SSH sebezhetősége után frissíteni kellett az összes szervert. Amikor feladatot adsz — fontos ellenőrizni a végrehajtást. (A beosztottak hajlamosak félreérteni, elfelejteni, összezavarodni, hibázni). Ezért először az okerr-be beépítettünk egy SSH verzió ellenőrzést minden szerveren, és az okerr segítségével figyeltük, hogy az összes szerveren telepítették-e a frissítéseket. (Kényelmes! Kiválasztottam ezt a típusú kijelzőt, és azonnal látszik, hogy melyik szerveren milyen verzió van). Amikor megbizonyosodtunk arról, hogy a feladat minden szerveren végrehajtásra került — eltávolítottuk a kijelzőt.
Pár alkalommal előfordult, hogy egy probléma felmerült, majd magától megoldódott. (Valószínűleg mindenkinek ismerős?). Míg észreveszed, míg ellenőrzöd — addigra már nem is marad mit ellenőrizni — minden jól működik. De aztán újra elromlik. Ez például nálunk a termékekkel volt, amelyeket az Amazon Marketplace-re (MWS) töltöttünk fel. Egy ponton a feltöltött készlet hibás volt (nem a megfelelő mennyiségű termékek és nem a megfelelő árak). Megoldottuk. De ahhoz, hogy megértsük — fontos volt azonnal észrevenni a problémát. Sajnos, a MWS, mint minden Amazon szolgáltatás — kissé lassú, ezért mindig volt egy késés, de végül is sikerült legalább nagyjából megragadni a kapcsolatot a probléma és a kiváltó scriptjei között (ellenőrzést végeztünk, hozzákapcsoltuk az okerrhez, és azonnal ellenőriztük az riasztás megérkezésekor).
Nemrég egy érdekes eset került a látótérbe egy nagy és drága európai hosztnál, amit ügyfelünk is használ. Hirtelen eltűntek az összes szerverünk a radarokról! Először ügyfelünk „kezeivel” (gyorsabban, mint az okerra!) észrevette, hogy az általa használt webhely nem nyílik meg, és nyitott róla egy jegyet. De nem csak egy webhely, hanem az összes! (Natasa, mindent elbuktunk!). Ekkor az Okerr hosszú üzeneteket kezdett küldeni az összes jelzőről, ami neki felgyulladt. Pánik-pánik, futkosunk körbe (mit is tehetnénk?). Aztán minden helyreállt. Kiderült, hogy a szolgáltató adatközpontjában tervezett karbantartási munkák folytak (többéves intervallumba) és természetesen figyelmeztetniük kellett volna minket. De valami balul sült el, és nem figyelmeztettek. Mindegy, sok infarktus vagy kevesebb infarktus. De a teljes helyreállítás után mindent ellenőrizni kell! El sem tudom képzelni, hogyan csinálnám ezt kézzel. Az Okerr néhány perc alatt mindent letesztelt. Kiderült, hogy a szerverek többsége csak átmenetileg volt elérhetetlen, de működött. Néhány — újraindult, de helyreállt, ahogy kellett. Az összes veszteség közül — két biztonsági mentést veszítettünk, amelyeknek a cron alapján létre kellett volna jönniük és betölteniük abban az időben, amíg ez a telitalálat ment. Még csak nem is kezdtem el létrehozni őket, egyszerűen másnap megérkeztek az értesítések, hogy minden rendben van, a biztonsági mentések megjelentek. Ez a példa nagyon tetszik, mert az Okerr nagyon hasznosnak bizonyult egy olyan helyzetben, amire előre nem is gondoltunk, de éppen ez a feladat a monitoringban — szembeszállni a kiszámíthatatlannal.
Az Okerr szenzorokhoz maximálisan olcsó hosztingokat használunk (ott a minőség és megbízhatóság nem fontos, biztosítják egymást). Nos, nemrég találtunk egy nagyon élénk hosztingot, szuper olcsón, a benchmark eredmények lenyűgözőek. De… néha előfordul, hogy a virtuális gépről indított kimenő kapcsolatok egy másik (szomszédos) IP-ről történnek. Csodák. A client_ip modul nem az igazi IP-t kapja. A szervernaplók alapján is látható, hogy a frissítés is erről a szomszédos IP-ről érkezett. Jelenleg a támogatással dolgozunk a problémán. Jó, hogy ezt békés időszakban észrevettük. De gyakran előfordul, hogy a hozzáférést a fehérlistás IP-k alapján írják elő — és ha a szerver néha rövid időre így villog — nagyon sokáig tarthat megoldani ezt a problémát.
És még egy dolog — mivel a VPS hosztolásokról beszélünk — mindig olcsókat használunk (hetzner, ovh, scaleway). A benchmarkok és a stabilitás alapján is nagyon tetszik. Használunk sokkal drágább Amazon EC2-t is más projektekhez. Nos, a okerr révén van saját megalapozott véleményünk. Mindkettő összeomlik. És nem mondanám, hogy a hosszú megfigyeléseink során az olcsó hosztok, mint a hetzner, észrevehetően kevésbé stabilak voltak, mint az EC2. Tehát ha nem kötődsz más Amazon funkciókhoz — miért fizess többet? 🙂
Mi következik?
Ha eddig nem riasztottalak el túlzottan az Okerr-től — akkor próbáld ki! Közvetlenül ezen a linken keresztül be lehet lépni a (Kattints most!). De tartsd szem előtt — hogy a demó fiók mindenkinek közös, tehát ha valamit csinálsz — valaki más ugyanabban a fiókban akadályozhat téged. Vagy (jobb lenne) regisztrálj a link alapján az — minden egyszerű, SMS nélkül. Ha nem szereted a valódi email címedet használni — használhatsz egy ideigleneset, például mailinator-t (Ajánlom: ). Ezek a fiókok idővel törlésre kerülhetnek — de teszteléshez megfelelőek.
A regisztrálás után felajánlják, hogy végezz el egy tréninget (több nem túl bonyolult oktatási feladatot). Az eredeti határok nagyon alacsonyak, de a tréninghez vagy egy szerverhez elegendőek. A tréning elvégzése után — a korlátok (például a maximális indikátorok számának) emelkedni fognak.
A dokumentációból — elsődlegesen a szerveroldalra és az ügyfélre (). De ha valami nem világos — írj a support (at) okerr.com címre vagy hagyj egy jegyet — igyekszünk gyorsan megoldani mindent.
Ha komolyan használod és ezek a megnövelt korlátok nem elegendőek — szintén írd meg a supportnak, ingyenesem növelni fogjuk.
Szeretnél okerr szervert telepíteni a saját szerveredre? Itt van a . Azt javasoljuk, hogy tiszta virtuális gépre telepítsd, akkor egyszerűen megteheted telepítő szkripttel. A saját virtuális gépeden — nincsenek korlátozások :-). És ismét — ha van valami — mindig igyekszünk segíteni.
Azt szeretnénk, hogy ez a projekt sikeres legyen, hogy a világ biztonságosabbá váljon a mi általunk. A ingyenes szoftverek és szolgáltatások révén a világ barátságosabb lett és dinamikusabban fejlődik. A forrásokat ingyenes github-on lehet tárolni, az e-mailekhez ingyenes gmail-t használhatunk. Ingyenesen használunk támogatásra. Nincs szükség szerverekre, nem kell letölteni és beállítani, és nem kell különböző üzemeltetési problémákat megoldani. Minden új projekt, minden csapat — azonnal rendelkezik e-maillel, adattárakkal és CRM-mel. Mindez nagyon magas minőségű, ingyenes és azonnal. Azt szeretnénk, hogy a monitorozás is így működjön — a kis vállalkozások és projektek ingyenesen használhassák az okerr-t, és még a születés és növekedés fázisában is megbízhatóságot nyújtsanak, mint a felnőtt komoly projektek.
Forrás: habr.com
