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

    Мониторинг работы оборудования и ключевого ПО — это азы системного администрирования. Но все мы постигаем их по-разному. За 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
    • 13.1k
    • 9
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 9

      0
      Quis custodiet ipsos custodes? Кто будет мониторить мониторинг?

      Самый важный вопрос о жизни, Вселенной и вообще)
        +1
        Это же очевидно: мониторинги как маркеры — два могут мониторить вообще всё.
          +1
          и теперь вопрос ниже пояса, что делать, если мониторинг живет на той же инфраструктуре?
            +1
            Очевидно, что два мониторинга должны быть независимы, как и каналы доставки алармов.
              0
              считать потенциальные потери в случае Х или пилить «микромониторинг» на сервисе «сбоку»
                0
                Добавить оповещение «В багдаде все спокойно». Естественно по СМС автору системы. А он уже пусть настраивает телефон на алерты в будильнике, если пропущено такое сообщение.
            +1
            При падении туннеля генерируется куча алертов о недоступности серверов, пришлось настраивать зависимости.

            Как знакомо. Я немного отошел от администрирования, но помню использовал заббикс 2.4 — там зависимости весьма примитивны (между триггерами, IIRC). Ситуация у нас похожая видимо — site-to-site vpn, и это была самая большая боль во всем заббиксе, все остальное очень нравилось. В новых версиях что-нибудь сделали с этим? Зависимости на более высоких уровнях?
              0
              да, в основном доставлял нестабильный интернет на одной из площадок. за давностью лет(в районе 2.2-2.4 дело было) уж не помню деталей, обошлись существующим механизмом зависимостей и zabbix-proxy
              0
              У нас в компании есть отдел мониторинга. При возникновении алертов они оповещают отдел поддержки. Далее те, если это прописано в инструкциях, пытаются закрыть алерт. Если же не прописано — отправляют сообщение в общий чат мониторинга в телеграмме, в котором присутствую программисты. И далее программисты уже разбираются с алертом. Если же алерт очень важный (перестал идти трафик от ключевого партнера, например), то тогда уже мониторинг напрямую звонит менеджерам или программистам. На моем опыте это очень редкий случай, буквально пару раз в год.

              Only users with full accounts can post comments. Log in, please.