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

Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.

Изменения (78)

просмотр истории страницы

*1.* При каких либо сбоях требуется проверить состояние сервера и работу всех служб. Делается это командой 
{code}server_check{code}В ответ будет выведено состояние всех служб биллинга. Все службы должны иметь состояние *\[ OK \].* Если где-то есть сбой, то при обращении в поддержку укажите сбойную службу.
{code}server_check{code}В ответ будет выведено состояние всех служб биллинга. Все службы должны иметь состояние *\[ OK \]*.

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

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

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

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}

110249
{code}
Проверьте сервер биллинга на соответствие [системным требованиям|Системные требования] и проверьте, какие события собираются [в стеке|CarbonBilling:nas_event_daemon]. Если количество не уменьшается, то следует обратиться в техническую поддержку для решения проблем с производительностью. создайте обращение на портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php]

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

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

h3. Смотрешка не принимает запросы от биллинга
В логе на котрый ссылается тест написано что просто произошла ошибка:
{code}2021-02-01 15:36:30,970 - worker - lifestream_sync - ERROR - Произошла ошибка{code}

Если посмотреть полный лок синхронизатора, можно увидеть следующее:
{code}2021-02-01 15:36:30,969 - worker - commands - INFO - Запрос не принят сервером:
Результат отправки запроса:
result.request.method=GET
result.request.url=https://lifestream.proxy.lfstrm.tv/v2/accounts?page_size=50000&page=0
result.request.body=None
result.status_code=403
result.content={"error": "HTTP 403: Forbidden (Access from 192.168.10.1 is not allowed)"} {code}
где 192.168.10.1 - адрес биллинга.
Данная ошибка означает, что Смотрешка не принимает запросы с ip 192.168.10.1. Для решения проблемы необходимо обратиться в техническую поддержку Смотрешки.


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


Подробную информацию по ошибке необходимо запросить у сервиса.
{info}
Смотрёшка не даёт обновить email абонента во время синхронизации. Необходимо вручную изменить его в Смотрёшке.
{info}

h3. iptv24tv_sync - ERROR - Произошла ошибка: ('Cursor.fetchone:\n- SQLCODE: -303\n- Dynamic SQL Error\n- SQL error code = -303 ...)
Если в логе возникает ошибка вида:
{code}2022-07-07 08:59:30,515 - worker - iptv24tv_sync - ERROR - Произошла ошибка: ('Cursor.fetchone:\n- SQLCODE: -303\n- Dynamic SQL Error\n- SQL error code = -303\n- arithmetic exception, numeric overflow, or string truncation\n- string right truncation', -303, 335544569){code}

Это означает что в БД биллинга поступают запросы от сервиса 24ТВ с логином, не соответствующим размеру поля логина в БД биллинга. Такие запросы генерируются из-за абонентов на портале IPTV у которых нет реквизитов email или телефон. Данная ошибка будет исправлена в новых версиях. Если столкнулись с данной проблемой - создайте обращение на портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php].



h2. check_error_django.sh
{code}- check_error_django.sh: ERROR(2) [СБОЙ ]
Ошибка говорит о том, что в настройках [пользователей биллинга|CarbonBilling:Управление пользователями, интерфейс администратора. Авторизация.] некорректно указан номер смс для оповещения. Номер телефона должен удовлетворять формату E.164:+79123456789 или 89123456789.

h3. Ошибка ввода значения в форму.
{code}
2021-05-25 16:30:00,581 - django - widgets - ERROR - Value 'Новый абонент' is not a valid choice.
2021-05-25 16:34:45,919 - django - widgets - ERROR - Value 'Новый абонент' is not a valid choice.
{code}
Сообщение "not a valid choice" обычно говорит о том, что в какую-то из форм ввели неверное значение.

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}
# [Обновите|Обновление биллинга] биллинг до актуальной версии.
# Если версия уже актуальная, запустите принудительное обновление - возможно повреждён какой-то файл или во время обновления произошла ошибка и новая версия не загрузилась:
{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]
2019-06-25 15:17:03 ++[python_error <140078326261696>]KeyError: 'NAS-Port'{code}

