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

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

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

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

h3. Ошибка при сборке конртейнера

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

# /app/collector/service build: [FAILED]{code}
Необходимо проверить, чтоб файлы в данном контейнере не были заблокированы или использовались каким-либо пользователем в системе.
В конфигурационном файле [collector|CarbonBilling:Collector] настроено сохранение [детальной статистики|CarbonBilling:Описание работы служб сбора статистики] на отдельный диск:
{code}# grep mount /app/collector/cfg/config
root 31910 26.4 1.3 202476 77840 ? R 16:03 0:02 python2.7 /usr/local/www/sites/manage.pyc rebuild_index --noinput
root 32670 24.5 1.1 373960 66080 ? Sl 16:03 0:00 /usr/bin/python2.7 /usr/local/sbin/paysystemsd.py start
496 28833 22.3 5.3 3623268 310300 ? Sl 16:02 0:09 /usr/bin/java
root 32414 21.0 1.2 302804 71928 ? R 16:03 0:00 /usr/bin/python2.7 /usr/local/sbin/worker.py start
root 359 17.0 0.6 269960 40848 ? R 16:03 0:00 /usr/bin/python2.7 /usr/local/sbin/felicitation_daemon.py start

h3. Недостаточно быстрые диски

Одной из основных проблем замедления работы является недостаточно производительные диски. Это можно проверить так:
{code}awk '($0~"ALARM load average" || $8=="D")' /app/base/var/log/check_loadaverage.log | less{code}
root 1147 0.0 0.0 0 0 ? D Mar07 48:34 [jbd2/sda3-8]
root 1400 0.0 0.0 0 0 ? D Mar07 188:02 [flush-8:0]
51 4248 0.0 0.0 76552 4672 ? D 09:30 0:00 sendmail: [127.0.0.1]: idle
root 6787 0.0 0.0 53596 3732 ? D 09:30 0:00 isql-fb 169.254.30.50:/var/db/billing.gdb -p -u SYSDBA
root 6865 0.0 0.0 108696 1048 ? D 09:30 0:00 /bin/bash /usr/local/sbin/nas_command.sh 111 mikrotik.sh 1
Для решения проблемы потребовалось перенести базу на отдельный 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


h4. Как найти проблемную задачу в биллинге

В сообщении об ошибке будет написан ID задачи. По нему можно определить на каком абоненте она была создана:
* Ошибка:
{code}- check_events_stack_compact_count.sh: ERROR(1) [СБОЙ ]{code}

Возникает при количестве событий больше 100000 в таблице events_stack_compact. В таблице events_stack_compact собираются события, связанные с отправкой команд на оборудование, но ещё не обработанные биллингом. Примеры состояния абонента и событий которые отправляются на оборудование после их обработки Вы можете посмотреть по [ссылке|Состояния пользователей, услуг и команды управления интернет].
Большое количество событий в таблице events_stack_compact может быть вызвано возрошей нагрузкой на биллинг. Например массовая авторизация абонентов при перезагрузке оборудования. При этом имеется проблема производительности сервера биллинга, в следтвии которой события не могут быть оперативно обработаны. Наблюдать за количеством событий можно с помощю следующего запроса.
{code}# sqlexec "select count(*) from events_stack_compact"
110249
{code}
Проверьте сервер биллинга на соответствие [системным требованиям|Системные требования] и проверьте, какие события собираются [в стеке|CarbonBilling:nas_event_daemon]. Если количество не уменьшается, то следует обратиться в техническую поддержку для решения проблем с производитьельностью.

{info}Если в стеке скопились команды отправки на маршрутизаторы *Mikrotik*, проверьте количество записей в _address list_:
h2. check_events_stack.py

Попробуйте оптимизировать отправку команд по статье: [nas_event_daemon|CarbonBilling:nas_event_daemon]





{info}Если в стеке скопились команды отправки на маршрутизаторы *Mikrotik*, проверьте количество записей в _address list_:
{code}/ip firewall address-list print count-only{code}
h2. check_error_oss.sh

Тетс Тест говорит о наличии ошибок синхронизации с сервисами [IPTV|CarbonBilling:Интеграция сервисов интернет-телевидения]:
{code}- check_error_oss.sh: ERROR(2) [FAILED]

