Преди две години вече направих публикация Лесен отказ за уебсайт за okerr. Сега има някакво развитие на проекта и аз също публикувах okerr изходен код от страна на сървъра под отворен лиценз, затова реших да напиша това кратко ревю на Хабр.

За когото може да е интересно

Това може да представлява интерес за вас, ако работите в малък екип или сами. Нямате мониторинг и не сте сигурни дали наистина имате нужда от него. Или сте опитали някакъв популярен сериозен мониторинг „за големите момчета“, но той някак си „не излетя“ за вас, или работи в почти конфигурация по подразбиране и не промени много живота ви. И също така - ако определено не планирате да разпределите цял служител (или дори отдел), който да наблюдава таблото за наблюдение поне няколко часа на ден или да го конфигурирате.

Защо okerr е необичаен

След това ще покажа интересни характеристики на okerra, които я отличават от някои други системи за наблюдение.

Okerr е хибриден мониторинг

По време на вътрешно наблюдение, на наблюдаваните машини работи „агент“, който предава данни към сървъра за наблюдение (например свободно дисково пространство). Когато е външен, сървърът извършва проверки по мрежата (например ping или наличност на уебсайт). Всеки подход има своите ограничения. Okerr използва и двете опции. Проверките в сървърите се извършват от много лек (30 Kb) агент или от вашите собствени скриптове и приложения, а мрежовите проверки се извършват чрез сензори okerr в различни страни.

okerr не е просто софтуер, но и услуга

Сървърната част на всеки мониторинг е голяма и сложна, трудна за инсталиране и конфигуриране и изисква ресурси. С okerr можете да инсталирате свой собствен сървър за наблюдение (той е безплатен и с отворен код) или можете просто да използвате само клиентската част и да използвате услугата на нашия сървър. Също безплатно.

Ако мониторингът ви позволява да компенсирате и прикриете липсата на надеждност в сървърите и приложенията, тогава възниква философски въпрос - кой е пазачът? Как мониторингът ще ни каже за проблем, ако самият той е „умрял“ по някаква причина, отделно или заедно с другите ви ресурси (например падна каналът към центъра за данни)? Когато използвате външната услуга okerr - този проблем е решен - ще получите предупреждение, дори ако целият център за данни с вашите сървъри е без ток или е атакуван от зомбита.

Разбира се, съществува риск самият okerr сървър да бъде недостъпен, това е вярно (както знаете, 90% от надеждността винаги се постига просто и „безплатно“, 99% с минимални усилия и всяка следваща девет е експоненциално по-трудно). Но, първо, шансовете това да се случи са по-малки, и второ, проблемът може да остане незабелязан само ако съвпадне с проблеми на нашите сървъри. Ако ние имаме 99.9% надеждност, а вие имате 99.9% (не твърде високи числа), тогава шансът за неоткрита повреда е 0.1% от 0.1% = 0.0001%. Добавянето на три деветки към вашата надеждност почти без усилия и без разходи е много добро!

Друго предимство на мониторинга като услуга е, че хостинг доставчик или уеб студио може да инсталира okerr сървър и да предоставя достъп на клиенти като платена или безплатна допълнителна услуга. Вашите конкуренти имат само хостинг и уебсайтове, но вие имате надежден хостинг с мониторинг.

Okerr е за индикатори

Индикаторът е "електрическа крушка". Има две основни състояния - зелено (OK) или червено (ERR). Проектът съдържа много групирани (например по сървър) индикатори. На главната страница на проекта веднага виждате, че или всичко е зелено (и можете да го затворите), или нещо свети червено и трябва да се коригира. При преход между тези състояния се изпраща предупреждение. Веднъж на ден, докато го настройвате, се изпраща резюме на проекта.

Всеки индикатор okerr има вградени условия, чрез които променя състоянието (в Zabbix това се нарича тригер). Например средното натоварване не трябва да бъде повече от 2 (разбира се, това може да се конфигурира). И за всяка вътрешна проверка (средно натоварване, свободен диск, ...) има пазач. Ако по някаква причина не получим успешно потвърждение в уречения час, се регистрира грешка и се изпраща предупреждение.

Нашият обичаен модел на работа е да проверяваме имейлите сутрин и да разглеждаме резюмето сред другите писма (планираме го в началото на работа). Ако всичко е наред в него, правим други важни неща (но за по-сигурно можем бързо да погледнем таблото на okerra и да се уверим, че всичко е зелено в този момент). Ако пристигне сигнал, ние реагираме.

Разбира се, възможно е просто да запазите „информационни“ индикатори (за да видите картината на мрежата от мониторинг), но всичко е направено за просто, лесно и бързо създаване на индикатори специално за автоматично наблюдение и изпращане на предупреждения.

Целта, за която настройвате okerr е в алармите, за да можете да създадете индикатор за минута, той може да "спи" една година, просто да приема актуализации и когато след година нещо се повреди, светва и изпраща предупреждение. Минутата, която веднъж прекарахте в създаването на индикатор, се отплати; научихте за проблема веднага, преди всеки друг. Възможно е да са го поправили, преди някой да забележи. Нещо, което се вдига бързо, не се счита за паднало!

сигурност

Би било жалко, ако настроите наблюдение с цел повишаване на надеждността, но в резултат на това сте атакувани през мрежата чрез него и има доста мрежови уязвимости в различни инструменти за наблюдение (Zabbix, Nagios).

Агент (okerrmod от пакет okerruptdate) работещ в системата не е мрежов сървър, а клиент. Следователно няма допълнителни отворени портове на наблюдавания сървър, клиентът лесно работи зад защитна стена или NAT и е много трудно (бих казал „невъзможно“) за хакване през мрежата, тъй като по принцип не слуша мрежата гнездо.

Пълно покритие на мониторинга

Сега нашето правило е, че научаваме за всички технически проблеми от okerr. Ако внезапно правилото бъде нарушено (okerr не предупреди за предстоящото му възникване (ако това е възможно) или че вече се е случило) - добавяме проверки към okerr.

Външни проверки

Доста типичен комплект:

пинг
http статус
проверка на валидността и актуалността на SSL сертификата (ще предупреди, ако е на път да изтече)
отворен TCP порт и банер върху него
http grep (страницата [не трябва] да съдържа специфичен текст)
sha1 хеш, за да улови промените на страницата.
DNS (DNS записът трябва да има конкретна стойност)
WHOIS (ще предупреди, ако домейнът е на път да се повреди)
Антиспам DNSBL (проверка на хост срещу 50+ антиспам черни списъци наведнъж)

Вътрешни проверки

Също така, доста стандартен комплект (но лесно разширяем).

df (свободно дисково пространство)
средно натоварване
opentcp (отворени TCP слушащи сокети - ще уведоми, ако нещо стартира или се срине)
ъптайм - само ъптайм на сървъра. Ще уведоми, ако се е променил (т.е. сървърът е претоварен)
client_ip
dirsize - използваме го, за да проследим кога rootfs на нашата виртуална машина надвишава разрешения размер, без да въвеждаме строги ограничения, както и размера на началните директории на потребителите
празни и непразни - наблюдавайте файлове, които трябва да са празни (или не празни). Например логът за грешки на самия okerr сървър трябва да е празен и ако има дори ред в него, ще получа известие и ще го проверя. Но mail.log на мейл сървъра НЕ трябва да е празен (N минути след ротация). И понякога беше празен за нас след актуализация на системата, когато logrotate не можеше да рестартира правилно rsyslog.
linecount - брой редове във файла (като wc -l). Използваме го като по-мек заместител на празен, когато регистърът на грешките все още може да расте, но само бавно (например Googlebot удря някои затворени страници). Има ограничение от 2 реда за 20 минути. Ако е по-високо, ще има сигнал

Интересни вътрешни проверки

