Що саме відстежує моніторинг
«Сайт відкривається» — це лише найпростіша перевірка. Повноцінний моніторинг дивиться на кілька рівнів одночасно:
- Доступність. Чи відповідає сайт, API, сторінка оплати; чи не закінчується сертифікат і термін реєстрації домену.
- Швидкість. Скільки часу відкриваються ключові сторінки і чи не погіршується цей показник з часом.
- Помилки в коді. Збої, які бачать користувачі: кнопка не спрацювала, оплата повернула помилку, сторінка кабінету не завантажилася.
- Ресурси серверів. Процесор, пам’ять, диск, кількість з’єднань з базою даних, довжина черг фонових завдань.
- Бізнес-показники. Наприклад, якщо за годину в робочий час не надійшло жодного замовлення, це привід перевірити, чи все гаразд.
Кому потрібен моніторинг
Будь-якому сайту, з якого надходять заявки чи продажі, потрібна хоча б базова перевірка доступності й сертифіката. Вона недорога і вже рятує від найнеприємніших сюрпризів.
Глибший моніторинг з відстеженням помилок і ресурсів потрібен інтернет-магазинам, онлайн-сервісам, порталам з особистими кабінетами, мобільним застосункам з власним сервером. Для великих систем він — обов’язкова частина супроводу навантажених проєктів: без даних неможливо зрозуміти, що саме сповільнює роботу.
Якщо у вас невеликий сайт-візитка, зайва складність не потрібна. Ми не пропонуємо налаштовувати десятки графіків там, де достатньо однієї перевірки й сповіщення в Telegram.
Інструменти: від простого до складного
- Зовнішні сервіси перевірки, як-от UptimeRobot. Перевіряють сайт ззовні, швидко налаштовуються, підходять для невеликих проєктів. Але бачать лише те, що бачить відвідувач, без причин.
- Збір помилок через Sentry. Показує конкретні помилки в коді з подробицями, тож розробник одразу бачить, що виправляти.
- Моніторинг інфраструктури на Prometheus і Grafana або Zabbix. Збирає детальні показники серверів і застосунків, дозволяє будувати графіки й бачити тенденції. Потребує налаштування й обслуговування, тому має сенс для середніх і великих проєктів.
- Централізовані журнали. Коли серверів кілька, журнали зручно збирати в одне місце, наприклад з переглядом у Kibana, щоб шукати причину збою, а не ходити по кожному серверу окремо.
Якщо проєкт працює в хмарі, частину задач закривають вбудовані засоби провайдера, і ми використовуємо їх, щоб не дублювати витрати.
Як не потонути в сповіщеннях
Найчастіша проблема моніторингу — не відсутність сповіщень, а їх надлишок. Коли телефон вібрує двадцять разів на добу через дрібниці, люди перестають реагувати, і справжня аварія губиться серед шуму.
Тому ми ділимо сигнали на рівні. Критичні — сайт недоступний, оплата не працює — надходять одразу і будь-коли. Попередження — диск заповнений на три чверті, сторінка почала відкриватися повільніше — потрапляють у робочий канал і розбираються вдень. Дрібниці збираються у зведення, яке переглядаємо періодично.
Що відбувається, коли спрацювала тривога
Сповіщення має сенс лише тоді, коли хтось знає, що з ним робити. Тому разом з налаштуванням ми домовляємося:
- хто отримує сигнал першим і хто підключається, якщо перший не відповів;
- що перевіряти насамперед для кожного типу збою;
- як і коли повідомляти вам, власнику бізнесу, і чи потрібно попередити клієнтів;
- як після відновлення записати причину і що змінити, щоб збій не повторився.
Що підготувати з вашого боку
- перелік сторінок і функцій, без яких бізнес зупиняється: оформлення замовлення, оплата, заявка, вхід у кабінет;
- доступи до сервера, коду або хмарного облікового запису, якщо потрібен глибший моніторинг;
- список людей, які мають отримувати сповіщення, і зручні для них канали;
- інформацію про години пікової активності й плановані роботи, щоб вони не викликали хибних тривог;
- історію останніх збоїв: що ламалося, як довго і як про це дізналися.
Якщо частини даних немає, нічого страшного: базові перевірки можна запустити одразу, а решту додати згодом.
Як ми оцінюємо результат
Моніторинг сам по собі не робить сайт стабільнішим — він робить проблеми помітними. Тому результат оцінюємо так: про збої команда дізнається раніше за клієнтів, час від початку проблеми до її виправлення скорочується, а однакові збої перестають повторюватися.
Ми не обіцяємо, що сайт ніколи не зупиниться. Але з моніторингом ви точно знатимете, скільки часу він працював без перебоїв, і зможете ухвалювати рішення на основі цифр, а не відчуттів.
Типові помилки
- Перевіряти лише головну сторінку, коли зламаною може бути саме оплата чи кошик.
- Надсилати всі сповіщення одній людині, яка може бути у відпустці.
- Розміщувати моніторинг на тому самому сервері, що й сайт: якщо впаде сервер, сповіщення теж не прийде.
- Налаштувати моніторинг і ніколи до нього не повертатися, хоча сайт за цей час суттєво змінився.
Що впливає на вартість
- Кількість систем і перевірок: один сайт чи кілька сервісів, серверів і інтеграцій.
- Глибина: лише доступність чи ще помилки в коді, ресурси, журнали та бізнес-показники.
- Інструменти: готові сервіси з підпискою чи власні системи моніторингу, які потрібно розгорнути й обслуговувати.
- Реагування: лише налаштування сповіщень чи також наше чергування й усунення збоїв.
Часті запитання
Чи можна налаштувати моніторинг без доступу до сервера? Частково. Зовнішні перевірки доступності працюють без доступів, але щоб бачити помилки й ресурси, потрібен доступ до коду або сервера.
Хто реагуватиме на сповіщення? Як домовимося. Можемо лише налаштувати моніторинг для вашої команди, а можемо реагувати самі в межах технічної підтримки.
Чи не сповільнить моніторинг сайт? Ні, якщо налаштувати його правильно. Перевірки й збір показників створюють дуже невелике навантаження порівняно зі звичайними відвідувачами.
Навіщо стежити за бізнес-показниками, якщо сайт відкривається? Бо сайт може відкриватися, а замовлення — не оформлюватися через збій оплати чи доставки. Падіння кількості замовлень до нуля в робочий час часто перший і найнадійніший сигнал такої проблеми.
Чи підійде моніторинг для мобільного застосунку? Так. Відстежуємо сервер, з яким працює застосунок, і збираємо помилки з самого застосунку, щоб бачити збої на конкретних пристроях.
Чому Promodex
Ми не лише налаштовуємо моніторинг, а й самі розробляємо та підтримуємо сайти з 2015 року, тому розуміємо, які сигнали справді важливі для бізнесу, а які — шум. Коли сайт підтримує наша власна команда в Києві, сповіщення отримують ті самі розробники, які потім виправляють помилку, тож задачу не потрібно передавати між різними підрядниками. Моніторинг добре доповнює технічну підтримку сайту і резервне копіювання.