{code}2019-05-07 10:01:00,717 1690 nas_event_daemon/lifestream CRITICAL Невозможно получить пользователей, т.к. не найден NAS{code}
В хранилище OSS схем (/app/asr_billing/var/oss/core) существует папка с OSS-схемой IPTV, при этом сам NAS не заведён в биллинге.
Для решения проблемы заведите NAS в ббиллинге или удалите OSS директорию.
Если удаляете OSS директорию NAS IPTV в каталоге */app/asr_billing/var/oss/core/*, обязательно, после этого требуется выполнить перезапуск службы *nas_event_daemon*.
{code}chroot /app/asr_billing/ service nas_event_daemon restart {code}

h3. Сервер ответил ошибкой
* Ошибка может быть в самом обработчике отправляющем запросы на портал телевидения.

h3. Нужно добавить префикс для логинов в настройках услуги\!

Эта проблема может возникнуть для некоторых IPTV, например [Смотрёшкой|CarbonBilling:Интеграция с LifeStream (Смотрёшка, Смотрешка)].
Настройте услуги телевидения, создающие учетную запись, по статье "[CarbonBilling:Настройка услуг IPTV]" - у всех таких услуг должен быть указан префикс для создаваемых логинов.

h3. Логины учетных записей в биллинге и на портале не совпадают\!

Включите опцию "*ignore_username_difference*" по статье [CarbonBilling:Интеграция с LifeStream (Смотрёшка, Смотрешка)|CarbonBilling:Интеграция с LifeStream (Смотрёшка, Смотрешка)]"

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

h3. Специфическая ошибка Смотрёшки
{code}2020-04-13 12:01:03,366 - worker - lifestream_sync - ERROR - Произошла ошибка
2020-04-13 12:01:03,366 31543 nas_event_daemon/lifestream ERROR Произошла ошибка{code}
В данном случае нужно смотреть полный лог Смотрёшки и анализировать конкретную ошибку.
Лог находится по пути */app/asr_billing/var/log/nas_event_daemon/lifestream.log*

Во-первых можно попробовать воспроизвести ошибку: включите непрерывный мониторинг лога в одном терминале:
{code}tail -f /app/asr_billing/var/log/nas_event_daemon/lifestream.log{code}
И перезапустите сервер синхронизации в другом:
{code}chroot /app/asr_billing/ service oss restart{code}
Из полученного лога в первом терминале можно сделать какие-то выводы. Если происходит ошибка, в выводе можно будет увидеть команду которую выполнял биллинг и что получил в ответ. Например:
{code:title=Команда} result.request.method=GET
result.request.url=https://best_isp.proxy.lfstrm.tv/v2/accounts?page_size=50000&page=0
result.request.body=None {code}
{code:title=Ответ} result.status_code=500
result.content={"error": "argument of type 'NoneType' is not iterable"}{code}
Получив вывод лога и возникшую ошибку, Вы можете обратиться в Смотрёшку и уточнить почему API вернул ошибку.

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

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

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

Если ошибка повторяется для одног о и того же пользователя, посмотрите полный лог, например так:
{code}tail -n 100 /app/asr_billing/var/log/nas_event_daemon/lifestream.log{code}

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

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

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

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

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




Посмотреть список услуг создающих учетные записи и из префиксы можно через [конструктор отчетов|CarbonBilling:Конструктор отчетов] таким запросом:

{code}select id, name ,create_login, prefix_login from usluga where create_login=1{code}

h3. Сервер вернул ошибку: requirement failed: Service ID must be non-empty

{code}2019-12-09 00:01:47,894 - django - commands - ERROR - Сервер вернул ошибку: requirement failed: Service ID must be non-empty{code}
Проблема может возникнуть при интеграции [Megogo|CarbonBilling:Интеграция с Megogo], если:
* В какой-то из услуг с пакетами ТВ не указан параметр "Строка с дополнительными параметрами по активации"
* В какой-то из услуг с пакетами ТВ не указан параметр "Строка с дополнительными параметрами по деактивации"
* Подключена услуга создающая учетную запись и в ней тоже нет одного из указанных параметров

Посмотреть списки услуг создающих учетные записи и из префиксы можно через [конструктор отчетов|CarbonBilling:Конструктор отчетов] такими запросами:

{code:title=Услуги ТВ пакетов без параметров активаци/деактивации}select u.id,u.name from usluga u join nas n on u.nas_id=n.id join nas_scheme ns on n.nas_scheme_id=ns.id and ns.object_type_id=2 where u.deleted=0 and (u.activate_string='' or u.deactivate_string='') and u.create_login=0{code}

{code:title=Услуги MEGOGO создающие учетную запись}select u.id,u.name from usluga u join nas n on u.nas_id=n.id join nas_scheme ns on n.nas_scheme_id=ns.id and ns.object_type_id=2 where u.create_login=1 and ns.name='Megogo'{code}

