Усі нотатки

Сайт упав о третій ночі: як я дізнаюсь першим

Моніторинг, який будить, лише коли справді треба. Про дві перевірки поспіль, сертифікати через SNI, 80 % диска й хибну тривогу під час оновлення.

(-_-) zzZ 28 вересня 2026 р. · 3 хв читання DevOpsмоніторингLinux

Найгірший спосіб дізнатися, що сайт не працює, — від клієнта. Другий найгірший — від бота, який щоп’ять хвилин кричить «ВСЕ ПРОПАЛО», коли нічого не пропало. Після третьої хибної тривоги ти вимикаєш звук, а на четвертій, справжній, спокійно спиш .

Моніторинг мрії
Пише лише тоді, коли щось зламалось. Одне повідомлення. Зрозуміле.
Моніторинг із життя
«Служба reviactyl-queue: activating». Бо я щойно оновив панель і вона перезапускається. Дякую, я знаю.

Цю другу панель я не вигадав: саме це показала перша ж пробна перевірка, поки я оновлював кабінет. Ось як тепер влаштовані сповіщення про сервер bebb.be.

Що перевіряти

Раз на п’ять хвилин, без root-доступу:

  • Диски — понад 80 % уже привід подивитись, 100 % — привід сумувати.
  • Служби — nginx, бази, Redis, S3-сховище, черги, поштовий релей: systemctl is-active для кожної.
  • Сертифікати — не файли, а те, що справді віддає nginx.
  • Черга — завдання, що провалились за останню годину.
  • Бекапи в S3 — чи вдалося останнє відправлення кожної політики.

Сертифікат — через SNI, а не з диска

Можна читати дату з файлу сертифіката. Але ламається зазвичай інше: nginx віддає не той сертифікат, не перечитав новий, домен потрапив не в той vhost. Тому я питаю nginx так само, як браузер:

$ctx = stream_context_create(['ssl' => ['capture_peer_cert' => true, 'peer_name' => $host,
    'SNI_enabled' => true, 'verify_peer' => false]]);
$s = stream_socket_client('ssl://127.0.0.1:443', $errno, $err, 8, STREAM_CLIENT_CONNECT, $ctx);
$cert = stream_context_get_params($s)['options']['ssl']['peer_certificate'];
$days = (openssl_x509_parse($cert)['validTo_time_t'] - time()) / 86400;   // < 14 — пишемо

Дві перевірки поспіль

Головний трюк проти хибних тривог: проблема має протриматись дві перевірки поспіль (5–10 хвилин), і лише тоді надходить сповіщення. Перезапуск служби під час оновлення триває секунди, і його ніхто не помітить.

$st['seen']++;
if ($st['notified'] === null && $st['seen'] >= 2) { $new[] = $text; $st['notified'] = $now; }
elseif ($st['notified'] !== null && $now - $st['notified'] >= 6 * 3600) { $still[] = $text; }  // нагадування

І ще дві дрібниці, що бережуть нерви:

  • «Знову гаразд» — лише про те, про що вже повідомляли. Інакше після кожного перезапуску приходило б «проблема зникла» про проблему, якої ти не бачив.
  • Нагадування раз на 6 годин, а не щоп’ять хвилин. Незакрита проблема не зникне з пам’яті, але й телефон не розрядиться.

Куди надсилати

У два канали: пошта й Telegram. Пошта — для історії, Telegram — щоб прочитати за секунду. Одне повідомлення групує все: «Нові проблеми», «Досі не вирішено», «Знову гаразд». Жодних двадцяти окремих сповіщень підряд.

А клієнтські сайти?

Для сайтів і ботів клієнтів окремий моніторинг щохвилини: сайт не відповідає двічі поспіль, бот перезапускається по колу, пам’ять тримається біля ліміту, сертифікат спливає за тиждень. Сповіщення одразу отримує клієнт — поштою й у Telegram, — а графіки видно в кабінеті .

Підсумок

  • Перевіряйте те, що бачить користувач (сертифікат від nginx), а не те, що лежить на диску.
  • Дві перевірки поспіль — і хибних тривог майже немає.
  • Групуйте, нагадуйте рідко, повідомляйте про відновлення.
  • І спіть спокійно. Для цього все й робилось.

Маєте ідею? Давайте поговоримо

Опишіть задачу кількома реченнями — відповім з питаннями й першою оцінкою.