Как стать автором
Обновить

Логи в файлах: написал своё приложение для просмотра структурированных логов

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров4.6K
Всего голосов 10: ↑10 и ↓0+11
Комментарии12

Комментарии 12

Зачётная иконка. Напомнило почему-то про Log Lady из Твин Пикса.

Иконку сгенерировал с ИИ. Правда был водяной знак, перерисовал вручную.

А не думали сделать UDTF чтобы читать логи при помощи SQL запроса? У нас есть такое - очень удобно.

Продуктовые логи сразу пишем в БД, но есть еще системные (joblog) логи заданий - вот для них есть UDTF.

Да, сразу смотрел на эту реализацию, по примеру как у Seq. Для более простого старта пошёл на компромисс.

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

Смотреть логи скулем универсально и удобно с точки зрения фильтрации

Поскокльку у нас вся работа крутится вокруг БД, то все логи ведем в виде таблиц бд. Там есть уровни логирования (как минимум три уровня - только ошибки, ошибки + бизнес ссобщения (то, что может быть интересно бизнесу), ошибки, бизнес и трейсы (это уже отладочная информацимя). Есть настройки - глубина хранения логов для разных уровней логирования, уровень логирования...

Естественно, для каждого продукта есть своя таблица логов (структура плюс-минус одинаковая, но могут быть какие-то специфические поля), свои настройки логирования.

Поскульку наша платформа работает "как большие машины" (т.е. все работает в рамках задания - job), для каждого задания системой ведется joblog (туда всякие системные вещи пишутся - системные исключений и т.п.). Это хранится в каком-то своем формате и смотреть можно или системными командами в виде текста, или есть системная UDTF JOBLOG_INFO, которая позволяет делать это скулем

SELECT ORDINAL_POSITION,
       MESSAGE_TYPE,
       MESSAGE_TIMESTAMP,
       FROM_LIBRARY,
       FROM_PROGRAM,
       MESSAGE_TEXT,
       MESSAGE_SECOND_LEVEL_TEXT
FROM TABLE(QSYS2.JOBLOG_INFO(JOB_NAME => '316557/QUSER/QZDASOINIT'));

Ну и получаем примерно такое

1	INFORMATIONAL	2024-04-06 09:32:40.412299	QSYS	QWTPIIPP	Задание 400332/QUSER/QZDASOINIT запущено 06.04.24 в 09:32:40 в подсистеме QUSRWRK в библиотеке QSYS. Задание появилось в системе 06.04.24 в 09:32:40.	
2	INFORMATIONAL	2024-04-08 11:47:52.655109	QSYS	QWTCHGJB	ACGDTA для 400332/QUSER/QZDASOINIT не занесен в журнал, код причины 1.	&N Причина . . . . :   Данные Задание учета ресурсов задания 400332/QUSER/QZDASOINIT не были занесены в журнал учета ресурсов системы с именем QSYS/QACGJRN. &P -- Коды причин и их значения приведены ниже: &P -- 1 - Системное значение уровня учета ресурсов (QACGLVL) указывает, что выполнять учет ресурсов этого уровня при входе задания в систему не нужно. &P -- 2 - Журнал QSYS/QACGJRN не в состоянии принимать данные.  Данные учета ресурсов были отправлены в протокол хронологии (QHST) в тексте сообщения CPF1303. Действия по исправлению см. в сообщении CPF1302 протокола хронологии (QHST). &P -- 3 - Журнал учета ресурсов QSYS/QACGJRN был выделен другому заданию.  Данные учета ресурсов были отправлены в протокол хронологии (QHST) в виде текста сообщения CPF1303.
3	INFORMATIONAL	2024-04-08 13:39:45.479460	QSYS	QWTCHGJB	ACGDTA для 400332/QUSER/QZDASOINIT не занесен в журнал, код причины 1.	&N Причина . . . . :   Данные Задание учета ресурсов задания 400332/QUSER/QZDASOINIT не были занесены в журнал учета ресурсов системы с именем QSYS/QACGJRN. &P -- Коды причин и их значения приведены ниже: &P -- 1 - Системное значение уровня учета ресурсов (QACGLVL) указывает, что выполнять учет ресурсов этого уровня при входе задания в систему не нужно. &P -- 2 - Журнал QSYS/QACGJRN не в состоянии принимать данные.  Данные учета ресурсов были отправлены в протокол хронологии (QHST) в тексте сообщения CPF1303. Действия по исправлению см. в сообщении CPF1302 протокола хронологии (QHST). &P -- 3 - Журнал учета ресурсов QSYS/QACGJRN был выделен другому заданию.  Данные учета ресурсов были отправлены в протокол хронологии (QHST) в виде текста сообщения CPF1303.
4	INFORMATIONAL	2024-04-08 13:39:45.479800	QSYS	QZBSSECR	К серверу подключен пользователь *** с клиента **.**.**.**.	&N Причина . . . . :   В данный момент с этим заданием сервера связан пользовательский профайл *** с клиента **.**.**.**.  Имя клиента - это имя удаленной системы TCP/IP, IP-адрес этой системы в десятичной записи с точками, адрес IPv6 либо имя локального хоста.
5	COMPLETION	2024-04-08 13:39:46.070314	QSYS	QWTCHGJB	Задание 400332/QUSER/QZDASOINIT изменено пользователем Y2KU.	
6	INFORMATIONAL	2024-04-08 13:39:46.102125	QSYS	QZDASRV	Следующие специальные регистры были заданы: CLIENT_ACCTNG: Windows 10;SSL=false;admin_user=true, CLIENT_APPLNAME: IBM i Access Client Solutions - Run SQL Scripts, CLIENT_PROGRAMID: file:/C:/Users/*****/IBM/ClientSolutions/acsbundle.jar | Версия: 1.1.8.8 | ИД компоновки: 1380 | 2021-09-13 13:47:59, CLIENT_USERID: *****, CLIENT_WRKSTNNAME: ******	&N Причина . . . . :   Это сообщение отправлено когда любой из клиентских специальных регистров был обновлен.

В общем и целом это все достаточоно удобно.

Спасибо за статью! Интересно смотреть как коллеги по цеху задачу с продуктовыми логами решают.

А в рамках одного лог файла свойства у каждой записи по шейпу совпадают или могут быть разными? Если совпадают – не думали прям на клиенте генерить «форму» для фильтра свойств? Или нужна более сложная фильтрация по логам?

Недавно в целом чем-то схожее решение разработали у себя. Буду наблюдать за гитхабом у вас для референсов :)

Спасибо за отзыв!

Форма объявлена в интерфейсе:

export interface CsLogData {
  //в логе могут быть любые свойства
  [key: string]: any;
  //Минимально нужные данные для одного лога
  '@t': Date;
  '@mt': string;
  '@l'?: 'Verbose' | 'Debug' | 'Information' | 'Warning' | 'Error' | 'Fatal';
}

Форма может быть любой, минимально требуемые параметры: Время, Сообщение, Уровень. Более гибкий вариант.

Генерировать форму отличная идея! В OpenSearch есть подобная система, автоматически сканируются параметры логов, можно по готовому списку фильтровать.

Крутой проект! Как-то не попадался в поисковике. Может сможете подсказать, логи нужно грузить через агрегатор на подобии logstash?

Из документации выглядит скорее как децентрализованное логирование, а не просмотр json файлов напрямую, возможно пропустил что-то в документации.

Как замена Opensearch Dashboard отличная тула!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории