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

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

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

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

110249
{code}
Проверьте сервер биллинга на соответствие [системным требованиям|Системные требования] и проверьте, какие события собираются [в стеке|CarbonBilling:nas_event_daemon]. Если количество не уменьшается, то следует обратиться в техническую поддержку для решения проблем с производительностью.

{info}Если в стеке скопились команды отправки на маршрутизаторы *Mikrotik*, проверьте количество записей в _address list_:
Получив вывод лога и возникшую ошибку, Вы можете обратиться в Смотрёшку и уточнить почему 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:Управление пользователями, интерфейс администратора. Авторизация.] некорректно указан номер смс для оповещения. Номер телефона должен удовлетворять формату E.164:+79123456789 или 89123456789.

h3. Ошибка обработки запроса.
Выдержка из лога сделанная тестом пишет о том что возникла ошибка обработки запроса: речь о запросе фреймворка Django, на котором разработано ядро биллинга, к базе данных.
{code:title=/app/asr_billing/var/monitoring_dump/check_error_django.sh.NNNN.log}
2020-09-09 08:40:19,347 - django - __init__ - ERROR - Ошибка обработки запроса
2020-09-09 08:46:44,690 - django - __init__ - ERROR - Ошибка обработки запроса
{code}
Если посмотреть полный лог, можно будет увидеть детали ошибка типа "Traceback" и сам запрос, например:
{code:title=/app/asr_billing//var/log/django/error.log}
2020-09-09 11:29:11,993 - django - __init__ - ERROR - Ошибка обработки запроса
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py", line 137, in get_response
...
"Error while preparing SQL statement:")
DatabaseError: ('Error while preparing SQL statement:\n- SQLCODE: -206\n- Dynamic SQL Error\n- SQL error code = -206\n- Column unknown\n- USLUGA.USLUGA_VOIP_GROUP_ID
...
{code}

h4. Решение

# Если версия уже актуальная, возможно обновление прошло не полностью. В первую очередь попробуйте обновить базу принудительно:
{code}/app/asr_billing/service stop
chroot /app/asr_billing
update_hook.sh --force
exit
/app/asr_billing/service start{code}
# [Обновите|CarbonBilling:Обновление платформы] биллинг до актуальной версии.
# Если версия уже актуальная, запустите принудительное обновление - возможно повреждён какой-то файл или во время обновления произошла ошибка и новая версия не загрузилась:
{code}carbon_update --force{code}
# Если все предыдущие действия не помогли - напишите разработчикам, приложив к задаче файл */app/asr_billing//var/log/django/error.log*

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

{info}
#25262 - это id абонета в базе данных. Быстро перейти на него в веб интерфейсе можно по ссылке:
{code}
http://<ip-биллинга>:8082/admin/Abonents/25262
{code}
{info}

h3. csv_loading - Файл конфигурации пустой
{code}
2020-07-08 06:04:08,979 - worker - csv_loading - ERROR - Файл конфигурации /cfg/autocsv/test.autocsv пустой
2020-07-08 06:04:40,464 - worker - csv_loading - ERROR - Файл конфигурации /cfg/autocsv/test.autocsv пустой
2020-07-08 06:04:41,633 - worker - csv_loading - ERROR - Файл конфигурации /cfg/autocsv/test.autocsv пустой
2020-07-08 06:04:42,432 - worker - csv_loading - ERROR - Файл конфигурации /cfg/autocsv/test.autocsv пустой
2020-07-08 06:05:10,670 - worker - csv_loading - ERROR - Файл конфигурации /cfg/autocsv/test.autocsv пустой
{code}
В каталоге с настройками для выгрузки платежей из [CSV|Автоматическая выгрузка платежей из CSV] находистся пустой файл настройки. Видимо вы создали файл для настроек выгрузки платежей и не заполнили его. Пустой файл нужно удалить:
# Посмотрим содержимое каталога:
{code}
ls -l /app/asr_billing/cfg/autocsv/
{code}
Видим два файла с настройками, *test.autocsv* - пустой.
{code}
-rw-rw-rw- 1 root root 0 Июн 16 11:28 test.autocsv
-rwxrwxrwx 1 root root 769 Июн 29 1976 default.autocsv
{code}
# Удалмите пустой файл:
{code}
rm -f /app/asr_billing/cfg/autocsv/test.autocsv
{code}

h3.Ошибка обработки отправки отложенных комманд ConnectionTimeout
{code}
2020-06-26 10:09:05,928 - worker - common - CRITICAL - Ошибка обработки отправки отложенных комманд ConnectionTimeout caused by - ReadTimeoutError(HTTPConnectionPool(host='169.254.92.94', port=9200): Read timed out. (read timeout=30))

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


h2. test_httpd.sh
{code}- test_httpd.sh: ERROR(2) [FAILED]
В таком случае попробуйте временно ограничить объём внешних соединений к серверу - обращения по API, доступ в панель управления абонентами и тарифами, количество одновременно выполняемых отчетов в [конструкторе|CarbonBilling:Конструктор отчетов]

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

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

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

h3. Проблема настройки SSL
Ошибка возникает при редактировании конфигурационного файла httpd.conf . Обычно это происходит при установке [ssl сертификата на локальный сайт|Установка ssl сертификата на локальный сайт].
{code:title=Ошибка}
Stopping httpd: [ OK ]
Starting httpd: Syntax error on line 1163 of /etc/httpd/conf/httpd.conf:
SSLCertificateFile: file '/cfg/cert/lk.my-telecom.ru/cert.pem' does not exist or is empty
{code}

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

h3. Порт уже занят другим приложением
{code:title=Ошибка}
Stopping httpd: [ OK ]
Starting httpd: (98)Address already in use: make_sock: could not bind to address 169.254.0.80:443
no listening sockets available, shutting down
Unable to open logs
[FAILED]
{code}

# Посмотрите, какое приложение заняло указанный порт (его видно в тексте ошибки, в примере это 443)
{code:title=Команда}netstat -nlp | grep 443 -w{code}
{code:title=Вывод}tcp 0 0 :::443 :::* LISTEN 5160/httpd{code}
# По выводу видно, что это приложение с PID 5160, посмотрите через подсистему proc что это за приложение
{code:title=Команда}ll /proc/5160/exe{code}
{code:title=Вывод}lrwxrwxrwx 1 root root 0 Окт 19 19:29 /proc/5160/exe -> /app/asr_fiscal/usr/sbin/httpd{code}
# В примере видно, что это исполняемый файл /app/asr_fiscal/usr/sbin/httpd. Исправьте его настройки:
#* используйте для этого приложения другой порт;
#* или перенесите его на другой сервер.

h1. Тесты asr_fiscal

h2. check_fiscal_httpd_netstat.sh

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

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

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

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

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

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

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

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

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

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

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

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

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

h2. check_fiscal_httpd_ssl_netstat.sh

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

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

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

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

h1. Тесты collector


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

h2. check_critical_traf_reporter.sh

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

h1. Общие ошибки продуктов на платформе Carbon PL5
{info}Проблема актуальна для продуктов Reductor, XGE и Softrouter. Если она произошла на Billing или Billing_Slave, обязательно обратитесь в техподдержку{info}

h2. ALARM Billing Watchdog не активен в течение двух часов!

Основная причина - остановленный cron в корневой системе. Перезапускает его softdog_agent, его лог - /var/log/softdog_agent.log
Если в данном логе много записей вида:

{code}
Mar 30 08:15:29 carbon crond[7293]: (CRON) INFO (Shutting down)
Mar 30 08:15:29 carbon crond[24413]: (CRON) STARTUP (1.4.4)
{code}

Надо искать причину остановки cron - например, он намеренно остановлен администратором, либо какой-то скрипт убил (в том числе - запущенный по крону), либо системный oom_killer при недостатке памяти:

{code}
grep -i 'killed process' /var/log/messages-20200419
{code}

Ищем подозрительные записи в кроне каждого из пользователей:

{code}
for user in $(getent passwd | cut -f1 -d: ); do echo $user; crontab -u $user -l; done
{code}

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

В /var/log/messages находим следующие записи:

{code}
Apr 26 11:45:14 carbon ntpdate[32431]: step time server 83.143.51.50 offset -44098.832672 sec
{code}

Проверяем разницу между временем на виртуальной машине и на хосте:

{code}
date; vmware-toolbox-cmd stat hosttime
Срд Май 27 15:25:59 MSK 2020
28 Май 2020 03:41:46
{code}

Устанавливаем на хост-машине верное время (желательно ещё включить и настроить получение его по NTP), проблема должна решиться.

Либо можно отключить синхронизацию с ВМ:

Disable Time Synchronization Completely
If you want to keep a fictitious time in a virtual machine, so that the clock in the guest is never synchronized
with that on the host, you must disable time synchronization completely.
A virtual machine occasionally synchronizes time with the host even if you do not turn on periodic time
synchronization. To completely disable time synchronization, you must set some properties in the virtual
machine configuration file.
Prerequisites
Power off the virtual machine.
Procedure
1 Open the configuration (.vmx) file of the virtual machine with a text editor.
2 Add lines for the time synchronization properties and set the properties to FALSE.
tools.syncTime = "FALSE"
time.synchronize.continue = "FALSE"
time.synchronize.restore = "FALSE"
time.synchronize.resume.disk = "FALSE"
time.synchronize.shrink = "FALSE"
time.synchronize.tools.startup = "FALSE"
3 Save and close the file.


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

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

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

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

Если проблема с каналом связи, это будет видно по журналу системы мониторинга:
{code:title=Файл журнала /app/base/var/log/watchdog.log}
curl: (6) Could not resolve: rest.crm.carbonsoft.ru (Timeout while contacting DNS servers)
curl: (7) Failed to connect to XXX.XXX.XXX.XXX port 80: Connection timed out
2020-10-19 18:30:01 [4346]: kildin.net watchdog started

-------------------------------------------------------------
2020-10-19 18:34:25 [4346]: kildin.net watchdog catch Error
{code}
Здесь видно, что система мониторинга не смогла связаться с CRM по IP-адресу - значит, проблема не в DNS, а с доступом к сети в целом.

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

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