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

Началось строительство 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 (процессорные).

Цикл статей о Zabbix продолжает не зарегистрированный здесь пользователь. Первую статью можете прочитать тут.

Зачем это нужно?

Добавить новый хост в Zabbix можно двумя основными способами: автообнаружение и ручное добавление хоста. Когда мы имеем очень большое количество узлов добавление их в систему мониторинга ручками занимает большое время, отслеживание их количества и подержание их в актуальном состоянии тоже не легкая задача. В этом случае удобно использовать авто обнаружение. Как его использовать в этой статье описываться не будет (если кому будет интересно можно будет подготовить маленький обзор по основным функциям). Основной недостаток при авто обнаружении — добавленные хосты получают имя равное IP устройства. При большом количестве устройств разобраться, что где проблематично.

Решение.

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

И так, встречайте: Zabbix.

Решил опубликовать статью, благодаря которой я получил инвайт на этот сайт.
Преждевременное З.Ы. Сразу замечу, что данная статья не является рекламой продукта, я лишь хочу порекомендовать его в использовании.

В далеком прошлом задался вопросом автоматизации контроля за сетевыми компонентами нашей компании внутри сети и вне ее. Решением были разные утилиты для проверки пинга в основном, но задачи были не только таковыми что ограничивались проверкой доступности и времени ответа от девайса. Нужно было проверять нагрузку разных БД, загрузку канала на роутере в сети, доступность ftp, smtp серверов, контроль девайсов Cisco и другие разнообразные задачи. Я никогда не искал для этого всего одного софтового решения, использовал разные, но большое колличество софта затрудняло работу с ним.
Как то наткнулся на продукт компании paessler который называется PRTG Network Monitor и был удивлен его функционалом а так же и непопулярностью (точнее недостаточной раскрученностью) среди системных администраторов.