IVA ДОКУМЕНТАЦИЯ
ОБНОВЛЕНИЯ

Логирование IVA CS

Логи сервисов логики SWL

Логи сервисов логики находятся в каталоге /var/log/ivasw.

Файл логов Описание

swl-auth.log

сервис аутентификации для WebSocket и REST

swl-backend.log

бэкенд-сервис: обработка запросов от API, работа с базой данных

swl-call.log

сервис обработки VoIP-вызовов: входящие звонки, маршрутизация, переадресация, коды абонентских функций

swl-dtmf.log

сервис обработки сигналов DTMF, IVR меню

swl-ldap.log

сервис синхронизации / аутентификации с LDAP

swl-location.log

сервис аутентификации / регистрации клиентских устройств (терминалов)

swl-notify.log

сервис отправки уведомлений на электронную почту (email)

swl-provision.log

сервис автоконфигурирования клиентских устройств (терминалов)

swl-registry.log

Service Registry — мониторинг / контроль запущенных сервисов логики, взаимодействие с ITS (конфигурирование, сбор загрузки сервисов)

swl-report.log

сервис генерирования отчетов по расписанию — журнал вызовов CDR

swl-rest.log

сервис REST API — прием запросов с их последующей передачей в swl_backend

swl-socket.log

сервис WebSocket API — прием запросов с их последующей передачей в swl_backend

swl-status.log

сервис обработки статусов терминалов — BLF

swl-storage.log

сервис хранения файлов — аудио, записи звонков, подготовленные файлы CDR, архивы с логами

swl-sync.log

сервис синхронизации зон

Логи сервисов ITS

Логи сервисов ITS находятся в каталоге /var/log/ivasw/its.

Файл логов Описание

its*.log

общий лог сервисов ITS (хранение логов осуществляется с ротацией)

Дополнительные сервисы

/var/log/ivasw/ivasw-nats.log

лог сервиса NATS-Streaming