Если исправить проблемы второго и третьего случаев невозможно решить настройкой оборудорвания (например, словарь атрибутов или из формат не настраиваются), потребуется доработать OSS схему или создать новую. С таким запросом Вы можете обратиться в техподдержку. создать обращение на портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php].

h2. check_critical_pumper.sh
{code}

h3. ATOL ошибка сервера
# Пример ошибки:
{code}
2021-02-21 12:05:40,512 - worker - paysystems_lib - ERROR - ERROR: ATOL ошибка сервера: [2001] При регистрации чека свободная касса в группе не появилась за опредённый в конфигурации диапазон времени (по умолчанию, 5 минут). (id -no id-); id операции=00001 id абонента=1001
{code}
# Ошибка говорит об отсутствии связи с сервисом АТОЛ Онлайн. Обратитесь в техническую поддержку АТОЛ.

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


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

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

Описание возможных [ошибок ядра биллинга|CarbonBilling:Имеются критические ошибки в логе worker].





h3. account_traf - Не найден абонент для N записей (некорректная настройка Collector)
{code}2019-02-22 08:38:02,458 - worker - account_traf - ERROR - Не найден абонент для 367 записей{code}
2020-04-20 08:44:41,544 - worker - account_voip - ERROR - Для OSS схемы 250002 не настроен обработчик CDR{code}
Данная ошибка проявляется, когда в биллинге создан VOIP NAS, но не инициализирован и отсутствуют правила обработки CDR-файлов. Для решения проблемы, необходимо выполнить настройку по инструкции: "[CarbonBilling:Настройка парсинга CDR]":
# Инициалихзируйте NAS
# Добавьте настройки CDR-парсера из статьи

{anchor:traf-old-date}
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}
2019-11-16 04:31:35,240 - worker - usluga_abon_pay - ERROR - У абонента #25457 услуга #55231 из другого тарифа!
{code}
Этао исключительная ситуация и причину можно попробовать найти в аудите, исходя из даты когда последний раз меняли тариф: возможно в этот момент произошла ошибка транзакции.
Для исправления проблемы:
# Переключите абонента на временный тариф, потом верните нужный
# При необходимости сделайте абоненту перерасчет начиная с нужной даты

h3. csv_loading - Файл конфигурации пустой.
{info}
#25262 - это id абонета в базе данных. Быстро перейти на него в веб интерфейсе можно по ссылке:
{code}
http://<ip-биллинга>:8082/admin/Abonents/25262
{code}
{info}

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 пустой
# Удалмите пустой файл:
{code}
rm -f /app/asr_billing/cfg/autocsv/1.autocsv /app/asr_billing/cfg/autocsv/test.autocsv
{code}

