... {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
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}
|
... {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).
h2. Ошибки тестов XGE
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}Файлы классов создаются при первой установке абоненту тарифа ограничением скорости. При свежей установке, создайте такой тариф и назначьте его абоненту чтобы не возникала ошибка теста.{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:Диагностика системы].
|
