BiTel

Был ошибочно изменен номер интерфейса в привязках (добавились новые интерфейсы на cisco, произошла их перенумерация, т.е. был 76, а стал 83).

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

Решил вернуть интерфейс на 76-ой в договоре и переобсчетать за февраль.
Результат нулевой!

Как разрешить?

Вы обработку логов именно запускали?

Добавил в обработку источник, на котором интерфейс поменялся за февраль месяц.

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

Выложите скрин как интерфейс заведен в редакторе, как привязан в договоре, и примеры строк из лога, которые должны попасть на этот интерфейс.
В netflow.out коллектора ошибок нет? Может опять ругается на что..

в редакторе



как привязан в договоре



обработка:



В netflow.out коллектора ошибок нет.

В логе:

Timestamp FromIp FromPort ToIp ToPort Bytes FromIface ToIface
1203080400 213.180.214.31 80 89.113.121.46 37086 397 76 20
1203080400 194.186.55.121 80 89.113.121.46 37082 3207 76 20
1203080400 194.186.55.121 80 89.113.121.46 37083 3247 76 20
1203080400 194.186.55.121 80 89.113.121.46 37084 24776 76 20
1203080400 194.186.55.121 80 89.113.121.46 37085 24776 76 20
1203080400 89.113.122.202 2811 194.215.38.3 80 128 46 76
1203080400 89.113.121.130 1090 194.67.57.170 80 1104 34 76
1203080400 89.113.121.46 37100 213.180.214.31 80 1463 20 76
1203080400 194.215.38.3 80 89.113.122.202 2811 88 76 46
1203080400 89.113.122.202 2815 194.215.38.3 80 128 46 76
1203080400 213.180.214.31 80 89.113.121.46 37100 5401 76 20
1203080400 89.113.121.130 1091 194.67.57.170 80 1104 34 76
1203080400 89.113.121.46 37101 213.180.214.31 80 1475 20 76

похожая проблема была ...
мы решали следущим образом.
всем клиентам привязаным к этому роутеру к конктретному интерфейсу (не ANY) закрыли диапазон адресов и создали новый с новым индексом интерфеса.

В сервис - журнал ошибок по ИПН модулю за эти часы ничего нет?

В журнале ошибок нет.
Их кстате нет вообще.
Это нормально?
Может журнал не работает.

Ставьте в log4j_netflow_ipn.properties

Потом запустите обработку какого-либо часа, и смотрите dataloader.log, ну и сюда выложите. Найдите какую-то из этих строк, посмотрим как она обрабатывается.
P.S. После обработки часа оключите режим ALL для логгера, т.к. это очень тормозит обработку.

А что здесь есть что?

dataloader.log.1:


DEBUG 07.04.2008 15:34:39 Found send client
DEBUG 07.04.2008 15:34:39 LINE 22255;40;9;396
DEBUG 07.04.2008 15:34:39 addAmount 14_33_9 => 396
DEBUG 07.04.2008 15:34:39 Find any iface list
DEBUG 07.04.2008 15:34:39 addr=3552242670; range.start=0; range.end=-1
DEBUG 07.04.2008 15:34:39 Process line 76 1047624260 80 45 1500609178 49208 725
DEBUG 07.04.2008 15:34:39 Find any iface list
DEBUG 07.04.2008 15:34:39 addr=1047624260; range.start=0; range.end=-1
DEBUG 07.04.2008 15:34:39 Find any iface list
DEBUG 07.04.2008 15:34:39 addr=1500609178; range.start=72; range.end=72
DEBUG 07.04.2008 15:34:39 Found receive client
DEBUG 07.04.2008 15:34:39 LINE 22256;30;8;725
DEBUG 07.04.2008 15:34:39 addAmount 43_173_8 => 725
DEBUG 07.04.2008 15:34:39 Process line 62 1500609142 1086 76 3246163408 110 374

UP

В очередной раз перезагрузилась cisco и естессно интерфейсы поменяли свои snmp идентификаторы, так как за время до перезагрузки появилось несколько новых интерфейсов.

Для клиентской статистики ничего страшного, ибо привязка только к интерфейсу за номером -1.

А вот провайдерские линки смотрятся с привязкой к интерфейсу.
Вот они и пострадали.

Причём, как и ранее я писал выше, в файлах коллектора данные есть.
А вот переобсчет со сменой интерфейса в привязках за период "после смены интерфеса" не дает результата.
Пробовал и зону "своя зона " и "нет зоны" - результат ноль.

Может это связано с каким-то косяком в базе?

Кидайте в личку доступ, будем смотреть.

циске нужно сказать snmp ifindex persist
что бы она при перезагрузке не меняла индексы интерфейсам

Мой кисёныш не разумеет такого...

аха...
а вот так он умеет: snmp-server ifindex persist..
посмотрим...