h3. csv_loading - codec can't decode byte
{code}
2021-03-16 12:05:14,927 - worker - csv_loading - ERROR - Ошибка при обработке выгрузки csv: file_name=/var/autocsv/default/test.csv
2021-03-16 12:05:14,927 - worker - csv_loading - ERROR - 'utf8' codec can't decode byte 0xe2 in position 3: invalid continuation byte
{code}
Кодировка [CSV|Автоматическая выгрузка платежей из CSV] файла с платежами отличается от указанной настройках загрузки платежей из [CSV|Автоматическая выгрузка платежей из CSV].
Проверить различе кодироваок можно командами:
# Определите к какой платёжной системе относится файл:
{code:title=Пример файла}
/var/autocsv/default/test.csv
{code}
Файл загружен в каталог *default*. Определим в каком конфигурационнм файле он используется:
{code}
fgrep default /app/asr_billing/cfg/autocsv/*
/app/asr_billing/cfg/autocsv/test.autocsv:csv_path: '/var/autocsv/default/'
{code}
Видино что каталог *default* задан в конфигурационном файле:
{code}
/app/asr_billing/cfg/autocsv/test.autocsv
{code}
# Посмотрите какая одировка в конфигурацинном файле:
{code:title=Кодировка в конфигурационном файле}
grep encoding /app/asr_billing/cfg/autocsv/test.autocsv
encoding: 'windows-1251'
{code}
# Сравните её с файлом, который вы загрузили на сервер:
{code:title=Кодировка файла с платежами}
file --brief --mime-encoding /app/asr_billing/var/autocsv/default/test.csv
utf-8
{code}
# Исправьте конфигурационный файл по [статье|Автоматическая выгрузка платежей из CSV].

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 необходимо перезапустить службу elasticsearch

{code:title=Перезапуск elasticsearch}
chroot /app/asr_billing/ service elasticsearch restart
{code}

Если перезапуск не устранил ошибку, тогда необходимо выполнить переиндексацию базы биллинга по [инструкции|CarbonBilling:Не работает поиск]


h3. Поле логин не должно содержать символы пробела!
{code}
2021-02-04 18:05:07,934 - worker - common - ERROR - Ошибка обработки статуса услуг: Поле логин не должно содержать символы пробела!
{code}
Ошибка возникает, если учетная запись была создана для абонента, номер договора которого содержит символ пробела. Получить список таких абонентов можно командой:
{code}
sqlexec "set list; select name, contract_number from abonents where contract_number like '% %'"

NAME Александров В. А.
CONTRACT_NUMBER BILL0000025
{code}
Для решения проблемы необходимо убрать пробелы из номера договора по статье [CarbonBilling:Изменение номера договора]

h3. Не могу выставить акт - абонент не главный на л.с.
{code}
2021-10-10 15:04:09,693 - worker - balance_change - ERROR - Не могу выставить акт - абонент не главный на л.с.: [4071]Абонент 1 account_id=10002908 master=None main=False
2021-10-10 15:04:09,701 - worker - balance_change - ERROR - Не могу выставить акт - абонент не главный на л.с.: [4159]Абонент 2 account_id=10002908 master=None main=False
{code}
Ошибка сообщает о том, что в биллинге, на одном лицевом счете 10002908 назначены две записи абонентов и не включена опция *"Главный абонент"*, в результате, биллинг не может корректно выставить акты по лицевому счету, что может привести к нарушению блокировки абонентов по балансу. Подробная информация по настройке абонентов с одним лицевым счетом обозначена в [документации.|CarbonBilling:Два договора на одном лицевом счете. Общий счет]




h2. test_httpd.sh
{code}- test_httpd.sh: ERROR(2) [FAILED]
Как правило, такие задачи следует передавать в отдел разработки для детального анализа каждого конкретного случая.
Тем не менее, это не всегда обязательно.
Есть несколько случаев, которые можно проверить и устранить самостоятельно, без привлечения отдела разработки даже техподдержки:
* В первую очередь следует проверить общий системный лог */var/log/messages* на наличие ошибок дисковой подсистемы, если они есть и относятся к диску на котором расположена БД биллинга - это с высокой долей вероятности может вызвать ошибку работы СУБД.
* Далее можно попробовать посмотреть содержимое файла */app/asr_billing//var/log/firebird/xinetd_169.254.30.50.log*, это журнал службы управляющей соединениями сервера баз данных, он необходим для экономии ресурсов системы и поддержания нагрузки на БД в разумных пределах.

h2. test_free_space.sh
{code}
{code}- - test_free_space.sh: ERROR(12) [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 Свободное место на диске заканчивается!
ALARM Заканчивается свободное место на диске
check_db_space /var/db/billing.gdb size is 3006791680 and on /var/db used 89%; TRIPLE_BILLING_DB_SIZE=12027166720; FREE_SPACE=10921476096; Filesystem 1K-blocks Used Available Use% Mounted on
- 100660656 27950292 67590364 30% /mnt/backup
- 100660656 84875152 10665504 89% /mnt/db
- 3966144 54912 3706432 2% /mnt/etc
- 100660656 25254224 70286432 27% /mnt/log
- 9948012 6783132 2652880 72% /mnt/shared
- 3497752448 2580575136 739494984 78% /mnt/var
{code}
/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 - базы, поврежденные в результатате некорректного завершения работы сервера.
Базы из папок *notstopped* и *replaced_by_shadow* могут пригодится если Вы планируете проводить детальный анализ поврежденных баз. Если нет - их можно очистить.
Базы из папки *safemode* можно очистить только в том случае, если в настоящий момент биллинг находится в работе.
Базы buff_traf.gdb.ГГГГММ (например, buff_traf.gdb.201904) содержат информацию по объёмам трафика полученную из netflow или radius accounting, данные из них агрегируются и добавляются в основную БД billing.gdb, их можно видеть в карточках абонентов на вкладке "[Расход|CarbonBilling:Счетчики услуг. Вкладка "Расход".]". Их можно удалять.

h2. test_radius_nas_list.sh

Чтобы найти причину, ориентируйтесь на время написанное при падении теста - в примере выше это "2017-03-21 14:48:52". Изучив лог за это время можно найти более подробную информацию о причине ошибки, вероятно она одна из описанных выше.
Если проблема повторяется часто, обратитесь в техподдержку.
Если проблема повторяется часто, составьте обращение в портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php].

