survivor Опубликовано 13 апреля, 2009 · Жалоба Доброго времени суток! Помогите, пожалуйста, добрым советом :) Так уж получилось, что я на этапе внедрения в нашей компании услуг ADSL поднял и настроил сервер для снятия с DSLAM'ов физических характеристик портов: - SNR, - attenuation, - output power, - connection speed, - загрузка порта по скорости (octets/time) соответственно, храню все это в rrd, рисую графики по всем параметрам, сделал доступ для технического саппорта (чтоб при звонке - "у меня не качается или у меня замигала какая-то лампочка на этой штуке" - могли однозначно диагностировать проблему) и сделал специальную страничку для адекватных клиентов, где они, авторизовавшись, могут сами смотреть все эти параметры... Хочу подчеркнуть - все это НИКАК не связано с биллингом: вопросы клиентов про текущий баланс, или "сколько и чего я скачал", или "как мне поменять пароль на подключение" или "сколько у меня осталось предоплаченного траффика" - все это к данной системе не относится. Все это прекрасно работает: клиенты и саппорт пользуются, но, вот пришло время очередного расширения, куча новых железок... а load averages на сервере у меня зашкаливает, все тормозит - вообщем нужно соответствующее расширение сервера статистики. Однако, в условиях кризиса, руководство задалось мыслью - "а оно нам вообще надо? денег-то прямых не приносит... у конкурентов такой штуки нет - ну и мы обойдемся". Соответственно, хочу посоветоваться - может действительно никто не снимает статистику по физическим параметрам линий? А если кто снимает - то какие вычислительные ресурсы используете (в расчете на 1000 портов) и какую конкретно статистику снимаете? Спасибо заранее! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zlobar Опубликовано 13 апреля, 2009 · Жалоба для снятия с DSLAM'ов физических характеристик портов:С зикселями IES-1000/2000 дружит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 13 апреля, 2009 · Жалоба да, вполне Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Rst7.CBSIE Опубликовано 13 апреля, 2009 · Жалоба Давайте посмотрим на проблему абстрагируясь от физического смысла данных... а load averages на сервере у меня зашкаливает, все тормозит Тормозит при сборе информации или загрузка велика из-за слишком частых запросов (т.е. загрузка при генерации отчетов)? соответственно, храню все это в rrd, Есть мнение, что корявость именно тут. Все-таки многопоточный залив данных в, например, mysql куда более производительная вещь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zlobar Опубликовано 13 апреля, 2009 · Жалоба да, вполнеПоделитесь?А то концентраторов море стоИт, а картинок наглядных нет :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
p10neer Опубликовано 13 апреля, 2009 · Жалоба imho данная статистика избыточна. При звонке клиента, техподдержка всегда может посмотреть данную информацию, непосредственно на порту оборудования. Есть статистика за последние 15 мин, за последний час, за 24 часа, за прошлые 24 часа. Единственное, это не касается загрузки порта по скорости. Такую информацию можно посмотреть не на всех дсламах. Оборудование: Zyxel IES-1000/2000/3000, D-Link DAS-3248/3216, ECI HF4. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 13 апреля, 2009 · Жалоба - здравствуйте, у меня каждую пятницу не работает интернет... Не бывает избыточных картинок. Клиентам может и не надо показывать, а вот техсаппорту - надо... Да и самому посмотреть, или кто там за линии ответственный... Чтобы иметь возможность нагнуть АТС вовремя... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 13 апреля, 2009 · Жалоба да, вполнеПоделитесь?А то концентраторов море стоИт, а картинок наглядных нет :) а что, конкретно интересует? данные снимаю mrtg, храню в rrd, показываю самописными скриптами. В принципе, можно все сделать на cacti... Могу подсказать конкретные snmp oid, скриптами тоже могу поделиться, но они написаны именно под нашу модель работы, поэтому советую все же - cacti Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
t0ly Опубликовано 13 апреля, 2009 · Жалоба соответственно, храню все это в rrd, Есть мнение, что корявость именно тут. Все-таки многопоточный залив данных в, например, mysql куда более производительная вещь. это почему же? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 13 апреля, 2009 · Жалоба imho данная статистика избыточна.При звонке клиента, техподдержка всегда может посмотреть данную информацию, непосредственно на порту оборудования. Есть статистика за последние 15 мин, за последний час, за 24 часа, за прошлые 24 часа. Единственное, это не касается загрузки порта по скорости. Такую информацию можно посмотреть не на всех дсламах. Оборудование: Zyxel IES-1000/2000/3000, D-Link DAS-3248/3216, ECI HF4. да, конечно, на самом дсламе можно посмотреть... но, согласитесь, это не так уж удобно - отсчитывать сколько 15min интервалов назад вчера отрубился линк, а если зоопарк железок? а если на некоторых нет веб интерфейса? а если на некоторых нельзя создать аккаунт, который может только смотреть, но ничего не изменять? и все это не придуманные проблемы - а мои реалии :) Кроме того 10-15min не очень хорошее разрешение - я снимаю данные каждые 2 минуты :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 13 апреля, 2009 · Жалоба статистика действительно избыточна: хочу вот отказаться от output power, но в соответствующем rfc есть еще море интересных данных, которые хотелось бы снимать - например errored seconds! от attenuation жалко отказываться - иногда при не аномально низком snr, высокий attenuation выдает проблемы линии... а snr без actual rate бессмысленен - так как snr в 10 децибел при 1 мегабите и 128K - это совсем разные линии Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
p10neer Опубликовано 13 апреля, 2009 · Жалоба статистика действительно избыточна: хочу вот отказаться от output power, но в соответствующем rfc есть еще море интересных данных, которые хотелось бы снимать - например errored seconds! от attenuation жалко отказываться - иногда при не аномально низком snr, высокий attenuation выдает проблемы линии... а snr без actual rate бессмысленен - так как snr в 10 децибел при 1 мегабите и 128K - это совсем разные линииЛибо у вас мало портов, либо я понимаю ваш сервер :) мониторить по снмп каждый порт с интервалом в 2 минуты.Плюс возникает проблема с проприетарными mib'ами. У ECI, Telrad свои системы управления дсламами и просто так опросить со стороны не получается. На длинках техподдержка сидит с максимальными правами, железок около сотни, прецедентов не было. - здравствуйте, у меня каждую пятницу не работает интернет... Не бывает избыточных картинок. Клиентам может и не надо показывать, а вот техсаппорту - надо... Да и самому посмотреть, или кто там за линии ответственный... Чтобы иметь возможность нагнуть АТС вовремя... Поднята система фиксирования ТТ (траблтикетов). Каждую пятницу говорите - назовите номер заявки. Наши станционщики сами кого угодно нагнут :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Rst7.CBSIE Опубликовано 14 апреля, 2009 · Жалоба это почему же? В современных реализациях мускуля приняты специальные меры для увеличения производительности в таком случае. Конечно, стреляет это только при правильном выборе формата таблицы, которая хранит значения. Обычно принято пользовать полотенце вида <timestamp(double)>,<param(int)>,<value(double)>. Поле param содержит просто номер параметра (его берут из другой таблицы), а пара timestamp/param должна быть уникальным ключем. Главное - забыть про древние принципы - "один параметр - одна таблица". Результат такого подхода - производительность INSERT ограничена практически только скоростью записи на диск. Хотя, конечно, интересно услышать от топикстартера, что именно нагружает сервер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 14 апреля, 2009 · Жалоба статистика действительно избыточна: хочу вот отказаться от 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 провайдеров). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 14 апреля, 2009 · Жалоба это почему же? В современных реализациях мускуля приняты специальные меры для увеличения производительности в таком случае. Конечно, стреляет это только при правильном выборе формата таблицы, которая хранит значения. Обычно принято пользовать полотенце вида <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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Rst7.CBSIE Опубликовано 14 апреля, 2009 · Жалоба Поделитесь хорошей ссылкой, плз, если есть. Да толку-то, если я Вас в гуглю отправлю... Конкретное решение предложить, не видя исходников как-то слабо :) боюсь не могу точно и грамотно ответить на вопрос... Давайте попробуем так определиться. Какая нагрузка на сервер (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 Может, натолкнет на ценные мысли. Тем более, что ребята к маю обещают стабильный релиз ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikevlz Опубликовано 14 апреля, 2009 · Жалоба bsd надеюсь amd64 стоит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 14 апреля, 2009 · Жалоба quad core = intel freebsd = 7.0 stable Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 14 апреля, 2009 · Жалоба ну раз запас видится - значит буду вытягивать производительность. Мне хотелось, чтоб со стороны оценили задачи / необходимое железо и поделились кто/что использует под сервер статистики и что, собственно говоря, снимает :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
p10neer Опубликовано 14 апреля, 2009 (изменено) · Жалоба - у вас бывает так, что монтеры на кроссе по собственной инициативе выдирают клиента из одного порта и втыкают в другой... и не информируют вас об этом. Помогает сервер статистики - просматриваем, в тот же момент когда на одном порту график остановился - где он появился, графики сильно выручают- у вас бывает, что монтеры на атс подключают нового клиента, знонят нам и говорят вход 57 выход 135... ЧТО ЭТО? попытки составить какую-то таблицу соответствия уже два года не дают никаких результатов: причем они то считают с нуля, то с одного - в зависимости от того, кто на дежурстве и т.д.... Это конечно перебор. Наши станционщики другие :) Регламент есть по подключению: продажники скидывают клиентов, админы выдают порт и пару, станционщики кроссируют именно на эту пару. и опять же если человек звонит и говорит что вчера вечером плохо качалось? сейчас достаточно глянуть на сервер статистики и там посмотреть:1) какой тариф подключен 2) на какую скорость соединился модем 3) если они равны - значил клиент сам забил себе канал или может вирусы, если не равны: 4) глянуть график snr, attenuation 5) если есть проседание графика в тот момент: 6) посмотреть характер изменения графика: может только по вечерам - значит сосед включает мега дрель рядом плохо изолированным проводом или вчера в это время шел дождь и залил шкаф, если колебаний нет, просто упал snr - звоним монтерам - пусть проверяют линии и т.д. 7) сравнить абсолютные величины с соседними показателями где качают хорошо и узнать какой snr вообще можно вытянуть на кабельной инфраструктуре той атс... С нашими вечерними полками такие клиенты идут лесом :) В договоре написано скорость ДО ххх.Опять же в серьезных дсламах на 1000 портов все усложняется, по снмп так просто не опросишь и есть встроенные средства мониторинга в софте для управления дсламом. В случае обращения клиента можно включить мониторинг этого порта и данные о параметрах линии будут писаться в лог, собрал лог за сутки/неделю, отключил мониторинг. bsd надеюсь amd64 стоит?имелась ввиду 64 битная версия, амд только для красоты указана :)64 битная версия прекрасно встает на xeon'ы Изменено 14 апреля, 2009 пользователем p10neer Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 14 апреля, 2009 · Жалоба какие xeon'ы?! о чем вы?!!! это обычный комп, у многих, думаю, сейчас дома помощнее стоят :) , простой проц на обычной однопроцессорной материнке из ближайшего магазина - который мы СЕРВЕРом называем :)) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikevlz Опубликовано 14 апреля, 2009 · Жалоба uname -a на этом тазике покажите. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 14 апреля, 2009 · Жалоба 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 .... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
astrolon Опубликовано 30 апреля, 2014 · Жалоба да, вполнеПоделитесь?А то концентраторов море стоИт, а картинок наглядных нет :) а что, конкретно интересует? данные снимаю mrtg, храню в rrd, показываю самописными скриптами. В принципе, можно все сделать на cacti... Могу подсказать конкретные snmp oid, скриптами тоже могу поделиться, но они написаны именно под нашу модель работы, поэтому советую все же - cacti Подскажите, snmp oid для zyxel ies-1000, будьте любезны Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 30 апреля, 2014 · Жалоба По существу вопроса. Зачем ломать офигенную систему, которая дает конкурентное преимущество в решении задач технической поддержки? Это просто бред. Вы видите всю картинку - быстро решаете вопросы. Аргумент руководителя "у конкурентов этого нет и нам не нужно" загонит вас в жопу в конечном итоге. Если жмоты, то сделайте наоборот инновацию, закаэите 2 мощных сервера с виртуалками, под которые переведите все свои сервисы. Получите удобную систему для резервирования сервисов и пониженное электропотребление в целом, да и этот вопрос закроете :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...