Посоветуйте, сколько взять денег за "prebilling"
Бери 1000000$, не ошибешься.
P.S. Если ты не можешь сам оценить стоимость подобной работы, то скорее всего ты не готов к ее реализации.
P.S. Если ты не можешь сам оценить стоимость подобной работы, то скорее всего ты не готов к ее реализации.
сколько времени ты собираешься потратить?
по примерным прикидкам - 2 недели/2 человека...
Это реальное время.
Это реальное время.
ошибусь явно, ибо меня пошлют нах...
И я могу оценить стоимость своей работы, боюсь только у них ленег не хватит...
И я могу оценить стоимость своей работы, боюсь только у них ленег не хватит...
Я бы попросил две-четыре штуки за проект. А дальше бы поторговался
$ ?
А разве такого готового нет, ну кроме может конфигурации через веб?
конечно есть, тебе ж написали -
2 недели/2 человека...
Это реальное время.
если работа 2 недели на двоих фул-тайм, то чего тут думать. Бери свою месячную зарплату с небольшим бонусом. В принципе супер каких знаний не нужно, поэтому $800-1000 будет нормально.
Ну а на двоих - 2000
вроде бы достаточно простая задача агрегации....
там писать-то делов действительно на неделю, если не вникать в netfow подробно, и не писать биллинг, взять спокойно flow-tools
и пустить написанный код по GPL, все равно фирме прийдется исходники отдать
там писать-то делов действительно на неделю, если не вникать в netfow подробно, и не писать биллинг, взять спокойно flow-tools
и пустить написанный код по GPL, все равно фирме прийдется исходники отдать
Задача-то простая, только результируящая программа должна работать как часы, очобенно если учесть то, что на этом висят все финансы компании...
Кроме того это только первый этап, планов у них куча, включая полный мониторинг сети (вот не устраивает их nagious!). То есть писать придётся в контексте более широкой и глобальной (а значит и более высокооплачиваемой) задачи. В то же время брать деньги за всё сразу не хочется - по понятным причинам.
Кроме того это только первый этап, планов у них куча, включая полный мониторинг сети (вот не устраивает их nagious!). То есть писать придётся в контексте более широкой и глобальной (а значит и более высокооплачиваемой) задачи. В то же время брать деньги за всё сразу не хочется - по понятным причинам.
Честно говоря не вник в суть задачи...
>Задача: "сворачивание" и "уплотнение" потока netflow по пути от цисок к биллинговой системе
Ok.
Могу тебе сказать, что забитый STM-1 дает загрузку flow примерно в 0,5 мбайта в сек.
Любое современное железо справляется с таким потоком на ура, буть у тебя хоть STM-16.
(Так хакеры молчат, так пример средний, то что можно получить flow с STM в размере того же STM и как я знаю).
>нужно свернуть все строки от одного источника(клиента) в одну
Это как ?
А если он в разное время к источнику обращался ?
И вообще какой смысл хранить все flow source всегда ?
Похранил месяц, потом очистил и оставил лишь почасовку/подневновку/помесячку и т.д.
>Кроме того нужно сворачивать усреднённую информацию по каждому пользователю по дням/месяцам и т.д. в БД, для статистики.
Вот тут рекомендую под видом клиента обратится в Cboss и взять у них тех. документацию на Абсолют.
Расписано всё очень хорошо
.
>Задача: "сворачивание" и "уплотнение" потока netflow по пути от цисок к биллинговой системе
Ok.
Могу тебе сказать, что забитый STM-1 дает загрузку flow примерно в 0,5 мбайта в сек.
Любое современное железо справляется с таким потоком на ура, буть у тебя хоть STM-16.
(Так хакеры молчат, так пример средний, то что можно получить flow с STM в размере того же STM и как я знаю).
>нужно свернуть все строки от одного источника(клиента) в одну
Это как ?
А если он в разное время к источнику обращался ?
И вообще какой смысл хранить все flow source всегда ?
Похранил месяц, потом очистил и оставил лишь почасовку/подневновку/помесячку и т.д.
>Кроме того нужно сворачивать усреднённую информацию по каждому пользователю по дням/месяцам и т.д. в БД, для статистики.
Вот тут рекомендую под видом клиента обратится в Cboss и взять у них тех. документацию на Абсолют.
Расписано всё очень хорошо
.>Вот тут рекомендую под видом клиента обратится в Cboss и взять у них тех. документацию на Абсолют.
>Расписано всё очень хорошо .
Можно попробовать. Но суть том что от одного клиента приходит очень много строчек netflow с одним и тем же полем адресс/номер, вот по сути их и нужно свернуть в одну, проссумировав траффик. Возможно что-то ещё. Это как бы "пре-биллинг", если его можно так назвать. Фильтрация происходит потоком, а биллинг получает свои данные раз в день...
Вобще по фактам там речь идёт о гигобайтах информации netflow...
>Расписано всё очень хорошо .
Можно попробовать. Но суть том что от одного клиента приходит очень много строчек netflow с одним и тем же полем адресс/номер, вот по сути их и нужно свернуть в одну, проссумировав траффик. Возможно что-то ещё. Это как бы "пре-биллинг", если его можно так назвать. Фильтрация происходит потоком, а биллинг получает свои данные раз в день...
Вобще по фактам там речь идёт о гигобайтах информации netflow...
>Но суть том что от одного клиента приходит очень много строчек netflow с одним и тем же полем адресс/номер
Вообще-то как раз этот параметр на Cisco ставится в настройках, чтоб не летел отчет о каждом пакете.
Причем регулируется он очень широких пределах.
Вообщем я это к чему, на больших временных объемах из-за большого объема выискивать в таблице одинаковые пары просто неэффективно по времени, затраченному на данную операцию, чем делать сразу общие поминутки, почасовки и т.д.
Проверено
Вообще-то как раз этот параметр на Cisco ставится в настройках, чтоб не летел отчет о каждом пакете.
Причем регулируется он очень широких пределах.
Вообщем я это к чему, на больших временных объемах из-за большого объема выискивать в таблице одинаковые пары просто неэффективно по времени, затраченному на данную операцию, чем делать сразу общие поминутки, почасовки и т.д.
Проверено
> в таблице одинаковые пары просто неэффективно по времени,
Это если искать в таблице, а если делать в процессе обработки потока зная заранее возможные значения полей (собственно пользователей) - то вобще-то очень халявно и халявнее это сделать предварительно, чем загрузить этим биллинг... Может я и ошибаюсь.
Насчёт настройки цисок - я не в курсе, ничего сказать пока не могу...
Это если искать в таблице, а если делать в процессе обработки потока зная заранее возможные значения полей (собственно пользователей) - то вобще-то очень халявно и халявнее это сделать предварительно, чем загрузить этим биллинг... Может я и ошибаюсь.
Насчёт настройки цисок - я не в курсе, ничего сказать пока не могу...
Даже у нас, на сравнительно небольших объемах по сравнению скажем со средним Российским оператором, flow source в сутки занимает ~5 млн. записей. Из такого объема конечно можно выдергивать нужную тебе информацию, но как-то сортировать или группировать его уже просто бесполезно-абсолютно бесполезная трата процессорного времени.
Так суть-то и состоит в том, чтобы обрабатывать этот "поток на лету" - приходит запись, мы определяем пользователя и суммируем с уже существующей записью в таблице плюс ещё как-то откладываем информацию для мониторинга (скажем в формате mrtg). Почти никаких затрат! А когда в три часа ночи данные потребуются биллингу - мы их вытаскиваем из БД и отдаём, тлько строчек netflow уже будет на несколько порядков меньше!
Идея конечно не нова.
Она даже реализована. UTM5.
Они правда ушли дальше-они даже в real time деньги считают.
Но скажу по секрету, серьезные операторские решения, основанные на этом принципе я не видел.
И скажу почему.
Данный принцип оптимизации хорошо работатет в случае flow потока с одного маршрутизатора, а вот если у тебя потоков несколько, так как несколько и маршрутизаторов, причем в зависимости от того, кто клиент, в некоторорых случаях надо его не считать, а в другом общитывать - эта идея крайне сложна в реализации.
Она даже реализована. UTM5.
Они правда ушли дальше-они даже в real time деньги считают.
Но скажу по секрету, серьезные операторские решения, основанные на этом принципе я не видел.
И скажу почему.
Данный принцип оптимизации хорошо работатет в случае flow потока с одного маршрутизатора, а вот если у тебя потоков несколько, так как несколько и маршрутизаторов, причем в зависимости от того, кто клиент, в некоторорых случаях надо его не считать, а в другом общитывать - эта идея крайне сложна в реализации.
А в чём проблема с несколькими маршрутизаторами?
Ну несколько потоков, ну может придётся какой-нибудь мультитрэд организовать, но только для приёма, несколько потоков всегда легко слить в один.
А не считать или обсчитывать клиента - разве как раз в такой схеме не проще это сделать? Перед выдачей информации биллингу децл поперемножать все строчки....
Ну несколько потоков, ну может придётся какой-нибудь мультитрэд организовать, но только для приёма, несколько потоков всегда легко слить в один.
А не считать или обсчитывать клиента - разве как раз в такой схеме не проще это сделать? Перед выдачей информации биллингу децл поперемножать все строчки....
Разные настройки маршрутизаторов, разные тайминги, поэтому не имея полной раскладки понять, где же искомое не так просто, как кажется на первый взгляд.
и следовательно нужно просить больше денег!
Понял я примерно...
Понял я примерно...
За прикручивание web frontendа к flow-tools я бы много денег не брал. Во всяком случае меньше, чем говорят в этом треде. Но ведь работодатель может не знать, что задача уже решена в нескольких open source продуктах и в десятках closed source. В таком случае можно заломить сколько совесть позволяет.
Могу тебе сказать, что забитый STM-1 дает загрузку flow примерно в 0,5 мбайта в сек.Объем потока эскпортов только косвенно зависит от объема канал на котором считается трафик.
Любое современное железо справляется с таким потоком на ура, буть у тебя хоть STM-16.
(Так хакеры молчат, так пример средний, то что можно получить flow с STM в размере того же STM и как я знаю).
Разные настройки маршрутизаторовСам себе виноват.
разные таймингичто имеется в виду?
поэтому не имея полной раскладки понять, где же искомое не так просто, как кажется на первый взгляд.Что такое полная раскладка? На мой первый взгляд всё так же просто. Покажи мне где не просто.
> На мой первый взгляд всё так же просто. Покажи мне где не просто.
Может быть всякие штуки вроде не считать трафик два раза, если вдруг он пошёл по резервному маршруту через два маршрутизатора вместо одного?
Может быть всякие штуки вроде не считать трафик два раза, если вдруг он пошёл по резервному маршруту через два маршрутизатора вместо одного?
> Что такое полная раскладка?
Наш весёлый друг наверное решил наконец обосновать необходимость хранения записей netflow полностью,
Наш весёлый друг наверное решил наконец обосновать необходимость хранения записей netflow полностью,
Именно.
Алгоритмы такого разбора уже есть. Ничего военного.
Оставить комментарий
hashion
Задача: "сворачивание" и "уплотнение" потока netflow по пути от цисок к биллинговой системе, цель - облегчить процесс биллинга. Netflow представляют собой записи (строки) с указанием того, кто куда чего и сколько наговорил/накачал, нужно свернуть все строки от одного источника(клиента) в одну. Конфигурация сего осуществляется через веб. Потом все эти строки запихиваются в БД, и достаются раз в день по мере востребования биллинговой системой. Кроме того нужно сворачивать усреднённую информацию по каждому пользователю по дням/месяцам и т.д. в БД, для статистики.Среда: FreeBSD/Linux, C++, postgres, php
Посоветуйте, сколько можно взять с достаточно состоятельной фирмы-провайдера за такую штукенцию?