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

На платформе 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.

check_free_memory.sh

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

    ALARM Мало свободной памяти
    
    Подробная информация записана в файл /app/base/var/log/check_free_memory.log
    10

Тест пишет об ошибке когда на сервере осталось менее 20% свободной ОЗУ. SWAP при этом не учитывается.
Последняя строка в выводе ("10" в примере выше) - это процент свободной ОЗУ.

Диагностику можно посмотреть в логе:

/app/base/var/log/check_free_memory.log

Там Вы наёдете вывод двух команд, выполненных при наличии ошибки:

• ps axSk-rss -F - список запущенных процессов, отсортированных по объёму занимаемой памяти
• pstree -upal - список процессов в виде дерева

Как именно работает тест

Разберём на примере вывода команды free:

free -m | grep -E 'total|^Mem'

             total       used       free     shared    buffers     cached
Mem:          5707       5324        382         25        681       1412

Что делает тест:

1. Получает количество памяти: в примере это total = 5707
2. Вычисляет свободную папять: складывает free, buffers и cached, то есть 384+681+1412, получается 2477
3. Получает свободную память в процентах: в примере выше - 2477*100/5707, получится 43%
4. Если свободной памяти меньше 20%, то:
   • Пишет диагностику в лог check_free_memory.log
   • В логе системы монторинга сохраняется информация что тест завершился с ошибкой
5. Если проблема повторится 5 раз за час, то создаётся автоматическая заявка.

Как понять на какие процессы ушла память?

Причины могут быть разными и зависить от конкретного процесса.

Методика определения причины:

1. Убедитесь, что Ваш сервер соответствует системным требованиям:
   • Количество ОЗУ достаточно
   • Скорость работы ОЗУ сотвтетствует требованиям
   • Процессор поддерживает работу с памятью на требуемой частоте
2. Если с требованиями всё в порядке, обратитесь к логу check_free_memory.log, типичная ситуация когда 1-2 процесса требуют больше всего памяти
   • Посмотрите что это за процессы и попробуйте найти в Google информацию о проблемах с назвапнием процесса и высоким потреблением памяти, например "mysqld high ram"

Что ещё может оказаться полезным:

• Убедитесь что занято не более 500Мб SWAP:
  Команда

  free -m | grep -E 'total|Swap'

  Вывод

               total       used       free     shared    buffers     cached
  Swap:         5839         15       5824
  

  
  

  • Если занято 300-500Мб, то это нормальная ситуация - некоторые системные программы и ядро могут использовать SWAP даже если есть свободная ОЗУ.
  • Если занять более 500Мб - скорей всего ОЗУ системе уже недостаточно и нжуно анализировать на что она ушла, так как вместо части ОЗУ используется болеемедленный диск
    
    
• Посмотрите потребление памяти конкретного процесса по его PID. Используя пример с тем же mysql:
  • Узнаем PID
    Команда

    ps aux | grep -E 'PID|/usr/libexec/mysqld.*port=3307'  | grep -v grep

    Вывод

    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    27        5064  0.0  0.5 377340 31624 ?        Sl   Jun05   2:43 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql ... --socket=/var/lib/mysql/mysql.sock --port=3307
    

  • Посмотрим, занимает ли процесс место только в памяти, или ещё в SWAP
    Команда

    cat /proc/5064/status | grep -E 'VmSize|VmSwap'

    Вывод

    VmSize:	  377340 kB
    VmSwap:	       0 kB

Пример выше делали на виртуальной машине где нет какой-либо проблемы, поэтому SWAP не занят. В действитеильности, документацию писали по кейсу где MySQL локального сайта заняла 44% ОЗУ и ещё 2Гб в SWAP, что явно говорило о проблема где-то в этой части системы.

Тесты 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 директорию.
Если удаляете OSS директорию NAS IPTV в каталоге /app/asr_billing/var/oss/core/, обязательно, после этого требуется выполнить перезапуск службы nas_event_daemon.

chroot /app/asr_billing/ service nas_event_daemon restart 

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

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-адреса.
Для решения, актуализируйте данные по приставкам в биллинге или удалите устройство на портале.

Специфическая ошибка Смотрёшки

