Dwa lata temu już napisałem post Prosty failover dla strony internetowej mówiłem okerr. Obecnie projekt się nieco rozwinął, a ja opublikowałem kod źródłowy serwera okerr pod na otwartej licencji, dlatego postanowiłem napisać na habr ten krótki przegląd.

[ pełny rozmiar ]

Kogo to może zainteresować

Może to Cię interesować, jeśli pracujesz w małym zespole lub w ogóle sam. Nie masz monitorowania i nie jesteś pewien, czy jest ono potrzebne. Lub próbowałeś jakiegoś popularnego, poważnego monitorowania "dla dużych chłopców", ale jakoś "nie chwyciło", lub działa w prawie domyślnej konfiguracji i nie zmieniło znacząco Twojego życia. A także — jeśli na pewno nie planujesz wyznaczać całego pracownika (a nawet działu) do tego, aby przynajmniej kilka godzin dziennie monitorował na pulpicie monitorowania lub go konfigurował.

Czym jest niezwykły okerr

Następnie pokażę interesujące cechy okerr, które odróżniają go od niektórych innych systemów monitorujących.

Okerr — to hybrydowe monitorowanie

W przypadku monitorowania wewnętrznego na obserwowanych maszynach działa "agent", który przesyła dane na serwer monitorowania (na przykład, wolne miejsce na dyskach). W monitorowaniu zewnętrznym serwer wykonuje kontrole przez sieć (na przykład, ping lub dostępność strony internetowej). Każde z podejść ma swoje ograniczenia. Okerr wykorzystuje oba warianty. Kontrole wewnątrz serwerów są wykonywane bardzo lekkim (30Kb) agentem lub Twoimi własnymi skryptami i aplikacjami, a kontrole sieciowe przez czujniki okerr w różnych krajach.

okerr — to nie tylko oprogramowanie, ale także usługa

Część serwerowa każdego monitorowania to duża i skomplikowana rzecz, trudna do zainstalowania i skonfigurowania, wymagająca zasobów. Z okerr możesz zainstalować własny serwer monitorowania (jest darmowy i open source), a możesz po prostu korzystać tylko z części klienckiej i korzystać z usługi naszego serwera. Również za darmo.

Jeśli monitoring pozwala na zrekompensowanie braku niezawodności serwerów i aplikacji, rodzi się filozoficzne pytanie — kto pilnuje strażnika? Jak monitoring może nas poinformować o problemie, jeśli sam 'umarł' z jakiegoś powodu, oddzielnie lub razem z innymi twoimi zasobami (na przykład, jeśli padł kanał do centrum danych)? Korzystając z zewnętrznej usługi okerr — ten problem jest rozwiązany — otrzymasz alert nawet jeśli całe centrum danych z twoimi serwerami będzie pozbawione zasilania lub padnie ofiarą ataku zombie.

Oczywiście, istnieje ryzyko, że serwer okerr sam będzie niedostępny, to prawda (jak wiadomo, 90% niezawodności osiąga się zawsze łatwo i 'za darmo', 99% — przy minimalnym wysiłku, a każda następna dziewiątka — jest eksponencjalnie trudniejsza). Ale po pierwsze, szanse na to są mniejsze, a po drugie, problem może pozostać niezauważony tylko wówczas, jeśli zbiegł się w czasie z problemami na naszych serwerach. Jeśli mamy niezawodność na poziomie 99.9%, a ty też 99.9% (nie są to zbyt wysokie liczby), to szansa na niezauważony błąd wynosi 0.1% z 0.1% = 0.0001%. Dodać sobie trzy dziewiątki w niezawodności prawie bez wysiłku i wydatków — to bardzo dobrze!

Kolejną zaletą monitorowania jako usługi jest to, że dostawca hostingu lub agencja webowa może zainstalować serwer okerr i zaoferować klientom dostęp do niego jako płatną lub bezpłatną dodatkową usługę. Twoi konkurenci mają tylko hosting i strony — a ty oferujesz niezawodny hosting z monitoringiem.

Okerr — to jest o wskaźnikach

Wskaźnik — to 'lampka'. Ma dwa podstawowe stany — zielony (OK) lub czerwony (ERR). W projekcie znajduje się wiele pogrupowanych (na przykład, według serwerów) wskaźników. Na głównej stronie projektu od razu widzisz, czy wszystko u ciebie jest zielone (i można zamknąć), czy coś świeci na czerwono i trzeba to naprawić. Przy przechodzeniu między tymi stanami — wysyłane jest powiadomienie. Raz dziennie, o czasie, gdy to skonfigurujesz — wysyłane jest podsumowanie projektu.

Każdy wskaźnik okerr ma wbudowane warunki, na podstawie których zmienia stan (w Zabbix nazywa się to trigger). Na przykład, średnie obciążenie (load average) nie powinno wynosić więcej niż 2 (oczywiście, to jest konfigurowalne). I dla każdej wewnętrznej kontroli (load average, wolne miejsce na dysku, …) — istnieje watchdog. Jeśli z jakiegoś powodu nie otrzymamy pozytywnego potwierdzenia w wyznaczonym czasie — rejestrujemy błąd i wysyłany jest alert.

Nasza standardowa procedura to poranna kontrola poczty, gdzie wśród wielu wiadomości sprawdzamy podsumowanie (ustalamy czas na początek pracy). Jeśli wszystko jest w porządku, zajmujemy się innymi ważnymi sprawami (możemy jednak dla pewności szybko zajrzeć do pulpitu nawigacyjnego okerra, aby upewnić się, że w tym momencie wszystko jest zielone). Jeśli pojawi się alert, reagujemy.

Oczywiście, istnieje możliwość trzymania jedynie «informacyjnych» wskaźników (aby zobaczyć obraz sieci z monitorowania), ale wszystko zrobione jest tak, aby łatwo i szybko tworzyć wskaźniki do automatycznego nadzoru i wysyłania alertów.

Sens, dla którego konfigurujesz okerr, tkwi w alertach — abyś mógł w minutę stworzyć wskaźnik, który przez rok mógłby «spać», po prostu przyjmując aktualizacje. A kiedy po roku coś się zepsuje, on się zapali i wyśle alert. Minuta, którą raz poświęciłeś na stworzenie wskaźnika, zwróciła się, dowiedziałeś się o problemie od razu, jako pierwszy. Być może udało ci się naprawić to, zanim ktokolwiek zauważył. Szybko podniesione nie liczy się jako upadłe!

Bezpieczeństwo

Byłoby smutno, gdybyś ustawił monitoring w celu zwiększenia niezawodności, a w rezultacie — zostałeś zaatakowany przez sieć, ponieważ różne narzędzia monitorujące mają wiele luk sieciowych (Zabbix, Nagios).

Agent (okerrmod z pakietu okerrupdate), działający na systemie — to nie serwer sieciowy, a klient. Dlatego na monitorowanym serwerze nie ma dodatkowych otwartych portów, klient łatwo działa za zaporą ogniową lub NAT-em i jest bardzo trudny (że tak powiem «niemożliwy») do złamania przez sieć, ponieważ zasadniczo nie nasłuchuje na gniazdku sieciowym.

Pełne pokrycie monitoringu

Obecnie mamy regułę — dowiadujemy się o wszystkich problemach technicznych z okerr. Jeśli nagle reguła zostanie naruszona (okerr nie ostrzegł o jej niedoborze (jeśli to możliwe) lub o tym, że już nastał) — dodajemy kontrole do okerr.

Kontrole zewnętrzne

Dość standardowy zestaw:

ping
status http
sprawdzanie ważności i świeżości certyfikatu SSL (ostrzega, jeśli termin wygasa wkrótce)
otwarty port TCP i baner na nim
grep http (na stronie [nie] powinien znajdować się określony tekst)
hash sha1, aby wychwycić zmianę strony.
DNS (rekord DNS powinien mieć określoną wartość)
WHOIS (ostrzega, jeśli domena wkrótce wygasa)
Antispam DNSBL (sprawdzanie hosta od razu w 50+ czarnych listach antyspamowych)

Wewnętrzne kontrole

Też dość typowy zestaw (ale łatwy do rozszerzenia).

df (wolne miejsce na dyskach)
average load
opentcp (otwarte gniazda TCP nasłuchujące — powiadomi, jeśli coś się uruchomi lub padnie)
uptime — po prostu uptime serwera. Powiadomi, jeśli spadnie (tzn. serwer został ponownie uruchomiony)
client_ip
dirsize — używamy go do monitorowania, gdy rootfs wirtualek przekracza dozwolony rozmiar, bez wprowadzania sztywnych ograniczeń, oraz do rozmiarów katalogów domowych użytkowników.
empty i nonempty — monitorują pliki, które powinny być puste (lub niepuste). Na przykład, error log samego serwera okerr — powinien być pusty, a jeśli pojawi choćby jedna linia — dostanę powiadomienie i sprawdzę. Z kolei mail.log na serwerze pocztowym powinien być NIE pusty (po N minutach od rotacji). A czasami był pusty, po aktualizacji systemu, gdy logrotate nie mógł poprawnie zrestartować rsyslog.
linecount — liczba linii w pliku (jak wc -l). Używamy tego jako łagodniejszej alternatywy dla empty, gdy error log może rosnąć, ale tylko wolno (na przykład, nasz googlebot ściśle sprawdza pewne zamknięte strony). Ustawiony limit na 2 linie w ciągu 20 minut. Jeśli będzie więcej — nastąpi alert.

Ciekawe wewnętrzne kontrole

Jeśli do tej pory czytałeś „po łebkach”, teraz będzie ciekawiej przeczytać bardziej uważnie.

backups

Monitoruje kopie zapasowe w katalogu. Mamy pliki kopii zapasowych o nazwach takich jak „ServerName-20200530.tar.gz”. Dla każdego serwera w okerr tworzony jest wskaźnik ServerName-DATE.tar.gz (faktyczna data zmienia się na ciąg „DATE”). Monitorowane jest zarówno istnienie świeżej kopii zapasowej, jak i jej rozmiar (na przykład nie może być mniejsza niż 90% poprzedniej kopii zapasowej).

Co trzeba zrobić, aby nowa kopia zapasowa zaczęła być monitorowana po tym, jak zaczęliśmy ją tworzyć i wkładać do tego katalogu? Nic! To bardzo wygodne podejście, gdy trzeba zrobić „nic”, ponieważ:

Zrobienie „nic” jest dość szybkie, oszczędza czas.
Trudno zapomnieć, aby zrobić „nic”.
Trudno zrobić „nic” źle, z błędem. Nic — to najpewniejsza metoda.

Jeśli jednak nagle przestaną pojawiać się świeże pliki kopii zapasowej — nastąpi alert. Jeśli na przykład wyłączyłeś jeden z serwerów i jego kopii zapasowej już nie powinno być — będziesz musiał usunąć wskaźnik (przez interfejs webowy lub z linii poleceń przez API).

maxfilesz

Monitoruje rozmiar największych plików (zazwyczaj: /var/log/*). Pomaga to w wychwytywaniu nieprzewidywalnych problemów, takich jak ataki brute force lub wysoka wysyłka spamu przez serwer.

runstatus/runline

To dwa ważne moduły proxy do uruchamiania innych programów na serwerze. Runstatus informuje o kodzie wyjścia programu. Na przykład, w okerr nie ma (nie jest wymagany) moduł do sprawdzania, czy usługi systemd działają. To odbywa się za pośrednictwem runstatus (patrz poniżej). Runline — informuje serwer o linii, którą generuje program. Na przykład, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" w konfiguracji Runline na naszym serwerze tworzy wskaźnik servername:temp z temperaturą procesora.

sql

Wykonuje zapytanie numeryczne do MySQL i informuje o wyniku w wskaźniku. W prostym przypadku można wykonać na przykład „SELECT 1” — to sprawdzi, czy baza danych działa poprawnie.

Ale znacznie ciekawsze zastosowanie — na przykład, śledzenie liczby zamówień w sklepie internetowym. Jeśli wiesz, że co godzinę masz 100 zamówień, możesz ustawić minimalny próg na 100 lub 80. Wtedy, jeśli nagle spadną sprzedaże — otrzymasz alert i będziesz mógł się tym zająć.

Zauważ — niezależnie od tego, z jakiego nieprzewidywalnego powodu to się stało:

Serwer jest po prostu niedostępny (brak zasilania lub utrata sieci), a alert przyszedł z powodu przestarzałego wskaźnika.
Serwer jest przeciążony, wolno działa lub tracone są pakiety, użytkownikom jest niewygodnie i opuszczają stronę bez zakupów.
Serwer znalazł się na czarnych listach spamowych i wiadomości od niego nie są przyjmowane, użytkownicy nie mogą się rejestrować.
Skonczono budżet kampanii reklamowej, banery nie są wyświetlane.

Przyczyn może być wiele, i nie da się ich wszystkich przewidzieć, a technicznie trudno je śledzić. Ale można wygodnie monitorować końcowy parametr (zamówienia) i na jego podstawie określić, że sytuacja jest podejrzana i zasługuje na to, aby się z nią zająć.

Logiczne wskaźniki

Pozwala korzystać z wyrażeń logicznych (składnia Pythona) za pośrednictwem modułu evalidate(artykuł na habrze). Do wyrażenia dostępne są dane projektu i jego wskaźników. Na przykład, w rozdziale o sprawdzeniu SQL powyżej, być może zauważyliście słaby punkt — w ciągu dnia mamy od 100 sprzedaży na godzinę, ale w nocy — 20, co jest normą, nie problemem. Co zrobić? Wskaźnik będzie w nocy wiecznie panikować.

Można stworzyć dwa wskaźniki: dzienny i nocny. Oba mogą być 'ciche' (nie będą wysyłać powiadomień). Można również stworzyć wskaźnik logiczny, który wymaga, aby do godziny 20:00 dzienny wskaźnik był OK, a po 20:00 wystarczy, aby nocny wskaźnik był OK.

Inny przykład użycia wskaźnika logicznego to eskalacja. Na przykład projektant decyduje się na rezygnację z powiadomień (nie jest mu to potrzebne, administratorzy powinni reagować na standardowe problemy), ale zapisuje się na wskaźnik logiczny, który zmienia kolor na czerwony, jeśli jakikolwiek wskaźnik w projekcie nie został naprawiony w wyznaczonym czasie.

Dodatkowo istnieje możliwość ustalenia dozwolonego czasu pracy, na przykład od 3 do 5 rano. Nie interesuje nas, jeśli serwery i strony 'upadają' w tym czasie. Ale o 5:00 muszą działać. Jeśli nie działają w innym czasie — generowane jest powiadomienie. Również wskaźnik logiczny uwzględnia rezerwację serwerów. Jeśli masz 5 serwerów www, administratorzy mogą wyłączać 1-2 serwery w dowolnym momencie. Ale jeśli w działaniu będzie mniej niż 3 z 5 serwerów — zostanie wygenerowane powiadomienie.

Powyższe przykłady nie są funkcjami okerr, to nie są jakieś funkcje, które należy aktywować i konfigurować. Żadnych z tych funkcji w okerr nie ma, ale istnieje moduł logiczny, który pozwala na realizację tego funkcjonalności (Podobnie jak w języku programowania — jeśli mamy operatory arytmetyczne, to nie potrzebujemy w języku specjalnej funkcji obliczania 20% VAT-u, zawsze możemy to samodzielnie zaimplementować według własnych potrzeb).

Wskaźnik logiczny jest prawdopodobnie jednym z niewielu stosunkowo skomplikowanych tematów w okerr, ale dobrą wiadomością jest to, że nie musisz ich opanować, zanim zajdzie taka potrzeba. Jednak bardzo mocno rozszerzają one możliwości, zachowując samą system stosunkowo prostym.

Dodawanie własnych kontrolek

Bardzo chciałbym przekazać myśl, że okerr to nie zbiór tysiąca gotowych kontrolek na każdą możliwą okoliczność, lecz wręcz przeciwnie — w pierwszej kolejności — prosty silnik z prostą możliwością tworzenia własnych kontrolek. Tworzenie własnych kontrolek w okerr nie jest zadaniem dla hakerów, współtwórców systemu czy przynajmniej zaawansowanych użytkowników okerr, a wykonalnym zadaniem dla każdego administratora, który miesiąc temu po raz pierwszy zainstalował linux.

Sprawdzanie minimalnych warunków odbywa się za pośrednictwem modułu runstatus:

Ten wiersz w konfiguracji runstatus powiadomi, jeśli nagle /bin/true nie zostanie uruchomione lub zwróci wartość inną niż 0.

true_OK=\/bin\/true

Zaledwie jedno zdanie — a już trochę rozszerzyliśmy funkcjonalność okerr.

Nawet taka kontrola ma swoją wartość: jeśli twój serwer przestanie działać — odpowiedni wskaźnik na serwerze okerr nie zaktualizuje się na czas, a po upływie czasu pojawi się alert.

Ta kontrola poinformuje, że serwer apache2 przestał działać (na wszelki wypadek…):

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

Więc jeśli znasz jakikolwiek język programowania, przynajmniej potrafisz pisać skrypty shell — to już możesz dodawać własne kontrole.

Bardziej skomplikowane — można napisać (w dowolnym języku) swój moduł dla okerrmod. W najprostszym przypadku wygląda to tak:

#!/usr/bin/python3

print("STATUS: OK")

Prawda, że nie jest to zbyt trudne? Moduł powinien wykonać samą kontrolę i wyświetlić wyniki na STDOUT. Bardziej skomplikowany moduł daje na przykład coś takiego:

$ okerrmod --dump df
NAME: pi:df-\
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G użytych, 13.0G wolnych
STATUS: 49.52

NAME: pi:df-\/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M użytych, 9.9M wolnych
STATUS: 84.32

Aktualizuje kilka wskaźników naraz (oddzielone pustą linią), w razie potrzeby je tworzy, podaje szczegóły kontroli i tag, według którego w dashboardzie łatwo znaleźć potrzebne wskaźniki.

Jest bot Telegramowy @OkerrBot. Nie musisz zaśmiecać telefonu dodatkowymi aplikacjami (sam nie lubię, że dla Piąterki potrzebna jest jedna aplikacja z kartą, dla Lenta druga, dla MTS trzecia, i tak dla wszystkich wszystkich wszystkich). Jeden telegram — wystarczy. Przez telegram można otrzymywać alerty na bieżąco i sprawdzać status projektu oraz wydać polecenie do ponownego sprawdzenia wszystkich problematycznych wskaźników. Wyszliśmy z teatru/samolotu, przez dwie godziny nie trzymaliśmy ręki na pulsie, włączyliśmy telefon, nacisnęliśmy jeden przycisk w czat-bocie i upewniliśmy się, że wszystko jest w porządku.

Strony statusu

W dzisiejszych czasach strony statusu są już prawie niezbędne dla każdego biznesu, który ma IT, odpowiedzialne podejście do niezawodności i szanuje swoich klientów/użytkowników.

Wyobraź sobie sytuację – użytkownik chce coś zrobić, zobaczyć informacje lub złożyć zamówienie, ale coś nie działa. Nie wie, w czym tkwi problem, po czyjej stronie leży błąd i kiedy zostanie rozwiązany. Może twoja firma ma po prostu niedziałającą stronę? A może coś zepsuło się pół roku temu i naprawi się za dwa lata? A lodówkę trzeba kupić już teraz, jest już w koszyku... Zupełnie inaczej wygląda sytuacja, gdy osoba widzi, że coś jest nie w porządku (przynajmniej jasno widać, że problem nie leży po jej stronie), że problem został wykryty, że już nad nim pracujesz i być może nawet napisałeś przybliżony czas naprawy. Użytkownik może subskrybować powiadomienia e-mailowe, gdy problem zostanie rozwiązany i będzie mógł zrealizować to, co chciał (kupić lodówkę).

Problemy, przestoje – zdarzają się wszystkim. Jednak użytkownicy i partnerzy bardziej ufają tym, którzy są bardziej przejrzystymi i odpowiedzialnymi w podejściu do tego kwestii.

Oto Przegląd 10 innych projektów, które umożliwiają tworzenie stron statusowych. Oto przykłady, jak wyglądają te strony w projektach Python i Dropbox. Strona statusu okerr.

Failover

Aby nie robić tego artykułu jeszcze dłuższym, jeszcze raz odwołam się do swojego poprzedniego artykułu — Prosty failover dla strony internetowej . Jeśli możesz stworzyć serwer zapasowy, to przy użyciu failovera, w zasadzie nie doświadczysz długiego przestoju – gdy tylko problem zostanie wykryty, użytkownicy automatycznie zostaną przekierowani na działający serwer zapasowy. I wydaje mi się, że to bardzo interesująca, wyróżniająca funkcja, która w niewielu miejscach istnieje.

Niskie wymagania systemowe

Dla serwerów okerr – używamy maszyn z RAM od 2 Gb. Dla czujników sieciowych – wystarczy nawet 512 Mb. Strona klienta – praktycznie prawie zero. (Pakiet okerrupdate waży 26 Kb, ale wymaga Python3 i standardowych bibliotek). Klient uruchamiany jest z crona, więc ma zerowe stałe zużycie pamięci. Wśród obserwowanych maszyn mamy czujniki (super tanie VPSy z 512 Mb RAM) oraz Raspberry Pi. Można nawet bez strony klienta wysyłać aktualizacje przez curl! (patrz poniżej)

Biorąc to pod uwagę – okerr, prawdopodobnie, jest najbardziej darmowy Monitoring system from the available options, because even to use another free open-source system like Zabbix or Nagios, resources (server) need to be allocated, and that costs money. Moreover, server maintenance is still required. With okerr, this part can be omitted. But you can also keep it and use your own server—depending on what you prefer.

API and integration into proprietary software

Simple and open architecture. okerr has a fairly straightforward API, which is easy to work with. Need to create 1000 indicators? One shell script of 3-4 lines will do it. Need to reconfigure 1000 indicators? It's very easy as well. For instance, we want to recheck all our HTTPS certificates specifically using a Russian sensor:

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

Indicators can be updated either using our client module or even without it, just via 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/

You can update indicators directly from your program. For example, by sending heartbeat signals so that okerr knows it's running and can raise an alarm if it crashes or hangs. By the way, the components of okerr do just that—okerr monitors itself, and issues in almost any module will be detected, generating a problem alert. (And in case of that "almost"—they are cross-checked from another server)

Here's a sample code (simplified) in our telegram bot:

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

To update indicators from Python programs—there's a library okerrupdate, for any other languages—there is no library, but you can either call the okerrupdate script or make an HTTP request to the okerr server.

How okerr helps us

Okerr changed our lives. Indeed. Perhaps another monitoring system could have done the same, but working with okerr is easy for us, and it has all the features we needed (what was missing—we added). By the way, if any feature is missing—ask, and I will add it (I can't promise, but I want okerr to be the best monitoring system for small to medium projects). Or, even better, add it yourself—it's straightforward.

Udało nam się żyć według zasady „wszystkie problemy należy poznać z okerr”. Jeśli nagle wystąpił jakiś problem, o którym dowiedzieliśmy się nie od okerr — dodajemy sprawdzenie w okerr. (W tym kontekście pod „my” rozumiem nas jako użytkowników systemu, a nie współtwórców). Na początku zdarzało się to często, ale teraz jest to już bardzo rzadkie.

Monitoring

Przez okerr śledzimy rozmiary logów na wszystkich serwerach. Czytanie każdej linijki logu wzrokiem jest oczywiście niemożliwe, ale proste monitorowanie szybkości wzrostu już wiele daje. Dzięki temu odkryliśmy zarówno rozsyłanie spamu, jak i brute force prób łamania haseł, a także kiedy niektóre aplikacje „szaleją”, mają z czymś problem i powtarzają to w kółko (za każdym razem dodając kilka linijek do logu).

Certyfikaty SSL. Prawie od razu po uruchomieniu LetsEncrypt nasz klient zaczął oferować swoim klientom darmowe certyfikaty SSL (około tysiąca z nich). I okazało się, że to prawdziwe piekło w administracji! Chodzi o to, że strony są „żywe”, klienci okresowo proszą o różne rzeczy, programiści to realizują. Mogą swobodnie przenieść stronę do innego DocumentRoot, na przykład. Albo dodać bezwarunkowy Rewrite do konfiguracji wirtualnego hosta. Naturalnie, po takim działaniu automatyczne odnawianie certyfikatów przestaje działać. Teraz wszystkie nasze hosty SSL są automatycznie dodawane do okerr przez nasze kolejne przydatne narzędzie z pakietu a2conf. Po prostu uruchamiamy a2okerr.py — i jeśli na serwerze pojawiło się kilka nowych stron — automatycznie pojawią się w okerr. Jeśli z jakiegoś powodu certyfikat nie jest odnawiany, na trzy tygodnie przed wygaśnięciem certyfikatu — jesteśmy na bieżąco i sprawdzamy, dlaczego nie jest odnawiany, ta psina. a2certbot.py z tego samego pakietu — bardzo pomaga w tym (od razu sprawdza najbardziej prawdopodobne problemy — i informuje, co zostało dobrze sprawdzone, a gdzie najprawdopodobniej jest problem).

Śledzimy daty wygaśnięcia wszystkich naszych domen. A wszystkie nasze serwery pocztowe, które wysyłają e-maile — są również sprawdzane w ponad 50 różnych czarnych listach. (I czasami się w nich znajdują). A propos, czy wiecie, że serwery pocztowe Google również znajdują się na czarnych listach? Po prostu dla samotestowania dodaliśmy mail-wr1-f54.google.com do monitorowanych serwerów, i rzeczywiście jest w czarnej liście SORBS! (To pytanie o wartość „antyspamowców”)

Kopie zapasowe — wcześniej wspomniałem, jak łatwo je śledzić za pomocą okerr. Śledzimy także świeże kopie zapasowe na naszym serwerze oraz (przy użyciu dodatkowego narzędzia, które wykorzystuje okerr) kopie zapasowe, które wrzucamy na Amazon Glacier. I tak, okresowo mogą wystąpić problemy. To nie przypadek, że musimy monitorować.

Używamy wskaźnika eskalacji. Dzięki temu widzimy, jeśli jakiś problem nie został rozwiązany przez dłuższy czas. Czasami, gdy rozwiązuję jakieś zadania, mogę o tym zapomnieć. Eskalacja to dobre przypomnienie, nawet jeśli sam siebie kontroluję.

Ogólnie uważam, że jakość naszej pracy wzrosła znacząco. Praktycznie nie ma przestojów (albo klient nie ma czasu, by to zauważyć. Tsss!), a przy tym objętość pracy zmniejszyła się, warunki pracy stały się spokojniejsze. Przeszliśmy od chaotycznej pracy z łataniem dziur taśmą do spokojnej i wyważonej pracy, gdzie wiele problemów jest przewidywanych z wyprzedzeniem i jest czas, by je zapobiec. Nawet problemy, które już się zdarzyły, stało się łatwiej rozwiązać: po pierwsze, dowiadujemy się o nich zanim klienci zaczynają panikować, po drugie, często bywa tak, że problem związany jest z ostatnią pracą (naprawiając jedno, zepsułem drugie) — dlatego łatwiej jest z nim poradzić sobie od razu.

A oto kolejny przypadek…

Czy wiecie, że w popularnym Debianie 9 (Stretch) taki popularny pakiet jak phpmyadmin nadal (już od wielu miesięcy!) znajduje się w stanie vulnerable? (CVE-2019-6798). Gdy pojawiła się ta luka bezpieczeństwa — szybko zabezpieczyliśmy ją na różne sposoby. Ustawiłem w okerr monitorowanie strony security-tracker’a, aby wiedzieć, kiedy pojawi się "ładne" rozwiązanie (przez sumę SHA1 zawartości). Kilka razy wskaźnik informował mnie, strona się zmieniała, ale jak widać — do tej pory (od stycznia 2019 roku!) nie wskazano, że problem został rozwiązany. Może ktoś wie, co to za problem, że taki ważny pakiet jest vulnerable już od ponad roku?

W podobnej sytuacji: po wykryciu luki w SSH trzeba było zaktualizować wszystkie serwery. Gdy postawisz zadanie — trzeba kontrolować jego wykonanie. (Podwładni mają tendencję do błędnych interpretacji, zapominania, mylenia się, popełniania błędów). Dlatego najpierw w okerr dodaliśmy sprawdzanie wersji SSH na wszystkich serwerach, a następnie przez okerr monitorowaliśmy, czy aktualizacje zostały zastosowane na wszystkich serwerach. (To wygodne! Wybrałem ten typ wskaźnika i od razu widać, na którym serwerze jaka wersja). Kiedy upewniliśmy się, że zadanie zostało wykonane na wszystkich serwerach — usunęliśmy wskaźniki.

Kilka razy miała miejsce sytuacja, kiedy pojawiał się pewien problem, a potem sam znikał. (Pewnie wszyscy to znają?). Zanim zauważysz, zanim sprawdzisz — a tu już nie ma co sprawdzać — wszystko działa znowu dobrze. Ale potem znów następuje awaria. Mieliśmy to na przykład z produktami, które ładowaliśmy na Amazon Marketplace (MWS). W pewnym momencie załadowane zbiory były nieprawidłowe (nie te ilości towarów i nie te ceny). Rozwiązaliśmy to. Ale żeby to zrozumieć — ważne było natychmiastowe poznanie problemu. Niestety, MWS, jak wszystkie usługi Amazona — jest trochę opóźniona, dlatego zawsze był lag, ale mimo wszystko udało się chociaż w przybliżeniu uchwycić związek między problemem a skryptami, które go wywołują (zrobiliśmy kontrolę, przyczepiliśmy ją do okerr i sprawdzaliśmy od razu po otrzymaniu alertu).

Ciekawy przypadek niedawno dodał duży i drogi europejski hosting, z którego korzysta nasz klient. Nagle wszystkie nasze serwery zniknęły z radarów! Najpierw klient sam „rękami” (szybciej niż Okerr!) zauważył, że strona, z którą pracował, nie otwiera się, i stworzył zgłoszenie w tej sprawie. Ale, nie chodziło tylko o jedną stronę, ale o wszystkie! (Natasha, wszystko zawaliliśmy!). Wtedy Okerr zaczął wysyłać długie raporty ze wszystkimi wskaźnikami, które mu się zapaliły. Panika, panika, biegamy w kółko (a co jeszcze robić?). Potem wszystko wróciło do normy. Okazało się, że w centrum danych prowadzone były zaplanowane prace (raz na kilka lat) i oczywiście powinni nas uprzedzić. Jednak pojawił się jakiś problem i nie powiadomili nas. Cóż, zawał mięśnia sercowego więcej czy mniej. Ale po przywróceniu wszystkiego — trzeba to wszystko sprawdzić! Nie wyobrażam sobie, jak bym to robił ręcznie. Okerr przetestował wszystko w kilka minut. Okazało się, że większa część serwerów była po prostu tymczasowo niedostępna, ale działała. Niektóre się zrestartowały, ale też wróciły na swoje miejsca. Z wszystkich strat — straciliśmy dwa backupy, które powinny były być utworzone i załadowane w czasie, gdy panował ten kompletny chaos. Nawet nie stworzyłem ich, po prostu po dobie przyszły powiadomienia, że wszystko w porządku, backupy się pojawiły. Ten przykład bardzo mi się podoba, ponieważ Okerr okazał się bardzo pomocny w sytuacji, o której nawet nie myśleliśmy wcześniej, ale w tym właśnie chodzi o monitorowanie — przeciwstawiać się nieprzewidywalnemu.

Dla sensorów Okerr używamy jak najtańszych hostingów (tam jakość i niezawodność nie mają znaczenia, one się wzajemnie ubezpieczają). Tak więc, niedawno znaleźliśmy bardzo zwinny hosting w super niskiej cenie, benchmarki są niesamowite. Ale… czasami okazuje się, że połączenia wychodzące z wirtualki wykonywane są z innego (sąsiedniego) adresu IP. Cuda. Moduł client_ip z https://diagnostic.opendns.com/myip otrzymuje niewłaściwy adres IP. A z logów serwerowych wskaźnika widać, że aktualizacja również przyszła z tego sąsiedniego adresu IP. Teraz zajmujemy się tym z pomocą techniczną. Dobrze, że zauważyliśmy to w spokojnym czasie. Ale, na przykład, często dzieje się tak, że dostęp jest zapisywany na białej liście adresów IP — i jeśli serwer będzie czasami na krótką chwilę tak migał — można bardzo długo starać się uchwycić ten problem.

A jeśli już mówimy o VPS-ach — zawsze korzystamy z tańszych (hetzner, ovh, scaleway). Zarówno pod względem wyników benchmarków, jak i stabilności — jesteśmy zadowoleni. Używamy również znacznie droższego Amazon EC2 do innych projektów. Tak więc, dzięki okerr mamy swoje uzasadnione zdanie. Zawieszają się — i jedni, i drudzy. I nie powiedziałbym, że w czasie naszych obserwacji tanie hostingi, takie jak hetzner, okazały się znacząco mniej stabilne niż EC2. Dlatego, jeśli nie potrzebujesz innych funkcji Amazona — po co płacić więcej? 🙂

Co dalej?

Jeśli na tym etapie jeszcze nie zniechęciłem Cię do Okerr’a — spróbuj! Prosto z tego linku możesz wejść do demo konta okerr (Kliknij teraz!). Ale pamiętaj — to demo konto jest jedno dla wszystkich, więc jeśli coś robisz — ktoś inny w tym samym czasie może Ci przeszkodzić. Lub (lepiej) zarejestruj się przez link na oficjalnej stronie okerr — wszystko proste, bez SMS-ów. Jeśli nie lubisz używać swojego prawdziwego e-maila — możesz użyć jednorazowego, takiego jak mailinator (Polecam getnada.com). Takie konta mogą być usuwane z czasem — ale do testów się nadają.

Po rejestracji zostaniesz poproszony o odbycie szkolenia (wykonanie kilku niezbyt skomplikowanych zadań edukacyjnych). Początkowe limity są bardzo małe, ale wystarczają na szkolenie lub jeden serwer. Po odbyciu szkolenia — limity (np. maksymalna liczba wskaźników) zostaną zwiększone.

Z dokumentacji — w pierwszej kolejności WIKI na część serwerową i klienta (okerrupdate wiki). Ale jeśli coś jest niejasne — napisz na support (at) okerr.com lub zostaw zgłoszenie — postaramy się szybko wszystko rozwiązać.

Jeśli będziesz korzystać poważnie i te zwiększone limity będą niewystarczające — także, napisz do supportu, zwiększymy (bezpłatnie).

Chcesz postawić serwer okerr na swoim serwerze? Oto repozytorium okerr-dev. Zalecamy instalację na czystej wirtualce, wtedy można to prosto zrobić skryptem instalacyjnym. Na swojej wirtualce — żadnych ograniczeń :-). No i znów — jeśli coś — zawsze postaramy się pomóc.

Chcemy, aby ten projekt wystartował, aby świat stał się bezpieczniejszy dzięki nam. Dzięki darmowemu oprogramowaniu i usługom świat stał się bardziej przyjazny i rozwija się dynamiczniej. Kod źródłowy można przechowywać za darmo na githubie, a do poczty korzystać z darmowego gmaila. Używamy darmowego freshworks do wsparcia. Nie potrzebujesz płacić za serwery, nie musisz pobierać i konfigurować, ani rozwiązywać różnych problemów z eksploatacją. Każdy nowy projekt, każda drużyna — od razu ma zarówno pocztę, jak i repozytoria oraz CRM. I to wszystko jest bardzo wysokiej jakości, darmowe i dostępne natychmiast. Chcemy, aby monitorowanie wyglądało podobnie — małe firmy i projekty mogłyby korzystać z okerr za darmo, nawet na etapie narodzin i rozwoju, mając niezawodność jak poważne, dojrzałe projekty.

Źródło: habr.com