Перейти к содержимому
Калькуляторы

какую статистику снимать с DSLAM'ов? snr, attenuation, output power и т.д....

Доброго времени суток!

 

Помогите, пожалуйста, добрым советом :)

 

Так уж получилось, что я на этапе внедрения в нашей компании услуг ADSL поднял и настроил сервер для снятия с DSLAM'ов физических характеристик портов:

- SNR,

- attenuation,

- output power,

- connection speed,

- загрузка порта по скорости (octets/time)

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

 

Хочу подчеркнуть - все это НИКАК не связано с биллингом:

вопросы клиентов про текущий баланс, или "сколько и чего я скачал", или "как мне поменять пароль на подключение" или "сколько у меня осталось предоплаченного траффика" - все это к данной системе не относится.

 

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

 

Однако, в условиях кризиса, руководство задалось мыслью - "а оно нам вообще надо? денег-то прямых не приносит... у конкурентов такой штуки нет - ну и мы обойдемся". Соответственно, хочу посоветоваться - может действительно никто не снимает статистику по физическим параметрам линий? А если кто снимает - то какие вычислительные ресурсы используете (в расчете на 1000 портов) и какую конкретно статистику снимаете?

 

Спасибо заранее!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

для снятия с DSLAM'ов физических характеристик портов:
С зикселями IES-1000/2000 дружит?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Давайте посмотрим на проблему абстрагируясь от физического смысла данных...

 

а load averages на сервере у меня зашкаливает, все тормозит

Тормозит при сборе информации или загрузка велика из-за слишком частых запросов (т.е. загрузка при генерации отчетов)?

 

соответственно, храню все это в rrd,

Есть мнение, что корявость именно тут. Все-таки многопоточный залив данных в, например, mysql куда более производительная вещь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

да, вполне
Поделитесь?

А то концентраторов море стоИт, а картинок наглядных нет :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

imho данная статистика избыточна.

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

Оборудование: Zyxel IES-1000/2000/3000, D-Link DAS-3248/3216, ECI HF4.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

- здравствуйте, у меня каждую пятницу не работает интернет...

 

Не бывает избыточных картинок. Клиентам может и не надо показывать, а вот техсаппорту - надо... Да и самому посмотреть, или кто там за линии ответственный... Чтобы иметь возможность нагнуть АТС вовремя...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

да, вполне
Поделитесь?

А то концентраторов море стоИт, а картинок наглядных нет :)

а что, конкретно интересует? данные снимаю mrtg, храню в rrd, показываю самописными скриптами. В принципе, можно все сделать на cacti...

Могу подсказать конкретные snmp oid, скриптами тоже могу поделиться, но они написаны именно под нашу модель работы, поэтому советую все же - cacti

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

соответственно, храню все это в rrd,

Есть мнение, что корявость именно тут. Все-таки многопоточный залив данных в, например, mysql куда более производительная вещь.

это почему же?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

imho данная статистика избыточна.

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

Оборудование: Zyxel IES-1000/2000/3000, D-Link DAS-3248/3216, ECI HF4.

да, конечно, на самом дсламе можно посмотреть... но, согласитесь, это не так уж удобно - отсчитывать сколько 15min интервалов назад вчера отрубился линк, а если зоопарк железок? а если на некоторых нет веб интерфейса? а если на некоторых нельзя создать аккаунт, который может только смотреть, но ничего не изменять? и все это не придуманные проблемы - а мои реалии :)

 

Кроме того 10-15min не очень хорошее разрешение - я снимаю данные каждые 2 минуты :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

статистика действительно избыточна: хочу вот отказаться от output power, но в соответствующем rfc есть еще море интересных данных, которые хотелось бы снимать - например errored seconds! от attenuation жалко отказываться - иногда при не аномально низком snr, высокий attenuation выдает проблемы линии... а snr без actual rate бессмысленен - так как snr в 10 децибел при 1 мегабите и 128K - это совсем разные линии

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