2020-04-13 12:01:03,366 - worker - lifestream_sync - ERROR - Произошла ошибка
2020-04-13 12:01:03,366 31543 nas_event_daemon/lifestream ERROR Произошла ошибка

В данном случае нужно смотреть полный лог Смотрёшки и анализировать конкретную ошибку.
Лог находится по пути /app/asr_billing/var/log/nas_event_daemon/lifestream.log

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

tail -f /app/asr_billing/var/log/nas_event_daemon/lifestream.log

И перезапустите сервер синхронизации в другом:

chroot /app/asr_billing/ service oss restart

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

   result.request.method=GET
   result.request.url=https://best_isp.proxy.lfstrm.tv/v2/accounts?page_size=50000&page=0
   result.request.body=None 

   result.status_code=500
   result.content={"error": "argument of type 'NoneType' is not iterable"}

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

Учетки с email "user@example.com" нет на портале, создадим

2020-07-04 00:03:35,093 - worker - lifestream_sync - ERROR - Учетки с email "user@example.com" нет на портале, создадим

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

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

tail -n 100 /app/asr_billing/var/log/nas_event_daemon/lifestream.log

В логе должна быть более детальная информация почему произошла ошибка, Например:

2020-07-06 08:17:07,106 - worker - lifestream_sync - ERROR - Учетки с email "user@example.com"" нет на портале, создадим
2020-07-06 08:17:07,106 - worker - v1 - INFO - Получаем учетку из биллинга
2020-07-06 08:17:07,106 - worker - v1 - INFO - Подходящие учетки не найдены - ищем любые учетки привязанные к насу 1114
2020-07-06 08:17:07,114 - worker - v1 - INFO - Получили учетку из биллинга user_id=user100007
2020-07-06 08:17:07,114 - worker - commands - INFO - Command — get_portal_user - login=user100007
2020-07-06 08:17:07,277 - worker - commands - INFO - Запрос не принят сервером: 
Результат отправки запроса: 
   result.request.method=POST 
   result.request.url=https://bestisp.proxy.lfstrm.tv/v2/accounts 
   result.request.body={"username": "user100007", "password": "123456", "email": "user@example.com""} 
   result.status_code=400
   result.content={"error": "HTTP 400: login: services.error.login.accounts.invalid_login"}

В логе видно, что Lifestream не принял запрос от биллинга с ошибкой 400 и коментарием "login: services.error.login.accounts.invalid_login".
Выше видно какие параметры отправлялись к сервису.

Подробную информацию по ошибке необходимо запросить у сервиса.

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

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)

Сервис IPTV недоступен (ERROR - Произошла ошибка)

В логе на котрый ссылается тест написано что просто произошла ошибка:

2019-12-16 05:39:40,098 - worker - lifestream_sync - ERROR - Произошла ошибка

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

2019-12-16 05:29:39,911 - worker - lifestream_sync - ERROR - Произошла ошибка
Traceback (most recent call last):
  File "/mnt/var/oss/core/LifeStream/init.d/lifestream_sync", line 162, in <module>
    iptv_portal.compare_users()
  File "/mnt/var/oss/core/LifeStream/init.d/lifestream_sync", line 53, in compare_users
    self.logger.info(u'Пользователей на портале: {0}'.format(len(self.remote_abonent_list['accounts'])))
  File "/mnt/var/oss/core/LifeStream/lib/lifestream_package/commands.py", line 177, in remote_abonent_list
    self._remote_abonent_list = self.get_remote_abonent_list()
  File "/mnt/var/oss/core/LifeStream/lib/lifestream_package/commands.py", line 168, in get_remote_abonent_list
    urlpath='accounts?page_size={0}&page={1}'.format(50000, 0)
  File "/mnt/var/oss/core/LifeStream/lib/lifestream_package/commands.py", line 92, in response_wrapper
