Dwa lata temu napisałem już post Proste przełączanie awaryjne dla witryny internetowej o OK. Teraz jest pewien rozwój projektu, a także opublikowałem kod źródłowy po stronie serwera oker pod licencja otwarta, dlatego zdecydowałam się napisać tę krótką recenzję na Habr.

[ pełny rozmiar ]

Kogo to może zainteresować

Może to Cię zainteresować, jeśli pracujesz w małym zespole lub sam. Nie masz monitoringu i nie jesteś pewien, czy na pewno go potrzebujesz. Albo próbowałeś jakiegoś popularnego, poważnego monitorowania „dla dużych chłopców”, ale jakoś „nie wyszło” w twoim przypadku, albo działa w niemal domyślnej konfiguracji i nie zmieniło zbytnio twojego życia. A także – jeśli na pewno nie planujesz wyznaczyć całego pracownika (ani nawet działu) do monitorowania dashboardu monitoringu przynajmniej na kilka godzin dziennie lub jego konfigurowania.

Dlaczego okerr jest niezwykły

Następnie pokażę ciekawe cechy okerry, które wyróżniają ją na tle innych systemów monitorowania.

Okerr to monitoring hybrydowy

Podczas wewnętrznego monitorowania na monitorowanych maszynach działa „agent”, który przesyła dane do serwera monitorującego (np. ilość wolnego miejsca na dysku). Gdy jest zewnętrzny, serwer sprawdza sieć (na przykład ping lub dostępność strony internetowej). Każde podejście ma swoje ograniczenia. Okerr korzysta z obu opcji. Kontrole wewnątrz serwerów przeprowadzane są przez bardzo lekkiego agenta (30 KB) lub własne skrypty i aplikacje, a kontrole sieci są przeprowadzane za pomocą czujników okerr w różnych krajach.

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

Część serwerowa każdego monitoringu jest duża i złożona, trudna w instalacji i konfiguracji oraz wymaga zasobów. Dzięki okerr możesz zainstalować własny serwer monitorujący (jest darmowy i open source) lub możesz po prostu korzystać tylko z części klienckiej i korzystać z usług naszego serwera. Również bezpłatne.

Jeżeli monitoring pozwala zrekompensować i zatuszować braki niezawodności w serwerach i aplikacjach, to pojawia się pytanie filozoficzne – kto jest strażnikiem? W jaki sposób monitoring powie nam o problemie, jeśli on sam z jakiegoś powodu „umarł”, osobno lub razem z innymi zasobami (np. padł kanał do centrum danych)? Podczas korzystania z usługi zewnętrznej okerr - ten problem został rozwiązany - otrzymasz powiadomienie, nawet jeśli całe centrum danych z Twoimi serwerami będzie pozbawione zasilania lub zostanie zaatakowane przez zombie.

Oczywiście istnieje ryzyko, że sam serwer okerr będzie niedostępny, to prawda (jak wiadomo, 90% niezawodności uzyskuje się zawsze prosto i „za darmo”, 99% przy minimalnym wysiłku, a każde kolejne dziewięć to wykładniczo trudniejsze). Ale po pierwsze, szanse na to są mniejsze, a po drugie, problem może pozostać niezauważony tylko wtedy, gdy zbiega się z problemami na naszych serwerach. Jeśli my mamy niezawodność na poziomie 99.9%, a Ty masz 99.9% (niezbyt duże liczby), wówczas szansa na niewykrytą awarię wynosi 0.1% z 0.1% = 0.0001%. Dodanie trzech dziewiątek do swojej niezawodności prawie bez wysiłku i bez kosztów jest bardzo dobre!

Kolejną zaletą monitorowania jako usługi jest to, że dostawca usług hostingowych lub studio internetowe może zainstalować serwer okerr i zapewniać klientom dostęp w ramach płatnej lub bezpłatnej usługi dodatkowej. Twoi konkurenci mają tylko hosting i strony internetowe, ale Ty masz niezawodny hosting z monitoringiem.

Okerr dotyczy wskaźników

Wskaźnikiem jest „żarówka”. Posiada dwa główne stany - zielony (OK) lub czerwony (ERR). Projekt zawiera wiele wskaźników pogrupowanych (np. według serwera). Na głównej stronie projektu od razu widać, że albo wszystko jest zielone (i można to zamknąć), albo coś świeci na czerwono i trzeba to poprawić. Podczas przejścia między tymi stanami wysyłany jest alert. Raz dziennie podczas konfiguracji wysyłane jest podsumowanie projektu.