h3. У абонента не настроен email
{code}2019-12-13 15:00:54,690 - django - commands - ERROR - У абонента не настроен email
2019-12-13 15:01:04,435 - django - commands - ERROR - У абонента не настроен email
2019-12-13 15:01:06,266 - django - commands - ERROR - У абонента не настроен email
{code}
Ошибка может возникнуть при [интеграции с сервисами IPTV|CarbonBilling:Интеграция сервисов интернет-телевидения], если абоненту подключили услугу, но у него нет адреса почты - как правило такие сервисы регистрируют абонента по адресу почты и/или номеру телефона.
В частности, адрес почты обязателен при [интеграции со Смотрёшкой|CarbonBilling:Интеграция с LifeStream (Смотрёшка, Смотрешка)].
Для решения проблемы выполните этот отчет в [конструкторе|CarbonBilling:Конструктор отчетов] и заполните у абонентов адреса почты, или отлючите у них услуги ТВ.
{code:title=Абоненты с услугами ТВ, но без адреса почты}select distinct a.contract_number,a.name from abonents a join users_usluga uu on a.id=uu.abonent_id join usluga u on uu.usluga_id=u.id join nas n on u.nas_id=n.id join nas_scheme ns on n.nas_scheme_id=ns.id and ns.object_type_id=2 where u.deleted=0 and uu.deleted=0 and a.deleted=0 and (a.email='' or a.email is null){code}

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

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

h3. Не удалось синхронизировать тех. группу: Ошибка при проверке номера
{code}2020-01-15 08:08:14,658 - django - authBackend - CRITICAL - Не удалось синхронизировать тех. группу: Ошибка при проверке номера: (0) Could not interpret numbers after plus-sign.{code}
Ошибка говорит о том, что в настройках [пользователей биллинга|CarbonBilling:Управление пользователями, интерфейс администратора. Авторизация.] некорректно указан номер смс для оповещения. Номер телефона должен удовлетворять формату E.164:+79123456789 или 89123456789.

h2. check_error_voip_radius.sh:
{code}- check_error_voip_radius.sh: ERROR(2) [FAILED]
http://docs.carbonsoft.ru/51019784#Системамониторинга-checkerrorpaysystems.sh {code}

Тетс Тест говорит о наличии ошибок синхронизации с сервисам [CarbonBilling:АТОЛ Онлайн].

Просмотреть чек по которому произошла ошибка можно следующим образом:
# Найдите ошибку в логе службы обработки платежей:
{code}
/app/asr_billing/mnt/log/paysystemsd.log
{code}
# Пример ошибки:
{code}
2019-10-03 03:51:03,015 - worker - paysystems_lib - INFO - Обрабатываем чек 1111111d-0acf-4cfd-ac16-e0215b098cf2 storno=False #13858
2019-10-03 03:51:03,402 - worker - paysystems_lib - ERROR - ERROR: Ошибка АТОЛ-Онлайн: [-3897] Не удалось выполнить операцию закрытия документа. Ответ от ККТ: [-3897] Описание: Чек оплачен не полностью. (id -no id-)
{code}
# Откройте чек в вэб интерфейсе биллинга. Здесь 1111111d-0acf-4cfd-ac16-e0215b098cf2 -- идентификатор действия со стороны атол-онлайн, #13858 -- номер финансовой операции в биллинге. Укажите его в ссылке на акт (Абонент->Операции->Операция->иконка с принтером):
{code}
http://<ip-биллинга>:8082/admin/FinanceOperations/print/13858/
{code}

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

В данном случае ошибка возникла из-за того что в карточке абонента не заведены "Email для оповещений" или "Номер SMS для оповещений".

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

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

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

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

Для ускорения применения настроек требуется выполнить следующую операцию:
{code}chroot /app/asr_billing/ python /usr/local/bin/get_fiscal_config.py{code}



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




h3. account_traf - Не найден абонент для N записей (некорректная настройка Collector)
{code}2019-02-22 08:38:02,458 - worker - account_traf - ERROR - Не найден абонент для 367 записей{code}
collector['api_ip']='192.168.8.71'
{code}
Так как коллектор и биллинг находятся на одном физическом сервере, просто в разных контейнерах, в настройках следует указывать локальынй локальный адрес биллинга 169.254.80.82. Приведите параметр к следуещему виду:
{code}collector['api_ip']='169.254.80.82'{code}
И перезапустите коллектор:
172.31.10.2{code}

