События и аварии являются неотъемлемым элементом эксплуатации сети. Ежесекундно фиксируются тысячи событий, служба эксплуатации постоянно занята устранением нескольких аварий, еще несколько аварий наверняка где-то есть, но пока не обнаружены и не диагностированы. Оперативная диагностика и обнаружение аварий является весьма сложной задачей, которая может быть решена только комплексом организационно- технических мер. И не последнюю роль в нем играют автоматизированные средства обнаружения и обработки аварий.

Существует немало систем мониторинга, которые выполняют активную проверку сети и сетевых сервисов по протоколам ICMP и SNMP. Быстрый и неправильный ответ – очевиден. Достаточно настроить волшебную систему мониторинга, и наступит полное счастье. Вся обманчивость этого заблуждения понимается со временем. Сначала выясняется, что обнаружение аварий происходит только на тех сервисах, которые поставлены на мониторинг. Хорошо, если удалось накрыть хотя бы основные сервисы. Остальные, увы, будут ставиться на мониторинг в результате горького опыта и ценой запоздалой реакции. Чуть попозже начинается мистика. Что-то явно работает не так, есть жалобы, но система мониторинга говорит, что все в порядке. В чем причина?

Продолжение «опытных мелочей». Предыдущие части: раз, два, три, четыре, пять.

В этом посте я расскажу о небольшом, но по-своему интересном опыте использования протокола SNMP для сбора статистики печати в организации.

В компании, о которой идет речь, довольно много печатают. Есть и большие, мощные принтера (типа HP 9000) и средние, и совсем уж Home класса. Благо, все они сетевые, и ассортимент производителей узок, всего два: HP и Ricoh (в разных ипостасях, от NRG до MB). И вот в один прекрасный весенний день, посмотрев на счета за канцелярию, бережливым руководством была поставлена задача: регулярно собирать статистику печати, «чтоб потом анализировать». Причем сильно они и не заморачивались: «Все принтера сетевые, у них есть страничка статистики, с утра сели обошли по списочку, записали циферки в Excel, вот и все — делов-то»!

Работая у крупнейшего провайдера РФ столкнулся с ситуацией, что происходит обращение абонента о проблемах в недалеком прошлом, т.е. вчера все было плохо, а сейчас заработало. Что делать в этом случае? Есть варианты использовать системы мониторинга, которые будут собирать ключевые параметры всех абонентских линий и хранить их некоторое время, и оператор ТП легко сможет получить доступ к этим данным для решения подобных ситуаций. Также, имея эти данные, можно давать автоматическую экспертную оценку по каждой абонентской линии, и при желании, на xDSL, автоматически подбирать наиболее подходящий профиль. Используя эти же данные, можно выявлять дефектные линии или линии с неудовлетворительными параметрами и устранять возможные проблемы абонентов еще до их обращения в ТП.
С первого взгляда задача не сложная, но когда количество оборудование легко перешагивает тысячи узлов доступа, а количество абонентских портов может исчисляться десятками тысяч появляются некоторые особенности настройки и запуска подобной системы, с максимальной автоматизацией всего.
Если интересно, добро пожаловать под кат

Судя по тому, насколько популярен блог DIY, многие из нас любят изобретать. Наверное, каждый встречал человека, который способен сутками что-нибудь паять, программировать, отлаживать, не замечая ничего вокруг. Вот совсем свежие примеры.

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

Речь пойдет про устройства NetPing. Эта российская разработка периодически упоминается на хабре, но детального рассказа я не встречал. Пусть эта статья будет продолжением серии «Оборудование российского производства». Мне достался самый универсальный прибор линейки – UniPing RS-232. Основная сфера его применения – удаленный мониторинг и управление множеством устройств в квартире, доме, офисе. Конечно, давно существует понятие «умный дом», но, как правило, это преподносится как вариант для состоятельных людей, хотя получают они черный ящик с жестко заданным, пусть и большим, набором функций. Однако, можно ведь все собрать и запрограммировать самому!

Cacti — Веб-приложение которое поможет Вам мониторить состояние вашего сервера, CISCO и всего что может отдавать данные по SNMP протоколу. Вы сможете наблюдать за загрузкой CPU сервера, видеть на графике среднюю загрузку памяти за период времени, количество DNS запросов приходящих на сервер, количество писем (спама) приходящих на почтовый сервер. Сможете мониторить среднюю нагрузку на сеть в рабочие часы и многое другое.

Cacti Plugin Architecture — дополнение для Cacti расширяющее возможности стандартного пакета путем включения функции установки стороних плагинов.

Spine — быстрый и качественный поллер для Cacti написанный на C. Используется взамен стандартного поллера, идущего в стандартной инсталляции Cacti, cmd.php.

Показательная, базовая установка Cacti с прибомбасами на CentOS 5.5 i386. Многие элементы настройки защиты веб-сервера игнорируются, ввиду тестовой инсталляции.Все действия будут выполняться под рутом.

Недавно возникла необходимость использования протокола SNMP, для мониторинга работы разрабатываемого серверного приложения, работающего под управлением Windows. По скольку с SNMP до этого я не сталкивался то начал с поиска руководств, статей и примеров. В результате я обратил внимание на крайнюю скудность информации по протоколу SNMP применительно к Windows. Данная статья является своеобразным подведением итогов по изучению и разработке модуля SNMP для Windows и призвана предоставить краткое описанное того, что было полезного найдено и использовано, возможно, это поможет сэкономить время тем, кто также будет с нуля разбираться с работой SNMP в ОС Windows.

Началось строительство FTTB и появилось новое оборудование производителя Edge-core. Естественно захотелось прикрутить новое железо к Zabbix. Ранее я поступал просто — натравливал snmpwalk на железку и анализировал полученные данные. Этот путь достаточно долгий, так как полученный результат бывает под несколько мегабайт текста и достаточно тяжело найти нужные значения. Но есть другой способ — использовать MIB устройства. Но ведь Zabbix не умеет работать напрямую с MIB файлами. Что же делать?
На форуме забикса нашел замечательную утилиту SNMP Builder for Zabbix. С её помощью можно сделать базовый шаблон устройства имея его MIB и потом ручками его допилить до нормального состояния.
Я вам расскажу как это сделать на примере оборудования Edge-core.

Решил собрать данные о текущих версиях прошивок со своих DSLAM Siemens HIX5630.
OID нашелся snmpwalk'ом достаточно быстро.

.1.3.6.1.4.1.231.7.1.2.2.1.1.2.1.1.12.xx
где хх = 13 14 15 16 17 18 19 20 соответственно 1 2 3 4 7 8 9 10 платы IU (модемные или голосовые)
а 21 и 22 платы CXU (процессорные).

Буду краток. На точках DWL-3200AP (вероятно, также на DWL-2100AP, DWL-2700AP) в конфигурации по умолчанию включена поддержка SNMP c именами ro/rw community соответственно public/private.

В OID 1.3.6.1.4.1.171.11.37.4.3.1.2.0 находится пароль администратора точки доступа открытым текстом.

Ссылки
Сообщение об аналогичной уязвимости в DWL-1000AP, 2001 год
Сообщение на русском форуме D-Link, 2006 год

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

Мораль
Всегда проверяйте все настройки оборудования и программного обеспечения собственными руками, не доверяйте их производителям/авторам/мэинтейнерам.

Существует давнее убеждение, что кактус перед экраном спасает пользователя от губительного радиоактивного излучения, генерирующееся монитором.



Огромное число этих колючих растений красуется перед, на или около монитора миллионов пользователей по всей России. По количеству адептов «кактусизм» на равных соревнуется со многими религиозными конфессиями. Это не может не настораживать… ©