[xcme]

Сейчас в сети мониторится всё, кроме оборудования доступа. Но уже при этом какти покрякивает, а заббикс попискивает. Отчасти поэтому, отчасти из спортивного интереса решил написать свой опросчик. Изначально я думал, что проблема будет в том, как собрать большое количество данных за короткое время. Тот же какти, например, иногда не справлялся из-за слоупочных девайсов (типа DGS-3100), из-за чего там пришлось отказаться от родного поллера. Но для этой проблемы нашлось решение - многопоточный опрос. А вот затем встал вопрос куда собранные данные запихивать? Добрые люди показали Graphite. Поставил, записал немного метрик - все хорошо. Но что получится, если вывалить туда всё разом? Изначально была задумка собирать с каждого свичика 4 статуса порта, 11 счетчиков ошибок, 5 счетчиков диагностики и 2 счетчика пакетов. Итого 22 счетчика. Умножим это на количество портов (28), а затем на количество устройств (3250) и получаем 2 002 000 метрик. По хорошему это все надо успеть записать до начала нового опроса. Если брать "стандартное" время в 5 минут, то за 1 секунду надо будет обновлять 6673 файла. Сдается мне, это будет непросто. :)

 

Я потестил карбон на небольшом количестве метрик (60, 70, 80 и 90 тысяч) и у меня сложилось мнение, что скорость записи их на диск нелинейна. То есть я не смог определить "пиковую мощь" для моей системы. Почитал вот тут и дальше про очереди, буферизацию и пр., но просветления не достиг. Потому просьба помочь советом. Как определить производительность, какие параметры подкрутить, может есть смысл писать базу на RAM-диск или сделать кластер серверов и т.д. Может кто-то решал подобные задачки.

 

p.s. Провести "разведку боем" боюсь - сервер в виртуальной машине, не знаю как отразится увеличение кол-ва операций ввода вывода на всей системе.

[zi_rus]

11 счетчиков ошибок, 5 счетчиков диагностики

серьезно? 16 счетчиков на клиентском порту? у вас там что все абоненты супер-вип?

 

на свичах же не все порты заняты, зачем тогда их дергать, уверен там заполнение портов порядка 50%

 

почти уверен что количество собираемой инофрмации можно привести к более реальным цифрам

[xcme]

серьезно? 16 счетчиков на клиентском порту? у вас там что все абоненты супер-вип?

 

на свичах же не все порты заняты, зачем тогда их дергать, уверен там заполнение портов порядка 50%

 

почти уверен что количество собираемой инофрмации можно привести к более реальным цифрам

Все клиенты важны. :)

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

Да, можно урезать все раза в два, но, опять же, я не знаю как найти порог. Может карбон и 5 млн пережует, а может после 300к уже нужно делать кластер.

 

p.s. Заполнение 70%

[Ivan_83]

Пишите в tmpfs потом от туда выгребайте в базу или ещё куда.

Много файлов - косяк.

[StSphinx]

rrdcached нерассматривали? Он многопоточный + изначально заточен под большие нагрузки.

[Megas]

Гребите сразу все дерево.

ifDescr, ifAdminStatus и счетчики, это облегчит работу чем отдельно пинать каждый OID, а потом уже со своей стороны разгребайте дальше.

Забикс лучше хранить на ssd с партицированием и за небольшой промежуток времени, можно написать свой пулер который просто будет класть вам нужные данные.

 

Вроде в 2.4 кое что переделали, но еще не ставил в тесты, да и в целом пока смысла в нем всем не вижу.

[xcme]

Гребите сразу все дерево.

ifDescr, ifAdminStatus и счетчики, это облегчит работу чем отдельно пинать каждый OID, а потом уже со своей стороны разгребайте дальше.

Забикс лучше хранить на ssd с партицированием и за небольшой промежуток времени, можно написать свой пулер который просто будет класть вам нужные данные.

 

Вроде в 2.4 кое что переделали, но еще не ставил в тесты, да и в целом пока смысла в нем всем не вижу.

Дык со сбором проблем нет (жаль только, что bulkwalk редко где поддерживается, пришлось walk'ом собирать). SSD не выработает свой ресурс раньше времени, если на него писать очень часто и по чуть чуть?

Графит понравился еще тем, что из него легко доставать данные, да и графики легко получить отдельно.

[MMM]

Пишите в tmpfs потом от туда выгребайте в базу или ещё куда.

Много файлов - косяк.

можно даже не tmpfs, а rabbitmq.

[Ivan_83]

SSD не выработает свой ресурс раньше времени, если на него писать очень часто и по чуть чуть?

Не выработает, там же кеш есть, если специально не флюшить то он кладёт в кеш а потом пишет пачкой.

Но сейчас собрать систему с 16-32-64гб оперативы можно не дорого, 16гб вообще по цене среднего ссд чуть большей ёмкости.

[s.lobanov]

xcme

все 22 счётчика вам точно нужны. вы сначала подумайте что вы с ними реально будете делать

 

но если уж вопрос стоит о записи 2М метрик за 5 минут, то в самом деле это не так уж и страшно как кажется

 

у меня был самописный многопоточный поллер на java (snmp4j с использованием bulkwalk и bulkget) + хранение данных в posgresql-е. сам поллинг занимал не так много времени, основное время занимала запись в БД. Для этого постгресу было отдано около 5Г RAM и данные вставлялись инсертами по несколько тысяч записей, затем один большой коммит по окончанию. было около 600К метрик за 5 минут, хранлище использовалось внешнее raid10, hdd

 

если отказаться от БД в сторону rrd и кеша с помощью ssd(или избрать прочие хитрые способы), то всё работало бы гораздо быстрее

 

я бы на вашем месте просто взял бы какой-нибудь сервер и тупо попробовал сначала даже без ssd кешей, теоретически всё это расчитать не реально не имея экспериментальных данных

[s.lobanov]

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

 

Не получится в большинстве случаев. Например, когда порт работает в режиме full-duplex(а в 99.999% случаев так и есть), нельзя узнать есть ли crc-шки в направлении свитч->абонент, т.е. если повреждена одна пара, то вы об этом не узнаете. Решается это(и подобные проблемы) только путём установки абонентом CPE под вашим управлением или что-то сливающее вам статистику

 

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

[xcme]

xcme

все 22 счётчика вам точно нужны. вы сначала подумайте что вы с ними реально будете делать

22 это идеальный вариант. Может потом сильно урежу число.

Что делать:

1. ТП сможет разбирать проблемы вида "А я вот тут уезжал на 3 месяца, инетом не пользовался, а отключиться забыл. Сделайте мне перерасчет." (хотя можно и другим способом это выяснить, но так будет проще)

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

3. Проблемы с кабелем будут решаться в тот же день. Сейчас абонент звонит, жалуется на не пойми что. Если в диагностике аномалии, сначала исправляют их, потом начинают думать над остальным. Но когда там видишь 200 ошибок и аптайм 94 дня, то очень сложно понять когда случилась беда. Техподдержка скидывает счетчики и мониторит абонента день или два. Но если снимать данные регулярно, то вывод можно сделать сразу и сразу же послать ремонтников, если требуется.

4. Раз в сутки отдельным скриптиком выискивать ТОП-10 аномалий по портам и передавать их человекам на разбор.

 

Насчет остального: видимо так и придется, спасибо. :)

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

 

Не получится в большинстве случаев. Например, когда порт работает в режиме full-duplex(а в 99.999% случаев так и есть), нельзя узнать есть ли crc-шки в направлении свитч->абонент, т.е. если повреждена одна пара, то вы об этом не узнаете.

Не очень понимаю, почему так? Как тогда поднимется линк на 100М? А если есть явное повреждение кабеля, то это можно будет увидеть на диагностике порта. Да и для TX-errors есть отдельные счетчики, там если не CRC, так различные коллизии будут.

[s.lobanov]

Да и для TX-errors есть отдельные счетчики, там если не CRC, так различные коллизии будут

 

Почитайте что такое full duplex, после этого вопросы о коллизиях и tx-errors у вас отпадут. А если где-то и будут tx-errors, значит это свитч записывает output drop'ы, которые не являются исправляемой проблемой как таковой (нехватка 100мбит или буфера коммутатора)

Ещё важно никогда не выставлять жёстко скорость в сторону абонента, а делать всегда auto

 

1. ТП сможет разбирать проблемы вида "А я вот тут уезжал на 3 месяца, инетом не пользовался, а отключиться забыл. Сделайте мне перерасчет." (хотя можно и другим способом это выяснить, но так будет проще)

Для этого нужен всего один счётчик - входящих пакетов

 

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

И понимать, что из своих 100мбит он от силы 10 утилизирует когда смотрит hd на ютубе и переходить на более дешёвые тарифы. Не нужно абоненту видеть график утилизации своего порта. Кому это реально надо - сами нарисуют

 

3. Проблемы с кабелем будут решаться в тот же день. Сейчас абонент звонит, жалуется на не пойми что. Если в диагностике аномалии, сначала исправляют их, потом начинают думать над остальным. Но когда там видишь 200 ошибок и аптайм 94 дня, то очень сложно понять когда случилась беда. Техподдержка скидывает счетчики и мониторит абонента день или два. Но если снимать данные регулярно, то вывод можно сделать сразу и сразу же послать ремонтников, если требуется.

Входящие ошибки достаточно снимать раз в часа или ещё реже, если задача состоит в поиске плохого кабеля

[pppoetest]

Ещё важно никогда не выставлять жёстко скорость в сторону абонента, а делать всегда auto

Вот прям +100500

[xcme]

Ещё важно никогда не выставлять жёстко скорость в сторону абонента, а делать всегда auto

Вот прям +100500

Ну вы еще скажите, что порт обязательно включать. :)))

 

А про TX-ошибки есть у меня возражения, завтра допишу.

[s.lobanov]

А про TX-ошибки есть у меня возражения, завтра допишу.

 

ok, жду (в контексте автосогласованного full-duplex)

[nuclearcat]

mongodb? я сделал достаточно большой обьем insert-ов, оно как раз на это рассчитано (по описанию)

[NiTr0]

Монго - на самом деле убого. Ибо поиск - медленный и печальный ввиду отсутствия индексов. Эдакий кеш временного хранения. 4 гига база у знакомых в одном проекте (сбор данных с датчиков) пыхтит и тужится, еле ворочается (хотя и само оно писано похабно, но все же и монго внес свою лепту в это). При этом у нас база заббикса на мускуле уже за 120 гигов перевалила - и никаких проблем, все летает.

[s.lobanov]

NiTr0

значит неправильно используется. nosql базы данных как раз и используется для подобных задач и есть куча success story, где объёмы измеряются в Тбайтах и ПБайтах

[decuplet]

А что мешает создать-таки индексы в монге?

[NiTr0]

Ну я в недра того кода не вникал. Там еще вылез прикол монго - 32бит версия оказалось в 4 гига размер БД упирается... И я особо не понял преимуществ слабо типизированного хранилища там, где просто напрашивается классическая реляционная база...

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

[xcme]

А про TX-ошибки есть у меня возражения, завтра допишу.

 

ok, жду (в контексте автосогласованного full-duplex)

Когда коммутаторы были соединены по меди, а над городом шла гроза, то после удара молнии наблюдалась как раз такая картина: линк выглядит как обычно, ошибок вроде как нет (swtoolz показывает только RX), но пакеты теряются. А если зайти на сам свичик и посмотреть TX-коллизии, то они в диком количестве росли прямо на глазах. И это на фулдуплексе. Ребут обоих железок проблему решал.

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

[s.lobanov]

А если зайти на сам свичик и посмотреть TX-коллизии, то они в диком количестве росли прямо на глазах. И это на фулдуплексе. Ребут обоих железок проблему решал.

Это один или оба свитча сошли с ума, т.е. единичный случай. На фулдуплексе tx-коллизий быть не может как бы.

 

Сейчас несколько свичиков посмотрел - везде, где есть TX-ошибки, так или иначе на какое то время поднимался халф.

Вообще, хафдуплекс это ненормально в принципе для fttb-провайдинга. И это не просто поводу задуматься, а это значит, что либо вы скоро получите заявку, либо абонент уйдёт. И полудуплексы нужно отслеживать другими средствами (traps, syslog и т.п.), а в идеале вообще избавиться от halfduplex. Кстати, по поводу хафдуплексов и как с ними бороться с помощью capabilities я писал здесь

[xcme]

Half может подняться в штатной ситуации? Например, комп выключен, но включен WOL или еще какие-нибудь случаи?

Если жестко запретить использовать что-либо кроме 100Full, не усложнит ли это диагностику линии монтажником ("О, у вас сетевая сгорела!")? Еще бывает, когда абонент подключают на >80 метров, а в буке сетевушка слабенькая и она в автосогласовании выставляет 10-тку. А в таком случае, выходит, линк вообще не поднимется. И вместо того, чтобы разбираться с линией, монтажник будет грешить на комп абонента.

Edited November 3, 2014 by xcme

[s.lobanov]

Half может подняться в штатной ситуации? Например, комп выключен, но включен WOL или еще какие-нибудь случаи?

Вот забыл я. То ли в 10full встаёт линк, то ли в 10half когда комп включен по питанию, но не загружен. Вроде бы 10full. Но суть это не меняет. Запрет всех режим кроме 100full на 100мбитном линке это хорошо. Когда я занимался этим вопросом, то на довольно большой сети нашёл всего одного абонента, где реально нужен 10half - это очень древний телефонный шлюз Cisco AT. Знаю ещё 2 случая(где нужен 10half) в серверных - management processor для древнего HP-сервера с HP-UX и устройство мониторинга SNR-ERD3

 

Еще бывает, когда абонент подключают на >80 метров, а в буке сетевушка слабенькая и она в автосогласовании выставляет 10-тку. А в таком случае, выходит, линк вообще не поднимется. И вместо того, чтобы разбираться с линией, монтажник будет грешить на комп абонента.

А так монтажник увидит 10мбит и догадается, что проблема в длине кабеля? Ну с таким же успехом он может догадаться, имея с собой кабельный тестер, умеющий поднимать линк или "нормальный" нетбук/ноутбук/роутер. Вообщем как-то надуманно у вас получается...