h3. account_traf - Неизвестный трафик (NAS не опознал трафик)
{code}
2020-04-27 03:35:19,771 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 04:05:12,614 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 04:35:22,370 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 05:05:11,747 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 05:35:21,180 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 06:05:11,770 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 06:35:11,355 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 07:05:14,855 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
2020-04-27 07:35:08,466 - worker - account_traf - WARNING - Неизвестный трафик: user_id=-1, user_ip=0 (NAS не опознал трафик)
{code}
В данном случае NAS не смог распознать трафик и прислал трафик с IP адресом 0.0.0.0 Для начала убедимся, что действительно в collector приходит netflow поток с неверным IP адресом в содержимым:
# Включим повышенное логирование в контейнере collector:
{code}
mkdir -p /app/collector/cfg/etc/netflow_collector/
cp -p /app/collector/etc/netflow_collector/nf_collector.conf /app/collector/cfg/etc/netflow_collector/nf_collector.conf
sed 's|LOG_LEVEL=0|LOG_LEVEL=3|' -i /app/collector/cfg/etc/netflow_collector/nf_collector.conf
/app/collector/service restart
{code}
# Подождём 5 минут, чтобы накопились данные в логе.
# Проверим какие IP адреса не смог распознать collector. Мы видим в первой записи адрес 0.0.0.0
{code}
grep 'New entry for ip' /app/collector/var/log/nf_collector.log | awk '{print $12}' | sort -u | head -n 3
0.0.0.0
10.0.0.20
10.100.20.20
{code}
# Выключим расширенное логирование collector
{code}
rm -f /app/collector/cfg/etc/netflow_collector/nf_collector.conf
/app/collector/service restart
{code}

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

h3. account_voip - Проблема с межоператорским расчетом звонка VoipLog
{code}2019-04-04 16:27:42,794 - worker - account_voip - ERROR - Проблема с межоператорским расчетом звонка VoipLog [ id=805042, src=71111111111, dst=72222222222, s_time=2019-04-04 16:26:30, suid=CDR_SMG1016201904041626305842335, dst_chan=Provider2 ] Доступные операторы: Abonents [ id=1418, name=ООО "Лучший провайдер" ]{code}
Решение проблемы описано в статье "[CarbonBilling:FAQ по ошибкам телефонии]"

h3. account_voip - Вы используете deprecated настройки для парсера CDR / Для OSS схемы 250002 не настроен обработчик CDR
{code}2020-04-20 08:44:41,544 - worker - account_voip - WARNING - Вы используете deprecated настройки для парсера CDR.
2020-04-20 08:44:41,544 - worker - account_voip - ERROR - Для OSS схемы 250002 не настроен обработчик CDR{code}
Данная ошибка проявляется, когда в биллинге создан VOIP NAS, но не инициализирован и отсутствуют правила обработки CDR-файлов. Для решения проблемы, необходимо выполнить настройку по инструкции: "[CarbonBilling:Настройка парсинга CDR]":
# Инициалихируйте NAS
# Добавьте настройки CDR-парсера из статьи

