Před dvěma lety jsem již napsal příspěvek Jednoduché převzetí služeb při selhání pro web про okerr. Nyní probíhá určitý vývoj projektu a také jsem publikoval zdrojový kód na straně serveru okerr pod otevřená licence, proto jsem se rozhodl napsat tuto krátkou recenzi na Habr.

[ v plné velikosti ]

Koho to může zajímat

To by vás mohlo zajímat, pokud pracujete v malém týmu nebo sami. Nemáte monitoring a nejste si jisti, zda jej opravdu potřebujete. Buď jste zkusili nějaký oblíbený seriózní monitoring „pro velké kluky“, ale nějak se vám „nevznesl“, nebo funguje v téměř výchozí konfiguraci a život vám příliš nezměnil. A také - pokud rozhodně neplánujete vyčlenit celého zaměstnance (nebo dokonce oddělení), aby monitorovací dashboard alespoň pár hodin denně sledoval nebo jej konfiguroval.

Proč je okerr neobvyklý

Dále ukážu zajímavé vlastnosti okerry, které ji odlišují od některých jiných monitorovacích systémů.

Okerr je hybridní monitoring

Během interního monitorování běží na monitorovaných strojích „agent“, který přenáší data na monitorovací server (například volné místo na disku). Když je externí, server provádí kontroly přes síť (například ping nebo dostupnost webu). Každý přístup má svá omezení. Okerr využívá obě možnosti. Kontroly uvnitř serverů jsou prováděny velmi lehkým (30 kB) agentem nebo vašimi vlastními skripty a aplikacemi a kontroly sítě se provádějí prostřednictvím okerr senzorů v různých zemích.

okerr není jen software, ale také služba

Serverová část jakéhokoli monitorování je velká a složitá, je obtížné ji instalovat a konfigurovat a vyžaduje zdroje. S okerr si můžete nainstalovat svůj vlastní monitorovací server (je zdarma a opensource), nebo můžete jednoduše používat pouze klientskou část a využívat služby našeho serveru. Také zdarma.

Pokud vám monitorování umožňuje kompenzovat a zakrývat nedostatečnou spolehlivost serverů a aplikací, pak vyvstává filozofická otázka – kdo je strážcem? Jak nám monitorování řekne o problému, pokud sám z nějakého důvodu „umřel“, samostatně nebo společně s vašimi dalšími zdroji (například spadl kanál do datového centra)? Při použití externí služby okerr - tento problém je vyřešen - obdržíte upozornění, i když je celé datové centrum s vašimi servery bez proudu nebo je napadeno zombiemi.

Samozřejmě existuje riziko, že samotný okerr server bude nedostupný, to je pravda (jak víte, 90 % spolehlivosti vždy získáte jednoduše a „zdarma“, 99 % s minimálním úsilím a každá další devítka je exponenciálně obtížnější). Ale za prvé, šance, že se to stane, je nižší, a za druhé, problém může zůstat nepovšimnut pouze v případě, že se shoduje s problémy na našich serverech. Pokud máme spolehlivost 99.9 % a vy máte 99.9 % (ne příliš vysoká čísla), pak je šance na neodhalenou poruchu 0.1 % z 0.1 % = 0.0001 %. Přidání tří devítek ke spolehlivosti téměř bez námahy a bez nákladů je velmi dobré!

Další výhodou monitoringu jako služby je, že poskytovatel hostingu nebo webové studio může nainstalovat okerr server a poskytnout přístup klientům jako placenou nebo bezplatnou doplňkovou službu. Vaši konkurenti mají pouze hosting a webové stránky, ale vy máte spolehlivý hosting s monitorováním.

Okerr je o ukazatelích

Indikátor je „žárovka“. Má dva hlavní stavy – zelený (OK) nebo červený (ERR). Projekt obsahuje mnoho seskupených (například podle serveru) indikátorů. Na hlavní stránce projektu hned vidíte, že buď je vše zelené (a můžete to zavřít), nebo něco svítí červeně a je potřeba to opravit. Při přechodu mezi těmito stavy je odesláno upozornění. Jednou denně během nastavování je zasílán souhrn projektu.

Každý indikátor okerr má vestavěné podmínky, kterými mění stav (v Zabbixu se tomu říká spoušť). Průměrná zátěž by například neměla být větší než 2 (samozřejmě je to konfigurovatelné). A pro každou interní kontrolu (průměr zatížení, volný disk, ...) existuje hlídací pes. Pokud z nějakého důvodu neobdržíme úspěšné potvrzení ve stanovený čas, zaprotokoluje se chyba a odešle se upozornění.

Naším obvyklým pracovním vzorem je zkontrolovat e-maily ráno a podívat se na shrnutí mezi ostatními dopisy (naplánujeme to na začátek práce). Pokud je v něm vše v pořádku, děláme další důležité věci (ale pro jistotu se můžeme rychle podívat na palubní desku okerry a ujistit se, že je v tuto chvíli vše zelené). Pokud přijde upozornění, reagujeme.

Samozřejmě je možné jednoduše ponechat „informační“ indikátory (pro zobrazení obrazu sítě z monitoringu), ale vše je děláno pro jednoduché, snadné a rychlé vytváření indikátorů speciálně pro automatické monitorování a zasílání upozornění.

Účelem, pro který nastavujete okerr, jsou výstrahy, abyste si vytvořili indikátor za minutu, mohl by rok „spát“, jen přijímat aktualizace, a když se o rok později něco pokazí, rozsvítí se a odešle upozornění. Minuta, kterou jste jednou strávili vytvářením indikátoru, se vyplatila; o problému jste se dozvěděli okamžitě, dříve než kdokoli jiný. Je možné, že to opravili, než si toho někdo všiml. Něco, co se rychle zvedne, se nepovažuje za spadlé!

zabezpečení

Byla by škoda, kdybyste si kvůli zvýšení spolehlivosti nastavili monitoring, ale ve výsledku jste přes něj přes síť napadeni a v různých monitorovacích nástrojích je poměrně hodně síťových zranitelností (Zabbix, Nagios).

Agent (okerrmod z balíčku okerrupdate) běžící v systému není síťový server, ale klient. Na sledovaném serveru tedy nejsou žádné další otevřené porty, klient snadno pracuje za firewallem nebo NAT a je velmi obtížné (řekl bych „nemožné“) hacknout po síti, protože v zásadě neposlouchá síť zásuvka.

Plné pokrytí monitorováním

Nyní je naším pravidlem, že se o všech technických problémech dozvídáme od společnosti okerr. Pokud je pravidlo náhle porušeno (okerr neupozornil na jeho brzký výskyt (pokud je to možné) nebo že k němu již došlo) - přidáme kontroly do okerr.

Externí kontroly

Docela typická sada:

• ping
• Stav http
• kontrola platnosti a čerstvosti SSL certifikátu (upozorní, pokud se blíží konec platnosti)
• otevřete TCP port a banner na něm
• http grep (stránka [nesmí] obsahovat určitý text)
• sha1 hash za účelem zachycení změn stránky.
• DNS (záznam DNS musí mít konkrétní hodnotu)
• WHOIS (upozorní, pokud se doména brzy pokazí)
• Antispam DNSBL (kontrola hostitele proti 50+ antispamovým blacklistům najednou)

Vnitřní kontroly

Také celkem standardní sada (ale snadno rozšiřitelná).

• df (volné místo na disku)
• průměr zatížení
• opentcp (otevřené TCP naslouchající sokety - upozorní, pokud se něco spustilo nebo zhroutilo)
• uptime - pouze doba provozu na serveru. Upozorní, pokud se změnilo dolů (tj. server je přetížený)
• client_ip
• dirsize – používáme jej ke sledování, kdy rootfs našich virtuálních strojů překročí povolenou velikost, bez zavádění přísných omezení, a velikost domovských adresářů uživatelů
• prázdné a neprázdné – sledují soubory, které by měly být prázdné (nebo neprázdné). Například chybový protokol samotného okerr serveru by měl být prázdný, a pokud je v něm i řádek, obdržím upozornění a zkontroluji to. Ale mail.log na poštovním serveru NESMÍ být prázdný (N minut po otočení). A někdy nám byl prázdný po aktualizaci systému, kdy logrotate nemohl správně restartovat rsyslog.
• linecount - počet řádků v souboru (jako wc -l). Používáme ho jako měkčí náhradu za prázdné, kdy se může chybový protokol stále zvětšovat, ale jen pomalu (například Googlebot narazí na některé zavřené stránky). Limit je 2 řádky za 20 minut. Pokud je vyšší, dojde k upozornění

Zajímavé vnitřní kontroly

Pokud jste až do tohoto bodu četli „úhlopříčně“, nyní bude zajímavější číst pozorněji.

zálohy

Sleduje zálohy v adresáři. Naše záložní soubory mají názvy jako „ServerName-20200530.tar.gz“. Pro každý server v okerr je vytvořen indikátor ServerName-DATE.tar.gz (skutečné datum se změní na řádek „DATE“). Sleduje se také samotná přítomnost čerstvé zálohy a její velikost (nemůže být například menší než 90 % předchozí zálohy).

Co je třeba udělat, aby se nová záloha začala sledovat poté, co jsme ji začali vytvářet a vkládat do tohoto adresáře? Nic! Jedná se o velmi pohodlný přístup, když nepotřebujete „nic“, protože:

• Nedělat „nic“ je docela rychlé, šetří to čas
• Je těžké zapomenout nedělat „nic“
• Je těžké udělat „nic“ špatně, s chybou. Nic není nejspolehlivější metoda

Pokud se náhle přestanou zobrazovat nové záložní soubory, zobrazí se upozornění. Pokud jste například deaktivovali jeden ze serverů a neměly by existovat žádné další zálohy, budete muset indikátor smazat (přes webové rozhraní nebo z shellu přes API).

maxfilesz

Sleduje velikost největších souborů (typicky: /var/log/*). To vám umožní zachytit nepředvídatelné problémy, například hesla hrubou silou nebo rozesílání spamu přes server.

runstatus/runline

Jedná se o dva důležité proxy moduly pro spouštění dalších programů na serveru. Runstatus hlásí indikátor ukončení programu. Okerr například nevyžaduje (nevyžaduje) modul pro kontrolu, zda jsou spuštěny služby systemd. To se provádí pomocí runstatus (viz níže). Runline – hlásí serveru linku, kterou program vytváří. Například, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" v konfiguraci Runline na našem serveru vytvoří indikátor servername:temp s teplotou procesoru.

sql

Provede numerický dotaz do MySQL a výsledek oznámí indikátoru. V jednoduchém případě můžete udělat například „SELECT 1“ - tím se ověří, že DBMS jako celek funguje.

Mnohem zajímavější aplikací je ale například sledování počtu objednávek v internetovém obchodě. Pokud víte, že máte 100 a více objednávek za hodinu, můžete nastavit minimální limit na 100 nebo 80. Pokud pak vaše tržby náhle poklesnou, dostanete upozornění a můžete na to přijít.

Všimněte si, že nezáleží na tom, z jakého nepředvídatelného důvodu se to stalo:

• Server je jednoduše nedostupný (bez napětí nebo bez sítě) a upozornění přišlo ze skutečnosti, že indikátor byl „shnilý“.
• Server je něčím přetížený, funguje pomalu nebo se ztrácejí pakety, je to pro uživatele nepohodlné a odcházejí bez nákupu
• Server je zařazen do seznamů spamu a pošta z něj není přijímána, uživatelé se nemohou registrovat
• Rozpočet reklamní kampaně došel, bannery se netočí.

Důvodů může být mnoho a všechny nelze předem předvídat a je technicky obtížné je sledovat. Můžete ale pohodlně sledovat výsledný parametr (objednávky) a z nich určit, že situace je podezřelá a zaslouží si řešení.

Logické ukazatele

Umožňuje použití booleovských výrazů (syntaxe Pythonu) prostřednictvím modulu ověřit(článek o Habrém). Data z projektu a jeho indikátory jsou k dispozici pro vyjádření. Například v kapitole o SQL kontrole výše jste si mohli všimnout slabého místa - přes den můžeme mít 100 prodejů za hodinu, ale v noci - 20, a to je běžné, není problém. Co bych měl dělat? Indikátor bude v noci neustále panikařit.

Můžete vytvořit dva indikátory, denní a noční. Udělejte oba „tiché“ (nebudou odesílat upozornění). A vytvořte logický indikátor, který vyžaduje, aby denní indikátor byl v pořádku před 20:00 a po 20:00 stačí, aby byl v pořádku noční indikátor.

Dalším příkladem použití logického indikátoru je eskalace. Například projektový manažer se odhlásí z odběru upozornění (nemusí to dělat, administrátoři by měli reagovat na běžné problémy), ale přihlásí se k odběru logického indikátoru, který zčervená, pokud některý indikátor v projektu není opraven ve stanoveném čase.

Také je možné nastavit povolenou dobu pro práci např. od 3 do 5 hodin. Je nám jedno, jestli během této doby dojde k selhání serverů a webů. Ale v 5:00 musí pracovat. Pokud nefungují v jinou dobu - upozorněte. Logický indikátor také umožňuje vzít v úvahu redundanci serveru. Pokud máte 5 webových serverů, mohou administrátoři kdykoli vypnout 1-2 servery. Ale pokud jsou v bitvě méně než 3 z 5 serverů, dojde k upozornění.

Výše uvedené příklady nepředstavují funkce oker, nikoli některé funkce, které je třeba aktivovat a nakonfigurovat. Okerra nemá všechny tyto funkce, ale existuje logický modul, který vám umožňuje tuto funkcionalitu implementovat (Přibližně jako v programovacím jazyce - pokud máme aritmetické operátory, pak nepotřebujeme speciální funkci pro výpočet 20% DPH z jazyka, vždy to můžete udělat sami, aby vyhovoval vašim potřebám).

Logic Indicator je pravděpodobně jedno z mála poměrně složitých témat v okerru, ale dobrou zprávou je, že jej nemusíte ovládat, dokud to nepotřebujete. Zároveň však značně rozšiřují možnosti, přičemž samotný systém je poměrně jednoduchý.

Přidání vlastních šeků

Opravdu bych rád zprostředkoval myšlenku, že okerr není sada tisíců hotových šeků pro všechny příležitosti, ale naopak - v první řadě - jednoduchý engine s jednoduchou možností vytvářet si vlastní šeky. Vytváření vlastních kontrol v okerru není úkol pro hackery, systémové co-vývojáře nebo alespoň pokročilé uživatele okerru, ale proveditelný úkol pro každého administrátora, který před měsícem poprvé nainstaloval Linux.

Prostřednictvím modulu se provádějí kontroly minimálních mezd runstatus:

Tento řádek v config runstatus vás upozorní, pokud se /bin/true náhle nespustí nebo vrátí něco jiného než 0.

true_OK=/bin/true

Jen jeden řádek - a už jsme tu trochu rozšířený funkčnost okerr.

I taková kontrola má již svou hodnotu: pokud váš server náhle spadne, odpovídající indikátor na serveru okerr nebude včas aktualizován a po uplynutí času se zobrazí upozornění.

Tato kontrola upozorní, že server apache2 spadl (no, nikdy nevíte...):

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

Pokud tedy mluvíte jakýmkoli programovacím jazykem a alespoň umíte psát skripty shellu, můžete již přidat své vlastní kontroly.

Obtížnější - můžete si napsat (v jakémkoli jazyce) svůj vlastní modul pro okerrmod. V nejjednodušším případě to vypadá takto:

#!/usr/bin/python3

print("STATUS: OK")

Není to moc těžké? Modul musí provést kontrolu sám a odeslat výsledky do STDOUT. Složitější modul poskytuje například toto:

$ 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

Aktualizuje několik indikátorů najednou (oddělených prázdným řádkem), v případě potřeby je vytvoří, uvede ověřovací detaily a značku, pomocí které lze snadno najít potřebné indikátory v dashboardu.

Telegram

Existuje robot Telegram @OkerrBot. Nemusíte si zahlcovat telefon samostatnými aplikacemi (nelíbí se mi, že pro Pyaterochku potřebujete jednu aplikaci s mapou, pro Lentu druhou, pro MTS třetí a tak dále pro všechny, všechny, všechny). Jeden telegram stačí. Prostřednictvím telegramu můžete okamžitě přijímat upozornění, zkontrolovat stav projektu a dát příkaz k opětovné kontrole všech problematických indikátorů. Opustili jsme divadlo/letadlo, nedrželi prst na tepu dvě hodiny, zapnuli telefon, zmáčkli jedno tlačítko na chatbotu a ujistili se, že je vše v pořádku.

Stavové stránky

Stavové stránky jsou v dnešní době téměř nezbytností pro každou firmu, která má IT, zodpovědný přístup ke spolehlivosti a která se ke svým klientům/uživatelům chová s respektem.

Představte si situaci – uživatel chce něco udělat, zobrazit informace nebo zadat objednávku a něco nefunguje. Neví, co se děje, na čí straně je problém a kdy se vyřeší. Možná má vaše společnost jednoduše nefunkční web? Nebo se to zlomilo před půl rokem a za dva roky se to spraví? Ale hned je potřeba koupit ledničku, ta už je ve vozíku... A úplně jiná věc je, když člověk vidí, že s tebou není něco v pořádku (alespoň je jasné, že problém není na jeho straně), že problém byl zjištěn, že na něm již pracujete a možná jste si zapsali i přibližný čas nápravy. Uživatel se může přihlásit k odběru a dostávat e-mailové upozornění, když je problém vyřešen a může si dělat, co chtěl (koupit ledničku).

Problémy a výpadky se stávají každému. Uživatelé a partneři však více důvěřují těm, kteří jsou v tomto přístupu transparentnější a odpovědnější.

zde je recenze 10 dalších projektů, které vám umožňují vytvářet stavové stránky. Zde jsou příklady, jak tyto stránky projektu vypadají PYTHON и Dropbox. stavová stránka okerr.

Failover

Aby tento článek nebyl ještě delší, odkážu ještě jednou na svůj předchozí článek - Jednoduché převzetí služeb při selhání pro web . Pokud můžete vytvořit duplicitní server, pak pomocí převzetí služeb při selhání v podstatě nebudete mít dlouhé prostoje – jakmile je zjištěn problém, uživatelé budou automaticky přesměrováni na fungující záložní server. A zdá se mi, že je to velmi zajímavá, jasná funkce, která je jen zřídka někde dostupná.

Nízké systémové požadavky

Pro okerr servery používáme stroje s RAM od 2Gb. Pro síťové senzory stačí i 512Mb. Klientská část je obecně téměř nulová. (Igelitová taška okerrupdate váží 26 Kb, ale vyžaduje Python3 a standardní knihovny). Klient se spouští z cron skriptu, takže má nulovou trvalou spotřebu paměti. Mezi námi sledovanými stroji máme senzory (superlevné VPS s 512Mb RAM) a Raspberry Pi. Jde to i bez klientské části posílat aktualizace přes curl! (viz. níže)

Když to vezmeme v úvahu - pravděpodobně okerr nejvíce zdarma monitorovací systém z dostupných, protože i pro použití jiného bezplatného open-source systému jako Zabbix nebo Nagios je potřeba do něj alokovat zdroje (server), a to už jsou peníze. Kromě toho je stále vyžadována určitá údržba serveru. Pomocí okerr lze tuto část odstranit. Nebo jej nemusíte odstraňovat a používat svůj vlastní server, podle toho, co se vám nejvíce líbí.

API a integrace do proprietárního softwaru

Jednoduchá a otevřená architektura. okerr to má docela jednoduché API, se kterým se snadno pracuje. Potřebujete vytvořit 1000 indikátorů? To udělá jeden shell skript o 3-4 řádcích. Potřebujete překonfigurovat 1000 indikátorů? Je to také velmi snadné. Například chceme znovu zkontrolovat všechny naše HTTPS certifikáty z ruského senzoru:

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

Indikátor můžete aktualizovat pomocí našeho klientského modulu i bez něj, pouze přes 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/

Indikátory můžete aktualizovat přímo z vašeho programu. Například odesílání signálů srdečního tepu, aby okerr věděl, že běží, a spustí alarm, pokud se zhroutí nebo zamrzne. Mimochodem, komponenty okerr to dělají - okerr se sám monitoruje a problémy v téměř každém modulu budou detekovány a vygenerují upozornění na problém. (A v případě tohoto „téměř“ - jsou křížově kontrolovány z jiného serveru)

Zde je kód (zjednodušený) v našem telegramovém robotu:

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

Existuje knihovna pro aktualizaci indikátorů z programů Python okerrupdate, pro žádné jiné jazyky neexistují žádné knihovny, ale můžete buď zavolat skript okerrupdate, nebo odeslat požadavek HTTP na server okerr.

Jak nám pomáhá okerr

Okerr změnil naše životy. Vskutku. Možná by to dokázal jiný monitorovací systém, ale práce s okerrem je pro nás snadná a jednoduchá a má všechny funkce, které jsme potřebovali (přidali jsme to, co neměl). Mimochodem, pokud nějaké funkce chybí, zeptejte se a já je přidám (neslibuji, ale chci, aby okerr byl nejlepší monitorovací systém pro malé a střední projekty). Nebo, ještě lépe, přidejte to sami – je to snadné.

Podařilo se nám žít podle zásady „učte se o všech problémech z kerry“. Pokud se náhle objeví problém, o kterém jsme se od okerru nedozvěděli, přidáme do okerru kontrolu. (v tomto případě „my“ myslím nás jako uživatele systému, nikoli spoluvývojáře). Zpočátku to bylo běžné, ale nyní se to stalo velmi vzácným.

Sledování

Prostřednictvím okerr sledujeme velikosti protokolů na všech serverech. Je samozřejmě nemožné promyšleně číst každý řádek deníku očima, ale pouhé sledování rychlosti růstu už dá hodně. Díky tomu jsme objevili spamovou poštu a hledání hesel hrubou silou, a když se některá z aplikací „zblázní“, něco se jim nepovede a opakují to znovu a znovu (pokaždé přidají pár řádků do protokolu ).

SSL certifikáty. Téměř okamžitě po spuštění Pojďme šifrovat náš zákazník začal svým klientům (asi tisícovce) poskytovat bezplatné SSL certifikáty. A ukázalo se, že je to jen peklo pro administrativu! Faktem je, že stránky jsou „živé“, klienti je pravidelně žádají, aby něco udělali, programátoři to dělají. Mohou zcela libovolně přenést web například do jiného DocumentRoot. Nebo přidejte bezpodmínečné přepsání do konfigurace virtuálního hostitele. Přirozeně se poté automatická obnova certifikátů porouchá. Nyní máme všechny hostitele SSL přidané do okerr automaticky prostřednictvím dalšího z našich užitečných nástrojů z balíčku a2conf. Pojďme jen spustit a2okerr.py — a pokud se na serveru objeví několik nových stránek, automaticky se objeví v okerr. Pokud se náhle z nějakého důvodu certifikát neobnoví, tři týdny před vypršením platnosti certifikátu, víme to a zjistíme, proč není aktualizován, takový pes. a2certbot.py ze stejného balíčku - s tímhle to hodně pomáhá (okamžitě zkontroluje nejpravděpodobnější problémy - a napíše, co bylo zkontrolováno dobře a kde je s největší pravděpodobností problém).

Sledujeme datum expirace všech našich domén. A všechny naše poštovní servery, které odesílají poštu, jsou také kontrolovány podle více než 50 různých blacklistů. (A někdy do nich spadnou). Mimochodem, věděli jste, že poštovní servery Google jsou také na černé listině? Jen pro vlastní testování jsme na sledované servery přidali mail-wr1-f54.google.com, který je stále na černé listině SORBS! (Jde o hodnotu „anti-spamerů“)

Zálohy - již jsem psal výše, jak je snadné je sledovat pomocí okerr. Ale sledujeme jak nejnovější zálohy na našem serveru, tak (pomocí samostatného nástroje, který používá okerr) zálohy, které nahráváme na Amazon Glacier. A ano, problémy se čas od času stávají. Není divu, že se dívali.

Používáme indikátor eskalace. Ukazuje, zda nějaký problém nebyl dlouho vyřešen. A já sám, když řeším nějaké problémy, někdy na ně dokážu zapomenout. Eskalace je dobrou připomínkou, i když se sami sledujete.

Celkově se domnívám, že kvalita naší práce se řádově zvýšila. Nedochází téměř k žádným prostojům (nebo si toho klient nestihne všimnout. Jen pšššt!), zatímco objem práce se zmenšil a pracovní podmínky se zklidnily. Od nouzové práce s přelepováním děr páskou jsme přešli ke klidné a odměřené práci, kdy je mnoho problémů předem předvídáno a je čas jim předcházet. Dokonce i problémy, které se staly, se také snáze opravují: za prvé se o nich dozvíme dříve, než klienti zpanikaří, a za druhé se často stává, že problém souvisí s nedávnou prací (když jsem dělal jednu věc, rozbil jsem jinou) - takže je to horké Je snazší se s tím vypořádat stopy.

Ale byl tu další případ...

Věděli jste, že v populárním Debianu 9 (Stretch) je tak populární balíček jako phpmyadmin stále (po mnoho měsíců!) ve stavu zranitelnosti? (CVE-2019-6798). Když se zranitelnost objevila, rychle jsme ji zakryli různými způsoby. Ale nastavil jsem monitorování stránky security-tracker v okerru, abych věděl, kdy vyjde „krásné“ řešení (přes součet obsahu SHA1). Indikátor mi několikrát škubl, stránka se změnila, ale jak vidíte, stále to (od ledna 2019!) neindikuje, že by byl problém vyřešen. Možná, mimochodem, někdo ví, v čem je problém, že tak důležitý balíček je stále zranitelný déle než rok?

Jindy v podobné situaci: po zranitelnosti v SSH bylo nutné aktualizovat všechny servery. A když nastavujete úkol, musíte řídit provádění. (Podřízení mají tendenci špatně rozumět, zapomínat, být zmateni a dělat chyby). Proto jsme nejprve přidali kontrolu verze SSH do okerr na všech serverech a prostřednictvím okerr jsme se ujistili, že aktualizace byly zavedeny na všechny servery. (Pohodlné! Zvolil jsem tento typ indikátoru a hned vidíte, který server má jakou verzi). Když jsme si byli jisti, že úkol byl dokončen na všech serverech, odstranili jsme indikátory.

Několikrát se vyskytla situace, kdy se objeví určitý problém, který pak sám odezní. (asi všem známý?). V době, kdy si všimnete, v době, kdy kontrolujete – a není co kontrolovat – již vše funguje dobře. Ale pak se to zase zlomí. Stalo se nám to například u produktů, které jsme nahráli na Amazon Marketplace (MWS). V určitém okamžiku byly načtené zásoby nesprávné (špatné množství zboží a špatné ceny). Přišli jsme na to. Ale abychom na to přišli, bylo důležité se o problému dozvědět hned. Bohužel, MWS, stejně jako všechny služby Amazonu, je trochu pomalý, takže vždy došlo ke zpoždění, ale přesto jsme byli schopni alespoň zhruba pochopit souvislost mezi problémem a skripty, které jej způsobují (provedli jsme kontrolu, zasekli na okerr a okamžitě jej zkontroloval a obdržel upozornění).

Zajímavé pouzdro nedávno přidal do sbírky velký a drahý evropský hoster, který používá náš zákazník. Najednou VŠECHNY naše servery zmizely z radaru! Nejprve si zákazník sám (rychlejší než okerra!) všiml, že stránka, se kterou pracuje, se neotevírá, a udělal si o tom lístek. Ale nepadl jen jeden web, ale všechny! (Natasho, všechno jsme nechali!). Zde Okerr začal posílat dlouhé obvazy nohou se všemi indikátory, které se mu rozsvítily. Panika, panika, běháme v kruzích (co jiného můžeme dělat?). Pak všechno povstalo. Ukázalo se, že v datovém centru probíhala běžná údržba (jednou za mnoho let) a samozřejmě jsme měli být varováni. Ale stal se jim nějaký problém a nevarovali nás. No, víc infarktů, míň infarktů. Ale poté, co je vše obnoveno, musíte vše znovu zkontrolovat! Neumím si představit, jak bych to dělal rukama. Okerr vše otestoval během pár minut. Ukázalo se, že většina serverů byla jednoduše dočasně nedostupná, ale fungovaly. Někteří byli přetížení, ale také se postavili, jak měli. Ze všech ztrát jsme přišli o dvě zálohy, které měly být podle koruny vytvořeny a načteny, zatímco probíhal tento plný banán. Ani jsem se neobtěžoval je vytvářet, jen o den později přišla upozornění, že je vše v pořádku, objevily se zálohy. Tento příklad se mi velmi líbí, protože okerr se ukázal jako velmi užitečný v situaci, o které jsme předem ani neuvažovali, ale to je účel sledování - odolat nepředvídatelnému.

Pro senzory Okerr používáme co nejlevnější hosting (kde kvalita a spolehlivost není důležitá, pojišťují se navzájem). Nedávno jsme tedy našli velmi dobrý hosting a super levný, benchmarky jsou úžasné. Ale... někdy se ukáže, že odchozí spojení z virtuálního stroje jsou vytvořena z jiné (sousední) IP. Zázraky. Modul Client_ip s https://diagnostic.opendns.com/myip dostane špatnou IP. A ze serverových logů indikátoru je jasné, že aktualizace přišla také z této sousední IP. Pojďme se nyní zabývat podporou. Je dobře, že jsme si toho všimli v době míru. Často se ale například stává, že přístup je registrován podle bílé listiny IP – a pokud server občas takto krátce zabliká – můžete se tento problém snažit zachytit velmi dlouho.

No a ještě jedna věc – protože mluvíme o VPS hostingu – vždy používáme ty levné (hetzner, ovh, scaleway). Moc se mi líbí jak z hlediska benchmarků, tak stability. Pro další projekty používáme i mnohem dražší Amazon EC2. Takže díky okerr máme svůj vlastní informovaný názor. Oba padají. A neřekl bych, že za dlouhou dobu našeho pozorování se levné hostingy jako hetzner ukázaly být znatelně méně stabilní než EC2. Pokud tedy nejste vázáni na jiné funkce Amazonu, proč platit více? 🙂

Co bude dál?

Pokud jsem vás v této fázi ještě nevyděsil od Okerra, zkuste to! Můžete přejít přímo na tento odkaz demo účet okerr (Klikněte nyní!) Mějte ale na paměti, že pro všechny existuje pouze jeden demo účet, takže pokud něco uděláte, může do vás ve stejnou dobu zasahovat někdo jiný na stejném účtu. Nebo se (lépe) zaregistrujte přes odkaz na offsite okerr - vše je jednoduché, bez SMS. Pokud nechcete používat svůj skutečný e-mail, můžete použít jednorázový, například mailinátor (doporučuji getnada.com). Takové účty mohou být časem smazány, ale pro testování budou v pořádku.

Po registraci budete vyzváni k absolvování školení (provedení několika nepříliš obtížných školicích úkolů). Počáteční limity jsou velmi malé, ale pro školení nebo jeden server stačí. Po absolvování školení se limity (například maximální počet ukazatelů) zvýší.

Z dokumentace - především WIKI na straně serveru a na straně klienta (wiki okerrupdate). Pokud ale není něco jasné, napište na podporu (zavináč) okerr.com nebo zanechte tiket – pokusíme se vše rychle vyřešit.

Pokud to používáte vážně a tyto zvýšené limity vám nestačí, napište na podporu a my vám to (zdarma) navýšíme.

Chcete nainstalovat server okerr na váš server? Tady okerr-dev úložiště. Doporučujeme instalaci na čistý virtuální počítač, poté to jednoduše provedete pomocí instalačního skriptu. Na vašem virtuálním počítači - bez omezení :-). No, znovu, kdyby se cokoliv stalo, vždy se pokusíme pomoci.

Chceme, aby se tento projekt rozjel, aby se svět díky nám stal spolehlivějším. Díky svobodnému softwaru a službám se svět stal přívětivějším a rozvíjí se dynamičtěji. Zdroje mohou být uloženy na bezplatném githubu, pro poštu můžete použít bezplatný gmail. Používáme zdarma čerstvé práce pro podporu. Za nic z toho nemusíte platit za servery, nemusíte stahovat a konfigurovat a nemusíte řešit různé provozní problémy. Každý nový projekt, každý tým má okamžitě poštu, úložiště a CRM. A to vše velmi kvalitní a zdarma a ihned. Chceme, aby to bylo stejné i pro monitorování – malé společnosti a projekty by mohly používat okerr zdarma a dokonce i ve fázi zrodu a růstu mají spolehlivost dospělých seriózních projektů.

Zdroj: www.habr.com