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

Skip to end of metadata
Go to start of metadata
Вы просматриваете старую версию данной страницы. Смотрите текущую версию. Сравнить с текущим  |   просмотр истории страницы

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

На платформе Carbon PL5 существует система автоматического тестирования, запускающая тесты всех контейнеров раз в 10 минут. При возникновении ошибки по любому из тестов, создаётся заявка в портале HelpDesk. Помимо тестов server_check существуют так же тест выгрузки резервных копий на FTP и тест на наличие UPS. Также каждые 6 часов, в 5-ю минуту запускается тест monitoring, который запускает проверку всех контейнеров биллинга.

Запуск проверки вручную

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

Диагностика в командной строке

1. При каких либо сбоях требуется проверить состояние сервера и работу всех служб. Делается это командой 

server_check

В ответ будет выведено состояние всех служб биллинга. Все службы должны иметь состояние [ OK ]. Если где-то есть сбой, то при обращении в поддержку укажите сбойную службу.

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

cat /app/asr_billing/var/log/firebird/firebird.log

В выводе особое внимание обратить на строки содержащие примерно такие блоки текста

2.1. Повреждена целостность БД, серьезный сбой. Вероятно потребуется восстановление из бекапа:

Database: /mnt/var/db/billing.gdb
database file appears corrupt (/mnt/var/db/billing.gdb)
wrong page type
page 1647 is of wrong type (expected 7, found 5)
internal gds software consistency check (error during savepoint backout (290), file: exe.cpp line: 4026)

2.2. Биллинг не может найти БД, вероятно биллинг в safemode:

Database: /mnt/var/db/billing.gdb
I/O error for file "/mnt/var/db/billing.gdb"
Error while trying to read from file
No such file or directory

2.3. Отдельная запись в таблице помечена как поврежденная:

Database: /mnt/var/db/billing.process.gdb.13836
Record 1002 is marked as damaged in table RDB$RELATIONS (6)

Тесты base

check_free_inodes.sh

- check_free_inodes.sh:  ERROR(254)                        [FAILED]

    /dev/md5             9125888 8581637  544251   95% /mnt/var
    ALARM Мало свободных inode

    ALARM На одном из устройств осталось мало свободных inode. Возможно какая-то папка забита большим количеством файлов

Ошибка говорит о том, что на одном из дисков слишком много файлов, в результате чего переполнена база файловой системы (inodes).
Для решения проблемы попробуйте перезагрузить сервер - возможно какой-то процесс создал много файлов, удалил, но до сих пор держит их в памяти.
Если перезагрузка не решила проблему, необходимо опеределить где слишком много файлов и удалить лишнее.
Воспользуйтесь утилитой tree, запустив её на указанный раздел:

tree /mnt/var/ | tail -n 1

Вывод будет преблизительно следующим:

39143 directories, 8730047 files

После чего нужно посмотреть сколько занято подпапками:

find /mnt/var -maxdepth 1 -type d | grep -v /$ | while read path; do echo $path; tree $path | tail -n 1; done

И так постепенно можно найти папки в которых находится более всего файлов. Что делать с файлами зависит от конкретной ситуации.
Если лишних файлов не оказалось, - их просто много -, возможно стоит пересоздать файловую систему, зарезервировав под БД файлов больший процент раздела передав команде mkfs параметр -N.
Возможно получится увеличить число inode без пересоздания утилитой tune2fs с ключем -m
Как временно перерести данные Вы можете узнать в разделе "Замена оборудования". Полную информацию по параметрам утилит mkfs и tune2fs Вы можете найти в их справочном руководстве: man mkfs.ext4, man tune2fs

Возмжно предварительно потребуется установить команду man:
yum install -y man

check_apps_not_destroyed.sh

- check_apps_not_destroyed.sh:  ERROR(2)                   [FAILED]

    ALARM Некорректное состояние аппов
    Обнаружены следующие аппы в состоянии destroy, которые должны быть включены:
    	 collector
    Требуется перезапустить их с помощью /etc/init.d/apps restart

Ошибка говорит о том, что какая-то из подсистем (контейнеров) платформы Carbon остановлена и "разрушена" - под этим понимается что контейнер остановлен и все точки монтирования внутри контейнера размонтированы.
Возможные причины:

  • Ведутся сервисные работы, изменяется конфигурация (например добавляются диски для расширения пространства под какие-либо данные) контейнера
  • При "сборе" контейнера произошла ошибка и какие-то разделы внутри него сервисный скрипт не смог замонтировать
  • Произошла какая-либо иная ошибка при старте системы, из-за которой работа сервисного скрипта запускающего платформу Carbon завершилась некорректно (например, если на диске были обнаружены ошибки и системная утилита mount не смогла собрать контейнер)

Для отладки в первую очередь можно попробовать запустить команду build:

/app/collector/service build

И посмотреть каким будет вывод, исходя из этого пути решения могут быть разными. Ниже рассмотрены возможные проблемы.

Ведутся сервисные работы

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

Ошибка при "сборе конрейнера

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

[root@Billing5 ~]# grep collector /var/log/apps.log  | tail -n 2
Sat Mar 23 17:06:56 +08 2019 collector stop STOPPING
Sat Mar 23 17:07:01 +08 2019 collector stop OK

По данному времени попробуйте найти информацию в логах загрузки (сохраняются в папке /var/log/boot/) и в системном логе */var/log/messages и архивных логах:

cat /var/log/messages*

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

Ошибка монтирования

/app/collector build
mount: no such partition found

# /app/collector/service build:                            [FAILED]

В конфигурационном файле collector настроено сохранение детальной статистики на отдельный диск:

# grep mount /app/collector/cfg/config
declare -A mount
mount['1statfs']='-U a7a26c14-e788-40a0-b0f9-f051be5c9e61 /app/collector/var/stat'
mount['2statfsnfsen']='--bind /app/collector/var/stat/nfsen_stat /app/collector/var/nfsen_stat'
mount['3statfsncapdndump']='--bind /app/collector/var/stat/nfcapd_dump /app/collector/var/nfcapd_dump'
mount['proc']='-t proc none /proc'

Но раздела с ID a7a26c14-e788-40a0-b0f9-f051be5c9e61 нет в системе:

[root@st-rline ~]# blkid | grep a7a26c14-e788-40a0-b0f9-f051be5c9e61 -c
0

