Pred dvoma rokmi som už napísal príspevok o . Teraz je tu určitý pokrok projektu a navyše som publikoval blokácii , preto som sa rozhodol napísať na habr tento malý prehľad.
[ ]
Koho to môže zaujímať
Môže vás to zaujímať, ak pracujete v malom tíme alebo dokonca sám. Nemáte monitorovanie a nie ste si istí, či je potrebné. Alebo ste sa pokúsili o nejaké populárne seriózne monitorovanie "pre veľkých chlapcov", ale vám to akosi "nefungovalo", alebo to funguje takmer v predvolenej konfigurácii a príliš nezmenilo váš život. A tiež – ak naozaj neplánujete vyčleniť celého zamestnanca (až celý tím) len na to, aby aspoň pár hodín denne monitoroval na dashboarde monitorovania alebo ho nastavoval.
Čím je okerr nezvyčajný
Ďalej ukážem zaujímavé vlastnosti okerr, ktoré ho odlišujú od niektorých iných monitorovacích nástrojov.
Okerr je hybridné monitorovanie
Pri vnútornom monitorovaní sa na sledovaných strojoch spúšťa „agent“, ktorý prenáša dáta na server monitorovania (napríklad voľné miesto na diskoch). Pri externom monitorovaní server cez sieť vykonáva kontroly (napríklad ping alebo dostupnosť webovej stránky). Každý prístup má svoje obmedzenia. Okerr využíva obidva varianty. Kontroly v rámci serverov sa vykonávajú veľmi ľahkým (30Kb) agentom alebo vašimi vlastnými skriptmi a aplikáciami, a sieťové kontroly cez senzory okerr v rôznych krajinách.
okerr nie je len softvér, ale aj služba
Serverová časť akéhokoľvek monitorovania je rozsiahla a zložitá, ťažko sa inštaluje a nastavuje, vyžaduje to zdroje. S okerr si môžete nainštalovať svoj vlastný server monitorovania (je bezplatný a opensource), alebo môžete jednoducho použiť iba klientskú časť a využívať službu nášho servera. Taktiež bezplatne.
Ak monitoring dokáže kompenzovať nedostatok spoľahlivosti serverov a aplikácií, vyvstáva filozofická otázka - kto stráži strážcu? Ako nám monitoring oznámi problém, ak sám „zhynul“ z nejakého dôvodu, oddelene alebo spolu s inými vašimi zdrojmi (napríklad, ak zlyhá kanál do dátového centra)? Pri použití externého servisu okerr - tento problém sa rieši - dostanete alert aj v prípade, že celé dátové centrum s vašimi servermi bude bez napájania alebo podrobené zombie útoku.
Samozrejme, existuje riziko, že server okerr bude samo nedostupný, to je pravda (ako je známe, 90% spoľahlivosti sa dosiahne vždy jednoducho a „bezplatne“, 99% - s minimom úsilia, a každé ďalšie číslo deväť je exponenciálne ťažšie). Ale po prvé, šance na to sú nižšie, a po druhé, problém môže zostať bez povšimnutia len v prípade, že sa zhoduje časovo s problémami na našich serveroch. Ak máme spoľahlivosť 99.9% a vy 99.9% (nie sú to veľmi vysoké čísla), tak šanca, že zlyhanie zostane bez povšimnutia je 0.1% z 0.1% = 0.0001%. Pridať si tri deviatky v spoľahlivosti takmer bez námahy a nákladov - to je veľmi dobre!
Ďalšou výhodou monitoringu ako služby je, že hostingový poskytovateľ alebo webová agentúra môže nainštalovať server okerr a poskytnúť prístup klientom ako platenú alebo bezplatnú doplnkovú službu. Vaši konkurenti ponúkajú len hosting a weby - a vy ponúkate spoľahlivý hosting s monitoringom.
Okerr - to sú indikátory
Indikátor je „lampička“. Má dva hlavné stavy - zelený (OK) alebo červený (ERR). V projekte je množstvo zoskupených (napríklad podľa serverov) indikátorov. Na hlavnej stránke projektu okamžite vidíte, či je všetko zelené (a môžete uzavrieť), alebo niečo svieti na červeno a je potrebné to opraviť. Pri prechode medzi týmito stavmi sa posiela upozornenie. Raz za deň, keď to nastavíte, sa posiela súhrn projektu.
Každý indikátor okerr má vstavané podmienky, podľa ktorých mení stav (v Zabbix sa to nazýva trigger). Napríklad, load average by mal byť nie viac ako 2 (samozrejme, toto je nastaviteľné). A pre každé vnútorné overenie (load average, disk free, …) existuje watchdog. Ak z nejakých dôvodov nedostaneme úspešné potvrdenie v stanovenom čase - registruje sa chyba a posiela sa alert.
Naša bežná prevádzková schéma je ranná kontrola e-mailov, kde medzi inými správami kontrolujeme súhrn (jeho čas plánujeme na začiatok práce). Ak je všetko v poriadku, zaoberáme sa inými dôležitými záležitosťami (ale pre istotu sa rýchlo pozrieme do dashboardu okerr, aby sme sa uistili, že je všetko zelené aj v tejto chvíli). Ak príde alert — reagujeme.
Samozrejme, je možné jednoducho mať "informačné" indikátory (aby ste videli prehľad siete z monitorovania), ale všetko je navrhnuté tak, aby bolo jednoduché, ľahké a rýchle vytvárať indikátory pre automatické sledovanie a zasielanie alertov.
Zmysel, pre ktorý nastavujete okerr — spočíva v alertoch, v tom, aby ste mohli za minútu vytvoriť indikátor, ktorý mohol roky "spi", len prijímal aktualizácie, a keď sa pred rokom niečo pokazilo — rozsvietil sa a poslal alert. Minúta, ktorú ste raz strávili vytvorením indikátora, sa vám vrátila, zistili ste o probléme okamžite, skôr ako ktokoľvek iný. Možno ste to dokonca opravili predtým, ako si to vôbec niekto všimol. Rýchlo vybudované sa nezapočítava za spadnuté!
Bezpečnosť
Bolo by to smutné, ak by ste nastavovali monitorovanie kvôli zvýšeniu spoľahlivosti, a nakoniec — cez neho by vás napadli online, a sieťové zraniteľnosti rôznych monitorovacích nástrojov sú dosť početné (, ).
Agent (okerrmod z balíka ), ktorý pracuje na systéme — nie je to sieťový server, ale klient. Preto na pozorovanom serveri nie sú žiadne ďalšie otvorené porty, klient ľahko funguje za firewallom alebo NAT-om a je veľmi ťažké (povedal by som "nemožné") ho hacknúť cez sieť, pretože v podstate nenavádza sieťový socket.
Úplné pokrytie monitorovania
Teraz máme pravidlo — dozvedáme sa o všetkých technických problémoch z okerr. Ak sa náhodou pravidlo poruší (okerr nás neinformoval o jeho blízkej nastávajúcej existencii (ak je to možné) alebo o tom, že už nastala) — pridáme kontroly do okerr.
Externé kontroly
Celkom typický súbor:
- ping
- http status
- kontrola platnosti a aktuality SSL certifikátu (upozorní, ak čoskoro vyprší)
- otvorený TCP port a banner na ňom
- http grep (na stránke [nemal] by sa nachádzať určitý text)
- sha1 hash na zachytenie zmien na stránke.
- DNS (DNS záznam by mal mať určité hodnoty)
- WHOIS (upozorní, ak doména čoskoro vyprší)
- Antispam DNSBL (verifikácia hostiteľa okamžite vo viac než 50 antispamových čiernych listinách)
Interné kontroly
Tiež celkom typická sada (ale ľahko rozšíriteľná).
- df (voľné miesto na diskoch)
- priemerná záťaž
- opentcp (otvorené počúvajúce TCP sokety – upozorní, ak sa niečo spustilo alebo spadlo)
- uptime — jednoducho uptime servera. Upozorní, ak sa zníži (t.j. server sa reštartoval)
- client_ip
- dirsize — používame ho na sledovanie, keď našich rootfs virtuálok prekročí povolenú veľkosť bez zavádzania prísnych obmedzení, a na sledovanie veľkostí domácich adresárov používateľov.
- empty a nonempty — sledujú súbory, ktoré by mali byť prázdne (alebo nie prázdne). Napríklad, error log samotného servera okerr — by mal byť prázdny, a ak sa v ňom objaví aspoň riadok — dostanem upozornenie a skontrolujem. Na druhej strane, mail.log na poštovom serveri by mal byť NEprázdny (po N minútach po rotácii). A niekedy bol prázdny po aktualizácii systému, keď logrotate nemohol správne reštartovať rsyslog.
- linecount — počet riadkov v súbore (ako wc -l). Používame ho ako miernejšiu náhradu za empty, keď error log môže rásť, ale len pomaly (napríklad, guglobot sa útočí na niektoré uzavreté stránky). Existuje limit na 2 riadky za 20 minút. Ak to bude viac — dostanete alert.
Zaujímavé interné kontroly
Ak ste do tohto momentu čítali „diagonálne“, teraz bude zaujímavejšie prečítať si to dôkladnejšie.
zálohy
Sleduje zálohy v adresári. Naše súbory záloh majú mená ako „ServerName-20200530.tar.gz“. Pre každý server sa v okerr vytvára indikátor ServerName-DATE.tar.gz (faktický dátum sa nahradí riadkom „DATE“). Sleduje sa aj prítomnosť čerstvej zálohy a jej veľkosť (napríklad, nemôže byť menšia ako 90% predchádzajúcej zálohy).
Čo treba urobiť, aby sa nová záloha začala sledovať, po jej vytvorení a umiestnení do tohto adresára? Nič! Je to veľmi pohodlný prístup, keď treba „nič“, pretože:
- Robiť „nič“ — je dosť rýchle, šetrí čas.
- Je ťažké zabudnúť robiť „nič“.
- Je ťažké robiť „nič“ nesprávne, s chybou. Nič — to je najspoľahlivejšia metóda.
Ak sa náhodou prestanú objavovať nové súbory zálohy — dôjde k alertu. Ak ste, napríklad, vypnuli jeden zo serverov a jeho zálohy by už nemali existovať — budete musieť odstrániť indikátor (cez webové rozhranie alebo z terminálu cez API).
maxfilesz
Sleduje veľkosť najväčších súborov (zvyčajne: /var/log/*). To umožňuje odhaľovať nepredvídateľné problémy, ako je napríklad preberanie hesiel alebo rozosielanie spamu cez server.
runstatus/runline
Toto sú dva dôležité proxy moduly, ktoré spúšťajú iné programy na serveri. Runstatus informuje o výstupe programu. Napríklad modul okerr nevyžaduje kontrolu, že služby systemd fungujú. To sa robí cez runstatus (pozri nižšie). Runline informuje server o riadku, ktorý program vyprodukoval. Napríklad, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" v konfigu Runline na našom serveri vytvára indikátor servername:temp s teplotou procesora.
sql
Vykonáva číselný dotaz na MySQL a hlási výsledok do indikátora. V jednoduchom prípade je možné napríklad zadať 'SELECT 1' — to overí, že správa databázy je celkovo funkčná.
Zaujímavejšie použitie je napríklad sledovanie počtu objednávok v internetovom obchode. Ak viete, že za hodinu máte od 100 objednávok, môžete nastaviť minimálny prah na 100 alebo 80. Potom, ak náhle klesnú vaše predaje — dostanete upozornenie a môžete to riešiť.
Všimnite si — nie je dôležité, z akého nepredvídateľného dôvodu sa to stalo:
- Server je jednoducho nedostupný (bez napájania alebo bez siete), a upozornenie prišlo, pretože indikátor 'vyprchol'.
- Server je niečím zaťažený, pomaly funguje alebo stráca pakety, používateľom to nevyhovuje a odchádzajú bez nákupov.
- Server sa dostal na spamové zoznamy a pošta od neho nie je prijímaná, používatelia sa nemôžu registrovať.
- Skončil rozpočet reklamnej kampane, bannery sa nezobrazujú.
Príčin môže byť neúrekom a všetky ich vopred nepredpokladáte, a technicky je ťažké to sledovať. Ale je možné jednoducho sledovať konečný parameter (objednávky) a podľa nich určiť, že situácia je podozrivá a zaslúži si ju preskúmať.
Logické indikátory
Umožňuje používať logické výrazy (syntax Python) prostredníctvom modulu (). Pre výrazy sú dostupné dáta projektu a jeho indikátorov. Napríklad v kapitole o SQL kontrole vyššie ste si možno všimli slabé miesto — cez deň môže byť od 100 predajov za hodinu, ale v noci to môže byť 20, a to je bežné, nie problém. Ako to riešiť? Indikátor bude predsa neustále panikáriť v noci.
Môžete vytvoriť dve indikácie, dennú a nočnú. Obe nastaviť ako „tiché“ (nebudú posielať upozornenia). A vytvoriť logickú indikáciu, ktorá vyžaduje do 20:00, aby bola denná indikácia OK, a po 20:00 stačí, aby bola nočná indikácia OK.
Ďalší príklad použitia logickej indikácie — to je eskalácia. Napríklad, projektový manažér sa odhlasuje od alertov (to nepotrebuje, administrátori by mali reagovať na bežné problémy), ale prihlasuje sa na logickú indikáciu, ktorá sčervená, ak akákoľvek indikácia v projekte nie je opravená v stanovenom čase.
Ešte — je tu možnosť určiť povolený čas na prácu, napríklad od 3 do 5 rána. Nezaujíma nás, ak servery a stránky v tom čase „padnú“. Ale o 5:00 musia fungovať. Ak nepracujú v inom čase — alert. Logická indikácia tiež umožňuje brať do úvahy rezervu serverov. Ak máte 5 webových serverov, tak administrátori môžu vypnúť 1-2 servery kedykoľvek. Ale ak v prevádzke bude menej ako 3 zo 5 serverov — bude alert.
Príklady vyššie — nie sú to funkcie okerr, nie sú to žiadne funkcie, ktoré treba aktivovať a nastaviť. Tieto funkcie v okerr chýbajú, ale je tu logický modul, ktorý umožňuje implementovať aj túto funkcionalitu (príklad, ako v programovacom jazyku — ak máme aritmetické operátory, nemusíme od jazyka vyžadovať špeciálnu funkciu na výpočet 20% DPH, tú si vždy môžeme spraviť sami podľa svojich potrieb).
Logická indikácia je pravdepodobne jedným z mála relatívne zložitých tém v okerr, ale dobrá správa je, že nie je potrebné ich ovládať, kým sa neobjaví potreba. Ale zároveň veľmi rozširujú možnosti, pričom samotný systém zostáva dosť jednoduchý.
Pridanie vlastných overení
Veľmi by som chcel zdôrazniť, že okerr nie je súbor z tisíc hotových overení na každý prípad, ale naopak — predovšetkým — jednoduchý motor s jednoduchou možnosťou vytvoriť si vlastné overenia. Vytváranie vlastných overení v okerr nie je úloha pre hackerov, spoluautorov systému alebo aspoň pokročilých používateľov okerr, ale zvládnuteľná úloha pre každého administrátora, ktorý pred mesiacom prvýkrát nainštaloval linux.
Overenia na minimálkach sa vykonávajú cez modul :
Tento riadok v konfigurácii upozorní, ak náhodou /bin/true neštartuje alebo nevráti 0.
true_OK=\/bin\/trueLen jeden riadok — a už sme trochu rozšírili funkcionalitu okerr.
Aj takáto kontrola má svoju hodnotu: ak by váš server zlyhal — relevantný indikátor na serveri okerr sa neaktualizuje načas a po uplynutí času sa objaví alert.
Táto kontrola vás upozorní, že server apache2 spadol (veď nikdy neviete…):
apache_OK="systemctl is-active --quiet apache2"Takže, ak ovládate akýkoľvek programovací jazyk, aspoň viete písať shell skripty — už môžete pridávať vlastné kontroly.
Složitejšie — môžete napísať (v akomkoľvek jazyku) svoj modul pre okerrmod. V najjednoduchšom prípade vyzerá takto:
#!/usr/bin/python3
print("STATUS: OK")Naozaj nie je to veľmi zložité? Modul by mal uskutočniť samotnú kontrolu a zobraziť výsledky na STDOUT. Zložitejší modul napríklad dáva takéto:
$ 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.32Udržiava viacero indikátorov (oddelené prázdnym riadkom), ak je to potrebné, vytvorí ich, uvedie podrobnosti kontroly a tag, podľa ktorého sa na dashboarde ľahko nájdu požadované indikátory.
Telegram
Existuje Telegram bot . Nemusíte si zbytočne zaplňovať telefon samostatnými aplikáciami (ani ja nemám rád, keď pre Pjaterechku potrebujem jednu aplikáciu s kartou, pre Lentu inú, pre MTS tretiu a tak ďalej). Jeden Telegram — stačí. Cez telegram môžete okamžite dostávať alerty a kontrolovať stav projektu a dať príkaz na opätovnú kontrolu všetkých problémových indikátorov. Vyšli ste z divadla/lietadla, dve hodiny ste nemali ruku na pulze, zapli ste tel, stlačili ste jedno tlačidlo v chatbote a uistili sa, že je všetko v poriadku.
Stránky statusu
V dnešnej dobe sú stránky statusu už takmer must have pre akýkoľvek biznis, ktorý má IT, zodpovedný prístup k spoľahlivosti a ktorý s úctou pristupuje k svojim klientom/používateľom.
Predstavte si situáciu – používateľ chce niečo urobiť, pozrieť si informácie alebo zadať objednávku a niečo nefunguje. Nevie, v čom je problém, na čej strane sa nachádza a kedy sa to vyrieši. Možno má vaša firma jednoducho nefunkčnú stránku? Alebo sa pokazila pred polrokom a oprava bude za dva roky? Chladničku treba kúpiť už teraz, je už v košíku... A úplne iná situácia je, keď človek vidí, že u vás sa niečo deje (aspoň je jasné, že problém nie je na jeho strane), že problém bol zistený, že na ňom už pracujete a možno ste dokonca uviedli približný čas opravy. Používateľ sa môže prihlásiť a dostávať na e-mail oznámenie, keď bude problém vyriešený a bude sa dať urobiť to, čo chcel (kúpiť chladničku).
Problémy, downtime – to sa stáva každému. Ale používatelia a partneri viac dôveryujú tým, ktorí sú priehľadnejší a zodpovednejšie k tomu pristupujú.
Tu sú . Tu sú príklady, ako vyzerajú tieto stránky u projektov a . .
Failover
Aby som túto časť článku ešte viac nezväčšoval, opäť odkazujem na svoj predchádzajúci článok — . Ak môžete vytvoriť duplikujúci server, potom s použitím failoveru, v zásade nebudete mať dlhý downtime – hneď ako bude problém zistený, používatelia sa automaticky presmerujú na funkčný záložný server. A myslím, že to je veľmi zaujímavá, pútavá funkcia, ktorá sa len málo kde vyskytuje.
Nízke systémové požiadavky
Pre servery okerr – používame stroje s RAM od 2 Gb. Pre sieťové senzory dokonca 512 Mb stačí. Klientska časť má takmer nulovú spotrebu. (Balík váži 26 Kb, ale vyžaduje Python3 a štandardné knižnice). Klient sa spúšťa z cron skriptu, takže má nulovú stálu spotrebu pamäte. Medzi pozorovanými strojmi máme senzory (super lacné VPS s 512 Mb RAM) a Raspberry Pi. Môžete dokonca bez klientskej časti ! (pozri nižšie)
Vzhľadom na to – okerr, pravdepodobne, najviac bezplatná monitorovací systém z existujících, pretože aj na to, aby ste mohli používať iný bezplatný open-source systém ako Zabbix alebo Nagios, musíte mu prerozdeliť zdroje (server), a to sú už peniaze. Okrem toho — vyžaduje to aj určitú údržbu servera. S okerr — túto časť môžete odstrániť. Môžete ju aj neodstrániť a používať vlastný server — záleží na tom, čo vám viac vyhovuje.
API a integrácia do vlastného softvéru
Jednoduchá a otvorená architektúra. Okerr má pomerne jednoduchý , s ktorým sa ľahko pracuje. Potrebujete vytvoriť 1000 indikátorov? Jeden shell skript v 3-4 riadkoch to dokáže. Potrebujete prestaviť 1000 indikátorov? Taktiež veľmi jednoducho. Napríklad, chceme prekontrolovať všetky naše HTTPS certifikáty práve z ruského senzora:
#!/bin/sh
for indicator in `okerrclient --api-filter sslcert`
do
echo set location for $indicator
okerrclient --api-set location=ru retest=1 --name $indicator
doneIndikátor môžete aktualizovať buď pomocou nášho klientského modulu, alebo dokonca bez neho, jednoducho cez curl.
# short and nice (using okerrupdate and config file)
$ okerrupdate MyIndicator OK
# only curl is enough!
$ curl -d 'textid=MyProject&name=MyIndicator&secret=MySecret&status=OK' https://bravo.okerr.com/Môžete aktualizovať indikátory priamo zo svojho programu. Napríklad, posielaním heartbeat signálov, aby okerr vedel, že je spustený, a spustil alarm, ak klesol alebo zamrzol. Mimochodom, komponenty okerr to robia — okerr sa o seba stará, a problémy v takmer akémkoľvek module budú odhalené a vygenerujú upozornenie na problém. (A pre prípad tohto „takmer“ — sú vzájomne overované z iného servera)
Takýto kód (zjednodušene) v našom telegramovom bote:
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))Pre aktualizáciu indikátorov z Python programov — existuje knižnica , pre akékoľvek iné jazyky — knižnice nie sú, ale môžete buď zavolať skript okerrupdate, alebo vykonať HTTP požiadavku na server okerr.
Ako nám pomáha okerr
Okerr zmenil náš život. Naozaj. Možno by iný monitorovací systém tiež mohol, ale s okerr sa nám pracuje jednoducho a ľahko a sú v ňom všetky funkcie, ktoré sme potrebovali (to, čo chýbalo — sme doplnili). Mimochodom, ak nejaká funkcia chýba — opýtajte sa, a ja ju pridám (nesľubujem, ale chcem, aby okerr bol najlepším monitorovacím systémom pre malé a stredné projekty). Alebo, ešte lepšie, pridajte ich sami — je to jednoduché.
Podarilo sa nám žiť podľa princípu „o všetkých problémoch sa dozvedieť prostredníctvom okerr“. Ak sa náhodou stala problém, o ktorom sme sa nedozvedeli od okerr — pridávame kontrolu do okerr. (v tomto prípade „my“ rozumiem ako používateľov systému, nie ako spolu vývojárov). Na začiatku to bolo často, ale teraz je to veľmi zriedkavé.
Monitorovanie
Cez okerr sledujeme veľkosti logov na všetkých serveroch. Starostlivo čítať každú jednu líniu logu očami — samozrejme, nemožno, ale jednoducho sledovanie rýchlosti rastu — už veľa pomáha. Takto sme objavili aj rozosielanie spamu a brutálny preberanie hesiel, a keď niektoré aplikácie „vešajú“, niečo im nefunguje a opakujú stále dokola (každý raz pridávajú pár riadkov do logu).
SSL certifikáty. Takmer hneď po spustení náš zákazník začal poskytovať svojim klientom bezplatné SSL certifikáty (približne tisíc z nich). A to sa ukázalo ako hotové peklo na správu! Vec je v tom, že weby sú „živé“, klienti občas niečo žiadajú, programátori to robia. Môžu úplne voľne presunúť stránku do iného DocumentRoot napríklad. Alebo pridať bezpodmienečný Rewrite do konfigurácie virtuálneho hostiteľa. Samozrejme, po takomto sa automatické obnovovanie certifikátov pokazí. Teraz sa všetky naše SSL hosty automaticky pridávajú do okerr cez ďalší náš užitočný nástroj z balíka . Jednoducho spustíme a2okerr.py — a ak sa na serveri objaví niekoľko nových webov — automaticky sa objavia v okerr. Ak sa náhodou z nejakého dôvodu certifikát neobnovuje, tri týždne pred vypršaním certifikátu — sme informovaní a zisťujeme, prečo sa neobnovuje, pes taký. a2certbot.py z rovnakého balíka — veľmi pomáha v tomto (hneď skontroluje najpravdepodobnejšie problémy — a píše, čo bolo dobre skontrolované, a kde pravdepodobne je problém).
Sledujeme dobu expirácie všetkých našich domén. A všetky naše poštové servery, ktoré posielajú poštu — sa ešte kontrolujú podľa 50+ rôznych čiernych zoznamov. (A niekedy sa tam dostanú). Mimochodom, vedeli ste, že poštové servery google sú tiež na čiernych zoznamoch? Iba pre samotestovanie sme pridali mail-wr1-f54.google.com k sledovaným serverom, a fakt je v čiernom zozname SORBS! (To k otázke hodnoty „antispamerov“)
Zálohy – už som vyššie spomenul, ako jednoducho ich sledovať pomocou okerr. Sledovali sme čerstvé zálohy na našom serveri a (s použitím samostatného nástroja, ktorý využíva okerr) – aj zálohy, ktoré nahrávame na Amazon Glacier. Áno, občas sa vyskytujú problémy. Nezabúdajte na to.
Používame indikátor eskalácie. Podľa neho je jasné, ak sa nejaký problém dlho neopravil. Aj ja, keď riešim určité úlohy, ich občas môžem zabudnúť. Eskalácia je dobré pripomenutie, aj keď sledujete sami seba.
V celku si myslím, že kvalita našej práce sa výrazne zlepšila. Výpadky takmer neexistujú (alebo ich klienti nestihnú zaznamenať. Len ššš!), pričom objem práce sa znížil a podmienky práce sú pokojnejšie. Prešli sme od hektického trápenia sa s opravami k pokojnej a vyváženej práci, kde sa mnohé problémy predvídajú vopred a máme čas ich predchádzať. Aj so skutočnými problémami sa teraz ľahšie vysporiadame: po prvé, dozvieme sa o nich skôr, ako klienti panikária, a po druhé, často sa stáva, že problém súvisí s nedávnou prácou (keď som robil jedno, pokazil som iné) – preto je jednoduchšie to vyriešiť hneď.
A toto bol ďalší prípad…
Viete, že v populárnom Debian 9 (Stretch) tak populárny balík ako phpmyadmin je stále (už mnoho mesiacov!) v stave zraniteľnosti? (). Keď sa zraniteľnosť objavila, rýchlo sme ju na mnohých miestach zabezpečili. Ale nastavil som v okerr sledovanie stránky security-tracker-a, aby som vedel, kedy sa objaví "krásne" riešenie (cez SHA1 kontrolný súčet obsahu). Niekoľkokrát ma indikátor upozornil, stránka sa menila, ale, ako vidíte, doteraz (od januára 2019!) sa tam neuvádza, že problém bol vyriešený. Možno niekto vie, čo tam za problém je, že tak dôležitý balík je už viac ako rok zraniteľný?
In a similar situation again: after a vulnerability in SSH, it was necessary to update all servers. When you set a task, you need to monitor its execution. (Subordinates tend to misunderstand, forget, get confused, and make mistakes). Therefore, first, we added a check for the SSH version on all servers in okerr, and through okerr, we monitored that the updates were applied to all servers. (Convenient! I selected this type of indicator, and immediately see which version is on which server). Once we confirmed that the task was completed on all servers, we removed the indicators.
A couple of times there was a situation where a certain problem occurred, and then it resolved itself. (Probably familiar to everyone?). By the time you notice it and check — there's nothing left to verify — everything is already working well. But then it breaks again. We experienced this, for instance, with the products we uploaded to Amazon Marketplace (MWS). At some point, the uploaded inventory was incorrect (the quantities and prices were wrong). We figured it out. But to sort this out, it was crucial to be informed of the issue immediately. Unfortunately, MWS, like all Amazon services, is a bit slow, so there was always a lag, but still — we managed to roughly catch the link between the problem and the scripts that cause it (we created a check, attached it to okerr, and monitored it as soon as the alert was received).
Nedávno sme mali zaujímavý prípad s veľkým a drahým európskym hostiteľom, ktorý využíva náš zákazník. Zrazu sa na radaroch stratili VŠETKY naše servery! Najprv si zákazník sám „rukami“ (rýchlejšie ako Okerr!) všimol, že stránka, s ktorou pracoval, sa neotvára a vytvoril tiket kvôli tomu. Ale nešlo o jeden web, ale o všetky! (Natasha, všetko sme posrali!). A tu začal Okerr posielať dlhé správy so všetkými indikátormi, ktoré sa aktivovali. Panika, panika, beháme krúžky (čo iné robiť?). Potom sa všetko obnovilo. Ukázalo sa, že v dátovom centre sa vykonávali plánované práce (raz za niekoľko rokov) a mali nás samozrejme upozorniť. Ale niečo im nevyšlo a neupozornili nás. Nuž, infarkt viac, infarkt menej. Ale po obnovení všetkého — treba všetko prekontrolovať! Neviem si predstaviť, ako by som to robil ručne. Okerr otestoval všetko za niekoľko minút. Ukázalo sa, že väčšina serverov bola len dočasne nedostupná, ale fungovala. Niektoré sa reštartovali, ale tiež sa vrátili do normálu. Z našich strát sme stratili dve zálohy, ktoré mali podľa plánu vzniknúť a nahrať sa v čase, keď sa to všetko dialo. Ani som ich nezačal vytvárať, jednoducho po dni prišli alerty, že všetko je v poriadku, zálohy sa objavili. Tento prípad sa mi veľmi páči, pretože Okerr bol veľmi užitočný v situácii, ktorú sme ani neplánovali vopred, ale to je úloha monitorovania — čeliť nepredvídateľnému.
Pre senzory Okerr používame maximálne lacné hostingy (kde kvalita a spoľahlivosť nie sú dôležité, navzájom sa poistení). Takže sme nedávno našli veľmi živý hosting a super lacno, benchmarky sú skvelé. Ale… niekedy sa ukáže, že odchádzajúce spojenia z virtuálky sa realizujú z inej (susednej) IP adresy. Zázraky. Modul client_ip s nedostáva tú správnu IP. A podľa serverových logov indikátora je vidno, že aj aktualizácia prišla z tejto susednej IP. Momentálne to riešime so supportom. Našťastie sme si to všimli v kľudnom čase. Ale, napríklad, často sa stáva, že prístup sa zapisuje podľa bieleho zoznamu IP — a ak server občas na krátky čas takto blikne — môže to trvať dlho, kým sa túto problém zachytí.
A ešte — keď sme sa už bavili o VPS hostingu — vždy používame cenovo dostupné (hetzner, ovh, scaleway). A podľa benchmarkov a stability — veľmi sa páčia. Používame aj oveľa drahší Amazon EC2 na iné projekty. Takže, vďaka okerr máme svoje zdôvodnené názory. Zlyhávajú — aj jedni, aj druhí. A povedal by som, že za dlhú dobu našich pozorovaní lacné hostiny ako hetzner nepreukázali byť podstatne menej stabilné než EC2. Preto, ak nie ste naviazaní na iné funkcie Amazonu — prečo platiť viac? 🙂
Čo ďalej?
Ak som vás na tomto bode ešte príliš neodradil od Okerr’a — vyskúšajte! Práve cez tento odkaz sa môžete prihlásiť do (Kliknite hneď teraz!). Ale pamätajte — že demou účet je jeden pre všetkých, takže, ak niečo robíte — niekto iný v tom istom účte vám môže v tom istom čase prekážať. Alebo (lepšie) sa zaregistrujte cez odkaz na — všetko jednoducho, bez SMS. Ak nemáte radi používanie svojho skutočného e-mailu — môžete použiť jednorazový ako mailinator (Odporúčam ). Takéto účty môžu byť časom odstránené — ale na testovanie to bude stačiť.
Po registrácii budete vyzvaní na absolvovanie školenia (splnenie niekoľkých nie veľmi náročných učebných úloh). Počiatočné limity sú veľmi malé, ale na školenie alebo jeden server sú dostatočné. Po absolvovaní školenia — limity (napríklad maximálny počet indikátorov) sa zvýšia.
Z dokumentácie — predovšetkým na serverovú časť a na klienta (). Ale ak niečo nie je jasné — píšte na support (at) okerr.com alebo zanechajte tiket — pokúsime sa všetko rýchlo vyriešiť.
Ak plánujete používať vážne a tieto zvýšené limity budú nedostačujúce — takisto, napíšte do podpory, zvýšime ich (zadarmo).
Chcete si nainštalovať server okerr na svojom serveri? Tu je . Odporúčame inštalovať na čistú virtuálnu mašinu, potom sa to dá jednoducho urobiť inštalačným skriptom. Na svojej virtuálke — žiadne obmedzenia :-). A opäť — ak niečo — vždy sa budeme snažiť pomôcť.
Chceme, aby tento projekt vzlietol, aby sa svet stal bezpečnejším vďaka nám. Vďaka bezplatnému softvéru a službám sa svet stal priateľskejším a vyvíja sa dynamickejšie. Zdroje môžeme uchovávať na bezplatnom github'e, na e-mail môžeme používať bezplatný gmail. Používame bezplatný pre podporu. Na nič z toho nie je potrebné platiť servery, nie je potrebné sťahovať a nastavovať a riešiť rôzne problémy s prevádzkou. Každý nový projekt, každý tím — hneď má e-mail, repozitáre a CRM. A to všetko je veľmi kvalitné, bezplatné a okamžité. Chceme, aby aj pre monitoring to bolo tak — malé firmy a projekty by mohli bezplatne používať okerr a dokonca v etape vzniku a rastu mať spoľahlivosť ako pri dospelých, serióznych projektoch.
Zdroj: habr.com
