Система мониторинга

{toc:maxLevel=2}

h1. Система мониторинга

На платформе *Carbon PL5* существует система автоматического тестирования, запускающая тесты всех контейнеров раз в 10 минут. При возникновении ошибки по любому из тестов, создаётся заявка в портале [HelpDesk|http://helpdesk.carbonsoft.ru/]. Помимо тестов server_check существуют так же тест выгрузки резервных копий на FTP и тест на наличие UPS. Также каждые 6 часов, в 5-ю минуту запускается тест monitoring, который запускает проверку всех контейнеров биллинга.

h2. Запуск проверки вручную

Проверку можно запустить вручную, выполнив команду *server_check* в терминале или открыв диагностику [в веб-интерфейсе|CarbonBilling:Диагностика системы].

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}

h1. Тесты base


h2. check_free_inodes.sh
{code}- check_free_inodes.sh: ERROR(254) [FAILED]

/dev/md5 9125888 8581637 544251 95% /mnt/var
ALARM Мало свободных inode

ALARM На одном из устройств осталось мало свободных inode. Возможно какая-то папка забита большим количеством файлов{code}
Ошибка говорит о том, что на одном из дисков слишком много файлов, в результате чего переполнена база файловой системы (inodes).
Для решения проблемы попробуйте перезагрузить сервер - возможно какой-то процесс создал много файлов, удалил, но до сих пор держит их в памяти.
Если перезагрузка не решила проблему, необходимо опеределить где слишком много файлов и удалить лишнее.
Воспользуйтесь утилитой *tree*, запустив её на указанный раздел:
{code}tree /mnt/var/ | tail -n 1{code}
Вывод будет преблизительно следующим:
{code}39143 directories, 8730047 files{code}
После чего нужно посмотреть сколько занято подпапками:
{code}find /mnt/var -maxdepth 1 -type d | grep -v /$ | while read path; do echo $path; tree $path | tail -n 1; done{code}
И так постепенно можно найти папки в которых находится более всего файлов. Что делать с файлами зависит от конкретной ситуации.
Если лишних файлов не оказалось, - их просто много \-, возможно стоит пересоздать файловую систему, зарезервировав под БД файлов больший процент раздела передав команде *mkfs* параметр *\-N*.
Возможно получится увеличить число inode без пересоздания утилитой *tune2fs* с ключем *\-m*
Как временно перерести данные Вы можете узнать в разделе "[CarbonBilling:Замена оборудования]". Полную информацию по параметрам утилит *mkfs* и *tune2fs* Вы можете найти в их справочном руководстве: *man mkfs.ext4*, *man tune2fs*
{info}Возмжно предварительно потребуется установить команду man:
{code}yum install -y man{code}{info}

h2. check_apps_not_destroyed.sh
{code}- check_apps_not_destroyed.sh: ERROR(2) [FAILED]

ALARM Некорректное состояние аппов
Обнаружены следующие аппы в состоянии destroy, которые должны быть включены:
collector
Требуется перезапустить их с помощью /etc/init.d/apps restart{code}
Ошибка говорит о том, что какая-то из подсистем (контейнеров) платформы Carbon остановлена и "разрушена" - под этим понимается что контейнер остановлен и все точки монтирования внутри контейнера размонтированы.
Возможные причины:
* Сервер был перезагружен некорректно, без остановки биллинга по статье "[CarbonBilling:Выключение, перезагрузка сервера]"
* Ведутся сервисные работы, изменяется конфигурация (например [добавляются диски|CarbonBilling:Добавление диска под статистику] для расширения пространства под какие-либо данные) контейнера
* При "сборе" контейнера произошла ошибка и какие-то разделы внутри него сервисный скрипт не смог замонтировать
* Произошла какая-либо иная ошибка при старте системы, из-за которой работа сервисного скрипта запускающего платформу Carbon завершилась некорректно (например, если на диске были обнаружены ошибки и системная утилита mount не смогла собрать контейнер)

Для отладки в первую очередь можно попробовать запустить команду build:
{code}/app/collector/service build{code}
И посмотреть каким будет вывод, исходя из этого пути решения могут быть разными. Ниже рассмотрены возможные проблемы.

h3. Ведутся сервисные работы

Сообщите, пожалуйста, в автоматической создавшейся заявке инженерам техподдержки что ведутся работы.

h3. Ошибка при сборке конрейнера

Попробуйте найти в журнале сервисного скрипта информацию когда контейнер с котором произошла ошибка запускался:
{code}[root@Billing5 ~]# grep collector /var/log/apps.log | tail -n 2
Sat Mar 23 17:06:56 +08 2019 collector stop STOPPING
Sat Mar 23 17:07:01 +08 2019 collector stop OK{code}
По данному времени попробуйте найти информацию в логах загрузки (сохраняются в папке */var/log/boot/*) и в системном логе \*/var/log/messages и архивных логах: {code}cat /var/log/messages*{code}
Возможно в файлов логов удастся найти информацию об ошибках файловой системы или некорректном завершении процессов по котором удастся понять причину почему не запустился контейнер.

h3. Ошибка монтирования
{code}/app/collector build
mount: no such partition found

# /app/collector/service build: [FAILED]{code}
В конфигурационном файле [collector|CarbonBilling:Collector] настроено сохранение [детальной статистики|CarbonBilling:Описание работы служб сбора статистики] на отдельный диск:
{code}# grep mount /app/collector/cfg/config
declare -A mount
mount['1statfs']='-U a7a26c14-e788-40a0-b0f9-f051be5c9e61 /app/collector/var/stat'
mount['2statfsnfsen']='--bind /app/collector/var/stat/nfsen_stat /app/collector/var/nfsen_stat'
mount['3statfsncapdndump']='--bind /app/collector/var/stat/nfcapd_dump /app/collector/var/nfcapd_dump'
mount['proc']='-t proc none /proc'{code}
Но раздела с ID _a7a26c14-e788-40a0-b0f9-f051be5c9e61_ нет в системе:
{code}[root@st-rline ~]# blkid | grep a7a26c14-e788-40a0-b0f9-f051be5c9e61 -c
0{code}
Весьма вероятно что конфигурационный файл перенесли с другого сервера, но диск на который ранее сохранялась статистика не подключили. Вариантов решения несколько:
# Выключите сервер, подключите диск, включите сервер
# Настройте сохранение на другой выделенный диск или раздел
# Уберите настройку выделенного раздела из конфигурационного файла

h2. check_loadaverage.sh

{code}- check_loadaverage.sh: ERROR(2) [FAILED]

ALARM Высокий load average

12:15:09 up 223 days, 1:07, 2 users, load average: 2.56, 6.35, 12.45
2.56 6.35 12.45 3/584 32535

Возможные причины:
- Запущены процессы, которые активно используют ресурс CPU.
- Аппаратные проблемы с жёсткими дисками.
- Часть запущенных процессов активно использует жёсткие диски
- На сервере мало свободной оперативной памяти и активно используется swap
- На сервере чрезвычайно много зависших процессов (run/total: 3/584)
- Сервер взломан и используется для майнинга криптовалюты.
- Если есть открытая автозаявка 'Повышенная нагрузка на некоторые ядра процессора'
нужно сперва решить её.

Полезные команды для отладки: free, top, iotop

Информация о потреблении ресурсов CPU записана в /app/base/var/log/check_loadaverage.log
Его можно проанализировать командой:
/app/base/usr/local/bin/analyze_check_loadaverage_log.sh --analyze

2019-10-16 12:15:09: pl5angel ALARM Высокий load average{code}

load average показывает очередь к CPU на выполнение запущенных процессов. Оно не должно превышать количество потоков. Если Вы столкнулись с такой проблемой, попробуйте проанилизровать лог: в него записывается вывод команды *ps \-aux* при срабатывании теста:
{code}/app/base/var/log/check_loadaverage.log{code}

# Анализ можно провести специальным скриптом:
{code}/app/base/usr/local/bin/analyze_check_loadaverage_log.sh --analyze{code}
# В начале вывода Вы увидите историю срабатывания автотеста, например:
{code}/app/base/usr/local/bin/analyze_check_loadaverage_log.sh --analyze [3588] START
Всего 14 срабатываний
Срд Окт 16 12:11:59 +05 2019 ALARM load average 0.62 0.79 0.69
Срд Окт 16 12:13:01 +05 2019 ALARM load average 0.28 0.65 0.64
Срд Окт 16 12:13:04 +05 2019 ALARM load average 0.25 0.64 0.64
Сбт Окт 19 05:05:56 +05 2019 ALARM load average 2.69 1.76 1.03
Сбт Окт 19 05:06:10 +05 2019 ALARM load average 3.72 2.02 1.13{code}
Так можно понять, часто ли возникает проблема и в какие промежутки времени - постоянно, или систематический в какое-то время, или это совершенно случайные события.
# Дале тест выводит топ 10 задач, нагружавших процессор по каждлому случаю, например:
{code}lavg.3588/Пнд_Окт_21_16_03_12_+05_2019.ps top 15/41
root 31910 26.4 1.3 202476 77840 ? R 16:03 0:02 python2.7 /usr/local/www/sites/manage.pyc rebuild_index --noinput
root 32670 24.5 1.1 373960 66080 ? Sl 16:03 0:00 /usr/bin/python2.7 /usr/local/sbin/paysystemsd.py start
496 28833 22.3 5.3 3623268 310300 ? Sl 16:02 0:09 /usr/bin/java
root 32414 21.0 1.2 302804 71928 ? R 16:03 0:00 /usr/bin/python2.7 /usr/local/sbin/worker.py start
root 359 17.0 0.6 269960 40848 ? R 16:03 0:00 /usr/bin/python2.7 /usr/local/sbin/felicitation_daemon.py start
root 372 16.0 0.6 269568 40256 ? R 16:03 0:00 /usr/bin/python2.7 /usr/local/sbin/jobs_daemon.py start
root 31869 8.0 1.1 376156 68492 ? Rl 16:03 0:00 /usr/bin/python2.7 /usr/local/sbin/msgd.py start
root 31904 6.9 1.1 299644 69276 ? S 16:03 0:00 /usr/bin/python2.7 /usr/local/sbin/worker.py start
root 28885 5.0 1.7 353852 103944 ? S 16:02 0:02 uwsgi --ini /etc/uwsgi.ini
495 32426 5.0 0.2 67592 12320 ? Ss 16:03 0:00 fb_inet_server
root 28883 4.3 1.6 346740 96728 ? S 16:02 0:01 uwsgi --ini /etc/uwsgi.ini
495 32301 4.4 0.1 66948 10048 ? Ss 16:03 0:00 fb_inet_server
root 31899 3.3 0.3 122752 19508 ? S 16:03 0:00 python2.7 /usr/local/bin/elasticsearch_reindex.py
root 29861 3.6 1.2 293252 71728 ? S 16:02 0:01 python2.7 /mnt/var/oss/core/Smotreshka_test/init.d/lifestream_sync
root 28886 3.3 1.2 310988 74240 ? R 16:02 0:01 uwsgi --ini /etc/uwsgi.ini{code}
Поняв что за процессы создают максимум нагрузки, можно попробовать:
#* Проанализировать их лог (если есть), посмотреть что они делали в указанное время
#* Возможно работа этих процессов завязана на системные ресурсы, которых им не хватает - ОЗУ, скорость работы дисков и тд.
#* Если используется SSD, убедитесть что диск произвонительный по современным меркам: более 50 000 IOPS на запись и чтение, ресурс по крайней мере 300TB, используемые чипы памяти SLC, MLC или TLC
#* Если используется аппаратный RAID-контроллер, то установлена BBU (батарея для сохранения кеша записи при отключении питания) - её отсутствие заметно снижает производительность дисковой подсистемы.
#* Если у вас все диски подключены к аппаратному RAID - выделите под статистику отдельный виртуальный диск, с ограниченным кешем, в противном случае постоянно поступающая статистика будет заполнять кеш контроллера, снижая производительность
#* Подключите отдельные диски под [детальную статистику|CarbonBilling:Добавление диска под статистику], [логи|CarbonBilling:Добавление диска под логи] (можно один диск на логи и статистику) и [базу данных|CarbonBilling:Добавление диска под БД]
#* Убедитесь, что используется производительный RAID: например, если диски собраны в RAID-6 -- это надежный, но весьма медленный вариант, его можно использовать для хранения детальной статистики. Систему и БД лучше держать на RAID10

h3. Недостаточно быстрые диски

Одной из основных проблем замедления работы является недостаточно производительные диски. Это можно проверить так:
{code}awk '($0~"ALARM load average" || $8=="D")' /app/base/var/log/check_loadaverage.log | less{code}
Если в выводе будет множество процессов в состоянии "D" (непрерываемй сон, состояние в котором процесс ожидает некоторое реакции ядра ОС и при этом не может быть прерван), это с вероятностью 99.9% говорит о недостаточной производительности дисков. Пример такого вывода:
{code}Срд Окт 16 09:30:12 +05 2019 ALARM load average 22.44 23.59 20.60
root 1147 0.0 0.0 0 0 ? D Mar07 48:34 [jbd2/sda3-8]
root 1400 0.0 0.0 0 0 ? D Mar07 188:02 [flush-8:0]
51 4248 0.0 0.0 76552 4672 ? D 09:30 0:00 sendmail: [127.0.0.1]: idle
root 6787 0.0 0.0 53596 3732 ? D 09:30 0:00 isql-fb 169.254.30.50:/var/db/billing.gdb -p -u SYSDBA
root 6865 0.0 0.0 108696 1048 ? D 09:30 0:00 /bin/bash /usr/local/sbin/nas_command.sh 111 mikrotik.sh 1
root 6867 0.0 0.0 108412 800 ? D 09:30 0:00 /bin/bash /usr/local/sbin/nas_command.sh 106 mikrotik.sh 1
root 6874 0.0 0.0 108408 808 ? D 09:30 0:00 /bin/bash /usr/local/sbin/nas_command.sh 83 session 1 /var/oss/core/Megogo/bin
root 6877 0.0 0.0 108644 980 ? D 09:30 0:00 /bin/bash /usr/local/sbin/nas_command.sh 97 mikrotik.sh 1
....{code}
Вывод сокращен, в действительности там еще около 30 строк с процессами в состоянии "D" и почти все они скрипты системы, получающие данные из БД биллинга.
Для решения проблемы потребовалось перенести базу на отдельный SSD диск с высокими показателями IOPS.

h1. Тесты asr_billing

h2. 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/].
Со временем база может достичь данного размера по той простой причине, что место на диске не очищается при удалении записей из базы данных, так как это создаст лишнюю постоянную нагрузку на диск и ОЗУ. Записи в БД добавляются постоянно - любые события, происходящие с абонентами, их лицевыми считами, оборудованием, добавляются в стэк событий, обрабатываются воркером, после чего очищаются.
Для решения проблемы Вам необходимо [создать резервную копию, после чего восстановиться с неё же|Восстановление БД биллинга из резервной копии.].

