... h2. Диагностика в командной строке
*1.* При каких либо сбоях требуется проверить состояние сервера и работу всех служб. Делается это командой
{code}server_check{code}В ответ будет выведено состояние всех служб биллинга. Все службы должны иметь состояние *\[ OK \].* Если где-то есть сбой, то при обращении в поддержку укажите сбойную службу.
*2.* Для проверки базы можно посмотреть логи которые ведет система:
лог базы биллинга
{code}cat /app/asr_billing/var/log/firebird/firebird.log{code}
*В выводе особое внимание обратить на строки содержащие примерно такие блоки текста*
2.1. Повреждена целостность БД, серьезный сбой. Вероятно потребуется восстановление из бекапа:
{code}
Database: /mnt/var/db/billing.gdb
database file appears corrupt (/mnt/var/db/billing.gdb)
wrong page type
page 1647 is of wrong type (expected 7, found 5)
internal gds software consistency check (error during savepoint backout (290), file: exe.cpp line: 4026)
{code}
2.2. Биллинг не может найти БД, вероятно биллинг в safemode:
{code}
Database: /mnt/var/db/billing.gdb
I/O error for file "/mnt/var/db/billing.gdb"
Error while trying to read from file
No such file or directory
{code}
2.3. Отдельная запись в таблице помечена как поврежденная:
{code}
Database: /mnt/var/db/billing.process.gdb.13836
Record 1002 is marked as damaged in table RDB$RELATIONS (6)
{code}
h3. Ошибки тестов
h4. check_billing_db_size.sh
{code}- check_billing_db_size.sh: ERROR(1) [СБОЙ ]
2017-03-03 13:38:47 Чрезмерно большая база данных биллинга
2017-03-03 13:38:47: /usr/local/monitoring/check_billing_db_size.sh ERROR(1): 2017-03-03 13:38:47 Чрезмерно большая база данных биллинга{code}
Ошибка происходит при увеличении размера БД до 10Гб. Почему так происходит, описано в [справочной документации firebird|http://www.firebirdfaq.org/faq41/].
Со временем база может достичь данного размера по той простой причине, что место на диске не очищается при удалении записей из базы данных, так как это создаст лишнюю постоянную нагрузку на диск и ОЗУ. Записи в БД добавляются постоянно - любые события, происходящие с абонентами, их лицевыми считами, оборудованием, добавляются в стэк событий, обрабатываются воркером, после чего очищаются.
Для решения проблемы Вам необходимо [создать бэкап, после чего восстановиться с него же|CarbonBilling:Создание бэкапа.Настройка бэкапов по FTP.Резервное копирование и восстановление базы данных из бэкапов при помощи WinSCP.].
h4. check_events_stack_count.sh
{code}- check_events_stack_count.sh: ERROR(1) [СБОЙ ]
2017-03-07 07:32:18 Очень большое количество команд в event_stack{code}
В таблице events_stack собираются события для отправки на оборудования. Большое количество событий связано как правило с проблемами доступа на оборудование (nas недоступен, сменились какие-то параметры вроде логина/пароля/ip, оборудование не принимает CoA и тд). Так же, возможно, что проблема в медленном ответе биллингу от НАСа, так как команды отправляются в заданное количество потоков (по-умолчанию, 1) и каждая следующая выполняется только после ответа от сервера. Убедитесь, что нагрузка процессора и канала на NAS в норме.
Узнать количество скопившихся событий можно выполнив запрос к БД
{code}# sqlexec "select count(*) from events_stack"
COUNT
============
122837 {code}
h4. test_radius_nas_list.sh
{code}- test_radius_nas_list.sh: ERROR(1) [СБОЙ ]
Nas с IP 192.168.0.1 нету в /etc/raddb/clients.conf
2017-03-21 14:48:52 localhost test_radius_nas_list.sh[1277]: Fix radiusd by restart
Останавливается radiusd: [ OK ]
Останавливается radiusd_acc: [ OK ]
Запускается radiusd: [ OK ]
|
Тест пытается исправить ошибку автоматический, пересоздав конфигурационные файлы radius. Такое может произойти, например, при обнлении, в случае если radius-сервер запустился раньше чем закончилась перезагрузка СУБД по той или иной причине. Так же ошибка может возникать в случае, если Вы не указали ни OSS-схему ни Тип НАСа при добавлении (например, если добавляли NAS не мастером, или не удалили демонстрационные NAS (не выполнили очистку БД перед окончательной интеграцией).
|
