Обнаружил у себя утечку трафика > 10% ...
Долго разбирался и выяснил, что часть трафика не тарифицируется, т.е. отсутствует в отчете по трафику.
При этом в деталке данные имеются и правильно классифицированны как "Входящий".
Версия 5.2.1-004
Биллинг не нагружен.
Помогайте плиз, куда рыть вообще не представляю ...
Правильная классификация и отсутствие тарификации !!!
Ничем не отличаются, адреса валидные (существующие), не мультикаст.
Да и классифицирован трафик нормально! В деталке то он есть.
А вот тарифицирован он не был, однозначно.
Диагностировать очень сложно т.к. нереально четко выяснить, что протарифицировано, а что нет (пакетов то летает дофига).
Просто у одного из клиентов ночью пролетел реальный кусок в 26 метров.
О том, что это не единичный случай говорит то, что в сравнении с netflow tools наблюдается очень существенная разница в объемах.
Да и классифицирован трафик нормально! В деталке то он есть.
А вот тарифицирован он не был, однозначно.
Диагностировать очень сложно т.к. нереально четко выяснить, что протарифицировано, а что нет (пакетов то летает дофига).
Просто у одного из клиентов ночью пролетел реальный кусок в 26 метров.
О том, что это не единичный случай говорит то, что в сравнении с netflow tools наблюдается очень существенная разница в объемах.
-
Instruktor
- Сообщения: 131
- Зарегистрирован: Ср авг 10, 2005 21:32
- Откуда: Москва
У меня такое было. Работает чел и в детальке пишет его трафик. И тут - в общем отчете появляется правильно определенный тип траифка со всей инфой, но вод ид узверя к которому он должен быть преписан был равен 0! Самое интерестное что при этом у остальных пользователей все нормально считало. Заметил что баг исправляется или после переподключения клиента (не всегда) или же после переподключения услуги. Вобщем с месяц такой ай ай ай продолжался - я уже устал услуги переподключать. Тогда работала свзяка FreeBSD 6.0 (URFA+RADIUS) Debian 3.1(MySQL) Debian 3.1 (NAS). щас полность перевел все сервера на FreeBSD 6.2 - уже с неделю - пока каких-либо багов акромя верификаторов не появлялось.
В логах наковырял следующее:
----------------------------
ERROR : Oct 10 08:15:53 DBAGlukError: commit_ip_traffic_downloaded: database gluk, more than one lines with downloaded_id=1191 and tclass_id=10
?Trace : Oct 10 08:15:53 trace: Obtained 10 stack frames.
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_Z15print_backtracev+0x1d) [0x83072dd]
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_ZN3UTM8DBAccess32commit_ip_traffic_downloaded_andEii+0xc9b) [0x80b2ea3]
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_ZN3UTM8DBAccess23__discount_from_accountEPNS_23discount_info_iptrafficEb+0x89d) [0x819b495]
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_ZN3UTM10BusClassif8blm_sendERKNS0_9cache_hdrERKNS0_10cache_infoE+0x1ad) [0x82eb65d]
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_ZN8dbintreeIN3UTM10BusClassif9cache_hdrENS1_10cache_infoEE6__enumEPNS4_4nodeEPFvRKS2_RKS3_PKvESC_+0x25) [0x
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_ZN8dbintreeIN3UTM10BusClassif9cache_hdrENS1_10cache_infoEE9enumerateEPFvRKS2_RKS3_PKvESA_+0x17) [0x82ece37]
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_ZN3UTM10BusClassif5flushEv+0x8b) [0x82e9ce3]
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_ZN3UTM10BusClassif16periodic_cleanupEPv+0x105) [0x82e9e39]
?Trace : Oct 10 08:15:53 trace: /lib/libpthread.so.0 [0xf7e083db]
?Trace : Oct 10 08:15:53 trace: /lib/libc.so.6(clone+0x5e) [0x4899406e]
-----------------------------------------------------------
И таких пользователей насчиталось 3 штуки
Вчера нарыл только одного, но корректировка уже принесла результат.
Разрыв значительно (до ~ 1%) сократился. Вероятнее всего здесь собака и порылась.
Сегодня удалил еще две лишние записи.
Ошибка, судя по downloaded_id=1191 очень старая...
При этом значения поля id у таких записей находятся рядом, т.е. разумно предположить, что возникают такие ошибки на моменте подключения тарифа (услуги) или в начале работы клиента.
Итого косяки:
1) На уровне хранения, возможность возникновения двойных записей не отслеживается. Надо просто создать ключ на основе 2-х полей таблицы downloaded.
2) В процессе тарификации наличие двойных записей похоже приводит к потере данных о протарифицированном, но еще не сохраненном в базу трафике,
причем не только по данному пользователю. Соответственно чем чаще данные о трафике такого пользователя пишутся в базу, тем больше утечка.
3) Верификотор не проверяет базу на наличие данных ошибок.
Проверить таблюцу можно так:
SELECT `downloaded_id`, `tclass_id`, COUNT(*) AS count FROM `downloaded` GROUP BY `downloaded_id`, `tclass_id` HAVING count > 1;
Всем кто откликнулся большое спасибо.
----------------------------
ERROR : Oct 10 08:15:53 DBAGlukError: commit_ip_traffic_downloaded: database gluk, more than one lines with downloaded_id=1191 and tclass_id=10
?Trace : Oct 10 08:15:53 trace: Obtained 10 stack frames.
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_Z15print_backtracev+0x1d) [0x83072dd]
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_ZN3UTM8DBAccess32commit_ip_traffic_downloaded_andEii+0xc9b) [0x80b2ea3]
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_ZN3UTM8DBAccess23__discount_from_accountEPNS_23discount_info_iptrafficEb+0x89d) [0x819b495]
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_ZN3UTM10BusClassif8blm_sendERKNS0_9cache_hdrERKNS0_10cache_infoE+0x1ad) [0x82eb65d]
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_ZN8dbintreeIN3UTM10BusClassif9cache_hdrENS1_10cache_infoEE6__enumEPNS4_4nodeEPFvRKS2_RKS3_PKvESC_+0x25) [0x
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_ZN8dbintreeIN3UTM10BusClassif9cache_hdrENS1_10cache_infoEE9enumerateEPFvRKS2_RKS3_PKvESA_+0x17) [0x82ece37]
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_ZN3UTM10BusClassif5flushEv+0x8b) [0x82e9ce3]
?Trace : Oct 10 08:15:53 trace: /netup/utm5/bin/utm5_core(_ZN3UTM10BusClassif16periodic_cleanupEPv+0x105) [0x82e9e39]
?Trace : Oct 10 08:15:53 trace: /lib/libpthread.so.0 [0xf7e083db]
?Trace : Oct 10 08:15:53 trace: /lib/libc.so.6(clone+0x5e) [0x4899406e]
-----------------------------------------------------------
И таких пользователей насчиталось 3 штуки
Вчера нарыл только одного, но корректировка уже принесла результат.
Разрыв значительно (до ~ 1%) сократился. Вероятнее всего здесь собака и порылась.
Сегодня удалил еще две лишние записи.
Ошибка, судя по downloaded_id=1191 очень старая...
При этом значения поля id у таких записей находятся рядом, т.е. разумно предположить, что возникают такие ошибки на моменте подключения тарифа (услуги) или в начале работы клиента.
Итого косяки:
1) На уровне хранения, возможность возникновения двойных записей не отслеживается. Надо просто создать ключ на основе 2-х полей таблицы downloaded.
2) В процессе тарификации наличие двойных записей похоже приводит к потере данных о протарифицированном, но еще не сохраненном в базу трафике,
причем не только по данному пользователю. Соответственно чем чаще данные о трафике такого пользователя пишутся в базу, тем больше утечка.
3) Верификотор не проверяет базу на наличие данных ошибок.
Проверить таблюцу можно так:
SELECT `downloaded_id`, `tclass_id`, COUNT(*) AS count FROM `downloaded` GROUP BY `downloaded_id`, `tclass_id` HAVING count > 1;
Всем кто откликнулся большое спасибо.
Круто 
Я это тоже заметил по ошибкам при старте биллинга, и исправил в начале месяца только ради того чтобы все красиво было, но не думал что из-за этого трафик уходит, счас проверил по итогам прошлого месяца разница в 20%, в этом месяце все сравнительно точно.
Запрос только немного надо поправить:
SELECT `downloaded_id`, `tclass_id`, COUNT(*) AS count FROM `downloaded` WHERE `is_deleted` = 0 GROUP BY `downloaded_id`, `tclass_id` HAVING count > 1;
Я это тоже заметил по ошибкам при старте биллинга, и исправил в начале месяца только ради того чтобы все красиво было, но не думал что из-за этого трафик уходит, счас проверил по итогам прошлого месяца разница в 20%, в этом месяце все сравнительно точно.
Запрос только немного надо поправить:
SELECT `downloaded_id`, `tclass_id`, COUNT(*) AS count FROM `downloaded` WHERE `is_deleted` = 0 GROUP BY `downloaded_id`, `tclass_id` HAVING count > 1;
а у меня запрос говорит что все ок. но при этом 2% от общего трафика попало в пользователь не определен. делаю детальный отчет в нем вижу некоторых клиентов с id 0 при этом ip у них правильный. с чем можеты быть связано? удаляю у такого пользователя тариф завожу заново тариф\ip. трафик начинает попадать в пользователя.Magnum72 писал(а): Запрос только немного надо поправить:
SELECT `downloaded_id`, `tclass_id`, COUNT(*) AS count FROM `downloaded` WHERE `is_deleted` = 0 GROUP BY `downloaded_id`, `tclass_id` HAVING count > 1;
я так понимаю эта проблема у многих так и не решена?
viewtopic.php?t=4626&postdays=0&postord ... D&start=15
[/quote]я так понимаю эта проблема у многих так и не решена?
viewtopic.php?t=4626&postdays=0&postord ... D&start=15
это другая проблема, вроде фикс уже сесть но требует тестирования поэтому решили не включать в 005, запроси в нетапе вообщем.
ЗЫ удалять пользователя не обязательно, досточно открыть ип адрес для редактирования и ничего не меняя закрыть или тупо ребутнуть биллинг
У меня эта фигня началась в переходом на 005.
Напрягает сильно. Лечится рестартом ядра.
Комментарии нетапа:
"Факт привязки трафика к лицевому счету 0 в
случае, если адрес отправителя или
получателя трафика зарегистрирован в
системе, свидетельствует о нарушении
целостности дерева поиска классификатора
сервисных связок."
Напрягает сильно. Лечится рестартом ядра.
Комментарии нетапа:
"Факт привязки трафика к лицевому счету 0 в
случае, если адрес отправителя или
получателя трафика зарегистрирован в
системе, свидетельствует о нарушении
целостности дерева поиска классификатора
сервисных связок."
viewtopic.php?t=4626&postdays=0&postord ... ED&start=0Magnum72 писал(а): это другая проблема, вроде фикс уже сесть но требует тестирования поэтому решили не включать в 005, запроси в нетапе вообщем.
ЗЫ удалять пользователя не обязательно, досточно открыть ип адрес для редактирования и ничего не меняя закрыть или тупо ребутнуть биллинг
мне показалось что именно об утечке на id=0 речь по крайней мере на первой странице. да и поиском несколько тем нашлось, только вот без решения
буду звонить в нетап
зы пользователя не удалял, удалял тариф у пользователя и заводил снова с тем же ip. как видно есть способ попроще
