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

Skip to end of metadata
Go to start of metadata
Вы просматриваете старую версию данной страницы. Смотрите текущую версию. Сравнить с текущим  |   просмотр истории страницы

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

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

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

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

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

1. При каких либо сбоях требуется проверить состояние сервера и работу всех служб. Делается это командой 

server_check

В ответ будет выведено состояние всех служб биллинга. Все службы должны иметь состояние [ OK ]. Если где-то есть сбой, то при обращении в поддержку укажите сбойную службу.

2. Для проверки базы можно посмотреть логи которые ведет система:
лог базы биллинга

cat /app/asr_billing/var/log/firebird/firebird.log

В выводе особое внимание обратить на строки содержащие примерно такие блоки текста

2.1. Повреждена целостность БД, серьезный сбой. Вероятно потребуется восстановление из бекапа:

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)

2.2. Биллинг не может найти БД, вероятно биллинг в safemode:

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

2.3. Отдельная запись в таблице помечена как поврежденная:

Database: /mnt/var/db/billing.process.gdb.13836
Record 1002 is marked as damaged in table RDB$RELATIONS (6)

Тесты base

check_free_inodes.sh

- check_free_inodes.sh:  ERROR(254)                        [FAILED]

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

    ALARM На одном из устройств осталось мало свободных inode. Возможно какая-то папка забита большим количеством файлов

Ошибка говорит о том, что на одном из дисков слишком много файлов, в результате чего переполнена база файловой системы (inodes).
Для решения проблемы попробуйте перезагрузить сервер - возможно какой-то процесс создал много файлов, удалил, но до сих пор держит их в памяти.
Если перезагрузка не решила проблему, необходимо опеределить где слишком много файлов и удалить лишнее.
Воспользуйтесь утилитой tree, запустив её на указанный раздел:

tree /mnt/var/ | tail -n 1

Вывод будет преблизительно следующим:

39143 directories, 8730047 files

После чего нужно посмотреть сколько занято подпапками:

find /mnt/var -maxdepth 1 -type d | grep -v /$ | while read path; do echo $path; tree $path | tail -n 1; done

И так постепенно можно найти папки в которых находится более всего файлов. Что делать с файлами зависит от конкретной ситуации.
Если лишних файлов не оказалось, - их просто много -, возможно стоит пересоздать файловую систему, зарезервировав под БД файлов больший процент раздела передав команде mkfs параметр -N.
Возможно получится увеличить число inode без пересоздания утилитой tune2fs с ключем -m
Как временно перерести данные Вы можете узнать в разделе "Замена оборудования". Полную информацию по параметрам утилит mkfs и tune2fs Вы можете найти в их справочном руководстве: man mkfs.ext4, man tune2fs

Возмжно предварительно потребуется установить команду man:
yum install -y man

check_apps_not_destroyed.sh

- check_apps_not_destroyed.sh:  ERROR(2)                   [FAILED]

    ALARM Некорректное состояние аппов
    Обнаружены следующие аппы в состоянии destroy, которые должны быть включены:
    	 collector
    Требуется перезапустить их с помощью /etc/init.d/apps restart

Ошибка говорит о том, что какая-то из подсистем (контейнеров) платформы Carbon остановлена и "разрушена" - под этим понимается что контейнер остановлен и все точки монтирования внутри контейнера размонтированы.
Возможные причины:

  • Сервер был перезагружен некорректно, без остановки биллинга по статье "Выключение, перезагрузка сервера"
  • Ведутся сервисные работы, изменяется конфигурация (например добавляются диски для расширения пространства под какие-либо данные) контейнера
  • При "сборе" контейнера произошла ошибка и какие-то разделы внутри него сервисный скрипт не смог замонтировать
  • Произошла какая-либо иная ошибка при старте системы, из-за которой работа сервисного скрипта запускающего платформу Carbon завершилась некорректно (например, если на диске были обнаружены ошибки и системная утилита mount не смогла собрать контейнер)

Для отладки в первую очередь можно попробовать запустить команду build:

/app/collector/service build

И посмотреть каким будет вывод, исходя из этого пути решения могут быть разными. Ниже рассмотрены возможные проблемы.

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

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

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

Попробуйте найти в журнале сервисного скрипта информацию когда контейнер с котором произошла ошибка запускался:

[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

По данному времени попробуйте найти информацию в логах загрузки (сохраняются в папке /var/log/boot/) и в системном логе */var/log/messages и архивных логах:

cat /var/log/messages*

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

Ошибка монтирования

/app/collector build
mount: no such partition found

# /app/collector/service build:                            [FAILED]

В конфигурационном файле collector настроено сохранение детальной статистики на отдельный диск:

# 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'

Но раздела с ID a7a26c14-e788-40a0-b0f9-f051be5c9e61 нет в системе:

[root@st-rline ~]# blkid | grep a7a26c14-e788-40a0-b0f9-f051be5c9e61 -c
0

Весьма вероятно что конфигурационный файл перенесли с другого сервера, но диск на который ранее сохранялась статистика не подключили. Вариантов решения несколько:

  1. Выключите сервер, подключите диск, включите сервер
  2. Настройте сохранение на другой выделенный диск или раздел
  3. Уберите настройку выделенного раздела из конфигурационного файла

check_loadaverage.sh

- 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

load average показывает очередь к CPU на выполнение запущенных процессов. Оно не должно превышать количество потоков. Если Вы столкнулись с такой проблемой, попробуйте проанилизровать лог: в него записывается вывод команды ps -aux при срабатывании теста:

/app/base/var/log/check_loadaverage.log
  1. Анализ можно провести специальным скриптом:
    /app/base/usr/local/bin/analyze_check_loadaverage_log.sh --analyze
  2. В начале вывода Вы увидите историю срабатывания автотеста, например:
    /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

    Так можно понять, часто ли возникает проблема и в какие промежутки времени - постоянно, или систематический в какое-то время, или это совершенно случайные события.

  3. Дале тест выводит топ 10 задач, нагружавших процессор по каждлому случаю, например:
    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

    Поняв что за процессы создают максимум нагрузки, можно попробовать:

    • Проанализировать их лог (если есть), посмотреть что они делали в указанное время
    • Возможно работа этих процессов завязана на системные ресурсы, которых им не хватает - ОЗУ, скорость работы дисков и тд.
    • Если используется SSD, убедитесть что диск произвонительный по современным меркам: более 50 000 IOPS на запись и чтение, ресурс по крайней мере 300TB, используемые чипы памяти SLC, MLC или TLC
    • Если используется аппаратный RAID-контроллер, то установлена BBU (батарея для сохранения кеша записи при отключении питания) - её отсутствие заметно снижает производительность дисковой подсистемы.
    • Если у вас все диски подключены к аппаратному RAID - выделите под статистику отдельный виртуальный диск, с ограниченным кешем, в противном случае постоянно поступающая статистика будет заполнять кеш контроллера, снижая производительность
    • Подключите отдельные диски под детальную статистику, логи (можно один диск на логи и статистику) и базу данных
    • Убедитесь, что используется производительный RAID: например, если диски собраны в RAID-6 – это надежный, но весьма медленный вариант, его можно использовать для хранения детальной статистики. Систему и БД лучше держать на RAID10

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

Одной из основных проблем замедления работы является недостаточно производительные диски. Это можно проверить так:

awk '($0~"ALARM load average" || $8=="D")' /app/base/var/log/check_loadaverage.log | less

Если в выводе будет множество процессов в состоянии "D" (непрерываемй сон, состояние в котором процесс ожидает некоторое реакции ядра ОС и при этом не может быть прерван), это с вероятностью 99.9% говорит о недостаточной производительности дисков. Пример такого вывода:

Срд Окт 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
....

Вывод сокращен, в действительности там еще около 30 строк с процессами в состоянии "D" и почти все они скрипты системы, получающие данные из БД биллинга.
Для решения проблемы потребовалось перенести базу на отдельный SSD диск с высокими показателями IOPS.

Тесты asr_billing

check_billing_db_size.sh

- 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 Чрезмерно большая база данных биллинга

Ошибка происходит при увеличении размера БД до 10Гб. Почему так происходит, описано в справочной документации firebird.
Со временем база может достичь данного размера по той простой причине, что место на диске не очищается при удалении записей из базы данных, так как это создаст лишнюю постоянную нагрузку на диск и ОЗУ. Записи в БД добавляются постоянно - любые события, происходящие с абонентами, их лицевыми считами, оборудованием, добавляются в стэк событий, обрабатываются воркером, после чего очищаются.
Для решения проблемы Вам необходимо создать резервную копию, после чего восстановиться с неё же.

check_critical_jobs.sh

- check_critical_jobs.sh:  ERROR(2)                        [СБОЙ ]

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

Тест сообщает что при выполнении запланированных задач произошла ошибка. Посмотрел описание ошибки можно в логе службы:

grep CRITICAL /app/asr_billing//var/log/jobs_daemon.log | cut -d' ' -f 8-100 | sort | uniq

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

В сообщении об ошибке будет написан ID задачи. По нему можно определить на каком абоненте она была создана:

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

Некорректного заполнения параметров запланированной задачи: отчеты

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

Ошибка возникла из-за некорректного заполнения параметров запланированной задачи на выполнение отчета - не указан ID отчета.

Некорректного заполнения параметров запланированной задачи: рассылка сообщений

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

Ошибка возникла из-за некорректного заполнения параметров запланированной задачи на рассылку сообщений - в параметрах задачи написали лишние символы кавычек "<" и ">"

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

Создана задача на выполнение отчёта. В sql запросе имеется ошибка.

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

Здесь указан ID отчета, но всё равно фиксируется ошибка. Для подробной дигностики откройте лог в программе просмотра текста less и найдите ошибку:

less /app/asr_billing//var/log/jobs_daemon.log

Следующие строчки говорят о том, что в выбраном отчёте используются переменная Po_datu. Использование переменных допускается только в ручном выполнение отчёта.

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'
Путей решения задачи два:
  • Исправить параметры, указав верные
  • Удалить запланированную задачу

check_events_stack_compact_count.sh

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

Возникает при количестве событий больше 100000 в таблице events_stack_compact. В таблице events_stack_compact собираются события, связанные с отправкой команд на оборудование, но ещё не обработанные биллингом. Примеры состояния абонента и событий которые отправляются на оборудование после их обработки Вы можете посмотреть по [ссылке].
Большое количество событий в таблице events_stack_compact может быть вызвано возрошей нагрузкой на биллинг. Например массовая авторизация абонентов при перезагрузке оборудования. При этом имеется проблема производительности сервера биллинга, в следтвии которой события не могут быть оперативно обработаны. Наблюдать за количеством событий можно с помощю следующего запроса.

# sqlexec "select count(*) from events_stack_compact"

       COUNT
============
      110249

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

Если в стеке скопились команды отправки на маршрутизаторы Mikrotik, проверьте количество записей в address list:
/ip firewall address-list print count-only

Если количество несколько сотен тысяч, вероятно маршрутизатор интегрирован с Carbon Reductor для фильтрации по IP. В таком случае Вам нужно изменить способ инитеграции Микротика с Редуктором по статье "IP фильтрация MikroTik"

check_events_stack_count.sh

- check_events_stack_count.sh:  ERROR(1)                   [СБОЙ ]

    2017-03-07 07:32:18 Очень большое количество команд в event_stack

В таблице events_stack собираются события для отправки на оборудования. Большое количество событий связано как правило с проблемами доступа на оборудование (nas недоступен, сменились какие-то параметры вроде логина/пароля/ip, оборудование не принимает CoA и тд). Так же, возможно, что проблема в медленном ответе биллингу от НАСа, так как команды отправляются в заданное количество потоков (по-умолчанию, 1) и каждая следующая выполняется только после ответа от сервера. Убедитесь, что нагрузка процессора и канала на NAS в норме.
Узнать количество скопившихся событий можно выполнив запрос к БД

# sqlexec "select count(*) from events_stack"

       COUNT
============
      122837 
Если в стеке скопились команды отправки на маршрутизаторы Mikrotik, проверьте количество записей в address list:
/ip firewall address-list print count-only

Если количество несколько сотен тысяч, вероятно маршрутизатор интегрирован с Carbon Reductor для фильтрации по IP. В таком случае Вам нужно изменить способ инитеграции Микротика с Редуктором по статье "IP фильтрация MikroTik"

check_events_stack.py

Попробуйте оптимизировать отправу команд по статье: nas_event_daemon

Если в стеке скопились команды отправки на маршрутизаторы Mikrotik, проверьте количество записей в address list:
/ip firewall address-list print count-only

Если количество несколько сотен тысяч, вероятно маршрутизатор интегрирован с Carbon Reductor для фильтрации по IP. В таком случае Вам нужно изменить способ инитеграции Микротика с Редуктором по статье "IP фильтрация MikroTik"

check_error_oss.sh

Тест говорит о наличии ошибок синхронизации с сервисами IPTV:

- 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

Все возникшие проблемы можно увидеть в логе /app/asr_billing//var/log/oss.log.
Ошибки синхронизации могут возникнуть как со стороны Carbon Billing 5, так и со стороны сервиса телевидения. Необходимые действия для их устранения необходимо определить исходя из сообщений в логе.

Не найден NAS

2019-05-07 10:01:00,717 1690 nas_event_daemon/lifestream CRITICAL Невозможно получить пользователей, т.к. не найден NAS

В хранилище OSS схем (/app/asr_billing/var/oss/core) существует папка с OSS-схемой IPTV, при этом сам NAS не заведён в биллинге.
Для решения проблемы заведите NAS в ббиллинге или удалите OSS директорию.

Сервер ответил ошибкой

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'}

При обращении к API портала телевидения возникла ошибка из-за структуры запроса или данных переданных в запросе.
Как правило сервисы возвращают текст ошибки, в указанном примере это параметр message:

null value in column "password" violates not-null constraint

При изменении параметров учетной записе на портале телевидения, не был передан пароль - именно об этом говориться в сообщении об ошибке.
Исходя из полученной информации, можно попробовать решить проблему:

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

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

Эта проблема может возникнуть для некоторых IPTV, например Смотрёшкой.
Настройте услуги телевидения, создающие учетную запись, по статье "Настройка услуг IPTV" - у всех таких услуг должен быть указан префикс для создаваемых логинов.

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

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

Неизвестный абонент на Stalker

iptvportal_package.commands ERROR Неизвестный абонент с ip=10.0.0.3 на Stalker, приставка mac=fe:54:00:ac:5b:e0

В процессе синхронизации биллинг нашел на [Stalker] абонентов с неизвестными ему связкой IP-адресам и MAC-адреса.
Для решения, актуализируйте данные по приставкам в биллинге или удалите устнойство на портале.

check_error_django.sh

- check_error_django.sh:  ERROR(2)                         [СБОЙ ]

    WARNING Имеются ошибки в логе /var/log/django/error.log за последний час: 1

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

Ошибка web_api_get

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"]

Ошибка функции web_api_get говорит о том, что скорей всего проблема в выполняемых к биллингу API-запросах. Отладить это можно по статье API REST v2.0, раздел "Отладка"

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

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

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

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

select id, name ,create_login, prefix_login from usluga where create_login=1

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

2019-12-09 00:01:47,894 - django - commands - ERROR - Сервер вернул ошибку: requirement failed: Service ID must be non-empty

Проблема может возникнуть при интеграции Megogo, если:

  • В какой-то из услуг с пакетами ТВ не указан параметр "Строка с дополнительными параметрами по активации"
  • В какой-то из услуг с пакетами ТВ не указан параметр "Строка с дополнительными параметрами по деактивации"
  • Подключена услуга создающая учетную запись и в ней тоже нет одного из указанных параметров

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

Услуги ТВ пакетов без параметров активаци/деактивации
select u.id,u.name from usluga u join nas n on u.nas_id=n.id join nas_scheme ns on n.nas_scheme_id=ns.id and ns.object_type_id=2 where u.deleted=0 and (u.activate_string='' or u.deactivate_string='') and u.create_login=0
Услуги MEGOGO создающие учетную запись
select u.id,u.name from usluga u join nas n on u.nas_id=n.id join nas_scheme ns on n.nas_scheme_id=ns.id and ns.object_type_id=2 where u.create_login=1 and ns.name='Megogo'

У абонента не настроен email

2019-12-13 15:00:54,690 - django - commands - ERROR - У абонента не настроен email
2019-12-13 15:01:04,435 - django - commands - ERROR - У абонента не настроен email
2019-12-13 15:01:06,266 - django - commands - ERROR - У абонента не настроен email

Ошибка может возникнуть при интеграции с сервисами IPTV, если абоненту подключили услугу, но у него нет адреса почты - как правило такие сервисы регистрируют абонента по адресу почты и/или номеру телефона.
В частности, адрес почты обязателен при интеграции со Смотрёшкой.
Для решения проблемы выполните этот отчет в конструкторе и заполните у абонентов адреса почты, или отлючите у них услуги ТВ.

Абоненты с услугами ТВ, но без адреса почты
select distinct a.contract_number,a.name from abonents a join users_usluga uu on a.id=uu.abonent_id join usluga u on uu.usluga_id=u.id join nas n on u.nas_id=n.id join nas_scheme ns on n.nas_scheme_id=ns.id and ns.object_type_id=2 where u.deleted=0 and uu.deleted=0 and a.deleted=0 and (a.email='' or a.email is null)

check_error_voip_radius.sh:

- check_error_voip_radius.sh:  ERROR(2)                    [FAILED]

    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

Ошибка возникает если в логе RADIUS-сервера телефонии обнаружены ошибки обработки звонков.
Посмотреть найденные ошибки можно в логе из описания заявки, в приведенном выше примере это check_error_voip_radius.sh_28358.log
Для диагностики включите опцию "Включить DEBUG для Radius демона телефонии" в настройках биллинга и попробуйте совершить тестовый звонок.
Если звонок не проходит или в не появляется в расходе абонента по завершению, посмотре лог ошибок, возможные причины:

  • Выбрана неправильная OSS схема
  • Присылаемые NAS-сервером атрибуты не учтены в схеме
  • Так же вероятная причина - не все требуемые атрибуты схемы приходят от оборудования, например:
    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'

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

check_critical_pumper.sh

 - check_critical_pumper.sh

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

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

grep ERR /app/asr_billing/var/log/pumper_daemon.log

check_error_paysystems.sh

 - 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 

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

Просмотреть чек по которому произошла ошибка можно следующим образом:

  1. Найдите ошибку в логе службы обработки платежей:
    /app/asr_billing/mnt/log/paysystemsd.log
    
  2. Пример ошибки:
    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-)
    
  3. Откройте чек в вэб интерфейсе биллинга. Здесь 1111111d-0acf-4cfd-ac16-e0215b098cf2 – идентификатор действия со стороны атол-онлайн, #13858 – номер финансовой операции в биллинге. Укажите его в ссылке на акт (Абонент->Операции->Операция->иконка с принтером):
    http://<ip-биллинга>:8082/admin/FinanceOperations/print/13858/
    

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

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

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

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

