2. О компании QIWI*
Kazakhstan
177,000+ терминалов и точек
приема платежей
17,3+ млн. виртуальных кошельков
*По данным QIWI plc за 1 квартал 2015 года
3.
4.
5. • Масштабируемость
• Функция discovery
• Инвентаризация
• Простота кастомизации
• Поддержка инфраструктурных
проверок из коробки
• Клонирование элементов
6. С чего начали
1.Установка сервера
2.Добавление хостов и
авторегистрация
3.Работа над ошибками
4.Составление плана
7. План (что сделано)
1.Перенос отдельных метрик
и orabbix
2.Уведомления и jira
3.Настройка авторизации
4.Шаблоны и полезность LLD
8. План (что осталось)
5.Шаблоны по сервисам
6.Перенос специфичных
бизнес метрик
7.Отказоустойчивость
8.Группировка узлов сети по
сервисам
9.Реализация baseline в
триггерах
Как-то перед Новым годом, на собрании нашего подразделения, обсуждали текущие проблемы и планы на будущее.
Одной из тем была "проблемы мониторинга". Текущая система мониторинга (исторически сложившийся нагиос) в текущем его исполнении, уже порядком поднадоел.
Высокое LA, частенько флапающие статусы проверок, тормозащий вэб. А так же желание навести порядок в мониторинге, так как от некоторых костылей можно избавиться, плюс увеличивающееся число заявок на постановку на мониторинг.
Высокое LA, частенько флапающие статусы проверок, тормозащий вэб. А так же желание навести порядок в мониторинге, так как от некоторых костылей можно избавиться, плюс увеличивающееся число заявок на постановку на мониторинг.
Короче говоря пришли к мысли: тут не исправить уже ничего, Господь, жги!
Из очевидных плюсов: масштабируемость (думаю тут и так все понятно), функция discovery (избавляемся от необходимости добавлять все вручную), мониторинг через агентов (избавляемся от необходимости ходить на хосты по ssh), кастомизация (), поддержка инфраструктурных проверок из коробки.
Так же стоит отметить функцию "клонирования" элементов данных и прочего, позволяющая в пару кликов размножить элементы мониторинга. Приходится часто сталкиваться с этим при заведении новых серверов в мониторинг и уже пальцы натерты от ctrl+C/ctrl+V.
Поскольку мы впервые столкнулись с использованием zabbix, мы как непосвященные пошли таким путем.
Про установку сервера, думаю, нет смысла рассказывать, так как проблем тут обычно не бывает.
На виртуалку раскатили заббикс и начали с добавления хостов из нагиос. Вручную. Epic fail.
Потратили на это много времени, и в дальнейшем обнаружили, что существует "Авторегистрация". В общем, ощутимо бы сэкономили время.
После этого добавили правила авторегистрации для unix и windows серверов, а для всего остального правила обнаружения.
Единственная придирка к обнаружению - негде посмотреть прогресс выполнения.
После этого было решено составить план переезда.
Первым пунктом была просьба от одного подразделения, перенести их сенсоры в заббикс. Чтобы уж сильно кардинально не отходить от привычного использования конфигов, для sql запросов мы прикрутили orabbix. Для нас он показался удобнее чем встроенная в заббикс поддержка запросов в базы. Отдельный информативный лог, привычные конфиги. Плюс по принципу работы, orabbix похож на самописную sql шлюз, который мы используем в nagios.
После этого сделали систему уведомлений.
От стандарной функции рассылки писем в заббикс отказался в пользу скрипта, чтобы были возможности кастомизации. По смскам, адаптировали скрипт из нагиос рассылающий через смс-агрегатора. С джирой подружили через перловый модуль JIRA::Client::Automated.
Включили LDAP авторизацию, и скриптом добавили синхронизацию пользователей из AD.
3. Следующим по плану, были шаблоны. Решили разделить на: шаблоны на инфтраструктурные элементы и шаблоны на сервисы.
Так же решили по возможности минимизировать количество проверок которые выполняются с сервера.
В процессе разработки шаблонов, увидели заинтересованность сетевиков, уставших от cacti. Посовещавшись, решили перенести и сетевые хосты, чтобы был единый мониторинг.
В шаблоне для сетевых железок, прониклись идеей LLD. Так же помог snmp-builder входящий в состав Zabbix Extras.
Из оставшегося: шаблоны по отдельным сервисам, перенос специфичных метрик, схема отказоустойчивости, реализация baseline в триггерах, группировка хостов по сферам работы
В нашем случае, мониторинг должен иметь аптайм 24/7 и простои недопустимы. Следовательно должен быть резерв готовый вступить в бой.
Zabbix через peacemaker+corosync. Mysql в режиме master-slave(passive master,с ведением бинарных логов). Переключение БД будет автоматизировано скриптами.
Остановились на такой схеме, правда пока не реализовали ее, потому что нужно будет перевезти заббикс на железный сервер, и согласно нашему плану мы пока не дошли до этого.
Про плюсы ораббикс уже рассказал. Java gateway - отличная вещь для мониторинга jmx, но наши разработчики ее перепишут для поддержки нашего кастома. Zabbix extras: надстройка на фронте, из тех вещей что понравились в ней это: вкладка с неподдерживаемыми элементами (в отличие от стандартного фильтра, показывает еще и текст ошибки), snmp builder - генератор шаблонов из мибов, вкладка показывает стоимость элементов данных.
Про плюсы ораббикс уже рассказал. Java gateway - отличная вещь для мониторинга jmx, но наши разработчики ее перепишут для поддержки нашего кастома. Zabbix extras: надстройка на фронте, из тех вещей что понравились в ней это: вкладка с неподдерживаемыми элементами (в отличие от стандартного фильтра, показывает еще и текст ошибки), snmp builder - генератор шаблонов из мибов, вкладка показывает стоимость элементов данных.