h2. test_radius.py

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

h2. check_billing_radius_acc_netstat.sh
{code}chroot /app/asr_billing/ service radiusd_acc restart{code}

Если проблема сохраняется, обратитесь в техподдержку.
Если проблема сохраняется, составьте обращение в портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php].


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

h2. test_oss_daemons.sh

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

ALARM ошибка в работе демона OSS
Статус: /usr/local/bin/oss/daemon --global status
Перезапуск: /etc/init.d/oss restart
Для решения проблемы воспользуйтесь статьёй:
http://docs.carbonsoft.ru/51019784#Системамониторинга-testossdaemons.sh
Daemon is not executable: /mnt/var/oss/core/TVIP_Media/init.d/tvipmedia_sync
Исправить проблему автоматически не удалось.
{code}

h3. Daemon is not executable (TVIP TMS, TVIPmedia)

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

# Для этого, в первую очередь, зайдите в контейнер биллинга:
{code:title=chroot /app/asr_billing/}
[root@carbon ~]# chroot /app/asr_billing/
[root@carbon (asr_billing) /]#
{code}
# Попробуйте посмотреть в корневой папке схемы - символические ссылки на OSS схемы делаются обычно на папки целиком:
{code:title=ls -l /mnt/var/oss/core/TVIP_Media/ &#x7c; grep -w init.d}
[root@carbon (asr_billing) /]# ls -l /mnt/var/oss/core/TVIP_Media/ | grep -w init.d
lrwxrwxrwx 1 root root 40 Авг 26 14:35 init.d -> /usr/local/share/oss/tvipmedia_v1/init.d
{code}
# По выводу видно, что папка со скриптом синхронизации ссылается на папку */usr/local/share/oss/tvipmedia_v1/init.d*, а должна на */usr/local/share/oss/tvip_tms_v1/init.d*
# Чтобы исправить, выполните небольшой скрипт:
{code}find /var/oss/core/ -type l | xargs ls -l | grep tvipmedia_v1 | awk '{print $9, $11}' | while read link destination; do rm -f $link; ln -s ${destination/tvipmedia_v1/tvip_tms_v1} $link; done{code}


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


Заявка может возникнуть при обновлении базы данных и говорит о том, что в процессе возникли какие-либо ошибки. Обновление БД может происходить в следующих случаях:
* Автоматически, [обновлении биллинга|CarbonBilling:Обновление платформы], биллинга|Обновление биллинга],
* Вручную, при запуске *update_hook.sh* во время [переноса биллинга на новый сервер|Перенос на другой сервер (классический способ)]
* Вручную, при запуске *update_hook.sh* при [восстановлении биллинга из резервной копии|CarbonBilling:Восстановление БД биллинга из резервной копии.]
{code}
{warning}{*}update_hook.sh* можно запускать только на остановленном биллинге{warning}
В случае если повторное обновление не исправило проблему (это можно проверить по логу, поискав слово "error"), обратитесь в техподдержку.
В случае если повторное обновление не исправило проблему (это можно проверить по логу, поискав слово "error"), составьте обращение в портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php].

h2. ALARM /usr/local/bin/sync_nas\! Не могу получить списки
!nas_in_production.png|border=1,width=400!