Сразу не проверил, а сейчас выяснилось, что по провайдерским линкам трафика нет в биллинге.
Коллектор собирает.

Посмотрел свойства договора в модули ->
IPN->Адреса->Парамтры-> Источники/Интерфейсы.
Нет привяки к интерфейсу.

Ставлю галку на интерфейсе - BG с минуту думает и сбрасывает ее.

Видимо все-таки в базе косяк...

Сбрасывает сразу или при попытке сохранить. Если сразу - запустите bgbilling_debug.bat, попробуйте повторить и выложите файл log

Сбрасывает через минуту после нажатия кнопки "OK".

log дайте и в server.out если что есть - выложите.

повторите действие и посмотрите/выложите server.out

Лог в личке..

По логу ошибок нет. Перезапускать пробовли клиент/сервер? На других машинах то же? Только в определенных договорах галочки пропадают?

Предыстория выше...

Краткое содержание предыдущих серий:

1) После того, как маршрутизатор перезагрузился, поменялись snmp-идентификаторы интерфейсов, ибо было добавлено несколько новых.
2) Привязка к реальным интерфейсам есть только в договорах провайдеров, а у остальных клиентов к интерфейсу -1
3) Попытка привязаться к новым идентификаторам интерфейсов приводит к зависону. После установки галки на интерфейс и нажатия кнопки ОК ничего ни происходит. Даже если попытаться привязаться к интерфейсу ANY... Приходится жать ОТМЕНА, чтобы закрыть окно.
4) Сервер и клиент перезапускались..
5) На других машинах тоже...

На основании предоставленных данных воспроизвести ошибку не получается.

Вы можете сделать что-то одно из двух:
1) С нуля описать последовательность действий на чистом биллинге, гарантированно приводящих к ошибке. Тогда бы мы смогли воспроизвести и исправить ее.
2) Обратиться в платную техподдержку http://bgbilling.ru/support.shtml и предоставить доступ к серверу.

Оба варианта нереальны..

Определился еще один интересный момент:

проблема возникает только с сеткой 0.0.0.0-255.255.255.255 !
Она не добавляется ни на какой договор в независимости от привязки интерфейса.

Любая другая сеть или адрес легко добавляется в договор и на любой интерфейс!

Вот что вываливается в server.out (сразу скажу дело не в памяти - ее достаточно, да и ошибок других нет в работе) в момент отбрыкивания сетки 0.0.0.0-255.255.255.255:

Exception in thread "Thread-2" java.lang.OutOfMemoryError: Java heap space
at java.nio.charset.CharsetEncoder.<init>(CharsetEncoder.java:209)
at sun.nio.cs.US_ASCII$Encoder.<init>(US_ASCII.java:121)
at sun.nio.cs.US_ASCII$Encoder.<init>(US_ASCII.java:118)
at sun.nio.cs.US_ASCII.newEncoder(US_ASCII.java:43)
at java.lang.StringCoding$StringEncoder.<init>(StringCoding.java:215)
at java.lang.StringCoding$StringEncoder.<init>(StringCoding.java:207)
at java.lang.StringCoding.encode(StringCoding.java:266)
at java.lang.String.getBytes(String.java:947)
at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228)
at java.io.File.exists(File.java:733)
at org.apache.log4j.helpers.FileWatchdog.checkAndConfigure(FileWatchdog.java:68)
at org.apache.log4j.helpers.FileWatchdog.run(FileWatchdog.java:99)
java.lang.OutOfMemoryError: Java heap space
at bitel.billing.server.ipn.action.ActionUpdateContractAddress.resourceAnalize(A
ctionUpdateContractAddress.java:174)
at bitel.billing.server.ipn.action.ActionUpdateContractAddress.doAction(ActionUp
dateContractAddress.java:73)
at bitel.billing.server.Executer.doModule(Executer.java:679)
at bitel.billing.server.Executer.doPost(Executer.java:168)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:615)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationF
ilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCha
in.java:206)
at bitel.billing.server.filters.SetCharacterEncodingFilter.doFilter(SetCharacter
EncodingFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationF
ilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCha
in.java:206)
at bitel.billing.server.filters.SetCharacterEncodingFilter.doFilter(SetCharacter
EncodingFilter.java:37)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationF
ilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCha
in.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.jav
a:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.jav
a:175)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http1
1Protocol.java:584)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)

Один из привязанных интерфейсов добавляемой сетки похоже принадлежат к глобальной зоне.
Если да - то биллинг начинает синхронизировать ресурсы, а это >4000000000 ip-адресов...

Нет. Интерфейсы, к которым пытаюсь привязаться принадлежат "Своей зоне".

У вас не последний билд IPN.

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

В данном случае каюсь - был не прав
Последний билд проблему снял.

Сделайте orig файлы, перетирать не будет.