Всем привет!

Нужен совет по выбору биллинговой системы.
Вот список требований:

1. Возможность загрузки в БД лог-файлов произвольного вида, гибкая настройка процедуры загрузки, автоматическая загрузка через определенные промежутки времени.
2. Возможность ввода произвольного кол-ва тарифных планов, объединение их в группы; привязка ТП к порту, протоколу, ip-адресу приемника/источника.
3. Возможность применения различных тарифных планов к клиентам (идентификация клиентов на основе MAC-адреса).
4. Учет трафика в разрезе: клиентов, ip-адрес источника, ip-адрес приемника, посе-щаемых url, протокола, порта, кол-ва пакетов, кол-ва байт.
5. Возможность установки лимита трафика для каждого пользователя (как по объему, так и по стоимости); возможность автоматического отключения клиента по дости-жении лимита или введение штрафных санкций; задание ip- и MAC-адресов, про-токолов, портов, для которых применяется лимит; установка лимитов и штрафов индивидуально для клиента;
6. Отдельный учет почтового трафика.
7. Отдельный учет трафика IP-телефонии.
8. Возможность просмотра клиентом через веб-интерфейс своей статистики в любой момент времени.
9. Коррекция ошибочного ввода (загрузки), возможность повторного обсчета данных.
10. Возможность ввода дополнительного «корректирующего» трафика для согласова-ния с данными провайдера.
11. Совместимость с LDAP – каталогом (авторизация пользователей, установка лими-тов).
12. Формирование отчетности в различных разрезах, возможность создания дополни-тельных отчетов.

Почему не подходят существующие системы? Есть несколько моментов:
1. Загрузка логов. Биллинг должен работать с готовыми логами CGP (почта), netgraph (на роутере), squid (это прокси), т.е. загружать все это каждый день и обсчитывать,. В базе должна присутствовать инфа о посещенных урл (ее дает прокси).

2. Учет в разрезе портов и протоколов. Очень немногие системы позволяют это.

3.Ручной ввод дополнительного трафика (разница с данными провайдера пропорционально раскидывается на подразделения)

На текущий момент есть более 700 юзеров, работающих в различных офисах и городах.

Просмотрев около 20 биллингов (в основном сертифицированных), не нашел ни одного подходящего :(

Хотелось бы услышать мнение уважаемых гуру: реально ли найти готовую систему, отвечающую таким требованиям, или необходимо писать свою?

Maksim ChakСтартовский смотрели?
Смотрел. по цене не потянуть (вернее, начальство не позволит)

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

Guest_NewСмотрели СмартАСР?
www.smartasr.com

Почитал. При том количестве информации, что там выложена, сказать что-либо трудно. Мне эта система не подходит уже потому, что не ведет учет в разрезе портов и протоколов (про урл не говорю). Еще нужно учесть, что тарификация должна проводиться в зависимости от ip-адреса приемника (т.е. по городу одна цена, по краю - другая, за пределы края - третья). Ни в одном биллинге такая возможность не заявлена.
В общем, все больше склоняюсь к варианту собственного биллинга.

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

Guest_Newсколько Вы готовы ждать;
2-3 месяца максимум. Проблема стоит уже довольно давно.

Вот дополнительная информация к размышлению:
Есть сеть ADSL точек доступа (около 20) в различных городах, подключенных к нескольким провайдерам. На каждой точке стоит прокси (squid), через который идет _весь_ трафик. Пишется лог. Задача - собрать логи с точек, обработать, обсчитать, выдать отчетность. Через веб юзер может посмотреть свою статистику. Тарификация: абонплата или стоимость Mb/Gb, www в пределах края, www остальной.
Это то, что должен уметь делать биллинг.

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

Александр Старшинин
Так что Ваши оптимистичные взгляды на то, что задачу удастся решить несколькими килобаксами на мой взгляд абсолютно не реальна.
А при разработке с нуля ориентироваться на 2-3 месяца - это уж совсем полный оптимизм. Уверяю Вас, за это время при разработке с нуля можно только утрясти полное ТЗ на систему. А реальный результат в виде начала опытной эксплуатации можно получить только в лучшем случае месяцев через 6.
Разумеется, с нуля за 3 месяца вопрос не стоит. Но в любом случае для руководства на первом месте финансовый вопрос, и, повторюсь, возможность вложения необходимых сумм _без гарантии скорости и полноты результата_ рассмотрена не будет.

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

Господа, хотелось бы услышать ваше мнение: какое решение будет оптимальным в такой ситуации?

Александр Старшинин
Если по Вашим взглядам на рынке нет более менее подходящего для Вас решения, то у Вас нет другого пути кроме двигаться к желанной цели поэтапно (Step by Step). А именно: ставьте систему приоритетов, сроки их достижения, примерные затраты, а дальше показывайте начальству план - когда и что Вы планируете достичь и при каком бюджете. Не Вы первые, не расстраивайтесь. С Наступающим Новым годом.

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

С наступающим Вас!

cТебе надо просмотреть SchlumbergerSema .Все пункты, кроме 11 - в стандартном наборе.
А что тебе дает LDAP для биллинга? С точки зрения системы в целом - это всего лишь дополнительный Web service....

Про стоимость ничего не сказано, но, подозреваю, для нас неподъемна.
LDAP нужен для доступа к списку пользователей домена.

Прошу прощения за задержку с ответом, ситуация с проектом была не определена.
Проект на данный момент заморожен. Я так думаю, реальная потребность в биллинге была ...ммм.... не слишком высокой. Хотя,скорее всего, месяцев через 6-7 проект имеет шанс возродиться )
Благодарю всех участников темы, можно закрывать.

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