Весьма вероятно что конфигурационный файл перенесли с другого сервера, но диск на который ранее сохранялась статистика не подключили. Вариантов решения несколько:

  1. Выключите сервер, подключите диск, включите сервер
  2. Настройте сохранение на другой выделенный диск или раздел
  3. Уберите настройку выделенного раздела из конфигурационного файла

Тесты asr_billing

check_billing_db_size.sh

- check_billing_db_size.sh:  ERROR(1)                      [СБОЙ ]

    2017-03-03 13:38:47 Чрезмерно большая база данных биллинга

2017-03-03 13:38:47: /usr/local/monitoring/check_billing_db_size.sh ERROR(1): 2017-03-03 13:38:47 Чрезмерно большая база данных биллинга

Ошибка происходит при увеличении размера БД до 10Гб. Почему так происходит, описано в справочной документации firebird.
Со временем база может достичь данного размера по той простой причине, что место на диске не очищается при удалении записей из базы данных, так как это создаст лишнюю постоянную нагрузку на диск и ОЗУ. Записи в БД добавляются постоянно - любые события, происходящие с абонентами, их лицевыми считами, оборудованием, добавляются в стэк событий, обрабатываются воркером, после чего очищаются.
Для решения проблемы Вам необходимо создать бэкап, после чего восстановиться с него же.

check_critical_jobs.sh

- check_critical_jobs.sh:  ERROR(2)                        [СБОЙ ]

    ALARM Имеются критические ошибки в логе jobs_daemon за последний час: 5690

Тест сообщает что при выполнении запланированных задач произошла ошибка. Посмотрел описание ошибки можно в логе службы:

grep CRITICAL /app/asr_billing//var/log/jobs_daemon.log | cut -d' ' -f 8-100 | sort | uniq
CRITICAL - Не удалось выполнить отложенную задачу id=18 абонента Тестовый:Traceback (most recent call last):
CRITICAL - Ошибка выполнения команды python2.7 /usr/lib/python2.7/site-packages/jobs_worker/jobs_scripts/make_reports.pyc  abonent_id=812

В данном случае ошибка возникла из-за некорректного заполнения параметров запланированной задачи на выполнение отчета - не указан ID отчета.
Путей решения задачи два:

  • Исправить параметры, указав верные
  • Удалить запланированную задачу

check_events_stack_compact_count.sh

- check_events_stack_compact_count.sh:  ERROR(1)                   [СБОЙ ]

Возникает при количестве событий больше 100000 в таблице events_stack_compact. В таблице events_stack_compact собираются события, связанные с отправкой команд на оборудование, но ещё не обработанные биллингом. Примеры состояния абонента и событий которые отправляются на оборудование после их обработки Вы можете посмотреть по [ссылке].
Большое количество событий в таблице events_stack_compact может быть вызвано возрошей нагрузкой на биллинг. Например массовая авторизация абонентов при перезагрузке оборудования. При этом имеется проблема производительности сервера биллинга, в следтвии которой события не могут быть оперативно обработаны. Наблюдать за количеством событий можно с помощю следующего запроса.

# sqlexec "select count(*) from events_stack_compact"

       COUNT
============
      110249

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

check_events_stack_count.sh

- check_events_stack_count.sh:  ERROR(1)                   [СБОЙ ]

    2017-03-07 07:32:18 Очень большое количество команд в event_stack

В таблице events_stack собираются события для отправки на оборудования. Большое количество событий связано как правило с проблемами доступа на оборудование (nas недоступен, сменились какие-то параметры вроде логина/пароля/ip, оборудование не принимает CoA и тд). Так же, возможно, что проблема в медленном ответе биллингу от НАСа, так как команды отправляются в заданное количество потоков (по-умолчанию, 1) и каждая следующая выполняется только после ответа от сервера. Убедитесь, что нагрузка процессора и канала на NAS в норме.
Узнать количество скопившихся событий можно выполнив запрос к БД

# sqlexec "select count(*) from events_stack"

       COUNT
============
      122837 

check_events_stack.py

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

check_error_oss.sh

Тетс говорит о наличии ошибок синхронизации с сервисами IPTV:

- check_error_oss.sh:  ERROR(2)                            [FAILED]

    WARNING Ошибки при синхронизации оборудования
    Не удалось выполнить синхронизацию команд с оборудованием OSS
    За последний час CRITICAL: 6
    За последний час ERROR: 0
    Подробности в логе службы /app/asr_billing//var/log/oss.log
    2019-05-07 10:01:00,717 1690 nas_event_daemon/lifestream CRITICAL Невозможно получить пользователей, т.к. не найден NAS
    2019-05-07 10:10:59,813 - worker - v1 - CRITICAL - Невозможно получить пользователей, т.к. не найден NAS
    2019-05-07 10:10:59,813 14711 nas_event_daemon/lifestream CRITICAL Невозможно получить пользователей, т.к. не найден NAS
    2019-05-07 10:19:37,027 - worker - v1 - CRITICAL - Невозможно получить пользователей, т.к. не найден NAS
    2019-05-07 10:19:37,027 25021 nas_event_daemon/lifestream CRITICAL Невозможно получить пользователей, т.к. не найден NAS
    Для решения проблемы воспользуйтесь статьёй:
    http://docs.carbonsoft.ru/51019784#Системамониторинга-checkerroross.sh

Все возникшие проблемы можно увидеть в логе /app/asr_billing//var/log/oss.log.
Ошибки синхронизации могут возникнуть как со стороны Carbon Billing 5, так и со стороны сервиса телевидения. Необходимые действия для их устранения необходимо определить исходя из сообщений в логе.

Не найден NAS

2019-05-07 10:01:00,717 1690 nas_event_daemon/lifestream CRITICAL Невозможно получить пользователей, т.к. не найден NAS

В хранилище OSS схем (/app/asr_billing/var/oss/core) существует папка с OSS-схемой IPTV, при этом сам NAS не заведён в биллинге.
Для решения проблемы заведите NAS в ббиллинге или удалите OSS директорию.

Сервер ответил ошибкой