check_error_worker.sh

- check_error_worker.sh:  ERROR(2)                         [СБОЙ ]

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

2019-02-22 08:38:32: pl5monitoring ALARM Имеются ошибки в логе worker за последний час: 57

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

grep ERR /app/asr_billing/var/log/worker.log

Ниже приведены кейсы решения некоторых возможных ошибок.
тут

account_traf - Не найден абонент для N записей (некорректная настройка Collector)

2019-02-22 08:38:02,458 - worker - account_traf - ERROR - Не найден абонент для 367 записей

Ошибка говорит о том, что обработчик абонентов не смог соотнести с каким-либо абонетом часть данных пришедших от коллектора аккаунтинга интернет-трафика
Это может произойти, если список с учетными записями и их IP-адресами на стороне коллектора устарел, вероятней всего по какой-то причине он не смог его синхронизировать (синхронизация проходит каждые 30 секунд).
В первую очередь стоит посмотреть лог синхронизатора:

# 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>

Список не обновился потому что в настройках коллектора указан неверный IP-адрес биллинга:

# grep api_ip /app/collector/cfg/config
collector['api_ip.widget']='inputbox "IP адрес для доступа к API биллинга" "IP адрес для доступа к API биллинга"'
collector['api_ip']='192.168.8.71'

Так как коллектор и биллинг находятся на одном физическом сервере, просто в разных контейнерах, в настройках следует указывать локальынй адрес биллинга 169.254.80.82. Приведите параметр к следуещему виду:

collector['api_ip']='169.254.80.82'

И перезапустите коллектор:

/app/collector/service restart

account_traf - Не найден абонент для N записей (аккаунтинг по неизвестным биллингу IP-адресам)

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

В случае если у Вас возникает ошибка аккаунтинга интернет-трафика, при этом в логе Вы видите записи "Bad traffic row", но нет ошибки синхронизации Collector, как в выше приведенном кейсе, вероятней всего проблема в том, что аккаунтинг (netflow) приходит по IP-адресам находящимся в Вашей сети, но не заведенным в биллинг.
Для решения проблемы ограничте набор интерфейсов с которых собирается netflow и разместите хосты вызывающие ошибку за другими интерфейсами BRAS. В случае если это сделать не возможно, например если Ваше оборудование не имеет такой настройки netflow-сенсора или это нарушит структуру сети, назначьте данные адреса учетным записям в биллинге, Вы можете использовать для этого одного абонента назвав его "Служебный трафик" или завести для каждого хоста своего абонента.
Получить список адресов вызывающих ошибку Вы можете следующей командой:

grep 'Bad traffic row ID' /app/asr_billing/var/log/worker.log | awk '{print $14}' | sed 's/IP=//g' | sort | uniq

Примерный результат:

10.24.240.1
172.16.5.148
172.31.10.1
172.31.10.2