/var/log/postgresql/*

логи PostgreSQL-сервера

/var/log/nginx/*

логи nginx

/var/log/haproxy.log*

логи haproxy

/var/log/daemon.log*

стандартный системный лог сообщений сервисов

Настройка

Сервисы логики SWL

Для сервисов логики по умолчанию установлен уровень логирования INFO.

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

Допустимые уровни логирования:

Уровень логирования Тип

DEBUG

подробные сообщения, используемые во время отладки

INFO

информационные сообщения о том, что происходит во время работы

WARN

предупреждение о возникновении нежелательной ситуации

ERROR

ошибки, при которых система способна продолжать функционировать

FATAL

фатальные ошибки, в большинстве случаев приводящие к завершению работы

PANIC

ошибки, приводящие к немедленному окончанию работы

Сервисы ITS

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

optional\_base.log\_severity

Примерный вид конфигурации с установленным уровнем логирования DEBUG:

{
    "zuri": "zrpc://nats\_backend/127.0.0.1:7900",
    "config": {
        "nats": {
            "url": "@NATS\_URL@",
            "cluster": "@NATS\_CLUSTER@",
            "client": "@NATS\_CLIENT@",
            "reconnect\_sec": 1,
            "timeout\_sec": 5
        }
    },
    "optional\_base": {
        "log\_severity": "DEBUG",
        "zrpc\_timeout\_sec": 1
    }
},

Допустимые уровни логирования:

Уровень логирования Тип

DEBUG

сообщения, используемые во время отладки

TRACE

более подробные сообщения об ошибках, чем на уровне DEBUG

INFO

информационные сообщения о том, что происходит во время работы

WARNING

предупреждение о возникновении нежелательной ситуации

ERROR

ошибки, при которых система способна продолжать функционировать

CRITICAL

фатальные ошибки, в большинстве случаев приводящие к завершению работы

Изменение уровней логирования

В веб-интерфейсе доступна возможность изменения уровней логирования для сервисов логики SWL и сервисов ITS.

Чтобы изменить уровень логирования, необходимо:

  1. раздел Обзор → вкладка Кластер

  2. выбрать сервис → Уровень логирования → выбрать уровень логирования в выпадающем списке

    Уровень логирования

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

  • API: Log

  • отправка системного сигнала конкретному процессу:

Сигнал Действие

pkill -SIGUSR1 swl-call

увеличить уровень логирования. Например, если выбран INFO, то переключить на DEBUG

pkill -SIGUSR2 swl-call

уменьшить уровень логирования. Например, если выбран DEBUG, то переключить на INFO

Централизованный сбор логов в SYSLOG

Начиная с версии IVA CS 1.10, можно настроить перенаправление логов сервисов IVA CS на syslog-сервер.

Предварительно необходимо выполнить последовательные шаги для настройки сервисов IVA CS и системных компонентов:

  1. настройка сервисов логики

    Необходимо настроить сервисы логики SWL на вывод логов в stdout в формате JSON:

    • открыть файл конфигурации /etc/ivasw/logic.yaml любым текстовым редактором

    • указать следующие данные:

      SWL:
  LOG_FORCE_STDOUT: 1
  LOG_JSON_STDOUT: 1

    • сохранить изменения и закрыть файл конфигурации

    • перезапустить сервисы логики:

      sudo ivacs-ctl restart ivasw-logic

  2. настройка journald

    Необходимо включить пересылку логов из journald в syslog:

    • открыть файл /etc/systemd/journald.conf любым доступным текстовым редактором и добавить в раздел [Journal] следующую информацию:

      [Journal]
ForwardToSyslog=yes

    • сохранить изменения и закрыть файл конфигурации

    • перезапустить journald:

      sudo systemctl restart systemd-journald

  3. установка rsyslog

    Чтобы настроить возможность отправки логов во внешние системы, необходимо установить пакет rsyslog (при условии, что данный пакет не установлен), выполнив команду:

    sudo apt install rsyslog

  4. настройка rsyslog

    Для последующей настройки rsyslog требуется создать файл конфигурации /etc/rsyslog.d/10-remotelog.conf. Содержимое файла зависит от выбранного варианта настройки.

    После создания файла конфигурации необходимо перезапустить rsyslog с помощью команды:

    sudo systemctl restart rsyslog

Варианты настройки пересылки логов

При создании файла конфигурации /etc/rsyslog.d/10-remotelog.conf, в зависимости от требуемых задач, необходимо выбрать способ выдачи логов.

Вариант Описание Рекомендуемая область применения

Пересылка логов в исходном формате

JSON в поле MSG

Разработка, тестирование, системы с JSON-парсером (ELK Stack, Graylog, Grafana Loki)

RFC 5424 + Structured Data

RFC 5424 с SD-PARAMs

Корпоративные SIEM, syslog-серверы, требования к стандартизации

Выбранный вариант конфигурации необходимо отобразить в файле конфигурации /etc/rsyslog.d/10-remotelog.conf

Пересылка логов в исходном формате (JSON as is)

Данный способ подразумевает передачу тела JSON-сообщения непосредственно в поле MSG syslog-протокола. Это наиболее простой вариант интеграции, не требующий написания дополнительных скриптов или какой-то промежуточной обработки логов со стороны сервера.

Настраиваемые параметры файла конфигурации /etc/rsyslog.d/10-remotelog.conf:

if $programname startswith 'swl-' then @<IP_ADDRESS_SYSLOG>:514
& stop
if $programname startswith 'its_' then @<IP_ADDRESS_SYSLOG>:514
& stop

где <IP_ADDRESS_SYSLOG> — IP-адрес или доменное имя syslog-сервера

Символ @ означает передачу по протоколу UDP. Для использования TCP необходимо указывать @@

На стороне получателя (например, syslog-ng, rsyslog, ELK Stack или Grafana Loki) тело сообщения содержит оригинальную JSON-строку, которая может быть обработана стандартными средствами для дальнейшего анализа, индексации и визуализации.

Пример содержимого поля MSG на принимающей стороне:

{"level":"INFO","timestamp":"2026-03-16T12:00:00.000+0300","caller":"server.go:42","msg":"Starting server","service":"swl-call","port":8080}

Пересылка в формате RFC 5424 с динамическими Structured Data

Формат логов сервисов

Сервисы IVA CS пишут логи в формате JSON. Пример:

{"level":"INFO","timestamp":"2026-03-16T12:00:00.000+0300","caller":"server.go:42","msg":"Starting server","service":"swl-call","port":8080}

  • стандартные поля: level, timestamp, msg

  • остальные поля — произвольные (caller, service, error, port и др.)

Маппинг JSON → RFC 5424

Поле JSON Поле RFC 5424

level

PRI (severity): DEBUG=7, INFO=6, WARN=4, ERROR=3

timestamp

TIMESTAMP

msg

MSG (текстовая часть сообщения)

Все остальные поля

Structured Data [ivacs@48576 key="value" …​]

Спецсимволы (", \, ]) в значениях SD-PARAM экранируются по RFC 5424.

Вложенные объекты (dict, list) преобразуются в JSON-строку

Внешний скрипт

Шаблоны rsyslog статические — в них нельзя автоматически перебирать один за другим все ключи, которые есть в JSON-сообщении. Для динамических Structured Data используется модуль omprog с внешним Python-скриптом rsyslog-rfc5424.py.

Установка

  1. скопировать скрипт на сервер:

    sudo cp rsyslog-rfc5424.py /usr/local/bin/rsyslog-rfc5424.py
sudo chmod +x /usr/local/bin/rsyslog-rfc5424.py

  2. настроить адрес syslog-сервера в скрипте:

    SYSLOG_HOST = "<IP_ADDRESS_SYSLOG>"   # Адрес syslog-сервера
SYSLOG_PORT = 514                     # Порт
SYSLOG_PROTO = "udp"                  # udp или tcp

    где <IP_ADDRESS_SYSLOG> — IP-адрес syslog-сервера

  3. создать конфигурацию rsyslog /etc/rsyslog.d/10-remotelog.conf:

    # Загрузка модуля для запуска внешних программ
module(load="omprog")

# Шаблон: передает programname, procid, hostname и тело сообщения в скрипт
# Поля разделены табуляцией
template(name="ivacs-omprog" type="list") {
    property(name="programname")
    constant(value="\t")
    property(name="procid")
    constant(value="\t")
    property(name="hostname")
    constant(value="\t")
    property(name="msg")
    constant(value="\n")
}

if ($programname startswith 'swl-' or $programname startswith 'its_') then {
    action(
        type="omprog"
        binary="/usr/bin/python3 /usr/local/bin/rsyslog-rfc5424.py"
        template="ivacs-omprog"
        output="/var/log/ivasw/rsyslog-rfc5424.log"
    )
    stop
}

  4. настроить AppArmor

  5. перезапустить rsyslog:

    sudo systemctl restart rsyslog

Принцип работы

  1. rsyslog фильтрует сообщения от сервисов swl-* и its_* и затем передает их через omprog в скрипт rsyslog-rfc5424.py

  2. скрипт разбирает JSON, формирует RFC 5424 сообщение и отправляет его на syslog-сервер

Примеры

Обычный лог

{"level":"INFO","timestamp":"2026-03-16T12:00:00.000+0300","caller":"server.go:42","msg":"Starting server","service":"swl-call","port":8080}
<14>1 2026-03-16T12:00:00.000+0300 ivacs0 swl-call 1234 - [ivacs@48576 caller="server.go:42" service="swl-call" port="8080"] Starting server

Лог с ошибкой

{"level":"ERROR","timestamp":"2026-03-16T12:01:00.000+0300","caller":"handler.go:88","msg":"Request failed","service":"swl-rest","error":"connection refused","method":"GET","path":"/api/v1/users"}
<11>1 2026-03-16T12:01:00.000+0300 ivacs0 swl-rest 1234 - [ivacs@48576 caller="handler.go:88" service="swl-rest" error="connection refused" method="GET" path="/api/v1/users"] Request failed

Лог с вложенным объектом

{"level":"WARN","timestamp":"2026-03-16T12:02:00.000+0300","msg":"Slow query","query":{"table":"accounts","duration_ms":1500}}
<12>1 2026-03-16T12:02:00.000+0300 ivacs0 swl-backend 1234 - [ivacs@48576 query="{\"table\":\"accounts\",\"duration_ms\":1500}"] Slow query

Решение проблем

AppArmor блокирует запуск скрипта

При пересылке логов в формате RFC 5424 с динамическими Structured Data rsyslog запускает внешний скрипт через модуль omprog. На системах с AppArmor (Ubuntu, Pop!_OS, Debian) профиль rsyslog может запрещать запуск внешних программ.

Симптомы:

  • в журнале rsyslog (sudo journalctl -u rsyslog):

    omprog: failed to execute program '/usr/bin/python3': Permission denied

  • в выводе команды dmesg:

    apparmor="DENIED" operation="exec" profile="rsyslogd" name="/usr/bin/python3.12"

Диагностика:

  1. убедиться, что AppArmor блокирует rsyslog:

    sudo dmesg | grep -i denied | grep rsyslog

  2. проверить статус профиля rsyslog:

    sudo aa-status 2>/dev/null | grep rsyslog

Исправление

Добавить разрешения в локальный профиль AppArmor для rsyslog:

  1. разрешить rsyslog запускать python3 и читать скрипт:

    sudo bash -c 'cat >> /etc/apparmor.d/local/usr.sbin.rsyslogd << EOF
/usr/bin/python3* ix,
/usr/local/bin/rsyslog-rfc5424.py r,
EOF'

  2. перезагрузить профиль:

    sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.rsyslogd

  3. перезапустить rsyslog:

    sudo systemctl restart rsyslog

  • ix — разрешить запуск (x) с наследованием профиля (i)

  • r — разрешить чтение файла

  • файл /etc/apparmor.d/local/usr.sbin.rsyslogd предназначен для локальных дополнений и не перезаписывается при обновлении пакета rsyslog

Замечания

  • если JSON не удалось разобрать, сообщение пересылается в текущем состоянии с уровнем severity = INFO

  • Private Enterprise Number (PEN) имеющий значение 48576 в SD_ID (ivacs@48576) — должен соответствовать зарегистрированному номеру организации в IANA. Если PEN имеет иное значение — заменить значение переменной SD_ID в скрипте

  • лог ошибок скрипта: /var/log/ivasw/rsyslog-rfc5424.log (параметр output в конфигурации rsyslog)