Każdy wskaźnik okerr ma wbudowane warunki, według których zmienia stan (w Zabbix nazywa się to wyzwalaczem). Na przykład średnia obciążenia nie powinna być większa niż 2 (oczywiście można to skonfigurować). Dla każdej wewnętrznej kontroli (średnie obciążenie, brak dysku, ...) istnieje watchdog. Jeżeli z jakiegoś powodu w wyznaczonym terminie nie otrzymamy pomyślnego potwierdzenia, zostanie zarejestrowany błąd i wysłany zostanie alert.

Nasz typowy schemat pracy polega na tym, że rano sprawdzamy e-maile i przeglądamy podsumowanie wśród innych listów (planujemy to na początku pracy). Jeśli wszystko w nim jest ok, to robimy inne ważne rzeczy (ale dla bezpieczeństwa możemy szybko zajrzeć do deski rozdzielczej okerry i upewnić się, że w tej chwili wszystko jest zielone). Jeśli nadejdzie ostrzeżenie, reagujemy.

Oczywiście możliwe jest po prostu zachowanie wskaźników „informacyjnych” (aby zobaczyć obraz sieci z monitoringu), ale wszystko po to, aby prosto, łatwo i szybko stworzyć wskaźniki specjalnie do automatycznego monitorowania i wysyłania alertów.

Celem dla którego ustawiasz okerr są alerty, żeby w minutę stworzyć wskaźnik, mógłby „uśpić” rok, po prostu akceptować aktualizacje, a jak po roku coś się zepsuje to zapala się i wysyła ostrzeżenie. Minuta poświęcona na stworzenie wskaźnika opłaciła się – o problemie dowiedziałeś się natychmiast, zanim ktokolwiek inny. Możliwe, że naprawili to, zanim ktokolwiek zauważył. Coś, co szybko się podnosi, nie jest uważane za upadłe!

bezpieczeństwo

Byłoby szkoda, gdybyś skonfigurował monitorowanie w celu zwiększenia niezawodności, ale w rezultacie jesteś za jego pośrednictwem atakowany przez sieć, a w różnych narzędziach monitorujących jest sporo luk w zabezpieczeniach sieci (Zabbix, Nagios).

Agent (okerrmod z pakietu okerrupdate) działający w systemie nie jest serwerem sieciowym, ale klientem. Dlatego na monitorowanym serwerze nie ma żadnych dodatkowych otwartych portów, klient z łatwością działa za zaporą ogniową lub NAT i bardzo trudno (powiedziałbym „niemożliwe”) zhakować przez sieć, ponieważ w zasadzie nie nasłuchuje sieci gniazdo elektryczne.

Pełny zasięg monitoringu

Teraz naszą zasadą jest, że o wszystkich problemach technicznych dowiadujemy się od okerra. Jeżeli nagle reguła zostanie naruszona (okerr nie uprzedził o jej rychłym wystąpieniu (o ile jest to możliwe) lub że już nastąpiło) - dodajemy kontrole do okerr.

Kontrole zewnętrzne

Całkiem typowy zestaw:

• świst
• Stan http
• sprawdzenie ważności i aktualności certyfikatu SSL (ostrzeże, jeśli będzie bliski wygaśnięcia)
• otwórz port TCP i baner na nim
• http grep (strona [nie może] zawierać określonego tekstu)
• sha1, aby przechwytywać zmiany stron.
• DNS (rekord DNS musi mieć określoną wartość)
• WHOIS (ostrzeże, jeśli domena wkrótce ulegnie awarii)
• Antyspam DNSBL (kontrola hosta na ponad 50 czarnych listach antyspamowych jednocześnie)

Kontrole wewnętrzne

Również dość standardowy zestaw (ale z możliwością łatwej rozbudowy).

• df (wolne miejsce na dysku)
• średnie obciążenie
• opentcp (otwarte gniazda nasłuchiwania TCP - powiadomią, jeśli coś się uruchomi lub ulegnie awarii)
• uptime - po prostu uptime na serwerze. Powiadomi, jeśli nastąpi awaria (tj. serwer jest przeciążony)
• klient_ip
• dirsize - używamy go do śledzenia, kiedy rootfs naszej maszyny wirtualnej przekraczają dozwolony rozmiar, bez wprowadzania ścisłych ograniczeń, oraz rozmiar katalogów domowych użytkowników
• pusty i niepusty - monitoruj pliki, które powinny być puste (lub niepuste). Np. dziennik błędów samego serwera okerr powinien być pusty, a jeśli będzie w nim chociaż linijka, to dostanę powiadomienie i sprawdzę to. Ale mail.log na serwerze pocztowym NIE powinien być pusty (N minut po rotacji). A czasami było dla nas puste po aktualizacji systemu, gdy logrotate nie mógł poprawnie zrestartować rsyslog.
• linecount - liczba linii w pliku (np. wc -l). Używamy go jako łagodniejszego zamiennika pustego, gdy dziennik błędów może nadal rosnąć, ale tylko powoli (na przykład Googlebot trafia na niektóre zamknięte strony). Obowiązuje limit 2 linii w ciągu 20 minut. Jeśli będzie wyższa, zostanie wyświetlony alert