account_voip - Проблема с межоператорским расчетом звонка VoipLog

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=ООО "Лучший провайдер" ]

Решение проблемы описано в статье "FAQ по ошибкам телефонии"

account_traf - Очень старая дата у трафика!

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

Проблема вызвана тем, что в потоке netflow дата и время трафика отличаются от установленных на биллинге. В сообщении об ошибки можно увидеть дату которая была в netflow, ID учетной записи и IP NAS-сервера.

Чтобы посмотреть по какой учетной записи возникла проблема в интерфейсе биллинга, подставьте ID из ошибки в адресную строку.
Пример. Допусти Вы подключаетесь к биллингу по IP 192.168.0.10, ссылка на учетную запись ID 4769 будет такой: http://192.168.0.10/admin/Users/4769

Настройка netflow-потоков подробно описана в статье. Для того, что бы решить проблему выполните:

  1. Установите утилиту tshark;
    yum -y install wireshark
  2. Запустите захват пакетов. В примере произведён захват по стандартному порту netflow 9996, на всех интерфейсах;
    tshark -pni any port 9996 -V -c 3 | grep -C 1 Timestamp

    Вывод будет выглядеть следующим образом:

    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

    Нас интересует значение поля Timestamp.

  3. Посмотрите дату и время установленные на биллинге:
    date
    

    Видим, что время отличается на два часа:

    date
    Срд Май 29 16:05:03 IRKT 2019
    
  4. Измените дату и время на NAS исходя из полученных данных.

usluga_abon_pay - У абонента услуга из другого тарифа!

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 из другого тарифа!

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

  1. Переключите абонента на временный тариф, потом верните нужный
  2. При необходимости сделайте абоненту перерасчет начиная с нужной даты

test_httpd.sh

- 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  ]
    Исправить проблему автоматически не удалось.

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

/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

По-умолчанию веб-сервер использует порты 8082 (http) и 8382 (https).
Убедитесь, что в конфигурационном файле /app/asr_billing/cfg/config заданы сделующие параметры:

app['apache.port']='8082'
app['apache.ip']='169.254.80.82'
app['apache.sslport']='8382'
app['apache.sslip']='169.254.83.82'

check_interbase_log.sh

Тест проверяет журнал ошибок работы СУБД:

- 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

В выводе теста написан путь до журнала обнаруженных ошибок: /app/asr_billing//var/log/firebird/firebird.log.catched.1559807284
Вы можете посмотреть его командой cat:

cat /app/asr_billing//var/log/firebird/firebird.log.catched.1559807284

Примре вывода:

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

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

  • В первую очередь следует проверить общий системный лог /var/log/messages на наличие ошибок дисковой подсистемы, если они есть и относятся к диску на котором расположена БД биллинга - это с высокой долей вероятности может вызвать ошибку работы СУБД.
  • Далее можно попробовать посмотреть содержимое файла /app/asr_billing//var/log/firebird/xinetd_169.254.30.50.log, это журнал службы управлеющий соединениями сервера баз данных, он необходим для экономии ресурсов системы и поддержания нагрузки на БД в разумных пределах.
    Если количество обращений к БД превышает допустимое, это вызовет отказ в соединении и в логе СУБД firebird.log появятся соответствующие записи.
    В таком случае попробуйте временно ограничить объём внешних соединений к серверу - обращения по API, доступ в панель управления абонентами и тарифами, количество одновременно выполняемых отчетов в конструкторе

test_free_space.sh

check_free_fs_space failed

- 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

Функция 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 Вы можете удалить или перенести данные на другой раздел.

check_db_space

- 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

Функция 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, их можно видеть в карточках абонентов на вкладке "Расход". Их можно удалять.

test_radius_nas_list.sh

- 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

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

Такое может произойти, в следующих случаях:

  • при обновлении, в случае если radius-сервер запустился раньше чем закончилась перезагрузка СУБД по той или иной причине
  • если Вы не указали ни OSS-схему ни Тип НАСа при добавлении (например, если добавляли NAS не мастером, или не удалили демонстрационные NAS).

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

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

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

Найти причину можно попробовать в логе RADIUS или его архивных копиях:

/app/asr_billing/var/log/radius/radius.log
/app/asr_billing/var/log/radius/radius.log-20191104.gz

Первый файл - актуальный лог
Второй - архивны, в нем информация от момета предыдущей архивации до 04 ноября 2019 года.

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

test_radius.py

Для отладки теста и подробного разбора проблемы можно выполнить его в режиме повышенного логирования

chroot /app/asr_billing python /usr/local/angel/test_radius.py --debug