Lingate уже рассматривал. Не нашел упоминания об учете стоимости трафика (для компании это важно)

Итак, господа, прогноз оправдался - потребность в биллинге опять была озвучена. На сей раз есть заинтересованность со стороны руководства, но... грабли все те же - выбор подходящей системы. При этом тратить десятки тысяч долларов на покупку и доработку биллинга желания по-прежнему нет. Признаться, я не вижу тут оптимального решения. т.к. поступиться некоторыми требованиями (например, детализация по url) руководство опять-таки не согласно.
Что бы ВЫ делали в такой ситуации?

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

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

GaryaИзвестные мне решения - все самопальные.
Действительно, готовой системы под наши требования пока найти не удается.
Есть мнение, что можно купить систему, удовлетворяющую требованиям частично и самостоятельно ее доработать... Но также и есть сомнения в том, что эта доработка будет выполнена, поскольку компания торговая и своей команды разработчиков просто нет (думаю, что взяться за доработку в одиночку мало кто возьмется :)). Отдать доработку сторонней фирме - долго и дорого.

SQL Developer I_m_Mad
1. Загрузка логов. Биллинг должен работать с готовыми логами CGP (почта), netgraph (на роутере), squid (это прокси), т.е. загружать все это каждый день и обсчитывать,. В базе должна присутствовать инфа о посещенных урл (ее дает прокси).


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

Совсем разные вещи.

Не совсем точно выразил мысль изначально. "Загружать каждый день" не в смысле 1 раз в день.

Валентин К
Уважаемый афтар топика и комрады, добавлю.
Прочитать про архитектуру бининговых систем негде, потому что это надо видеть, а не читать про это.
Вобщем искать надо кроме билинговой системы еще и нормального архитектора систем учета. Почему учета, потому что все это классика жанра учетного, просто немного сменились декорации предметной области.


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

SQL Developer
Если руководство решало >0.5 года, нужен биллинг или нет, то
>> Большие сроки
это уже тогда >2 лет :-)

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

SQL Developer
Лучше сперва найти человека, а уже потом billing :-)
Дешевле будет :-)
Согласен. Вот только людей таких в пределах досягаемости не сказать чтобы нет, но...почти нет; естественно, привлечь такого человека к проектированию было бы неплохо, да вот только не разрабатывают биллинги у нас в Приморском крае (вернее, мне такие случаи неизвесты), поэтому можно максимум рассчитывать на человека, который _работал_ с каким-либо готовым решением, и который может _посоветовать обратить внимание_ на такою-то систему.

SQL Developer
А если сами что-то делали уже, то используете то?
Кто мешает грузить данные каждые 5 минут (как пример),
не real-time, но "hot" billing получаеться :-)
Тот биллинг был написан задолго до моего появления в компании. Сейчас он заброшен, т.к. человек, писавший его, прекратил поддержку. Почему - покрыто тайной. Знаю, что использовали оракл + пхп. Факт в том, что разговоры об использовании/реанимировании этого биллинга вожди не начинают. Почему - предпочитаю не спрашивать.

ASCRUSМы из положения вышли следующим образом:
Купили программу учета трафика TMeter, которая помимо своих логов, может по ODBC их писать в БД. Она создает в БД свои таблицы и в параллейном потоке пишет туда информацию. Даже если сервер БД проседает ил временно не доступен, трафик не теряется и потом туда будет записан. Программа имеет кучу настроек, фильтров, достаточно легка в управлении и шустро работает. В качестве СУБД взяли ASA9, добавили туда еще свои таблички, аггрегирующие трафик по различным значениям, справочные, информационные и прочие. Добавили события, которые рассчитывают аггрегаты по ночам, выгружают и пакуют в текстовые логи информацию, которая уже имеет далекую дату и не будет затребована, ну и прочее. На веб-сервисах ASA подняли выброс статистики в браузер по 80-ому порту и дополнительно прицепили наш менеджер отчетов на базе FastReport. Вроде как все работает и справляется, админы отслеживают трафик по нашим конторам и арендаторам, можно вести учет по ip, портам, хостам и т.д. При желании на базе ASA и FastReport можно легко дорабатывать функциональность в нужную сторону.
Конечно это не полноценная биллинговая система, но нам в принципе хватает за глаза.

Есть мнение, что на наших роутерах под FreeBSD эта схема не заработает... :)
Тут имхо подошли бы скрипты, скидывающие логи в центральную БД, а она бы уже "управляла" роутером в части доступа юзеров.

игра
мы как раз в Приморском крае и делали ;)
Расскажите плз поподробнее - что и как...