... {toc}
h1. Система мониторинга
На платформе Carbon PL5 существует система автоматического тестирования, запускающая тесты всех контейнеров раз в 10 минут. При возникновении ошибки по любому из тестов, создаётся автоматическая заявка в портале [HelpDesk|http://helpdesk.carbonsoft.ru/]. Аналогичную проверку можно запустить вручную, выполнив команду *server_check* в терминале или запустив диагностику [в веб-интерфейсе|CarbonBilling:Диагностика системы].
Помимо тестов server_check существуют так же тест выгрузки бэкапов на FTP и тест на наличие UPS.
h1. Диагностика в командной строке
*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}
h2. Ошибки тестов ASR_BILLING
h3. Тесты angel и monitoring
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/].
Со временем база может достичь данного размера по той простой причине, что место на диске не очищается при удалении записей из базы данных, так как это создаст лишнюю постоянную нагрузку на диск и ОЗУ. Записи в БД добавляются постоянно - любые события, происходящие с абонентами, их лицевыми считами, оборудованием, добавляются в стэк событий, обрабатываются воркером, после чего очищаются.
Для решения проблемы Вам необходимо [создать бэкап, после чего восстановиться с него же|Восстановление БД биллинга из резервной копии.].
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 ]
Запускается radiusd_acc: [ OK ]
Nas с IP 192.168.0.1 нету в /etc/raddb/clients.conf{code}
Тест пытается исправить ошибку автоматический, пересоздав конфигурационные файлы radius. Такое может произойти, например, при обнлении, в случае если radius-сервер запустился раньше чем закончилась перезагрузка СУБД по той или иной причине. Так же ошибка может возникать в случае, если Вы не указали ни OSS-схему ни Тип НАСа при добавлении (например, если добавляли NAS не мастером, или не удалили демонстрационные NAS).
h3. Прочие тесты
h4. ALARM Billing Не настроены реквизиты доступа к администраторской панели для тестирования
Для ускорения работы веб-интерфейса биллинга, планировщик задач ежечасно делает запрос в веб-интерфейс для формирования кеша и проверки отсутствия ошибок в отображении абонентов.
Для корректной работы требуется администратор с правами *root*. По-умолчанию, в конфигурационном файле биллинга используются учетные данные *root* с паролем *servicemode*.
При изменении пароля *root*, необходимо исправить так же конфигурационный файл. Либо Вы можете создать нового администратора исключительно для данной функции по статье "[Интерфейсы пользователей биллинга|CarbonBilling:Интерфейсы пользователей биллинга.]" и указать его учетные данные.
*/app/asr_billing/cfg/config*
{code}declare -A django
django['username']='root'
|
... h4. check_xge_free_class.sh
{code}check_xge_free_class.sh: ERROR(1) [СБОЙ]{code}
Шейпер в XGE (Softrouter) является динамическим. Занятые классы определяется по наличию файлов в папке /app/xge/var/lib/xge_shapers/lock, свободные в /app/xge/var/lib/xge_shapers/free.
В ситуации, когда по той или иной причине не сработала синхронизация шейперов, может возникнуть ошибка скрипта check_xge_free_class.sh. Подобная проблема наиболее характерна при подключении абонентов через vpn (pptp, pppoe)
В данном случае следует посмотреть количество свободных и занятых классов:
{code}
ls /app/xge/var/lib/xge_shapers/lock/ | wc -l
7000
ls /app/xge/var/lib/xge_shapers/free | wc -l
0
{code}
В выводе: количество занятых классов, далее количество свободных. Как видно из примера, свободных более нет. Для решения проблемы следует запустить скрипт, удаляющий лишние локи:
{code}chroot /app/xge fix_locked_shapers.sh{code}
Если после выполнения скрипта абоненты будут жаловаться на наличие проблем со скоростью, перезапустите XGE
{code}/app/xge/service restart{code}
{note}Файлы классов создаются при первой установке абоненту тарифа ограничением скорости. При свежей установке, создайте такой тариф и назначьте его абоненту чтобы не возникала ошибка теста. В случае, если они не создались после установки тарифа, выполните следующую команду:
{code}for shaperid in `seq 2000 8998`; do touch /app/xge/var/lib/xge_shapers/free/$shaperid; done{code}{note}
h1. Общие ошибки продуктов на платформе Carbon PL5
h2. ALARM Ошибка автоматического бекапа\!
Полный текст ошибки
{code}Ошибка автоматического бекапа! Информация в логе: /app/base/var/log/cron_backup.sh.log{code}
В нём сообщается, где можно уточнить в чем заключается проблема с бэкапами.
Как правило, ошибки возникают на стороне FTP, как то: недостаток свободного места, недоступность сервера, превышение квот, о чем можно подробней посмотреть в логе FTP-сервера.
h3. backup: \[СБОЙ \]
Ошибка говорит о проблемах с созданием бэкапа.
Убедитесь, что на разделе /mnt/backup достаточно свободного места
{code}# df -h /mnt/backup/
Файловая система Разм Исп Дост Исп% смонтирована на
/dev/sdc3 32G 6,0G 24G 21% /mnt/backup{code}
Если места достаточно, найдите в логе /app/base/var/log/cron_backup.sh.log строку, содержашую "backup: \[СБОЙ\]", например:
{code}# /app/collector/service backup: [СБОЙ ]{code}
Перед ней будет лог выполнения резервного копирования. Причин проблемы с резервным копированием может быть огромное множество, соответственно и решение строго индивидуально в каждом конкретном случае.
h3. backup_upload: \[СБОЙ \]
найдите в логе /app/base/var/log/cron_backup.sh.log строку, содержашую "backup_upload: \[СБОЙ\]", например:
{code}# /app/collector/service backup_upload: [СБОЙ ]{code}
Перед ней будет лог выполнения резервного копирования.
h4. FTP недоступен, curl: (7) couldn't connect to host
Наиболее респространенной причиной ошибки является недоступность ФТП-сервера:
{code}/app/collector backup_upload
Backup upload collector
Синхронизирую каталог root:servicemode /app/collector/mnt/backup/ ftp://10.20.30.40/carbon/collector
Procedd /app/collector/mnt/backup//.... Не найден md5 для файла /app/collector/mnt/backup//.! Не синхронизируем!
Procedd /app/collector/mnt/backup//./config_11.42.57_09-2014... Не найден md5 для файла /app/collector/mnt/backup//./config_11.42.57_09-2014! Не синхронизируем!
Procedd /app/collector/mnt/backup//./config_16.40.08_12-2014... Не найден md5 для файла /app/collector/mnt/backup//./config_16.40.08_12-2014! Не синхронизируем!
Procedd /app/collector/mnt/backup//./config_08.00.16_12-2014... Не найден md5 для файла /app/collector/mnt/backup//./config_08.00.16_12-2014! Не синхронизируем!
Procedd /app/collector/mnt/backup//./backup_monthly_2017-03-31_02-51_collector.tar.gz... curl: (7) couldn't connect to host
md5 не сходится! Выкладываем! ebba6adaa42ad946cfed04g9af0420dc /app/collector/mnt/backup/backup_monthly_2017-03-31_02-51_collector.tar.gz !=
curl: (7) couldn't connect to host
Retry: curl -v -sS --user root:servicemode --ftp-create-dirs --upload-file /app/collector/mnt/backup//./backup_monthly_2017-03-31_02-51_collector.tar.gz ftp://10.20.30.40/carbon/collector//./backup_monthly_2017-03-31_02-51_
* About to connect() to 10.20.30.40 port 21 (#0)
* Trying 10.20.30.40... Время ожидания соединения истекло
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host{code}
В данном случае, следует проверить что FTP-сервер доступен и работает.
{info}Далее приведёны примеры наиболее часто встречающихся проблем. Полный список кодов ошибок с описанием можно посмотреть [в соответствующей статье на Википедии|https://en.wikipedia.org/wiki/List_of_FTP_server_return_codes].{info}
h4. Отсутствует свободное место на фтп-сервере, curl: (25) Failed FTP upload: 452
{code}* Connecting to 1.2.3.4 (1.2.3.4) port 59996
> TYPE I^M
< 200 Type set to I.^M
> STOR audit_operations.fdb.gbk.gz^M
< 452 Unique file name cannot be created.^M
* Failed FTP upload: 452
* Remembering we are in dir "backups/asr_billing//./static/var/db/billing/201705/"
* Uploaded unaligned file size (0 out of 323513 bytes)
* Connection #0 to host 1.2.3.4 left intact
curl: (25) Failed FTP upload: 452
> QUIT^M
< 221 Goodbye.^M
* Closing connection #0{code}
Ошибка 452 говорит о том, тчо закончилось свободное место на фтп-сервере.
h4. Логин или пароль не подходят, curl: (67) Access denied: 530
Как видно из лога, ошибка с логином
{code}* About to connect() to 10.20.30.40 port 21 (#0)
* Trying 10.20.30.40... connected
* Connected to 10.20.30.40 (10.20.30.40) port 21 (#0)
< 220 ProFTPD 1.3.5b Server (Hetzner Backup) [::ffff:10.20.30.40]^M
> USER root^M
< 331 Password required for root^M
> PASS servicemode^M
< 530 Login incorrect.^M
* Access denied: 530
* Closing connection #0
curl: (67) Access denied: 530{code}
h4. Нет прав на создание директорий, curl: (9) Failed to MKD dir: 550
Убедитесь, что корректно настроили права пользователя в настройках ftp, а так же права файловой системы.
{code}< 250 Directory successfully changed.^M
> CWD backup^M
< 550 Failed to change directory.^M
> MKD backup^M
< 550 Create directory operation failed.^M
* Failed to MKD dir: 550
* Remembering we are in dir "/mnt/carbon/backup/billing/monitoring//"
* Uploaded unaligned file size (0 out of 76018 bytes)
* Connection #0 to host 10.20.30.40 left intact
curl: (9) Failed to MKD dir: 550{code}
h2. ALARM Не обнаружен работающий UPS
Настройка и решение проблемы с ИБП описаны в статье [CarbonBaseSystem:Подсистема контроля UPS]
h1. Диагностика в веб-интерфейсе
Описание диагностики находится в [соответствующей статье|CarbonBilling:Диагностика системы].
|