test_daemons.sh

Тест срабатывает если одна из служб контейнера не работает и пытается исправить ситуацию автоматический (перезапуском службы). В любом случае будет создана автоматическая заявка. Пример текста ошибки:

- 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

При запуске все службы (=демоны) asr_billing создают маркерный файл в директории /var/lock/subsys/, так тест понимает какие службы нужно проверять (это нужно на случай если какие-то из них отключены в конфигурационном файле контейнера).
По каждой службе из полученного списка тест ищет pid-файл и проверяет что процесс запущен. В результате проверки он может вернуть либо состояние "ОК", что значит что проверка пройдена успешно, либо одну из следующимх ошибок:

  • Pidfile not found - тест не нашел пути pid-файл для процесса
  • No pidfile - по найденому пути либо не pid-файл (например, папка), либо он удален
  • No pid - в PID-файле не оказалось ID процесса (например, если файл оказался пустым)
  • No proc entry - pid-файл найден, но процесса с указанным ID не оказалось.

Pidfile not found

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

Например, перезапустим службу аккаунтинга трафика:

# /etc/init.d/radiusd_traf restart
Stopping radiusd_traf:                                     [FAILED]
Starting radiusd_traf:                                     [  OK  ]

Ошибка произошла про причине того, что процесс уже запущен, но PID-файл почему-то не создан:

# 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

Находим должное насположение PID-файла (подставьте путь до init файла службы) и убеждаемся что его действительно нет и ошибка не в самом тесте:

# 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

Для решения проблемы Вы можете послать сигнал TERM командой kill -15 PID_процесса и заново его запустить.

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

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

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

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

/app/asr_billing/cfg/config

declare -A django
django['username']='root'
django['password']='servicemode'

FATAL Billing Error copy metadata

Заявка может возникнуть при обновлении базы данных и говорит о том, что в процессе возникли какие-либо ошибки. Обновление БД может происходить в следующих случаях:

Скрипт обновления БД пишет лог в файл /app/asr_billing/var/log/ib_upgrade.sh.log
Так же определить наличие проблемы можно сравнив версию БД и версию биллинга. При нормальной работе версии должны совпадать.

  • Просмотр версии биллинга:
    cat /app/Billing.version
    
  • Просмотр версии БД:
    sqlexec "set list; select CONST_VALUE from vpn_const where const_id = 7"
    

    Если Вы столкнулись с этой ошибкой, попробуйте еще раз запустить update_hook.sh с ключем --force.

    /app/asr_billing/service stop
    chroot /app/asr_billing
    update_hook.sh --force
    exit
    /app/asr_billing/service start
    

    Или повторно запустить обновление биллинга с ключем --force.

    carbon_update update --force
    
    update_hook.sh можно запускать только на остановленном биллинге

    В случае если повторное обновление не исправило проблему (это можно проверить по логу, поискав слово "error"), обратитесь в техподдержку.

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

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

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

Сообщения в логе:

__main__.TimeoutError: Timeout
[Errno 113] No route to host
[Errno 113] No route to host

Проверьте что:

  • NAS-сервер включен
  • NAS-сервер доступепен биллингу по сети
  • На NAS-сервере не заблокирован доступ с биллинга фаерволом

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

Сообщения в логе:

[Errno 111] Connection refused
[Errno 111] Connection refused
[Errno 111] Connection refused

Проверьте следующее:

  • В биллинге указан правильный порт управления NAS-сервером
  • На NAS-сервере обращения с биллинга не блокируются фаерволом
  • На NAS-сервере включен протокол через который описано получение данных в session скрипте (в стандартных схемах это API для Mikrotik, ssh/telnet для Cisco и RedBack)

В функции users_from_nas скрипта session есть ошибка, в результате которой она завершается некорректно

Пример сообщений в логе:

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

В указанном скрипте /var/oss/core/Mikrotik-Simple/bin/session есть ошибка синтаксиса.
В примере некорректно реализовано ветвление (if [ nnn ]; then; действие; fi), не дописан оператор закрывающий "if", и bash дойдя до конца функции users_from_nas говорит об ошибке.

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

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

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

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

Это могло произойти в старых версиях биллинга и при попытке закрыть период произойдет ошибка нарушения связей в базе данных.
Получить список не удаленных абонентов чьи папки в корзине можно через конструктор отчетов:

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

Тесты asr_cabinet

check_cabinet_httpd_netstat.sh

Код ошибки:

- check_cabinet_httpd_netstat.sh:  ERROR(2)                [СБОЙ ]

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

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

Путь к файлу httpd.conf:

/app/asr_cabinet/etc/httpd/conf/httpd.conf

Для исправления ошибки необходимо восстановить стандартный конфигурационный файл httpd.conf , для этого нужно:

  1. Зайти в chroot asr_cabinet:
    chroot /app/asr_cabinet/
    
  2. Сохраняем текущие конфигурационные файлы:
    echo yes | mv /cfg/config /root/
    echo yes | mv /cfg/etc/httpd/conf/httpd.conf /root/
    
  3. Копируем стандартный конфигурационный файл:
    cp -p /skelet/cfg/config /cfg/
    
  4. Выходим из chroot asr_cabinet и перезапускаем его:
    exit
    /app/asr_cabinet/service restart
    

Тесты collector

check_critical_traf_reporter.sh

- 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