h3. account_traf - Очень старая дата у трафика\!
{code}2019-08-28 12:41:40,184 - worker - account_traf - ERROR - Очень старая дата у трафика! Проверьте настройки NAS! Дата: 2010-10-24 02:43:35, User ID: 4769, NAS: 10.0.0.1{code}
{info}Чтобы посмотреть по какой учетной записи возникла проблема в интерфейсе биллинга, подставьте ID из ошибки в адресную строку.
*Пример*. Допусти Вы подключаетесь к биллингу по IP 192.168.0.10, ссылка на учетную запись ID 4769 будет такой: [http://192.168.0.10/admin/Users/4769]

{info}
Настройка netflow-потоков подробно описана в [статье|Настройка и проверка netflow-потоков]. Для того, что бы решить проблему выполните:
# Измените дату и время на NAS исходя из полученных данных.

h3. usluga_abon_pay - У абонента услуга из другого тарифа\!
{code}
2019-11-16 04:31:35,160 - worker - usluga_abon_pay - ERROR - У абонента #25262 услуга #51323 из другого тарифа!
2019-11-16 04:31:35,195 - worker - usluga_abon_pay - ERROR - У абонента #25306 услуга #51779 из другого тарифа!
2019-11-16 04:31:35,205 - worker - usluga_abon_pay - ERROR - У абонента #25429 услуга #54374 из другого тарифа!
2019-11-16 04:31:35,230 - worker - usluga_abon_pay - ERROR - У абонента #25447 услуга #54821 из другого тарифа!
2019-11-16 04:31:35,240 - worker - usluga_abon_pay - ERROR - У абонента #25457 услуга #55231 из другого тарифа!
{code}
Эта исключительная ситуация и прчину можно попробовать найти в аудите, исходя из даты когда последний раз меняли тариф: возможно в этот момент произошла ошибка транзакции.
Для исправления проблемы:
# Переключите абонента на временный тариф, потом верните нужный
# При необходимости сделайте абоненту перерасчет начиная с нужной даты

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

h2. test_free_space.sh

h3. check_free_fs_space failed
{code}- test_free_space.sh: ERROR(1) [FAILED]

2019-04-10 07:54:55 billing5_server test_free_space.sh[16503]: check_free_fs_space failed on /tmp used 96% when used_limit 85% and free 4741708 when free_limit 5000000
2019-04-10 07:54:55 billing5_server test_free_space.sh[16503]: Filesystem 1K-blocks Used Available Use% Mounted on - 10572056 2253400 7774964 23% /mnt/backup - 85501368 3777096 77374372 5% /mnt/db - 3964096 47108 3712292 2% /mnt/etc - 53396996 5200816 45477104 11% /mnt/log - 9947884 6264104 3171788 67% /mnt/shared - 106925104 96745248 4741700 96% /mnt/var
2019-04-10 07:54:55 billing5_server test_free_space.sh[16503]: ALARM Свободное место на диске заканчивается!

/usr/local/angel/test_free_space.sh ERROR(1)
Create_date: 2019-04-10 07:54:55{code}
Функция +check_free_fs_space+ проверяет наличие свободного места на разделах /var/db, /tmp/ (смонтирован на /mnt/var хост системы), /var/log внутри контейнера биллинга.
Если в описании заявки ошибка возникла в проверке "check_free_fs_space failed", используя утилиту *df \-h* проверьте на каком из разделов места недостаточно (занято более 85%).
Определив проблемный раздел, утилитой *du \-sch /mnt/var/\** Вы можете постепенно найти папку которая занимает более всего места.
Утилитами *rm*, и *mv* Вы можете удалить или перенести данные на другой раздел.

h3. check_db_space
{code}- test_free_space.sh: ERROR(1) [FAILED]

2019-04-10 10:04:24 localhost.localdomain test_free_space.sh[8221]: check_db_space /var/db/billing.gdb size is 1587576832 and on /var/db used 76%
2019-04-10 10:04:24 localhost.localdomain test_free_space.sh[8221]: TRIPLE_BILLING_DB_SIZE=6350307328; FREE_SPACE=6119776256
/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 - базы, поврежденные в результатате некорректного завершения работы сервера.
/app/asr_billing/var/log/radius/radius.log-20191104.gz{code}
Первый файл - актуальный лог
Второй - архивны, в нем информация от момета предыдущей архивации до 04 ноября 2019 года.

Чтобы найти причину, ориентируйтесь на время написанное при падении теста - в примере выше это "2017-03-21 14:48:52". Изучив лог за это время можно найти более подробную информацию о причине ошибки, вероятно она одна из описанных выше.
{code}chroot /app/asr_billing python /usr/local/angel/test_radius.py --debug{code}

h2. check_billing_radius_acc_netstat.sh

Для решения проблемы попробуйте перезапустить обработчик аккаунтинга RADIUS:
{code}chroot /app/asr_billing/ service radiusd_acc restart{code}

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


h2. test_daemons.sh

* На NAS-сервере включен протокол через который описано получение данных в *session* скрипте (в стандартных схемах это API для Mikrotik, ssh/telnet для Cisco и RedBack)

h3. В функции users_from_nas скрипта [session|Пользовательская custom схема] есть ошибка, в результате которой она завершается некорректно

Пример сообщений в логе:

h3. Удалены папки с работающими абонентами

Это могло произойти в старых версиях биллинга и при попытке закрыть период произойдет ошибка нарушения связей в базе данных.
Получить список не удаленных абонентов чьи папки в корзине можно через [конструктор отчетов|CarbonBilling:Конструктор отчетов]:
{code}select
ab2.id "ID папки", ab2.name "Название папки", ab.id "ID абонента", ab.name "Наименование/ФИО", ab.contract_number "Номер договора"
from abonents ab
left join abonents ab2 on ab.parent_id=ab2.id
where
ab2.deleted=1 and (ab.deleted is null or ab.deleted=0) and ab2.id<>4{code}

{code}

Для исправления иошибки необходимо восстановить стандартный конфигурационный файл httpd.conf , для этого нужно:
# Зайти в chroot asr_cabinet:
{code}
{code}

h1. Тесты asr_fiscal

h2. check_fiscal_httpd_netstat.sh

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

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

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

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

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

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

h4. Проблема с /proc

Проверьте, подключен ли /proc:
{code:title=Команда}mount | grep fiscal/proc{code}
{code:title=Вывод}none on /app/asr_fiscal/proc type proc (rw){code}
Такой вывод говорит о том, что подключен. Если вывод другой или его вообще не было - ещё раз убедитесь что ФС не смонтирована:
{code:title=Команда}ls -l /app/asr_fiscal/proc/{code}
{code:title=Вывод}total 0{code}
В папке /proc пусто, а должно быть большое количество папок и файлов.

Если Вы столкнулись с такой проблемой, вероятно произошла какая-то ошибка при старте системы. Перезапустит контейнер чтобы её исправить:
{code:title=Команда}/app/asr_fiscal/service stop && /app/asr_fiscal/service destroy && /app/asr_fiscal/service build && /app/asr_fiscal/service start{code}

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

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

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

{code:title=Посмотреть какая программа заняла порт}netstat -nlp | grep 1444{code}
{code:title=Посмотреть PID этой программы и записать в переменную "pid" (потребуется дальше)}pid=$(netstat -nlp | grep 1444 | awk '$7{print $7}' | cut -d'/' -f 1) && echo $pid{code}
{code:title=Путь до исполняемого файла программы занявшей порт платежных систем}ls -l /proc/$pid/exe{code}
{code:title=Файлы и сокеты открытые этой программой}ls -l /proc/$pid/fd/{code}
{code:title=Посмотреть информацию по программе в дереве процессов. "-C2" оставлено на случай если программа была вызвана из другой программы или сама запустила "потомков"}ps auxf | grep -E 'START|8673.*' -C2{code}

h2. check_fiscal_httpd_ssl_netstat.sh

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

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

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

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

h1. Тесты collector

h2. check_nf_collector_listen.sh

{code}
Netflow Collector не запущен
Останавливается Netflow collector: [СБОЙ ]
nf_collector disabled in /cfg/config
is stopped

/usr/local/angel/check_nf_collector_listen.sh ERROR(2)
Create_date: 2020-05-16 22:40:10
{code}

Тест проверят запущена ли служба [nf_collector|Collector#NetflowCollector]
Обычно ошибка возникает, если на разделе со статистикой кончилось [место|#check_disk_space_stat.sh]. Сбор статистики был остановлен.
{warning}
Если служба сбора статистики выключена, биллинг не сможет считать объём трафика.
{warning}

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

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

h2. check_critical_traf_reporter.sh
{code}- check_check_critical_traf_reporter.sh: ERROR(1) [СБОЙ ]




h2. check_bstat_check_raw_stat.sh
{code} Отсутствует сырая статистика
{code}

h3. Включена устаревшая функция: "Сохранять сырую статистику"

В прошлом (еще до [появления nfsen в поставке|CarbonBilling:nfsen]) мы добавили функцию сбора сырой статисти для дальнейшего анализа Nfsen. Идея была в том чтобы собирать её для диагностики, если есть подозрения что [детальная статистика в биллинге|CarbonBilling:bstatd] работает некорректно.
Подразумевается, что такая сырая статистика собиралась бы короткий промежуток времени, анализировалась и вручную удалялась.
Если на Вашем сервере сбор включен и с собранными файлами ни чего не делать, то через какое-то время сработает тест *check_bstat_many_raw.sh*.

Определить, в этом проблема или нет, и решить её можно так:
# Посмотрите, есть ли файлы сырой статистики для nfsen:
{code:title=Команда}find /app/collector/var/stat/raw/ -iname 'rawnetflow*' | wc -l{code}
{code:title=Пример вывода когда есть файлы статистики}194{code}
# Если вывод будет больше ноля, как в примере выше, рекомендуем отключить опцию и удалить собранную статистику.
# Отключить можно в настройках [служб сбора статистики|CarbonBilling:Описание работы служб сбора статистики], на вкладке "*Настhойки сохранения сырой статистики*", опция "*Сохранять сырую статистику*"
# Удалить уже собранную статистику можно такой командой:
{code}find /app/collector/var/stat/raw/ -iname 'rawnetflow*' -delete{code}

h2. check_disk_space_stat.sh
{code}- check_disk_space_stat.sh: ERROR(2) [FAILED]
http://docs.carbonsoft.ru/51019784#Системамониторинга-checkdiskspacestat.sh
df: Warning: cannot read table of mounted file systems: No such file or directory{code}
Ошибка говорит о том, что у Вас недостаточно места для хранения [детальной статистики|CarbonBilling:Описание работы служб сбора статистики].
Для решения проблемы удалите часть архива или подключите более объемный диск по статье "[CarbonBilling:Добавление диска под статистику]"

Тест начинает сообщать о проблеме когда на разделе со статистикой остаётся меньше чем:
* На 7 дней. Объём статистики за 7 дней вычисляется исходя из архива предыдущих месяцев - тест ищет в каком периоде было больше всего статстики, делить объём на 30 и умножает на 7.
* На 7 дней
* 14Гб

{info}Объём статистики за 7 дней вычисляется исходя из архива предыдущих месяцев - тест ищет в каком периоде было больше всего статстики, делить объём на 30 и умножает на 7.{info}
{note}Рекомендуемый объём диска *1ТБ*, диска меньшего объёма скорей всего надолго не хватит.{note}
{warning}Если служба сбора статистики выключена, биллинг не сможет считать объём трафика. После очистки места на диске включите службу по статье: [nf_collector|Collector#NetflowCollector].{warning}

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

# Освободите место, чем больше - тем лучше, *свободным должно быть хотя бы 200Гб*
# После очистки места на диске включите службу:
## В файле */app/collector/cfg/config* поменяйте значение опции *app\['nf_collector.enabled'\]* на 1, должно получиться так:
{code:title=Команда}grep nf_collector\.enabled /app/collector/cfg/config | grep -v widget{code}
{code:title=Вывод}app['nf_collector.enabled']='1'{code}
## И перезапустите коллектор трафика:
{code:title=Команда}
chroot /app/collector/ service nf_collector restart
{code}
{code:title=Вывод}
Stopping Netflow collector: [FAILED]
Starting Netflow collector: [ OK ]
{code}

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

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

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

{code}
chroot /app/collector/
service bstatd restart
{code}

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

h1. Тесты xge

0
{code}

h3 Решение

В выводе: количество занятых классов, далее количество свободных. Как видно из примера, свободных более нет. Для решения проблемы следует запустить скрипт, удаляющий лишние локи:
{code}chroot /app/xge fix_locked_shapers.sh{code}
Если после выполнения скрипта абоненты будут жаловаться на наличие проблем со скоростью, перезапустите XGE
{code}/app/xge/service restart{code}
{note}Файлы классов создаются при первой установке абоненту тарифа ограничением скорости. При свежей установке, создайте такой тариф и назначьте его абоненту чтобы не возникала ошибка теста. В случае, если они не создались после установки тарифа, выполните следующую команду:
{code}for shaperid in `seq 2000 8998`; do touch /app/xge/var/lib/xge_shapers/free/$shaperid; done{code}{note}

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

Файлы классов создаются при первой установке абоненту тарифа ограничением скорости. При свежей установке, создайте такой тариф и назначьте его абоненту чтобы не возникала ошибка теста. В случае, если они не создались после установки тарифа, выполните следующую команду:
{code}for shaperid in `seq 2000 8998`; do touch /app/xge/var/lib/xge_shapers/free/$shaperid; done{code}

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

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

# [Включите синхронизацию со стороны XGE|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=38961204#НастройкасвязкисCarbonBilling5-Синхронизациясбиллингом]
# Сбросьте все сессии абонентов на XGE
{code}chroot /app/xge
for sessions in $(xgesh session dump | awk '{print $1}'); do xgesh session $sessions remove; done{code}
# Дождитесь синхронизации или запустите её вручную:
{code}chroot /app/xge/ xge_sync{code}

h2. check_vm.sh





h2. check_xge_httpd_redirect_netstat.sh

Если IP-адрес отличается от указанного выше, необходимо заменить его на 169.254.80.90 и перезапустить контейнер XGE.

h2. check_xge_shapers.sh

Сообщение

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

Данная ошибка может возникать в том случае, если сервер загрузился с некорректным ядром. Посмотреть, с каким ядром загружен сервер, можно с помощью команды uname \-a:
{code:title=Команда} uname -a{code}
{code:title=Вывод}Linux localhost_localdomain 2.6.32-754.28.1.el6.x86_64 #1 SMP Wed Mar 11 18:38:45 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux {code}
Для корректной работы шейперов сервер должен быть загружен с одним из следующих ядер:
* Linux-carbon-master
* Linux-carbon-johnik_xge
* Linux-carbon-devel
* Linux-carbon-754

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

< 221 Goodbye.^M
* Closing connection #0{code}
Ошибка 452 говорит о том, тчо что закончилось свободное место на фтп-сервере.

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





h2. ALARM Мало свободного места на диске\!

Ошибка возникает если на одном из разделов занято *более 85%* пространства.

h3. Диагностика в командной строке:
Решение подобных проблем довольно обширная тема, поэтоу мы вынесли её в отдельную статью [CarbonBilling:Мало места на диске]

1. Проверям какой раздел заполнен:
{code}
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 3,7G 1,9G 1,6G 55% /
/dev/sda2 14G 6,7G 6,3G 52% /app
/dev/sda3 13G 1,4G 11G 12% /mnt/backup
/dev/sda4 1,9G 36M 1,7G 3% /mnt/etc
/dev/sda5 53G 47,2G 5.8G 89% /mnt/var
/dev/sda6 8,2G 4,3G 3,6G 55% /mnt/log
/dev/sdb1 394G 140G 234G 38% /mnt/stat
/dev/sdb1 394G 140G 234G 38% /app/collector/mnt/var/stat
{code}

Видно, что заполнен раздел /dev/sda5 с логами.
{code}
/dev/sda5 53G 47,2G 5.8G 89% /mnt/var
{code}

2. Теперь нужно узнать какие именно данные занимают раздел. Запускаем комманду подсчёта объёма и двигаемся вглубь файловой системы.
{code}
du -sh /mnt/log/*
{code}

3. После того как найдены данные, которые зинимаю диск, их необходимо перенести на другой носитель. Или подключить дополнительный диск для их хранения. Для раздела с логами это можно сделать по [инструкции|CarbonBilling:Добавление диска под логи].

{info}
В данном примере рассмотрено заполение раздела с логами. Удалить старые логи можно по [статье|Переполнение разделов диска логами].
{info}

h2. ALARM app заблокирован в течении минут

Тест реагирует на проблему некорректого распределения обработки прерываний по ядрам процессора, вероятней всего на Вашем сервере этим занимается только одно ядро.
Диагностика и решение подробно описаны в документации по Carbon Reductor X, так же построенного на платформе Carbon: [REDUCTOR9:Потери на сетевых картах, задержки в обработке и как с ними бороться]
Быстрое решить проблему можно попытавшись запустив утилиту автоматического рапределения прерываний вызываемых обработкой сетевого карта по всем используемым сетевым интерфейсам, например:
Быстро решить проблему можно, попытавшись запустить утилиту автоматического рапределения прерываний, вызываемых обработкой сетевого трафика по всем используемым сетевым интерфейсам, например:
{code}rss-ladder eth0{code}
Если это исправит проблему, не зуабудьте добавить автоматический вызовы настройки в [хук|xge:Дополнительные настройки. hooks. Хуки] XGE
{info}Проблема актуальна для продуктов Reductor, XGE и Softrouter. Если она произошла на Billing или Billing_Slave, обязательно обратитесь в техподдержку{info}

h2. ALARM Обнаружен другой работающий watchdog

На сервере работает [система мониторинга|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=51019784#Системамониторинга-Системамониторинга], каждые 10 минут она запускает набор автоматических тестов, если в работе подсистем продукта (Биллинга, маршрутизатора XGE, Редуктора и тд) обнаружены ошибки - отправляет сообщение администратору на почту и создаёт заявку в портале HelpDesk.

В исключительных случаях может случиться так, что очередной запуск тестов не уложится в 10 минут и следующая итерация не сможет начаться, в место этого будет создана заявка о возникшей проблеме.

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

Лог системы мониторинга:

* Тесты запускаемые раз в 10 минут
{code}/app/base/var/log/watchdog.log{code}
* Тесты запускаемые раз в 6 часов, обычно некритичные
{code}/app/base/var/log/monitoring.log{code}

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

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

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

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

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

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

{code} /etc/init.d/kdump status {code}

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

{code} Kdump is unsupported on this kernel {code}

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


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

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

В некоторых случаях ядро не может само выделить память. Проверяем загрузочный вывод ядра:
{code} grep crash /var/log/dmesg {code}
Появится строка "Reserving xxxMB of memory at ... for crashkernel"

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


h2. WARNING Не доступны DNS серверы
{code}- check_dns.sh: ERROR(2) [FAILED]
Скрипт из примера установит timeout=2 в конфигурационных файлах всех контейнеров.

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

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

Данный тест проверяет следующие параметры:
1. Какое ограничение по размеру применяется к файлу дампа (core file size значение unlimited) (carbon_limits.d). Информацию об этом можно посмотреть с помощью команды:
{code}ulimit -a | grep 'core file size'{code}
2. Соответствие имени файла дампа указанному шаблону "/tmp/cores/core.%e.%p.%h.%t" (sysctl kernel.core_pattern) (carbon_sysctl.d). Текущие настройки можно проверить:
{code}sysctl -a | grep 'kernel.core_pattern'{code}




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