--
    return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 468, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python2.7/site-packages/raven/breadcrumbs.py", line 297, in send
    resp = real_send(self, request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 576, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 437, in send
    raise ConnectionError(e, request=request)
ConnectionError: HTTPSConnectionPool(host='https', port=443): Max retries exceeded with url: //bestisp.proxy.lfstrm.tv/v2/accounts?page_size=50000&page=0 (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7f8bee64a750>: Failed to establish a new connection: [Errno -2] Name or service not known',))

По тексту ошибки видно, что сервис телевидения недоступен, это можно понять по фразам "ConnectionError" и "Max retries exceeded with url".
Возможные причины:

• Проблема с DNS: внутри контейнера биллинга он указан неправильно или не указан. Для этого проверьте домен Вашего порта командой nslookup, например:

  chroot /app/asr_billing/ nslookup bestisp.proxy.lfstrm.tv

  Указать правильный DNS можно по статье "Настройки сети"

• Проблема с DNS: либо сервер возвращате неверный IP. Для решения проблемы обратитесь к администратору используемого DNS-сервера или используйте другой сервер.
• Иные сетевые проблемы: например, если с DNS все в порядке, но сервис недоступен по сети, не вингуется, не отвечает на запросы и тд. Решение этой проблемы ни чем не отличается от решения любой другйо сетевой проблемы и не относится к настройке биллинга и данной документации.

Не удалось синхронизировать тех. группу: Ошибка при проверке номера

2020-01-15 08:08:14,658 - django - authBackend - CRITICAL - Не удалось синхронизировать тех. группу: Ошибка при проверке номера: (0) Could not interpret numbers after plus-sign.

Ошибка говорит о том, что в настройках пользователей биллинга некорректно указан номер смс для оповещения. Номер телефона должен удовлетворять формату E.164:+79123456789 или 89123456789.

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 для оповещений".

Для решение проблемы требуется:
1. Проверить наличие E-Mail чека по умолчанию в настройках "АТОЛ Онлайн"
2. Проверить в /app/asr_fiscal/cfg/config опцию atol_online 'cabinet' на наличие параметра 'default_email'
Например:

atol_online['cabinet']='enable login passwd kkt_group inn mesto email sno vat'

Исправить на:

atol_online['cabinet']='enable default_email login passwd kkt_group inn mesto email sno vat'

Для ускорения применения настроек требуется выполнить следующую операцию:

chroot /app/asr_billing/ python /usr/local/bin/get_fiscal_config.py

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_traf - Неизвестный трафик (NAS не опознал трафик)

2020-04-27 03:35:19,771 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 04:05:12,614 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 04:35:22,370 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 05:05:11,747 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 05:35:21,180 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 06:05:11,770 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 06:35:11,355 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 07:05:14,855 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 07:35:08,466 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)

В данном случае NAS не смог распознать трафик и прислал трафик с IP адресом 0.0.0.0 Для начала убедимся, что действительно в collector приходит netflow поток с неверным IP адресом в содержимым:

1. Включим повышенное логирование в контейнере collector:

   mkdir -p /app/collector/cfg/etc/netflow_collector/
   cp -p /app/collector/etc/netflow_collector/nf_collector.conf /app/collector/cfg/etc/netflow_collector/nf_collector.conf
   sed 's|LOG_LEVEL=0|LOG_LEVEL=3|' -i /app/collector/cfg/etc/netflow_collector/nf_collector.conf
   /app/collector/service restart
   

2. Подождём 5 минут, чтобы накопились данные в логе.
3. Проверим какие IP адреса не смог распознать collector. Мы видим в первой записи адрес 0.0.0.0

   grep 'New entry for ip' /app/collector/var/log/nf_collector.log | awk '{print $12}' | sort -u | head -n 3
   0.0.0.0
   10.0.0.20
   10.100.20.20
   

4. Выключим расширенное логирование collector

   rm -f /app/collector/cfg/etc/netflow_collector/nf_collector.conf
   /app/collector/service restart
   

Теперь мы убедились, что в netflow потоке приходит IP адрес 0.0.0.0 Для исправления проблемы вам нужно настроить поток netflow на NAS, для этого обратитесь к официальной документации по своему NAS.

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_voip - Вы используете deprecated настройки для парсера CDR / Для OSS схемы 250002 не настроен обработчик CDR

2020-04-20 08:44:41,544 - worker - account_voip - WARNING - Вы используете deprecated настройки для парсера CDR.
2020-04-20 08:44:41,544 - worker - account_voip - ERROR - Для OSS схемы 250002 не настроен обработчик CDR

Данная ошибка проявляется, когда в биллинге создан VOIP NAS, но не инициализирован и отсутствуют правила обработки CDR-файлов. Для решения проблемы, необходимо выполнить настройку по инструкции: "Настройка парсинга CDR":