h3. Ошибка сохранения: Carbon XGE local readonly
Если требуется удалить/ отключить синхронизацию в биллинге у NAS XGE и возникает данная ошибка, в этом случае требуется в [глобальных настройках|https://docs.carbonsoft.ru/pages/viewpage.action?pageId=63242421#Глобальныенастройкибиллингаиоператора-Общие] биллинга снять флаг *Запретить редактировать Carbon XGE local*

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

ab2.deleted=1 and (ab.deleted is null or ab.deleted=0) and ab2.id<>4{code}

h2. WARNING Billing Не работает платежная система в asr_billing

Данная ошибка будет автоматически фиксироваться системой мониторинга при отключении контейнера *asr_fiscal*(Платежные системы).
Если вам нет необходимости использовать контейнер "Платежные системы" в биллинге, для отключения теста составьте обращение в портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php].


h1. Тесты asr_cabinet

{code}

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

h3. Проблема настройки SSL
Ошибка возникает при редактировании конфигурационного файла httpd.conf . Обычно это происходит при установке [ssl сертификата на локальный сайт|Установка SSL-сертификата на локальный сайт].
{code:title=Ошибка}
Stopping httpd: [ OK ]
Starting httpd: Syntax error on line 1163 of /etc/httpd/conf/httpd.conf:
SSLCertificateFile: file '/cfg/cert/lk.my-telecom.ru/cert.pem' does not exist or is empty
{code}

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

h3. Порт уже занят другим приложением
{code:title=Ошибка}
Stopping httpd: [ OK ]
Starting httpd: (98)Address already in use: make_sock: could not bind to address 169.254.0.80:443
no listening sockets available, shutting down
Unable to open logs
[FAILED]
{code}

# Посмотрите, какое приложение заняло указанный порт (его видно в тексте ошибки, в примере это 443)
{code:title=Команда}netstat -nlp | grep 443 -w{code}
{code:title=Вывод}tcp 0 0 :::443 :::* LISTEN 5160/httpd{code}
# По выводу видно, что это приложение с PID 5160, посмотрите через подсистему proc что это за приложение
{code:title=Команда}ll /proc/5160/exe{code}
{code:title=Вывод}lrwxrwxrwx 1 root root 0 Окт 19 19:29 /proc/5160/exe -> /app/asr_fiscal/usr/sbin/httpd{code}
# В примере видно, что это исполняемый файл /app/asr_fiscal/usr/sbin/httpd. Исправьте его настройки:
#* используйте для этого приложения другой порт;
#* или перенесите его на другой сервер.

h2. test_mysql.sh

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

ALARM Повреждена база данных личного кабинета
Для решения проблемы воспользуйтесь статьёй:
http://docs.carbonsoft.ru/51019784#Системамониторинга-testmysql.sh
Останавливается mysqld: [ OK ]
Запускается mysqld: [ OK ]
HOMES.HOMES OK
...
mysql.func OK
mysql.general_log
Error : You can't use locks with log tables.
status : OK
mysql.help_category OK
mysql.help_keyword OK
...
wordpress.wp_commentmeta
Error : Incorrect information in file: './wordpress/wp_commentmeta.frm'
error : Corrupt
wordpress.wp_comments OK
...

Repairing tables
wordpress.wp_commentmeta
Error : Incorrect information in file: './wordpress/wp_commentmeta.frm'
error : Corrupt
Исправить проблему автоматически не удалось.
{code}

Это сокращённый вовод автоматического теста БД сайта и личного кабинета.

В примере видно, что тест обнаружил две ошибки:
# *Error : You can't use locks with log tables.*
# *Error : Incorrect information in file: './wordpress/wp_commentmeta.frm'*

Первая ошибка не влияет на работу сайта и ЛК, поэтому её решение не описано в рамках данной статьи.

Вторая ошибка уже может быть критичной. В конце вывода теста, mysql сообщает о том, что файл *./wordpress/wp_commentmeta.frm* повреждён.
Чтобы исправить проблему, восстановите ЛК из последней резервной копии по статье [CarbonBilling:Восстановление Wordpress. Восстановление базы данных сайта из бекапа]