2019-05-07 10:04:37,126 15643 iptvportal_package.commands ERROR Сервер ответил ошибкой: {u'error': {u'message': u'null value in column "password" violates not-null constraint\nDETAIL:  Failing row contains (1234567, null, null, null, null, null, 78, 12345678, null, f, null, null, 1, 2019-05-06 15:33:51.876434+03, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null).\n'}, u'id': 111, u'method': u'update'}, Url: https://admin.provider.iptvportal.ru/api/jsonsql/, Запрос: {"params": {"table": "subscriber", "set": {"password": null}, "where": {"eq": ["username", "12345678"]}, "returning": "id"}, "jsonrpc": "2.0", "id": 111, "method": "update"}, Авторизация: {'Iptvportal-Authorization': u'sessionid=kjdiv32ur9fksffopsdkfmv34k9r0efc'}

При обращении к API портала телевидения возникла ошибка из-за структуры запроса или данных переданных в запросе.
Как правило сервисы возвращают текст ошибки, в указанном примере это параметр message:

null value in column "password" violates not-null constraint

При изменении параметров учетной записе на портале телевидения, не был передан пароль - именно об этом говориться в сообщении об ошибке.
Исходя из полученной информации, можно попробовать решить проблему:

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

check_error_django.sh

- check_error_django.sh:  ERROR(2)                         [СБОЙ ]

    WARNING Имеются ошибки в логе /var/log/django/error.log за последний час: 1

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

  • 2018-11-15 20:45:08,307 - django - handlers - ERROR - Exeption:'NoneType' object has no attribute '__getitem__' 'NoneType' object has no attribute '__getitem__'
    2018-11-15 20:45:08,307 - django - handlers - ERROR - 'NoneType' object has no attribute '__getitem__' 'NoneType' object has no attribute '__getitem__'
    2018-11-15 20:45:08,307 - django - handlers - ERROR - traceback: ['Traceback (most recent call last):\n', '  File "//usr/local/www/sites/admin/api/handlers.py", line 353, in get\n', '  File "//usr/local/www/sites/admin/api/handlers.py", line 399, in web_api_get\n', '  File "//usr/local/www/sites/admin/api/handlers.py", line 368, in process_method\n', "TypeError: 'NoneType' object has no attribute '__getitem__'\n"]

    Ошибка функции web_api_get говорит о том, что скорей всего проблема в выполняемых к биллингу API-запросах. Отладить это можно по статье API REST v2.0, раздел "Отладка"

check_error_worker.sh

- check_error_worker.sh:  ERROR(2)                         [СБОЙ ]

    ALARM Имеются ошибки в логе worker за последний час: 57

2019-02-22 08:38:32: pl5monitoring ALARM Имеются ошибки в логе worker за последний час: 57

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

grep ERR /app/asr_billing/var/log/worker.log

Ниже приведены кейсы решения некоторых возможных ошибок.

account_traf - Не найден абонент для N записей (некорректная настройка Collector)

2019-02-22 08:38:02,458 - worker - account_traf - ERROR - Не найден абонент для 367 записей

Ошибка говорит о том, что [обработчик абонентов] не смог соотнести с каким-либо абонетом часть данных пришедших от коллектора аккаунтинга интернет-трафика
Это может произойти, если список с учетными записями и их IP-адресами на стороне коллектора устарел, вероятней всего по какой-то причине он не смог его синхронизировать (синхронизация проходит каждые 30 секунд).
В первую очередь стоит посмотреть лог синхронизатора:

# egrep -i 'CRIT|ERR' /app/collector/var/log/sync_billing.log | head -n 2
2019-02-08 03:48:50,602 - CRITICAL - Не удалось выполнить api запрос: http://192.168.8.71:8082/system_api/?arg1=%7B%7D&model=Collector&psw=3ln8bshn&context=collector&method1=collector_manager.collector_get_checked_ip_pools&format=json.
 Error: <urlopen error [Errno 101] Network is unreachable>

Список не обновился потому что в настройках коллектора указан неверный IP-адрес биллинга:

# grep api_ip /app/collector/cfg/config
collector['api_ip.widget']='inputbox "IP адрес для доступа к API биллинга" "IP адрес для доступа к API биллинга"'
collector['api_ip']='192.168.8.71'

Так как коллектор и биллинг находятся на одном физическом сервере, просто в разных контейнерах, в настройках следует указывать локальынй адрес биллинга 169.254.80.82. Приведите параметр к следуещему виду:

collector['api_ip']='169.254.80.82'

И перезапустите коллектор:

/app/collector/service restart

account_traf - Не найден абонент для N записей (аккаунтинг по неизвестным биллингу IP-адресам)

2019-02-26 09:00:51,620 - worker - account_traf - ERROR - Bad traffic row ID=3408858 IP=10.24.240.1
2019-02-26 09:00:51,621 - worker - account_traf - ERROR - Bad traffic row ID=3408857 IP=10.24.240.1
2019-02-26 09:05:48,390 - worker - account_traf - ERROR - Не найден абонент для 4 записей
2019-02-26 09:05:48,392 - worker - account_traf - ERROR - Bad traffic row ID=3409307 IP=172.31.10.2
2019-02-26 09:05:48,392 - worker - account_traf - ERROR - Bad traffic row ID=3409350 IP=192.168.0.110
2019-02-26 09:05:48,393 - worker - account_traf - ERROR - Bad traffic row ID=3409361 IP=172.31.10.1
2019-02-26 09:05:48,393 - worker - account_traf - ERROR - Bad traffic row ID=3409306 IP=172.31.10.2
2019-02-26 09:15:40,475 - worker - account_traf - ERROR - Не найден абонент для 2 записей
2019-02-26 09:15:40,477 - worker - account_traf - ERROR - Bad traffic row ID=3410341 IP=192.168.0.100
2019-02-26 09:15:40,477 - worker - account_traf - ERROR - Bad traffic row ID=3410342 IP=192.168.0.100

В случае если у Вас возникает ошибка аккаунтинга интернет-трафика, при этом в логе Вы видите записи "Bad traffic row", но нет ошибки синхронизации Collector, как в выше приведенном кейсе, вероятней всего проблема в том, что аккаунтинг (netflow) приходит по IP-адресам находящимся в Вашей сети, но не заведенным в биллинг.
Для решения проблемы ограничте набор интерфейсов с которых собирается netflow и разместите хосты вызывающие ошибку за другими интерфейсами BRAS. В случае если это сделать не возможно, например если Ваше оборудование не имеет такой настройки netflow-сенсора или это нарушит структуру сети, назначьте данные адреса учетным записям в биллинге, Вы можете использовать для этого одного абонента назвав его "Служебный трафик" или завести для каждого хоста своего абонента.
Получить список адресов вызывающих ошибку Вы можете следующей командой:

grep 'Bad traffic row ID' /app/asr_billing/var/log/worker.log | awk '{print $14}' | sed 's/IP=//g' | sort | uniq

Примерный результат:

10.24.240.1
172.16.5.148
172.31.10.1
172.31.10.2

account_voip - Проблема с межоператорским расчетом звонка VoipLog

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=ООО "Лучший провайдер" ]

Решение проблемы описано в статье "FAQ по ошибкам телефонии"

account_traf - Очень старая дата у трафика!

2019-05-26 18:04:18,641 - worker - account_traf - ERROR - Очень старая дата у трафика! Проверьте настройки NAS! 2019-04-18 09:50:22

Проблема вызвана тем, что в потоке netflow дата и время трафика отличаются от установленных на биллинге. Настройка netflow-потоков подробно описана в статье. Для того, что бы решить проблему выполните:

  1. Установите утилиту tshark;
    yum -y install wireshark
  2. Запустите захват пакетов. В примере произведён захват по стандартному порту netflow 9996, на всех интерфейсах;
    tshark -pni any port 9996 -V -c 3 | grep -C 1 Timestamp

    Вывод будет выглядеть следующим образом:

    tshark -pni any port 9996 -V -c 3 | grep -C 1 Timestamp
    Running as user "root" and group "root". This could be dangerous.
    Capturing on Pseudo-device that captures on all interfaces
        SysUptime: 1968550053
        Timestamp: May 29, 2019 14:03:54.000000000 IRKT
            CurrentSecs: 1559109834
    --
        SysUptime: 1968550053
        Timestamp: May 29, 2019 14:03:54.000000000 IRKT
            CurrentSecs: 1559109834
    --
        SysUptime: 1968550053
        Timestamp: May 29, 2019 14:03:54.000000000 IRKT
            CurrentSecs: 1559109834
    3 packets captured

    Нас интересует значение поля Timestamp.

  3. Посмотрите дату и время установленные на биллинге:
    date
    

    Видим, что время отличается на два часа:

    date
    Срд Май 29 16:05:03 IRKT 2019
    
  4. Измените дату и время на NAS исходя из полученных данных.

test_httpd.sh

- test_httpd.sh:  ERROR(2)                                 [FAILED]

    ALARM Недоступен веб-интерфейс биллинга
    Для решения проблемы воспользуйтесь статьёй:
    http://docs.carbonsoft.ru/51019784#Системамониторинга-testhttpd.sh
    Stopping Admin Web Server: Starting Admin Web Server:  [  OK  ]
    Stopping nginx:                                        [FAILED]
    Starting nginx:                                        [  OK  ]
    Исправить проблему автоматически не удалось.

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

/app/asr_billing/var/log/nginx/error.log
/app/asr_billing/var/log/nginx/access.log
/app/asr_billing/var/log/admin_web_server.log

По-умолчанию веб-сервер использует порты 8082 (http) и 8382 (https).
Убедитесь, что в конфигурационном файле /app/asr_billing/cfg/config заданы сделующие параметры:

app['apache.port']='8082'
app['apache.ip']='169.254.80.82'
app['apache.sslport']='8382'
app['apache.sslip']='169.254.83.82'

test_free_space.sh

check_free_fs_space failed

- 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

Функция 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 Вы можете удалить или перенести данные на другой раздел.

check_db_space

- test_free_space.sh:  ERROR(1)                            [FAILED]

    2019-04-10 10:04:24 localhost.localdomain test_free_space.sh[8221]: check_db_space /var/db/billing.gdb size is 1587576832 and on /var/db used 76%
    2019-04-10 10:04:24 localhost.localdomain test_free_space.sh[8221]: TRIPLE_BILLING_DB_SIZE=6350307328; FREE_SPACE=6119776256
    2019-04-10 10:04:24 localhost.localdomain test_free_space.sh[8221]: Filesystem 1K-blocks Used Available Use% Mounted on - 961173328 660500248 251841568 73% /mnt/backup - 25905452 18606512 5976344 76% /mnt/db - 3966144 42280 3719064 2% /mnt/etc - 961173328 660500248 251841568 73% /mnt/log - 9948012 5649084 3786928 60% /mnt/shared - 32414588 5572272 25189068 19% /mnt/var
    2019-04-10 10:04:24 localhost.localdomain test_free_space.sh[8221]: ALARM Свободное место на диске заканчивается!

	/usr/local/angel/test_free_space.sh ERROR(1)
	Create_date: 2019-04-10 10:04:24

Функция check_db_space проверяет что на разделе /var/db (/mnt/db в хост системе) свободного места в три раза больше текущего размера БД биллинга.
В первую очередь проверьте следующие папки:

  • /mnt/db/app/asr_billing/db/notstopped - базы, поврежденные в результатате некорректного завершения работы сервера.
  • /mnt/db/app/asr_billing/db/safemode - рабочиие базы, работа которых была завершена корректно, их можно восстановить в работу.
  • /mnt/db/app/asr_billing/db/replaced_by_shadow - поврежденные базы, замененные теневой копией
  • /mnt/db/app/asr_billing/db/buff_traf.gdb.ГГГГММ - базы с аккаунтингом трафика

Базы из папок notstopped и replaced_by_shadow могут пригодится если Вы планируете проводить детальный анализ поврежденных баз. Если нет - их можно очистить.
Базы из папки safemode можно очистить только в том случае, если в настоящий момент биллинг находится в работе.
Базы buff_traf.gdb.ГГГГММ (например, buff_traf.gdb.201904) содержат информацию по объёмам трафика полученую из netflow или radius accounting, данные из них агрегируются и добавляются в основную БД billing.gdb, их можно видеть в карточках абонентов на вкладке "Расход". Их можно удалять.

test_radius_nas_list.sh

- test_radius_nas_list.sh:  ERROR(1)                       [СБОЙ ]

    Nas с IP 192.168.0.1 нету в /etc/raddb/clients.conf
    2017-03-21 14:48:52 localhost test_radius_nas_list.sh[1277]: Fix radiusd by restart
    Останавливается radiusd:                               [  OK  ]
    Останавливается radiusd_acc:                           [  OK  ]
    Запускается radiusd:                                   [  OK  ]
    Запускается radiusd_acc:                               [  OK  ]
    Nas с IP 192.168.0.1 нету в /etc/raddb/clients.conf

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