1. Инициалихируйте NAS
2. Добавьте настройки CDR-парсера из статьи

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. При необходимости сделайте абоненту перерасчет начиная с нужной даты

csv_loading - Файл конфигурации пустой

2020-07-08 06:04:08,979 - worker - csv_loading - ERROR - Файл конфигурации /cfg/autocsv/test.autocsv пустой
2020-07-08 06:04:40,464 - worker - csv_loading - ERROR - Файл конфигурации /cfg/autocsv/test.autocsv пустой
2020-07-08 06:04:41,633 - worker - csv_loading - ERROR - Файл конфигурации /cfg/autocsv/test.autocsv пустой
2020-07-08 06:04:42,432 - worker - csv_loading - ERROR - Файл конфигурации /cfg/autocsv/test.autocsv пустой
2020-07-08 06:05:10,670 - worker - csv_loading - ERROR - Файл конфигурации /cfg/autocsv/test.autocsv пустой

В каталоге с настройками для выгрузки платежей из CSV находистся пустой файл настройки. Видимо вы создали файл для настроек выгрузки платежей и не заполнили его. Пустой файл нужно удалить:

1. Посмотрим содержимое каталога:

   ls -l /app/asr_billing/cfg/autocsv/
   

   Видим два файла с настройками, test.autocsv - пустой.

   -rw-rw-rw- 1 root root   0 Июн 16 11:28 test.autocsv
   -rwxrwxrwx 1 root root 769 Июн 29  1976 default.autocsv
   

2. Удалмите пустой файл:

   rm -f /app/asr_billing/cfg/autocsv/test.autocsv 
   

Ошибка обработки отправки отложенных комманд ConnectionTimeout

2020-06-26 10:09:05,928 - worker - common - CRITICAL - Ошибка обработки отправки отложенных комманд ConnectionTimeout caused by - ReadTimeoutError(HTTPConnectionPool(host='169.254.92.94', port=9200): Read timed out. (read timeout=30))

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

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

- 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

Тест test_free_space.sh проверяет что на разделе /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

check_billing_radius_acc_netstat.sh

Для решения проблемы попробуйте перезапустить обработчик аккаунтинга RADIUS:

chroot /app/asr_billing/ service radiusd_acc restart

Если проблема сохраняется, обратитесь в техподдержку.

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

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

• Автоматически, [обновлении биллинга],
• Вручную, при запуске update_hook.sh во время переноса биллинга на новый сервер
• Вручную, при запуске update_hook.sh при восстановлении биллинга из резервной копии

Скрипт обновления БД пишет лог в файл /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
   

Тесты asr_fiscal

check_fiscal_httpd_netstat.sh

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

    ALARM Недоступен веб-сервер платёжных систем
    Для решения проблемы воспользуйтесь статьёй:
    http://docs.carbonsoft.ru/51019784#Системамониторинга-checkfiscalhttpdnetstat.sh
    Stopping httpd:                                        [FAILED]
    Starting httpd: (98)Address already in use: make_sock: could not bind to address 169.254.14.44:1444
    no listening sockets available, shutting down
    Unable to open logs

Тест проверяет, что HTTP-сервер платёжных систем работает на порту указанному в настройках, "Внешний порт платежных систем"

Для этого он берёт из настроек /app/asr_fiscal/cfg/config переменные apache.ip и apache.port и командой netstat проверяет что http-сервер запущен на указанных адресе и порту.

Address already in use: make_sock: could not bind to address 169.254.14.44:1444

Две наиболее вероятных причины когда можно получить такую ошибку:

• На порту HTTP-сервера уже запущенно какое-то приложение, может другой сервер из хост-системы или другого контейнера
• При загрузке некорректно собрался контейнер asr_fiscal и информационнная ФС /proc не смонтировалась - поэтому netstat не может посмотреть информацию по занятым портам

Проблема с /proc

Проверьте, подключен ли /proc:

mount | grep fiscal/proc

none on /app/asr_fiscal/proc type proc (rw)

Такой вывод говорит о том, что подключен. Если вывод другой или его вообще не было - ещё раз убедитесь что ФС не смонтирована:

ls -l /app/asr_fiscal/proc/

total 0

В папке /proc пусто, а должно быть большое количество папок и файлов.

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

