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

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

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

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

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


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" нет на портале, создадим

{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".
Выше видно какие параметры отправлялись к сервису.

Подробную информацию по ошибке необходимо запросить у сервиса.
{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}
Этао исключительная ситуация и причину можно попробовать найти в аудите, исходя из даты когда последний раз меняли тариф: возможно в этот момент произошла ошибка транзакции.
Для исправления проблемы:
# Переключите абонента на временный тариф, потом верните нужный
# При необходимости сделайте абоненту перерасчет начиная с нужной даты

{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 пустой
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. 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*, это журнал службы управляющей соединениями сервера баз данных, он необходим для экономии ресурсов системы и поддержания нагрузки на БД в разумных пределах.
В таком случае попробуйте временно ограничить объём внешних соединений к серверу - обращения по API, доступ в панель управления абонентами и тарифами, количество одновременно выполняемых отчетов в [конструкторе|CarbonBilling:Конструктор отчетов]

h2. check_db_space 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}
Функция +check_db_space+ Тест *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

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


Наиболее вероятной причиной отключения коллектора является переполнение раздела с детальной статистикой - это проверяет автоматический тест *check_disk_space_stat.sh*
Перейдите по [ссылке|#Системамониторинга-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:Системные требования]


Данная ошибка может возникать в том случае, если сервер загрузился с некорректным ядром. Посмотреть, с каким ядром загружен сервер, можно с помощью команды uname \-a:
{code} uname -a
{code:title=Команда} uname -a{code}
Linux {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}
Для корректной работы шейперов сервер должен быть загружен с одним из следующих ядер:
* title Linux-carbon-master
* title Linux-carbon-johnik_xge
* title Linux-carbon-devel
* title Linux-carbon-754

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, либо не выполнена перезагрузка после обновления).