Tag Archives | мониторинг

One Interface Monitoring

Мониторинг чрез жопу единый интерфейс, или чем меня не устраивают существующие у нас системы мониторинга.

И с чео вообще я опять решил взяться за мониторинг ? Просто наболело. Всю прошлую неделю и кусок этой я ковырялся с Zabbix, пытался заставить непослушную скотину заставить делать рассылки через XMPP и при этом отрисовывать вменяемый интерфейс.
Ну нельзя так жить ! При этом коммерческие продукты не лучше.
Чем конкретно я недоволен ? К примеру zabbix ужасен в настройке. Мне всего то нужно прописать в него с десяток серверов. Но при этом на них вертятся не совсем стандартные приложения. К примеру нужно отследить штук 20 логов, чтобы они регулярно обновлялись и триггер срабатывал, если лог не обновлялся более 40 минут. 20 логов, 10 серверов. Убиться веником…
Ладно, запаслись терпением, прописали 20 логов, сделали шаблон, успокоились.
Но это же еще не все! Теперь надо вэбсервисы мониторить. Замечательно, есть встроенная фича мониторинга сайтов с развесистыми скриптами. Вот только виндусявая авторизация не поддерживается. А у нас все сервисы с авторизацией. Ладно, проехали.
Теперь нужно мониторить скрипт, который регулярно пишет в базу некий параметр. И если он повис должен сработать тригер. Настроил ODBC источник на сервере. Вот только Zabbix их не поддерживает. Баг.
Ладно, проехали. Тога может быть хотя бы для этих логов настроим оповещалки? Да, замечательно. Из настроек подключения к jabber только jid и пароль. И если сервер использует SSL или нестандартный порт…. Но это еще ладно. Так XMPP нотификация нормально работает только начиная с версии 1.6.5 .

В общем, zabbix — редкостное сексуальное извращение и пльзоваться им можно только за отсутствием чего то лучшего. Ну или заниматься извращениями как я.

Спасибо, пожалуйста, извините, наболело.
Всегда Ваш.

Мониторинг — потихоньку выкладываю сорсы.

Решил тут выложить сорсы класса alarm .

На подходе агент мониторинга в двух исполнениях (служба и приложение).

Ну и маленький дисклаймер, на будущее 🙂 :

Все что тут выложено по определению не содержит никаких Хау Ноу (или как оно там правильно ?) по этому копипаста не воспрещена 🙂 . Если обнаружили баги — сообщайте, поправлю.

Disaster friendly arcitecture

Все нижеизложенное целиком и полностью навеяно статьей на сайте Радар О’Рейли.

Если в кратце, то на прошлой неделе M$ начали закрытое бета-тестирование нового сервиса Vine, предназначенного для мониторинга и оповещения в случае катостроф и нештатных ситуаций. Планируется что это будет мультиплатформенный (в понимании M$) сервис, позволяющий оставаться на связи с некоторой группой людей в случае нештатной ситуации или для повседневной жизни.

Сервис представляет из себя mashup из LiveMesenger, FaceBook, LinkedIn и позволяет делать групповые оповещения и отслеживать местонахождение участников (через специальный клиент).

Так же планируется интеграция с твиттером, вэб-интерфейс и клиенты для «Не виндовс» :-).

Посмотрим, во принципе может получиться вполне приличная коммуникационная платформа, только подозреваю что в случае на самом деле серьезных проблем толку от нее будет ровно 0.

В случае каких-либо техногенных катастроф информационная инфраструктура страдает сильнее всего: если каналы связи и оказываются не поврежденными то получают серьезную перегрузку (помните отключение электричества в Москве?).

В любом случае нужно смотреть на это ближе, подписался на участие в бэта-тестировании, жду приглашения. Если пришлют и удастся посмотреть — расскажу подробнее.

Мониторинг за 4 раза :-) , агенты влияния.

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

Схема хранения данных, выбор протокола, реализация агентов мониторинга.

В прошлой статье мы определили что такое система мониторинга и как она оценивается. В этот раз мы с вами попытаемся разобраться с архитектурой и реализовать агенты мониторинга для типовой (сферической в вакууме) инфраструктуры уровня крупного отдела некоей корпорации.

Continue Reading →

Мониторинг за 4 раза :-) , введение в мониторинг.

Quis custodiet ipsos custodes?

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

Немного теории для начала

Согласно WIKI:

Мониторинг — процесс систематического или непрерывного сбора информации о параметрах сложного объекта или процесса.

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

Качество работы любой системы мониторинга определяется тремя основными показателями :

  • Максимальное время реакции — время необходимое системе на то чтобы распознать проблему и оповестить о ней оператора.
  • Вероятность ложного срабатывания. (Оповещение оператора о несуществующей или уже завершившейся проблеме)
  • Вероятность пропуска аварии. (Ситуация, при которой система не оповещает оператора о существующей проблеме)

Чем меньше время реакции — тем больше времени остается оператору на принятие решения и устранение проблемы. Два следующих показателя в принципе равнозначны, и хотя пропуск аварии на первый взгляд кажется более опасным, при большом потоке аварий ложное срабатывание вещь очень неприятная. Оператор тратит свое время на решение несуществующей проблемы, да и меры предпринимаемые для ее устранения с очень большой долей вероятности приводят к реальным сбоям.

Есть еще один, неофициальный показатель — степень доверия. Это то, на сколько доверяют системе мониторинга операторы. 🙂

Continue Reading →

Powered by WordPress. Designed by WooThemes