статистика действительно избыточна: хочу вот отказаться от output power, но в соответствующем rfc есть еще море интересных данных, которые хотелось бы снимать - например errored seconds! от attenuation жалко отказываться - иногда при не аномально низком snr, высокий attenuation выдает проблемы линии... а snr без actual rate бессмысленен - так как snr в 10 децибел при 1 мегабите и 128K - это совсем разные линии
Либо у вас мало портов, либо я понимаю ваш сервер :) мониторить по снмп каждый порт с интервалом в 2 минуты.

Плюс возникает проблема с проприетарными mib'ами. У ECI, Telrad свои системы управления дсламами и просто так опросить со стороны не получается.

 

На длинках техподдержка сидит с максимальными правами, железок около сотни, прецедентов не было.

 

- здравствуйте, у меня каждую пятницу не работает интернет...

 

Не бывает избыточных картинок. Клиентам может и не надо показывать, а вот техсаппорту - надо... Да и самому посмотреть, или кто там за линии ответственный... Чтобы иметь возможность нагнуть АТС вовремя...

Поднята система фиксирования ТТ (траблтикетов). Каждую пятницу говорите - назовите номер заявки. Наши станционщики сами кого угодно нагнут :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

это почему же?

В современных реализациях мускуля приняты специальные меры для увеличения производительности в таком случае. Конечно, стреляет это только при правильном выборе формата таблицы, которая хранит значения. Обычно принято пользовать полотенце вида <timestamp(double)>,<param(int)>,<value(double)>. Поле param содержит просто номер параметра (его берут из другой таблицы), а пара timestamp/param должна быть уникальным ключем. Главное - забыть про древние принципы - "один параметр - одна таблица".

 

Результат такого подхода - производительность INSERT ограничена практически только скоростью записи на диск.

 

Хотя, конечно, интересно услышать от топикстартера, что именно нагружает сервер.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

статистика действительно избыточна: хочу вот отказаться от output power, но в соответствующем rfc есть еще море интересных данных, которые хотелось бы снимать - например errored seconds! от attenuation жалко отказываться - иногда при не аномально низком snr, высокий attenuation выдает проблемы линии... а snr без actual rate бессмысленен - так как snr в 10 децибел при 1 мегабите и 128K - это совсем разные линии
Либо у вас мало портов, либо я понимаю ваш сервер :) мониторить по снмп каждый порт с интервалом в 2 минуты.

Плюс возникает проблема с проприетарными mib'ами. У ECI, Telrad свои системы управления дсламами и просто так опросить со стороны не получается.

 

На длинках техподдержка сидит с максимальными правами, железок около сотни, прецедентов не было.

 

- здравствуйте, у меня каждую пятницу не работает интернет...

 

Не бывает избыточных картинок. Клиентам может и не надо показывать, а вот техсаппорту - надо... Да и самому посмотреть, или кто там за линии ответственный... Чтобы иметь возможность нагнуть АТС вовремя...

Поднята система фиксирования ТТ (траблтикетов). Каждую пятницу говорите - назовите номер заявки. Наши станционщики сами кого угодно нагнут :)

 

Портов действительно мало :) но - растем и вот надо думать как масштабировать снятие статистики... при текущей загрузке придется ставить по quad core на каждую тысячу портов....

 

Насчет трабл тикета и нагибания атс... :) не знаю как у вас, но наши атс....

 

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

- у вас бывает, что монтеры на атс подключают нового клиента, знонят нам и говорят вход 57 выход 135... ЧТО ЭТО? попытки составить какую-то таблицу соответствия уже два года не дают никаких результатов: причем они то считают с нуля, то с одного - в зависимости от того, кто на дежурстве

и т.д....

 

и опять же если человек звонит и говорит что вчера вечером плохо качалось? сейчас достаточно глянуть на сервер статистики и там посмотреть:

1) какой тариф подключен

2) на какую скорость соединился модем

3) если они равны - значил клиент сам забил себе канал или может вирусы, если не равны:

4) глянуть график snr, attenuation

5) если есть проседание графика в тот момент:

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

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

 