h2. check_critical_jobs.sh
{code}- check_critical_jobs.sh: ERROR(2) [СБОЙ ]

ALARM Имеются критические ошибки в логе jobs_daemon за последний час: 5690{code}
Тест сообщает что при выполнении [запланированных задач|CarbonBilling:Запланированные задачи] произошла ошибка. Посмотрел описание ошибки можно в логе службы:
{code}grep CRITICAL /app/asr_billing//var/log/jobs_daemon.log | cut -d' ' -f 8-100 | sort | uniq{code}

h4. Как найти проблемную задачу в биллинге

В сообщении об ошибке будет написан ID задачи. По нему можно определить на каком абоненте она была создана:
* Ошибка:
{code}CRITICAL - Не удалось выполнить отложенную задачу id=20{code}
* Создайте отчет в [конструкторе|CarbonBilling:Конструктор отчетов], подставьте в него ID проблемной задачи из описания ошибки:
{code}select a.contract_number from jobs_stack js join abonents a on js.abonent_id=a.id where js.id=20{code}
* Выполните отчет и Вы узнаете номер договора абонента. Найдите его [поиском|CarbonBilling:Поиск и массовое изменение абонентов]

h4. Некорректного заполнения параметров запланированной задачи: отчеты
{code}CRITICAL - Не удалось выполнить отложенную задачу id=18 абонента Тестовый:Traceback (most recent call last):
CRITICAL - Ошибка выполнения команды python2.7 /usr/lib/python2.7/site-packages/jobs_worker/jobs_scripts/make_reports.pyc abonent_id=812{code}
Ошибка возникла из-за некорректного заполнения параметров запланированной задачи на выполнение отчета - не указан ID отчета.

