Одно отключение света, 445 тревог и камера, которая кричала «волк»

Большой объект: несколько корпусов, больше 300 устройств в сети — коммутаторы, камеры, точки доступа, телефоны. Всё это под присмотром Uptime Kuma, который пингует каждое устройство и пишет в журнал, когда оно пропало и когда вернулось.

Задача пришла простая: посчитать, сколько раз и надолго отключалось электричество. Нужны были цифры для разговора с теми, кто отвечает за электроснабжение. Ответ оказался неожиданным: отключение было одно. А вот всё остальное в журнале рассказало гораздо больше, чем у нас спрашивали.

Достаём данные

У Uptime Kuma нет кнопки «выгрузить историю», но всё лежит в обычной базе SQLite внутри контейнера. Чтобы копия была целостной, контейнер останавливаем на несколько секунд, иначе часть свежих данных останется в WAL-файле:

docker stop uptime-kuma
docker cp uptime-kuma:/app/data/kuma.db ~/kuma.db
docker start uptime-kuma
sudo apt install -y sqlite3

Сначала смотрим, за какой период вообще есть история:

SELECT COUNT(*) AS beats, MIN(time) AS oldest, MAX(time) AS newest FROM heartbeat;
SELECT COUNT(*) AS events FROM heartbeat WHERE important = 1;

Первая находка: история хранилась только с 9 апреля. Всё, что раньше, удалилось по настройке срока хранения. Мы бы и не узнали, если бы не посмотрели.

Как отличить «пропал свет» от «пропала камера»

Одно упавшее устройство — это проблема устройства. Если разом легли пятьдесят камер и три коммутатора — это питание. Поэтому ищем пятиминутные окна, в которых одновременно упало много устройств:

SELECT datetime((strftime('%s', time) / 300) * 300, 'unixepoch', 'localtime') AS window,
       COUNT(DISTINCT monitor_id) AS devices_down
FROM heartbeat
WHERE important = 1 AND status = 0
GROUP BY window
HAVING devices_down >= 15
ORDER BY window;

Порог в 15 устройств подбирается по факту: попробуйте 10, 30, 50 и посмотрите, где картина перестаёт меняться.

Что показали данные

Отключение было одно, и прошло оно двумя волнами. В 12:34:14 за восемь секунд легли все 12 коммутаторов первого корпуса. Второй корпус продержался ещё 1 час 25 минут и упал в 13:59. Восстановились оба одновременно, в 15:04.

Эти 85 минут — самое ценное во всех данных. Они значат, что во втором корпусе стоит ИБП, и его реальный запас под реальной нагрузкой — ровно полтора часа без пяти минут. Ни один паспорт и ни один расчёт не скажет этого точнее.

Третий корпус отключения не заметил вообще. Ни один из 11 коммутаторов и 15 точек доступа не упал, как и серверы с системой оповещения. Значит, рабочая схема резервирования на объекте уже есть, просто не везде. Это очень удобный аргумент: не «надо купить ИБП», а «сделайте в первом корпусе так же, как уже сделано в третьем».

Камера, которая кричала «волк». Из 445 событий «устройство недоступно» за весь период 156 принадлежали одной-единственной камере. Она флапала: пропадала и возвращалась по несколько раз в день. Найти таких легко:

SELECT m.name, COUNT(*) AS downs
FROM heartbeat h JOIN monitor m ON m.id = h.monitor_id
WHERE h.important = 1 AND h.status = 0
GROUP BY h.monitor_id
ORDER BY downs DESC
LIMIT 25;

Одна такая камера обесценивает всю систему уведомлений. Когда телефон пищит по двадцать раз на дню из-за одного и того же устройства, люди перестают смотреть уведомления. И пропускают то единственное, которое было важным.

Мелочи, которые всплыли попутно. Два монитора с разными названиями пинговали один и тот же адрес. Отдельная стойка регулярно падала целиком, независимо от общих отключений, — это уже её собственное питание. И пять устройств числились «недоступными» больше месяца: их никто не чинил, потому что к красным строчкам в мониторинге все привыкли.

Что мы предложили

Шесть конкретных пунктов вместо общих слов: резервирование первого корпуса по образцу третьего, проверка батарей ИБП второго корпуса, замена или отключение флапающей камеры, проверка питания отдельной стойки, удаление дублей и «вечных мертвецов» из мониторинга. И увеличение срока хранения истории, плюс регулярная выгрузка базы в архив, чтобы следующий такой отчёт можно было сделать за год, а не за четыре месяца:

# /etc/cron.d/kuma-backup — каждую ночь копия базы в архив
0 4 * * * root docker stop uptime-kuma && docker cp uptime-kuma:/app/data/kuma.db /backup/kuma-$(date +\%F).db; docker start uptime-kuma

Похожая история с другим объектом

Похожий разбор мы делали по архиву Zabbix для другого заказчика: 230 простоев за полгода, 22 из них дольше двух часов. Цифры выглядели как «у нас постоянно пропадает свет». Но больше половины суммарного простоя приходилось на ночи и выходные, когда после короткого сбоя оборудование просто некому было включить обратно. Решение оказалось не в генераторе, а в реле с автоматическим перезапуском, которое стоит в сотни раз дешевле.

Что из этого вынести

Мониторинг — это не только красные лампочки. Это ещё и архив, в котором записана правда о вашей инфраструктуре: какой ИБП реально держит, какое устройство врёт, какой корпус уже защищён. Иногда один запрос к базе экономит закупку, которую все считали неизбежной. Настройка мониторинга и такие разборы входят в наше абонентское обслуживание.