[xcme]

В общем, стали собирать следующее:

- RX/TX с абонентских портов. См. первую картинку. Сейчас бьемся за производительность Graphite, он чуть-чуть не справляется, но сдвиги есть. Сначала была проблема с чтением данных из кеша, что приводило к отрисовке графиков с задержкой. Сейчас читать кеш научились, но теперь имеем "дырки" на графиках и решаем уже эту проблему.

- RX CRC. В профиле абонента рисуется динамика роста ошибок (картинка 2), а также сам факт роста фиксируется отдельно. Можно посмотреть ТОП портов с ошибками (картинка 3), где ошибки не просто имеются, а именно растут. Аналогичный ТОП есть и для магистральных портов

- Тип дуплекса. На него пока никак не реагируем, просто фиксируем в истории что порт поднимался на HALF. Это может помочь при разборе ситуаций с ростом ошибок или "А почему у меня во вторник торрент медленно качал?"

- Административно заданная скорость. Этот списочек перебираем вручную, смотрим где и почему скорость задана явно. Сначала там было довольно много портов (несколько сотен), теперь же остались только VIP-клиенты и прочие включения, где скорость и должна быть выставлена вручную. Для этих случаев есть кнопочка "Забыть".

 

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

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

Имеется график на ТОП mac notification. Он больше для админских вопросов, поскольку ситуации там обычно специфичные.

 

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

 

 

Еще можно сказать что графики ушли несколько вперед по отношению к самому рабочему процессу. То есть данные имеются, но пользоваться этим научились не все. Пролистывая тикеты задним числом видел как абонента отправляют в сервис или на переустановку ОС при том что проблема была в принудительном 10_half на порту, а это никто не заметил. Но и положительные примеры тоже есть. На днях коллега, сравнивая графики, обнаружил кольцо, которое умудрились сделать через нашу сеть, замкнув ее по воздуху между разными населенными пунктами! Это вам не патчкорд двумя концами в свичик вставить! :)))

[Negator]

У нас объемы поменьше, со сбором данных пока справляется zabbix.

Интересен анализатор проблем.

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

С ошибками на порту вроде все ясно. Если есть постоянный рост ошибок - значит ищи проблему.

Но часто рост ошибок не постоянный. Сегодня утром они активно росли, днем уже нет проблемы.

Пробные звонки и походы к таким абонентам проблем не выявили вовсе.

Поэтому непонятно как реагировать на подобные вещи.

 

Касаемо скорости и дуплекса - тут тоже не все так просто. Часто сетевушки ноутбуков в режиме сна встают в 10/Half, или в 10/Full

Касаемо штормов - мы давно уже только настраиваем ограничение кол-ва броадкастов в секунду. Но портов не блокируем и не выключаем.

 

С диагностикой кабеля вообще беда. Что то внятное она показывает только при вынутом из абонентского устройства кабелем.

В остальных случаях - может показать все что угодно. Опросил кучу коммутаторов -никакой однозначной картины выстроить так и не смог.

Более того -абонентские сетевушки могут показывать pair short на кабеле если комп выключен.

 

Попробую собирать топ падения/поднятия портов, но по заверениям длинка- это у них нормальная ситуация.

Не раз уже видел - на свиче порт скачет - у абонента линк есть всегда и все работает нормально.

[BeHalf]

В общем, стали собирать следующее:

Я так понимаю это допилен ваш старый скрипт по опросу коммутаторов? А в паблик ожидается? или таки не в паблик, но за денежку?

[xcme]

У нас объемы поменьше, со сбором данных пока справляется zabbix.

Интересен анализатор проблем.

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

Есть два типа анализа - предварительный автоматический и последующий ручной. Первый призван отобрать из общей массы подозрительные состояния и сгенерировать уведомление. Например, для RX CRC у меня заданы условия:

- Если обнаружен рост более чем на 5, инкрементировать триггер

- Если триггер не увеличивается 12 раз подряд (12*5=60 минут ничего не меняется), сбросить триггер

- Если триггер увеличился до 3 (т.е. трижды за час CRC увеличились более, чем на 5), сгенерировать alarm, после чего игнорировать любые события 9 раз (т.е. получаем одно уведомление в час)

 

Таким образом, мы получаем сигналы только об устойчивых проблемах. А затем уже применяем ручной анализ - видим alarm, изучаем его и по совокупности факторов понимаем, надо ли что-то предпринимать. Если просто half-линк - ерунда, а если при этом трафик идет и ошибки растут, значит это уже не режим сна. А если по истории абонент уже обращался с проблемами, значит точно что-то не так.

 

В посте выше упоминал, что обнаружили кольцо. Его нашли как раз так - увидели, что одни и те же коммутаторы в топе на разных графиках. Автоматике такой анализ не под силу, а вот живому админу - вполне.

 

Касаемо штормов - мы давно уже только настраиваем ограничение кол-ва броадкастов в секунду. Но портов не блокируем и не выключаем.

Вот почему то где-то глубоко внутри у меня есть убеждение, что блокировка работает аппаратно, а ограничение - программно, а значит привет нагрузка CPU. Или я ошибаюсь? Если так, то хорошо, значит у себя тоже переделаю. Потренируюсь пока на ком-нибудь штормящем.

 

С диагностикой кабеля вообще беда. Что то внятное она показывает только при вынутом из абонентского устройства кабелем.