Тест определяет наличине ошибок в логе traf_reporter - эта служба отправляет в биллинг данные по объёмам абонентского трафика. Данные отправляются на radiusd_traf в биллинге. Подобные ошибки могу возникать, если с RADIUS-сервер трафика в биллинге отключен или его работа была прервана по какой-либо причине. Отсутствие связи можно увидеть по логу traf-reporter:

# 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.

Обратить внимание следует на сообшение "RADIUS server does not reply"
Для решения проблемы попробуйте перезапустить RADIUS:

chroot /app/asr_billing/ service radiusd_traf restart

Возможные ответы:

Starting radiusd_traf: [ OK ]

Корректный ответ, сервис запустился. На всякий случай проверьте что трафик стал отсылаться в биллинг по логу репортера (новые сообщения должны быть только с тегом INFO:

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

Stopping radiusd_traf: [FAILED]

Подобный ответ говорит о проблемах с запуском радиус-сервера. Попробуйте найти решение в документации или обратитесь в техподдержку.

radius_traf disabled in /cfg/config

Данный ответ говорит о том, что сервер сбора трафика отключен в настройках биллинга. Включите его в биллинге в меню Настройки (в файле)

check_bstat_check_raw_stat.sh

 Отсутствует сырая статистика

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

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

check_bstat_many_raw.sh

- 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

Тест проверяет количество файлов сырой статистики bstatd в директории:

/app/collector/var/stat/raw/

При превышении лимита создаётся автоматическая заявка. В большинстве случаев достаточно перезапустить сервис bstatd командой:

chroot /app/collector/ service bstatd restart

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

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

Определить, в этом проблема или нет, и решить её можно так:

  1. Посмотрите, есть ли файлы сырой статистики для nfsen:
    Команда
    find /app/collector/var/stat/raw/ -iname 'rawnetflow*' | wc -l
    Пример вывода когда есть файлы статистики
    194
  2. Если вывод будет больше ноля, как в примере выше, рекомендуем отключить опцию и удалить собранную статистику.
  3. Отключить можно в настройках служб сбора статистики, на вкладке "Настойки сохранения сырой статистики", опция "Сохранять сырую статистику"
  4. Удалить уже собранную статистику можно такой командой:
    find /app/collector/var/stat/raw/ -iname 'rawnetflow*' -delete

check_disk_space_stat.sh

- 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

Ошибка говорит о том, что у Вас недостаточно места для хранения детальной статистики.
Для решения проблемы удалите часть архива или подключите более объемный диск по статье "Добавление диска под статистику"

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

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

Тесты xge

check_xge_free_class.sh

check_xge_free_class.sh:  ERROR(1)                       [СБОЙ]

Шейпер в XGE (Softrouter) является динамическим. Занятые классы определяется по наличию файлов в папке /app/xge/var/lib/xge_shapers/lock, свободные в /app/xge/var/lib/xge_shapers/free.
В ситуации, когда по той или иной причине не сработала синхронизация шейперов, может возникнуть ошибка скрипта check_xge_free_class.sh. Подобная проблема наиболее характерна при подключении абонентов через vpn (pptp, pppoe)
В данном случае следует посмотреть количество свободных и занятых классов:

ls /app/xge/var/lib/xge_shapers/lock/ | wc -l
7000
ls /app/xge/var/lib/xge_shapers/free | wc -l
0

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

chroot /app/xge fix_locked_shapers.sh

Если после выполнения скрипта абоненты будут жаловаться на наличие проблем со скоростью, перезапустите XGE

/app/xge/service restart
Файлы классов создаются при первой установке абоненту тарифа ограничением скорости. При свежей установке, создайте такой тариф и назначьте его абоненту чтобы не возникала ошибка теста. В случае, если они не создались после установки тарифа, выполните следующую команду:
for shaperid in `seq 2000 8998`; do touch /app/xge/var/lib/xge_shapers/free/$shaperid; done

check_vm.sh

Сообщение:

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

Имя виртуальной машины может изменяться, в зависимости от оборудования.

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

check_xge_httpd_redirect_netstat.sh

Сообщение:

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

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

 httpd['internal_ip']='169.254.80.90' 

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

Общие ошибки продуктов на платформе Carbon PL5

ALARM Ошибка автоматической резервной копии!

Полный текст ошибки

Ошибка автоматического бекапа! Информация в логе: /app/base/var/log/cron_backup.sh.log

В нём сообщается, где можно уточнить в чем заключается проблема выгрузки.
Как правило, ошибки возникают на стороне FTP, как то: недостаток свободного места, недоступность сервера, превышение квот, о чем можно подробней посмотреть в логе FTP-сервера.

backup: [СБОЙ ]

Ошибка говорит о том что резервная копия не была создана.
Убедитесь, что на разделе /mnt/backup достаточно свободного места

# df -h /mnt/backup/
Файловая система      Разм  Исп  Дост  Исп% смонтирована на
/dev/sdc3              32G  6,0G   24G  21% /mnt/backup

Если места достаточно, найдите в логе /app/base/var/log/cron_backup.sh.log строку, содержашую "backup: [СБОЙ]", например:

# /app/collector/service backup: [СБОЙ ]

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

backup_upload: [СБОЙ ]

Найдите в логе /app/base/var/log/cron_backup.sh.log строку, содержашую "backup_upload: [СБОЙ]", например:

# /app/collector/service backup_upload: [СБОЙ ]

Перед ней будет лог выполнения резервного копирования.

FTP недоступен, curl: (7) couldn't connect to host

Наиболее респространенной причиной ошибки является недоступность ФТП-сервера:

/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

В данном случае, следует проверить что FTP-сервер доступен и работает.

Далее приведёны примеры наиболее часто встречающихся проблем. Полный список кодов ошибок с описанием можно посмотреть в соответствующей статье на Википедии.

Отсутствует свободное место на фтп-сервере, curl: (25) Failed FTP upload: 452

* 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

Ошибка 452 говорит о том, что закончилось свободное место на фтп-сервере.

Логин или пароль не подходят, curl: (67) Access denied: 530

Как видно из лога, ошибка с логином

* 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

Нет прав на создание директорий, curl: (9) Failed to MKD dir: 550

Убедитесь, что корректно настроили права пользователя в настройках ftp, а так же права файловой системы.

< 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

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

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

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

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

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

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

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

1. Проверям какой раздел заполнен:

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

Видно, что заполнен раздел /dev/sda5 с логами.

/dev/sda5        53G 47,2G  5.8G  89% /mnt/var

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

du -sh /mnt/log/*

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

В данном примере рассмотрено заполение раздела с логами. Удалить старые логи можно по [статье].

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

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

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

В тексте сообщения об ошибке будет описано при обновлени какого контейнера произошла ошибка, например:

	Обновление #5 [20] от 2019-03-28 07:30:42:
 CRITICAL - carbon_update: скрипт обновления завершился с ошибкой 12
 ----
 app: base

"Номер" ошибки - это код возврата какого-либо из скриптов обновления запускаемых при обновлении, инициируемых основным скриптом carbon_update.
Если ошибка возникнет повторно, описание заявки обновится, будет указано время когда она последний раз возникала.
В зависимости от способа запуска обновления (автообновление изи вручную из веб-интерфейса), полную информацию об ошибке можно найти в файлах:

  • Автообновление: /var/log/carbon_update_autoupdate.log (лог обновления) или /var/log/carbon_update_download.log (лог загрузки актуального дистрибутива)
  • Вручную: /app/base/var/log/update.log
    Ошибку можно попробовать найти утилитой grep, например:
    grep 'скрипт обновления завершился с ошибкой' /var/log/carbon_update_download.log --color -n

    grep с флагом "-n*" первым полепи пишет номер строки в файле где обнаружена ошибка:

    1024648:2019-03-28 10:30:04: CRITICAL - carbon_update: скрипт обновления завершился с ошибкой 12

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

скрипт обновления завершился с ошибкой 12

+ /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]

Согласно логу, скрипт не смог загрузить обновление с сервера, соединение было сброшено самим сервером обновлений.
Вероятные причины:

  • В момент когда Ваша установка пыталась запустить обновление, присходил выпуск новой версии и старая стала недоступна для загрузки
  • В момент когда Ваша установка пыталась запустить обновление, на сервере начались технические работы

ALARM Повышенная нагрузка на некоторые ядра

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

Тест реагирует на проблему некорректого распределения обработки прерываний по ядрам процессора, вероятней всего на Вашем сервере этим занимается только одно ядро.
Диагностика и решение подробно описаны в документации по Carbon Reductor X, так же построенного на платформе Carbon: Потери на сетевых картах, задержки в обработке и как с ними бороться
Быстро решить проблему можно, попытавшись запустить утилиту автоматического рапределения прерываний, вызываемых обработкой сетевого трафика по всем используемым сетевым интерфейсам, например:

rss-ladder eth0

Если это исправит проблему, не забудьте добавить автоматический вызов настройки в хук XGE

Проблема актуальна для продуктов Reductor, XGE и Softrouter. Если она произошла на Billing или Billing_Slave, обязательно обратитесь в техподдержку

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

На сервере работает система мониторинга, каждые 10 минут она запускает набор автоматических тестов, если в работе подсистем продукта (Биллинга, маршрутизатора XGE, Редуктора и тд) обнаружены ошибки - отправляет сообщение администратору на почту и создаёт заявку в портале HelpDesk.

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

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

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

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

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

- 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

Тест check_dns.sh есть в каждом контейнере платформы Carbon. Для контейнера base используются DNS-сервера host-системы, он выполняет команду "nslookup -timeout=X ya.ru", "X" - количество секунд ожидания ответа, задаётся в конфигурационном файле контейнера (например, /app/base/cfg/config)
Возможные причины возникновения проблемы:

  • В файле /etc/resolv.conf контейнера не указаны или указаны неверные DNS-сервера.
  • Заданные DNS-сервера не отвечают
  • Заданные DNS-сервера отвечают слишком долго (дольше заданного timeout)

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

Укажите работающие и доступные для биллинга DNS-сервера по статье "Настройки сети" и перезапустите все :

/etc/init.d/apps restart

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

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

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

Выполните вручную команду:

nslookup timeout=1 ya.ru

Если DNS-сервер не ответит вовремя, увеличьте timeout на еденицу (timeout=2) и так далее пока не найдете оптимальное значение.
Когда удастся определить рабочий timeout, выполните следуюищй скрипт, где new_timeout задаёте равным нужному значению:

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

Скрипт из примера установит timeout=2 в конфигурационных файлах всех контейнеров.

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

Описание диагностики находится в соответствующей статье.АТОЛ Онлайн

Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.