Читая форум начинаю немного нервничать, ведь пришло время переводить клиентов на новый биллинг, а "случайно возможные" проблемы пугают. Получается, что установка ПО Вашими сотрудниками еще не повод пить пивоLex писал(а):не всегда проявляется и не всегда приводит
Придётся еще точить и точить, даже под стандартные нужды. Взять тот же самый mpd + netflow, про который при платной установке никто даже и не намекал. Все настройки по этой теме были выужены из форумов.Спасибо, обязательно воспользуемся. Файлы первичной информации -- это iptraffic_raw_*.utm, если я правильно понимаю?Lex писал(а):Да, если сможете показать, что это проблема действительно у Вас проявляется. Сразу скажу, что для подтверждения наличия данной проблемы нужен отладочный лог-файл на момент возникновения этой проблемы, дамп базы и файлы первичной информации о трафике. Плюс нужно четко указать на неверно классифицируемый IP-адрес.dk писал(а):Значит ли это, что если я с моими 001 и 002 напишу багрепорт на известную всем ошибку с постоянно возникающей привязкой трафика к нулевому аккаунту, то будет предоставлены исправленные сборки?
ВЕЛКАМ!WhoIm писал(а):Читая форум начинаю немного нервничать, ведь пришло время переводить клиентов на новый биллинг, а "случайно возможные" проблемы пугают. Получается, что установка ПО Вашими сотрудниками еще не повод пить пивоLex писал(а):не всегда проявляется и не всегда приводит
1. Теоретически может.Wishmaster писал(а):Наверное, это сообщение не совсем в тему, но, раз уж пошла такая пьянка...
Уважаемый Lex, не могли бы вы ответить на несколько сакраментальных вопросов про аггрегацию.
1. Возможна ли такая ситуация, что статистика по трафику в монстро-таблицах (все знают, о чем идет речь), для абонента, за какой-либо период будет описана одной записью? (имеется в виду, штатная ситуация, когда биллинг сам так сделает).
2. Если ответ на первый вопрос - да, то не объясните ли вы, принцип, по которому можно привести 1000 записей к одной. (т.е. какие поля должны при этом суммироваться, какие игнориться и т.д.)
3. Я всетаки не понимаю, почему вы не хотите сделать прибамбас для переаггрегации старого трафика? Вы и так пишите, что не несете никакой ответственности, ну, добавьте дополнительный disclaimer, но хотя бы принцип напишите, ведь кроме Вас это можно только экспериментальным путем выяснить.. Я, просто, хоть убейте, не понимаю, зачем нужна почасовая статистика годичной давности.. а вот посуточная - совсем не помешает.. Вкупе с новым механизмом хранения, такой подарок от Вас был бы очень востребован...
Вот и чудненько, напишите пожалуйста, какие типы данных там бывают, и как нужно группировать данные, для каждого типа. Т.е. допустим, для типа "тра-ля-ля" суммируем поля А, а остальные поля оставляем без изменения, для типа "трам-пам-пам", суммируем поля А, поля Б, и все остальное оставляем.. В общем, в таком духе. А уж алгоритмы и разный stuff напишем сами.Lex писал(а): 3. Основная причина - техническая сложность сохранения любой информации в общем случае, необходимость пересчета входящих/исходящих остатков и следующие после потери какой бы то ни было информации претензии. Так что если кто-то хочет делать переагрегацию, может делать её на свой страх и риск сторонними средствами, а штатные средства были исключены.
Красиво всё, есть чему поучится.Aleks писал(а):А перспектива похоже сдесь
http://www.lanbilling.ru/todo.html
Очень точно поставлены даты.
Никаких тебе: "возможно", "похоже" "вероятно", "авось", "где-то после майских", "может быть", "мы постараемся" и т.д.
А вот и отсутствующий "обещанный платеж"
http://www.lanbilling.ru/doc/1.8/PAYED_ ... COM_29.pdf
Да и вебморда похоже на пхп, выводи стату как хочешь, а тут такие извращения народ юзает, что диву даешься..
Скоро будем делать скриншоты веб интерфейса, прикручивать систему распознования, обрабатывать и выдавать в удобном виде...(шутка)
Разработчики смотрят не на запросы пользователя, а на то где можно ужать функционал, чтобы потом продать его за отдельные деньги.
