DevOps
Server Administration
System administration
Data storage
October 4 2017

Мониторинг головного мозга

Мониторинг работы оборудования и ключевого ПО — это азы системного администрирования. Но все мы постигаем их по-разному. За 10 лет работы в IT моё отношение к мониторингу прошло через три стадии:


Отрицание. Ничего не мониторить, пользователи сами сообщат, когда у них возникнут проблемы.
Гнев. Мониторить всё, что можно и нельзя, оповещать всех, включая не очень заинтересованных лиц, что на веб-сервере в течение 30 секунд нагрузка на CPU была 95%.
Смирение. Бизнесу пофиг на процессор/память/диски. Его больше интересует, лучше или хуже стало после изменений в инфраструктуре. Надо работать на упреждение.



Под катом — подробности эволюции моего отношения.


Отрицание


Всё началось давным-давно, в далёкой галактике. Я учился в университете и работал в двух местах «ты ж программистом»:


  • Торгово-производственная компания: три сервера, десять пользователей. На этих фотографиях вы видите серверную.
  • Кафедра государственного университета: четыре сервера, сорок рабочих мест.


В то время я даже не подозревал о существовании такой штуки, как мониторинг. Я искренне считал, что если что-то сломается, то можно просто броситься грудью на амбразуру и героически решить проблемы.


Моё отношение к мониторингу в то время можно охарактеризовать так:


  • Пользователи сами сообщат, когда что-то сломается.Мы сами постоянно работаем с сайтом, поэтому увидим, когда он сломался.На сервере перегружен процессор? Мне какое дело, программисты что-то там написали.

К счастью, этот период продлился недолго — я начал подозревать, что здесь что-то не так, и бывает лучше.


Гнев


Под влиянием получаемого опыта начало меняться и моё видение мониторинга. Это процесс совпал со сменой работ. Уйдя из университета и производственной компании, я начал работать в не больших outstaffing фирмах:


  • В первой компании было три офиса, 100 пользователей, одна стойка в дата-центре и два системных администратора. Серверный парк состоял из 100 машин, расположенных в 5000 км от меня, а на хостинге было 1200 клиентов.
  • Во второй компании было 400 серверов, до которых всего-то 12000 км, два корпоративных сайта и один системный администратор.


К тому времени уже считал, что:


  • Мониторить нужно всё подряд. В том числе и то, что никому не нужно. Все события являются важными, и информацию о них нужно рассылать максимальному количеству человек. Включая начальство. По SMS. Ночью. Процессор на сервере в течение 35 секунд был загружен на 95%? Нет времени объяснять, необходимо срочно слать SMS!

В то же время активно развивался и преображался инструментарий. Изначально была пачка скриптов, контролирующих всевозможные метрики (свободное место, количество доступных обновлений, результат работы бэкапов и так далее), а также сторонние сервисы Red Alert, Lazy Farmer (in-house разработка — попытка заменить сервис проверки сайтов).


В такой конфигурации система мониторинга существовала около года, но за это время выявилось много недостатков:


  • Многочисленные задержки в работе серверов из-за работы скриптов.
  • Неизвестна утилизация ресурсов.
  • Сложно найти источники проблем.

Встал вопрос, как упростить себе жизнь. Рассматривал варианты с Dude/Nagios/Zabbix. Основным критерием при выборе стала скорость развертывания, и выбор пал на Zabbix.


В нём на мониторинг ставили всё, до чего дотягивались руки:


  • Количествво пользователей, подключенных к WiFi.
  • Количество напечатанных на принтере страниц.
  • Свободную память на маршрутизаторе.
  • Количество VPN туннелей на маршрутизаторе.
  • Температуру на серверах.
  • Открытость крышки сервера.
  • Загруженность сетевых интерфейсов коммутаторов.
  • … и многое другое.

Отдельно хочу упомянуть про особенности внедрения и работы с Zabbix:


  1. Серверы далеко, а метрик много. Когда начали появляться пропуски, внедрили Zabbix proxy.
  2. При падении туннеля генерируется куча алертов о недоступности серверов, пришлось настраивать зависимости.
  3. Мы автоматизировали однотипные действия при алертах: сначала система пробует починить самостоятельно (к примеру, почистить диск), и только в случае неудачи шлёт алерт. Чтобы уменьшить время реакции на алерт, мы настроили рассылку SMS.
  4. Чтобы алерты не сыпались круглые сутки в виде SMS, не надо настраивать оповещения о том, что на сервере в течение 5 секунд CPU грузился на 100%.
  5. При мониторинге сложных метрик из-за ресурсоёмкости процесса терялась часть значений. Хотя данные отправлялись серверу мониторинга, он не успевал всё регистрировать.
  6. У Sphinx есть куча сервисов, состав которых может меняться. Новые серверы автоматически обнаруживаются и ставятся на мониторинг. Бывают ситуации, когда вебсервер запущен, но пользователь видит фигу вместо страницы. В подобных случаях мы прогоняли пользовательские сценарии на вебе, а в случае проблем система слала алерт.
  7. Обычно заказчики хотят, что бы все задачи/проблемы отображались в одном месте, поэтому мы создавали задачу при возникновении критичного для бизнес-процессов события.
  8. Сбор необработанных исключений долог и нуден, поэтому при возникновении события мы обрабатывали его в eventlog и создавали задачу.
  9. Заказчики не читают писем, поэтому мы писали им в Skype (zabbix2skype).
  10. Quis custodiet ipsos custodes? Кто будет мониторить мониторинг? Я так и не нашёл для себя ответа.

Смирение


Спустя несколько лет я пришёл к смирению. Опять же, этот период отчасти совпал со сменой места работы. Три ЦОДа, тысячи серверов, тысячи сотрудников, офисы по всей РФ, и не только.


Я понял для себя, что бизнес не интересует нагрузка на CPU и прочие технические подробности. Владельцы и управленцы мыслят другими категориями: время простоя/информационная система/потеря прибыли…



Zabbix мне нравился, но я увидел, что существуют другие системы (сторонние решения, сильно доработанные напильником, или самописные), которые плотно интегрируются с бизнесом заказчика.


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


  1. Нельзя всё удержать в голове, должно быть хранилище знаний об инфраструктуре (кто ответственен за сервер, где что находится, и так далее).Необходимо упрощать и унифициовать настройку мониторинга (SNMP вместо агентов).
  2. Важно, чтобы у системы мониторинга был дружелюбный интерфейс, позволяющий разобраться в ситуации даже не айтишникам.
  3. Если информационная система не работает, это ещё не повод поднимать всех по тревоге в 3 ночи. Необходимо оговаривать с заказчиком допустимую продолжительность простоя и реакции.
  4. Серебряной пули не существует — надо идти на компромиссы при выборе метрик для отслеживания, при создании правил уведомления, при автоматизации типовых действий и так далее.

Так, вкратце, эволюционировали представления о мониторинге как таковом, его задачах и способах реализации. Конечно, огромное влияние на этот процесс оказали условия, сложившиеся в компаниях, где я работал, и люди, трудившиеся вместе со мной.


UPD: English version

+19
12.4k 63
Comments 9
Top of the day