Tantum possumus quantum scimus
Пожалуй каждый согласится — мониторинг является одной из важнейших составляющих ИТ инфраструктуры.
Необходимо знать о состоянии твоих подопечных, ведь очень не хочется «внезапно» обнаружить рассыпавшийся RAID, забитый доверху корневой раздел или LA превышающую все пределы разумного.
Инструменты, для постоянного наблюдения за жизнедеятельностью оборудования, каждый выбирает сам.
Кому-то по душе Nagios, кто-то выберет Munin, а так же найдутся любители проприетарных или иных решений.
Мы же, создавая услугу мониторинга для своих клиентов, выбрали Zabbix.
Но мало просто подключить сервер к мониторингу, нужно организовать взаимосвязь с тикетной системой и личным кабинетом пользователя. Помимо информирования о наличии проблемы, автоматически создать заявку в службу технической поддержки, для скорейшего реагирования на инцедент, а так же дополнительно уведомить клиента по email.
Под хаброкатом расскажем как у нас это получилось.
Описание.
Немного остановимся на процедуре подключения сервиса.
В первую очередь нужно выбрать вкладку «Мониторинг».
Ознакомимся с описанием сервиса и подключим его.
«Из коробки» для выбора доступны самые, на наш взгляд, важные из параметров.
Кликнем на «Настройки» для установки нужных пороговых значений и параметров уведомлений.
Пороговые значения можно выставить в промежутке от 10% до 90% с шагом в 10%.
Так же имеется возможность настроить варианты уведомлений.
А что если набор предопределенных метрик не полностью соответствует требованиям к мониторингу?
В таком случае есть возможность отправить, через специальную форму, свои пожелания и тогда мы настраиваем мониторинг сервера(ов) именно так, как необходимо клиенту.
Для системных администраторов создается заявка на подключение услуги и тикет, где клиент может дополнительно обсудить детали и проконтролировать подключение.
При превышении пороговых значений, заданных ранее, система мониторинга рапортует о проблеме подсвечивая вкладку «Мониторинг» в личном кабинете красным цветом.
А так же отправляет клиенту уведомление по email и создает тикет для дежурных инженеров(если были отмечены соответствующие галочки).
Кликнув по ссылке «Прочитано» отключаем цветовую индикацию.
После описания сработавшего триггера указана ссылка на тикет в системе технической поддержки, где можно уточнить детали у дежурного инженера.
По каждому из графиков доступен просмотр данных в разрезе нужного промежутка времени.
Техническая часть.
Для интеграции с нашей админкой мы использовали, найденный на просторах гитхаба, класс.
Критерием выбора была возможность получать картинки графиков (в API такого функционала нет) и простота реализации класса.
Несколько других были написаны так, что было не понятно — это для работы с API или для запуска космического корабля.
Этот класс расчитан для версий Zabbix до 2.2, по этому пришлось его немного доработать. Добавили нужные нам фичи, исправили авторизацию для, используемой нами, 2.4 версии и некоторые параметры в ZabbixAPI вызовах.
Так же изменили скрипт формирования графика в zabbix, чтобы можно было вырезать лишние данные и вставлять свой заголовок.
Обмен данными идет по http/https, API отдает json объект в виде массива.
Графики берутся несколько хитрее — как бы эмулируется браузер, т.е. скрипт через curl авторизируется логин/паролем и с выданой кукой скачивает png-шку с графиком.
Картинки графиков (и их предпросмотр) у нас хранятся в redis, с временем жизни 1 час, если график не обновляли, например выбрали другую дату или прошла 1 минута с последнего показа графиков пользователю в личном кабинете, сделано это для того чтобы юзер совсем не заддосил zabbix созданием картинок при каждом обновлении странички.
Картинки формируются при каждом уникальном запросе, т.е. если пользователь не заходит в мониторинг, то и система не дергается по поводу графиков.
Все запросы к Zabbix скрыты ключами на основе md5 хеширования с солью. Параметры запроса так же хранятся в redis и не доступны пользователю, т.е. не видно конкретные параметры и ссылки на сервер мониторинга.
Скрипт в cron 1 раз в минуту проверяет все активные триггеры и записывает дату и время начала события и дату и время когда проверка показала, что такой триггер больше не активен (логируются только выбранные при подключении сервиса триггеры).
В зависимости от выбранных событий по срабатыванию триггера, юзеру отсылается сообщение о новом активном триггере и о триггерах, которые он еще не отметил как прочитанные в личном кабинете и/или создается тикет с текстом триггера и/или мигает пункт меню «Мониторинг».
В самом Zabbix шаблоны триггеров в описании заданы как «scm_IDтриггера порог%», например «scm_CPU 70%», за счет этого после заказа скрипт сам может найти ID триггеров (уникальные для каждого хоста и варианта триггера), и это позволяет легко заменить описание «scm_CPU 70%» на «CPU load more than 70%» или «Загрузка CPU выше 70%».
В нашей админке показыватся все доступные графики, триггеры и события для этого хоста, и их в любой момент можно юзеру включить/выключить.
Шаблоны для мониторинга каких-то специфических вещей создавались с нуля, либо дорабатывались найденные, так же немного поправили default шаблоны под нашу специфику.
Если возникнет интерес, то с удовольствием поделимся с сообществом наработками.
На этом все !
Благодарим за внимание!
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий