Технические особенности логирования в Loginom

При работе с Loginom Server и Loginom Integrator важно иметь возможность отслеживать события, диагностировать ошибки и анализировать работу системы. Для этого используются журналы (логи), которые содержат подробную информацию о работе компонентов платформы.

В статье рассмотрены:

• Местоположение и формат логов для Windows и Linux.
• Регулярные выражения (RegEx) для парсинга логов.
• Структура записей journald.
• Способы агрегации и визуализации логов.
• Настройки популярных инструментов для сбора логов, включая Fluent Bit, Promtail и LogDy.

Расположение и доступ к логам

Loginom Server и Loginom Integrator записывают логи в файлы или в journald (только для Linux).

Расположение файлов по умолчанию:

Loginom Server:

• Windows: C:\ProgramData\Loginom\Server\Logs\
• Linux: /var/opt/loginom/server/Logs/

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

Loginom Integrator:

• Windows: C:\ProgramData\Loginom\Integrator\Logs\
• Linux: /var/opt/loginom/integrator/Logs/

Для Integrator возможна настройка записи логов сразу в БД или в консоль.

Файловые логи можно прочитать любым текстовым редактором, journald читается штатными средствами:

# все логи (с последней перезагрузки хоста) сервера Loginom
sudo journalctl -t loginomd
# перейти в конец и включить мониторинг
sudo journalctl -t loginomd -e -f
# отображать только ошибки
sudo journalctl -t loginomd -p 3
# вывести только нужные поля в json
sudo journalctl -t loginomd --output-fields=MESSAGE,EXCEPTION,STACK_TRACE -o json-pretty
# данные за период
sudo journalctl -t loginomd --since "2024-01-15 07:15:00" --until "2024-01-15 08:15:00"
# логи Integrator
sudo journalctl -t Integrator
# ...

Структура файлового лога

Пример лога loginom:

txt
2025-01-29T12:35:36.496 info 2256b86ce73b1d4c94275806353fb4f3 (loginomd.exe:6852>) — Loginom Enterprise запущен{"VERSION": "7.2.3"}
2025-01-29T12:35:54.793 warn becf183c126b88429ae23a064d6c395b (loginomd.exe:308>) — Не удалось войти в учетную запись user{"USER_NAME": "user", "REASON": "Неверное имя пользователя или пароль", "CLIENT_IP": "127.0.0.1", "HEADERS": "{host=localhost:8080,...}"}
2025-01-29T12:35:58.340 info 5fc5caa8eddfc549a26df848301172bd (loginomd.exe:2144>user:1) — Инициализирована сессия для пользователя user{"USER_NAME": "user", "SESSION_TYPE": "Интерактивная сессия", "CLIENT_IP": "127.0.0.1", "HEADERS": "{host=localhost:8080,...}"}
2025-01-29T12:36:08.346 info f83b8ef14e13784f9032c3b163c6f39b (loginomd.exe:2144>user:1) — Создан черновик пакета
2025-01-29T12:36:08.404 info 94823d6605b0e04d8544e8c971b09920 (loginomd.exe:2144>user:1) — Сохранен пакет "/user/tmp.lgp"{"PACKAGE_FILE": "/user/tmp.lgp"}
2025-01-29T12:36:08.404 info 58f880f79d427940a5f7d1e25b2f2255 (loginomd.exe:2144>user:1) — Открыт пакет "/user/tmp.lgp" в режиме редактирования{"PACKAGE_FILE": "/user/tmp.lgp"}
2025-01-29T12:36:27.197 error 86f0b82d885c424bac824aeca6936f15 (loginomd.exe:2144>user:1) — Ошибка активации узла "Текстовый файл" GUID={73E60C95-B0CB-45D5-B5CE-08F981A1F855} Пакет=tmp{"Message": "Файл \"noexist.txt\" не найден", "ExceptionClass": "EBGException"}

Разберем строку: 2025-01-29T12:36:08.404 info 94823d6605b0e04d8544e8c971b09920 (loginomd.exe:2144>user:1) — Сохранен пакет "/user/tmp.lgp"{"PACKAGE_FILE": "/user/tmp.lgp"}

RegEx для разбора строки лога: (?P<time>\d{4}\-\d{2}\-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}) (?P<priority>\S+) (?P<id>\S+) \((?P<thread>\S+?)(>(?P<session>\S+?))?\) \- (?P<message>.+)

• time — таймстамп сообщения (2025-01-29T12:36:08.404).
• priority — приоритет сообщения (info).
• id — id сообщения (94823d6605b0e04d8544e8c971b09920).
• thread — id потока выполнения (loginomd.exe:2144).
• session — id сессии (user:1).
• message — текст сообщения. Может содержать детали сообщения в формате JSON или StackTrace ошибки (Сохранен пакет "/user/tmp.lgp"{"PACKAGE_FILE": "/user/tmp.lgp"}.

Пример лога Integrator:

txt
2025-01-29 11:23:03.0382|Info|4e2c1d7caae849f19e0e617a7b4b4874|Url вызываемого метода: http://192.168.0.12/rest/metrics/orders
2025-01-29 11:23:03.0382|Info|4e2c1d7caae849f19e0e617a7b4b4874|Обработка пакета «metrics» версии 1.0.0, выполнение узла «orders» с именем «orders» и идентификатором {148306ac-856e-280a-8010-7e51f9d75196}
2025-01-29 11:23:03.0382|Info|4e2c1d7caae849f19e0e617a7b4b4874|Обработка запроса на сервере 192.168.0.11
2025-01-29 11:23:03.1548|Info|4e2c1d7caae849f19e0e617a7b4b4874|Обработка завершена успешно

Разберем строку: 2025-01-29 11:23:03.0382|Info|4e2c1d7caae849f19e0e617a7b4b4874|Url вызываемого метода: http://192.168.0.12/rest/metrics/orders

RegEx для разбора строки лога: (?P<time>\d{4}\-\d{2}\-\d{2} \d{2}:\d{2}:\d{2}\.\d{4})\|(?P<priority>\S+)\|(?P<session>\S+?)\|(?P<message>.+)

• time — таймстамп сообщения (2025-01-29 11:23:03.0382).
• priority — приоритет сообщения(Info).
• session — id сессии. Соответствует значению поля session в логах Loginom Server для того же запроса (4e2c1d7caae849f19e0e617a7b4b4874).
• message — текст сообщения (http://192.168.0.12/rest/metrics/orders).

Поля записей journald

Server

Общие поля сообщения в journald:

• MESSAGE_ID — обязательный идентификатор сообщения.
• MESSAGE — текст сообщения.
• PRIORITY — приоритет (ошибка, хинт и т.д.).

Стандартные поля для сообщения от Loginom:

• USER — пользователь от которого пришло сообщение.
• SESSION_ID — число, идентификатор сессии от которой пришло сообщение.
• REQUEST_ID (необязательный) — строка, идентификатор запроса от которого пришло сообщение. Параметр присутствует только если значение идентификатора не пустая строка, т.е. когда выполняется запрос из интегратора.

Поля для сообщения об исключении от Loginom:

• EXCEPTION — текст исключения.
• EXCEPTION_CLASS — класс исключения.
• STACK_TRACE — строка с callstack-ом исключения.
• EXCEPTION_TYPE — тип исключения ('Error', 'Warning', 'Hint').
• SENDER — класс отправителя исключения.

Остальные параметры:

• COLUMN_NAME, COLUMN_CAPTION — имя/метка колонки.
• USER_NAME, GROUP_NAME — имя пользователя/группы.
• ROW_NUM (начинается с 0), ROW, LINE (начинается с 1) — номер строки данных к которой относится сообщение.
• ERROR_MESSAGE — текст сообщения об ошибке.
• ELEMENT_GUID, ELEMENT_NAME, ELEMENT_ID — идентификация элементов конфигурации.
• PACKAGE_FILE, PACKAGE_NAME — идентификация пакета.
• SESSION_TYPE, SESSION_NAME — идентификации сессии.
• PROCESS_CAPTION, PROCESS_NAME, DIM_CAPTION, DIM_NAME — идентификация процесса.
• NODE_CAPTION, NODE_GUID — идентификация узла сценария.

Integrator

Общие поля сообщения в journald:

• MESSAGE_ID — обязательный идентификатор сообщения.
• PRIORITY — приоритет (ошибка, хинт и т.д.).
• MESSAGE — текст сообщения.

Поля для сообщений от Loginom Integrator:

• CONTAINER_NAME — имя контейнера (определяется значением переменной окружения JOURNALD_CONTAINER_NAME).
• REQUEST_ID — уникальный идентификатор запроса. Значение данного поля совпадает со значением поля REQUEST_ID в логах Loginom Server по тому же запросу.
• PACKAGE_NAME — имя выполняемого пакета.
• NODE_NAME — имя выполняемого узла.
• EXCEPTION — информация об исключении (текст сообщения об ошибке, класс исключения, stack trace, внутренние исключения).
• REQUEST — текст запроса.
• RESPONSE — текст ответа.

Системы агрегации логов

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

Наиболее правильным решением будет чтение и отправка логов в системы агрегации логов — Grafana Loki, ELK, Greylog и т. п.

Непосредственно сбором логов обычно занимается специальный агент — FluentBit, Promtail, Logstash. Агент мониторит источник логов и при наличии изменений парсит и отправляет данные в систему хранения.

Общими настройками для всех агентов будут следующие параметры:

• Для файловых логов:
  • расположение лог файла app.log.
  • regex для парсинга строк лога.
• Для journald:
  • SYSLOG_IDENTIFIER.
  • набор забираемых полей.

Пример настройки fluent-bit для отправки journald лога в Grafana Loki.

...
[INPUT]
    Name              systemd
    Tag               loginom
    Systemd_Filter    SYSLOG_IDENTIFIER=loginomd
    Systemd_Filter    SYSLOG_IDENTIFIER=Integrator

# [OUTPUT]
#    name stdout
#    match *

[OUTPUT]
    Name loki
    Match *
    host loki.example.local
    port 3100
    labels service=$_COMM,ver=$VERSION,user=$USER,level=$PRIORITY,host=$_HOSTNAME,request_id=$REQUEST_ID,session_id=$SESSION_ID,session_type=$SESSION_TYPE
    line_format key_value
    remove_keys _UID,_GID,REQUEST_ID,SESSION_ID,SESSION_TYPE,USER_NAME,EXCEPTION_CLASS,_MACHINE_ID,_TRANSPORT,_BOOT_ID,_CAP_EFFECTIVE,_SELINUX_CONTEXT,_SYSTEMD_SLICE,MESSAGE_ID,TID,SYSLOG_IDENTIFIER,_PID,_COMM,_EXE,_CMDLINE,_SYSTEMD_CGROUP,_SYSTEMD_UNIT,_SYSTEMD_INVOCATION_ID,_SOURCE_REALTIME_TIMESTAMP

Promtail на Windows

server:
  http_listen_port: 9080
  grpc_listen_port: 0
  log_level: 'warn'

positions:
  # This location needs to be writeable by promtail.
  filename: "C:/loki/positions.yaml"

client:
  url: http://localhost:3100/loki/api/v1/push

scrape_configs:
  - job_name: loginom_server
    pipeline_stages:
      - regex:
          # 2021-05-04T13:48:55.776 info (Server.exe:12928>service:1275:f154a980e5024e68b880f8c37e034cca) — Закрыт пакет "/LDM/libs/connection.lgp"
          expression: '(?P<time>\d{4}\-\d{2}\-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}) (?P<priority>\S+) (?P<id>\S+) \((?P<thread>\S+?)(>(?P<session>\S+?))?\) \- (?P<message>.+)'
      - timestamp:
          source: time
          format: 2006-01-02T15:04:05.000
          location: 'Local'
      - output:
          source: priority
      - output:
          source: message
      - labels:
          priority: priority
          thread: thread
          session: session
    static_configs:
      - labels:
          env: dev
          host: dev
          job: loginom_server_logs
          __path__: "C:/ProgramData/Loginom/Server/Logs/app.log"
        targets:
          - localhost
  - job_name: loginom_integrator
    pipeline_stages:
      - regex:
          expression: '(?P<time>\d{4}\-\d{2}\-\d{2} \d{2}:\d{2}:\d{2}\.\d{4})\|(?P<priority>\S+)\|(?P<session>\S+?)\|(?P<message>.+)'
      - timestamp:
          source: time
          format: 2006-01-02 15:04:05.0000
          location: 'Local'
      - output:
          source: priority
      - output:
          source: message
      - labels:
          level: priority
          session: session
    static_configs:
      - labels:
          env: dev
          host: dev
          job: loginom_integrator_logs
          __path__: "C:/ProgramData/Loginom/Integrator/Logs/log.log"
        targets:
          - localhost

LogDy

Более простой (и менее удобный) способ — транслировать содержимое логов в веб-интерфейсе LogDy хоста с Loginom Server.

В примере веб интерфейс для файловых логов будет доступен на всех ip адресах хоста на порту 4585 (http://loginom.example.local:4585/):

Windows:

pwsh -Command "Get-Content C:\ProgramData\Loginom\Server\Logs\app.log -Wait -Tail 10 | .\logdy_windows_amd64.exe --ui-ip 0.0.0.0 -p 4585 -u -n --config logdy.json"

Альтернативный способ запуска через встроенную команду Logdy:

logdy_windows_amd64.exe follow C:\ProgramData\Loginom\Server\Logs\app.log --full-read --ui-ip 0.0.0.0 -p 4585 -u -n --config logdy.json

Linux:

tail -f /var/opt/loginom/server/Logs/app.log | logdy --ui-ip 0.0.0.0 -p 4585 -u -n --config logdy.json
# или
logdy follow /var/opt/loginom/server/Logs/app.log --full-read --ui-ip 0.0.0.0 -p 4585 -u -n --config logdy.json

Пример logdy.json:

{
    "name": "main",
    "columns": [
        {
            "id": "829927",
            "name": "timestamp",
            "handlerTsCode": "(line: Message): CellHandler => {\n    return { text: line.content.slice(0,23) }\n}",
            "faceted": false,
            "idx": 1,
            "width": 184
        },
        {
            "id": "920743",
            "name": "priority",
            "handlerTsCode": "(line: Message): CellHandler => {\n    return { text: line.content.split(' ')[1] }\n}",
            "faceted": true,
            "width": 50,
            "idx": 2
        },
        {
            "id": "362442",
            "name": "message",
            "handlerTsCode": "(line: Message): CellHandler => {\n    return { text: line.content.split(' - ')[1] }\n}",
            "idx": 0,
            "width": 1347,
            "faceted": false
        }
    ],
    "settings": {
        "leftColWidth": 300,
        "drawerColWidth": 900,
        "maxMessages": 1000,
        "middlewares": []
    }
}

Сообщения из journald можно транслировать следующим образом:

journalctl -t loginomd -f -n 1000 -o json | logdy -ui-ip 0.0.0.0 -p 4585 -u -n

Что это дает на практике

Корректная настройка логирования в Loginom Server и Integrator — необходимый шаг для эффективной диагностики, мониторинга и обеспечения стабильности работы системы. Использование систем агрегации логов позволяет централизованно отслеживать события, оперативно выявлять проблемы и повышать прозрачность работы бизнес-процессов.

В статье рассмотрены основные подходы к сбору и анализу логов, включая файловые журналы и systemd-journald, а также примеры настройки агентов Fluent Bit, Promtail и LogDy. Эти инструменты обеспечивают гибкость и масштабируемость в работе с логами, что особенно важно в продуктивной среде.

Более подробно о задачах, которые решаются с помощью логирования — отладки, профилирования, мониторинга и обеспечения безопасности, — рассказано в статье «Логи в Loginom без секретов: как заставить их «говорить». В ней рассматриваются типы логов, ключевые параметры настройки и методы их интерпретации.

Другие материалы по теме:

Использование OpenID для входа в Loginom

Планировщик задач в Loginom