h3. Ошибка: Cannot create SSLMutex.

{code:title=Ошибка}
[error] (28)No space left on device: Cannot create SSLMutex
Configuration Failed
{code}

Когда в логах apache видим ошибку «No space left on device: Couldn’t create accept lock or Cannot create SSLMutex», решить проблему помогут следующие действия:

От пользователя Апач осталось большое количество семафоров, которые необходимо удалить.

{code}
ipcs -s | grep apache
{code}

Удаление этих семафоров и является решением:


{code}
ipcs -s | grep apache | perl -e ‘while () { @a=split(/\s+/); print `ipcrm sem $a[1]`}’
{code}



h1. Тесты asr_fiscal

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


h1. Тесты collector

Перейдите по [ссылке|#checkdiskspacestat.sh] - там описано как решить проблему.

h3. Ошибка nf_collector запущен без пидфайла
{code}
2021-11-16 12:19:00: pl5angel ALARM Netflow Collector не запущен
Останавливается Netflow collector: [СБОЙ ]
Запускается Netflow collector: nf_collector запущен без пидфайла /var/run/nf_collector.pid!
[СБОЙ ]
is stopped

/usr/local/angel/check_nf_collector_listen.sh ERROR(2)
Create_date: 2021-11-16 12:19:00
{code}

Проблема могла возникнуть при перезапуске сервера или контейнера collector.
Для решения, необходимо перезапустить контейнер collector полностью.
{code}/app/collector/service restart{code}


h2. check_critical_traf_reporter.sh
{code}- check_check_critical_traf_reporter.sh: ERROR(1) [СБОЙ ]
{code}
{panel}Stopping radiusd_traf: {color:red}\[FAILED\]{color}{panel}
Подобный ответ говорит о проблемах с запуском радиус-сервера. Попробуйте найти решение в документации или обратитесь в техподдержку.
Подобный ответ говорит о проблемах с запуском радиус-сервера. Попробуйте найти решение в документации или составьте обращение в портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php].
{panel}radius_traf disabled in /cfg/config{panel}
Данный ответ говорит о том, что сервер сбора трафика отключен в настройках биллинга. Включите его в биллинге в меню [Настройки (в файле)|CarbonBilling:Настройки (в файле)]
{code:title=Пример вывода когда есть файлы статистики}194{code}
# Если вывод будет больше ноля, как в примере выше, рекомендуем отключить опцию и удалить собранную статистику.
# Отключить можно в настройках [служб сбора статистики|CarbonBilling:Описание работы служб сбора статистики], на вкладке "*Настhройки сохранения сырой статистики*", опция "*Сохранять сырую статистику*"
# Удалить уже собранную статистику можно такой командой:
{code}find /app/collector/var/stat/raw/ -iname 'rawnetflow*' -delete{code}
h3. Как исправить проблему

# Освободите место, чем больше - тем лучше, *свободным должно быть хотя бы 200Гб*
# Освободите место, чем больше - тем лучше, *свободным должно быть хотя бы 200Гб*. Перенесите статистику на другой сервер по rsync поверх ssh. В примере переносим статистику за январь 2021 года.
## Создайте каталог на целевом сервере
{code:title=bstat}
mkdir -p /var/stat/binstat/202101/
{code}
{code:title=nfsen}
mkdir -p /var/live/router/2021/01/
{code}
## Перенестие статистику
{code:title=bstat}
rsync --archive --verbose --progress /mnt/var/app/collector/var/stat/binstat/202101/ root@192.168.10.10:/var/stat/binstat/202101/
{code}
{code:title=nfsen}
rsync --archive --verbose --progress /mnt/var/app/collector/var/nfcapd_dump/live/router/2021/01/ root@192.168.10.10:/var/live/router/2021/01/
{code}
## Удалите статистику на сервере
{warning:title=Используйте команду в точности как написано ниже!}
Настоятельно не рекомендуем вносить изменение в команду удаления статистики, так как это может привести к неработоспособности системы в целом.
{code:title=bstat}
rm -rf /mnt/var/app/collector/var/stat/binstat/202101
{code}
{code:title=nfsen}
rm -rf /mnt/var/app/collector/var/nfcapd_dump/live/router/2021/01
{code}
{warning}
# После очистки места на диске включите службу:
## В файле */app/collector/cfg/config* поменяйте значение опции *app\['nf_collector.enabled'\]* на 1, должно получиться так:
{code}

После этого нужно создать отдельную заявку составьте обращение в службу поддержки портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php] на анализ файла. Если не переместить файл, то проблема может спровоцировать излишнюю нагрузку на сервер.

h1. Тесты xge
{code}

h3. Решение

В выводе: количество занятых классов, далее количество свободных. Как видно из примера, свободных более нет. Для решения проблемы следует запустить скрипт, удаляющий лишние локи:
{code}chroot /app/xge/ fix_locked_shapers.sh{code}
Если после выполнения скрипта абоненты будут жаловаться на наличие проблем со скоростью, перезапустите XGE
{code}/app/xge/service restart{code}
{code}chroot /app/xge/ xge_sync{code}

h3. Решение не помогло
# Перейдите в контейнер *xge*
{code}
chroot /app/xge/
{code}
# Удалите старые сессии на xge:
## Просмотрите сессии
{code}
ll /var/lib/xge_sessions/
{code}
## Переместите одну из сессий в пользовательский каталог. Например *178.22.169.233*.
{code}
mv /var/lib/xge_sessions/178.22.169.233 /root/
{code}
## Удалите сессии
{code}
rm -f /var/lib/xge_sessions/*
{code}
## Верните единственную сессию в каталог
{code}
mv /root/178.22.169.233 /var/lib/xge_sessions/
{code}
# Удалите занятые шейпреры
{code}
rm -f /var/lib/xge_shapers/lock/*
{code}
# Запустите синхронизацию абонентов
{code}
/usr/local/bin/xge_sync
{code}
# Покиньте контейнер *xge*
{code}
exit
{code}

h2. check_vm.sh


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

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

{anchor:ftp_error}
h2. ALARM Ошибка автоматической резервной копии\!

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

h4. Ошибка при попытке создать бэкап asr_cabinet
Ошибка в логе */app/base/var/log/cron_backup.sh.log*
{code}/app/asr_cabinet backup daily
Backup asr_cabinet; Prefix = daily
Очищаем старые каталоги резервных копий
Копирую cfg/
Копирую var/reg/
Запускаем хук /usr/local/bin/backup_hook.sh
Создаем бекап БД
Копируем var/cabinet_modules
rsync: [sender] link_stat "/var/cabinet_modules/*" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1330) [sender=3.2.3]

# /app/asr_cabinet/service backup daily: [СБОЙ ]
{code}
Для решения проблемы требуется остановить контейнер и заново его пересобрать командой:
{code}/app/asr_cabinet/service stop && /app/asr_cabinet/service destroy && /app/asr_cabinet/service build && /app/asr_cabinet/service start{code}


h3. backup_upload: \[СБОЙ \]

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

h4. Файловая система на FTP-сервере защищена от записи (только для чтения), curl: (25) Failed FTP upload: 451
{code}
> STOR backup_daily_2021-08-30_02-51_auth.tar.gz
< 451 Requested action aborted: Read-only file system
* Failed FTP upload: 451
* Remembering we are in dir "/backup/auth//./"
* Uploaded unaligned file size (0 out of 240829 bytes)
* Connection #0 to host 94.247.58.212 left intact
curl: (25) Failed FTP upload: 451
{code}
В этом примере, биллинг попытался отправить резервную копию на FTP, но сервер не принял файл и написал ошибку что файловая система в ражиме только для чтения.
Это может возникнуть, например, если диск или файловая система на FTP-сервере, неисправны, или её так настроили специально по какой-то причине.

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

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

curl: (9) Failed to MKD dir: 550{code}