Такое может произойти, в следующих случаях:

  • при обновлении, в случае если radius-сервер запустился раньше чем закончилась перезагрузка СУБД по той или иной причине
  • если Вы не указали ни OSS-схему ни Тип НАСа при добавлении (например, если добавляли NAS не мастером, или не удалили демонстрационные NAS).

Также данный тест может сообщать следующую ошибку:

ALARM список разрешенного оборудования в Radius не совпадает со списком базы

В тесте есть скрипт, проверяющий соответствие NAS в БД и конфигурационном файле /app/asr_billing/etc/raddb/clients.conf. В случае, если в момент тестирования наблюдались сбои при обращении к БД, может появиться эта ошибка.

test_radius.py

Для отладки теста и подробного разбора проблемы можно выполнить его в режиме повышенного логирования

chroot /app/asr_billing python /usr/local/angel/test_radius.py --debug

test_daemons.sh

Тест срабатывает если одна из служб контейнера не работает и пытается исправить ситуацию автоматический (перезапуском службы). В любом случае будет создана автоматическая заявка. Пример текста ошибки:

- test_daemons.sh:  ERROR(2)                               [FAILED]

    2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_daemon admin_web_server
    2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: - check_pidfile admin_web_server ok
...
    2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_daemon radiusd_acc
    2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: - check_pidfile radiusd_acc ok
    2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_daemon radiusd_traf
    2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_pidfile - Pidfile not found for radiusd_traf
    2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: radiusd_traf restart
    Stopping radiusd_traf:                                 [FAILED]
    Starting radiusd_traf:                                 [  OK  ]
    2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_daemon radiusd_traf
    2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: check_pidfile - Pidfile not found for radiusd_traf
...
    2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: - check_pidfile xinetd ok
    2019-03-29 14:29:53 billing,megatc_ru test_daemons.sh[26103]: ALARM Некоторые демоны не работают, проверьте тест test_daemons.sh

При запуске все службы (=демоны) asr_billing создают маркерный файл в директории /var/lock/subsys/, так тест понимает какие службы нужно проверять (это нужно на случай если какие-то из них отключены в конфигурационном файле контейнера).
По каждой службе из полученного списка тест ищет pid-файл и проверяет что процесс запущен. В результате проверки он может вернуть либо состояние "ОК", что значит что проверка пройдена успешно, либо одну из следующимх ошибок:

  • Pidfile not found - тест не нашел пути pid-файл для процесса
  • No pidfile - по найденому пути либо не pid-файл (например, папка), либо он удален
  • No pid - в PID-файле не оказалось ID процесса (например, если файл оказался пустым)
  • No proc entry - pid-файл найден, но процесса с указанным ID не оказалось.

Pidfile not found

Ошибка может произойти если при запуске службы возникли ошибки и запуск не был корректно завершен.
Еще одной возможной причиной может быть если почему-то пропал PID-файл, при том что сама служба работает.

Например, перезапустим службу аккаунтинга трафика:

# /etc/init.d/radiusd_traf restart
Stopping radiusd_traf:                                     [FAILED]
Starting radiusd_traf:                                     [  OK  ]

Ошибка произошла про причине того, что процесс уже запущен, но PID-файл почему-то не создан:

# ps aux | grep radiusd_traf | grep -v grep
radiusd  10218  0.0  0.0 492948  4516 ?        Ssl  03:30   0:00 /usr/sbin/radiusd_traf -d /etc/raddb_traf

Находим должное насположение PID-файла (подставьте путь до init файла службы) и убеждаемся что его действительно нет и ошибка не в самом тесте:

# grep ^prog /etc/init.d/radiusd_traf | sed 's/.*=//g' | while read progname; do pidpath=$(grep ^pidfile /etc/init.d/radiusd_traf | sed 's/\$prog/'$progname'/g; s/.*=//g; s/\}//g'); ls -l $pidpath; done
ls: cannot access /var/run/radiusd_traf/radiusd_traf.pid: No such file or directory

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

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

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

Для корректной работы требуется администратор с правами root. По-умолчанию, в конфигурационном файле биллинга используются учетные данные root с паролем servicemode.

При изменении пароля root, необходимо исправить так же конфигурационный файл. Либо Вы можете создать нового администратора исключительно для данной функции по статье "Интерфейсы пользователей биллинга" и указать его учетные данные.

/app/asr_billing/cfg/config

declare -A django
django['username']='root'
django['password']='servicemode'

FATAL Billing Error copy metadata

Заявка может возникнуть при обновлении базы данных и говорит о том, что в процессе возникли какие-либо ошибки. Обновление БД может происходить в следующих случаях:

Скрипт обновления БД пишет лог в файл /app/asr_billing/var/log/ib_upgrade.sh.log
Так же определить наличие проблемы можно сравнив версию БД и версию биллинга. При нормальной работе версии должны совпадать.

  • Просмотр версии биллинга:
    cat /app/Billing.version
    
  • Просмотр версии БД:
    sqlexec "set list; select CONST_VALUE from vpn_const where const_id = 7"
    

    Если Вы столкнулись с этой ошибкой, попробуйте еще раз запустить update_hook.sh с ключем --force.

    /app/asr_billing/service stop
    chroot /app/asr_billing
    update_hook.sh --force
    exit
    /app/asr_billing/service start
    

    Или повторно запустить обновление биллинга с ключем --force.

    carbon_update update --force
    
    update_hook.sh можно запускать только на остановленном биллинге

    В случае если повторное обновление не исправило проблему (это можно проверить по логу, поискав слово "error"), обратитесь в техподдержку.

ALARM /usr/local/bin/sync_nas! Не могу получить списки

Ошибка теста говорит о том, что в процессе синхронизации оборудования интернет возникли ошибки.
Причину ошибки можно определить по логу синхронизации /app/asr_billing/var/log/sync_nasd.log. Ниже описаны наиболее часто возникающие ошибки и пети их решения.

NAS-сервер недоступен для биллинга

Сообщения в логе:

__main__.TimeoutError: Timeout
[Errno 113] No route to host
[Errno 113] No route to host

Проверьте что:

  • NAS-сервер включен
  • NAS-сервер доступепен биллингу по сети
  • На NAS-сервере не заблокирован доступ с биллинга фаерволом