/app/asr_fiscal/service stop && /app/asr_fiscal/service destroy && /app/asr_fiscal/service build && /app/asr_fiscal/service start

Порт занят кем-то другим

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

Если это окажется какая-то программа из состава Carbon Billing 5, укажите для неё другой порт и перезапустите сервер.
Если что-то не относящееся к продукту - лучше перенесите на другой сервер, но можно и просто указать другой порт.

netstat -nlp | grep 1444

pid=$(netstat -nlp | grep 1444 | awk '$7{print $7}' | cut -d'/' -f 1) && echo $pid

ls -l /proc/$pid/exe

ls -l /proc/$pid/fd/

ps auxf | grep -E 'START|8673.*' -C2

check_fiscal_httpd_ssl_netstat.sh

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

    ALARM Недоступен веб-сервер (ssl) платёжных систем
    Для решения проблемы воспользуйтесь статьёй:
    http://docs.carbonsoft.ru/51019784#Системамониторинга-checkfiscalhttpdsslnetstat.sh
    Stopping httpd:                                        [FAILED]
    Starting httpd: (98)Address already in use: make_sock: could not bind to address 169.254.14.44:1444
    no listening sockets available, shutting down
    Unable to open logs

Тест проверяет, что HTTPS-сервер платёжных систем работает на порту указанному в настройках, "Защищенный внешний порт платежных систем, без необходимости передачи сертификата"

Причины и методы решения проблем аналогичны инструкции теста check_fiscal_httpd_netstat.sh (выше).

Тесты collector

check_nf_collector_listen.sh

  Netflow Collector не запущен
 Останавливается Netflow collector: [СБОЙ ]
 nf_collector disabled in /cfg/config
  is stopped
 
  /usr/local/angel/check_nf_collector_listen.sh ERROR(2)
  Create_date: 2020-05-16 22:40:10

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

Если служба сбора статистики выключена, биллинг не сможет считать объём трафика.

Как исправить проблему

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

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

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

