|
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.
|
Комментарий:
Изменения (1)
просмотр истории страницы... {toc:maxLevel=2} h1. Система мониторинга На платформе *Carbon PL5* существует система автоматического тестирования, запускающая тесты всех контейнеров раз в 10 минут. При возникновении ошибки по любому из тестов, создаётся заявка в портале [HelpDesk|http://helpdesk.carbonsoft.ru/]. Помимо тестов server_check существуют так же тест выгрузки резервных копий на FTP и тест на наличие UPS. Также каждые 6 часов, в 5-ю минуту запускается тест monitoring, который запускает проверку всех контейнеров биллинга. h2. Запуск проверки вручную Проверку можно запустить вручную, выполнив команду *server_check* в терминале или открыв диагностику [в веб-интерфейсе|CarbonBilling:Диагностика системы]. h1. Диагностика в командной строке *1.* При каких либо сбоях требуется проверить состояние сервера и работу всех служб. Делается это командой {code}server_check{code}В ответ будет выведено состояние всех служб биллинга. Все службы должны иметь состояние *\[ OK \].* Если где-то есть сбой, то при обращении в поддержку укажите сбойную службу. *2.* Для проверки базы можно посмотреть логи которые ведет система: лог базы биллинга {code}cat /app/asr_billing/var/log/firebird/firebird.log{code} *В выводе особое внимание обратить на строки содержащие примерно такие блоки текста* 2.1. Повреждена целостность БД, серьезный сбой. Вероятно потребуется восстановление из бекапа: {code} Database: /mnt/var/db/billing.gdb database file appears corrupt (/mnt/var/db/billing.gdb) wrong page type page 1647 is of wrong type (expected 7, found 5) internal gds software consistency check (error during savepoint backout (290), file: exe.cpp line: 4026) {code} 2.2. Биллинг не может найти БД, вероятно биллинг в safemode: {code} Database: /mnt/var/db/billing.gdb I/O error for file "/mnt/var/db/billing.gdb" Error while trying to read from file No such file or directory {code} 2.3. Отдельная запись в таблице помечена как поврежденная: {code} Database: /mnt/var/db/billing.process.gdb.13836 Record 1002 is marked as damaged in table RDB$RELATIONS (6) {code} h1. Тесты base h2. check_free_inodes.sh {code}- check_free_inodes.sh: ERROR(254) [FAILED] /dev/md5 9125888 8581637 544251 95% /mnt/var ALARM Мало свободных inode ALARM На одном из устройств осталось мало свободных inode. Возможно какая-то папка забита большим количеством файлов{code} Ошибка говорит о том, что на одном из дисков слишком много файлов, в результате чего переполнена база файловой системы (inodes). Для решения проблемы попробуйте перезагрузить сервер - возможно какой-то процесс создал много файлов, удалил, но до сих пор держит их в памяти. Если перезагрузка не решила проблему, необходимо опеределить где слишком много файлов и удалить лишнее. Воспользуйтесь утилитой *tree*, запустив её на указанный раздел: {code}tree /mnt/var/ | tail -n 1{code} Вывод будет преблизительно следующим: {code}39143 directories, 8730047 files{code} После чего нужно посмотреть сколько занято подпапками: {code}find /mnt/var -maxdepth 1 -type d | grep -v /$ | while read path; do echo $path; tree $path | tail -n 1; done{code} И так постепенно можно найти папки в которых находится более всего файлов. Что делать с файлами зависит от конкретной ситуации. Если лишних файлов не оказалось, - их просто много \-, возможно стоит пересоздать файловую систему, зарезервировав под БД файлов больший процент раздела передав команде *mkfs* параметр *\-N*. Возможно получится увеличить число inode без пересоздания утилитой *tune2fs* с ключем *\-m* Как временно перерести данные Вы можете узнать в разделе "[CarbonBilling:Замена оборудования]". Полную информацию по параметрам утилит *mkfs* и *tune2fs* Вы можете найти в их справочном руководстве: *man mkfs.ext4*, *man tune2fs* {info}Возмжно предварительно потребуется установить команду man: {code}yum install -y man{code}{info} h2. check_apps_not_destroyed.sh {code}- check_apps_not_destroyed.sh: ERROR(2) [FAILED] ALARM Некорректное состояние аппов Обнаружены следующие аппы в состоянии destroy, которые должны быть включены: collector Требуется перезапустить их с помощью /etc/init.d/apps restart{code} Ошибка говорит о том, что какая-то из подсистем (контейнеров) платформы Carbon остановлена и "разрушена" - под этим понимается что контейнер остановлен и все точки монтирования внутри контейнера размонтированы. Возможные причины: * Сервер был перезагружен некорректно, без остановки биллинга по статье "[CarbonBilling:Выключение, перезагрузка сервера]" * Ведутся сервисные работы, изменяется конфигурация (например [добавляются диски|CarbonBilling:Добавление диска под статистику] для расширения пространства под какие-либо данные) контейнера * При "сборе" контейнера произошла ошибка и какие-то разделы внутри него сервисный скрипт не смог замонтировать * Произошла какая-либо иная ошибка при старте системы, из-за которой работа сервисного скрипта запускающего платформу Carbon завершилась некорректно (например, если на диске были обнаружены ошибки и системная утилита mount не смогла собрать контейнер) Для отладки в первую очередь можно попробовать запустить команду build: {code}/app/collector/service build{code} И посмотреть каким будет вывод, исходя из этого пути решения могут быть разными. Ниже рассмотрены возможные проблемы. h3. Ведутся сервисные работы Сообщите, пожалуйста, в автоматической создавшейся заявке инженерам техподдержки что ведутся работы. h3. Ошибка при сборке контейнера Попробуйте найти в журнале сервисного скрипта информацию когда контейнер с котором произошла ошибка запускался: {code}[root@Billing5 ~]# grep collector /var/log/apps.log | tail -n 2 Sat Mar 23 17:06:56 +08 2019 collector stop STOPPING Sat Mar 23 17:07:01 +08 2019 collector stop OK{code} По данному времени попробуйте найти информацию в логах загрузки (сохраняются в папке */var/log/boot/*) и в системном логе \*/var/log/messages и архивных логах: {code}cat /var/log/messages*{code} Возможно в файлов логов удастся найти информацию об ошибках файловой системы или некорректном завершении процессов по котором удастся понять причину почему не запустился контейнер. h3. Ошибка монтирования {code}/app/collector build mount: no such partition found # /app/collector/service build: [FAILED]{code} Необходимо проверить, чтоб файлы в данном контейнере не были заблокированы или использовались каким-либо пользователем в системе. В конфигурационном файле [collector|CarbonBilling:Collector] настроено сохранение [детальной статистики|CarbonBilling:Описание работы служб сбора статистики] на отдельный диск: {code}# grep mount /app/collector/cfg/config declare -A mount mount['1statfs']='-U a7a26c14-e788-40a0-b0f9-f051be5c9e61 /app/collector/var/stat' mount['2statfsnfsen']='--bind /app/collector/var/stat/nfsen_stat /app/collector/var/nfsen_stat' mount['3statfsncapdndump']='--bind /app/collector/var/stat/nfcapd_dump /app/collector/var/nfcapd_dump' mount['proc']='-t proc none /proc'{code} Но раздела с ID _a7a26c14-e788-40a0-b0f9-f051be5c9e61_ нет в системе: {code}[root@st-rline ~]# blkid | grep a7a26c14-e788-40a0-b0f9-f051be5c9e61 -c 0{code} Весьма вероятно что конфигурационный файл перенесли с другого сервера, но диск на который ранее сохранялась статистика не подключили. Вариантов решения несколько: # Выключите сервер, подключите диск, включите сервер # Настройте сохранение на другой выделенный диск или раздел # Уберите настройку выделенного раздела из конфигурационного файла h2. check_loadaverage.sh {code}- check_loadaverage.sh: ERROR(2) [FAILED] ALARM Высокий load average 12:15:09 up 223 days, 1:07, 2 users, load average: 2.56, 6.35, 12.45 2.56 6.35 12.45 3/584 32535 Возможные причины: - Запущены процессы, которые активно используют ресурс CPU. - Аппаратные проблемы с жёсткими дисками. - Часть запущенных процессов активно использует жёсткие диски - На сервере мало свободной оперативной памяти и активно используется swap - На сервере чрезвычайно много зависших процессов (run/total: 3/584) - Сервер взломан и используется для майнинга криптовалюты. - Если есть открытая автозаявка 'Повышенная нагрузка на некоторые ядра процессора' нужно сперва решить её. Полезные команды для отладки: free, top, iotop Информация о потреблении ресурсов CPU записана в /app/base/var/log/check_loadaverage.log Его можно проанализировать командой: /app/base/usr/local/bin/analyze_check_loadaverage_log.sh --analyze 2019-10-16 12:15:09: pl5angel ALARM Высокий load average{code} load average показывает очередь к CPU на выполнение запущенных процессов. Оно не должно превышать количество потоков. Если Вы столкнулись с такой проблемой, попробуйте проанилизровать лог: в него записывается вывод команды *ps \-aux* при срабатывании теста: {code}/app/base/var/log/check_loadaverage.log{code} # Анализ можно провести специальным скриптом: {code}/app/base/usr/local/bin/analyze_check_loadaverage_log.sh --analyze{code} # В начале вывода Вы увидите историю срабатывания автотеста, например: {code}/app/base/usr/local/bin/analyze_check_loadaverage_log.sh --analyze [3588] START Всего 14 срабатываний Срд Окт 16 12:11:59 +05 2019 ALARM load average 0.62 0.79 0.69 Срд Окт 16 12:13:01 +05 2019 ALARM load average 0.28 0.65 0.64 Срд Окт 16 12:13:04 +05 2019 ALARM load average 0.25 0.64 0.64 Сбт Окт 19 05:05:56 +05 2019 ALARM load average 2.69 1.76 1.03 Сбт Окт 19 05:06:10 +05 2019 ALARM load average 3.72 2.02 1.13{code} Так можно понять, часто ли возникает проблема и в какие промежутки времени - постоянно, или систематический в какое-то время, или это совершенно случайные события. # Дале тест выводит топ 10 задач, нагружавших процессор по каждлому случаю, например: {code}lavg.3588/Пнд_Окт_21_16_03_12_+05_2019.ps top 15/41 root 31910 26.4 1.3 202476 77840 ? R 16:03 0:02 python2.7 /usr/local/www/sites/manage.pyc rebuild_index --noinput root 32670 24.5 1.1 373960 66080 ? Sl 16:03 0:00 /usr/bin/python2.7 /usr/local/sbin/paysystemsd.py start 496 28833 22.3 5.3 3623268 310300 ? Sl 16:02 0:09 /usr/bin/java root 32414 21.0 1.2 302804 71928 ? R 16:03 0:00 /usr/bin/python2.7 /usr/local/sbin/worker.py start root 359 17.0 0.6 269960 40848 ? R 16:03 0:00 /usr/bin/python2.7 /usr/local/sbin/felicitation_daemon.py start root 372 16.0 0.6 269568 40256 ? R 16:03 0:00 /usr/bin/python2.7 /usr/local/sbin/jobs_daemon.py start root 31869 8.0 1.1 376156 68492 ? Rl 16:03 0:00 /usr/bin/python2.7 /usr/local/sbin/msgd.py start root 31904 6.9 1.1 299644 69276 ? S 16:03 0:00 /usr/bin/python2.7 /usr/local/sbin/worker.py start root 28885 5.0 1.7 353852 103944 ? S 16:02 0:02 uwsgi --ini /etc/uwsgi.ini 495 32426 5.0 0.2 67592 12320 ? Ss 16:03 0:00 fb_inet_server root 28883 4.3 1.6 346740 96728 ? S 16:02 0:01 uwsgi --ini /etc/uwsgi.ini 495 32301 4.4 0.1 66948 10048 ? Ss 16:03 0:00 fb_inet_server root 31899 3.3 0.3 122752 19508 ? S 16:03 0:00 python2.7 /usr/local/bin/elasticsearch_reindex.py root 29861 3.6 1.2 293252 71728 ? S 16:02 0:01 python2.7 /mnt/var/oss/core/Smotreshka_test/init.d/lifestream_sync root 28886 3.3 1.2 310988 74240 ? R 16:02 0:01 uwsgi --ini /etc/uwsgi.ini{code} Поняв что за процессы создают максимум нагрузки, можно попробовать: #* Проанализировать их лог (если есть), посмотреть что они делали в указанное время #* Возможно работа этих процессов завязана на системные ресурсы, которых им не хватает - ОЗУ, скорость работы дисков и тд. #* Если используется SSD, убедитесть что диск произвонительный по современным меркам: более 50 000 IOPS на запись и чтение, ресурс по крайней мере 300TB, используемые чипы памяти SLC, MLC или TLC #* Если используется аппаратный RAID-контроллер, то установлена BBU (батарея для сохранения кеша записи при отключении питания) - её отсутствие заметно снижает производительность дисковой подсистемы. #* Если у вас все диски подключены к аппаратному RAID - выделите под статистику отдельный виртуальный диск, с ограниченным кешем, в противном случае постоянно поступающая статистика будет заполнять кеш контроллера, снижая производительность #* Подключите отдельные диски под [детальную статистику|CarbonBilling:Добавление диска под статистику], [логи|CarbonBilling:Добавление диска под логи] (можно один диск на логи и статистику) и [базу данных|CarbonBilling:Добавление диска под БД] #* Убедитесь, что используется производительный RAID: например, если диски собраны в RAID-6 -- это надежный, но весьма медленный вариант, его можно использовать для хранения детальной статистики. Систему и БД лучше держать на RAID10 h3. Недостаточно быстрые диски Одной из основных проблем замедления работы является недостаточно производительные диски. Это можно проверить так: {code}awk '($0~"ALARM load average" || $8=="D")' /app/base/var/log/check_loadaverage.log | less{code} Если в выводе будет множество процессов в состоянии "D" (непрерываемй сон, состояние в котором процесс ожидает некоторое реакции ядра ОС и при этом не может быть прерван), это с вероятностью 99.9% говорит о недостаточной производительности дисков. Пример такого вывода: {code}Срд Окт 16 09:30:12 +05 2019 ALARM load average 22.44 23.59 20.60 root 1147 0.0 0.0 0 0 ? D Mar07 48:34 [jbd2/sda3-8] root 1400 0.0 0.0 0 0 ? D Mar07 188:02 [flush-8:0] 51 4248 0.0 0.0 76552 4672 ? D 09:30 0:00 sendmail: [127.0.0.1]: idle root 6787 0.0 0.0 53596 3732 ? D 09:30 0:00 isql-fb 169.254.30.50:/var/db/billing.gdb -p -u SYSDBA root 6865 0.0 0.0 108696 1048 ? D 09:30 0:00 /bin/bash /usr/local/sbin/nas_command.sh 111 mikrotik.sh 1 root 6867 0.0 0.0 108412 800 ? D 09:30 0:00 /bin/bash /usr/local/sbin/nas_command.sh 106 mikrotik.sh 1 root 6874 0.0 0.0 108408 808 ? D 09:30 0:00 /bin/bash /usr/local/sbin/nas_command.sh 83 session 1 /var/oss/core/Megogo/bin root 6877 0.0 0.0 108644 980 ? D 09:30 0:00 /bin/bash /usr/local/sbin/nas_command.sh 97 mikrotik.sh 1 ....{code} Вывод сокращен, в действительности там еще около 30 строк с процессами в состоянии "D" и почти все они скрипты системы, получающие данные из БД биллинга. Для решения проблемы потребовалось перенести базу на отдельный SSD диск с высокими показателями IOPS. h2. check_free_memory.sh {code}- check_free_memory.sh: ERROR(2) [FAILED] ALARM Мало свободной памяти Подробная информация записана в файл /app/base/var/log/check_free_memory.log 10 {code} Тест пишет об ошибке когда на сервере осталось менее 20% свободной ОЗУ. SWAP при этом не учитывается. Последняя строка в выводе ("10" в примере выше) - это процент свободной ОЗУ. Диагностику можно посмотреть в логе: {code}/app/base/var/log/check_free_memory.log{code} Там Вы наёдете вывод двух команд, выполненных при наличии ошибки: * *ps axSk-rss -F* - список запущенных процессов, отсортированных по объёму занимаемой памяти * *pstree -upal* - список процессов в виде дерева h3. Как именно работает тест Разберём на примере вывода команды free: {code:title=Команда}free -m | grep -E 'total|^Mem'{code} {code:title=Вывод} total used free shared buffers cached Mem: 5707 5324 382 25 681 1412 {code} Что делает тест: # Получает количество памяти: в примере это total = 5707 # Вычисляет свободную папять: складывает free, buffers и cached, то есть 384+681+1412, получается 2477 # Получает свободную память в процентах: в примере выше - 2477*100/5707, получится 43% # Если свободной памяти меньше 20%, то: #* Пишет диагностику в лог check_free_memory.log #* В логе системы монторинга сохраняется информация что тест завершился с ошибкой # Если проблема повторится 5 раз за час, то создаётся автоматическая заявка. h3. Как понять на какие процессы ушла память? Причины могут быть разными и зависить от конкретного процесса. Методика определения причины: # Убедитесь, что Ваш сервер соответствует [системным требованиям|CarbonBilling:Системные требования]: #* Количество ОЗУ достаточно #* Скорость работы ОЗУ сотвтетствует требованиям #* Процессор поддерживает работу с памятью на требуемой частоте # Если с требованиями всё в порядке, обратитесь к логу *check_free_memory.log*, типичная ситуация когда 1-2 процесса требуют больше всего памяти #* Посмотрите что это за процессы и попробуйте найти в Google информацию о проблемах с назвапнием процесса и высоким потреблением памяти, например "[mysqld high ram|https://www.google.com/search?q=mysqld+high+ram&oq=mysqld+high+ram]" Что ещё может оказаться полезным: * Убедитесь что занято не более 500Мб SWAP: {code:title=Команда}free -m | grep -E 'total|Swap'{code} {code:title=Вывод} total used free shared buffers cached Swap: 5839 15 5824 {code} \\ ** Если занято 300-500Мб, то это нормальная ситуация - некоторые системные программы и ядро могут использовать SWAP даже если есть свободная ОЗУ. ** Если занять более 500Мб - скорей всего ОЗУ системе уже недостаточно и нжуно анализировать на что она ушла, так как вместо части ОЗУ используется болеемедленный диск \\ \\ * Посмотрите потребление памяти конкретного процесса по его PID. Используя пример с тем же mysql: ** Узнаем PID {code:title=Команда}ps aux | grep -E 'PID|/usr/libexec/mysqld.*port=3307' | grep -v grep{code} {code:title=Вывод}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 {code} ** Посмотрим, занимает ли процесс место только в памяти, или ещё в SWAP {code:title=Команда}cat /proc/5064/status | grep -E 'VmSize|VmSwap'{code} {code:title=Вывод}VmSize: 377340 kB VmSwap: 0 kB{code} Пример выше делали на виртуальной машине где нет какой-либо проблемы, поэтому SWAP не занят. В действитеильности, документацию писали по кейсу где MySQL локального сайта заняла 44% ОЗУ и ещё 2Гб в SWAP, что явно говорило о проблема где-то в этой части системы. h1. Тесты asr_billing h2. check_billing_db_size.sh {code}- check_billing_db_size.sh: ERROR(1) [СБОЙ ] 2017-03-03 13:38:47 Чрезмерно большая база данных биллинга 2017-03-03 13:38:47: /usr/local/monitoring/check_billing_db_size.sh ERROR(1): 2017-03-03 13:38:47 Чрезмерно большая база данных биллинга{code} Ошибка происходит при увеличении размера БД до 10Гб. Почему так происходит, описано в [справочной документации firebird|http://www.firebirdfaq.org/faq41/]. Со временем база может достичь данного размера по той простой причине, что место на диске не очищается при удалении записей из базы данных, так как это создаст лишнюю постоянную нагрузку на диск и ОЗУ. Записи в БД добавляются постоянно - любые события, происходящие с абонентами, их лицевыми считами, оборудованием, добавляются в стэк событий, обрабатываются воркером, после чего очищаются. Для решения проблемы Вам необходимо [создать резервную копию, после чего восстановиться с неё же|Восстановление БД биллинга из резервной копии.]. h2. check_critical_jobs.sh {code}- check_critical_jobs.sh: ERROR(2) [СБОЙ ] ALARM Имеются критические ошибки в логе jobs_daemon за последний час: 5690{code} Тест сообщает что при выполнении [запланированных задач|CarbonBilling:Запланированные задачи] произошла ошибка. Посмотрел описание ошибки можно в логе службы: {code}grep CRITICAL /app/asr_billing//var/log/jobs_daemon.log | cut -d' ' -f 8-100 | sort | uniq{code} h4. Как найти проблемную задачу в биллинге В сообщении об ошибке будет написан ID задачи. По нему можно определить на каком абоненте она была создана: * Ошибка: {code}CRITICAL - Не удалось выполнить отложенную задачу id=20{code} * Создайте отчет в [конструкторе|CarbonBilling:Конструктор отчетов], подставьте в него ID проблемной задачи из описания ошибки: {code}select a.contract_number from jobs_stack js join abonents a on js.abonent_id=a.id where js.id=20{code} * Выполните отчет и Вы узнаете номер договора абонента. Найдите его [поиском|CarbonBilling:Поиск и массовое изменение абонентов] h4. Некорректного заполнения параметров запланированной задачи: отчеты {code}CRITICAL - Не удалось выполнить отложенную задачу id=18 абонента Тестовый:Traceback (most recent call last): CRITICAL - Ошибка выполнения команды python2.7 /usr/lib/python2.7/site-packages/jobs_worker/jobs_scripts/make_reports.pyc abonent_id=812{code} Ошибка возникла из-за некорректного заполнения параметров запланированной задачи на выполнение отчета - не указан ID отчета. h4. Некорректного заполнения параметров запланированной задачи: рассылка сообщений {code}CRITICAL - Не удалось выполнить отложенную задачу id=20 абонента Исилькуль:/bin/sh: -c: line 0: syntax error near unexpected token `12' CRITICAL - Ошибка выполнения команды python2.7 /usr/lib/python2.7/site-packages/jobs_worker/jobs_scripts/message_sending.pyc admin_msg_id=<12> objects_status=<27> abonent_id=2471 job_id=20{code} Ошибка возникла из-за некорректного заполнения параметров запланированной задачи на рассылку сообщений - в параметрах задачи написали лишние символы кавычек "<" и ">" Для решения - отредактируйте задачу, убрав ненужные символы и сохраните, сообщения отправятся. h4. Создана задача на выполнение отчёта. В sql запросе имеется ошибка. {code}CRITICAL - Не удалось выполнить отложенную задачу id=54 абонента Все:Traceback (most recent call last): CRITICAL - Ошибка выполнения команды python2.7 /usr/lib/python2.7/site-packages/jobs_worker/jobs_scripts/make_reports.pyc -r 1048 abonent_id=1 job_id=54{code} Здесь указан ID отчета, но всё равно фиксируется ошибка. Для подробной дигностики откройте лог в программе просмотра текста *less* и найдите ошибку: {code}less /app/asr_billing//var/log/jobs_daemon.log{code} Следующие строчки говорят о том, что в выбраном отчёте используются переменная *Po_datu*. Использование переменных допускается только в ручном выполнение отчёта. {code} 2019-10-01 01:01:06,188 - worker - jobs_lib - CRITICAL - Не удалось выполнить отложенную задачу id=54 абонента Все:Traceback (most recent call last): File "//usr/lib/python2.7/site-packages/jobs_worker/jobs_scripts/make_reports.py", line 71, in <module> File "//usr/lib/python2.7/site-packages/jobs_worker/jobs_scripts/make_reports.py", line 48, in _run File "//usr/local/www/sites/admin/models/admin_custom_reports.py", line 23, in get_data File "//usr/local/www/sites/admin/models/admin_custom_reports.py", line 61, in _execute_sql KeyError: u'2.Po_datu|date' {code} h6. Путей решения задачи два: * Исправить параметры, указав верные * Удалить запланированную задачу h2. check_events_stack_compact_count.sh {code}- check_events_stack_compact_count.sh: ERROR(1) [СБОЙ ]{code} Возникает при количестве событий больше 100000 в таблице events_stack_compact. В таблице events_stack_compact собираются события, связанные с отправкой команд на оборудование, но ещё не обработанные биллингом. Примеры состояния абонента и событий которые отправляются на оборудование после их обработки Вы можете посмотреть по [ссылке|Состояния пользователей, услуг и команды управления интернет]. Большое количество событий в таблице events_stack_compact может быть вызвано возрошей нагрузкой на биллинг. Например массовая авторизация абонентов при перезагрузке оборудования. При этом имеется проблема производительности сервера биллинга, в следтвии которой события не могут быть оперативно обработаны. Наблюдать за количеством событий можно с помощю следующего запроса. {code}# sqlexec "select count(*) from events_stack_compact" COUNT ============ 110249 {code} Проверьте сервер биллинга на соответствие [системным требованиям|Системные требования] и проверьте, какие события собираются [в стеке|CarbonBilling:nas_event_daemon]. Если количество не уменьшается, то следует обратиться в техническую поддержку для решения проблем с производительностью. {info}Если в стеке скопились команды отправки на маршрутизаторы *Mikrotik*, проверьте количество записей в _address list_: {code}/ip firewall address-list print count-only{code} Если количество несколько сотен тысяч, вероятно маршрутизатор интегрирован с *Carbon Reductor* для фильтрации по IP. В таком случае Вам нужно изменить способ инитеграции Микротика с Редуктором по статье "[REDUCTOR9:IP фильтрация MikroTik]"{info} h2. check_events_stack_count.sh {code}- check_events_stack_count.sh: ERROR(1) [СБОЙ ] 2017-03-07 07:32:18 Очень большое количество команд в event_stack{code} В таблице events_stack собираются события для отправки на оборудования. Большое количество событий связано как правило с проблемами доступа на оборудование (nas недоступен, сменились какие-то параметры вроде логина/пароля/ip, оборудование не принимает CoA и тд). Так же, возможно, что проблема в медленном ответе биллингу от НАСа, так как команды отправляются в заданное количество потоков (по-умолчанию, 1) и каждая следующая выполняется только после ответа от сервера. Убедитесь, что нагрузка процессора и канала на NAS в норме. Узнать количество скопившихся событий можно выполнив запрос к БД {code}# sqlexec "select count(*) from events_stack" COUNT ============ 122837 {code} {info}Если в стеке скопились команды отправки на маршрутизаторы *Mikrotik*, проверьте количество записей в _address list_: {code}/ip firewall address-list print count-only{code} Если количество несколько сотен тысяч, вероятно маршрутизатор интегрирован с *Carbon Reductor* для фильтрации по IP. В таком случае Вам нужно изменить способ инитеграции Микротика с Редуктором по статье "[REDUCTOR9:IP фильтрация MikroTik]"{info} h2. check_events_stack.py Попробуйте оптимизировать отправку команд по статье: [nas_event_daemon|CarbonBilling:nas_event_daemon] {info}Если в стеке скопились команды отправки на маршрутизаторы *Mikrotik*, проверьте количество записей в _address list_: {code}/ip firewall address-list print count-only{code} Если количество несколько сотен тысяч, вероятно маршрутизатор интегрирован с *Carbon Reductor* для фильтрации по IP. В таком случае Вам нужно изменить способ инитеграции Микротика с Редуктором по статье "[REDUCTOR9:IP фильтрация MikroTik]"{info} h2. check_error_oss.sh Тест говорит о наличии ошибок синхронизации с сервисами [IPTV|CarbonBilling:Интеграция сервисов интернет-телевидения]: {code}- check_error_oss.sh: ERROR(2) [FAILED] WARNING Ошибки при синхронизации оборудования Не удалось выполнить синхронизацию команд с оборудованием OSS За последний час CRITICAL: 6 За последний час ERROR: 0 Подробности в логе службы /app/asr_billing//var/log/oss.log 2019-05-07 10:01:00,717 1690 nas_event_daemon/lifestream CRITICAL Невозможно получить пользователей, т.к. не найден NAS 2019-05-07 10:10:59,813 - worker - v1 - CRITICAL - Невозможно получить пользователей, т.к. не найден NAS 2019-05-07 10:10:59,813 14711 nas_event_daemon/lifestream CRITICAL Невозможно получить пользователей, т.к. не найден NAS 2019-05-07 10:19:37,027 - worker - v1 - CRITICAL - Невозможно получить пользователей, т.к. не найден NAS 2019-05-07 10:19:37,027 25021 nas_event_daemon/lifestream CRITICAL Невозможно получить пользователей, т.к. не найден NAS Для решения проблемы воспользуйтесь статьёй: http://docs.carbonsoft.ru/51019784#Системамониторинга-checkerroross.sh{code} Все возникшие проблемы можно увидеть в логе */app/asr_billing//var/log/oss.log*. Ошибки синхронизации могут возникнуть как со стороны Carbon Billing 5, так и со стороны сервиса телевидения. Необходимые действия для их устранения необходимо определить исходя из сообщений в логе. h3. Не найден NAS {code}2019-05-07 10:01:00,717 1690 nas_event_daemon/lifestream CRITICAL Невозможно получить пользователей, т.к. не найден NAS{code} В хранилище OSS схем (/app/asr_billing/var/oss/core) существует папка с OSS-схемой IPTV, при этом сам NAS не заведён в биллинге. Для решения проблемы заведите NAS в биллинге или удалите OSS директорию. Если удаляете OSS директорию NAS IPTV в каталоге */app/asr_billing/var/oss/core/*, обязательно, после этого требуется выполнить перезапуск службы *nas_event_daemon*. {code}chroot /app/asr_billing/ service nas_event_daemon restart {code} h3. Сервер ответил ошибкой {code}2019-05-07 10:04:37,126 15643 iptvportal_package.commands ERROR Сервер ответил ошибкой: {u'error': {u'message': u'null value in column "password" violates not-null constraint\nDETAIL: Failing row contains (1234567, null, null, null, null, null, 78, 12345678, null, f, null, null, 1, 2019-05-06 15:33:51.876434+03, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null).\n'}, u'id': 111, u'method': u'update'}, Url: https://admin.provider.iptvportal.ru/api/jsonsql/, Запрос: {"params": {"table": "subscriber", "set": {"password": null}, "where": {"eq": ["username", "12345678"]}, "returning": "id"}, "jsonrpc": "2.0", "id": 111, "method": "update"}, Авторизация: {'Iptvportal-Authorization': u'sessionid=kjdiv32ur9fksffopsdkfmv34k9r0efc'}{code} При обращении к API портала телевидения возникла ошибка из-за структуры запроса или данных переданных в запросе. Как правило сервисы возвращают текст ошибки, в указанном примере это параметр *message*: {code}null value in column "password" violates not-null constraint{code} При изменении параметров учетной записе на портале телевидения, не был передан пароль - именно об этом говориться в сообщении об ошибке. Исходя из полученной информации, можно попробовать решить проблему: * В параметрах запроса видно что изменяли учтеную запись с логином "12345678" - можно попробовать найти её в биллинге и убедиться, что пароль не задан в самой учетной записи. В таком случае установите пароль и дождитесь следующей синхронизации. * Ошибка может быть в самом обработчике отправляющем запросы на портал телевидения. h3. Нужно добавить префикс для логинов в настройках услуги\! Эта проблема может возникнуть для некоторых IPTV, например [Смотрёшкой|CarbonBilling:Интеграция с LifeStream (Смотрёшка, Смотрешка)]. Настройте услуги телевидения, создающие учетную запись, по статье "[CarbonBilling:Настройка услуг IPTV]" - у всех таких услуг должен быть указан префикс для создаваемых логинов. h3. Логины учетных записей в биллинге и на портале не совпадают\! Включите опцию "*ignore_username_difference*" по статье [Интеграция с LifeStream (Смотрёшка, Смотрешка)|CarbonBilling:Интеграция с LifeStream (Смотрёшка, Смотрешка)]" h3. Неизвестный абонент на Stalker {code}iptvportal_package.commands ERROR Неизвестный абонент с ip=10.0.0.3 на Stalker, приставка mac=fe:54:00:ac:5b:e0{code} В процессе синхронизации биллинг нашел на [Stalker|CarbonBilling:Интеграция со Stalker] абонентов с неизвестными ему связкой IP-адресам и MAC-адреса. Для решения, актуализируйте данные по приставкам в биллинге или удалите устройство на портале. h3. Специфическая ошибка Смотрёшки {code}2020-04-13 12:01:03,366 - worker - lifestream_sync - ERROR - Произошла ошибка 2020-04-13 12:01:03,366 31543 nas_event_daemon/lifestream ERROR Произошла ошибка{code} В данном случае нужно смотреть полный лог Смотрёшки и анализировать конкретную ошибку. Лог находится по пути */app/asr_billing/var/log/nas_event_daemon/lifestream.log* Во-первых можно попробовать воспроизвести ошибку: включите непрерывный мониторинг лога в одном терминале: {code}tail -f /app/asr_billing/var/log/nas_event_daemon/lifestream.log{code} И перезапустите сервер синхронизации в другом: {code}chroot /app/asr_billing/ service oss restart{code} Из полученного лога в первом терминале можно сделать какие-то выводы. Если происходит ошибка, в выводе можно будет увидеть команду которую выполнял биллинг и что получил в ответ. Например: {code:title=Команда} result.request.method=GET result.request.url=https://best_isp.proxy.lfstrm.tv/v2/accounts?page_size=50000&page=0 result.request.body=None {code} {code:title=Ответ} result.status_code=500 result.content={"error": "argument of type 'NoneType' is not iterable"}{code} Получив вывод лога и возникшую ошибку, Вы можете обратиться в Смотрёшку и уточнить почему API вернул ошибку. h3. Учетки с email "user@example.com" нет на портале, создадим {code}2020-07-04 00:03:35,093 - worker - lifestream_sync - ERROR - Учетки с email "user@example.com" нет на портале, создадим{code} Ошибка говорит о том, что при синхронизации с сервисом телевидения, биллинг не обнаружил на портале учётную запись и создал её. Если ошибка повторяется для одног о и того же пользователя, посмотрите полный лог, например так: {code}tail -n 100 /app/asr_billing/var/log/nas_event_daemon/lifestream.log{code} В логе должна быть более детальная информация почему произошла ошибка, Например: {code} 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"} {code} В логе видно, что Lifestream не принял запрос от биллинга с ошибкой 400 и коментарием "login: services.error.login.accounts.invalid_login". Выше видно какие параметры отправлялись к сервису. Подробную информацию по ошибке необходимо запросить у сервиса. h2. check_error_django.sh {code}- check_error_django.sh: ERROR(2) [СБОЙ ] WARNING Имеются ошибки в логе /var/log/django/error.log за последний час: 1 {code} Причин возникновения этой ошибки может быть несколько и иногда они требуются анализа отделом разработки, однако если посмотреть какие именно были ошибки возможно получится отладить их без привлечения разработчика. Ниже приведено решение нескольких типичных проблем. h3. Ошибка web_api_get {code}2018-11-15 20:45:08,307 - django - handlers - ERROR - Exeption:'NoneType' object has no attribute '__getitem__' 'NoneType' object has no attribute '__getitem__' 2018-11-15 20:45:08,307 - django - handlers - ERROR - 'NoneType' object has no attribute '__getitem__' 'NoneType' object has no attribute '__getitem__' 2018-11-15 20:45:08,307 - django - handlers - ERROR - traceback: ['Traceback (most recent call last):\n', ' File "//usr/local/www/sites/admin/api/handlers.py", line 353, in get\n', ' File "//usr/local/www/sites/admin/api/handlers.py", line 399, in web_api_get\n', ' File "//usr/local/www/sites/admin/api/handlers.py", line 368, in process_method\n', "TypeError: 'NoneType' object has no attribute '__getitem__'\n"]{code} Ошибка функции *web_api_get* говорит о том, что скорей всего проблема в выполняемых к биллингу API-запросах. Отладить это можно по статье [CarbonBilling:API REST v2.0], раздел "*Отладка*" h3. Нужно добавить префикс для логинов в настройках услуги\! {code}2019-09-12 08:35:17,269 - django - commands - ERROR - Логин {0} состоит из одних цифр и может быть не принят! 2019-09-12 08:35:17,269 - django - commands - ERROR - Нужно добавить префикс для логинов в настройках услуги!{code} Ошибка говорит о том, что в услуге создающей учетную запись не задан префикс. Вероятней всего ошибка возникла при [настройке услуг IPTV|CarbonBilling:Настройка услуг IPTV] Посмотреть список услуг создающих учетные записи и из префиксы можно через [конструктор отчетов|CarbonBilling:Конструктор отчетов] таким запросом: {code}select id, name ,create_login, prefix_login from usluga where create_login=1{code} h3. Сервер вернул ошибку: requirement failed: Service ID must be non-empty {code}2019-12-09 00:01:47,894 - django - commands - ERROR - Сервер вернул ошибку: requirement failed: Service ID must be non-empty{code} Проблема может возникнуть при интеграции [Megogo|CarbonBilling:Интеграция с Megogo], если: * В какой-то из услуг с пакетами ТВ не указан параметр "Строка с дополнительными параметрами по активации" * В какой-то из услуг с пакетами ТВ не указан параметр "Строка с дополнительными параметрами по деактивации" * Подключена услуга создающая учетную запись и в ней тоже нет одного из указанных параметров Посмотреть списки услуг создающих учетные записи и из префиксы можно через [конструктор отчетов|CarbonBilling:Конструктор отчетов] такими запросами: {code:title=Услуги ТВ пакетов без параметров активаци/деактивации}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{code} {code:title=Услуги MEGOGO создающие учетную запись}select u.id,u.name from usluga u join nas n on u.nas_id=n.id join nas_scheme ns on n.nas_scheme_id=ns.id and ns.object_type_id=2 where u.create_login=1 and ns.name='Megogo'{code} h3. У абонента не настроен email {code}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 {code} Ошибка может возникнуть при [интеграции с сервисами IPTV|CarbonBilling:Интеграция сервисов интернет-телевидения], если абоненту подключили услугу, но у него нет адреса почты - как правило такие сервисы регистрируют абонента по адресу почты и/или номеру телефона. В частности, адрес почты обязателен при [интеграции со Смотрёшкой|CarbonBilling:Интеграция с LifeStream (Смотрёшка, Смотрешка)]. Для решения проблемы выполните этот отчет в [конструкторе|CarbonBilling:Конструктор отчетов] и заполните у абонентов адреса почты, или отлючите у них услуги ТВ. {code:title=Абоненты с услугами ТВ, но без адреса почты}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){code} h3. Сервис IPTV недоступен (ERROR - Произошла ошибка) В логе на котрый ссылается тест написано что просто произошла ошибка: {code}2019-12-16 05:39:40,098 - worker - lifestream_sync - ERROR - Произошла ошибка{code} Если посмотреть полный лок синхронизатора, можно увидеть на каком этапе скрипт синхронизации завершился, информация об этом есть в следующих строках: {code}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',)){code} По тексту ошибки видно, что сервис телевидения недоступен, это можно понять по фразам "ConnectionError" и "Max retries exceeded with url". Возможные причины: * Проблема с DNS: внутри контейнера биллинга он указан неправильно или не указан. Для этого проверьте домен Вашего порта командой nslookup, например: {code}chroot /app/asr_billing/ nslookup bestisp.proxy.lfstrm.tv{code} Указать правильный DNS можно по статье "[CarbonBilling:Настройки сети]" * Проблема с DNS: либо сервер возвращате неверный IP. Для решения проблемы обратитесь к администратору используемого DNS-сервера или используйте другой сервер. * Иные сетевые проблемы: например, если с DNS все в порядке, но сервис недоступен по сети, не вингуется, не отвечает на запросы и тд. Решение этой проблемы ни чем не отличается от решения любой другйо сетевой проблемы и не относится к настройке биллинга и данной документации. h3. Не удалось синхронизировать тех. группу: Ошибка при проверке номера {code}2020-01-15 08:08:14,658 - django - authBackend - CRITICAL - Не удалось синхронизировать тех. группу: Ошибка при проверке номера: (0) Could not interpret numbers after plus-sign.{code} Ошибка говорит о том, что в настройках [пользователей биллинга|CarbonBilling:Управление пользователями, интерфейс администратора. Авторизация.] некорректно указан номер смс для оповещения. Номер телефона должен удовлетворять формату E.164:+79123456789 или 89123456789. h3. Ошибка обработки запроса. Выдержка из лога сделанная тестом пишет о том что возникла ошибка обработки запроса: речь о запросе фреймворка Django, на котором разработано ядро биллинга, к базе данных. {code:title=/app/asr_billing/var/monitoring_dump/check_error_django.sh.NNNN.log} 2020-09-09 08:40:19,347 - django - __init__ - ERROR - Ошибка обработки запроса 2020-09-09 08:46:44,690 - django - __init__ - ERROR - Ошибка обработки запроса {code} Если посмотреть полный лог, можно будет увидеть детали ошибка типа "Traceback" и сам запрос, например: {code:title=/app/asr_billing//var/log/django/error.log} 2020-09-09 11:29:11,993 - django - __init__ - ERROR - Ошибка обработки запроса Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py", line 137, in get_response ... "Error while preparing SQL statement:") DatabaseError: ('Error while preparing SQL statement:\n- SQLCODE: -206\n- Dynamic SQL Error\n- SQL error code = -206\n- Column unknown\n- USLUGA.USLUGA_VOIP_GROUP_ID ... {code} h4. Решение # Если версия уже актуальная, возможно обновление прошло не полностью. В первую очередь попробуйте обновить базу принудительно: {code}/app/asr_billing/service stop chroot /app/asr_billing update_hook.sh --force exit /app/asr_billing/service start{code} # [Обновите|CarbonBilling:Обновление платформы] биллинг до актуальной версии. # Если версия уже актуальная, запустите принудительное обновление - возможно повреждён какой-то файл или во время обновления произошла ошибка и новая версия не загрузилась: {code}carbon_update --force{code} # Если все предыдущие действия не помогли - напишите разработчикам, приложив к задаче файл */app/asr_billing//var/log/django/error.log* h2. check_error_voip_radius.sh: {code}- 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{code} Ошибка возникает если в логе [RADIUS-сервера телефонии|CarbonBilling:Настройка VoIP оборудования в биллинге] обнаружены ошибки обработки звонков. Посмотреть найденные ошибки можно в логе из описания заявки, в приведенном выше примере это _check_error_voip_radius.sh_28358.log_ Для диагностики включите опцию "*Включить DEBUG для Radius демона телефонии*" в [настройках биллинга|CarbonBilling:Настройки (в файле)] и попробуйте совершить тестовый звонок. Если звонок не проходит или в не появляется в расходе абонента по завершению, посмотре лог ошибок, возможные причины: * Выбрана неправильная [OSS схема|CarbonBilling:Интеграция оборудования телефонии] * Присылаемые NAS-сервером атрибуты не учтены в схеме * Так же вероятная причина - не все требуемые атрибуты схемы приходят от оборудования, например: {code}2019-06-25 15:17:03 ++[python_error <140078326261696>] File "/usr/lib/python2.7/site-packages/radius_python/billing_tools/radius.py", line 171, in make_correct_acc_record new_env['NAS-Port'] = env['NAS-Port'] 2019-06-25 15:17:03 ++[python_error <140078326261696>]KeyError: 'NAS-Port'{code} Если исправить проблемы второго и третьего случаев невозможно решить настройкой оборудорвания (например, словарь атрибутов или из формат не настраиваются), потребуется доработать OSS схему или создать новую. С таким запросом Вы можете обратиться в техподдержку. h2. check_critical_pumper.sh {code} - check_critical_pumper.sh ALARM Ошибки в работе архиватора БД За последний час обнаружено CRITICAL ошибок: 6 {code} Тест регистрирует наличие некритичных ошибок обработчика, который переносит старые данные в архивную БД. Узнать, что за ошибки произошли, Вы можете следующей командой: {code}grep ERR /app/asr_billing/var/log/pumper_daemon.log{code} h2. check_error_paysystems.sh {code} - check_error_paysystems.sh: ERROR(2) [СБОЙ ] WARNING платежи или чеки клиентов не обработаны Необходимо проверить ошибки и устранить. За последний час CRITICAL: 436 За последний час ERROR: 0 Лог службы /app/asr_billing//var/log/paysystemsd.log Подробности в логе /app/asr_billing/var/monitoring_dump/check_error_paysystems.sh_11674.log Для решения проблемы воспользуйтесь статьёй: http://docs.carbonsoft.ru/51019784#Системамониторинга-checkerrorpaysystems.sh {code} Тест говорит о наличии ошибок синхронизации с сервисам [CarbonBilling:АТОЛ Онлайн]. Просмотреть чек по которому произошла ошибка можно следующим образом: # Найдите ошибку в логе службы обработки платежей: {code} /app/asr_billing/mnt/log/paysystemsd.log {code} # Пример ошибки: {code} 2019-10-03 03:51:03,015 - worker - paysystems_lib - INFO - Обрабатываем чек 1111111d-0acf-4cfd-ac16-e0215b098cf2 storno=False #13858 2019-10-03 03:51:03,402 - worker - paysystems_lib - ERROR - ERROR: Ошибка АТОЛ-Онлайн: [-3897] Не удалось выполнить операцию закрытия документа. Ответ от ККТ: [-3897] Описание: Чек оплачен не полностью. (id -no id-) {code} # Откройте чек в вэб интерфейсе биллинга. Здесь 1111111d-0acf-4cfd-ac16-e0215b098cf2 -- идентификатор действия со стороны атол-онлайн, #13858 -- номер финансовой операции в биллинге. Укажите его в ссылке на акт (Абонент->Операции->Операция->иконка с принтером): {code} http://<ip-биллинга>:8082/admin/FinanceOperations/print/13858/ {code} h3. Не обработано чеков платежей: N из-за отсутствия email или sms\! {code}2019-10-17 12:08:00,311 - worker - paysystems_lib - CRITICAL - не обработано чеков платежей: 10 из-за отсутствия email или sms!{code} В данном случае ошибка возникла из-за того что в карточке абонента не заведены "Email для оповещений" или "Номер SMS для оповещений". Для решение проблемы требуется: 1. Проверить наличие *E-Mail чека по умолчанию* в настройках ["АТОЛ Онлайн"|CarbonBilling:АТОЛ Онлайн] 2. Проверить в */app/asr_fiscal/cfg/config* опцию atol_online _'cabinet'_ на наличие параметра _'default_email'_ Например: {code}atol_online['cabinet']='enable login passwd kkt_group inn mesto email sno vat'{code} Исправить на: {code}atol_online['cabinet']='enable default_email login passwd kkt_group inn mesto email sno vat'{code} Для ускорения применения настроек требуется выполнить следующую операцию: {code}chroot /app/asr_billing/ python /usr/local/bin/get_fiscal_config.py{code} h2. check_error_worker.sh {code}- check_error_worker.sh: ERROR(2) [СБОЙ ] ALARM Имеются ошибки в логе worker за последний час: 57 2019-02-22 08:38:32: pl5monitoring ALARM Имеются ошибки в логе worker за последний час: 57{code} Тест регистрирует наличине некритичных ошибок обработки абонентов, но требующих реакции администратора или техподдержки. Узнать что за ошибки произошли Вы можете следующей командой: {code}grep ERR /app/asr_billing/var/log/worker.log{code} Ниже приведены кейсы решения некоторых возможных ошибок. [тут|CarbonBilling:АТОЛ Онлайн] h3. account_traf - Не найден абонент для N записей (некорректная настройка Collector) {code}2019-02-22 08:38:02,458 - worker - account_traf - ERROR - Не найден абонент для 367 записей{code} Ошибка говорит о том, что [обработчик абонентов|Worker (ядро биллинга)] не смог соотнести с каким-либо абонетом часть данных пришедших от [коллектора аккаунтинга интернет-трафика|CarbonBilling:Collector] Это может произойти, если список с учетными записями и их IP-адресами на стороне коллектора устарел, вероятней всего по какой-то причине он не смог его синхронизировать (синхронизация проходит каждые 30 секунд). В первую очередь стоит посмотреть лог синхронизатора: {code}# egrep -i 'CRIT|ERR' /app/collector/var/log/sync_billing.log | head -n 2 2019-02-08 03:48:50,602 - CRITICAL - Не удалось выполнить api запрос: http://192.168.8.71:8082/system_api/?arg1=%7B%7D&model=Collector&psw=3ln8bshn&context=collector&method1=collector_manager.collector_get_checked_ip_pools&format=json. Error: <urlopen error [Errno 101] Network is unreachable>{code} Список не обновился потому что в настройках коллектора указан неверный IP-адрес биллинга: {code}# grep api_ip /app/collector/cfg/config collector['api_ip.widget']='inputbox "IP адрес для доступа к API биллинга" "IP адрес для доступа к API биллинга"' collector['api_ip']='192.168.8.71' {code} Так как коллектор и биллинг находятся на одном физическом сервере, просто в разных контейнерах, в настройках следует указывать локальный адрес биллинга 169.254.80.82. Приведите параметр к следуещему виду: {code}collector['api_ip']='169.254.80.82'{code} И перезапустите коллектор: {code}/app/collector/service restart{code} h3. account_traf - Не найден абонент для N записей (аккаунтинг по неизвестным биллингу IP-адресам) {code}2019-02-26 09:00:51,620 - worker - account_traf - ERROR - Bad traffic row ID=3408858 IP=10.24.240.1 2019-02-26 09:00:51,621 - worker - account_traf - ERROR - Bad traffic row ID=3408857 IP=10.24.240.1 2019-02-26 09:05:48,390 - worker - account_traf - ERROR - Не найден абонент для 4 записей 2019-02-26 09:05:48,392 - worker - account_traf - ERROR - Bad traffic row ID=3409307 IP=172.31.10.2 2019-02-26 09:05:48,392 - worker - account_traf - ERROR - Bad traffic row ID=3409350 IP=192.168.0.110 2019-02-26 09:05:48,393 - worker - account_traf - ERROR - Bad traffic row ID=3409361 IP=172.31.10.1 2019-02-26 09:05:48,393 - worker - account_traf - ERROR - Bad traffic row ID=3409306 IP=172.31.10.2 2019-02-26 09:15:40,475 - worker - account_traf - ERROR - Не найден абонент для 2 записей 2019-02-26 09:15:40,477 - worker - account_traf - ERROR - Bad traffic row ID=3410341 IP=192.168.0.100 2019-02-26 09:15:40,477 - worker - account_traf - ERROR - Bad traffic row ID=3410342 IP=192.168.0.100{code} В случае если у Вас возникает ошибка аккаунтинга интернет-трафика, при этом в логе Вы видите записи "Bad traffic row", но нет ошибки синхронизации Collector, как в выше приведенном кейсе, вероятней всего проблема в том, что аккаунтинг (netflow) приходит по IP-адресам находящимся в Вашей сети, но не заведенным в биллинг. Для решения проблемы ограничте набор интерфейсов с которых собирается netflow и разместите хосты вызывающие ошибку за другими интерфейсами BRAS. В случае если это сделать не возможно, например если Ваше оборудование не имеет такой настройки netflow-сенсора или это нарушит структуру сети, назначьте данные адреса учетным записям в биллинге, Вы можете использовать для этого одного абонента назвав его "Служебный трафик" или завести для каждого хоста своего абонента. Получить список адресов вызывающих ошибку Вы можете следующей командой: {code}grep 'Bad traffic row ID' /app/asr_billing/var/log/worker.log | awk '{print $14}' | sed 's/IP=//g' | sort | uniq{code} Примерный результат: {code}10.24.240.1 172.16.5.148 172.31.10.1 172.31.10.2{code} h3. account_traf - Неизвестный трафик (NAS не опознал трафик) {code} 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 не опознал трафик) {code} В данном случае NAS не смог распознать трафик и прислал трафик с IP адресом 0.0.0.0 Для начала убедимся, что действительно в collector приходит netflow поток с неверным IP адресом в содержимым: # Включим повышенное логирование в контейнере collector: {code} 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 {code} # Подождём 5 минут, чтобы накопились данные в логе. # Проверим какие IP адреса не смог распознать collector. Мы видим в первой записи адрес 0.0.0.0 {code} 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 {code} # Выключим расширенное логирование collector {code} rm -f /app/collector/cfg/etc/netflow_collector/nf_collector.conf /app/collector/service restart {code} Теперь мы убедились, что в netflow потоке приходит IP адрес 0.0.0.0 Для исправления проблемы вам нужно настроить поток netflow на NAS, для этого обратитесь к официальной документации по своему NAS. h3. account_voip - Проблема с межоператорским расчетом звонка VoipLog {code}2019-04-04 16:27:42,794 - worker - account_voip - ERROR - Проблема с межоператорским расчетом звонка VoipLog [ id=805042, src=71111111111, dst=72222222222, s_time=2019-04-04 16:26:30, suid=CDR_SMG1016201904041626305842335, dst_chan=Provider2 ] Доступные операторы: Abonents [ id=1418, name=ООО "Лучший провайдер" ]{code} Решение проблемы описано в статье "[CarbonBilling:FAQ по ошибкам телефонии]" h3. account_voip - Вы используете deprecated настройки для парсера CDR / Для OSS схемы 250002 не настроен обработчик CDR {code}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{code} Данная ошибка проявляется, когда в биллинге создан VOIP NAS, но не инициализирован и отсутствуют правила обработки CDR-файлов. Для решения проблемы, необходимо выполнить настройку по инструкции: "[CarbonBilling:Настройка парсинга CDR]": # Инициалихируйте NAS # Добавьте настройки CDR-парсера из статьи h3. account_traf - Очень старая дата у трафика\! {code}2019-08-28 12:41:40,184 - worker - account_traf - ERROR - Очень старая дата у трафика! Проверьте настройки NAS! Дата: 2010-10-24 02:43:35, User ID: 4769, NAS: 10.0.0.1{code} Проблема вызвана тем, что в потоке netflow дата и время трафика отличаются от установленных на биллинге. В сообщении об ошибки можно увидеть дату которая была в netflow, ID [учетной записи|CarbonBilling:Учетная запись. Создание и изменение.] и IP NAS-сервера. {info}Чтобы посмотреть по какой учетной записи возникла проблема в интерфейсе биллинга, подставьте ID из ошибки в адресную строку. *Пример*. Допусти Вы подключаетесь к биллингу по IP 192.168.0.10, ссылка на учетную запись ID 4769 будет такой: [http://192.168.0.10/admin/Users/4769] {info} Настройка netflow-потоков подробно описана в [статье|Настройка и проверка netflow-потоков]. Для того, что бы решить проблему выполните: # Установите утилиту tshark; {code}yum -y install wireshark{code} # Запустите захват пакетов. В примере произведён захват по стандартному порту netflow 9996, на всех интерфейсах; {code}tshark -pni any port 9996 -V -c 3 | grep -C 1 Timestamp{code} Вывод будет выглядеть следующим образом: {code}tshark -pni any port 9996 -V -c 3 | grep -C 1 Timestamp Running as user "root" and group "root". This could be dangerous. Capturing on Pseudo-device that captures on all interfaces SysUptime: 1968550053 Timestamp: May 29, 2019 14:03:54.000000000 IRKT CurrentSecs: 1559109834 -- SysUptime: 1968550053 Timestamp: May 29, 2019 14:03:54.000000000 IRKT CurrentSecs: 1559109834 -- SysUptime: 1968550053 Timestamp: May 29, 2019 14:03:54.000000000 IRKT CurrentSecs: 1559109834 3 packets captured{code} Нас интересует значение поля *Timestamp*. # Посмотрите дату и время установленные на биллинге: {code} date {code} Видим, что время отличается на два часа: {code} date Срд Май 29 16:05:03 IRKT 2019 {code} # Измените дату и время на NAS исходя из полученных данных. h3. usluga_abon_pay - У абонента услуга из другого тарифа\! {code} 2019-11-16 04:31:35,160 - worker - usluga_abon_pay - ERROR - У абонента #25262 услуга #51323 из другого тарифа! 2019-11-16 04:31:35,195 - worker - usluga_abon_pay - ERROR - У абонента #25306 услуга #51779 из другого тарифа! 2019-11-16 04:31:35,205 - worker - usluga_abon_pay - ERROR - У абонента #25429 услуга #54374 из другого тарифа! 2019-11-16 04:31:35,230 - worker - usluga_abon_pay - ERROR - У абонента #25447 услуга #54821 из другого тарифа! 2019-11-16 04:31:35,240 - worker - usluga_abon_pay - ERROR - У абонента #25457 услуга #55231 из другого тарифа! {code} Эта исключительная ситуация и прчину можно попробовать найти в аудите, исходя из даты когда последний раз меняли тариф: возможно в этот момент произошла ошибка транзакции. Для исправления проблемы: # Переключите абонента на временный тариф, потом верните нужный # При необходимости сделайте абоненту перерасчет начиная с нужной даты h3. csv_loading - Файл конфигурации пустой {code} 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 пустой {code} В каталоге с настройками для выгрузки платежей из [CSV|Автоматическая выгрузка платежей из CSV] находистся пустой файл настройки. Видимо вы создали файл для настроек выгрузки платежей и не заполнили его. Пустой файл нужно удалить: # Посмотрим содержимое каталога: {code} ls -l /app/asr_billing/cfg/autocsv/ {code} Видим два файла с настройками, *test.autocsv* - пустой. {code} -rw-rw-rw- 1 root root 0 Июн 16 11:28 test.autocsv -rwxrwxrwx 1 root root 769 Июн 29 1976 default.autocsv {code} # Удалмите пустой файл: {code} rm -f /app/asr_billing/cfg/autocsv/test.autocsv {code} h3.Ошибка обработки отправки отложенных комманд ConnectionTimeout {code} 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)) {code} При фиксировании данной ошибке в логе worker необходимо выполнить переиндексацию базы биллинга по [инструкции|CarbonBilling:Не работает поиск] h2. test_httpd.sh {code}- test_httpd.sh: ERROR(2) [FAILED] ALARM Недоступен веб-интерфейс биллинга Для решения проблемы воспользуйтесь статьёй: http://docs.carbonsoft.ru/51019784#Системамониторинга-testhttpd.sh Stopping Admin Web Server: Starting Admin Web Server: [ OK ] Stopping nginx: [FAILED] Starting nginx: [ OK ] Исправить проблему автоматически не удалось. {code} Тест говорит о том, что веб-интерфейс управления абонентами и тарифами недоступен. Найти ошибку можно попытаться в следующих логах веб-сервера: {code}/app/asr_billing/var/log/nginx/error.log /app/asr_billing/var/log/nginx/access.log /app/asr_billing/var/log/admin_web_server.log /app/asr_billing/var/log/wget_abonents.log{code} По-умолчанию веб-сервер использует порты 8082 (http) и 8382 (https). Убедитесь, что в конфигурационном файле */app/asr_billing/cfg/config* заданы сделующие параметры: {code}app['apache.port']='8082' app['apache.ip']='169.254.80.82' app['apache.sslport']='8382' app['apache.sslip']='169.254.83.82'{code} h2. check_interbase_log.sh Тест проверяет журнал ошибок работы СУБД: {code}- check_interbase_log.sh: ERROR(2) [FAILED] ALARM Обнаружены ошибки в логах Firebird Необходимо проверить лог /app/asr_billing//var/log/firebird/firebird.log.catched.1559807284 Для решения проблемы воспользуйтесь статьёй: http://docs.carbonsoft.ru/51019784#Системамониторинга-checkinterbaselog.sh{code} В выводе теста написан путь до журнала обнаруженных ошибок: */app/asr_billing//var/log/firebird/firebird.log.catched.1559807284* Вы можете посмотреть его командой *cat*: {code}cat /app/asr_billing//var/log/firebird/firebird.log.catched.1559807284{code} Примре вывода: {code}localhost.localdomain Thu Jun 6 12:31:16 2019 I/O error for file "/usr/lib64/firebird/security2.fdb" localhost.localdomain Thu Jun 6 12:31:16 2019 Error while trying to open file localhost.localdomain Thu Jun 6 12:31:16 2019 No such file or directory localhost.localdomain Thu Jun 6 12:31:16 2019 I/O error for file "/usr/lib64/firebird/security2.fdb" localhost.localdomain Thu Jun 6 12:31:16 2019 Error while trying to open file localhost.localdomain Thu Jun 6 12:31:16 2019 No such file or directory{code} В данном случае ошибка связана с доступом к файлу одной из системных баз, обеспечивающих работу СУБД. Как правило, такие задачи следует передавать в отдел разработки для детального анализа каждого конкретного случая. Тем не менее, это не всегда обязательно. Есть несколько случаев, которые можно проверить и устранить самостоятельно, без привлечения отдела разработки даже техподдержки: * В первую очередь следует проверить общий системный лог */var/log/messages* на наличие ошибок дисковой подсистемы, если они есть и относятся к диску на котором расположена БД биллинга - это с высокой долей вероятности может вызвать ошибку работы СУБД. * Далее можно попробовать посмотреть содержимое файла */app/asr_billing//var/log/firebird/xinetd_169.254.30.50.log*, это журнал службы управляющей соединениями сервера баз данных, он необходим для экономии ресурсов системы и поддержания нагрузки на БД в разумных пределах. Если количество обращений к БД превышает допустимое, это вызовет отказ в соединении и в логе СУБД firebird.log появятся соответствующие записи. В таком случае попробуйте временно ограничить объём внешних соединений к серверу - обращения по API, доступ в панель управления абонентами и тарифами, количество одновременно выполняемых отчетов в [конструкторе|CarbonBilling:Конструктор отчетов] h2. test_free_space.sh {code}- test_free_space.sh: ERROR(1) [FAILED] 2019-04-10 10:04:24 localhost.localdomain test_free_space.sh[8221]: check_db_space /var/db/billing.gdb size is 1587576832 and on /var/db used 76% 2019-04-10 10:04:24 localhost.localdomain test_free_space.sh[8221]: TRIPLE_BILLING_DB_SIZE=6350307328; FREE_SPACE=6119776256 2019-04-10 10:04:24 localhost.localdomain test_free_space.sh[8221]: Filesystem 1K-blocks Used Available Use% Mounted on - 961173328 660500248 251841568 73% /mnt/backup - 25905452 18606512 5976344 76% /mnt/db - 3966144 42280 3719064 2% /mnt/etc - 961173328 660500248 251841568 73% /mnt/log - 9948012 5649084 3786928 60% /mnt/shared - 32414588 5572272 25189068 19% /mnt/var 2019-04-10 10:04:24 localhost.localdomain test_free_space.sh[8221]: ALARM Свободное место на диске заканчивается! /usr/local/angel/test_free_space.sh ERROR(1) Create_date: 2019-04-10 10:04:24{code} Тест *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, их можно видеть в карточках абонентов на вкладке "[Расход|CarbonBilling:Счетчики услуг. Вкладка "Расход".]". Их можно удалять. h2. test_radius_nas_list.sh {code}- test_radius_nas_list.sh: ERROR(1) [СБОЙ ] Nas с IP 192.168.0.1 нету в /etc/raddb/clients.conf 2017-03-21 14:48:52 localhost test_radius_nas_list.sh[1277]: Fix radiusd by restart Останавливается radiusd: [ OK ] Останавливается radiusd_acc: [ OK ] Запускается radiusd: [ OK ] Запускается radiusd_acc: [ OK ] Nas с IP 192.168.0.1 нету в /etc/raddb/clients.conf{code} Тест пытается исправить ошибку автоматически, пересоздав конфигурационные файлы radius. Такое может произойти, в следующих случаях: * при обновлении, в случае если radius-сервер запустился раньше чем закончилась перезагрузка СУБД по той или иной причине * если Вы не указали ни OSS-схему ни Тип НАСа при добавлении (например, если добавляли NAS не мастером, или не удалили демонстрационные NAS). Также данный тест может сообщать следующую ошибку: {code}ALARM список разрешенного оборудования в Radius не совпадает со списком базы{code} В тесте есть скрипт, проверяющий соответствие NAS в БД и конфигурационном файле /app/asr_billing/etc/raddb/clients.conf. В случае, если в момент тестирования наблюдались сбои при обращении к БД, может появиться эта ошибка. Найти причину можно попробовать в логе RADIUS или его архивных копиях: {code}/app/asr_billing/var/log/radius/radius.log /app/asr_billing/var/log/radius/radius.log-20191104.gz{code} Первый файл - актуальный лог Второй - архивны, в нем информация от момета предыдущей архивации до 04 ноября 2019 года. Чтобы найти причину, ориентируйтесь на время написанное при падении теста - в примере выше это "2017-03-21 14:48:52". Изучив лог за это время можно найти более подробную информацию о причине ошибки, вероятно она одна из описанных выше. Если проблема повторяется часто, обратитесь в техподдержку. h2. test_radius.py Для отладки теста и подробного разбора проблемы можно выполнить его в режиме повышенного логирования {code}chroot /app/asr_billing python /usr/local/angel/test_radius.py --debug{code} h2. check_billing_radius_acc_netstat.sh Для решения проблемы попробуйте перезапустить обработчик аккаунтинга RADIUS: {code}chroot /app/asr_billing/ service radiusd_acc restart{code} Если проблема сохраняется, обратитесь в техподдержку. h2. test_daemons.sh Тест срабатывает если одна из служб контейнера не работает и пытается исправить ситуацию автоматический (перезапуском службы). В любом случае будет создана автоматическая заявка. Пример текста ошибки: {code}- test_daemons.sh: ERROR(2) [FAILED] 2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_daemon admin_web_server 2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: - check_pidfile admin_web_server ok ... 2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_daemon radiusd_acc 2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: - check_pidfile radiusd_acc ok 2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_daemon radiusd_traf 2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_pidfile - Pidfile not found for radiusd_traf 2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: radiusd_traf restart Stopping radiusd_traf: [FAILED] Starting radiusd_traf: [ OK ] 2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_daemon radiusd_traf 2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_pidfile - Pidfile not found for radiusd_traf ... 2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: - check_pidfile xinetd ok 2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: ALARM Некоторые демоны не работают, проверьте тест test_daemons.sh{code} При запуске все службы (=демоны) asr_billing создают маркерный файл в директории /var/lock/subsys/, так тест понимает какие службы нужно проверять (это нужно на случай если какие-то из них отключены в конфигурационном файле контейнера). По каждой службе из полученного списка тест ищет pid-файл и проверяет что процесс запущен. В результате проверки он может вернуть либо состояние "ОК", что значит что проверка пройдена успешно, либо одну из следующимх ошибок: * *Pidfile not found* \- тест не нашел пути pid-файл для процесса * *No pidfile* \- по найденому пути либо не pid-файл (например, папка), либо он удален * *No pid* \- в PID-файле не оказалось ID процесса (например, если файл оказался пустым) * *No proc entry* \- pid-файл найден, но процесса с указанным ID не оказалось. h3. Pidfile not found Ошибка может произойти если при запуске службы возникли ошибки и запуск не был корректно завершен. Еще одной возможной причиной может быть если почему-то пропал PID-файл, при том что сама служба работает. Например, перезапустим службу аккаунтинга трафика: {code}# /etc/init.d/radiusd_traf restart Stopping radiusd_traf: [FAILED] Starting radiusd_traf: [ OK ]{code} Ошибка произошла про причине того, что процесс уже запущен, но PID-файл почему-то не создан: {code}# ps aux | grep radiusd_traf | grep -v grep radiusd 10218 0.0 0.0 492948 4516 ? Ssl 03:30 0:00 /usr/sbin/radiusd_traf -d /etc/raddb_traf{code} Находим должное насположение PID-файла (подставьте путь до init файла службы) и убеждаемся что его действительно нет и ошибка не в самом тесте: {code}# grep ^prog /etc/init.d/radiusd_traf | sed 's/.*=//g' | while read progname; do pidpath=$(grep ^pidfile /etc/init.d/radiusd_traf | sed 's/\$prog/'$progname'/g; s/.*=//g; s/\}//g'); ls -l $pidpath; done ls: cannot access /var/run/radiusd_traf/radiusd_traf.pid: No such file or directory{code} Для решения проблемы Вы можете послать сигнал TERM командой *kill \-15 PID_процесса* и заново его запустить. h2. ALARM Billing Не настроены реквизиты доступа к администраторской панели для тестирования Для ускорения работы веб-интерфейса биллинга, планировщик задач ежечасно делает запрос в веб-интерфейс для формирования кеша и проверки отсутствия ошибок в отображении абонентов. Для корректной работы требуется администратор с правами *root*. По-умолчанию, в конфигурационном файле биллинга используются учетные данные *root* с паролем *servicemode*. При изменении пароля *root*, необходимо исправить так же конфигурационный файл. Либо Вы можете создать нового администратора исключительно для данной функции по статье "[Интерфейсы пользователей биллинга|Интерфейсы пользователей биллинга]" и указать его учетные данные. */app/asr_billing/cfg/config* {code}declare -A django django['username']='root' django['password']='servicemode'{code} h2. FATAL Billing Error copy metadata Заявка может возникнуть при обновлении базы данных и говорит о том, что в процессе возникли какие-либо ошибки. Обновление БД может происходить в следующих случаях: * Автоматически, [обновлении биллинга|CarbonBilling:Обновление платформы], * Вручную, при запуске *update_hook.sh* во время [переноса биллинга на новый сервер|Перенос на другой сервер (классический способ)] * Вручную, при запуске *update_hook.sh* при [восстановлении биллинга из резервной копии|CarbonBilling:Восстановление БД биллинга из резервной копии.] Скрипт обновления БД пишет лог в файл */app/asr_billing/var/log/ib_upgrade.sh.log* Так же определить наличие проблемы можно сравнив версию БД и версию биллинга. При нормальной работе версии должны совпадать. * Просмотр версии биллинга: {code} cat /app/Billing.version {code} * Просмотр версии БД: {code} sqlexec "set list; select CONST_VALUE from vpn_const where const_id = 7" {code} Если Вы столкнулись с этой ошибкой, попробуйте еще раз запустить *update_hook.sh* с ключем *\--force*. {code} /app/asr_billing/service stop chroot /app/asr_billing update_hook.sh --force exit /app/asr_billing/service start {code} Или повторно запустить обновление биллинга с ключем *\--force*. {code} carbon_update update --force {code} {warning}{*}update_hook.sh* можно запускать только на остановленном биллинге{warning} В случае если повторное обновление не исправило проблему (это можно проверить по логу, поискав слово "error"), обратитесь в техподдержку. h2. ALARM /usr/local/bin/sync_nas\! Не могу получить списки Ошибка теста говорит о том, что в процессе [синхронизации оборудования интернет|CarbonBilling:Синхронизация абонентов на оборудовании] возникли ошибки. Причину ошибки можно определить по логу синхронизации */app/asr_billing/var/log/sync_nasd.log*. Ниже описаны наиболее часто возникающие ошибки и пети их решения. h4. NAS-сервер недоступен для биллинга Сообщения в логе: {code}__main__.TimeoutError: Timeout [Errno 113] No route to host [Errno 113] No route to host{code} Проверьте что: * NAS-сервер включен * NAS-сервер доступепен биллингу по сети * На NAS-сервере не заблокирован доступ с биллинга фаерволом h3. Отключен или закрыт фаерволом порт протокола синхронизации Сообщения в логе: {code}[Errno 111] Connection refused [Errno 111] Connection refused [Errno 111] Connection refused{code} Проверьте следующее: * В биллинге указан правильный порт управления NAS-сервером * На NAS-сервере обращения с биллинга не блокируются фаерволом * На NAS-сервере включен протокол через который описано получение данных в *session* скрипте (в стандартных схемах это API для Mikrotik, ssh/telnet для Cisco и RedBack) h3. В функции users_from_nas скрипта [session|Пользовательская схема] есть ошибка, в результате которой она завершается некорректно Пример сообщений в логе: {code}2019-03-26 10:26:51 vm120 sync_nas[1897]: sync by oss cheme /var/oss/core/Mikrotik-Simple/bin/session: line 75: syntax error near unexpected token `}' /var/oss/core/Mikrotik-Simple/bin/session: line 75: `}' /usr/local/bin/sync_nas: line 207: users_from_nas: command not found{code} В указанном скрипте */var/oss/core/Mikrotik-Simple/bin/session* есть ошибка синтаксиса. В примере некорректно реализовано ветвление (if \[ nnn \]; then; действие; fi), не дописан оператор закрывающий "if", и bash дойдя до конца функции users_from_nas говорит об ошибке. h3. Вы интегрируете новый NAS и ошибка возникла в процессе отладки. В случае если Вы интегрируете новый NAS, снимите опцию "*В эксплуатации*" чтобы погасить ошибки синхронизации до момент когда он будет полностью интегрирован. !nas_in_production.png|border=1,width=400! h2. WARNING Обнаружены ошибки удаления абонентов h3. Удалены папки с работающими абонентами Это могло произойти в старых версиях биллинга и при попытке закрыть период произойдет ошибка нарушения связей в базе данных. Получить список не удаленных абонентов чьи папки в корзине можно через [конструктор отчетов|CarbonBilling:Конструктор отчетов]: {code}select ab2.id "ID папки", ab2.name "Название папки", ab.id "ID абонента", ab.name "Наименование/ФИО", ab.contract_number "Номер договора" from abonents ab left join abonents ab2 on ab.parent_id=ab2.id where ab2.deleted=1 and (ab.deleted is null or ab.deleted=0) and ab2.id<>4{code} h1. Тесты asr_cabinet h2. check_cabinet_httpd_netstat.sh Код ошибки: {code} - check_cabinet_httpd_netstat.sh: ERROR(2) [СБОЙ ] ALARM Веб-сервер локального сайта недоступен Для решения проблемы воспользуйтесь статьёй: http://docs.carbonsoft.ru/51019784#Системамониторинга-checkcabinethttpdnetstat.sh Останавливается httpd: [ OK ] Запускается httpd: [ OK ] Исправить проблему автоматически не удалось. {code} Сбой теста говорит о проблеме с сайтом провайдера и личным кабинетом. Ошибка возникает при редактировании конфигурационного файла httpd.conf . Обычно это происходит при установке [ssl сертификата на локальный сайт|Установка ssl сертификата на локальный сайт]. Путь к файлу httpd.conf: {code} /app/asr_cabinet/etc/httpd/conf/httpd.conf {code} Для исправления ошибки необходимо восстановить стандартный конфигурационный файл httpd.conf , для этого нужно: # Зайти в chroot asr_cabinet: {code} chroot /app/asr_cabinet/ {code} # Сохраняем текущие конфигурационные файлы: {code} echo yes | mv /cfg/config /root/ echo yes | mv /cfg/etc/httpd/conf/httpd.conf /root/ {code} # Копируем стандартный конфигурационный файл: {code} cp -p /skelet/cfg/config /cfg/ {code} # Выходим из chroot asr_cabinet и перезапускаем его: {code} exit /app/asr_cabinet/service restart {code} h1. Тесты asr_fiscal h2. check_fiscal_httpd_netstat.sh {code}- 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{code} Тест проверяет, что HTTP-сервер платёжных систем работает на порту указанному в [настройках|CarbonBilling:Основные настройки платежных систем], "Внешний порт платежных систем" Для этого он берёт из настроек /app/asr_fiscal/cfg/config переменные apache.ip и apache.port и командой netstat проверяет что http-сервер запущен на указанных адресе и порту. h3. Address already in use: make_sock: could not bind to address 169.254.14.44:1444 Две наиболее вероятных причины когда можно получить такую ошибку: * На порту HTTP-сервера уже запущенно какое-то приложение, может другой сервер из хост-системы или другого контейнера * При загрузке некорректно собрался контейнер asr_fiscal и информационнная ФС /proc не смонтировалась - поэтому netstat не может посмотреть информацию по занятым портам h4. Проблема с /proc Проверьте, подключен ли /proc: {code:title=Команда}mount | grep fiscal/proc{code} {code:title=Вывод}none on /app/asr_fiscal/proc type proc (rw){code} Такой вывод говорит о том, что подключен. Если вывод другой или его вообще не было - ещё раз убедитесь что ФС не смонтирована: {code:title=Команда}ls -l /app/asr_fiscal/proc/{code} {code:title=Вывод}total 0{code} В папке /proc пусто, а должно быть большое количество папок и файлов. Если Вы столкнулись с такой проблемой, вероятно произошла какая-то ошибка при старте системы. Перезапустит контейнер чтобы её исправить: {code:title=Команда}/app/asr_fiscal/service stop && /app/asr_fiscal/service destroy && /app/asr_fiscal/service build && /app/asr_fiscal/service start{code} h4. Порт занят кем-то другим Ниже приведены несколько команд, которые помогут Вам найти процесс занявший порт. Если это окажется какая-то программа из состава Carbon Billing 5, укажите для неё другой порт и перезапустите сервер. Если что-то не относящееся к продукту - лучше перенесите на другой сервер, но можно и просто указать другой порт. {code:title=Посмотреть какая программа заняла порт}netstat -nlp | grep 1444{code} {code:title=Посмотреть PID этой программы и записать в переменную "pid" (потребуется дальше)}pid=$(netstat -nlp | grep 1444 | awk '$7{print $7}' | cut -d'/' -f 1) && echo $pid{code} {code:title=Путь до исполняемого файла программы занявшей порт платежных систем}ls -l /proc/$pid/exe{code} {code:title=Файлы и сокеты открытые этой программой}ls -l /proc/$pid/fd/{code} {code:title=Посмотреть информацию по программе в дереве процессов. "-C2" оставлено на случай если программа была вызвана из другой программы или сама запустила "потомков"}ps auxf | grep -E 'START|8673.*' -C2{code} h2. check_fiscal_httpd_ssl_netstat.sh {code}- 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{code} Тест проверяет, что HTTPS-сервер платёжных систем работает на порту указанному в [настройках|CarbonBilling:Основные настройки платежных систем], "Защищенный внешний порт платежных систем, без необходимости передачи сертификата" Причины и методы решения проблем аналогичны инструкции теста *check_fiscal_httpd_netstat.sh* (выше). h1. Тесты collector h2. check_nf_collector_listen.sh {code} 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 {code} Тест проверят запущена ли служба [nf_collector|Collector#NetflowCollector] Обычно ошибка возникает, если на разделе со статистикой кончилось [место|#check_disk_space_stat.sh]. Сбор статистики был остановлен. {warning} Если служба сбора статистики выключена, биллинг не сможет считать объём трафика. {warning} h3. Как исправить проблему Наиболее вероятной причиной отключения коллектора является переполнение раздела с детальной статистикой - это проверяет автоматический тест *check_disk_space_stat.sh* Перейдите по [ссылке|#checkdiskspacestat.sh] - там описано как решить проблему. h2. check_critical_traf_reporter.sh {code}- check_check_critical_traf_reporter.sh: ERROR(1) [СБОЙ ] ALARM Критические ошибки в логе /var/log/reporter.log: 4 2018-03-20 17:07:00: pl5monitoring ALARM Критические ошибки в логе /var/log/reporter.log: 4 /usr/local/monitoring/check_check_critical_traf_reporter.sh ERROR(1) Create_date: 2018-03-20 17:07:00{code} Тест определяет наличине ошибок в логе traf_reporter - эта служба отправляет в биллинг данные по объёмам абонентского трафика. Данные отправляются на radiusd_traf в биллинге. Подобные ошибки могу возникать, если с RADIUS-сервер трафика в биллинге отключен или его работа была прервана по какой-либо причине. Отсутствие связи можно увидеть по логу traf-reporter: {code}# grep ERR /app/collector/var/log/reporter.log -A10 | tail -n 9 2018-03-20 17:04:25 - [traf-reporter] - ERROR - File /var/dump/1521471029.10.0.0.1.dat. Not send packets: 1 2018-03-20 17:04:25 - [traf-reporter] - INFO - File /var/dump/1521471029.10.0.0.1.dat not remove 2018-03-20 17:04:41 - [traf-reporter] - INFO - RADIUS server does not reply 2018-03-20 17:04:41 - [traf-reporter] - INFO - Radius server does not responce. Sleep 60 sec and retry. 2018-03-20 17:05:56 - [traf-reporter] - INFO - RADIUS server does not reply 2018-03-20 17:05:56 - [traf-reporter] - ERROR - File /var/dump/1521524972.10.0.0.2.dat. Not send packets: 1 2018-03-20 17:05:56 - [traf-reporter] - INFO - File /var/dump/1521524972.10.0.0.2.dat not remove 2018-03-20 17:06:11 - [traf-reporter] - INFO - RADIUS server does not reply 2018-03-20 17:06:11 - [traf-reporter] - INFO - Radius server does not responce. Sleep 60 sec and retry.{code} Обратить внимание следует на сообшение "RADIUS server does not reply" Для решения проблемы попробуйте перезапустить RADIUS: {code}chroot /app/asr_billing/ service radiusd_traf restart{code} Возможные ответы: {panel}Starting radiusd_traf: {color:green}\[ OK \]{color}{panel} Корректный ответ, сервис запустился. На всякий случай проверьте что трафик стал отсылаться в биллинг по логу репортера (новые сообщения должны быть только с тегом INFO: {code} 2018-03-20 15:20:50 - [traf-reporter] - INFO - File /var/dump/1521548443.10.0.0.1.dat remove 2018-03-20 15:20:50 - [traf-reporter] - INFO - Stop report 2018-03-20 15:20:50 - [traf-reporter] - INFO - Wait 10 seconds... 2018-03-20 15:21:00 - [traf-reporter] - INFO - Start report 2018-03-20 15:21:00 - [traf-reporter] - INFO - File /var/dump/1521548458.10.0.0.2.dat remove 2018-03-20 15:21:00 - [traf-reporter] - INFO - File /var/dump/1521548457.dat remove 2018-03-20 15:21:00 - [traf-reporter] - INFO - Stop report {code} {panel}Stopping radiusd_traf: {color:red}\[FAILED\]{color}{panel} Подобный ответ говорит о проблемах с запуском радиус-сервера. Попробуйте найти решение в документации или обратитесь в техподдержку. {panel}radius_traf disabled in /cfg/config{panel} Данный ответ говорит о том, что сервер сбора трафика отключен в настройках биллинга. Включите его в биллинге в меню [Настройки (в файле)|CarbonBilling:Настройки (в файле)] h2. check_bstat_check_raw_stat.sh {code} Отсутствует сырая статистика /usr/local/monitoring/check_bstat_check_raw_stat.sh ERROR(2) Create_date: 2019-05-27 00:05:14 {code} Тест проверяет, включен ли bstatd (можно проверить на веб-интерфейсе в настройках "Системы сбора статистики"), а также наличие данных статистики в /var/stat/binstat/ и /var/stat/raw/. Необходимо проверить, появляются ли файлы в данных папках, если нет, то может быть проблема с NAS, по причине которой он не отправляет статистику на биллинг. h2. check_bstat_many_raw.sh {code} - check_bstat_many_raw.sh: ERROR(2) [СБОЙ ] ALARM Большое кол-во необработанной сырой статистики 2019-08-22 11:41:12: pl5monitoring ALARM Большое кол-во необработанной сырой статистики /usr/local/monitoring/check_bstat_many_raw.sh ERROR(2) Create_date: 2019-08-22 11:41:12 {code} Тест проверяет количество файлов сырой статистики bstatd в директории: {code}/app/collector/var/stat/raw/{code} При превышении лимита создаётся автоматическая заявка. В большинстве случаев достаточно перезапустить сервис bstatd командой: {code} chroot /app/collector/ service bstatd restart {code} h3. Включена устаревшая функция: "Сохранять сырую статистику" В прошлом (еще до [появления nfsen в поставке|CarbonBilling:nfsen]) мы добавили функцию сбора сырой статисти для дальнейшего анализа Nfsen. Идея была в том чтобы собирать её для диагностики, если есть подозрения что [детальная статистика в биллинге|CarbonBilling:bstatd] работает некорректно. Подразумевается, что такая сырая статистика собиралась бы короткий промежуток времени, анализировалась и вручную удалялась. Если на Вашем сервере сбор включен и с собранными файлами ни чего не делать, то через какое-то время сработает тест *check_bstat_many_raw.sh*. Определить, в этом проблема или нет, и решить её можно так: # Посмотрите, есть ли файлы сырой статистики для nfsen: {code:title=Команда}find /app/collector/var/stat/raw/ -iname 'rawnetflow*' | wc -l{code} {code:title=Пример вывода когда есть файлы статистики}194{code} # Если вывод будет больше ноля, как в примере выше, рекомендуем отключить опцию и удалить собранную статистику. # Отключить можно в настройках [служб сбора статистики|CarbonBilling:Описание работы служб сбора статистики], на вкладке "*Настhойки сохранения сырой статистики*", опция "*Сохранять сырую статистику*" # Удалить уже собранную статистику можно такой командой: {code}find /app/collector/var/stat/raw/ -iname 'rawnetflow*' -delete{code} h2. check_disk_space_stat.sh {code}- check_disk_space_stat.sh: ERROR(2) [FAILED] ALARM Заканчивается место для детальной статистики Для решения проблемы воспользуйтесь статьёй: http://docs.carbonsoft.ru/51019784#Системамониторинга-checkdiskspacestat.sh df: Warning: cannot read table of mounted file systems: No such file or directory{code} Ошибка говорит о том, что у Вас недостаточно места для хранения [детальной статистики|CarbonBilling:Описание работы служб сбора статистики]. Для решения проблемы удалите часть архива или подключите более объемный диск по статье "[CarbonBilling:Добавление диска под статистику]" Тест начинает сообщать о проблеме когда на разделе со статистикой остаётся меньше чем: * На 7 дней * 14Гб {info}Объём статистики за 7 дней вычисляется исходя из архива предыдущих месяцев - тест ищет в каком периоде было больше всего статстики, делить объём на 30 и умножает на 7.{info} {note}Рекомендуемый объём диска *1ТБ*, диска меньшего объёма скорей всего надолго не хватит.{note} {warning}Если служба сбора статистики выключена, биллинг не сможет считать объём трафика. После очистки места на диске включите службу по статье: [nf_collector|Collector#NetflowCollector].{warning} h3. Как исправить проблему # Освободите место, чем больше - тем лучше, *свободным должно быть хотя бы 200Гб* # После очистки места на диске включите службу: ## В файле */app/collector/cfg/config* поменяйте значение опции *app\['nf_collector.enabled'\]* на 1, должно получиться так: {code:title=Команда}grep nf_collector\.enabled /app/collector/cfg/config | grep -v widget{code} {code:title=Вывод}app['nf_collector.enabled']='1'{code} ## И перезапустите коллектор трафика: {code:title=Команда} chroot /app/collector/ service nf_collector restart {code} {code:title=Вывод} Stopping Netflow collector: [FAILED] Starting Netflow collector: [ OK ] {code} h2. check_error_bstatd.sh {code} - 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 {code} Ошибка появляется в случае если обработчик детальной статистики bstat не справился с одним из файлов в /app/collector/var/stat/raw. Причина может быть в некорректных данных в файле. Переместите старый необработанный файл в другую папку, например в /var/stat/raw/bad, после чего перезапустите службу bstatd следующей командой: {code} chroot /app/collector/ service bstatd restart {code} После этого нужно создать отдельную заявку в службу поддержки на анализ файла. Если не переместить файл, то проблема может спровоцировать излишнюю нагрузку на сервер. h1. Тесты xge h2. check_xge_free_class.sh {code}check_xge_free_class.sh: ERROR(1) [СБОЙ]{code} Шейпер в XGE (Softrouter) является динамическим. Занятые классы определяется по наличию файлов в папке /app/xge/var/lib/xge_shapers/lock, свободные в /app/xge/var/lib/xge_shapers/free. В ситуации, когда по той или иной причине не сработала синхронизация шейперов, может возникнуть ошибка скрипта check_xge_free_class.sh. Подобная проблема наиболее характерна при подключении абонентов через vpn (pptp, pppoe) В данном случае следует посмотреть количество свободных и занятых классов: {code} ls /app/xge/var/lib/xge_shapers/lock/ | wc -l 7000 ls /app/xge/var/lib/xge_shapers/free | wc -l 0 {code} h3 Решение В выводе: количество занятых классов, далее количество свободных. Как видно из примера, свободных более нет. Для решения проблемы следует запустить скрипт, удаляющий лишние локи: {code}chroot /app/xge fix_locked_shapers.sh{code} Если после выполнения скрипта абоненты будут жаловаться на наличие проблем со скоростью, перезапустите XGE {code}/app/xge/service restart{code} h3. Решение выше не помогло, XGE/Softrouter только установили Файлы классов создаются при первой установке абоненту тарифа ограничением скорости. При свежей установке, создайте такой тариф и назначьте его абоненту чтобы не возникала ошибка теста. В случае, если они не создались после установки тарифа, выполните следующую команду: {code}for shaperid in `seq 2000 8998`; do touch /app/xge/var/lib/xge_shapers/free/$shaperid; done{code} h3. Решение не помогло, установка старая, XGE/Softrouter давно используется Рекомендуется выполнять эту инструкцию во время минимальной нагрузки на сеть. # [Включите синхронизацию со стороны XGE|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=38961204#НастройкасвязкисCarbonBilling5-Синхронизациясбиллингом] # Сбросьте все сессии абонентов на XGE {code}chroot /app/xge for sessions in $(xgesh session dump | awk '{print $1}'); do xgesh session $sessions remove; done{code} # Дождитесь синхронизации или запустите её вручную: {code}chroot /app/xge/ xge_sync{code} h2. check_vm.sh Сообщение: {info}ALARM XGE запущен на виртуальной машине: kvm. Максимальная производительности может быть достигнута только при установке на физическую машину.{info} Имя виртуальной машины может изменяться, в зависимости от оборудования. Тест сообщает об ошибке потому что XGE (как отдельно, так и в составе Softrouter) не предназначен для работы в гипервизоре. Softrouter и XGE предназначены только для работы на физическом оборудовании. Стабильная работа в виртуальных машинах не гарантируется и поддержка по проблемам с повисаниями, с потерей пакетов, с производительностью не оказывается. Об этом так же упоминается в статье [CarbonBilling:Системные требования] h2. check_xge_httpd_redirect_netstat.sh Сообщение: {info}WARNING Не слушает http-сервер XGE для неавторизованных{info} {info}WARNING Не слушает внутренний http сервер XGE{info} Тест сообщает об ошибке, если в файле /app/xge/cfg/config указан некорректный IP-адрес для редиректа. Необходимо проверить строку {code} httpd['internal_ip']='169.254.80.90' {code} Если IP-адрес отличается от указанного выше, необходимо заменить его на 169.254.80.90 и перезапустить контейнер XGE. h2. check_xge_shapers.sh Сообщение {info} Сломалось дерево шейперов Пытаемся починить шейперы Cannot find device "imq0" Cannot find device "imq1" Command failed \-:1 Не удалось востановить дерево шейперов из последнего сейва, строим новое дерево шейперов. Требуется синхронизация скоростей Cannot find device "imq0" Cannot find device "imq1" {info} Данная ошибка может возникать в том случае, если сервер загрузился с некорректным ядром. Посмотреть, с каким ядром загружен сервер, можно с помощью команды uname \-a: {code:title=Команда} uname -a{code} {code:title=Вывод}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 {code} Для корректной работы шейперов сервер должен быть загружен с одним из следующих ядер: * Linux-carbon-master * Linux-carbon-johnik_xge * Linux-carbon-devel * Linux-carbon-754 h1. Общие ошибки продуктов на платформе Carbon PL5 h2. ALARM Ошибка автоматической резервной копии\! Полный текст ошибки {code}Ошибка автоматического бекапа! Информация в логе: /app/base/var/log/cron_backup.sh.log{code} В нём сообщается, где можно уточнить в чем заключается проблема выгрузки. Как правило, ошибки возникают на стороне FTP, как то: недостаток свободного места, недоступность сервера, превышение квот, о чем можно подробней посмотреть в логе FTP-сервера. h3. backup: \[СБОЙ \] Ошибка говорит о том что резервная копия не была создана. Убедитесь, что на разделе /mnt/backup достаточно свободного места {code}# df -h /mnt/backup/ Файловая система Разм Исп Дост Исп% смонтирована на /dev/sdc3 32G 6,0G 24G 21% /mnt/backup{code} Если места достаточно, найдите в логе /app/base/var/log/cron_backup.sh.log строку, содержашую "backup: \[СБОЙ\]", например: {code}# /app/collector/service backup: [СБОЙ ]{code} Перед ней будет лог выполнения резервного копирования. Причин проблемы с резервным копированием может быть огромное множество, соответственно и решение строго индивидуально в каждом конкретном случае. h3. backup_upload: \[СБОЙ \] Найдите в логе /app/base/var/log/cron_backup.sh.log строку, содержашую "backup_upload: \[СБОЙ\]", например: {code}# /app/collector/service backup_upload: [СБОЙ ]{code} Перед ней будет лог выполнения резервного копирования. h4. FTP недоступен, curl: (7) couldn't connect to host Наиболее респространенной причиной ошибки является недоступность ФТП-сервера: {code}/app/collector backup_upload Backup upload collector Синхронизирую каталог root:servicemode /app/collector/mnt/backup/ ftp://10.20.30.40/carbon/collector Procedd /app/collector/mnt/backup//.... Не найден md5 для файла /app/collector/mnt/backup//.! Не синхронизируем! Procedd /app/collector/mnt/backup//./config_11.42.57_09-2014... Не найден md5 для файла /app/collector/mnt/backup//./config_11.42.57_09-2014! Не синхронизируем! Procedd /app/collector/mnt/backup//./config_16.40.08_12-2014... Не найден md5 для файла /app/collector/mnt/backup//./config_16.40.08_12-2014! Не синхронизируем! Procedd /app/collector/mnt/backup//./config_08.00.16_12-2014... Не найден md5 для файла /app/collector/mnt/backup//./config_08.00.16_12-2014! Не синхронизируем! Procedd /app/collector/mnt/backup//./backup_monthly_2017-03-31_02-51_collector.tar.gz... curl: (7) couldn't connect to host md5 не сходится! Выкладываем! ebba6adaa42ad946cfed04g9af0420dc /app/collector/mnt/backup/backup_monthly_2017-03-31_02-51_collector.tar.gz != curl: (7) couldn't connect to host Retry: curl -v -sS --user root:servicemode --ftp-create-dirs --upload-file /app/collector/mnt/backup//./backup_monthly_2017-03-31_02-51_collector.tar.gz ftp://10.20.30.40/carbon/collector//./backup_monthly_2017-03-31_02-51_ * About to connect() to 10.20.30.40 port 21 (#0) * Trying 10.20.30.40... Время ожидания соединения истекло * couldn't connect to host * Closing connection #0 curl: (7) couldn't connect to host{code} В данном случае, следует проверить что FTP-сервер доступен и работает. {info}Далее приведёны примеры наиболее часто встречающихся проблем. Полный список кодов ошибок с описанием можно посмотреть [в соответствующей статье на Википедии|https://en.wikipedia.org/wiki/List_of_FTP_server_return_codes].{info} h4. Отсутствует свободное место на фтп-сервере, curl: (25) Failed FTP upload: 452 {code}* Connecting to 1.2.3.4 (1.2.3.4) port 59996 > TYPE I^M < 200 Type set to I.^M > STOR audit_operations.fdb.gbk.gz^M < 452 Unique file name cannot be created.^M * Failed FTP upload: 452 * Remembering we are in dir "backups/asr_billing//./static/var/db/billing/201705/" * Uploaded unaligned file size (0 out of 323513 bytes) * Connection #0 to host 1.2.3.4 left intact curl: (25) Failed FTP upload: 452 > QUIT^M < 221 Goodbye.^M * Closing connection #0{code} Ошибка 452 говорит о том, что закончилось свободное место на фтп-сервере. h4. Логин или пароль не подходят, curl: (67) Access denied: 530 Как видно из лога, ошибка с логином {code}* About to connect() to 10.20.30.40 port 21 (#0) * Trying 10.20.30.40... connected * Connected to 10.20.30.40 (10.20.30.40) port 21 (#0) < 220 ProFTPD 1.3.5b Server (Hetzner Backup) [::ffff:10.20.30.40]^M > USER root^M < 331 Password required for root^M > PASS servicemode^M < 530 Login incorrect.^M * Access denied: 530 * Closing connection #0 curl: (67) Access denied: 530{code} h4. Нет прав на создание директорий, curl: (9) Failed to MKD dir: 550 Убедитесь, что корректно настроили права пользователя в настройках ftp, а так же права файловой системы. {code}< 250 Directory successfully changed.^M > CWD backup^M < 550 Failed to change directory.^M > MKD backup^M < 550 Create directory operation failed.^M * Failed to MKD dir: 550 * Remembering we are in dir "/mnt/carbon/backup/billing/monitoring//" * Uploaded unaligned file size (0 out of 76018 bytes) * Connection #0 to host 10.20.30.40 left intact curl: (9) Failed to MKD dir: 550{code} h3. Самые распространенные причины # Не создалась резервная копия *asr_billing*. Скорее всего, выявились ошибки БД. Об будет сообщено в логе, и в этом случае лучше сразу обратиться в техподдержку. Дополнительные логи программы *gbak*, которая не смогла снять резервную копию, доступны в файле {code}/app/asr_billing/var/log/backup_db_v2.sh.log{code} # Резервная копия не не была выложена на ftp. В случае ошибок curl, он выполняется повторно с флагом \-v и в логе пишется строка с аргументами, которые передаются в curl. Вы можете напрямую скопировать команду с curl в консоль для отладки. Подробней об ошибках выгрузки Вы можете прочитать в [соответствующей статье|Система мониторинга] h2. ALARM Не обнаружен работающий UPS Настройка и решение проблемы с ИБП описаны в статье [CarbonBaseSystem:Подсистема контроля UPS] h2. ALARM Мало свободного места на диске\! Ошибка возникает если на одном из разделов занято *более 85%* пространства. Решение подобных проблем довольно обширная тема, поэтоу мы вынесли её в отдельную статью [CarbonBilling:Мало места на диске] h2. ALARM app заблокирован в течении минут Журнал блокировок пишется в файл */var/log/pl5_service.log*. По времени создания заявки можно найти какая оперпция занимала слишком много времени и отладить. h2. ALARM CRITICAL carbon_update скрипт обновления завершился В тексте сообщения об ошибке будет описано при обновлени какого контейнера произошла ошибка, например: {code} Обновление #5 [20] от 2019-03-28 07:30:42: CRITICAL - carbon_update: скрипт обновления завершился с ошибкой 12 ---- app: base{code} "Номер" ошибки - это код возврата какого-либо из скриптов обновления запускаемых при обновлении, инициируемых основным скриптом *carbon_update*. Если ошибка возникнет повторно, описание заявки обновится, будет указано время когда она последний раз возникала. В зависимости от способа запуска обновления (автообновление изи вручную из веб-интерфейса), полную информацию об ошибке можно найти в файлах: * Автообновление: /var/log/carbon_update_autoupdate.log (лог обновления) или /var/log/carbon_update_download.log (лог загрузки актуального дистрибутива) * Вручную: /app/base/var/log/update.log Ошибку можно попробовать найти утилитой *grep*, например: {code}grep 'скрипт обновления завершился с ошибкой' /var/log/carbon_update_download.log --color -n{code} grep с флагом "-n*" первым полепи пишет номер строки в файле где обнаружена ошибка: {code}1024648:2019-03-28 10:30:04: CRITICAL - carbon_update: скрипт обновления завершился с ошибкой 12{code} Перейдя к этой строке в файле, чуть выше можно посмотреть расширенный лог и найти в каком месте работы скрипта возникла ошибка h3. скрипт обновления завершился с ошибкой 12 {code}+ /app/base/usr/local/bin/update/rsync --block-size=40507 -c --port=555 --timeout=60 --exclude=/var/ --exclude=/etc/ --exclude=/cfg/ update51.carbonsoft.ru::filearchive/profiles/Billing /tmp/__update_download.24716._app_list rsync: read error: Connection reset by peer (104) rsync error: error in rsync protocol data stream (code 12) at io.c(768) [Receiver=3.0.9]{code} Согласно логу, скрипт не смог загрузить обновление с сервера, соединение было сброшено самим сервером обновлений. Вероятные причины: * В момент когда Ваша установка пыталась запустить обновление, присходил выпуск новой версии и старая стала недоступна для загрузки * В момент когда Ваша установка пыталась запустить обновление, на сервере начались технические работы h2. ALARM Повышенная нагрузка на некоторые ядра {code}pl5angel Повышенная нагрузка на некоторые ядра процессора. Мы отслеживаем сколько ресурсов процессора потребляют процессы ядра: events/* и ksoftirqd/* Основанием для срабатывания проверки является превышения лимита в 15 одним из процессов 4 раза подряд с промежутками 3, 6 и 9 секунд между замерами 4 root 20 0 0 0 0 S 21.4 0.0 1406:21 [ksoftirqd/ 53 root 20 0 0 0 0 S 1.9 0.0 1:32.39 [ksoftirqd/ По названию процессов перечисленных выше можно определить перегруженные ядра. Всего ядер - 16. Если более одного ядра имеют нагрузку выше 15.0, возможно перегружен весь сервер и нужно искать причину высокой нагрузки. Если такое ядро только одно - нужно найти способ распределить нагрузку по ядрам. Возможны ситуации при которых нагрузка возрастает скачками из-за большого числа интерфейсов + стороннего софта для мониторинга, который слишком часто считывает счётчики из системы. Информация о нагрузке записана в /app/base/var/log/check_kprocessess.log Обратите внимание на то, что ещё было запущено в момент повышения нагрузки. /app/base/usr/local/angel/check_kprocesses.sh ERROR(2) Create_date: 2019-04-04 21:10:22{code} Тест реагирует на проблему некорректого распределения обработки прерываний по ядрам процессора, вероятней всего на Вашем сервере этим занимается только одно ядро. Диагностика и решение подробно описаны в документации по Carbon Reductor X, так же построенного на платформе Carbon: [REDUCTOR9:Потери на сетевых картах, задержки в обработке и как с ними бороться] Быстро решить проблему можно, попытавшись запустить утилиту автоматического рапределения прерываний, вызываемых обработкой сетевого трафика по всем используемым сетевым интерфейсам, например: {code}rss-ladder eth0{code} Если это исправит проблему, не забудьте добавить автоматический вызов настройки в [хук|xge:Дополнительные настройки. hooks. Хуки] XGE |
| {info}Проблема актуальна для продуктов Reductor, XGE и Softrouter. Если она произошла на Billing или Billing_Slave, обязательно обратитесь в техподдержку{info} |
| h2. ALARM Billing Watchdog не активен в течение двух часов! Основная причина - остановленный cron в корневой системе. Перезапускает его softdog_agent, его лог - /var/log/softdog_agent.log Если в данном логе много записей вида: {code} Mar 30 08:15:29 carbon crond[7293]: (CRON) INFO (Shutting down) Mar 30 08:15:29 carbon crond[24413]: (CRON) STARTUP (1.4.4) {code} Надо искать причину остановки cron - например, он намеренно остановлен администратором, либо какой-то скрипт убил (в том числе - запущенный по крону), либо системный oom_killer при недостатке памяти: {code} grep -i 'killed process' /var/log/messages-20200419 {code} Ищем подозрительные записи в кроне каждого из пользователей: {code} for user in $(getent passwd | cut -f1 -d: ); do echo $user; crontab -u $user -l; done {code} Также ошибка может появляться в случае, если биллинг установлен на виртуальной машине. В /var/log/messages находим следующие записи: {code} Apr 26 11:45:14 carbon ntpdate[32431]: step time server 83.143.51.50 offset -44098.832672 sec {code} Проверяем разницу между временем на виртуальной машине и на хосте: {code} date; vmware-toolbox-cmd stat hosttime Срд Май 27 15:25:59 MSK 2020 28 Май 2020 03:41:46 {code} Устанавливаем на хост-машине верное время (желательно ещё включить и настроить получение его по NTP), проблема должна решиться. Либо можно отключить синхронизацию с ВМ: Disable Time Synchronization Completely If you want to keep a fictitious time in a virtual machine, so that the clock in the guest is never synchronized with that on the host, you must disable time synchronization completely. A virtual machine occasionally synchronizes time with the host even if you do not turn on periodic time synchronization. To completely disable time synchronization, you must set some properties in the virtual machine configuration file. Prerequisites Power off the virtual machine. Procedure 1 Open the configuration (.vmx) file of the virtual machine with a text editor. 2 Add lines for the time synchronization properties and set the properties to FALSE. tools.syncTime = "FALSE" time.synchronize.continue = "FALSE" time.synchronize.restore = "FALSE" time.synchronize.resume.disk = "FALSE" time.synchronize.shrink = "FALSE" time.synchronize.tools.startup = "FALSE" 3 Save and close the file. |
| h2. ALARM Обнаружен другой работающий watchdog |
... На сервере работает [система мониторинга|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=51019784#Системамониторинга-Системамониторинга], каждые 10 минут она запускает набор автоматических тестов, если в работе подсистем продукта (Биллинга, маршрутизатора XGE, Редуктора и тд) обнаружены ошибки - отправляет сообщение администратору на почту и создаёт заявку в портале HelpDesk. В исключительных случаях может случиться так, что очередной запуск тестов не уложится в 10 минут и следующая итерация не сможет начаться, в место этого будет создана заявка о возникшей проблеме. Такие ситуации нужно анализировать по логам системы мониторинга и попробовать определить что за тест вызвал проблему, дальше анализировать поведение и файлы журналов службы которую проверял тест. Лог системы мониторинга: * Тесты запускаемые раз в 10 минут {code}/app/base/var/log/watchdog.log{code} * Тесты запускаемые раз в 6 часов, обычно некритичные {code}/app/base/var/log/monitoring.log{code} h2. ALARM Reboot\! Не могу записать в /tmp/softdog_agent.tmp Данная ошибка означает, что на текущий момент невозможно работать с корневым разделом (*/*) в системе. Чаще всего это связано с отсутствием свободного места в разделе. {code} /var/log/messages billing-5 auditd[1469]: Audit daemon has no space left on logging partition {code} Также, проблема может проявляться при некорректной работе жесткого диска, или из-за проблем с файловой системой на котором размещен раздел. Если проблема наблюдается в текущий момент времени, то информацию можно посмотреть с использованием команды *dmesg \| tail* h2. WARNING Не запущен kdump {code}- check_kdump.sh: ERROR(2) [СБОЙ ] Не запущен kdump. Возможно, нужна перезагрузка сервера.{code} Окружение, и дисковая подсистема в частности, должна быть совместима с kdump Для проверки нужно выполнить команду: {code} /etc/init.d/kdump status {code} при несовместимости появляется ответ {code} Kdump is unsupported on this kernel {code} Точно не поддерживаются: а) дисковые контроллеры с драйвером cciss (все не новые серверы HP) б) виртуальные машины Xen HVM с PV-драйверами; в) паравиртуальные среды (OpenVZ, LXC, Xen PV) Убедитесь что у Вас установлено и загружено актуальное ядро ОС: если с первым пунктом всё в порядке, но */etc/init.d/kdump start* всё равно выдаёт *"Kdump is not supported on this kernel"*, то: * Если в [базовом интерфейсе|https://docs.carbonsoft.ru/display/CarbonBilling/Base] есть предложение обновиться, то обновите и перезагрузите сервер * Если предложения нет, то просто перезагрузить сервер в новом ядре В некоторых случаях ядро не может само выделить память. Проверяем загрузочный вывод ядра: {code} grep crash /var/log/dmesg {code} Появится строка "Reserving xxxMB of memory at ... for crashkernel" Строка "kexec: crashkernel=auto resulted in zero bytes of reserved memory" появляется, если на сервере менее 2 Гб оперативной памяти. Если объем памяти соответствует системным требованиям, обратитесь в техподдержку. h2. WARNING Не доступны DNS серверы {code}- check_dns.sh: ERROR(2) [FAILED] WARNING Не доступны DNS-серверы 2019-04-10 11:03:31: pl5angel WARNING Не доступны DNS-серверы /app/base/usr/local/angel/check_dns.sh ERROR(2) Create_date: 2019-04-10 11:03:31{code} Тест *check_dns.sh* есть в каждом контейнере платформы Carbon. Для контейнера *base* используются DNS-сервера host-системы, он выполняет команду "*nslookup \-timeout=X ya.ru*", "X" - количество секунд ожидания ответа, задаётся в конфигурационном файле контейнера (например, /app/+base+/cfg/config) Возможные причины возникновения проблемы: * В файле /etc/resolv.conf контейнера не указаны или указаны неверные DNS-сервера. * Заданные DNS-сервера не отвечают * Заданные DNS-сервера отвечают слишком долго (дольше заданного timeout) h3. В файле /etc/resolv.conf контейнера не указаны или указаны неверные DNS-сервера. Укажите работающие и доступные для биллинга DNS-сервера по статье "[CarbonBilling:Настройки сети]" и перезапустите все : {code}/etc/init.d/apps restart{code} h3. Заданные DNS-сервера не отвечают Убедитесь, что биллингу доступен интернет и есть доступ до заданных DNS-серверов. Убедитесь что DNS-сервера работоспособны. Попробуйте указать в [настройках сети|CarbonBilling:Настройки сети] публично доступные DNS-сервера, например 8.8.8.8 (Google) или 77.88.8.8 (Yandex) h3. Заданные DNS-сервера отвечают слишком долго (дольше заданного timeout) Выполните вручную команду: {code}nslookup timeout=1 ya.ru{code} Если DNS-сервер не ответит вовремя, увеличьте timeout на еденицу (timeout=2) и так далее пока не найдете оптимальное значение. Когда удастся определить рабочий timeout, выполните следуюищй скрипт, где new_timeout задаёте равным нужному значению: {code}new_timeout=2; cat /app/01_*.list | while read app; do sed "s/app\['dns_timeout'\]='[0-9].*'/app\['dns_timeout'\]='$new_timeout'/g" -i /app/$app/cfg/config; done{code} Скрипт из примера установит timeout=2 в конфигурационных файлах всех контейнеров. h2. ALARM Billing Сбились настройки coredump {code}Сбились настройки 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{code} Данный тест проверяет следующие параметры: 1. Какое ограничение по размеру применяется к файлу дампа (core file size значение unlimited) (carbon_limits.d). Информацию об этом можно посмотреть с помощью команды: {code}ulimit -a | grep 'core file size'{code} 2. Соответствие имени файла дампа указанному шаблону "/tmp/cores/core.%e.%p.%h.%t" (sysctl kernel.core_pattern) (carbon_sysctl.d). Текущие настройки можно проверить: {code}sysctl -a | grep 'kernel.core_pattern'{code} h1. Диагностика в веб-интерфейсе Описание диагностики находится в [соответствующей статье|CarbonBilling:Диагностика системы].[АТОЛ Онлайн|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=154238981] |