h4. Бекап не успевает передаться на FTP-сервер за отведеное время, curl: (28) Operation timed out after 900000 milliseconds with 106463232 bytes received
{code}
* Connect data stream passively
< 229 Entering Extended Passive Mode (|||55624|)^M
* Trying 10.10.0.23... connected
* Connecting to 10.10.0.23 (10.10.0.23) port 55624
> TYPE I^M
< 200 Type set to I.^M
> STOR backup_weekly_2022-01-27_02-50_asr_cabinet.tar.gz^M
< 150 Opening BINARY mode data connection for 'backup_weekly_2022-01-27_02-50_asr_cabinet.tar.gz'.^M
} [data not shown]
* Operation timed out after 900000 milliseconds with 106463232 bytes received
* Closing connection #0
curl: (28) Operation timed out after 900000 milliseconds with 106463232 bytes received
{code}
Возможные пути решения данной проблемы:
# Увеличить пропускную способность канала между биллингом и FTP-сервером
# Увеличить время работы скрипта для выгрузки бекапа. Для этого в файле */app/base/cfg/config* указать требуемое время в секундах в поле backup['ftp.maxtime']=''

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

# Не создалась резервная копия *asr_billing*. Скорее всего, выявились ошибки БД. Об будет сообщено в логе, и в этом случае лучше сразу обратиться составьте обращение в техподдержку. портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php]. Дополнительные логи программы *gbak*, которая не смогла снять резервную копию, доступны в файле
{code}/app/asr_billing/var/log/backup_db_v2.sh.log{code}
# Резервная копия не не была выложена на ftp. В случае ошибок curl, он выполняется повторно с флагом \-v и в логе пишется строка с аргументами, которые передаются в curl. Вы можете напрямую скопировать команду с curl в консоль для отладки. Подробней об ошибках выгрузки Вы можете прочитать в [соответствующей статье|Система мониторинга]
{code}rss-ladder eth0{code}
Если это исправит проблему, не забудьте добавить автоматический вызов настройки в [хук|xge:Дополнительные настройки. hooks. Хуки] XGE
{info}Проблема актуальна для продуктов Reductor, XGE и Softrouter. Если она произошла на Billing или Billing_Slave, обязательно обратитесь в техподдержку{info}
{info}Проблема актуальна для продуктов Reductor, XGE и Softrouter. Если она произошла на Billing или Billing_Slave, обязательно составьте обращение в портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php]{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



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

* Если в [базовом интерфейсе|https://docs.carbonsoft.ru/display/CarbonBilling/Base] есть предложение обновиться, то обновите и перезагрузите сервер
* Если предложения нет, то просто перезагрузить сервер в новом ядре
{code}
[root@carbon ~]# uname -r
2.6.32-754.el6.x86_64
{code}
- это актуальная версия ядра

Если версия ядра актуальная, но */etc/init.d/kdump start* всё равно выдаёт *"Kdump is not supported on this kernel"*, то:

* Если в [базовом интерфейсе|https://docs.carbonsoft.ru/display/CarbonBilling/Base] есть предложение обновиться, то обновите и перезагрузите сервер. Актуальная версия биллинга публикуется в блоге: https://www.carbonsoft.ru/blog/
* Если предложения обновиться нет, но версия старая, обратитесь в техническую поддержку.

В некоторых случаях ядро не может само выделить память. Проверяем загрузочный вывод ядра:
{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 Гб оперативной памяти. Если объем памяти соответствует системным требованиям, обратитесь составьте обращение в техподдержку. портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php].


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

h3. Биллингу недоступен интернет, вероятно что-то с сетевым подключением

Результат автоматической проверки подсистема мониторинга отправляет в нашу CRM, для создания автоматических обращений в портале HelpDesk.

Если проблема с каналом связи, это будет видно по журналу системы мониторинга:
{code:title=Файл журнала /app/base/var/log/watchdog.log}
curl: (6) Could not resolve: rest.crm.carbonsoft.ru (Timeout while contacting DNS servers)
curl: (7) Failed to connect to XXX.XXX.XXX.XXX port 80: Connection timed out
2020-10-19 18:30:01 [4346]: kildin.net watchdog started

-------------------------------------------------------------
2020-10-19 18:34:25 [4346]: kildin.net watchdog catch Error
{code}
Здесь видно, что система мониторинга не смогла связаться с CRM по IP-адресу - значит, проблема не в DNS, а с доступом к сети в целом.

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

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