LINUX.ORG.RU

Биллинговые системы: Чем траф считать народ?


0

0

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

собственно, чем лучше считать траф?

разумеется, определимся с окружением:
1. система - Любая NIX (например, RedHat >v4 | Fedora 6)
2. локальная сеть/число пользователей - большая/огромное постоянно изменяющееся
3. конфигурирование - гибкое... оччень гибкое - от ввода различного тарифа/правила для конкретного пользователя(подсетки, другого условия) до возможности писать свои модуля и прочее
4. хорошо документированная
5. трудно-роняемая, и если что - быстро подымаемая с бэкапа за считанные минуты снуля...

*. большинством используемая и всеми любимая ;)

спасибо!

anonymous

Ответ на: комментарий от nicholas

>Есть такая приколная программ Ethereal
ага, есть - только какое отношение она имеет к сабжу? вы ей считаете трафик ? )))))

dreamer ★★★★★
()

тут на самом деле не указано много важных параметров: способ авторизации юзеров, кол-во каналов,огромное кол-во юзеров - это сколько ?

откуда будет снимтаься трафик (cisco,linux..etc) ?

dreamer ★★★★★
()

в свое время начал искать биллинговую систему для нашего предприятия (года два назад). Ну уж очень мне не хотелось админить доставшийся в наследство ВинРут. В итоге перебрал несколько штук, но так ничего подходящего именно для моей ситуации не нашел. Либо какие-то вещи были выполненны совершенно не так, как мне надо, либо чего-то не хватало. В итоге уже два года работает связка (пишу полностью с сервисами): squid+postfix+fetchmail - серверная часть (DNS и DHCP и все остальное не пишу т.к. к теме вообще не имеет отношения); Билингом занимается crond :) Само сабой не сам. Скрипты на перле, для разбора логов прокси и почтовика. Дальше все пихается в MySQL. Дальше идет обработка полученных данных, формирование отчета, который выкладывается как страничка для apache и на один из сетевых дисков файл-сервера, идет сравнение лимитов и при необходимости блокировка юзеров, перебравших свой трафик. Трафик считается только входящий: почта+прокси, авторизайия по имени пользователя. Блокирование (ну и само собой разбор логов) раз в час. В моем случае чаще не нужно. Хотя при большом желании можно было бы и чаще. В итоге это дело работает уже два года без особых нареканий. Конечно всплывали иногда некоторые баги, но исправляемые. Единственное, что нет к этому делу нормального интерфейса, а все приходится ручками править. Ну вообщем в идеалогии SlackWare :) Ну и на самом серваке именно слака и стоит. А написать что либо более дружественное... ну не програмист я, не програмист. Мне и это эело с немалым трудом удалось написать

deys ★★★
()
Ответ на: комментарий от dreamer

>тут на самом деле не указано много важных параметров
зато, указано, что система должна быть модульной с возможностью гибкой конфигурации (например, стратегия аутентификации юзеров, определяется в каком-либо interception filter в самописном плагине)

>откуда будет снимтаься трафик
так же, желательно не привязываться к конкретному "DataSource", чисто для конкретики - с интерфейсов шлюза, который под Fedora >= 2.6.16 (или RedHat 4)

>огромное кол-во юзеров - это сколько
10000 ;)

anonymous
()

Плох тот админ, который не написал свою систему учета трафика :)

Но это если не нужно одобрение минсвязи...

sergej ★★★★★
()
Ответ на: комментарий от sergej

> Плох тот админ, который не написал свою систему учета трафика :) плох тот админ, который всех на свой софт присадить хочет ;) ИМХО, любой самописный софт подобного масштаба (с вышеназванным ф-лом) весть нуждающая в постоянном суппорте, поддержке всяческой и прочими времяизливаниями ещё и на то, на что обычо его "время" никогда не зватает...

давайте не будем изобретать велосипед? ;)

anonymous
()
Ответ на: комментарий от anonymous

"Иногда проще изобрести свой велосипед, чем разбираться с чужим" (ц) где-то я это уже говорил :)

биллинг работающей с 200 клиентами - это примерно 5 килобайт скриптов.

sergej ★★★★★
()
Ответ на: комментарий от sergej

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

собственно, если серьёзно, кто что скажет о Lan Billing ?????

anonymous
()
Ответ на: комментарий от sergej

> давайте не будем изобретать велосипед? ;)

мне всетаки было проще свой велосипед изобрести, чем чей-то под себя подстраивать

> биллинг работающей с 200 клиентами - это примерно 5 килобайт скриптов.

у меня порядка 35 для самого биллинга, и еще около 50 для более наглядного просмотра статистики работы, но уже только для меня лично.

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

я, к примеру, свой "велосипед" не собираюсь никому впаривать:) Он у меня работает себе и все. То, что мне нужно делает. И не нужно за ним постоянный супорт. А ситуация, как у меня, может и ни у кого не возникнуть. А переписывать под универсал я явно не собираюсь.

deys ★★★
()
Ответ на: комментарий от deys

+1

написание билинга - это чуть сложнее файлов конфигурации.

Никто же не делает дистрибутивов из конфигов. Разве что сложные конфиги выкладывают куда-нибудь...

sergej ★★★★★
()
Ответ на: комментарий от anonymous

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.