Два роки тому я вже постував Простий failover для вебсайту про okerr. Наразі є деякий розвиток проекту, а ще я опублікував вихідний код серверної частини okerr під відкритою ліцензієютому і вирішив написати на хабр цей невеликий огляд.

Кому це може бути цікаво

Вам це може бути цікаво, якщо ви працюєте невеликою командою або взагалі один. У вас немає моніторингу і ви не впевнені, чи він точно потрібен. Або ж ви пробували якийсь популярний серйозний моніторинг для великих хлопчиків, але для вас він якось не злетів, або працює в майже дефолтної конфігурації і не сильно змінив ваше життя. А ще — якщо ви точно не плануєте виділяти цілого співробітника (а то й відділу) на те, щоб той хоча б пару годин на день моніторив у дашборд моніторингу або налаштовував його.

Чим незвичайний okerr

Далі я покажу цікаві особливості Окер, які відрізняють його від деяких інших моніторингів.

Okerr – це гібридний моніторинг

При внутрішньому моніторингу на машинах, що спостерігаються, крутиться «агент», який передає дані на сервер моніторингу (наприклад, вільне місце на дисках). При зовнішньому — сервер мережі виконує перевірки (наприклад, ping або доступність вебсайту). Кожен підхід має свої обмеження. Okerr використовує обидва варіанти. Перевірки всередині серверів виконуються дуже легким (30Kb) агентом або вашими власними скриптами та додатками, а мережеві через сенсори okerr в різних країнах.

okerr - це не просто софт, але ще й сервіс

Серверна частина будь-якого моніторингу – штука велика та складна, її складно ставити та налаштовувати, вона потребує ресурсів. З okerr ви можете поставити свій власний сервер моніторингу (він безкоштовний та opensource), а можна просто використовувати лише клієнтську частину та користуватися сервісом нашого сервера. Теж безкоштовно.

Якщо моніторинг дозволяє компенсувати, прикрити брак надійності у серверів і додатків, виникає філософське питання — хто вартує стражника? Як моніторинг повідомить про проблему, якщо він сам «помер» з якоїсь причини, окремо або разом з іншими вашими ресурсами (наприклад, впав канал у дата-центр)? При використанні зовнішнього сервісу okerr — ця проблема вирішується — ви отримаєте алерт навіть якщо весь дата-центр з вашими серверами буде знеструмлений або атакуватиметься зомбі.

Звичайно, є ризик, що сервер okerr сам буде недоступний, це так (як відомо, 90% надійності виходять завжди просто і «безкоштовно», 99% — з мінімумом зусиль, і кожна наступна дев'яточка експоненційно складніше). Але, по-перше, шанси цього нижчі, а по-друге, проблема може виявитися непоміченою тільки якщо вона збігається в часі з проблемами на наших серверах. Якщо у нас надійність 99.9%, і у вас 99.9% (не надто високі числа), то шанс непоміченого збою - 0.1% від 0.1% = 0.0001%. Додати собі три дев'ятки до надійності майже без зусиль і без витрат – це дуже непогано!

Ще одна перевага моніторингу як сервісу — хостинг-провайдер або веб-студія може встановити сервер okerr і надавати доступ клієнтам як платну або безкоштовну додаткову послугу. У ваших конкурентів просто хостинг та сайти – а у вас надійний хостинг із моніторингом.

Okerr – це про індикатори

Індикатор – це «лампочка». У нього два основні стани – зелений (OK) або червоний (ERR). У проекті — безліч згрупованих (наприклад, серверів) індикаторів. На головній сторінці проекту ви відразу бачите, чи у вас все зелене (і можна закривати), чи щось горить червоненьким і потрібно виправляти. При переході між цими станами надсилається оповіщення. Раз на добу коли налаштуєте - надсилається зведення за проектом.

Кожен індикатор okerr має вбудовані умови, якими він змінює стан (у Zabbix це називається trigger). Наприклад, load average має бути не більше 2 (звісно ж, це налаштовується). І для кожної внутрішньої перевірки (load average, disk free, …) є watchdog. Якщо з якихось причин ми не отримали успішного підтвердження у призначений час — реєструється помилка та надсилається алерт.

Звичайна схема роботи у нас - ранкова перевірка пошти, там серед інших листів дивимося зведення (її час призначаємо на початок роботи). Якщо в ній все окей займаємося іншими важливими справами (але можемо для надійності швидко глянути в дашборд окерра, переконатися, що і в цю хвилину все зелене). Якщо приходить алерт – реагуємо.

Звичайно, є можливість просто тримати «інформаційні» індикатори (щоб бачити картину мережі з моніторингу), але все зроблено, щоб просто, легко та швидко робити індикатори саме для автоматичного спостереження та розсилки алертів.

Сенс, заради якого ви налаштовуєте okerr — в алертах, щоб ви могли за хвилину створити індикатор, він може бути рік би «спав», просто приймав апдейти, а коли через рік у вас щось поламається — він загорівся і вислав алерт . Хвилина, яку витратили одного разу на створення індикатора, окупилася, ви дізналися про проблему одразу, найперше. Можливо, що й полагодили, до того, як хтось помітив. Швидко підняте не вважається впалим!

Безпека

Було б прикро, якщо ви ставите моніторинг заради підвищення надійності, а в результаті вас через нього атакують по мережі, і мережевих уразливостей у різних засобів моніторингу досить багато (Zabbix, Нагіос).

Агент (okerrmod із пакету okerrupdate), що працює на системі - це не мережевий сервер, а клієнт. Тому на сервері, що спостерігається, немає додаткових відкритих портів, клієнт легко працює за файрволом або NAT'ом і його дуже складно (я б сказав «неможливо») зламати по мережі, оскільки він в принципі не слухає мережевий сокет.

Повне охоплення моніторингу

Зараз у нас правило - ми дізнаємося про всі технічні проблеми з okerr. Якщо раптом правило порушилося (okerr не попередив про її швидкий наступ (якщо це можливо) або про те, що вона вже настала), ми додаємо перевірки в okerr.

Зовнішні перевірки

Досить типовий набір:

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

Внутрішні перевірки

Також досить типовий набір (але легко розширюється).

df (вільне місце на дисках)
навантаження середня
opentcp (відкриті слухаючі TCP сокети - повідомить, якщо щось запустилося або впало)
uptime - просто uptime сервер. Повідомить, якщо він змінився вниз (тобто сервер перевантажився)
клієнт_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 щоб денний індикатор був OK, а після 20:00 достатньо, щоб нічний індикатор був ОК.

Інший приклад використання логічного індикатора - це ескалація. Наприклад, менеджер проекту відписується від алертів (йому це нема чого, адміни повинні реагувати на звичайні проблеми), але підписується на логічний індикатор, який червоніє, якщо будь-який індикатор у проекті не виправлений за відведений час.

Ще є можливість призначити дозволений час для робіт, наприклад, з 3 до 5 ранку. Нас не хвилює, якщо сервери та сайти «падають» у цей час. Але о 5:00 вони мають працювати. Якщо не працюють у будь-який інший час – алерт. Також логічний індикатор дозволяє враховувати резервування серверів. Якщо у вас 5 веб-серверів, адміни можуть вимикати 1-2 сервери в будь-який час. Але якщо в бою буде менше 3 із 5 серверів – буде алерт.

Приклади вище - це не функції окер, не якісь фічі, які потрібно активувати та налаштувати. Усіх цих функцій в океррі немає, натомість є логічний модуль, який дозволяє реалізувати і цей функціонал (Приблизно, як у мові програмування — якщо у нас є арифметичні оператори, то нам не потрібна від мови особлива функція розрахунку 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
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

Він оновлює відразу кілька індикаторів (розділені порожнім рядком), при необхідності створить їх, вказує деталі перевірки та тег, яким у дашборді легко знайти потрібні індикатори.

Є Telegram bot @OkerrBot. Вам не потрібно захаращувати телефон окремими програмами (сам не люблю, що для П'ятірочки потрібна одна програма з картою, для Стрічки інша, для МТС третя, і так для всіх-всіх). Один телеграм – достатньо. Через телеграм можна і отримувати алерти відразу ж і перевіряти статус проекту і віддати команду на перевірку перевірку всіх проблемних індикаторів. Вийшли з театру/літака, дві години не тримали руку на пульсі, увімкнули тіл, натиснули одну кнопку в чат-боті, і переконалися, що все гаразд.

Сторінки статусу

У наш час, сторінки статусу — вже майже must have для будь-якого бізнесу, який має IT, відповідальне ставлення до надійності і який шанобливо ставиться до своїх клієнтів/користувачів.

Уявіть ситуацію – користувач хоче щось зробити, подивитися інформацію чи оформити замовлення, і щось не працює. Він не знає в чому справа, на чиїй стороні проблема і коли вона вирішиться. Чи може у вашої фірми просто неробочий сайт? Чи ламалося півроку тому, і полагодиться через два роки? А холодильник треба купити вже зараз, він уже в кошику... І зовсім інша справа, коли людина бачить, що у вас щось не в порядку (хоча б ясно, що проблема не на її боці), що проблема виявлена, що ви над нею вже працюєте, і можливо навіть написали приблизний час виправлення. Користувач може підписатися та отримати на пошту повідомлення, коли проблема буде виправлена і можна буде зробити те, що він хотів (купити холодильник).

Проблеми, даунтайм – бувають у всіх. Але користувачі та партнери більше довіряють тим, хто більш прозорий та відповідально підходить до цього.

Ось огляд 10 інших проектів, які дозволяють робити сторінки статусу. Ось приклади, як виглядають ці сторінки у проектів Python и Dropbox. Сторінка статусу okerr.

Failover

Щоб не робити цю статтю ще більше, я ще раз пошлюся на свою попередню статтю. Простий failover для вебсайту . Якщо ви можете зробити дублюючий сервер, то з використанням failover'а, у вас в принципі не буде довгого даунтайму — як тільки проблема буде виявлена, користувачі автоматично перенаправляться на працюючий резервний сервер. І мені здається, це дуже цікава, яскрава функція, яка мало де є.

Низькі системні вимоги

Для серверів okerr ми використовуємо машини з RAM від 2Gb. Для мережевих сенсорів навіть 512Mb достатньо. Клієнтська частина взагалі майже нуль. (Пакет okerrupdate важить 26 Kb, але вимагає Python3 та стандартних бібліотек). Клієнт запускається з крон скрипта, тому має нульове постійне споживання пам'яті. Серед машин, що спостерігаються, у нас є сенсори (супер-дешеві VPSки з 512Mb RAM) і Raspberry Pi. Можна навіть без клієнтської частини відправляти апдейти через curl! (див. нижче)

З огляду на це — okerr, напевно, найбільш безкоштовна система моніторингу з наявних, адже навіть щоб використовувати іншу безкоштовну опен-сорсну систему на кшталт Zabbix або Nagios, потрібно виділити їй ресурси (сервер), а це вже гроші. Крім того - все ж таки потрібне деяке обслуговування сервера. З okerr - цю частину можна прибрати. А можна і не прибирати і використовувати власний сервер - дивлячись, як вам більше подобається.

API та інтеграція у власне ПЗ

Проста та відкрита архітектура. У okerr є досить простий APIз яким легко працювати. Чи потрібно створити 1000 індикаторів? Один шелл-скрипт у 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 сам за собою стежить, і проблеми майже в будь-якому модулі - будуть виявлені і згенерують сповіщення про проблему. (А на випадок цього «майже» вони перехресно перевіряються з іншого сервера)

Ось такий код (спрощено) у нашому телеграм-боті:

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.

Як нам допомагає okerr

Okerr змінив наше життя. Справді. Можливо, інша система моніторингу теж могла б, але з okerr працювати нам легко і просто і в ньому є всі функції, які нам були потрібні (що не було — ми дописали). До речі, якщо якоїсь фічі немає — спитайте, і я їх додам (не обіцяю, але мені хочеться, щоб okerr був найкращою системою моніторингу для малих-середніх проектів). Або, ще краще, додайте самі – це просто.

У нас вдалося жити за принципом «про всі проблеми дізнатися з окерра». Якщо раптом виникла проблема, про яку ми дізналися не від okerr, ми додаємо перевірку в okerr. (В даному випадку під «ми» - я розумію нас як користувачів системи, а не співрозробників). Спочатку це було часто, але зараз стало дуже рідко.

моніторинг

Через okerr ми стежимо за розмірами ліг на всіх серверах. Вдумливо читати очима кожен рядок лога — звичайно, неможливо, але просто стеження за швидкістю зростання — вже багато дає. Через це ми виявляли і розсилку спаму і брутфорс перебір паролів, і коли якісь із додатків «сходять з розуму», у них щось не виходить і вони повторюють знову і знову (щоразу додаючи пару рядків у балку).

Сертифікати SSL. Майже одразу після запуску Дозволяє шифрувати наш замовник почав надавати своїм клієнтам безкоштовні 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 як і всі сервіси амазону — трохи гальмівний, тому завжди був лаг, але все-таки вдалося хоча б приблизно вловити зв'язок між проблемою, і скриптами, які її викликають (зробили перевірку, приляпали її до окерру, і перевіряли відразу по отриманні алерту).

Цікавий випадок у скарбничку зовсім недавно додав великий та дорогий європейський хостер, яким користується наш замовник. Раптом раптом з радарів зникли ВСІ наші сервери! Спочатку замовник сам «ручками» (швидше за окерра!) зауважив, що сайт з яким він працював — не відкривається і зробив тикет про це. Але поліг не один сайт, а взагалі все! (Наташа, ми всі впустили!). Тут і Okerr почав слати довгі онучі з усіма індикаторами, які в нього спалахнули. Паніка-паніка, бігаємо колами (а що ще робити?). Потім усе підвелося. Виявляється, у дата-центрі були регламентні роботи (раз на багато років) і нас, звичайно ж, мали попередити. Але ось запердика сталася в них якась і не попередили. Ну, інфарктом більше, інфарктом менше. Але після відновлення всього — треба ж все перевіряти ще раз! Я не уявляю, як це робив би руками. Okerr за кілька хвилин все відтестував. Виявилося, що більшість серверів просто була тимчасово недоступна, але працювала. Деякі перевантажилися, але теж встали як слід. З усіх втрат ми втратили два бекапи, які по крону мали створюватися і завантажитися в той час, поки йшов цей повний бананас. Я навіть не став їх створювати, просто через добу прилетіли алерти, що всі ОК, бекапи з'явилися. Мені цей приклад дуже подобається, тому що 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. Ми використовуємо безкоштовний свіжі роботи для сапорту. Ні для чого цього не потрібно оплачувати сервери, не потрібно завантажувати та налаштовувати та вирішувати різні проблеми з експлуатацією. Кожен новий проект, кожна команда — одразу має і пошту, і репозиторії, і CRM. І все це дуже якісне та безкоштовно і відразу. Ми хочемо, щоб для моніторингу було так само — невеликі компанії та проекти могли б безкоштовно використовувати okerr і навіть на етапі народження та зростання мати надійність як у дорослих серйозних проектів.

Джерело: habr.com

Огляд гібридної системи моніторингу Okerr