Отключен или закрыт фаерволом порт протокола синхронизации

Сообщения в логе:

[Errno 111] Connection refused
[Errno 111] Connection refused
[Errno 111] Connection refused

Проверьте следующее:

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

В функции users_from_nas скрипта session есть ошибка, в результате которой она завершается некорректно

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

2019-03-26 10:26:51 vm120 sync_nas[1897]: sync by oss cheme
/var/oss/core/Mikrotik-Simple/bin/session: line 75: syntax error near unexpected token `}'
/var/oss/core/Mikrotik-Simple/bin/session: line 75: `}'
/usr/local/bin/sync_nas: line 207: users_from_nas: command not found

В указанном скрипте /var/oss/core/Mikrotik-Simple/bin/session есть ошибка синтаксиса.
В примере некорректно реализовано ветвление (if [ nnn ]; then; действие; fi), не дописан оператор закрывающий "if", и bash дойдя до конца функции users_from_nas говорит об ошибке.

Вы интегрируете новый NAS и ошибка возникла в процессе отладки.

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

Тесты asr_cabinet

check_cabinet_httpd_netstat.sh

Код ошибки:

- check_cabinet_httpd_netstat.sh:  ERROR(2)                [СБОЙ ]

    ALARM Веб-сервер локального сайта недоступен
    Для решения проблемы воспользуйтесь статьёй:
    http://docs.carbonsoft.ru/51019784#Системамониторинга-checkcabinethttpdnetstat.sh
    Останавливается httpd:                                 [  OK  ]
    Запускается httpd:                                     [  OK  ]
    Исправить проблему автоматически не удалось.

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

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

/app/asr_cabinet/etc/httpd/conf/httpd.conf

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

  1. Зайти в chroot asr_cabinet:
    chroot /app/asr_cabinet/
    
  2. Сохраняем текущие конфигурационные файлы:
    echo yes | mv /cfg/config /root/
    echo yes | mv /cfg/etc/httpd/conf/httpd.conf /root/
    
  3. Копируем стандартный конфигурационный файл:
    cp -p /skelet/cfg/config /cfg/
    
  4. Выходим из chroot asr_cabinet и перезапускаем его:
    exit
    /app/asr_cabinet/service restart
    

Тесты collector

check_critical_traf_reporter.sh

- check_check_critical_traf_reporter.sh:  ERROR(1)         [СБОЙ ]

    ALARM Критические ошибки в логе /var/log/reporter.log: 4

2018-03-20 17:07:00: pl5monitoring ALARM Критические ошибки в логе /var/log/reporter.log: 4

	/usr/local/monitoring/check_check_critical_traf_reporter.sh ERROR(1)
	Create_date: 2018-03-20 17:07:00

Тест определяет наличине ошибок в логе traf_reporter - эта служба отправляет в биллинг данные по объёмам абонентского трафика. Данные отправляются на radiusd_traf в биллинге. Подобные ошибки могу возникать, если с RADIUS-сервер трафика в биллинге отключен или его работа была прервана по какой-либо причине. Отсутствие связи можно увидеть по логу traf-reporter:

# grep ERR /app/collector/var/log/reporter.log -A10 | tail -n 9
2018-03-20 17:04:25 - [traf-reporter] - ERROR - File /var/dump/1521471029.10.0.0.1.dat. Not send packets: 1
2018-03-20 17:04:25 - [traf-reporter] - INFO - File /var/dump/1521471029.10.0.0.1.dat not remove
2018-03-20 17:04:41 - [traf-reporter] - INFO - RADIUS server does not reply
2018-03-20 17:04:41 - [traf-reporter] - INFO - Radius server does not responce. Sleep 60 sec and retry.
2018-03-20 17:05:56 - [traf-reporter] - INFO - RADIUS server does not reply
2018-03-20 17:05:56 - [traf-reporter] - ERROR - File /var/dump/1521524972.10.0.0.2.dat. Not send packets: 1
2018-03-20 17:05:56 - [traf-reporter] - INFO - File /var/dump/1521524972.10.0.0.2.dat not remove
2018-03-20 17:06:11 - [traf-reporter] - INFO - RADIUS server does not reply
2018-03-20 17:06:11 - [traf-reporter] - INFO - Radius server does not responce. Sleep 60 sec and retry.

Обратить внимание следует на сообшение "RADIUS server does not reply"
Для решения проблемы попробуйте перезапустить RADIUS:

chroot /app/asr_billing/ service radiusd_traf restart

Возможные ответы:

Starting radiusd_traf: [ OK ]

