Здравствуйте форумчане!
Несколько дней назад обнаружили такую штуку в паре абонентских учётках: невозможно удалить тарифную связку и сервисную связку из карточки пользователя, а также не ставится никакая блокировка на лицевой счет.
Может кто сталкивался с такой проблемой? К тому же было подмечено, что тарифная связка ссылается на старый рассчетный период, который истёк к этому времени уже несколько дней назад. Из-за этого не производится списание ежедневное списание средств со счёта.
В main.log каждую секунду сыпется это:
Mar 10 14:59:58 28a03790 TrafficAggregator: failed to process detailed traffic record: get_discount_period_iter: no such di
ERROR : Mar 10 14:59:58 28a03790 DBAExistingError: get_discount_period_iter: no such disc per 370
ERROR : Mar 10 14:59:58 28a03790 TrafficAggregator: failed to process detailed traffic record: get_discount_period_iter: no such disc per 370
ERROR : Mar 10 14:59:58 28a03790 DBAExistingError: get_discount_period_iter: no such disc per 370
ERROR : Mar 10 14:59:58 28a03790 TrafficAggregator: failed to process detailed traffic record: get_discount_period_iter: no such disc per 370
ERROR : Mar 10 14:59:58 28a03790 DBAExistingError: get_discount_period_iter: no such disc per 370
ERROR : Mar 10 14:59:58 28a03790 TrafficAggregator: failed to process detailed traffic record: get_discount_period_iter: no such disc per 370
ERROR : Mar 10 14:59:58 28a03790 DBAExistingError: get_discount_period_iter: no such disc per 370
ERROR : Mar 10 14:59:58 28a03790 TrafficAggregator: failed to process detailed traffic record: get_discount_period_iter: no such disc per 370
ERROR : Mar 10 14:59:58 28a03790 DBAExistingError: get_discount_period_iter: no such disc per 370
ERROR : Mar 10 14:59:58 28a03790 TrafficAggregator: failed to process detailed traffic record: get_discount_period_iter: no such disc per 370
ERROR : Mar 10 14:59:58 28a03790 DBAExistingError: get_discount_period_iter: no such disc per 370
ERROR : Mar 10 14:59:58 28a03790 TrafficAggregator: failed to process detailed traffic record: get_discount_period_iter: no such disc per 370
ERROR : Mar 10 14:59:58 28a03790 DBAExistingError: get_discount_period_iter: no such disc per 370
..........
В данном отрывке видно, что UTM пытается что-то обработать по расчетному периоду с id 370, вот он то и истёк уже несколько дней назад.
В debug.log пишет:
ERROR : Mar 10 15:02:10 28a03790 DBAExistingError: get_discount_period_iter: no such disc per 370
ERROR : Mar 10 15:02:10 28a03790 TrafficAggregator: failed to process detailed traffic record: get_discount_period_iter: no such disc per 370
ERROR : Mar 10 15:02:10 28a03790 DBAExistingError: get_discount_period_iter: no such disc per 370
ERROR : Mar 10 15:02:10 28a03790 TrafficAggregator: failed to process detailed traffic record: get_discount_period_iter: no such disc per 370
..........
Еще есть один абонент, у которого нет ни тарифа, ни сервисной связки, на его лицевой счет не ставится никакая блокировка и ко всему этому еще у него продолжает расти минус, хотя никакого основания для этого нет.
Подскажите какие-нибудь варианты куда копать!?
P.S. FreeBSD 7.2-RELEASE/UTM 5.2.1-008
Проблема с учётками абонентов
Проблема с учётками абонентов
Последний раз редактировалось NeXuSs Пт мар 11, 2011 09:05, всего редактировалось 1 раз.
У нас так заведено, что расчетный период вообще один - сутки. И на всех абонентах стоит этот рп.
Что касается абонента, у которого не указан ни тарифный план, ни сервисная связка, а списание все равно идет, то у него конечно никаких периодов нет, так как не к чему просто его привязать, тем не менее, если выставить его баланс >=0, то на следующий день он уйдет в минус, который будет увеличиваться день ото дня.
Что касается "проблемных" абонентов, то у тех, у кого ничего не удаляется, как раз "застрял" старый рп с id 370, похоже, что в логи про них пишется.у этого человека расчетный период выставлен? и правильный ли он ?
Что касается абонента, у которого не указан ни тарифный план, ни сервисная связка, а списание все равно идет, то у него конечно никаких периодов нет, так как не к чему просто его привязать, тем не менее, если выставить его баланс >=0, то на следующий день он уйдет в минус, который будет увеличиваться день ото дня.
Для выяснения решил разобрать конкретного абонента.
Просмотрел все debug.log'и, а их 30 с разными датами, с grep'ом по его id лицевого счета.
Если у "нормального" абонента видно, при помощи выборки как происходит списание (запись типа UPDATE accounts SET balance='...' WHERE id = '...'), то проблемные абоненты вообще никак не фигурируют в дебаге. То есть, такое ощущение, что как сменился когда-то расчетный период, что-то сглючило, так с тех пор про этих абонентов ничего не видно и не слышно в дебаге.
Единственное, в первом посте можно видеть ругань как раз по поводу старого расчетного периода.
Так же просмотрел записи в дебаге по закрытию текущего РП, ввод в действие нового и списание средств в соответствии с ним, но, опять же, проблемные учетки в этом процессе не фигурируют.
Складывается такое ощущение, что в свое время, когда закрывался РП с id 370 и вступал в силу новый с id 371, что-то пошло не так, не для всех этот процесс прошел успешно и теперь учеткам абонентов, которым "повезло" не присваивается новый РП и, соответственно, не списывается периодическая составляющая стоимости.
Просмотрел все debug.log'и, а их 30 с разными датами, с grep'ом по его id лицевого счета.
Если у "нормального" абонента видно, при помощи выборки как происходит списание (запись типа UPDATE accounts SET balance='...' WHERE id = '...'), то проблемные абоненты вообще никак не фигурируют в дебаге. То есть, такое ощущение, что как сменился когда-то расчетный период, что-то сглючило, так с тех пор про этих абонентов ничего не видно и не слышно в дебаге.
Единственное, в первом посте можно видеть ругань как раз по поводу старого расчетного периода.
Так же просмотрел записи в дебаге по закрытию текущего РП, ввод в действие нового и списание средств в соответствии с ним, но, опять же, проблемные учетки в этом процессе не фигурируют.
Складывается такое ощущение, что в свое время, когда закрывался РП с id 370 и вступал в силу новый с id 371, что-то пошло не так, не для всех этот процесс прошел успешно и теперь учеткам абонентов, которым "повезло" не присваивается новый РП и, соответственно, не списывается периодическая составляющая стоимости.
Сегодня проблема со старым ТП с id=370 решилась сама собой 
У тех абонентов, у которых был старый расчетный период сегодня исчезли тарифный план и сервисная связка, соответственно со всеми установками айпишника, логина и пароля. При анализе логов увидели, что писанина по поводу старого тарифного плана прекратилась, то есть период с id=370 перестал упоминаться.
Это повлекло за собой удаление выше указанных параметров у проблемных абонентов.
Ну, по-идее, все верно, так как id ТП был давно устаревший, а на новый в рабочем порядке в свое время не было переключения, то просто произошло удаление ТП.
Не понятно только что именно произошло, во всех логах - тишина. Посмотрим проявится-ли проблема в дальнейшем.
У тех абонентов, у которых был старый расчетный период сегодня исчезли тарифный план и сервисная связка, соответственно со всеми установками айпишника, логина и пароля. При анализе логов увидели, что писанина по поводу старого тарифного плана прекратилась, то есть период с id=370 перестал упоминаться.
Это повлекло за собой удаление выше указанных параметров у проблемных абонентов.
Ну, по-идее, все верно, так как id ТП был давно устаревший, а на новый в рабочем порядке в свое время не было переключения, то просто произошло удаление ТП.
Не понятно только что именно произошло, во всех логах - тишина. Посмотрим проявится-ли проблема в дальнейшем.