Не беспокойтесь, мы за ними присмотрим. Интеграция Zabbix в личный кабинет клиента

    Tantum possumus quantum scimus


    Пожалуй каждый согласится — мониторинг является одной из важнейших составляющих ИТ инфраструктуры.
    Необходимо знать о состоянии твоих подопечных, ведь очень не хочется «внезапно» обнаружить рассыпавшийся RAID, забитый доверху корневой раздел или LA превышающую все пределы разумного.
    image

    Инструменты, для постоянного наблюдения за жизнедеятельностью оборудования, каждый выбирает сам.
    Кому-то по душе 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 шаблоны под нашу специфику.
    Если возникнет интерес, то с удовольствием поделимся с сообществом наработками.

    На этом все !
    Благодарим за внимание!
    ServerClub
    Company
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 20

      +2
      Добро пожаловать в клуб, ага
      image
        0
        Скрин старый, не заметил когда статью оформлял, сейчас бага исправлена.
        0
        Иван Иваныч докладывает — в FF сьезжает разметка
          0
          Спасибо, поправим.
          0
          Правильное написание множественного числа у слова «сервер» — «серверы», а не «сервера».
            0
            Все время вижу это правило и по большей части употребляем «серверы». Но хотелось бы увидеть правила написания для подобных слов, на которые можно ссылаться, чтобы понимать что «сервера» не допустимо, т.к. слово то в словарях Ожегова и Даля не найдешь )
              0
              СЕ́РВЕР [сэ́], а, мн. се́рверы

              Крысин Л.П. Толковый словарь иноязычных слов. — М.: Эксмо, 2008.
                0
                С вами не согласны:
                www.gramota.ru/slovari/dic/?all=x&word=%25F1%25E5%25F0%25E2%25E5%25F0
                dic.academic.ru/dic.nsf/dic_fwords/32945/%D0%A1%D0%95%D0%A0%D0%92%D0%95%D0%A0
                slovari.yandex.ru/~%D0%BA%D0%BD%D0%B8%D0%B3%D0%B8/%D0%A2%D0%BE%D0%BB%D0%BA%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%81%D0%BB%D0%BE%D0%B2%D0%B0%D1%80%D1%8C%20%D0%B8%D0%BD%D0%BE%D1%8F%D0%B7%D1%8B%D1%87%D0%BD%D1%8B%D1%85%20%D1%81%D0%BB%D0%BE%D0%B2/%D0%A1%D0%B5%D1%80%D0%B2%D0%B5%D1%80/
                и ряд других словарей.
                  0
                  Полагаю, есть смысл уточнить у автора, почему в 1998 г. употребляет "-а", но в 2008 г. уже "-ы".
                  Лично я предпочту более современную форму.
                  За ссылки спасибо, при случае можно оформить в отдельную статью, холивар обеспечен. :)
            +1
            Я правильно понимаю, что вы за Zabbix еще и деньги берете?
              0
              Это вы еще про виртуальных хостеров не знаете, они вообще деньги за OVZ/KVM/Xen берут, смысл не в самом мониторинге как таковом, смысл, как я понимаю, в сервисе, клиенту не нужно париться самому следить за состоянием рейдов, свободным местом, высокой загрузкой и прочим, об этом позаботится хостер и много где такой услуги очень не хватает. Лично я при деградации рейда, хотел бы, чтоб хостер максимально быстро заменил сбойный диск, а не только по моему тикету, у многих отношение: «Мы тебе сервер в аренду сдали, дальше сношайся с ним как хочешь, только деньги плати вовремя», так что услуга однозначный плюс, ну и пользоваться насильно, я так понимаю, ей никто не заставляет.
                0
                А действительно ли хостер заменит сразу диск по автоматически созданному тикету? Сомневаюсь. По всей видимости нужно всё же будет в него повторно написать. Вообще интересно, как техподдержка обращает внимание на такие сгенерированные тикеты, как: «У клиента IDxxx загрузка CPU на сервере IDxxx выше 70%»?
                  +1
                  >А действительно ли хостер заменит сразу диск по автоматически созданному тикету?
                  Нет, потому как время отключения сервера нужно согласовать с клиентом.
                  В созданном тикете это, как раз, и делается.

                  > Вообще интересно, как техподдержка обращает внимание на такие сгенерированные тикеты, как: «У клиента IDxxx загрузка CPU на сервере IDxxx выше 70%»?
                  Запрашивает доступы к серверу для выяснения причин нагрузки, а если доступы выдавались клиентом ранее, то сразу предпринимает необходимые действия.
                    0
                    Чтобы заменить диск в рейде — отключать сервер? Отличный какой-то рейд. От других. В которых обычно смысл как раз в нулевом даунтайме.
                      0
                      Диски и рейды в серверах — разные бывают. Где то надо и выключать.
                  0
                  Внезапно, у хостера либо есть доступ к ОС, либо нет.

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

                  Если нет — то это обычный unmanaged dedicated server, и, соответственно, никаких вопросов к хостеру по определению нет. Клиент сам все забрал себе, сам мониторит и для хостера в этом случае хорошим тоном является выставить наружу public API для того, чтобы если что, можно было или передернуть сервер по питанию, или создать тикет (обычно из внешней системы мониторинга).

                  В любых формах виртуального хостинга в любом случае мониторинг железки (да и вещей типа load average или нагрузки на IO) — забота хостера.
                    0
                    Вы говорите очевидные вещи, но судя по сайту хостер не предоставляет виртуальных серверов вообще, а все сервера unmanaged dedicated, данная запись в корпоративном блоге, похоже, переход с unmanaged dedicated server на managed dedicated server, что в принципе не плохо и расширение услуг, другой вопрос в реализации, но тут могут сказать только клиенты хостинга.
                  0
                  Да, есть бесплатные опции мониторинга, но по большей части — за плату. Но смысл весь, как тут уже указали, именно в полном цикле обслуживания. Что очень удобно: например админ вашего сервера в командировке или отпуске и вылетает один диск из рейда, система это увидит, создаст тикет и спросить у клиента: в какое время меняем диск? Клиенту достаточно написать с телефона: «как можно скорее или интервал времени» и система снова будет в безопаности.
                    0
                    Насколько я понял, вы работаете в сегменте managed серверов (ну, хотя бы потому, что вы можете клиенту в сервер что-то поставить). Я вот немножко покопался в памяти и сходу не вспомнил ни одного хостера, который бы (1) брал дополнительные деньги за мониторинг и обслуживание сервера, если уж речь идет о managed; (2) собственно явно привлекал клиента ко всей этой кухне, раз уж взялся администрировать его сервер.

                    Само собой, managed стоит больше, чем unmanaged. Но в этом как бы и смысл, что один раз платишь — и свободен. И бэкапы, и мониторинг, и любое (уж тем более — аппаратное) обслуживание, системные апдейты, DNS-почта-все-такое и т.д. — включены. И несколько дико мало того, что настраивать алерты (и уж тем более писать с телефона), но вообще принимать в этом участие.

                    Учитывая, что цены у вас изначально, мягко говоря, выше среднего, а сервера — весьма не первой свежести — так еще и получается, что еще за то, чтобы этот managed стал настоящим managed — надо еще доплачивать.
                      0
                      managed сервер — очень абстрактное понятие сегодня на рынке. Также знаем множество хостеров, кто делая приписку «managed» — кроме как обновление прошивок ничего больше не обещает. А уж не привлекать клиента к вопросам администрирования — так сразу очень много клиентов разбежится от нас, если мы без разрешения и согласования полезем в БД, веб-серверы и прочие системы клиента.

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