и все это не зависимо от оборудования (у меня сейчас 4 типа dslam'ов и планируется закупка еще двух типов): есть веб интерфейс или нет, есть разграничение доступа или нет, какая система команд используется на железке... в таких условиях обучить суппорт смотреть картинки гораздо проще...

 

Но стоит ли это удобство одного quad core на 1000 портов? Насыщение нашего рынка где-то всего 15-20 тысяч абонентов на весь город (около 20 провайдеров).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

это почему же?

В современных реализациях мускуля приняты специальные меры для увеличения производительности в таком случае. Конечно, стреляет это только при правильном выборе формата таблицы, которая хранит значения. Обычно принято пользовать полотенце вида <timestamp(double)>,<param(int)>,<value(double)>. Поле param содержит просто номер параметра (его берут из другой таблицы), а пара timestamp/param должна быть уникальным ключем. Главное - забыть про древние принципы - "один параметр - одна таблица".

 

Результат такого подхода - производительность INSERT ограничена практически только скоростью записи на диск.

 

Хотя, конечно, интересно услышать от топикстартера, что именно нагружает сервер.

боюсь не могу точно и грамотно ответить на вопрос... в top висит куча perl процессов (по одному на каждую железку), которые по snmp собирают данные (каждые 2 минуты) и кладут в rrd. Картинки для детализированного просмотра порта генерируются cgi'кой на лету при клике на порт. Картинки для превью генерируются отдельным скриптом из cron'а по очереди раз в 5 минут - на это уходит в два раза больше cpu чем на предыдущую задачу - но отказаться от превьюшек не могу - в них основной смысл. А генерировать на лету не хочу, потому что тогда веб интерфейс будет очень сильно тормозить.

 

Может из сервера и можно выжать еще производительности, но немного не хватает соответствующих знаний и :) времени. Поделитесь хорошей ссылкой, плз, если есть. OS там freebsd, cpu - quad core, ram - 4GB

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поделитесь хорошей ссылкой, плз, если есть.

Да толку-то, если я Вас в гуглю отправлю... Конкретное решение предложить, не видя исходников как-то слабо :)

 

боюсь не могу точно и грамотно ответить на вопрос...

Давайте попробуем так определиться. Какая нагрузка на сервер (CPU load), если

 

1. Работает только система сбора (т.е. перловые сборщики). Прямо в цифрах, типа ядро1=xx%, ядро 2=yy%

2. Генерация картинок для превьюшек - сколько времени работает скрипт генерации.

3. Время генерации странички и среднее количество запросов этих страничек.

 

cpu - quad core, ram - 4GB

Мдя. Как по мне - запас мама не горюй.

 

Ориентироваться можно на вот такие цифры (правда, это не мускуль, а почти прямой слив в файлы, но современные реализации мускуля не уступают)

Первым механизмом является механизм блочного(покадрового или транзактивного) помещения данных в файлы архивов значений. Такой механизм позволяет достичь максимальной скорости архивирования, а следовательно и позволяет одновременно архивировать больше потоков данных. Опыт практического применение показал, что система K8–3000 с обычным IDE жестким диском способна архивировать до 300000 потоков данных с периодичностью 1 секунда или, система K5–400 с IDE диском (2.5») способна архивировать до 100 параметров с периодичностью 1 миллисекунда.

Вообще, рекомендую покурить - http://diyaorg.dp.ua/oscada/index.php?id=2&L=1

 

Может, натолкнет на ценные мысли. Тем более, что ребята к маю обещают стабильный релиз ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ну раз запас видится - значит буду вытягивать производительность.

 

Мне хотелось, чтоб со стороны оценили задачи / необходимое железо и поделились кто/что использует под сервер статистики и что, собственно говоря, снимает :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

- у вас бывает, что монтеры на атс подключают нового клиента, знонят нам и говорят вход 57 выход 135... ЧТО ЭТО? попытки составить какую-то таблицу соответствия уже два года не дают никаких результатов: причем они то считают с нуля, то с одного - в зависимости от того, кто на дежурстве

и т.д....