Ciekawe kontrole wewnętrzne

Jeśli do tego momentu czytałeś „po przekątnej”, teraz ciekawiej będzie czytać uważniej.

Kopie zapasowe

Monitoruje kopie zapasowe w katalogu. Nasze pliki kopii zapasowych mają nazwy takie jak „NazwaSerwera-20200530.tar.gz”. Dla każdego serwera w okerr tworzony jest wskaźnik ServerName-DATE.tar.gz (rzeczywista data zmienia się na linię „DATE”). Monitorowana jest także sama obecność świeżej kopii zapasowej oraz jej rozmiar (np. nie może być mniejszy niż 90% poprzedniej kopii zapasowej).

Co należy zrobić, aby nowa kopia zapasowa zaczęła być śledzona po tym, jak zaczęliśmy ją tworzyć i umieszczać w tym katalogu? Nic! Jest to bardzo wygodne podejście, gdy trzeba „nic nie robić”, ponieważ:

• Nierobienie „nic” jest dość szybkie, oszczędza czas
• Trudno zapomnieć o „nic nie robieniu”
• Trudno zrobić „nic” złego, popełniając błąd. Nic nie jest najbardziej niezawodną metodą

Jeśli nagle przestaną się pojawiać nowe pliki kopii zapasowych, pojawi się alert. Jeśli np. wyłączyłeś jeden z serwerów i nie powinno być już żadnych kopii zapasowych, konieczne będzie usunięcie wskaźnika (poprzez interfejs WWW lub z powłoki poprzez API).

maxfilesz

Śledzi rozmiar największych plików (zwykle: /var/log/*). Pozwala to wychwycić nieprzewidywalne problemy, np. hasła typu brute-force czy wysyłanie spamu przez serwer.

stan pracy/linia uruchomieniowa

Są to dwa ważne moduły proxy do uruchamiania innych programów na serwerze. Runstatus zgłasza kod zakończenia programu do wskaźnika. Na przykład okerr nie wymaga (wymaga) modułu sprawdzającego, czy usługi systemowe działają. Odbywa się to poprzez status uruchomienia (patrz poniżej). Runline - raportuje do serwera linię utworzoną przez program. Na przykład, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" w konfiguracji Runline na naszym serwerze tworzy wskaźnik nazwa_serwera:temp z temperaturą procesora.

sql

Wykonuje zapytanie numeryczne do MySQL i raportuje wynik do wskaźnika. W prostym przypadku możesz wykonać na przykład „WYBIERZ 1” - sprawdzi to, czy system DBMS jako całość działa.

Ale o wiele ciekawszym zastosowaniem jest na przykład śledzenie liczby zamówień w sklepie internetowym. Jeśli wiesz, że masz 100 lub więcej zamówień na godzinę, możesz ustawić minimalny limit na 100 lub 80. Wtedy, jeśli Twoja sprzedaż nagle spadnie, otrzymasz powiadomienie i będziesz mógł to rozgryźć.

Pamiętaj, że nie ma znaczenia, z jakiego nieprzewidywalnego powodu to się stało:

• Serwer jest po prostu niedostępny (brak zasilania lub sieci), a ostrzeżenie wynika z faktu, że wskaźnik był „zepsuty”.
• Serwer jest czymś przeciążony, działa wolno lub gubi pakiety, jest to niewygodne dla użytkowników i wychodzą bez dokonania zakupów
• Serwer znajduje się na listach spamowych i poczta z niego nie jest akceptowana, użytkownicy nie mogą się rejestrować
• Skończył się budżet kampanii reklamowej, banery nie kręcą się.

Powodów może być wiele i nie można ich wszystkich przewidzieć z góry, a śledzenie ich jest technicznie trudne. Można jednak wygodnie monitorować końcowy parametr (zlecenia) i na ich podstawie stwierdzić, że sytuacja jest podejrzana i zasługuje na to, aby się nią zająć.

Wskaźniki logiczne

Umożliwia użycie wyrażeń logicznych (składnia Pythona) za pośrednictwem modułu sprawdzić(artykuł o Habré). Dane z projektu i jego wskaźników są dostępne do wyrażenia. Na przykład w powyższym rozdziale o sprawdzaniu SQL mogłeś zauważyć słaby punkt - w ciągu dnia możemy mieć 100 sprzedaży na godzinę, ale w nocy - 20, i to jest normalne, nie stanowi problemu. Co powinienem zrobić? Wskaźnik będzie stale panikować w nocy.

Możesz utworzyć dwa wskaźniki, dzień i noc. Ustaw oba jako „ciche” (nie będą wysyłać alertów). I utwórz logiczny wskaźnik, który wymaga, aby wskaźnik dzienny był OK przed 20:00, a po 20:00 wystarczy, że wskaźnik nocny będzie OK.

Innym przykładem zastosowania wskaźnika logicznego jest eskalacja. Na przykład kierownik projektu rezygnuje z alertów (nie musi tego robić, administratorzy powinni reagować na normalne problemy), ale subskrybuje logiczny wskaźnik, który zmienia kolor na czerwony, jeśli którykolwiek wskaźnik w projekcie nie zostanie poprawiony w wyznaczonym czasie.

Można także ustawić dozwolony czas pracy, np. od 3 do 5 rano. Nie obchodzi nas, czy w tym czasie serwery i witryny ulegną awarii. Ale o 5:00 muszą pracować. Jeśli w innym terminie nie zadziałają - alarmuj. Wskaźnik logiczny pozwala również uwzględnić redundancję serwera. Jeśli masz 5 serwerów internetowych, administratorzy mogą w dowolnym momencie wyłączyć 1-2 serwery. Jeżeli jednak w bitwie bierze udział mniej niż 3 z 5 serwerów, pojawi się ostrzeżenie.

Powyższe przykłady nie są funkcjami ok, ani niektórymi funkcjami, które należy aktywować i skonfigurować. Okerra nie posiada wszystkich tych funkcji, ale jest moduł logiczny, który pozwala na realizację tej funkcjonalności (W przybliżeniu jak w języku programowania - jeśli mamy operatory arytmetyczne, to nie potrzebujemy specjalnej funkcji do wyliczenia 20% VAT z języka, zawsze możesz to zrobić sam, dostosuj do swoich potrzeb).

Wskaźnik logiki jest prawdopodobnie jednym z niewielu stosunkowo skomplikowanych tematów w okerr, ale dobra wiadomość jest taka, że ​​nie musisz go opanowywać, dopóki nie będzie to konieczne. Ale jednocześnie znacznie rozszerzają możliwości, zachowując jednocześnie dość prosty system.

Dodawanie własnych czeków

Bardzo chciałbym przekazać myśl, że okerr nie jest zbiorem tysięcy gotowych czeków na każdą okazję, ale wręcz odwrotnie - przede wszystkim - prostym silnikiem z prostą możliwością tworzenia własnych czeków. Tworzenie własnych kontroli w okerr nie jest zadaniem dla hakerów, współtwórców systemu lub przynajmniej zaawansowanych użytkowników okerr, ale wykonalnym zadaniem dla każdego administratora, który miesiąc temu po raz pierwszy zainstalował Linuksa.

Kontrola płacy minimalnej odbywa się za pośrednictwem modułu stan pracy:

Ta linia w pliku config stan pracy powiadomi Cię, jeśli /bin/true nagle się nie uruchomi lub zwróci coś innego niż 0.

true_OK=/bin/true

Tylko jedna linijka - i już jesteśmy trochę rozszerzony funkcjonalność ok.

Nawet taka kontrola ma już swoją wartość: jeśli nagle Twój serwer ulegnie awarii, odpowiedni wskaźnik na serwerze oker nie zostanie zaktualizowany w odpowiednim czasie, a po upływie czasu pojawi się alert.

To sprawdzenie powiadomi, że serwer Apache2 uległ awarii (no cóż, nigdy nie wiadomo...):

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

Tak więc, jeśli znasz dowolny język programowania i przynajmniej potrafisz pisać skrypty powłoki, możesz już dodawać własne kontrole.

Trudniejsze - możesz napisać (w dowolnym języku) własny moduł dla okerrmod. W najprostszym przypadku wygląda to tak:

#!/usr/bin/python3

print("STATUS: OK")

Czy to nie jest bardzo trudne? Moduł musi sam sprawdzić i wyprowadzić wyniki do STDOUT. Bardziej złożony moduł daje na przykład 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.32

Aktualizuje kilka wskaźników na raz (oddzielonych pustą linią), tworzy je w razie potrzeby, wskazuje szczegóły weryfikacji oraz znacznik, dzięki któremu łatwo znaleźć potrzebne wskaźniki w dashboardzie.

Telegram

Istnieje bot Telegramu @OkerrBot. Nie musisz zaśmiecać telefonu osobnymi aplikacjami (nie podoba mi się, że dla Pyaterochki potrzebujesz jednej aplikacji z mapą, dla Lenty drugiej, dla MTS trzeciej i tak dalej dla wszystkich, wszystkich, wszystkich). Wystarczy jeden telegram. Za pośrednictwem telegramu możesz natychmiast otrzymywać powiadomienia, sprawdzać status projektu i wydawać polecenia 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, wcisnęliśmy jeden przycisk w chatbocie i upewniliśmy się, że wszystko jest w porządku.

Strony stanu

W dzisiejszych czasach strony statusowe są niemal koniecznością dla każdej firmy, która posiada IT, odpowiedzialne podejście do niezawodności i która traktuje swoich klientów/użytkowników z szacunkiem.

Wyobraźmy sobie sytuację – użytkownik chce coś zrobić, wyświetlić informacje lub złożyć zamówienie, a coś nie działa. Nie wie, co się dzieje, po czyjej stronie leży problem i kiedy zostanie rozwiązany. Może Twoja firma ma po prostu niefunkcjonalną stronę internetową? A może zepsuł się sześć miesięcy temu i zostanie naprawiony za dwa lata? Ale lodówkę trzeba kupić już teraz, jest już w koszyku... A zupełnie inna sprawa, gdy ktoś widzi, że coś z Tobą jest nie tak (przynajmniej widać, że problem nie leży po jego stronie), że problem został wykryty, że już nad nim pracujesz, a może nawet zapisałeś przybliżony czas naprawy. Użytkownik może się zapisać i otrzymać powiadomienie e-mailem, gdy problem zostanie rozwiązany i będzie mógł robić, co chce (kupić lodówkę).

Problemy i przestoje zdarzają się każdemu. Jednak użytkownicy i partnerzy bardziej ufają tym, którzy podchodzą do tego bardziej przejrzyście i odpowiedzialnie.

tutaj jest przegląd 10 innych projektów pozwalających na tworzenie stron statusowych. Oto przykłady wyglądu tych stron projektu Python и Dropbox. oker strona stanu.

Failover

Aby nie przedłużać tego artykułu, jeszcze raz odniosę się do mojego poprzedniego artykułu - Proste przełączanie awaryjne dla witryny internetowej . Jeśli możesz utworzyć zduplikowany serwer, to korzystając z przełączania awaryjnego, w zasadzie nie będziesz mieć długich przestojów - gdy tylko zostanie wykryty problem, użytkownicy zostaną automatycznie przekierowani na działający serwer zapasowy. I wydaje mi się, że jest to bardzo ciekawa, jasna funkcja, która rzadko jest gdziekolwiek dostępna.

Niskie wymagania systemowe

Do serwerów okerr używamy maszyn z pamięcią RAM od 2Gb. W przypadku czujników sieciowych wystarczy nawet 512Mb. Część klienta jest na ogół prawie zerowa. (Plastikowa torba okerrupdate waży 26 Kb, ale wymaga Python3 i bibliotek standardowych). Klient działa ze skryptu cron, więc zużycie pamięci trwałej jest zerowe. Wśród maszyn, które monitorowaliśmy, mamy czujniki (super tani VPS z 512Mb RAM) i Raspberry Pi. Jest to możliwe nawet bez udziału klienta wysyłaj aktualizacje za pośrednictwem curl! (patrz poniżej)

Biorąc to pod uwagę – prawdopodobnie okerr większość darmowa system monitorowania spośród dostępnych, bo nawet żeby skorzystać z innego darmowego systemu typu open source jak Zabbix czy Nagios, trzeba przeznaczyć na niego zasoby (serwer), a to już są pieniądze. Ponadto nadal wymagana jest konserwacja serwera. Dzięki okerr tę część można usunąć. Lub nie musisz go usuwać i korzystać z własnego serwera, w zależności od tego, co lubisz najbardziej.

API i integracja z oprogramowaniem autorskim

Prosta i otwarta architektura. oker ma całkiem prosty API, z którym łatwo się pracuje. Chcesz utworzyć 1000 wskaźników? Zrobi to jeden skrypt powłoki składający się z 3-4 linii. Chcesz ponownie skonfigurować 1000 wskaźników? To także bardzo łatwe. Na przykład chcemy dokładnie sprawdzić wszystkie nasze certyfikaty HTTPS z rosyjskiego czujnika:

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

Możesz zaktualizować wskaźnik za pomocą naszego modułu klienta, nawet bez niego, po prostu za pomocą 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/

Możesz aktualizować wskaźniki bezpośrednio ze swojego programu. Na przykład wysyłanie sygnałów pulsu, aby okerr wiedział, że działa i podnosił alarm w przypadku awarii lub zawieszenia. Nawiasem mówiąc, komponenty okerr właśnie to robią - okerr monitoruje się sam, a problemy w prawie każdym module zostaną wykryte i wygenerują powiadomienie o problemie. (A w przypadku tego „prawie” - są sprawdzane krzyżowo z innego serwera)

Oto kod (uproszczony) w naszym bocie telegramowym:

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

Istnieje biblioteka do aktualizacji wskaźników z programów w języku Python okerrupdate, dla innych języków nie ma bibliotek, ale możesz albo wywołać skrypt okerrupdate, albo wysłać żądanie HTTP do serwera okerr.

Jak okerr nam pomaga

Okerr zmienił nasze życie. Rzeczywiście. Być może inny system monitorowania mógłby zrobić to samo, ale praca z okerr jest dla nas łatwa i prosta i ma wszystkie funkcje, których potrzebowaliśmy (dodaliśmy to, czego nie miał). Swoją drogą, jeśli brakuje jakichś funkcji, pytaj, a ja je dodam (nie obiecuję, ale chcę, żeby okerr był najlepszym systemem monitorowania małych i średnich projektów). Albo jeszcze lepiej, dodaj go sam – to proste.

Udało nam się żyć zgodnie z zasadą „o wszystkich problemach dowiaduj się od kerry”. Jeśli nagle pojawi się problem, o którym nie dowiedzieliśmy się od okerr, dodajemy kontrolę do okerr. (w tym przypadku przez „my” mam na myśli nas jako użytkowników systemu, a nie współtwórców). Na początku było to powszechne, ale teraz stało się bardzo rzadkie.

Monitorowanie

Za pośrednictwem okerr monitorujemy rozmiary logów na wszystkich serwerach. Niemożliwe jest oczywiście dokładne przeczytanie każdej linii kłody oczami, ale samo monitorowanie tempa wzrostu już wiele daje. Dzięki temu wykryliśmy wysyłanie spamu i odgadywanie haseł metodą brute-force, a kiedy niektóre aplikacje „wariują”, coś im nie wychodzi i powtarzają to raz za razem (za każdym razem dodając kilka linii do dziennika ).

Certyfikaty SSL. Niemal natychmiast po uruchomieniu LetsEncrypt nasz klient zaczął dostarczać swoim klientom bezpłatne certyfikaty SSL (około tysiąca sztuk). I okazało się, że to piekło dla administracji! Faktem jest, że strony są „na żywo”, klienci okresowo proszą je o coś, robią to programiści. Mogą całkowicie swobodnie przenieść witrynę np. na inny DocumentRoot. Lub dodaj bezwarunkowe przepisanie do konfiguracji wirtualnego hosta. Naturalnie po tym automatyczne odnawianie certyfikatów zostaje przerwane. Teraz wszystkie hosty SSL zostały automatycznie dodane do okerr za pomocą innego przydatnego narzędzia z pakietu a2conf. Po prostu wystartujmy a2okerr.py — a jeśli na serwerze pojawi się kilka nowych witryn, automatycznie pojawią się one w okerr. Jeśli nagle z jakiegoś powodu certyfikat nie zostanie odnowiony, na trzy tygodnie przed wygaśnięciem certyfikatu, będziemy wiedzieć i dowiemy się, dlaczego nie jest aktualizowany, taki pies. a2certbot.py z tej samej paczki - bardzo w tym pomaga (od razu sprawdza najbardziej prawdopodobne problemy - i pisze, co zostało dobrze sprawdzone i gdzie najprawdopodobniej jest problem).

Monitorujemy datę ważności wszystkich naszych domen. Wszystkie nasze serwery pocztowe wysyłające pocztę są również sprawdzane na ponad 50 różnych czarnych listach. (A czasem w nie wpadają). Swoją drogą, czy wiesz, że serwery pocztowe Google również znajdują się na czarnej liście? Dla własnego testu dodaliśmy mail-wr1-f54.google.com do monitorowanych serwerów i nadal znajduje się on na czarnej liście SORBS! (Tu chodzi o wartość „antyspamerów”)

Kopie zapasowe - pisałem już powyżej jak łatwo je monitorować za pomocą okerr. Ale monitorujemy zarówno najnowsze kopie zapasowe na naszym serwerze, jak i (za pomocą osobnego narzędzia korzystającego z okerr) kopie zapasowe, które przesyłamy do Amazon Glacier. I tak, problemy zdarzają się od czasu do czasu. Nic dziwnego, że patrzyli.

Używamy wskaźnika eskalacji. Pokazuje, czy jakiś problem nie został rozwiązany przez długi czas. A ja sam, gdy rozwiązuję jakieś problemy, czasem udaje mi się o nich zapomnieć. Eskalacja jest dobrym przypomnieniem, nawet jeśli sam siebie monitorujesz.

Ogólnie uważam, że jakość naszej pracy wzrosła o rząd wielkości. Przestojów prawie nie ma (albo klient nie ma czasu tego zauważyć. Po prostu ciii!), a ilość pracy się zmniejszyła, a warunki pracy stały się spokojniejsze. Przeszliśmy od pracy awaryjnej przy zaklejaniu dziur taśmą do pracy spokojnej i wyważonej, kiedy wiele problemów jest przewidywanych z góry i jest czas, aby im zapobiec. Nawet problemy, które się wydarzyły, również stały się łatwiejsze do naprawienia: po pierwsze, dowiadujemy się o nich, zanim klienci wpadną w panikę, a po drugie, często zdarza się, że problem ma związek z ostatnią pracą (robiąc jedno, zepsułem drugą) - więc jest gorąco Ślady łatwiej sobie z tym poradzą.

Ale był inny przypadek...

Czy wiesz, że w popularnym Debianie 9 (Stretch) tak popularny pakiet jak phpmyadmin nadal (od wielu miesięcy!) znajduje się w stanie zagrożenia? (CVE-2019-6798). Gdy pojawiła się luka, szybko zajęliśmy się nią na różne sposoby. Ale skonfigurowałem monitorowanie strony śledzenia bezpieczeństwa w okerr, aby wiedzieć, kiedy pojawi się „piękne” rozwiązanie (poprzez sumę treści SHA1). Wskaźnik drgnął mi kilka razy, strona się zmieniła, ale jak widać nadal (od stycznia 2019!) nie oznacza, że ​​problem został rozwiązany. Może przy okazji ktoś wie w czym tkwi problem, że tak ważny pakiet jest podatny na ataki już od ponad roku?

Kolejny raz w podobnej sytuacji: po luce w SSH konieczna była aktualizacja wszystkich serwerów. A kiedy wyznaczasz zadanie, musisz kontrolować jego wykonanie. (Podwładni mają tendencję do niezrozumienia, zapominania, dezorientacji i popełniania błędów). Dlatego najpierw dodaliśmy funkcję sprawdzania wersji SSH do okerr na wszystkich serwerach, a poprzez okerr upewniliśmy się, że aktualizacje zostały wdrożone na wszystkich serwerach. (Wygodne! Wybrałem ten typ wskaźnika i od razu widać, który serwer ma jaką wersję). Kiedy byliśmy pewni, że zadanie zostało wykonane na wszystkich serwerach, usunęliśmy wskaźniki.

Kilka razy zdarzyła się sytuacja, że ​​pojawił się pewien problem, a potem sam zniknął. (prawdopodobnie każdemu znane?). Zanim zauważysz, zanim sprawdzisz – a nie ma co sprawdzać – wszystko już działa dobrze. Ale potem znowu się psuje. Zdarzyło nam się to na przykład w przypadku produktów, które przesłaliśmy do Amazon Marketplace (MWS). W pewnym momencie załadowane zapasy były nieprawidłowe (złe ilości towarów i złe ceny). Rozwiązaliśmy to. Ale żeby to rozgryźć, ważne było, aby od razu dowiedzieć się o problemie. Niestety MWS, podobnie jak wszystkie usługi Amazon, jest trochę powolny, więc zawsze występowało opóźnienie, ale mimo to udało nam się przynajmniej z grubsza zrozumieć związek między problemem a skryptami, które go powodują (sprawdziliśmy, utknęliśmy go do okerra i sprawdziłem natychmiast po otrzymaniu ostrzeżenia).

Do kolekcji dołączył ostatnio ciekawy case od dużego i drogiego europejskiego hostera, z którego korzysta nasz klient. Nagle WSZYSTKIE nasze serwery zniknęły z radaru! Najpierw sam klient (szybciej niż okerra!) zauważył, że strona, z którą współpracował, nie otwiera się i wystawił z tego powodu mandat. Ale nie tylko jedna witryna uległa awarii, ale wszystkie! (Natasza, rzuciliśmy wszystko!). Tutaj Okerr zaczął wysyłać długie opaski na stopy ze wszystkimi świecącymi dla niego wskaźnikami. Panika, panika, biegamy w kółko (co innego możemy zrobić?). Potem wszystko się podniosło. Okazuje się, że w centrum danych przeprowadzono rutynową konserwację (raz na wiele lat) i oczywiście należało nas ostrzec. Ale przydarzył im się jakiś problem i nas nie ostrzegli. Cóż, więcej ataków serca, mniej ataków serca. Ale po przywróceniu wszystkiego musisz wszystko dokładnie sprawdzić! Nie wyobrażam sobie, jak bym to zrobił własnymi rękami. Okerr przetestował wszystko w ciągu kilku minut. Okazało się, że większość serwerów była po prostu chwilowo niedostępna, ale działały. Niektórzy byli przeciążeni, ale też wstawali tak, jak powinni. Ze wszystkich strat straciliśmy dwa zapasy, które według korony powinny były zostać utworzone i załadowane w czasie trwania tego pełnego banana. Nawet nie zawracałem sobie głowy ich tworzeniem, zaledwie dzień później pojawiły się powiadomienia, że ​​wszystko jest w porządku, pojawiły się kopie zapasowe. Bardzo podoba mi się ten przykład, ponieważ okerr okazał się bardzo przydatny w sytuacji, o której nawet wcześniej nie myśleliśmy, a taki jest cel monitorowania – przeciwstawienie się nieprzewidywalnemu.

W przypadku czujników Okerr korzystamy z najtańszego możliwego hostingu (gdzie jakość i niezawodność nie są ważne, ubezpieczają się nawzajem). Niedawno znaleźliśmy bardzo dobry hosting i super tani, testy porównawcze są niesamowite. Ale... czasami okazuje się, że połączenia wychodzące z maszyny wirtualnej są realizowane z innego (sąsiadującego) adresu IP. Cuda. Moduł Client_ip z https://diagnostic.opendns.com/myip dostaje zły adres IP. A z logów serwera wskaźnika jasno wynika, że ​​aktualizacja również pochodziła z tego sąsiedniego adresu IP. Zajmijmy się teraz wsparciem. Dobrze, że zauważyliśmy to w czasie pokoju. Ale np. często zdarza się, że dostęp jest rejestrowany według białej listy IP - i jeśli serwer czasem tak miga przez krótki czas - to można próbować wyłapać ten problem bardzo długo.

No i jeszcze jedno – skoro mowa o hostingu VPS – zawsze korzystamy z niedrogich (hetzner, ovh, Scaleway). Bardzo mi się podoba zarówno pod względem benchmarków, jak i stabilności. Do innych projektów wykorzystujemy także znacznie droższe Amazon EC2. Dzięki okerr mamy więc własną, świadomą opinię. Oboje upadają. I nie powiedziałbym, że na przestrzeni długiego okresu naszych obserwacji tanie hostingi typu hetzner okazywały się zauważalnie mniej stabilne niż EC2. Dlatego jeśli nie jesteś przywiązany do innych funkcji Amazon, po co płacić więcej? 🙂

Co dalej?

Jeśli na tym etapie jeszcze Cię nie odstraszyłem od Okerra, to spróbuj! Możesz przejść bezpośrednio do tego linku oker konto demo (Kliknij teraz!) Pamiętaj jednak, że dla wszystkich jest tylko jedno konto demo, więc jeśli coś zrobisz, ktoś inny na tym samym koncie może w tym samym czasie przeszkadzać. Lub (lepiej) zarejestruj się poprzez link do poza siedzibą firmy, OK - wszystko jest proste, bez SMS-ów. Jeśli nie lubisz używać swojego prawdziwego adresu e-mail, możesz użyć jednorazowego, np. mailinatora (polecam getnada.com). Takie konta mogą z czasem zostać usunięte, ale będą w porządku do testów.

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

Z dokumentacji - przede wszystkim WIKI po stronie serwera i klienta (okerrupdate wiki). Jeśli jednak coś jest niejasne, napisz do supportu (at) okerr.com lub zostaw zgłoszenie - postaramy się szybko wszystko rozwiązać.

Jeśli używasz go na poważnie i te zwiększone limity nie wystarczą, napisz do supportu, a my je zwiększymy (za darmo).

Czy chcesz zainstalować serwer okerr na swoim serwerze? Tutaj repozytorium okerr-dev. Zalecamy instalację na czystej maszynie wirtualnej, wtedy można to po prostu zrobić za pomocą skryptu instalacyjnego. Na Twojej maszynie wirtualnej - bez ograniczeń :-). Cóż, jeśli coś się stanie, zawsze postaramy się pomóc.

Chcemy, żeby ten projekt wystartował, aby świat dzięki nam stał się bardziej niezawodny. Dzięki darmowemu oprogramowaniu i usługom świat stał się bardziej przyjazny i rozwija się dynamiczniej. Źródła można przechowywać na darmowym githubie, do poczty można używać darmowego Gmaila. Korzystamy bezpłatnie świeże wyroby dla wsparcia. W tym celu nie musisz płacić za serwery, nie musisz pobierać i konfigurować ani rozwiązywać różnych problemów operacyjnych. Każdy nowy projekt, każdy zespół od razu ma pocztę, repozytoria i CRM. A wszystko to jest bardzo wysokiej jakości, bezpłatne i natychmiastowe. Chcemy, żeby tak samo było z monitoringiem – małe firmy i projekty mogłyby korzystać z okerr za darmo i już na etapie narodzin i wzrostu mieć pewność poważnych, dorosłych projektów.

Źródło: www.habr.com