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

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

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

просмотр истории страницы
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

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

В сообщении об ошибке будет написан ID задачи. По нему можно определить на каком абоненте она была создана:
* Ошибка:



{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]

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

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

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

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

{code}2019-09-12 08:35:17,269 - django - commands - ERROR - Логин {0} состоит из одних цифр и может быть не принят!
Ошибка говорит о том, что в услуге создающей учетную запись не задан префикс. Вероятней всего ошибка возникла при [настройке услуг IPTV|CarbonBilling:Настройка услуг IPTV]

Посмотреть список услуг создающих учетные записи и из префиксы можно через [конструктор отчетов|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

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

{code}select id, name ,create_login, prefix_login from usluga where create_login=1{code}
Посмотреть списки услуг создающих учетные записи и из префиксы можно через [конструктор отчетов|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}

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\!




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}
# Измените дату и время на 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]
/app/asr_billing/var/log/radius/radius.log-20191104.gz{code}
Первый файл - актуальный лог
Второй - архивны, в нем информация от момета предыдущей архивации до 04 ноября 2019 года.

Чтобы найти причину, ориентируйтесь на время написанное при падении теста - в примере выше это "2017-03-21 14:48:52". Изучив лог за это время можно найти более подробную информацию о причине ошибки, вероятно она одна из описанных выше.
* На 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}



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:Описание работы служб сбора статистики], на вкладке "*Настойки сохранения сырой статистики*", опция "*Сохранять сырую статистику*"
# Удалить уже собранную статистику можно такой командой:
{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}




h2. check_xge_httpd_redirect_netstat.sh

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

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



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

Тест реагирует на проблему некорректого распределения обработки прерываний по ядрам процессора, вероятней всего на Вашем сервере этим занимается только одно ядро.
Диагностика и решение подробно описаны в документации по 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. WARNING Не доступны DNS серверы
{code}- check_dns.sh: ERROR(2) [FAILED]