Корректный ответ, сервис запустился. На всякий случай проверьте что трафик стал отсылаться в биллинг по логу репортера (новые сообщения должны быть только с тегом 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

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

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

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. Отключить можно в настройках служб сбора статистики, на вкладке "Настhойки сохранения сырой статистики", опция "Сохранять сырую статистику"
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ТБ, диска меньшего объёма скорей всего надолго не хватит.

Если служба сбора статистики выключена, биллинг не сможет считать объём трафика. После очистки места на диске включите службу по статье: nf_collector.

Как исправить проблему

1. Освободите место, чем больше - тем лучше, свободным должно быть хотя бы 200Гб
2. После очистки места на диске включите службу:
   1. В файле /app/collector/cfg/config поменяйте значение опции app['nf_collector.enabled'] на 1, должно получиться так:
      Команда

      grep nf_collector\.enabled /app/collector/cfg/config | grep -v widget

      Вывод

      app['nf_collector.enabled']='1'

   2. И перезапустите коллектор трафика:
      Команда

      chroot /app/collector/ service nf_collector restart
      

      Вывод

      Stopping Netflow collector:                                [FAILED]
      Starting Netflow collector:                                [  OK  ]
      

check_error_bstatd.sh

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

    ALARM обнаружены ошибки в работе bstatd
    За последний час ERROR: 5997
    Лог службы /app/collector/var/log/bstatd.log
    Подробности в логе /app/collector/var/monitoring_dump/check_error_bstad.sh_8284.log 

Ошибка появляется в случае если обработчик детальной статистики bstat не справился с одним из файлов в /app/collector/var/stat/raw. Причина может быть в некорректных данных в файле. Переместите старый необработанный файл в другую папку, например в /var/stat/raw/bad, после чего перезапустите службу bstatd следующей командой:

chroot /app/collector/
service bstatd restart

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

Тесты 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

h3 Решение

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

chroot /app/xge fix_locked_shapers.sh

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

/app/xge/service restart

Решение выше не помогло, XGE/Softrouter только установили

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

for shaperid in `seq 2000 8998`; do touch /app/xge/var/lib/xge_shapers/free/$shaperid; done

Решение не помогло, установка старая, XGE/Softrouter давно используется

Рекомендуется выполнять эту инструкцию во время минимальной нагрузки на сеть.

1. Включите синхронизацию со стороны XGE
2. Сбросьте все сессии абонентов на XGE

   chroot /app/xge
   for sessions in $(xgesh session dump | awk '{print $1}'); do xgesh session $sessions remove; done

3. Дождитесь синхронизации или запустите её вручную:

   chroot /app/xge/ xge_sync

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.

check_xge_shapers.sh

Сообщение

Сломалось дерево шейперов Пытаемся починить шейперы Cannot find device "imq0" Cannot find device "imq1" Command failed -:1 Не удалось востановить дерево шейперов из последнего сейва, строим новое дерево шейперов. Требуется синхронизация скоростей Cannot find device "imq0" Cannot find device "imq1"

Данная ошибка может возникать в том случае, если сервер загрузился с некорректным ядром. Посмотреть, с каким ядром загружен сервер, можно с помощью команды uname -a:

 uname -a

Linux localhost_localdomain 2.6.32-754.28.1.el6.x86_64 #1 SMP Wed Mar 11 18:38:45 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux 

Для корректной работы шейперов сервер должен быть загружен с одним из следующих ядер:

• Linux-carbon-master
• Linux-carbon-johnik_xge
• Linux-carbon-devel
• Linux-carbon-754

Общие ошибки продуктов на платформе 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% пространства.

Решение подобных проблем довольно обширная тема, поэтоу мы вынесли её в отдельную статью Мало места на диске

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

ALARM Reboot! Не могу записать в /tmp/softdog_agent.tmp

Данная ошибка означает, что на текущий момент невозможно работать с корневым разделом (/) в системе. Чаще всего это связано с отсутствием свободного места в разделе.

 /var/log/messages

    billing-5 auditd[1469]: Audit daemon has no space left on logging partition

Также, проблема может проявляться при некорректной работе жесткого диска, или из-за проблем с файловой системой на котором размещен раздел.
Если проблема наблюдается в текущий момент времени, то информацию можно посмотреть с использованием команды dmesg | tail

WARNING Не запущен kdump

- check_kdump.sh: ERROR(2) [СБОЙ ]
 Не запущен kdump. Возможно, нужна перезагрузка сервера.

Окружение, и дисковая подсистема в частности, должна быть совместима с kdump
Для проверки нужно выполнить команду:

 /etc/init.d/kdump status 

при несовместимости появляется ответ

 Kdump is unsupported on this kernel 

Точно не поддерживаются:
а) дисковые контроллеры с драйвером cciss (все не новые серверы HP)
б) виртуальные машины Xen HVM с PV-драйверами;
в) паравиртуальные среды (OpenVZ, LXC, Xen PV)

Убедитесь что у Вас установлено и загружено актуальное ядро ОС: если с первым пунктом всё в порядке, но /etc/init.d/kdump start всё равно выдаёт "Kdump is not supported on this kernel", то:

• Если в базовом интерфейсе есть предложение обновиться, то обновите и перезагрузите сервер
• Если предложения нет, то просто перезагрузить сервер в новом ядре

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

 grep crash /var/log/dmesg 

Появится строка "Reserving xxxMB of memory at ... for crashkernel"

Строка "kexec: crashkernel=auto resulted in zero bytes of reserved memory" появляется, если на сервере менее 2 Гб оперативной памяти. Если объем памяти соответствует системным требованиям, обратитесь в техподдержку.

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 в конфигурационных файлах всех контейнеров.

ALARM Billing Сбились настройки coredump

Сбились настройки coredump (возможно сломался carbon_sysctl.d или carbon_limits.d, либо не выполнена перезагрузка после обновления).

  /app/base/usr/local/monitoring/check_coredump.sh ERROR(2)
  Create_date: 2020-02-26 18:05:04

Данный тест проверяет следующие параметры:
1. Какое ограничение по размеру применяется к файлу дампа (core file size значение unlimited) (carbon_limits.d). Информацию об этом можно посмотреть с помощью команды:

ulimit -a | grep 'core file size'

2. Соответствие имени файла дампа указанному шаблону "/tmp/cores/core.%e.%p.%h.%t" (sysctl kernel.core_pattern) (carbon_sysctl.d). Текущие настройки можно проверить:

sysctl -a | grep 'kernel.core_pattern'

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

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