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

[ full size ]

На кого може да бъде интересно

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

С какво е особен okerr

По-долу ще покажа интересни особености на okerr, които го отличават от някои други мониторинги.

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

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

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

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

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

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

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

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

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

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

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

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

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

Сигурност

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

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

Пълен обхват на мониторинга

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

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

Доста типичен набор:

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

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

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

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

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

Ако до това място сте чели „диагонално“, сега ще е интересно да прочетете по-внимателно.

бекъпи

Следи за бекъпите в директорията. При нас файловете с бекъпи имат имена като „ServerName-20200530.tar.gz“. За всеки сървър в okerr се създава индикатор ServerName-DATE.tar.gz (фактическата дата се сменя с реда „DATE“). Следи се както наличието на свеж бекъп, така и размерът му (например, не може да бъде по-малък от 90% от предишния бекъп).

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

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

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

maxfilesz

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

runstatus/runline

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

sql

Изпълнява числова заявка към MySQL и съобщава резултата в индикатора. В прост случай, можете да направите, например, "SELECT 1" — това ще провери дали базата данни функционира.

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

Обърнете внимание — не е важно по каква непредсказуема причина това се случва:

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

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

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

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

Можете да създадете два индикатора, дневен и нощен. И двата да са "тихи" (те няма да изпратят известия). И да създадете логичен индикатор, който изисква до 20:00 дневният индикатор да бъде ОК, а след 20:00 е достатъчно нощният индикатор да е ОК.

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

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

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

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

Добавяне на собствени проверки

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

Проверки на минималките се правят чрез модула runstatus:

Тази линия в конфигурацията runstatus ще извести, ако случайно /bin/true не стартира или върне не 0.

true_OK=\/bin\/true

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

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

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

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

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

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

#!/usr/bin/python3

print("STATUS: OK")

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

$ okerrmod --dump df
ИМЕ: pi:df-\/ 
ТАГОВЕ: df
МЕТОД: numerical|maxlim=90
ДЕТАЙЛИ: 49.52%, 13.9G\/28.2G заето, 13.0G свободно
СТАТУС: 49.52

ИМЕ: pi:df-\/boot
ТАГОВЕ: df
МЕТОД: numerical|maxlim=90
ДЕТАЙЛИ: 84.32%, 53.1M\/62.9M заето, 9.9M свободно
СТАТУС: 84.32

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

Има Telegram бот @OkerrBot. Не е нужно да запълвате телефона си с отделни приложения (и аз не обичам, че за Пятерочка трябва едно приложение с карта, за Лента друго, за МТС трето, и така за всички-всички-всички). Един Telegram—достатъчнo е. Чрез Telegram можете и да получавате предупреждения веднага, и да проверявате статуса на проекта, и да дадете команда за повторна проверка на всички проблемни индикатори. Излезли сте от театър\/самолет, два часа не сте следили, включвате телефона, натискате един бутон в чат-бота и се уверявате, че всичко е наред.

Страници на статуса

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

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

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

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

Failover

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

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

За сървърите okerr — използваме машини с RAM от 2Gb. За мрежови сензори — дори и 512Mb е достатъчно. Клиентската част — почти е нулева. (Пакет okerrupdate тегли 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/

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

Такъв код (опростено) в нашия Telegram бот:

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 програми — има библиотека okerrupdate, за всички други езици — библиотека няма, но можете или да извикате скрипта okerrupdate, или да извършите HTTP заявка към сървъра на okerr.

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

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

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

Мониторинг

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

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

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

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

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

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

А ето и още един случай…

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

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

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

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

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

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

Какво следва?

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

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

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

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

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

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

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