ІТ-моніторинг і доступність: Nagios, Zabbix та моніторинг аптайму

Коротко: Моніторинг безперервно перевіряє, чи доступні сервіси й сервери та чи справні вони, і сповіщає про проблеми; доступність вимірюється у відсотках і керується через пороги й тривоги.

Докладніше: «Ми дізнаємося, коли дзвонять клієнти» — запізно. Моніторинг виявляє збої та тенденції (диск заповнюється, бракує пам’яті, спливає сертифікат) до виникнення шкоди.

Подробиці

Що відстежується

• Доступність (ping/HTTP/порт TCP), час відгуку.
• Системні значення: CPU, RAM, місце на диску, введення-виведення, пропускна здатність мережі, температура.
• Сервіси/процеси, база даних, черги, журнали/частка помилок.
• Сертифікати (строк дії), домен, резервні копії (чи запускаються?), ДБЖ, принтери/тонер (SNMP).
• Застосунок (APM): запити, помилки, затримки, бізнес-метрики (замовлень за хвилину).
• Синтетичний моніторинг: імітований користувач проходить вхід/купівлю.

Інструменти

• Nagios/Icinga/Checkmk: класичний моніторинг на основі перевірок.
• Zabbix: агент, SNMP, автовиявлення, дашборди.
• Prometheus + Grafana: метрики, Alertmanager (cloud-native).
• Uptime Kuma (self-hosted, простий), UptimeRobot, Better Stack, Pingdom: зовнішні HTTP-перевірки, сторінки статусу.
• ELK/Loki (журнали), Sentry (помилки), OpenTelemetry (траси).
• Сторінка статусу (як /status) чесно інформує користувачів про збої.

Тривоги та доступність

• Пороги з рівнями попередження (80 %) і критично (95 %); гістерезис і повторні спроби (сповіщати лише після 3 збоїв) проти хибних тривог.
• Уникайте втоми від сповіщень: лише ті тривоги, що потребують дій, пріоритети, графік чергувань, runbook (що робити за тривоги X?).
• Канали: електронна пошта, чат, push, SMS, телефон для критичних.
• Доступність = (загальний час − простій) / загальний час; 99,9 % ≈ 43 хв простою на місяць; задавайте SLO/SLA; бюджет помилок.
• Чотири золоті сигнали: затримка, трафік, помилки, насичення.

Початок та іспит

• Почніть із малого: Uptime Kuma для сайтів + сертифікат + тривога за місцем на диску; сповіщення на телефон.
• Аналіз першопричин: дашборд + журнали + історія (що змінилося? деплой?).
• Планування місткості за тенденціями.
• Конфіденційність: журнали можуть містити персональні дані (IP), обмежуйте строк зберігання.
• Підтримання: тримайте перевірки актуальними, тестуйте тривоги, моніторте сам моніторинг (dead man’s switch).
• IHK: розрахувати доступність, пояснити терміни моніторингу (SNMP, агент, polling і trap, поріг).

Див. також: Prometheus і метрики, Дашборди в Grafana, SNMP, ІТ-планування на випадок надзвичайних ситуацій