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

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

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

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

*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 - выделите под статистику отдельный виртуальный диск, с ограниченным кешем, в противном случае постоянно поступающая статистика будет заполнять кеш контроллера, снижая производительность
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|Интеграция с Infomir Ministra (ex Stalker)] абонентов с неизвестными ему связкой IP-адресам и MAC-адреса.
Для решения, актуализируйте данные по приставкам в биллинге или удалите устройство на портале.

{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) [СБОЙ ]
exit
/app/asr_billing/service start{code}
# [Обновите|CarbonBilling:Обновление платформы] [Обновите|Обновление биллинга] биллинг до актуальной версии.
# Если версия уже актуальная, запустите принудительное обновление - возможно повреждён какой-то файл или во время обновления произошла ошибка и новая версия не загрузилась:
{code}carbon_update --force{code}
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-парсера из статьи

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

{code}
При фиксировании данной ошибке в логе worker необходимо выполнить переиндексацию базы биллинга по [инструкции|CarbonBilling:Не работает поиск] перезапустить службу elasticsearch

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

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


h3. Поле логин не должно содержать символы пробела!
{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 - базы, поврежденные в результатате некорректного завершения работы сервера.

Чтобы найти причину, ориентируйтесь на время написанное при падении теста - в примере выше это "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 Обнаружены ошибки удаления абонентов


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



h3. Проблема настройки SSL
Ошибка возникает при редактировании конфигурационного файла httpd.conf . Обычно это происходит при установке [ssl сертификата на локальный сайт|Установка ssl сертификата SSL-сертификата на локальный сайт].
{code:title=Ошибка}
Stopping httpd: [ OK ]
#* или перенесите его на другой сервер.

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}
{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 не активен в течение двух часов!


Убедитесь что у Вас установлено и загружено актуальное ядро ОС: если с первым пунктом всё в порядке, но */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].


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

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

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