h4. Некорректного заполнения параметров запланированной задачи: рассылка сообщений
{code}CRITICAL - Не удалось выполнить отложенную задачу id=20 абонента Исилькуль:/bin/sh: -c: line 0: syntax error near unexpected token `12'
CRITICAL - Ошибка выполнения команды python2.7 /usr/lib/python2.7/site-packages/jobs_worker/jobs_scripts/message_sending.pyc admin_msg_id=<12> objects_status=<27> abonent_id=2471 job_id=20{code}
Ошибка возникла из-за некорректного заполнения параметров запланированной задачи на рассылку сообщений - в параметрах задачи написали лишние символы кавычек "<" и ">"

Для решения - отредактируйте задачу, убрав ненужные символы и сохраните, сообщения отправятся.

h4. Создана задача на выполнение отчёта. В sql запросе имеется ошибка.
{code}CRITICAL - Не удалось выполнить отложенную задачу id=54 абонента Все:Traceback (most recent call last):
CRITICAL - Ошибка выполнения команды python2.7 /usr/lib/python2.7/site-packages/jobs_worker/jobs_scripts/make_reports.pyc -r 1048 abonent_id=1 job_id=54{code}
Здесь указан ID отчета, но всё равно фиксируется ошибка. Для подробной дигностики откройте лог в программе просмотра текста *less* и найдите ошибку:
{code}less /app/asr_billing//var/log/jobs_daemon.log{code}
Следующие строчки говорят о том, что в выбраном отчёте используются переменная *Po_datu*. Использование переменных допускается только в ручном выполнение отчёта.
{code}
2019-10-01 01:01:06,188 - worker - jobs_lib - CRITICAL - Не удалось выполнить отложенную задачу id=54 абонента Все:Traceback (most recent call last):
File "//usr/lib/python2.7/site-packages/jobs_worker/jobs_scripts/make_reports.py", line 71, in <module>
File "//usr/lib/python2.7/site-packages/jobs_worker/jobs_scripts/make_reports.py", line 48, in _run
File "//usr/local/www/sites/admin/models/admin_custom_reports.py", line 23, in get_data
File "//usr/local/www/sites/admin/models/admin_custom_reports.py", line 61, in _execute_sql
KeyError: u'2.Po_datu|date'
{code}

h6. Путей решения задачи два:

* Исправить параметры, указав верные
* Удалить запланированную задачу

h2. check_events_stack_compact_count.sh

{code}- check_events_stack_compact_count.sh: ERROR(1) [СБОЙ ]{code}

Возникает при количестве событий больше 100000 в таблице events_stack_compact. В таблице events_stack_compact собираются события, связанные с отправкой команд на оборудование, но ещё не обработанные биллингом. Примеры состояния абонента и событий которые отправляются на оборудование после их обработки Вы можете посмотреть по [ссылке|Состояния пользователей, услуг и команды управления].
Большое количество событий в таблице events_stack_compact может быть вызвано возрошей нагрузкой на биллинг. Например массовая авторизация абонентов при перезагрузке оборудования. При этом имеется проблема производительности сервера биллинга, в следтвии которой события не могут быть оперативно обработаны. Наблюдать за количеством событий можно с помощю следующего запроса.
{code}# sqlexec "select count(*) from events_stack_compact"

COUNT
============
110249
{code}
Проверьте сервер биллинга на соответствие [системным требованиям|Системные требования]. Если количество не уменьшается, то следует обратиться в техническую поддержку для решения проблем с производитьльностью.

{info}Если в стеке скопились команды отправки на маршрутизаторы *Mikrotik*, проверьте количество записей в _address list_:
{code}/ip firewall address-list print count-only{code}
Если количество несколько сотен тысяч, вероятно маршрутизатор интегрирован с *Carbon Reductor* для фильтрации по IP. В таком случае Вам нужно изменить способ инитеграции Микротика с Редуктором по статье "[REDUCTOR9:IP фильтрация MikroTik]"{info}


h2. 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}


{info}Если в стеке скопились команды отправки на маршрутизаторы *Mikrotik*, проверьте количество записей в _address list_:
{code}/ip firewall address-list print count-only{code}
Если количество несколько сотен тысяч, вероятно маршрутизатор интегрирован с *Carbon Reductor* для фильтрации по IP. В таком случае Вам нужно изменить способ инитеграции Микротика с Редуктором по статье "[REDUCTOR9:IP фильтрация MikroTik]"{info}

h2. check_events_stack.py

Попробуйте оптимизировать отправу команд по статье:&nbsp;[nas_event_daemon|CarbonBilling:nas_event_daemon]




{info}Если в стеке скопились команды отправки на маршрутизаторы *Mikrotik*, проверьте количество записей в _address list_:
{code}/ip firewall address-list print count-only{code}
Если количество несколько сотен тысяч, вероятно маршрутизатор интегрирован с *Carbon Reductor* для фильтрации по IP. В таком случае Вам нужно изменить способ инитеграции Микротика с Редуктором по статье "[REDUCTOR9:IP фильтрация MikroTik]"{info}

h2. check_error_oss.sh

Тест говорит о наличии ошибок синхронизации с сервисами [IPTV|CarbonBilling:Интеграция сервисов интернет-телевидения]:
{code}- check_error_oss.sh: ERROR(2) [FAILED]

WARNING Ошибки при синхронизации оборудования
Не удалось выполнить синхронизацию команд с оборудованием OSS
За последний час CRITICAL: 6
За последний час ERROR: 0
Подробности в логе службы /app/asr_billing//var/log/oss.log
2019-05-07 10:01:00,717 1690 nas_event_daemon/lifestream CRITICAL Невозможно получить пользователей, т.к. не найден NAS
2019-05-07 10:10:59,813 - worker - v1 - CRITICAL - Невозможно получить пользователей, т.к. не найден NAS
2019-05-07 10:10:59,813 14711 nas_event_daemon/lifestream CRITICAL Невозможно получить пользователей, т.к. не найден NAS
2019-05-07 10:19:37,027 - worker - v1 - CRITICAL - Невозможно получить пользователей, т.к. не найден NAS
2019-05-07 10:19:37,027 25021 nas_event_daemon/lifestream CRITICAL Невозможно получить пользователей, т.к. не найден NAS
Для решения проблемы воспользуйтесь статьёй:
http://docs.carbonsoft.ru/51019784#Системамониторинга-checkerroross.sh{code}
Все возникшие проблемы можно увидеть в логе */app/asr_billing//var/log/oss.log*.
Ошибки синхронизации могут возникнуть как со стороны Carbon Billing 5, так и со стороны сервиса телевидения. Необходимые действия для их устранения необходимо определить исходя из сообщений в логе.

h3. Не найден NAS
{code}2019-05-07 10:01:00,717 1690 nas_event_daemon/lifestream CRITICAL Невозможно получить пользователей, т.к. не найден NAS{code}
В хранилище OSS схем (/app/asr_billing/var/oss/core) существует папка с OSS-схемой IPTV, при этом сам NAS не заведён в биллинге.
Для решения проблемы заведите NAS в ббиллинге или удалите OSS директорию.

h3. Сервер ответил ошибкой
{code}2019-05-07 10:04:37,126 15643 iptvportal_package.commands ERROR Сервер ответил ошибкой: {u'error': {u'message': u'null value in column "password" violates not-null constraint\nDETAIL: Failing row contains (1234567, null, null, null, null, null, 78, 12345678, null, f, null, null, 1, 2019-05-06 15:33:51.876434+03, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null).\n'}, u'id': 111, u'method': u'update'}, Url: https://admin.provider.iptvportal.ru/api/jsonsql/, Запрос: {"params": {"table": "subscriber", "set": {"password": null}, "where": {"eq": ["username", "12345678"]}, "returning": "id"}, "jsonrpc": "2.0", "id": 111, "method": "update"}, Авторизация: {'Iptvportal-Authorization': u'sessionid=kjdiv32ur9fksffopsdkfmv34k9r0efc'}{code}
При обращении к API портала телевидения возникла ошибка из-за структуры запроса или данных переданных в запросе.
Как правило сервисы возвращают текст ошибки, в указанном примере это параметр *message*:
{code}null value in column "password" violates not-null constraint{code}
При изменении параметров учетной записе на портале телевидения, не был передан пароль - именно об этом говориться в сообщении об ошибке.
Исходя из полученной информации, можно попробовать решить проблему:
* В параметрах запроса видно что изменяли учтеную запись с логином "12345678" - можно попробовать найти её в биллинге и убедиться, что пароль не задан в самой учетной записи. В таком случае установите пароль и дождитесь следующей синхронизации.
* Ошибка может быть в самом обработчике отправляющем запросы на портал телевидения.

h3. Нужно добавить префикс для логинов в настройках услуги\!

Эта проблема может возникнуть для некоторых IPTV, например [Смотрёшкой|CarbonBilling:Интеграция с LifeStream (Смотрёшка, Смотрешка)].
Настройте услуги телевидения, создающие учетную запись, по статье "[CarbonBilling:Настройка услуг IPTV]" - у всех таких услуг должен быть указан префикс для создаваемых логинов.

h3. Логины учетных записей в биллинге и на портале не совпадают\!

Включите опцию "*ignore_username_difference*" по статье [Интеграция с LifeStream (Смотрёшка, Смотрешка)|CarbonBilling:Интеграция с LifeStream (Смотрёшка, Смотрешка)]"

h3. Неизвестный абонент на Stalker
{code}iptvportal_package.commands ERROR Неизвестный абонент с ip=10.0.0.3 на Stalker, приставка mac=fe:54:00:ac:5b:e0{code}
В процессе синхронизации биллинг нашел на [Stalker|CarbonBilling:Интеграция со Stalker] абонентов с неизвестными ему связкой IP-адресам и MAC-адреса.
Для решения, актуализируйте данные по приставкам в биллинге или удалите устнойство на портале.

h2. check_error_django.sh
{code}- check_error_django.sh: ERROR(2) [СБОЙ ]

WARNING Имеются ошибки в логе /var/log/django/error.log за последний час: 1
{code}
Причин возникновения этой ошибки может быть несколько и иногда они требуются анализа отделом разработки, однако если посмотреть какие именно были ошибки возможно получится отладить их без привлечения разработчика. Ниже приведено решение нескольких типичных проблем.

h3. Ошибка web_api_get

{code}2018-11-15 20:45:08,307 - django - handlers - ERROR - Exeption:'NoneType' object has no attribute '__getitem__' 'NoneType' object has no attribute '__getitem__'
2018-11-15 20:45:08,307 - django - handlers - ERROR - 'NoneType' object has no attribute '__getitem__' 'NoneType' object has no attribute '__getitem__'
2018-11-15 20:45:08,307 - django - handlers - ERROR - traceback: ['Traceback (most recent call last):\n', ' File "//usr/local/www/sites/admin/api/handlers.py", line 353, in get\n', ' File "//usr/local/www/sites/admin/api/handlers.py", line 399, in web_api_get\n', ' File "//usr/local/www/sites/admin/api/handlers.py", line 368, in process_method\n', "TypeError: 'NoneType' object has no attribute '__getitem__'\n"]{code}
Ошибка функции *web_api_get* говорит о том, что скорей всего проблема в выполняемых к биллингу API-запросах. Отладить это можно по статье [CarbonBilling:API REST v2.0], раздел "*Отладка*"

h3. Нужно добавить префикс для логинов в настройках услуги!

{code}2019-09-12 08:35:17,269 - django - commands - ERROR - Логин {0} состоит из одних цифр и может быть не принят!
2019-09-12 08:35:17,269 - django - commands - ERROR - Нужно добавить префикс для логинов в настройках услуги!{code}

Ошибка говорит о том, что в услуге создающей учетную запись не задан префикс. Вероятней всего ошибка возникла при [настройке услуг IPTV|CarbonBilling:Настройка услуг IPTV]

Посмотреть список услуг создающих учетные записи и из префиксы можно через [конструктор отчетов|CarbonBilling:Конструктор отчетов] таким запросом:

{code}select id, name ,create_login, prefix_login from usluga where create_login=1{code}

h3. Сервер вернул ошибку: requirement failed: Service ID must be non-empty

ALARM обнаружены ошибки в работе радиус сервера VOIP
За последний час ERROR: 270
Лог службы /var/log/radius_asterisk/radius_debug.log
Подробности в логе /app/asr_billing/var/monitoring_dump/check_error_voip_radius.sh_28358.log
Для решения проблемы воспользуйтесь статьёй:
http://docs.carbonsoft.ru/51019784#Системамониторинга-checkerrorradiusvoip.sh{code}

Ошибка возникает если в логе [RADIUS-сервера телефонии|CarbonBilling:Настройка VoIP оборудования в биллинге] обнаружены ошибки обработки звонков.
Посмотреть найденные ошибки можно в логе из описания заявки, в приведенном выше примере это _check_error_voip_radius.sh_28358.log_
Для диагностики включите опцию "*Включить DEBUG для Radius демона телефонии*" в [настройках биллинга|CarbonBilling:Настройки (в файле)] и попробуйте совершить тестовый звонок.
Если звонок не проходит или в не появляется в расходе абонента по завершению, посмотре лог ошибок, возможные причины:
* Выбрана неправильная [OSS схема|CarbonBilling:Интеграция оборудования телефонии]
* Присылаемые NAS-сервером атрибуты не учтены в схеме
* Так же вероятная причина - не все требуемые атрибуты схемы приходят от оборудования, например:
{code}2019-06-25 15:17:03 ++[python_error <140078326261696>] File "/usr/lib/python2.7/site-packages/radius_python/billing_tools/radius.py", line 171, in make_correct_acc_record new_env['NAS-Port'] = env['NAS-Port']
2019-06-25 15:17:03 ++[python_error <140078326261696>]KeyError: 'NAS-Port'{code}

Если исправить проблемы второго и третьего случаев невозможно решить настройкой оборудорвания (например, словарь атрибутов или из формат не настраиваются), потребуется доработать OSS схему или создать новую. С таким запросом Вы можете обратиться в техподдержку.

h2. check_critical_pumper.sh

{code} - check_critical_pumper.sh

ALARM Ошибки в работе архиватора БД
За последний час обнаружено CRITICAL ошибок: 6 {code}

Тест регистрирует наличие некритичных ошибок обработчика, который переносит старые данные в архивную БД.
Узнать, что за ошибки произошли, Вы можете следующей командой:

{code}grep ERR /app/asr_billing/var/log/pumper_daemon.log{code}


h2. check_error_paysystems.sh

{code} - check_error_paysystems.sh: ERROR(2) [СБОЙ ]

WARNING платежи или чеки клиентов не обработаны
Необходимо проверить ошибки и устранить.
За последний час CRITICAL: 436
За последний час ERROR: 0
Лог службы /app/asr_billing//var/log/paysystemsd.log
Подробности в логе /app/asr_billing/var/monitoring_dump/check_error_paysystems.sh_11674.log
Для решения проблемы воспользуйтесь статьёй:
http://docs.carbonsoft.ru/51019784#Системамониторинга-checkerrorpaysystems.sh {code}

Тест говорит о наличии ошибок синхронизации с сервисам [CarbonBilling:АТОЛ Онлайн].

Просмотреть чек по которому произошла ошибка можно следующим образом:
# Найдите ошибку в логе службы обработки платежей:
{code}
/app/asr_billing/mnt/log/paysystemsd.log
{code}
# Пример ошибки:
{code}
2019-10-03 03:51:03,015 - worker - paysystems_lib - INFO - Обрабатываем чек 1111111d-0acf-4cfd-ac16-e0215b098cf2 storno=False #13858
2019-10-03 03:51:03,402 - worker - paysystems_lib - ERROR - ERROR: Ошибка АТОЛ-Онлайн: [-3897] Не удалось выполнить операцию закрытия документа. Ответ от ККТ: [-3897] Описание: Чек оплачен не полностью. (id -no id-)
{code}
# Откройте чек в вэб интерфейсе биллинга. Здесь 1111111d-0acf-4cfd-ac16-e0215b098cf2 -- идентификатор действия со стороны атол-онлайн, #13858 -- номер финансовой операции в биллинге. Укажите его в ссылке на акт (Абонент->Операции->Операция->иконка с принтером):
{code}
http://<ip-биллинга>:8082/admin/FinanceOperations/print/13858/
{code}

h3. Не обработано чеков платежей: N из-за отсутствия email или sms\!

{code}2019-10-17 12:08:00,311 - worker - paysystems_lib - CRITICAL - не обработано чеков платежей: 10 из-за отсутствия email или sms!{code}

В данном случае ошибка возникла из-за того что в карточке абонента не заведены "Email для оповещений" или "Номер SMS для оповещений".

Для решение проблемы можно указать *E-Mail чека по умолчанию* в настройках ["АТОЛ Онлайн"|CarbonBilling:АТОЛ Онлайн]




h2. check_error_worker.sh
{code}- check_error_worker.sh: ERROR(2) [СБОЙ ]

ALARM Имеются ошибки в логе worker за последний час: 57

2019-02-22 08:38:32: pl5monitoring ALARM Имеются ошибки в логе worker за последний час: 57{code}
Тест регистрирует наличине некритичных ошибок обработки абонентов, но требующих реакции администратора или техподдержки.
Узнать что за ошибки произошли Вы можете следующей командой:
{code}grep ERR /app/asr_billing/var/log/worker.log{code}

Ниже приведены кейсы решения некоторых возможных ошибок.
[тут|CarbonBilling:АТОЛ Онлайн]





h3. account_traf - Не найден абонент для N записей (некорректная настройка Collector)
{code}2019-02-22 08:38:02,458 - worker - account_traf - ERROR - Не найден абонент для 367 записей{code}
Ошибка говорит о том, что [обработчик абонентов|Worker (ядро биллинга)] не смог соотнести с каким-либо абонетом часть данных пришедших от [коллектора аккаунтинга интернет-трафика|CarbonBilling:Collector]
Это может произойти, если список с учетными записями и их IP-адресами на стороне коллектора устарел, вероятней всего по какой-то причине он не смог его синхронизировать (синхронизация проходит каждые 30 секунд).
В первую очередь стоит посмотреть лог синхронизатора:
{code}# egrep -i 'CRIT|ERR' /app/collector/var/log/sync_billing.log | head -n 2
2019-02-08 03:48:50,602 - CRITICAL - Не удалось выполнить api запрос: http://192.168.8.71:8082/system_api/?arg1=%7B%7D&model=Collector&psw=3ln8bshn&context=collector&method1=collector_manager.collector_get_checked_ip_pools&format=json.
Error: <urlopen error [Errno 101] Network is unreachable>{code}
Список не обновился потому что в настройках коллектора указан неверный IP-адрес биллинга:
{code}# grep api_ip /app/collector/cfg/config
collector['api_ip.widget']='inputbox "IP адрес для доступа к API биллинга" "IP адрес для доступа к API биллинга"'
collector['api_ip']='192.168.8.71'
{code}
Так как коллектор и биллинг находятся на одном физическом сервере, просто в разных контейнерах, в настройках следует указывать локальынй адрес биллинга 169.254.80.82. Приведите параметр к следуещему виду:
{code}collector['api_ip']='169.254.80.82'{code}
И перезапустите коллектор:
{code}/app/collector/service restart{code}

h3. account_traf - Не найден абонент для N записей (аккаунтинг по неизвестным биллингу IP-адресам)
{code}2019-02-26 09:00:51,620 - worker - account_traf - ERROR - Bad traffic row ID=3408858 IP=10.24.240.1
2019-02-26 09:00:51,621 - worker - account_traf - ERROR - Bad traffic row ID=3408857 IP=10.24.240.1
2019-02-26 09:05:48,390 - worker - account_traf - ERROR - Не найден абонент для 4 записей
2019-02-26 09:05:48,392 - worker - account_traf - ERROR - Bad traffic row ID=3409307 IP=172.31.10.2
2019-02-26 09:05:48,392 - worker - account_traf - ERROR - Bad traffic row ID=3409350 IP=192.168.0.110
2019-02-26 09:05:48,393 - worker - account_traf - ERROR - Bad traffic row ID=3409361 IP=172.31.10.1
2019-02-26 09:05:48,393 - worker - account_traf - ERROR - Bad traffic row ID=3409306 IP=172.31.10.2
2019-02-26 09:15:40,475 - worker - account_traf - ERROR - Не найден абонент для 2 записей
2019-02-26 09:15:40,477 - worker - account_traf - ERROR - Bad traffic row ID=3410341 IP=192.168.0.100
2019-02-26 09:15:40,477 - worker - account_traf - ERROR - Bad traffic row ID=3410342 IP=192.168.0.100{code}
В случае если у Вас возникает ошибка аккаунтинга интернет-трафика, при этом в логе Вы видите записи "Bad traffic row", но нет ошибки синхронизации Collector, как в выше приведенном кейсе, вероятней всего проблема в том, что аккаунтинг (netflow) приходит по IP-адресам находящимся в Вашей сети, но не заведенным в биллинг.
Для решения проблемы ограничте набор интерфейсов с которых собирается netflow и разместите хосты вызывающие ошибку за другими интерфейсами BRAS. В случае если это сделать не возможно, например если Ваше оборудование не имеет такой настройки netflow-сенсора или это нарушит структуру сети, назначьте данные адреса учетным записям в биллинге, Вы можете использовать для этого одного абонента назвав его "Служебный трафик" или завести для каждого хоста своего абонента.
Получить список адресов вызывающих ошибку Вы можете следующей командой:
{code}grep 'Bad traffic row ID' /app/asr_billing/var/log/worker.log | awk '{print $14}' | sed 's/IP=//g' | sort | uniq{code}
Примерный результат:
{code}10.24.240.1
172.16.5.148
172.31.10.1
172.31.10.2{code}

h3. account_voip - Проблема с межоператорским расчетом звонка VoipLog
{code}2019-04-04 16:27:42,794 - worker - account_voip - ERROR - Проблема с межоператорским расчетом звонка VoipLog [ id=805042, src=71111111111, dst=72222222222, s_time=2019-04-04 16:26:30, suid=CDR_SMG1016201904041626305842335, dst_chan=Provider2 ] Доступные операторы: Abonents [ id=1418, name=ООО "Лучший провайдер" ]{code}
Решение проблемы описано в статье "[CarbonBilling:FAQ по ошибкам телефонии]"

h3. account_traf - Очень старая дата у трафика\!
{code}2019-08-28 12:41:40,184 - worker - account_traf - ERROR - Очень старая дата у трафика! Проверьте настройки NAS! Дата: 2010-10-24 02:43:35, User ID: 4769, NAS: 10.0.0.1{code}
Проблема вызвана тем, что в потоке netflow дата и время трафика отличаются от установленных на биллинге. В сообщении об ошибки можно увидеть дату которая была в netflow, ID [учетной записи|CarbonBilling:Учетная запись. Создание и изменение.] и IP NAS-сервера.
{info}Чтобы посмотреть по какой учетной записи возникла проблема в интерфейсе биллинга, подставьте ID из ошибки в адресную строку.
*Пример*. Допусти Вы подключаетесь к биллингу по IP 192.168.0.10, ссылка на учетную запись ID 4769 будет такой: [http://192.168.0.10/admin/Users/4769]

{info}
Настройка netflow-потоков подробно описана в [статье|Настройка и проверка netflow-потоков]. Для того, что бы решить проблему выполните:
# Установите утилиту tshark;
{code}yum -y install wireshark{code}
# Запустите захват пакетов. В примере произведён захват по стандартному порту netflow 9996, на всех интерфейсах;
{code}tshark -pni any port 9996 -V -c 3 | grep -C 1 Timestamp{code}
Вывод будет выглядеть следующим образом:
{code}tshark -pni any port 9996 -V -c 3 | grep -C 1 Timestamp
Running as user "root" and group "root". This could be dangerous.
Capturing on Pseudo-device that captures on all interfaces
SysUptime: 1968550053
Timestamp: May 29, 2019 14:03:54.000000000 IRKT
CurrentSecs: 1559109834
--
SysUptime: 1968550053
Timestamp: May 29, 2019 14:03:54.000000000 IRKT
CurrentSecs: 1559109834
--
SysUptime: 1968550053
Timestamp: May 29, 2019 14:03:54.000000000 IRKT
CurrentSecs: 1559109834
3 packets captured{code}
Нас интересует значение поля *Timestamp*.
# Посмотрите дату и время установленные на биллинге:
{code}
date
{code}
Видим, что время отличается на два часа:
{code}
date
Срд Май 29 16:05:03 IRKT 2019
{code}
# Измените дату и время на NAS исходя из полученных данных.

h3. usluga_abon_pay - У абонента услуга из другого тарифа\!
{code}
2019-11-16 04:31:35,160 - worker - usluga_abon_pay - ERROR - У абонента #25262 услуга #51323 из другого тарифа!
2019-11-16 04:31:35,195 - worker - usluga_abon_pay - ERROR - У абонента #25306 услуга #51779 из другого тарифа!
2019-11-16 04:31:35,205 - worker - usluga_abon_pay - ERROR - У абонента #25429 услуга #54374 из другого тарифа!
2019-11-16 04:31:35,230 - worker - usluga_abon_pay - ERROR - У абонента #25447 услуга #54821 из другого тарифа!
2019-11-16 04:31:35,240 - worker - usluga_abon_pay - ERROR - У абонента #25457 услуга #55231 из другого тарифа!
{code}
Эта исключительная ситуация и прчину можно попробовать найти в аудите, исходя из даты когда последний раз меняли тариф: возможно в этот момент произошла ошибка транзакции.
Для исправления проблемы:
# Переключите абонента на временный тариф, потом верните нужный
# При необходимости сделайте абоненту перерасчет начиная с нужной даты

h2. test_httpd.sh
{code}- test_httpd.sh: ERROR(2) [FAILED]

ALARM Недоступен веб-интерфейс биллинга
Для решения проблемы воспользуйтесь статьёй:
http://docs.carbonsoft.ru/51019784#Системамониторинга-testhttpd.sh
Stopping Admin Web Server: Starting Admin Web Server: [ OK ]
Stopping nginx: [FAILED]
Starting nginx: [ OK ]
Исправить проблему автоматически не удалось.
{code}
Тест говорит о том, что веб-интерфейс управления абонентами и тарифами недоступен.
Найти ошибку можно попытаться в следующих логах веб-сервера:
{code}/app/asr_billing/var/log/nginx/error.log
/app/asr_billing/var/log/nginx/access.log
/app/asr_billing/var/log/admin_web_server.log
/app/asr_billing/var/log/wget_abonents.log{code}
По-умолчанию веб-сервер использует порты 8082 (http) и 8382 (https).
Убедитесь, что в конфигурационном файле */app/asr_billing/cfg/config* заданы сделующие параметры:
{code}app['apache.port']='8082'
app['apache.ip']='169.254.80.82'
app['apache.sslport']='8382'
app['apache.sslip']='169.254.83.82'{code}

h2. check_interbase_log.sh

Тест проверяет журнал ошибок работы СУБД:
{code}- check_interbase_log.sh: ERROR(2) [FAILED]

ALARM Обнаружены ошибки в логах Firebird
Необходимо проверить лог /app/asr_billing//var/log/firebird/firebird.log.catched.1559807284
Для решения проблемы воспользуйтесь статьёй:
http://docs.carbonsoft.ru/51019784#Системамониторинга-checkinterbaselog.sh{code}
В выводе теста написан путь до журнала обнаруженных ошибок: */app/asr_billing//var/log/firebird/firebird.log.catched.1559807284*
Вы можете посмотреть его командой *cat*:
{code}cat /app/asr_billing//var/log/firebird/firebird.log.catched.1559807284{code}
Примре вывода:
{code}localhost.localdomain Thu Jun 6 12:31:16 2019
I/O error for file "/usr/lib64/firebird/security2.fdb"


localhost.localdomain Thu Jun 6 12:31:16 2019
Error while trying to open file


localhost.localdomain Thu Jun 6 12:31:16 2019
No such file or directory


localhost.localdomain Thu Jun 6 12:31:16 2019
I/O error for file "/usr/lib64/firebird/security2.fdb"


localhost.localdomain Thu Jun 6 12:31:16 2019
Error while trying to open file


localhost.localdomain Thu Jun 6 12:31:16 2019
No such file or directory{code}
В данном случае ошибка связана с доступом к файлу одной из системных баз, обеспечивающих работу СУБД.
Как правило, такие задачи следует передавать в отдел разработки для детального анализа каждого конкретного случая.
Тем не менее, это не всегда обязательно.
Есть несколько случаев, которые можно проверить и устранить самостоятельно, без привлечения отдела разработки даже техподдержки:
* В первую очередь следует проверить общий системный лог */var/log/messages* на наличие ошибок дисковой подсистемы, если они есть и относятся к диску на котором расположена БД биллинга - это с высокой долей вероятности может вызвать ошибку работы СУБД.
* Далее можно попробовать посмотреть содержимое файла */app/asr_billing//var/log/firebird/xinetd_169.254.30.50.log*, это журнал службы управлеющий соединениями сервера баз данных, он необходим для экономии ресурсов системы и поддержания нагрузки на БД в разумных пределах.
Если количество обращений к БД превышает допустимое, это вызовет отказ в соединении и в логе СУБД firebird.log появятся соответствующие записи.
В таком случае попробуйте временно ограничить объём внешних соединений к серверу - обращения по API, доступ в панель управления абонентами и тарифами, количество одновременно выполняемых отчетов в [конструкторе|CarbonBilling:Конструктор отчетов]

h2. test_free_space.sh

h3. check_free_fs_space failed
{code}- test_free_space.sh: ERROR(1) [FAILED]

2019-04-10 07:54:55 billing5_server test_free_space.sh[16503]: check_free_fs_space failed on /tmp used 96% when used_limit 85% and free 4741708 when free_limit 5000000
2019-04-10 07:54:55 billing5_server test_free_space.sh[16503]: Filesystem 1K-blocks Used Available Use% Mounted on - 10572056 2253400 7774964 23% /mnt/backup - 85501368 3777096 77374372 5% /mnt/db - 3964096 47108 3712292 2% /mnt/etc - 53396996 5200816 45477104 11% /mnt/log - 9947884 6264104 3171788 67% /mnt/shared - 106925104 96745248 4741700 96% /mnt/var
2019-04-10 07:54:55 billing5_server test_free_space.sh[16503]: ALARM Свободное место на диске заканчивается!

/usr/local/angel/test_free_space.sh ERROR(1)
Create_date: 2019-04-10 07:54:55{code}
Функция +check_free_fs_space+ проверяет наличие свободного места на разделах /var/db, /tmp/ (смонтирован на /mnt/var хост системы), /var/log внутри контейнера биллинга.
Если в описании заявки ошибка возникла в проверке "check_free_fs_space failed", используя утилиту *df \-h* проверьте на каком из разделов места недостаточно (занято более 85%).
Определив проблемный раздел, утилитой *du \-sch /mnt/var/\** Вы можете постепенно найти папку которая занимает более всего места.
Утилитами *rm*, и *mv* Вы можете удалить или перенести данные на другой раздел.

h3. check_db_space
{code}- test_free_space.sh: ERROR(1) [FAILED]

2019-04-10 10:04:24 localhost.localdomain test_free_space.sh[8221]: check_db_space /var/db/billing.gdb size is 1587576832 and on /var/db used 76%
2019-04-10 10:04:24 localhost.localdomain test_free_space.sh[8221]: TRIPLE_BILLING_DB_SIZE=6350307328; FREE_SPACE=6119776256
2019-04-10 10:04:24 localhost.localdomain test_free_space.sh[8221]: Filesystem 1K-blocks Used Available Use% Mounted on - 961173328 660500248 251841568 73% /mnt/backup - 25905452 18606512 5976344 76% /mnt/db - 3966144 42280 3719064 2% /mnt/etc - 961173328 660500248 251841568 73% /mnt/log - 9948012 5649084 3786928 60% /mnt/shared - 32414588 5572272 25189068 19% /mnt/var
2019-04-10 10:04:24 localhost.localdomain test_free_space.sh[8221]: ALARM Свободное место на диске заканчивается!

/usr/local/angel/test_free_space.sh ERROR(1)
Create_date: 2019-04-10 10:04:24{code}
Функция +check_db_space+ проверяет что на разделе /var/db (/mnt/db в хост системе) свободного места в три раза больше текущего размера БД биллинга.
В первую очередь проверьте следующие папки:
* /mnt/db/app/asr_billing/db/notstopped - базы, поврежденные в результатате некорректного завершения работы сервера.
* /mnt/db/app/asr_billing/db/safemode - рабочиие базы, работа которых была завершена корректно, их можно восстановить в работу.
* /mnt/db/app/asr_billing/db/replaced_by_shadow - поврежденные базы, замененные теневой копией
* /mnt/db/app/asr_billing/db/buff_traf.gdb.ГГГГММ - базы с аккаунтингом трафика

Базы из папок *notstopped* и *replaced_by_shadow* могут пригодится если Вы планируете проводить детальный анализ поврежденных баз. Если нет - их можно очистить.
Базы из папки *safemode* можно очистить только в том случае, если в настоящий момент биллинг находится в работе.
Базы buff_traf.gdb.ГГГГММ (например, buff_traf.gdb.201904) содержат информацию по объёмам трафика полученую из netflow или radius accounting, данные из них агрегируются и добавляются в основную БД billing.gdb, их можно видеть в карточках абонентов на вкладке "[Расход|CarbonBilling:Счетчики услуг. Вкладка "Расход".]". Их можно удалять.

h2. 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).

Также данный тест может сообщать следующую ошибку:

{code}ALARM список разрешенного оборудования в Radius не совпадает со списком базы{code}

В тесте есть скрипт, проверяющий соответствие NAS в БД и конфигурационном файле /app/asr_billing/etc/raddb/clients.conf. В случае, если в момент тестирования наблюдались сбои при обращении к БД, может появиться эта ошибка.

Найти причину можно попробовать в логе RADIUS или его архивных копиях:
{code}/app/asr_billing/var/log/radius/radius.log
/app/asr_billing/var/log/radius/radius.log-20191104.gz{code}
Первый файл - актуальный лог
Второй - архивны, в нем информация от момета предыдущей архивации до 04 ноября 2019 года.

Чтобы найти причину, ориентируйтесь на время написанное при падении теста - в примере выше это "2017-03-21 14:48:52". Изучив лог за это время можно найти более подробную информацию о причине ошибки, вероятно она одна из описанных выше.
Если проблема повторяется часто, обратитесь в техподдержку.

h2. test_radius.py

Для отладки теста и подробного разбора проблемы можно выполнить его в режиме повышенного логирования
{code}chroot /app/asr_billing python /usr/local/angel/test_radius.py --debug{code}

h2. test_daemons.sh

Тест срабатывает если одна из служб контейнера не работает и пытается исправить ситуацию автоматический (перезапуском службы). В любом случае будет создана автоматическая заявка. Пример текста ошибки:
{code}- test_daemons.sh: ERROR(2) [FAILED]

2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_daemon admin_web_server
2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: - check_pidfile admin_web_server ok
...
2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_daemon radiusd_acc
2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: - check_pidfile radiusd_acc ok
2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_daemon radiusd_traf
2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_pidfile - Pidfile not found for radiusd_traf
2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: radiusd_traf restart
Stopping radiusd_traf: [FAILED]
Starting radiusd_traf: [ OK ]
2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_daemon radiusd_traf
2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_pidfile - Pidfile not found for radiusd_traf
...
2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: - check_pidfile xinetd ok
2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: ALARM Некоторые демоны не работают, проверьте тест test_daemons.sh{code}
При запуске все службы (=демоны) asr_billing создают маркерный файл в директории /var/lock/subsys/, так тест понимает какие службы нужно проверять (это нужно на случай если какие-то из них отключены в конфигурационном файле контейнера).
По каждой службе из полученного списка тест ищет pid-файл и проверяет что процесс запущен. В результате проверки он может вернуть либо состояние "ОК", что значит что проверка пройдена успешно, либо одну из следующимх ошибок:
* *Pidfile not found* \- тест не нашел пути pid-файл для процесса
* *No pidfile* \- по найденому пути либо не pid-файл (например, папка), либо он удален
* *No pid* \- в PID-файле не оказалось ID процесса (например, если файл оказался пустым)
* *No proc entry* \- pid-файл найден, но процесса с указанным ID не оказалось.

h3. Pidfile not found

Ошибка может произойти если при запуске службы возникли ошибки и запуск не был корректно завершен.
Еще одной возможной причиной может быть если почему-то пропал PID-файл, при том что сама служба работает.

Например, перезапустим службу аккаунтинга трафика:
{code}# /etc/init.d/radiusd_traf restart
Stopping radiusd_traf: [FAILED]
Starting radiusd_traf: [ OK ]{code}
Ошибка произошла про причине того, что процесс уже запущен, но PID-файл почему-то не создан:
{code}# ps aux | grep radiusd_traf | grep -v grep
radiusd 10218 0.0 0.0 492948 4516 ? Ssl 03:30 0:00 /usr/sbin/radiusd_traf -d /etc/raddb_traf{code}
Находим должное насположение PID-файла (подставьте путь до init файла службы) и убеждаемся что его действительно нет и ошибка не в самом тесте:
{code}# grep ^prog /etc/init.d/radiusd_traf | sed 's/.*=//g' | while read progname; do pidpath=$(grep ^pidfile /etc/init.d/radiusd_traf | sed 's/\$prog/'$progname'/g; s/.*=//g; s/\}//g'); ls -l $pidpath; done
ls: cannot access /var/run/radiusd_traf/radiusd_traf.pid: No such file or directory{code}
Для решения проблемы Вы можете послать сигнал TERM командой *kill \-15 PID_процесса* и заново его запустить.

h2. ALARM Billing Не настроены реквизиты доступа к администраторской панели для тестирования

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

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

При изменении пароля *root*, необходимо исправить так же конфигурационный файл. Либо Вы можете создать нового администратора исключительно для данной функции по статье "[Интерфейсы пользователей биллинга|Интерфейсы пользователей биллинга]" и указать его учетные данные.

*/app/asr_billing/cfg/config*
{code}declare -A django
django['username']='root'
django['password']='servicemode'{code}

h2. FATAL Billing Error copy metadata

Заявка может возникнуть при обновлении базы данных и говорит о том, что в процессе возникли какие-либо ошибки. Обновление БД может происходить в следующих случаях:
* Автоматически, [обновлении биллинга|CarbonBilling:Обновление платформы],
* Вручную, при запуске *update_hook.sh* во время [переноса биллинга на новый сервер|Перенос на другой сервер (классический способ)]
* Вручную, при запуске *update_hook.sh* при [восстановлении биллинга из резервной копии|CarbonBilling:Восстановление БД биллинга из резервной копии.]

Скрипт обновления БД пишет лог в файл */app/asr_billing/var/log/ib_upgrade.sh.log*
Так же определить наличие проблемы можно сравнив версию БД и версию биллинга. При нормальной работе версии должны совпадать.
* Просмотр версии биллинга:
{code}
cat /app/Billing.version
{code}
* Просмотр версии БД:
{code}
sqlexec "set list; select CONST_VALUE from vpn_const where const_id = 7"
{code}
Если Вы столкнулись с этой ошибкой, попробуйте еще раз запустить *update_hook.sh* с ключем *\--force*.
{code}
/app/asr_billing/service stop
chroot /app/asr_billing
update_hook.sh --force
exit
/app/asr_billing/service start
{code}
Или повторно запустить обновление биллинга с ключем *\--force*.
{code}
carbon_update update --force
{code}
{warning}{*}update_hook.sh* можно запускать только на остановленном биллинге{warning}
В случае если повторное обновление не исправило проблему (это можно проверить по логу, поискав слово "error"), обратитесь в техподдержку.

h2. ALARM /usr/local/bin/sync_nas\! Не могу получить списки

Ошибка теста говорит о том, что в процессе [синхронизации оборудования интернет|CarbonBilling:Синхронизация абонентов на оборудовании] возникли ошибки.
Причину ошибки можно определить по логу синхронизации */app/asr_billing/var/log/sync_nasd.log*. Ниже описаны наиболее часто возникающие ошибки и пети их решения.

h4. NAS-сервер недоступен для биллинга

Сообщения в логе:
{code}__main__.TimeoutError: Timeout
[Errno 113] No route to host
[Errno 113] No route to host{code}
Проверьте что:
* NAS-сервер включен
* NAS-сервер доступепен биллингу по сети
* На NAS-сервере не заблокирован доступ с биллинга фаерволом

h3. Отключен или закрыт фаерволом порт протокола синхронизации

Сообщения в логе:
{code}[Errno 111] Connection refused
[Errno 111] Connection refused
[Errno 111] Connection refused{code}
Проверьте следующее:
* В биллинге указан правильный порт управления NAS-сервером
* На NAS-сервере обращения с биллинга не блокируются фаерволом
* На NAS-сервере включен протокол через который описано получение данных в *session* скрипте (в стандартных схемах это API для Mikrotik, ssh/telnet для Cisco и RedBack)

h3. В функции users_from_nas скрипта [session|Пользовательская custom схема] есть ошибка, в результате которой она завершается некорректно

Пример сообщений в логе:
{code}2019-03-26 10:26:51 vm120 sync_nas[1897]: sync by oss cheme
/var/oss/core/Mikrotik-Simple/bin/session: line 75: syntax error near unexpected token `}'
/var/oss/core/Mikrotik-Simple/bin/session: line 75: `}'
/usr/local/bin/sync_nas: line 207: users_from_nas: command not found{code}
В указанном скрипте */var/oss/core/Mikrotik-Simple/bin/session* есть ошибка синтаксиса.
В примере некорректно реализовано ветвление (if \[ nnn \]; then; действие; fi), не дописан оператор закрывающий "if", и bash дойдя до конца функции users_from_nas говорит об ошибке.

h3. Вы интегрируете новый NAS и ошибка возникла в процессе отладки.

В случае если Вы интегрируете новый NAS, снимите опцию "*В эксплуатации*" чтобы погасить ошибки синхронизации до момент когда он будет полностью интегрирован.

!nas_in_production.png|border=1,width=400!

h2. WARNING Обнаружены ошибки удаления абонентов

h3. Удалены папки с работающими абонентами

Это могло произойти в старых версиях биллинга и при попытке закрыть период произойдет ошибка нарушения связей в базе данных.
Получить список не удаленных абонентов чьи папки в корзине можно через [конструктор отчетов|CarbonBilling:Конструктор отчетов]:
{code}select
ab2.id "ID папки", ab2.name "Название папки", ab.id "ID абонента", ab.name "Наименование/ФИО", ab.contract_number "Номер договора"
from abonents ab
left join abonents ab2 on ab.parent_id=ab2.id
where
ab2.deleted=1 and (ab.deleted is null or ab.deleted=0) and ab2.id<>4{code}

h1. Тесты asr_cabinet

h2. check_cabinet_httpd_netstat.sh

Код ошибки:
{code}
- check_cabinet_httpd_netstat.sh: ERROR(2) [СБОЙ ]

ALARM Веб-сервер локального сайта недоступен
Для решения проблемы воспользуйтесь статьёй:
http://docs.carbonsoft.ru/51019784#Системамониторинга-checkcabinethttpdnetstat.sh
Останавливается httpd: [ OK ]
Запускается httpd: [ OK ]
Исправить проблему автоматически не удалось.
{code}

Сбой теста говорит о проблеме с сайтом провайдера и личным кабинетом. Ошибка возникает при редактировании конфигурационного файла httpd.conf . Обычно это происходит при установке [ssl сертификата на локальный сайт|Установка ssl сертификата на локальный сайт].

Путь к файлу httpd.conf:
{code}
/app/asr_cabinet/etc/httpd/conf/httpd.conf
{code}

Для исправления ошибки необходимо восстановить стандартный конфигурационный файл httpd.conf , для этого нужно:
# Зайти в chroot asr_cabinet:
{code}
chroot /app/asr_cabinet/
{code}
# Сохраняем текущие конфигурационные файлы:
{code}
echo yes | mv /cfg/config /root/
echo yes | mv /cfg/etc/httpd/conf/httpd.conf /root/
{code}
# Копируем стандартный конфигурационный файл:
{code}
cp -p /skelet/cfg/config /cfg/
{code}
# Выходим из chroot asr_cabinet и перезапускаем его:
{code}
exit
/app/asr_cabinet/service restart
{code}

h1. Тесты collector

h2. check_critical_traf_reporter.sh
{code}- check_check_critical_traf_reporter.sh: ERROR(1) [СБОЙ ]

ALARM Критические ошибки в логе /var/log/reporter.log: 4

2018-03-20 17:07:00: pl5monitoring ALARM Критические ошибки в логе /var/log/reporter.log: 4

/usr/local/monitoring/check_check_critical_traf_reporter.sh ERROR(1)
Create_date: 2018-03-20 17:07:00{code}
Тест определяет наличине ошибок в логе traf_reporter - эта служба отправляет в биллинг данные по объёмам абонентского трафика. Данные отправляются на radiusd_traf в биллинге. Подобные ошибки могу возникать, если с RADIUS-сервер трафика в биллинге отключен или его работа была прервана по какой-либо причине. Отсутствие связи можно увидеть по логу traf-reporter:
{code}# grep ERR /app/collector/var/log/reporter.log -A10 | tail -n 9
2018-03-20 17:04:25 - [traf-reporter] - ERROR - File /var/dump/1521471029.10.0.0.1.dat. Not send packets: 1
2018-03-20 17:04:25 - [traf-reporter] - INFO - File /var/dump/1521471029.10.0.0.1.dat not remove
2018-03-20 17:04:41 - [traf-reporter] - INFO - RADIUS server does not reply
2018-03-20 17:04:41 - [traf-reporter] - INFO - Radius server does not responce. Sleep 60 sec and retry.
2018-03-20 17:05:56 - [traf-reporter] - INFO - RADIUS server does not reply
2018-03-20 17:05:56 - [traf-reporter] - ERROR - File /var/dump/1521524972.10.0.0.2.dat. Not send packets: 1
2018-03-20 17:05:56 - [traf-reporter] - INFO - File /var/dump/1521524972.10.0.0.2.dat not remove
2018-03-20 17:06:11 - [traf-reporter] - INFO - RADIUS server does not reply
2018-03-20 17:06:11 - [traf-reporter] - INFO - Radius server does not responce. Sleep 60 sec and retry.{code}
Обратить внимание следует на сообшение "RADIUS server does not reply"
Для решения проблемы попробуйте перезапустить RADIUS:
{code}chroot /app/asr_billing/ service radiusd_traf restart{code}
Возможные ответы:
{panel}Starting radiusd_traf: {color:green}\[ OK \]{color}{panel}
Корректный ответ, сервис запустился. На всякий случай проверьте что трафик стал отсылаться в биллинг по логу репортера (новые сообщения должны быть только с тегом INFO:
{code}
2018-03-20 15:20:50 - [traf-reporter] - INFO - File /var/dump/1521548443.10.0.0.1.dat remove
2018-03-20 15:20:50 - [traf-reporter] - INFO - Stop report
2018-03-20 15:20:50 - [traf-reporter] - INFO - Wait 10 seconds...
2018-03-20 15:21:00 - [traf-reporter] - INFO - Start report
2018-03-20 15:21:00 - [traf-reporter] - INFO - File /var/dump/1521548458.10.0.0.2.dat remove
2018-03-20 15:21:00 - [traf-reporter] - INFO - File /var/dump/1521548457.dat remove
2018-03-20 15:21:00 - [traf-reporter] - INFO - Stop report
{code}
{panel}Stopping radiusd_traf: {color:red}\[FAILED\]{color}{panel}
Подобный ответ говорит о проблемах с запуском радиус-сервера. Попробуйте найти решение в документации или обратитесь в техподдержку.
{panel}radius_traf disabled in /cfg/config{panel}
Данный ответ говорит о том, что сервер сбора трафика отключен в настройках биллинга. Включите его в биллинге в меню [Настройки (в файле)|CarbonBilling:Настройки (в файле)]





h2. check_bstat_check_raw_stat.sh
{code} Отсутствует сырая статистика

/usr/local/monitoring/check_bstat_check_raw_stat.sh ERROR(2)
Create_date: 2019-05-27 00:05:14 {code}

Тест проверяет, включен ли bstatd (можно проверить на веб-интерфейсе в настройках "Системы сбора статистики"), а также наличие данных статистики в /var/stat/binstat/ и /var/stat/raw/. Необходимо проверить, появляются ли файлы в данных папках, если нет, то может быть проблема с NAS, по причине которой он не отправляет статистику на биллинг.


h2. check_bstat_many_raw.sh

{code}
- check_bstat_many_raw.sh: ERROR(2) [СБОЙ ]

ALARM Большое кол-во необработанной сырой статистики

2019-08-22 11:41:12: pl5monitoring ALARM Большое кол-во необработанной сырой статистики

/usr/local/monitoring/check_bstat_many_raw.sh ERROR(2)
Create_date: 2019-08-22 11:41:12

{code}

Тест проверяет количество файлов сырой статистики bstatd в директории:
{code}/app/collector/var/stat/raw/{code}
При превышении лимита создаётся автоматическая заявка. В большинстве случаев достаточно перезапустить сервис bstatd командой:
{code}
chroot /app/collector/ service bstatd restart
{code}

h3. Включена устаревшая функция: "Сохранять сырую статистику"

В прошлом (еще до [появления nfsen в поставке|CarbonBilling:nfsen]) мы добавили функцию сбора сырой статисти для дальнейшего анализа Nfsen. Идея была в том чтобы собирать её для диагностики если есть подозрения что [детальная статистика в биллинге|CarbonBilling:bstatd] работает некорректно.
Подразумевается, что такая сырая статистика собиралась бы короткий промежуток времени, анализировалась и вручную удалялась.
Если на Вашем сервере сбор включен и с собранными файлами ни чего не делать, то через какое-то время сработает тест *check_bstat_many_raw.sh*.

Определить, в этом проблема или нет, и решить её можно так:
# Посмотрите, есть ли файлы сырой статистики для nfsen:
{code:title=Команда}find /app/collector/var/stat/raw/ -iname 'rawnetflow*' | wc -l{code}
{code:title=Пример вывода когда есть файлы статистики}194{code}
# Если вывод будет больше ноля, как в примере выше, рекомендуем отключить опцию и удалить собранную статистику.
# Отключить можно в настройках [служб сбора статистики|CarbonBilling:Описание работы служб сбора статистики], на вкладке "*Настойки сохранения сырой статистики*", опция "*Сохранять сырую статистику*"
# Удалить уже собранную статистику можно такой командой:
{code}find /app/collector/var/stat/raw/ -iname 'rawnetflow*' -delete{code}

h2. check_disk_space_stat.sh
{code}- check_disk_space_stat.sh: ERROR(2) [FAILED]

ALARM Заканчивается место для детальной статистики
Для решения проблемы воспользуйтесь статьёй:
http://docs.carbonsoft.ru/51019784#Системамониторинга-checkdiskspacestat.sh
df: Warning: cannot read table of mounted file systems: No such file or directory{code}
Ошибка говорит о том, что у Вас недостаточно места для хранения [детальной статистики|CarbonBilling:Описание работы служб сбора статистики].
Для решения проблемы удалите часть архива или подключите более объемный диск по статье "[CarbonBilling:Добавление диска под статистику]"

Тест начинает сообщать о проблеме когда на разделе со статистикой остаётся меньше чем:
* На 7 дней
* 14Гб

{info}Объём статистики за 7 дней вычисляется исходя из архива предыдущих месяцев - тест ищет в каком периоде было больше всего статстики, делить объём на 30 и умножает на 7.{info}
{note}Рекомендуемый объём диска *1ТБ*, диска меньшего объёма скорей всего надолго не хватит.{note}

h1. Тесты xge

h2. 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}

h2. check_vm.sh

Сообщение:
{info}ALARM XGE запущен на виртуальной машине: kvm. Максимальная производительности может быть достигнута только при установке на физическую машину.{info}
Имя виртуальной машины может изменяться, в зависимости от оборудования.

Тест сообщает об ошибке потому что XGE (как отдельно, так и в составе Softrouter) не предназначен для работы в гипервизоре. Softrouter и XGE предназначены только для работы на физическом оборудовании.
Стабильная работа в виртуальных машинах не гарантируется и поддержка по проблемам с повисаниями, с потерей пакетов, с производительностью не оказывается.
Об этом так же упоминается в статье [CarbonBilling:Системные требования]






h2. check_xge_httpd_redirect_netstat.sh

Сообщение:

{info}WARNING Не слушает http-сервер XGE для неавторизованных{info}

{info}WARNING Не слушает внутренний http сервер XGE{info}

Тест сообщает об ошибке, если в файле /app/xge/cfg/config указан некорректный IP-адрес для редиректа. Необходимо проверить строку

{code} httpd['internal_ip']='169.254.80.90' {code}

Если IP-адрес отличается от указанного выше, необходимо заменить его на 169.254.80.90 и перезапустить контейнер XGE.


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}

h3. Самые распространенные причины

# Не создалась резервная копия *asr_billing*. Скорее всего, выявились ошибки БД. Об будет сообщено в логе, и в этом случае лучше сразу обратиться в техподдержку. Дополнительные логи программы *gbak*, которая не смогла снять резервную копию, доступны в файле
{code}/app/asr_billing/var/log/backup_db_v2.sh.log{code}
# Резервная копия не не была выложена на ftp. В случае ошибок curl, он выполняется повторно с флагом \-v и в логе пишется строка с аргументами, которые передаются в curl. Вы можете напрямую скопировать команду с curl в консоль для отладки. Подробней об ошибках выгрузки Вы можете прочитать в [соответствующей статье|Система мониторинга]

h2. ALARM Не обнаружен работающий UPS

Настройка и решение проблемы с ИБП описаны в статье [CarbonBaseSystem:Подсистема контроля UPS]






h2. ALARM Мало свободного места на диске\!

Ошибка возникает если на одном из разделов занято более 85% пространства.

h3. Диагностика в командной строке:

1. Проверям какой раздел заполнен:
{code}
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 3,7G 1,9G 1,6G 55% /
/dev/sda2 14G 6,7G 6,3G 52% /app
/dev/sda3 13G 1,4G 11G 12% /mnt/backup
/dev/sda4 1,9G 36M 1,7G 3% /mnt/etc
/dev/sda5 53G 47,2G 5.8G 89% /mnt/var
/dev/sda6 8,2G 4,3G 3,6G 55% /mnt/log
/dev/sdb1 394G 140G 234G 38% /mnt/stat
/dev/sdb1 394G 140G 234G 38% /app/collector/mnt/var/stat
{code}

Видно, что заполнен раздел /dev/sda5 с логами.
{code}
/dev/sda5 53G 47,2G 5.8G 89% /mnt/var
{code}

2. Теперь нужно узнать какие именно данные занимают раздел. Запускаем комманду подсчёта объёма и двигаемся вглубь файловой системы.
{code}
du -sh /mnt/log/*
{code}

3. После того как найдены данные, которые зинимаю диск, их необходимо перенести на другой носитель. Или подключить дополнительный диск для их хранения. Для раздела с логами это можно сделать по [инструкции|CarbonBilling:Добавление диска под логи].

{info}
В данном примере рассмотрено заполение раздела с логами. Удалить старые логи можно по [статье|Переполнение разделов диска логами].
{info}

h2. ALARM app заблокирован в течении минут

Журнал блокировок пишется в файл */var/log/pl5_service.log*.
По времени создания заявки можно найти какая оперпция занимала слишком много времени и отладить.

h2. ALARM CRITICAL carbon_update скрипт обновления завершился

В тексте сообщения об ошибке будет описано при обновлени какого контейнера произошла ошибка, например:
{code} Обновление #5 [20] от 2019-03-28 07:30:42:
CRITICAL - carbon_update: скрипт обновления завершился с ошибкой 12
----
app: base{code}
"Номер" ошибки - это код возврата какого-либо из скриптов обновления запускаемых при обновлении, инициируемых основным скриптом *carbon_update*.
Если ошибка возникнет повторно, описание заявки обновится, будет указано время когда она последний раз возникала.
В зависимости от способа запуска обновления (автообновление изи вручную из веб-интерфейса), полную информацию об ошибке можно найти в файлах:
* Автообновление: /var/log/carbon_update_autoupdate.log (лог обновления) или /var/log/carbon_update_download.log (лог загрузки актуального дистрибутива)
* Вручную: /app/base/var/log/update.log
Ошибку можно попробовать найти утилитой *grep*, например:
{code}grep 'скрипт обновления завершился с ошибкой' /var/log/carbon_update_download.log --color -n{code}
grep с флагом "-n*" первым полепи пишет номер строки в файле где обнаружена ошибка:
{code}1024648:2019-03-28 10:30:04: CRITICAL - carbon_update: скрипт обновления завершился с ошибкой 12{code}
Перейдя к этой строке в файле, чуть выше можно посмотреть расширенный лог и найти в каком месте работы скрипта возникла ошибка

h3. скрипт обновления завершился с ошибкой 12
{code}+ /app/base/usr/local/bin/update/rsync --block-size=40507 -c --port=555 --timeout=60 --exclude=/var/ --exclude=/etc/ --exclude=/cfg/ update51.carbonsoft.ru::filearchive/profiles/Billing /tmp/__update_download.24716._app_list
rsync: read error: Connection reset by peer (104)
rsync error: error in rsync protocol data stream (code 12) at io.c(768) [Receiver=3.0.9]{code}
Согласно логу, скрипт не смог загрузить обновление с сервера, соединение было сброшено самим сервером обновлений.
Вероятные причины:
* В момент когда Ваша установка пыталась запустить обновление, присходил выпуск новой версии и старая стала недоступна для загрузки
* В момент когда Ваша установка пыталась запустить обновление, на сервере начались технические работы

h2. ALARM Повышенная нагрузка на некоторые ядра
{code}pl5angel Повышенная нагрузка на некоторые ядра процессора.

Мы отслеживаем сколько ресурсов процессора потребляют процессы ядра: events/* и ksoftirqd/*
Основанием для срабатывания проверки является превышения лимита в 15
одним из процессов 4 раза подряд с промежутками 3, 6 и 9 секунд между замерами

4 root 20 0 0 0 0 S 21.4 0.0 1406:21 [ksoftirqd/
53 root 20 0 0 0 0 S 1.9 0.0 1:32.39 [ksoftirqd/

По названию процессов перечисленных выше можно определить перегруженные ядра.

Всего ядер - 16. Если более одного ядра имеют нагрузку выше 15.0,
возможно перегружен весь сервер и нужно искать причину высокой нагрузки.
Если такое ядро только одно - нужно найти способ распределить нагрузку по ядрам.

Возможны ситуации при которых нагрузка возрастает скачками из-за большого числа интерфейсов
+ стороннего софта для мониторинга, который слишком часто считывает счётчики из системы.

Информация о нагрузке записана в /app/base/var/log/check_kprocessess.log
Обратите внимание на то, что ещё было запущено в момент повышения нагрузки.

/app/base/usr/local/angel/check_kprocesses.sh ERROR(2)
Create_date: 2019-04-04 21:10:22{code}
Тест реагирует на проблему некорректого распределения обработки прерываний по ядрам процессора, вероятней всего на Вашем сервере этим занимается только одно ядро.
Диагностика и решение подробно описаны в документации по Carbon Reductor X, так же построенного на платформе Carbon: [REDUCTOR9:Потери на сетевых картах, задержки в обработке и как с ними бороться]
Быстро решить проблему можно, попытавшись запустить утилиту автоматического рапределения прерываний, вызываемых обработкой сетевого трафика по всем используемым сетевым интерфейсам, например:
{code}rss-ladder eth0{code}
Если это исправит проблему, не забудьте добавить автоматический вызов настройки в [хук|xge:Дополнительные настройки. hooks. Хуки] XGE
{info}Проблема актуальна для продуктов Reductor, XGE и Softrouter. Если она произошла на Billing или Billing_Slave, обязательно обратитесь в техподдержку{info}

h2. ALARM Обнаружен другой работающий watchdog

На сервере работает [система мониторинга|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=51019784#Системамониторинга-Системамониторинга], каждые 10 минут она запускает набор автоматических тестов, если в работе подсистем продукта (Биллинга, маршрутизатора XGE, Редуктора и тд) обнаружены ошибки - отправляет сообщение администратору на почту и создаёт заявку в портале HelpDesk.

В исключительных случаях может случиться так, что очередной запуск тестов не уложится в 10 минут и следующая итерация не сможет начаться, в место этого будет создана заявка о возникшей проблеме.

Такие ситуации нужно анализировать по логам системы мониторинга и попробовать определить что за тест вызвал проблему, дальше анализировать поведение и файлы журналов службы которую проверял тест.

Лог системы мониторинга:

* Тесты запускаемые раз в 10 минут
{code}/app/base/var/log/watchdog.log{code}
* Тесты запускаемые раз в 6 часов, обычно некритичные
{code}/app/base/var/log/monitoring.log{code}

h2. WARNING Не доступны DNS серверы
{code}- check_dns.sh: ERROR(2) [FAILED]

WARNING Не доступны DNS-серверы

2019-04-10 11:03:31: pl5angel WARNING Не доступны DNS-серверы

/app/base/usr/local/angel/check_dns.sh ERROR(2)
Create_date: 2019-04-10 11:03:31{code}
Тест *check_dns.sh* есть в каждом контейнере платформы Carbon. Для контейнера *base* используются DNS-сервера host-системы, он выполняет команду "*nslookup \-timeout=X ya.ru*", "X" - количество секунд ожидания ответа, задаётся в конфигурационном файле контейнера (например, /app/+base+/cfg/config)
Возможные причины возникновения проблемы:
* В файле /etc/resolv.conf контейнера не указаны или указаны неверные DNS-сервера.
* Заданные DNS-сервера не отвечают
* Заданные DNS-сервера отвечают слишком долго (дольше заданного timeout)

h3. В файле /etc/resolv.conf контейнера не указаны или указаны неверные DNS-сервера.

Укажите работающие и доступные для биллинга DNS-сервера по статье "[CarbonBilling:Настройки сети]" и перезапустите все :
{code}/etc/init.d/apps restart{code}

h3. Заданные DNS-сервера не отвечают

Убедитесь, что биллингу доступен интернет и есть доступ до заданных DNS-серверов.
Убедитесь что DNS-сервера работоспособны.
Попробуйте указать в [настройках сети|CarbonBilling:Настройки сети] публично доступные DNS-сервера, например 8.8.8.8 (Google) или 77.88.8.8 (Yandex)

h3. Заданные DNS-сервера отвечают слишком долго (дольше заданного timeout)

Выполните вручную команду:
{code}nslookup timeout=1 ya.ru{code}
Если DNS-сервер не ответит вовремя, увеличьте timeout на еденицу (timeout=2) и так далее пока не найдете оптимальное значение.
Когда удастся определить рабочий timeout, выполните следуюищй скрипт, где new_timeout задаёте равным нужному значению:
{code}new_timeout=2; cat /app/01_*.list | while read app; do sed "s/app\['dns_timeout'\]='[0-9].*'/app\['dns_timeout'\]='$new_timeout'/g" -i /app/$app/cfg/config; done{code}
Скрипт из примера установит timeout=2 в конфигурационных файлах всех контейнеров.

h1. Диагностика в веб-интерфейсе

Описание диагностики находится в [соответствующей статье|CarbonBilling:Диагностика системы].[АТОЛ Онлайн|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=154238981]