Корректный ответ, сервис запустился. На всякий случай проверьте что трафик стал отсылаться в биллинг по логу репортера (новые сообщения должны быть только с тегом INFO:

2018-03-20 15:20:50 - [traf-reporter] - INFO - File /var/dump/1521548443.10.0.0.1.dat remove
2018-03-20 15:20:50 - [traf-reporter] - INFO - Stop report
2018-03-20 15:20:50 - [traf-reporter] - INFO - Wait 10 seconds...
2018-03-20 15:21:00 - [traf-reporter] - INFO - Start report
2018-03-20 15:21:00 - [traf-reporter] - INFO - File /var/dump/1521548458.10.0.0.2.dat remove
2018-03-20 15:21:00 - [traf-reporter] - INFO - File /var/dump/1521548457.dat remove
2018-03-20 15:21:00 - [traf-reporter] - INFO - Stop report

Stopping radiusd_traf: [FAILED]

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

radius_traf disabled in /cfg/config

Данный ответ говорит о том, что сервер сбора трафика отключен в настройках биллинга. Включите его в биллинге в меню Настройки (в файле)

Тесты xge

check_xge_free_class.sh

check_xge_free_class.sh:  ERROR(1)                       [СБОЙ]

Шейпер в XGE (Softrouter) является динамическим. Занятые классы определяется по наличию файлов в папке /app/xge/var/lib/xge_shapers/lock, свободные в /app/xge/var/lib/xge_shapers/free.
В ситуации, когда по той или иной причине не сработала синхронизация шейперов, может возникнуть ошибка скрипта check_xge_free_class.sh. Подобная проблема наиболее характерна при подключении абонентов через vpn (pptp, pppoe)
В данном случае следует посмотреть количество свободных и занятых классов:

ls /app/xge/var/lib/xge_shapers/lock/ | wc -l
7000
ls /app/xge/var/lib/xge_shapers/free | wc -l
0

В выводе: количество занятых классов, далее количество свободных. Как видно из примера, свободных более нет. Для решения проблемы следует запустить скрипт, удаляющий лишние локи:

chroot /app/xge fix_locked_shapers.sh

Если после выполнения скрипта абоненты будут жаловаться на наличие проблем со скоростью, перезапустите XGE

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

check_vm.sh

Сообщение:

ALARM XGE запущен на виртуальной машине: kvm. Максимальная производительности может быть достигнута только при установке на физическую машину.

Имя виртуальной машины может изменяться, в зависимости от оборудования.

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

check_xge_httpd_redirect_netstat.sh

Сообщение:

WARNING Не слушает http-сервер XGE для неавторизованных
WARNING Не слушает внутренний http сервер XGE

Тест сообщает об ошибке, если в файле /app/xge/cfg/config указан некорректный IP-адрес для редиректа. Необходимо проверить строку

 httpd['internal_ip']='169.254.80.90' 

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

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

ALARM Ошибка автоматического бекапа!

Полный текст ошибки

Ошибка автоматического бекапа! Информация в логе: /app/base/var/log/cron_backup.sh.log

В нём сообщается, где можно уточнить в чем заключается проблема с бэкапами.
Как правило, ошибки возникают на стороне FTP, как то: недостаток свободного места, недоступность сервера, превышение квот, о чем можно подробней посмотреть в логе FTP-сервера.

backup: [СБОЙ ]

Ошибка говорит о проблемах с созданием бэкапа.
Убедитесь, что на разделе /mnt/backup достаточно свободного места

# df -h /mnt/backup/
Файловая система      Разм  Исп  Дост  Исп% смонтирована на
/dev/sdc3              32G  6,0G   24G  21% /mnt/backup

Если места достаточно, найдите в логе /app/base/var/log/cron_backup.sh.log строку, содержашую "backup: [СБОЙ]", например:

# /app/collector/service backup: [СБОЙ ]

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

backup_upload: [СБОЙ ]

найдите в логе /app/base/var/log/cron_backup.sh.log строку, содержашую "backup_upload: [СБОЙ]", например:

# /app/collector/service backup_upload: [СБОЙ ]

Перед ней будет лог выполнения резервного копирования.

FTP недоступен, curl: (7) couldn't connect to host

Наиболее респространенной причиной ошибки является недоступность ФТП-сервера:

/app/collector backup_upload
Backup upload collector
Синхронизирую каталог root:servicemode /app/collector/mnt/backup/ ftp://10.20.30.40/carbon/collector
Procedd /app/collector/mnt/backup//.... Не найден md5 для файла /app/collector/mnt/backup//.! Не синхронизируем!
Procedd /app/collector/mnt/backup//./config_11.42.57_09-2014... Не найден md5 для файла /app/collector/mnt/backup//./config_11.42.57_09-2014! Не синхронизируем!
Procedd /app/collector/mnt/backup//./config_16.40.08_12-2014... Не найден md5 для файла /app/collector/mnt/backup//./config_16.40.08_12-2014! Не синхронизируем!
Procedd /app/collector/mnt/backup//./config_08.00.16_12-2014... Не найден md5 для файла /app/collector/mnt/backup//./config_08.00.16_12-2014! Не синхронизируем!
Procedd /app/collector/mnt/backup//./backup_monthly_2017-03-31_02-51_collector.tar.gz... curl: (7) couldn't connect to host
md5 не сходится! Выкладываем! ebba6adaa42ad946cfed04g9af0420dc  /app/collector/mnt/backup/backup_monthly_2017-03-31_02-51_collector.tar.gz !=
curl: (7) couldn't connect to host
Retry: curl -v -sS --user root:servicemode --ftp-create-dirs --upload-file /app/collector/mnt/backup//./backup_monthly_2017-03-31_02-51_collector.tar.gz ftp://10.20.30.40/carbon/collector//./backup_monthly_2017-03-31_02-51_
* About to connect() to 10.20.30.40 port 21 (#0)
*   Trying 10.20.30.40... Время ожидания соединения истекло
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host

В данном случае, следует проверить что FTP-сервер доступен и работает.

Далее приведёны примеры наиболее часто встречающихся проблем. Полный список кодов ошибок с описанием можно посмотреть в соответствующей статье на Википедии.

Отсутствует свободное место на фтп-сервере, curl: (25) Failed FTP upload: 452

* Connecting to 1.2.3.4 (1.2.3.4) port 59996
> TYPE I^M
< 200 Type set to I.^M
> STOR audit_operations.fdb.gbk.gz^M
< 452 Unique file name cannot be created.^M
* Failed FTP upload: 452
* Remembering we are in dir "backups/asr_billing//./static/var/db/billing/201705/"
* Uploaded unaligned file size (0 out of 323513 bytes)
* Connection #0 to host 1.2.3.4 left intact
curl: (25) Failed FTP upload: 452
> QUIT^M
< 221 Goodbye.^M
* Closing connection #0

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

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

Как видно из лога, ошибка с логином

* About to connect() to 10.20.30.40 port 21 (#0)
*   Trying 10.20.30.40... connected
* Connected to 10.20.30.40 (10.20.30.40) port 21 (#0)
< 220 ProFTPD 1.3.5b Server (Hetzner Backup) [::ffff:10.20.30.40]^M
> USER root^M
< 331 Password required for root^M
> PASS servicemode^M
< 530 Login incorrect.^M
* Access denied: 530
* Closing connection #0
curl: (67) Access denied: 530

Нет прав на создание директорий, curl: (9) Failed to MKD dir: 550

Убедитесь, что корректно настроили права пользователя в настройках ftp, а так же права файловой системы.

< 250 Directory successfully changed.^M
> CWD backup^M
< 550 Failed to change directory.^M
> MKD backup^M
< 550 Create directory operation failed.^M
* Failed to MKD dir: 550
* Remembering we are in dir "/mnt/carbon/backup/billing/monitoring//"
* Uploaded unaligned file size (0 out of 76018 bytes)
* Connection #0 to host 10.20.30.40 left intact
curl: (9) Failed to MKD dir: 550

ALARM Не обнаружен работающий UPS

Настройка и решение проблемы с ИБП описаны в статье Подсистема контроля UPS

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

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

Диагностика в командной строке:

1. Проверям какой раздел заполнен:

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

Видно, что заполнен раздел /dev/sda5 с логами.

/dev/sda5        53G 47,2G  5.8G  89% /mnt/var

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

du -sh /mnt/log/*

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

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

Журнал блокировок пишется в файл /var/log/pl5_service.log.
По времени создания заявки можно найти какая оперпция занимала слишком много времени и отладить.

ALARM CRITICAL carbon_update скрипт обновления завершился

В тексте сообщения об ошибке будет описано при обновлени какого контейнера произошла ошибка, например:

	Обновление #5 [20] от 2019-03-28 07:30:42:
 CRITICAL - carbon_update: скрипт обновления завершился с ошибкой 12
 ----
 app: base

"Номер" ошибки - это код возврата какого-либо из скриптов обновления запускаемых при обновлении, инициируемых основным скриптом carbon_update.
Если ошибка возникнет повторно, описание заявки обновится, будет указано время когда она последний раз возникала.
В зависимости от способа запуска обновления (автообновление изи вручную из веб-интерфейса), полную информацию об ошибке можно найти в файлах:

  • Автообновление: /var/log/carbon_update_autoupdate.log (лог обновления) или /var/log/carbon_update_download.log (лог загрузки актуального дистрибутива)
  • Вручную: /app/base/var/log/update.log
    Ошибку можно попробовать найти утилитой grep, например:
    grep 'скрипт обновления завершился с ошибкой' /var/log/carbon_update_download.log --color -n

    grep с флагом "-n*" первым полепи пишет номер строки в файле где обнаружена ошибка:

    1024648:2019-03-28 10:30:04: CRITICAL - carbon_update: скрипт обновления завершился с ошибкой 12

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

скрипт обновления завершился с ошибкой 12

+ /app/base/usr/local/bin/update/rsync --block-size=40507 -c --port=555 --timeout=60 --exclude=/var/ --exclude=/etc/ --exclude=/cfg/ update51.carbonsoft.ru::filearchive/profiles/Billing /tmp/__update_download.24716._app_list
rsync: read error: Connection reset by peer (104)
rsync error: error in rsync protocol data stream (code 12) at io.c(768) [Receiver=3.0.9]

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

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

ALARM Повышенная нагрузка на некоторые ядра

pl5angel Повышенная нагрузка на некоторые ядра процессора.

Мы отслеживаем сколько ресурсов процессора потребляют процессы ядра: events/* и ksoftirqd/*
Основанием для срабатывания проверки является превышения лимита в 15
одним из процессов 4 раза подряд с промежутками 3, 6 и 9 секунд между замерами

    4 root      20   0     0    0    0 S 21.4  0.0   1406:21 [ksoftirqd/
   53 root      20   0     0    0    0 S  1.9  0.0   1:32.39 [ksoftirqd/

По названию процессов перечисленных выше можно определить перегруженные ядра.

Всего ядер - 16. Если более одного ядра имеют нагрузку выше 15.0,
возможно перегружен весь сервер и нужно искать причину высокой нагрузки.
Если такое ядро только одно - нужно найти способ распределить нагрузку по ядрам.

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

Информация о нагрузке записана в /app/base/var/log/check_kprocessess.log
Обратите внимание на то, что ещё было запущено в момент повышения нагрузки.

	/app/base/usr/local/angel/check_kprocesses.sh ERROR(2)
	Create_date: 2019-04-04 21:10:22

Тест реагирует на проблему некорректого распределения обработки прерываний по ядрам процессора, вероятней всего на Вашем сервере этим занимается только одно ядро.
Диагностика и решение подробно описаны в документации по Carbon Reductor X, так же построенного на платформе Carbon: Потери на сетевых картах, задержки в обработке и как с ними бороться
Быстрое решить проблему можно попытавшись запустив утилиту автоматического рапределения прерываний вызываемых обработкой сетевого карта по всем используемым сетевым интерфейсам, например:

rss-ladder eth0

Если это исправит проблему, не зубудьте добавить автоматический вызовы настройки в хук XGE

Проблема актуальна для продуктов Reductor, XGE и Softrouter. Если она произошла на Billing или Billing_Slave, обязательно обратитесь в техподдержку

WARNING Не доступны DNS серверы

- check_dns.sh:  ERROR(2)                                  [FAILED]

    WARNING Не доступны DNS-серверы

2019-04-10 11:03:31: pl5angel WARNING Не доступны DNS-серверы

	/app/base/usr/local/angel/check_dns.sh ERROR(2)
	Create_date: 2019-04-10 11:03:31

Тест check_dns.sh есть в каждом контейнере платформы Carbon. Для контейнера base используются DNS-сервера host-системы, он выполняет команду "nslookup -timeout=X ya.ru", "X" - количество секунд ожидания ответа, задаётся в конфигурационном файле контейнера (например, /app/base/cfg/config)
Возможные причины возникновения проблемы:

  • В файле /etc/resolv.conf контейнера не указаны или указаны неверные DNS-сервера.
  • Заданные DNS-сервера не отвечают
  • Заданные DNS-сервера отвечают слишком долго (дольше заданного timeout)

В файле /etc/resolv.conf контейнера не указаны или указаны неверные DNS-сервера.

Укажите работающие и доступные для биллинга DNS-сервера по статье "Настройки сети" и перезапустите все :

/etc/init.d/apps restart

Заданные DNS-сервера не отвечают

Убедитесь, что биллингу доступен интернет и есть доступ до заданных DNS-серверов.
Убедитесь что DNS-сервера работоспособны.
Попробуйте указать в настройках сети публично доступные DNS-сервера, например 8.8.8.8 (Google) или 77.88.8.8 (Yandex)

Заданные DNS-сервера отвечают слишком долго (дольше заданного timeout)

Выполните вручную команду:

nslookup timeout=1 ya.ru

Если DNS-сервер не ответит вовремя, увеличьте timeout на еденицу (timeout=2) и так далее пока не найдете оптимальное значение.
Когда удастся определить рабочий timeout, выполните следуюищй скрипт, где new_timeout задаёте равным нужному значению:

new_timeout=2; cat /app/01_*.list | while read app; do sed "s/app\['dns_timeout'\]='[0-9].*'/app\['dns_timeout'\]='$new_timeout'/g" -i /app/$app/cfg/config; done

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

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

Описание диагностики находится в соответствующей статье.

Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.