В остальных случаях - может показать все что угодно. Опросил кучу коммутаторов -никакой однозначной картины выстроить так и не смог.

Более того -абонентские сетевушки могут показывать pair short на кабеле если комп выключен.

С диагностикой плохо, согласен, но, в целом, мы ей доверяем. Обзвонили 10 человек у которых диагностика прыгала (то ОК, то short), 4 из них проблему подтвердили. Им и остальным предложили бесплатный ремонт (даже если проблему абонент не замечал) - в 70% диагностика стала стабильной, эти 4-ро проблемы замечать перестали. Понятное дело, что 10 это не показатель, но все равно кое что. Другие "исследования" тоже показывают, что проблемы замечают далеко не все, так что это нормально.

 

Попробую собирать топ падения/поднятия портов, но по заверениям длинка- это у них нормальная ситуация.

Не раз уже видел - на свиче порт скачет - у абонента линк есть всегда и все работает нормально.

Винда иногда просто не успевает положить порт, но такое есть, согласен. Тут еще есть зависимость от модели устройства. Если порт глюкнет в результате диагностики, то на 3200-28 С1 он будет флапать, а на других ревизиях может просто свалиться и не подниматься. Свич с флапающим портом можно отправить в ребут утром, примерно в 15-20% случаев это возвращает порт в нормальное состояние. Красивого решения мы тут тоже пока не нашли. Одно понятно - чем "старше" территория, тем больше там разного рода проблем. Я находил свичики, где на 10 из 24-х портов коммутатор фиксирует какую то аномалию. Нашел, например, монтажи с длиной более 150 метров. На недавно застроенных территориях такого нет.

 

В общем пока еще сами смотрим, удивляемся. На самостоятельный откуп ТП отдали только ТОП абонентских DHCP на порту (но это делается другим сервисом), остальное пока исключительно в ручном режиме.

 

В общем, стали собирать следующее:

Я так понимаю это допилен ваш старый скрипт по опросу коммутаторов? А в паблик ожидается? или таки не в паблик, но за денежку?

Если речь про swtoolz, то нет. То был скрипт на PHP для опроса по требованию, а теперь два демона под FreeBSD на Python для постоянного опроса. Выложу на гитхаб как только освоюсь с ним немного.

Демоны гибко настраиваются и, по сути, не привязаны к каким-то моделям, да и к D-Link вообще. Но нужно иметь практический опыт работы с SNMP, понимать, чем отличается bulk от walk, сколько времени и какую нагрузку на оборудование создает конкретный запрос и т.д, иначе можно ушатать сеть этой штукой, т.к. работает быстро и беспощадно. :)

[BeHalf]

Выложу на гитхаб как только освоюсь с ним немного.

Демоны гибко настраиваются и, по сути, не привязаны к каким-то моделям, да и к D-Link вообще. Но нужно иметь практический опыт работы с SNMP, понимать, чем отличается bulk от walk, сколько времени и какую нагрузку на оборудование создает конкретный запрос и т.д, иначе можно ушатать сеть этой штукой, т.к. работает быстро и беспощадно. :)

С интересом буду ждать) сеть небольшая ~70-80 единиц оборудования и вся на управляемых dlink.

[xcme]

Касаемо штормов - мы давно уже только настраиваем ограничение кол-ва броадкастов в секунду. Но портов не блокируем и не выключаем.

Вот почему то где-то глубоко внутри у меня есть убеждение, что блокировка работает аппаратно, а ограничение - программно, а значит привет нагрузка CPU. Или я ошибаюсь? Если так, то хорошо, значит у себя тоже переделаю. Потренируюсь пока на ком-нибудь штормящем.

Открыл доку, похоже все наоборот и как раз я использовал софтовый механизм. :) В общем, буду изучать, спасибо за подсказку.

Drop – Utilizes the hardware Traffic Control mechanism...

Shutdown – Utilizes the Switch’s software Traffic Control mechanism...

[xcme]

Выложил проект сюда https://github.com/xcme/briseis . Анализатор будет позже, все равно интересующимся будет чем заняться - в уже выложенной доке все несколько мозговзрывабельно, но разобраться можно и нужно.

Проблемы и т.п. можно обсудить там же или на http://xcme.blogspot.ru/2015/03/briseis-freebsd-snmp.html.

 

По поводу storm в drop mode - попробовал, понравилось. Спасибо, Negator.

 

С Graphite тоже разобрались. Ipfw не успевал лепить динамические правила, из-за этого часть данных терялась. Разрешил прохождение SNMP безусловно и теперь графики рисуются полностью и смотреть их можно, не ожидая пока метрики запишутся на диск.

[Negator]

На данный момент я опрашиваю около 3200 коммутаторов D-Link, в памяти формируется более 600 000 метрик, а сам сбор данных при этом занимает менее 1 минуты.

не слабо так..

[xcme]

Анализатор тоже выложил. С гитхабом пока не очень дружу, но что надо вроде как появилось. Можно и релиз скачать одним архивом.

[comopt]

А туда можно отдавать собранные мной метрики, чтобы он их обдумывал и дальше кидал в графит? Или он должен сам все собирать?

Riemann это пайп с прикрученным анализатором. Он сам ничего не собирает. Так же как и инфукс/графит и прочие.

Вы про этот графит

Изменено 6 сентября, 2016 пользователем comopt