Ако до този момент сте чели "по диагонал", сега ще бъде по-интересно да четете по-внимателно.

архивиране

Следи резервните копия в директорията. Нашите архивни файлове имат имена като „ServerName-20200530.tar.gz“. За всеки сървър в okerr се създава индикатор ServerName-DATE.tar.gz (действителната дата се променя на реда „ДАТА“). Самото наличие на свеж бекъп и неговият размер също се следи (например не може да бъде по-малко от 90% от предишния бекъп).

Какво трябва да се направи, за да започне да се проследява ново архивиране, след като сме започнали да го създаваме и поставяме в тази директория? Нищо! Това е много удобен подход, когато трябва да правите „нищо“, защото:

Правенето на „нищо“ е доста бързо, спестява време
Трудно е да забравиш да не правиш „нищо“
Трудно е да се направи „нищо“ нередно, с грешка. Нищо е най-надеждният метод

Ако внезапно свежи архивни файлове спрат да се появяват, ще има предупреждение. Ако например сте деактивирали един от сървърите и не трябва да има повече резервни копия, ще трябва да изтриете индикатора (чрез уеб интерфейса или от обвивката чрез API).

maxfilesz

Следи размера на най-големите файлове (обикновено: /var/log/*). Това ви позволява да улавяте непредсказуеми проблеми, например груба сила на пароли или изпращане на спам през сървъра.

runstatus/runline

Това са два важни прокси модула за изпълнение на други програми на сървъра. Runstatus съобщава кода за изход на програмата на индикатора. Например, okerr не (изисква) модул за проверка дали системните услуги работят. Това става чрез runstatus (вижте по-долу). Runline - докладва на сървъра реда, който програмата произвежда. Например, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" в конфигурацията на Runline на нашия сървър създава индикатор servername:temp с температурата на процесора.

SQL

Изпълнява числова заявка към MySQL и докладва резултата на индикатора. В прост случай можете да направите например „ИЗБЕРЕТЕ 1“ - това ще провери дали СУБД като цяло работи.

Но много по-интересно приложение е например проследяването на броя на поръчките в онлайн магазин. Ако знаете, че имате 100 или повече поръчки на час, можете да зададете минималния лимит на 100 или 80. След това, ако продажбите ви внезапно спаднат, ще получите предупреждение и можете да го разберете.

Имайте предвид, че няма значение по каква непредсказуема причина се е случило това:

Сървърът просто е недостъпен (изключен или без мрежа), а предупреждението идва от факта, че индикаторът е „гнил“.
Сървърът е претоварен с нещо, работи бавно или се губят пакети, неудобно е за потребителите и те си тръгват без да направят покупки
Сървърът е включен в спам списъците и пощата от него не се приема, потребителите не могат да се регистрират
Бюджетът на рекламната кампания е изчерпан, банерите не се въртят.

Може да има произволен брой причини и всички те не могат да бъдат предвидени предварително и е технически трудно да се проследят. Но можете удобно да наблюдавате крайния параметър (поръчки) и да определите от тях, че ситуацията е подозрителна и заслужава да бъде разгледана.

Логически индикатори

Позволява използването на булеви изрази (синтаксис на Python) чрез модул оценете(статия за хъб). Данните от проекта и неговите показатели са достъпни за изразяване. Например в главата за SQL проверката по-горе може да сте забелязали слабо място - през деня можем да имаме 100 продажби на час, но през нощта - 20 и това е обичайно, не е проблем. Какво трябва да направя? Индикаторът постоянно ще се паникьосва през нощта.

Можете да създадете два индикатора, дневен и нощен. Направете и двете „безшумни“ (няма да изпращат предупреждения). И създайте логичен индикатор, който изисква дневният индикатор да е наред преди 20:00 часа, а след 20:00 часа е достатъчно нощният индикатор да е наред.

Друг пример за използване на логически индикатор е ескалация. Например, ръководител на проект се отписва от известия (няма нужда да прави това, администраторите трябва да реагират на нормални проблеми), но се абонира за логически индикатор, който става червен, ако някой индикатор в проекта не бъде коригиран в рамките на определеното време.

Също така е възможно да зададете разрешеното време за работа, например от 3 до 5 сутринта. Не ни интересува дали сървърите и сайтовете се сриват през това време. Но в 5:00 те трябва да работят. Ако не работят в друго време - сигнал. Логическият индикатор също ви позволява да вземете под внимание резервирането на сървъра. Ако имате 5 уеб сървъра, тогава администраторите могат да изключат 1-2 сървъра по всяко време. Но ако има по-малко от 3 от 5 сървъра в битка, ще има предупреждение.

Примерите по-горе не са окер функции, а не някои функции, които трябва да бъдат активирани и конфигурирани. Okerra няма всички тези функции, но има логически модул, който ви позволява да приложите тази функционалност (Приблизително като в език за програмиране - ако имаме аритметични оператори, тогава не се нуждаем от специална функция за изчисляване на 20% ДДС от езика, винаги можете да го направите сами, направете го според вашите нужди).

Логическият индикатор вероятно е една от малкото сравнително сложни теми в okerr, но добрата новина е, че не е нужно да го овладявате, докато не е необходимо. Но в същото време те значително разширяват възможностите, като същевременно поддържат самата система доста проста.

Добавяне на ваши собствени чекове

Наистина бих искал да предам идеята, че okerr не е набор от хиляди готови проверки за всички случаи, а напротив - на първо място - прост двигател с проста възможност за създаване на ваши собствени проверки. Създаването на ваши собствени проверки в okerr не е задача за хакери, системни съразработчици или поне за напреднали потребители на okerr, а осъществима задача за всеки администратор, който е инсталирал Linux за първи път преди месец.

Чрез модула се извършват проверки на минималните работни заплати състояние на изпълнение:

Този ред в конфиг състояние на изпълнение ще ви уведоми, ако /bin/true изведнъж не стартира или върне нещо различно от 0.

true_OK=/bin/true

Само един ред - и ето ни вече малко разширена функционалност okerr.

Дори такава проверка вече има своята стойност: ако внезапно вашият сървър се срине, съответният индикатор на сървъра okerr няма да се актуализира своевременно и след изтичане на времето ще се появи предупреждение.

Тази проверка ще уведоми, че сървърът apache2 се е сбил (е, никога не се знае...):

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

Така че, ако говорите който и да е език за програмиране и поне можете да пишете шел скриптове, тогава вече можете да добавите свои собствени проверки.

По-трудно - можете да напишете (на всеки език) свой собствен модул за okerrmod. В най-простия случай изглежда така:

#!/usr/bin/python3

print("STATUS: OK")

Не е ли много трудно? Модулът трябва сам да извърши проверката и да изведе резултатите в STDOUT. По-сложен модул дава например това:

$ 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

Той актуализира няколко индикатора наведнъж (разделени с празен ред), създава ги, ако е необходимо, посочва подробности за проверка и етикет, чрез който е лесно да намерите необходимите индикатори в таблото за управление.

Има телеграм бот @OkerrBot. Не е нужно да затрупвате телефона си с отделни приложения (не ми харесва, че за Pyaterochka имате нужда от едно приложение с карта, за Lenta друго, за MTS трето и така нататък за всички, всички, всички). Една телеграма е достатъчна. Чрез телеграма можете незабавно да получавате сигнали, да проверявате състоянието на проекта и да давате команда за повторна проверка на всички проблемни индикатори. Излязохме от театъра/самолета, не сдържахме пулса си два часа, включихме телефона, натиснахме един бутон в чатбота и се уверихме, че всичко е наред.

Страници за състоянието

В днешно време страниците за състояние са почти задължителни за всеки бизнес, който има ИТ, отговорно отношение към надеждността и който се отнася с уважение към своите клиенти/потребители.

Представете си ситуация - потребител иска да направи нещо, да види информация или да направи поръчка и нещо не работи. Не знае какво се случва, на чия страна е проблемът и кога ще се реши. Може би вашата компания просто има нефункциониращ уебсайт? Или се е счупил преди шест месеца и ще го оправят след две години? Но трябва да си купите хладилник сега, той вече е в количката... И е съвсем друго нещо, когато човек види, че нещо не е наред с вас (поне е ясно, че проблемът не е на негова страна), че е открит проблем, че вече работите по него и може би дори сте записали приблизителното време за коригиране. Потребителят може да се абонира и да получава известие по имейл, когато проблемът е отстранен и може да прави каквото иска (да си купи хладилник).

Проблеми и прекъсвания се случват на всеки. Но потребителите и партньорите се доверяват повече на тези, които са по-прозрачни и отговорни в подхода си към това.

тук е преглед на 10 други проекта, които ви позволяват да създавате страници за състояние. Ето примери как изглеждат тези страници на проекта Питон и Dropbox. okerr страница за състояние.

Failover

За да не правя тази статия още по-дълга, отново ще се позова на предишната си статия - Лесен отказ за уебсайт . Ако можете да направите дублиран сървър, след това с помощта на отказ, по същество няма да имате дълъг престой - веднага щом бъде открит проблем, потребителите автоматично ще бъдат пренасочени към работещ резервен сървър. И ми се струва, че това е много интересна, ярка функция, която рядко се предлага навсякъде.

Ниски системни изисквания

За okerr сървъри използваме машини с RAM от 2Gb. За мрежови сензори дори 512Mb са достатъчни. Клиентската част като цяло е почти нулева. (Найлонов плик okerruptdate тежи 26 Kb, но изисква Python3 и стандартни библиотеки). Клиентът работи от cron скрипт, така че има нулева консумация на постоянна памет. Сред машините, които наблюдавахме, имаме сензори (супер евтин VPS с 512Mb RAM) и Raspberry Pi. Възможно е и без клиентската част изпращайте актуализации чрез curl! (виж отдолу)

Имайки това предвид - okerr, вероятно най-безплатно система за мониторинг от наличните, тъй като дори за да използвате друга безплатна система с отворен код като Zabbix или Nagios, трябва да отделите ресурси (сървър) към нея, а това вече са пари. Освен това все още е необходима известна поддръжка на сървъра. С okerr тази част може да бъде премахната. Или не е нужно да го премахвате и да използвате свой собствен сървър, в зависимост от това какво ви харесва най-много.

API и интеграция в патентован софтуер

Проста и отворена архитектура. okerr има доста проста API, с който се работи лесно. Трябва да създадете 1000 индикатора? Един shell скрипт от 3-4 реда ще направи това. Трябва да преконфигурирате 1000 индикатора? Освен това е много лесно. Например, искаме да проверим отново всички наши HTTPS сертификати от руски сензор:

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

Можете да актуализирате индикатора с помощта на нашия клиентски модул, дори и без него, само чрез 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/

Можете да актуализирате индикаторите директно от вашата програма. Например изпращане на сигнали за сърдечен ритъм, така че okerr да знае, че работи и да задейства аларма, ако се срине или замръзне. Между другото, компонентите на okerr правят точно това - okerr се самонаблюдава и проблемите в почти всеки модул ще бъдат открити и ще генерират предупреждение за проблема. (И в случай на това „почти“ - те се проверяват от друг сървър)

Ето кода (опростен) в нашия телеграм бот:

from okerrupdate import OkerrProject, OkerrExc

op = OkerrProject()
uptimei = op.indicator("{}:telebot_uptime".format(hostname))
...
uptimei.update('OK', 'pid: {} Uptime: {} cmds: {}'.format(
        os.getpid(), dhms(uptime), commands_cnt))

Има библиотека за актуализиране на индикатори от Python програми okerruptdate, за всички други езици няма библиотеки, но можете да извикате скрипта okerrupdate или да направите HTTP заявка към сървъра okerr.

Как okerr ни помага

Окер промени живота ни. Наистина. Може би друга система за наблюдение би могла да направи същото, но работата с okerr е лесна и проста за нас и има всички функции, от които се нуждаехме (ние добавихме това, което нямаше). Между другото, ако липсват някои функции, попитайте и аз ще ги добавя (не обещавам, но искам okerr да бъде най-добрата система за наблюдение за малки и средни проекти). Или още по-добре, добавете го сами - лесно е.

Успяхме да живеем според принципа „научете за всички проблеми от kerra“. Ако изведнъж възникне проблем, за който не сме научили от okerr, добавяме проверка към okerr. (в този случай под „ние“ имам предвид нас като потребители на системата, а не съразработчици). Първоначално това беше обичайно, но сега стана много рядко.

мониторинг

Чрез okerr наблюдаваме размерите на журналите на всички сървъри. Разбира се, невъзможно е внимателно да прочетете всеки ред от дневника с очите си, но простото наблюдение на скоростта на растеж вече дава много. Чрез това открихме изпращане на нежелана поща и грубо търсене на пароли и когато някои от приложенията „полудяват“, нещо не им се получава и те го повтарят отново и отново (всеки път добавяйки няколко реда към дневника ).

SSL сертификати. Почти веднага след старта LetsEncrypt нашият клиент започна да предоставя безплатни SSL сертификати на своите клиенти (около хиляда от тях). И това се оказа просто ад за администрацията! Факт е, че сайтовете са „на живо“, клиентите периодично ги молят да направят нещо, програмистите го правят. Могат напълно свободно да прехвърлят сайта в друг DocumentRoot например. Или добавете безусловно презаписване към конфигурацията на virtualhost. Естествено, след това автоматичното подновяване на сертификатите се поврежда. Сега имаме всички SSL хостове, добавени към okerr автоматично чрез друга от нашите полезни помощни програми от пакета a2conf. Нека просто стартираме a2okerr.py — и ако няколко нови сайта се появят на сървъра, те автоматично ще се появят в okerr. Ако изведнъж по някаква причина сертификатът не бъде подновен, три седмици преди изтичането на сертификата, ние сме наясно и ще разберем защо не се актуализира, такова куче. a2certbot.py от същия пакет - помага много с това (веднага проверява най-вероятните проблеми - и пише какво е проверено добре и къде най-вероятно има проблем).

Ние следим датата на изтичане на всички наши домейни. И всички наши пощенски сървъри, които изпращат поща, също се проверяват срещу 50+ различни черни списъци. (И понякога попадат в тях). Между другото, знаете ли, че пощенските сървъри на Google също са в черния списък? Само за самопроверка добавихме mail-wr1-f54.google.com към наблюдаваните сървъри и той все още е в черния списък на SORBS! (Това е за стойността на „анти-спамърите“)

Бекъпи - вече писах по-горе колко лесно се следят с okerr. Но ние наблюдаваме както най-новите резервни копия на нашия сървър, така и (с помощта на отделна помощна програма, която използва okerr) архивите, които качваме в Amazon Glacier. И да, проблемите се случват от време на време. Нищо чудно, че са гледали.

Използваме индикатора за ескалация. Показва дали даден проблем не е бил отстранен дълго време. И аз самият, когато решавам някои проблеми, понякога мога да забравя за тях. Ескалацията е добро напомняне, дори ако се наблюдавате.

Като цяло смятам, че качеството на нашата работа се е повишило с порядък. Почти няма престой (или клиентът няма време да го забележи. Просто шшт!), докато обемът на работата е намалял и условията на работа са станали по-спокойни. Преминахме от спешна работа със закърпване на дупки с тиксо към спокойна и премерена работа, когато много проблеми са предвидени предварително и има време да бъдат предотвратени. Дори възникналите проблеми също станаха по-лесни за отстраняване: първо, разбираме за тях, преди клиентите да изпаднат в паника, и второ, често се случва проблемът да е свързан със скорошна работа (докато правех едно нещо, счупих друго) - така че е горещо По-лесно е следите да се справят с него.

Но имаше и друг случай...

Знаете ли, че в популярния Debian 9 (Stretch) такъв популярен пакет като phpmyadmin все още (в продължение на много месеци!) е в състояние на уязвим? (CVE-2019 6798-). Когато се появи уязвимостта, ние бързо я покрихме по различни начини. Но аз настроих наблюдение на страницата за проследяване на сигурността в okerr, за да знам кога ще излезе „красиво“ решение (чрез SHA1 сумата на съдържанието). Индикаторът ми потрепна няколко пъти, страницата се промени, но както виждате, все още (от януари 2019 г.!) не показва, че проблемът е решен. Може би, между другото, някой знае какъв е проблемът, че такъв важен пакет все още е уязвим повече от година?

Друг път в подобна ситуация: след уязвимост в SSH беше необходимо да се актуализират всички сървъри. И когато поставите задача, трябва да контролирате изпълнението. (Подчинените са склонни да разбират погрешно, да забравят, да се объркват и да правят грешки). Затова първо добавихме проверка на версията на SSH към okerr на всички сървъри и чрез okerr се уверихме, че актуализациите се разпространяват на всички сървъри. (Удобно! Избрах този тип индикатор и веднага можете да видите кой сървър каква версия има). Когато бяхме сигурни, че задачата е изпълнена на всички сървъри, премахнахме индикаторите.

Няколко пъти имаше ситуация, при която възниква определен проблем, който след това изчезва от само себе си. (вероятно познато на всички?). Докато забележите, докато проверите - и няма какво да проверявате - всичко вече работи добре. Но след това отново се счупи. Това се случи например с продукти, които качихме в Amazon Marketplace (MWS). В даден момент зареденият инвентар беше неправилен (грешни количества стоки и грешни цени). Разбрахме го. Но за да го разберем, беше важно да разберем за проблема веднага. За съжаление, MWS, подобно на всички услуги на Amazon, е малко бавен, така че винаги имаше забавяне, но все пак успяхме поне грубо да разберем връзката между проблема и скриптовете, които го причиняват (направихме проверка, останахме го към okerr и го провери веднага, като получи предупреждение).

Наскоро беше добавен интересен случай към колекцията от голям и скъп европейски хостер, който наш клиент използва. Изведнъж ВСИЧКИ наши сървъри изчезнаха от радара! Първо, самият клиент (по-бързо от okerra!) забеляза, че сайтът, с който работи, не се отваря и направи билет за това. Но не само един сайт падна, а всичките! (Наташа, зарязахме всичко!). Тук Окер започна да изпраща дълги опаковки за крака с всички индикатори, които светнаха за него. Паника, паника, тичаме в кръг (какво друго можем да направим?). Тогава всичко се издигна. Оказва се, че е имало рутинна поддръжка в центъра за данни (веднъж на много години) и, разбира се, е трябвало да бъдем предупредени. Но им се случи някакъв проблем и не ни предупредиха. Е, повече инфаркти, по-малко инфаркти. Но след като всичко бъде възстановено, трябва да проверите отново всичко! Не мога да си представя как бих го направил с ръцете си. Okerr тества всичко за няколко минути. Оказа се, че повечето сървъри просто временно са недостъпни, но работят. Някои бяха претоварени, но също се изправиха както трябва. От всички загуби загубихме две резервни копия, които според короната трябваше да бъдат създадени и заредени, докато вървеше този пълен банан. Дори не си направих труда да ги създам, само ден по-късно пристигнаха сигнали, че всичко е наред, появиха се резервни копия. Много ми харесва този пример, защото okerr се оказа много полезен в ситуация, за която дори не сме се замисляли предварително, но това е целта на наблюдението - да устоим на непредсказуемото.

За сензорите Okerr използваме възможно най-евтиния хостинг (където качеството и надеждността не са важни, те се застраховат взаимно). И така, наскоро намерихме много добър хостинг и супер евтин, показателите са страхотни. Но... понякога се оказва, че изходящите връзки от виртуалната машина се правят от друго (съседно) IP. Чудеса. Client_ip модул с https://diagnostic.opendns.com/myip получава грешен IP. А от сървърните логове на индикатора става ясно, че актуализацията идва и от това съседно IP. Сега да се заемем с поддръжката. Добре, че го забелязахме в мирно време. Но, например, често се случва достъпът да се регистрира според белия списък на IP - и ако сървърът понякога мига така за кратко време - можете да опитате да хванете този проблем за много дълго време.

Е, още нещо – тъй като говорим за VPS хостинг – винаги използваме евтини (hetzner, ovh, scaleway). Наистина го харесвам както като бенчмаркове, така и като стабилност. Използваме и много по-скъпия Amazon EC2 за други проекти. Така че, благодарение на okerr, имаме собствено информирано мнение. И двамата падат. И не бих казал, че през дългия период на нашите наблюдения евтините хостинги като hetzner се оказаха значително по-малко стабилни от EC2. Следователно, ако не сте обвързани с други функции на Amazon, защо да плащате повече? 🙂

Каква е следващата?

Ако на този етап все още не съм ви изплашил от Okerr, тогава опитайте! Можете да отидете директно на тази връзка okerr демо сметка (Щракнете сега!) Но имайте предвид, че има само един демо акаунт за всеки, така че ако направите нещо, някой друг в същия акаунт може да ви попречи в същото време. Или (по-добре) се регистрирайте чрез връзката към извън сайта okerr - всичко е просто, без SMS. Ако не обичате да използвате истинския си имейл, можете да използвате такъв за еднократна употреба, като mailinator (препоръчвам getnada.com). Такива акаунти може да бъдат изтрити с течение на времето, но те ще бъдат добри за тестване.

След регистрацията ще бъдете помолени да преминете обучение (изпълнете няколко не много трудни задачи за обучение). Първоначалните ограничения са много малки, но за обучение или един сървър са достатъчни. След приключване на обучението лимитите (например максималният брой индикатори) ще бъдат увеличени.

От документацията - на първо място WIKI от страна на сървъра и от страна на клиента (okerrupdate wiki). Но ако нещо не е ясно, пишете на support (at) okerr.com или оставете билет - ще се опитаме да разрешим всичко бързо.

Ако го използвате сериозно и тези увеличени лимити не са достатъчни, пишете на поддръжката и ние ще го увеличим (безплатно).

Искате ли да инсталирате сървъра okerr на вашия сървър? Тук okerr-dev хранилище. Препоръчваме да инсталирате на чиста виртуална машина, след което можете просто да го направите с инсталационен скрипт. На вашата виртуална машина - без ограничения :-). Е, отново, ако нещо се случи, винаги ще се опитаме да помогнем.

Искаме този проект да се развие, така че светът да стане по-надежден благодарение на нас. Благодарение на безплатния софтуер и услуги светът стана по-приятелски настроен и се развива по-динамично. Източниците можете да съхранявате в безплатния github, а за поща можете да използвате безплатния gmail. Използваме безплатно прясна работа за подкрепа. За нищо от това не е необходимо да плащате за сървъри, не е необходимо да изтегляте и конфигурирате и не е необходимо да решавате различни оперативни проблеми. Всеки нов проект, всеки екип веднага има поща, хранилища и CRM. И всичко това е много качествено и безплатно и веднага. Искаме да бъде същото и за мониторинга - малките компании и проекти биха могли да използват okerr безплатно и дори на етапа на раждане и растеж да имат надеждността на възрастни сериозни проекти.

Източник: www.habr.com

Преглед на хибридната система за мониторинг Okerr