Это конечно перебор. Наши станционщики другие :) Регламент есть по подключению: продажники скидывают клиентов, админы выдают порт и пару, станционщики кроссируют именно на эту пару.

 

и опять же если человек звонит и говорит что вчера вечером плохо качалось? сейчас достаточно глянуть на сервер статистики и там посмотреть:

1) какой тариф подключен

2) на какую скорость соединился модем

3) если они равны - значил клиент сам забил себе канал или может вирусы, если не равны:

4) глянуть график snr, attenuation

5) если есть проседание графика в тот момент:

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

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

С нашими вечерними полками такие клиенты идут лесом :) В договоре написано скорость ДО ххх.

Опять же в серьезных дсламах на 1000 портов все усложняется, по снмп так просто не опросишь и есть встроенные средства мониторинга в софте для управления дсламом. В случае обращения клиента можно включить мониторинг этого порта и данные о параметрах линии будут писаться в лог, собрал лог за сутки/неделю, отключил мониторинг.

 

bsd надеюсь amd64 стоит?
имелась ввиду 64 битная версия, амд только для красоты указана :)

64 битная версия прекрасно встает на xeon'ы

Изменено пользователем p10neer

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

какие xeon'ы?! о чем вы?!!! это обычный комп, у многих, думаю, сейчас дома помощнее стоят :) , простой проц на обычной однопроцессорной материнке из ближайшего магазина - который мы СЕРВЕРом называем :))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

uname -a на этом тазике покажите.

# uname -a

FreeBSD stats 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 23 16:11:51 2008 root@stats:/usr/src/sys/i386/compile/STATS i386

 

dmesg пустой :(

 

# top

 

last pid: 19405; load averages: 1.43, 0.78, 0.68 up 97+13:14:42 15:00:44

145 processes: 4 running, 138 sleeping, 3 zombie

CPU: 50.4% user, 0.0% nice, 5.5% system, 0.1% interrupt, 44.0% idle

Mem: 650M Active, 4718M Inact, 233M Wired, 149M Cache, 112M Buf, 123M Free

Swap: 8192M Total, 8192M Free

 

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND

34362 root 1 8 0 13844K 11116K nanslp 2 44:02 1.86% perl5.8.8

34467 root 1 8 0 13816K 11084K nanslp 3 42:20 0.29% perl5.8.8

35221 root 1 8 0 13188K 10460K nanslp 2 9:30 0.29% perl5.8.8

34500 root 1 44 0 13816K 11088K select 0 39:02 0.20% perl5.8.8

34533 root 1 8 0 13844K 11116K nanslp 3 43:39 0.00% perl5.8.8

34359 root 1 8 0 13844K 11112K nanslp 2 42:46 0.00% perl5.8.8

34488 root 1 44 0 13844K 11124K select 0 42:04 0.00% perl5.8.8

34539 root 1 44 0 13868K 11132K select 0 42:02 0.00% perl5.8.8

34578 root 1 8 0 13816K 11100K nanslp 0 41:46 0.00% perl5.8.8

....

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

да, вполне
Поделитесь?

А то концентраторов море стоИт, а картинок наглядных нет :)

а что, конкретно интересует? данные снимаю mrtg, храню в rrd, показываю самописными скриптами. В принципе, можно все сделать на cacti...

Могу подсказать конкретные snmp oid, скриптами тоже могу поделиться, но они написаны именно под нашу модель работы, поэтому советую все же - cacti

Подскажите, snmp oid для zyxel ies-1000, будьте любезны

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По существу вопроса.

Зачем ломать офигенную систему, которая дает конкурентное преимущество в решении задач технической поддержки?

Это просто бред. Вы видите всю картинку - быстро решаете вопросы. Аргумент руководителя "у конкурентов этого нет и нам не нужно" загонит вас в жопу в конечном итоге.

Если жмоты, то сделайте наоборот инновацию, закаэите 2 мощных сервера с виртуалками, под которые переведите все свои сервисы. Получите удобную систему для резервирования сервисов и пониженное электропотребление в целом, да и этот вопрос закроете :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.