Когда я пришёл работать в компанию Гриндата шесть лет назад, мои задачи были достаточно стандартными для аналитика, который работает с low-code решениями. Работа с объектной моделью, написание алгоритмов, настройка визуалов - всё что обычно выполняет начинающий специалист в данной области. Однако в процессе моей работы и роста иногда я сталкивался с необходимостью разбираться в тонкостях работы Java, а именно с ошибками, которые возникали в процессе её исполнения.

Эти встречи с Java сначала были случайностью, но со временем превратились в моё новое профессиональное увлечение. Каждый случай сбоя или нестандартного поведения программы становился для меня вызовом; я понял, что за ошибками стоят не просто коды и сообщения, а целые истории о том, как работает система. Этот интерес постепенно перерос в глубокое погружение в мир Java-логов, благодаря чему я стал одним из ведущих экспертов по анализу программных сбоев в GreenData.

В этом цикле статьей я хочу поделиться своим опытом изучения логов Java, чтобы помочь вам лучше понять, как использовать этот навык для диагностики и улучшения работы программных систем.

В первой статье поговорим о том

• зачем аналитикам уметь читать логи?

• какие логи бывают для приложений на GreenData?

• какие уровни логирования можно установить?

• как и какие настройки для сбора логов можно задать?

• что использовать, чтобы открыть лог на чтение?

Зачем аналитикам, интеграторам уметь читать java-логи?

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

В такие моменты нам нужно понять, что такого мы делаем неправильно, от чего возникает многих пугающая ошибка «Обратитесь к администратору».

Первое, что мы делаем - начинаем паниковать, что всё сломали, что всё пропало, но, к счастью, за частую это не так, иногда так, но мы будем верить в лучшее =)

Чтобы на всех парах не мчать к своему руководителю и\или заводить суперблокирующиий блокер стоит успокоиться и попробовать разобраться (иногда это может занять часы, поэтому если сходу не понятно, то смело заводите суперблокирующий блокер), что же произошло, почему появился этот несчастный popUpmessage.

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

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

1. Логирование действий происходящих в Базе данных. В наших проектах используются разные СУБД, сейчас чаще всего это Postgres SQL. В зависимости от проекта такое логирование может быть включено на уровне самой базы данных.

2. Логирование на уровне Балансировщика, Операционной системы, Reddis, в данном списке стоит выделить в первую очередь логирование Redisson, которое мы иногда можем запрашивать для разбора проблем, возникающих при взаимодействии нод нашей платформы.

3. Логирование самого приложения.

Логирование приложения может иметь различные уровни:

1. ERROR:  в этом случае фиксируются критические ошибки, из-за которых невозможно продолжать выполнение программы без её исправления. Примерами являются необработанные исключения или недопустимые состояния данных.

2. WARN (Предупреждение): уровень логирования, при котором фиксируются важные сообщения, которые указывают на потенциальные проблемы в работе приложения. Например, использование устаревших API или возможные неправильные конфигурации. Приложение все еще может продолжать выполнение, но требуются проверка и возможная коррекция.

3.  INFO (Информация): логи будут хранить сообщения общего характера, отражающие основную работу приложения. Это может включать в себя успех операций, состояние системы, статистическую информацию и т.д. Информационные сообщения полезны при обычном мониторинге приложения.

4. DEBUG (Отладка): в этом случае логи содержат детальные технические сообщения, предназначенные для разработчиков приложений в процессе отладки. Включают в себя переменные, состояния объектов, выполнение определенных блоков кода и другую детализированную информацию, которая помогает в поиске и исправлении ошибок.

5. TRACE (Трассировка): Самый подробный уровень логирования, который используется для полной трассировки работы приложения. Включает в себя все сообщения DEBUG уровня, а также дополнительные микродетали операций, такие как вход и выход из функций, детальные шаги в алгоритмах и т.д. используется в основном в процессе интенсивной отладки и диагностики. Отдельно стоит отметить, что в нашем приложении можно включать и отключать.

Также в лог приложения пишутся SQL-запросы который выполняет наша платформа, а также выполнение прикладных запросов (дашборды, отчеты, OLAP, ETL и тд.)

Самый оптимальны уровень логирования для просмотра информации об ошибках - это DEBUG (для разработчиков более полезен TRACE).

Дополнительно хочу отметить, что система пишет параллельно сразу 2 лога: общий лог, который пишет в app.log, и app.error, в который пишутся только ошибки (по сути пишется только уровень ERROR).

Что фиксирует лог приложения? Практически всё, что происходит в системе: выполнение sql-запросов, алгоритмов, работа бизнес-процессов и интеграций, вход и выход пользователей в системе, сброс кэша, актуализацию таблиц, скачивание реестра в эксель, установку гуфов, изменение прав доступа, то есть вообще всё (кроме явных ошибок фронта, об этом будет ниже).

В логах фиксируются действия всех пользователей фактически поименно.

Важно помнить, что в обоих логах приложения отображается дата и время, время указывается по GMT-0 (то есть по Гринвичу) Пермь это GMT+5, Москва GMT+3.

Размер файла лога может варьироваться от нескольких мегабайт до 1гб (больше обычно никто не делает, так как открывать такие файлы довольно затруднительно, чаще делают меньшим размером).

Рассмотрим в общих чертах, как настраивается сам лог.

У GreenData есть файлы с настройкой это либо app.yml либо app.service, которые хранятся в той же папке на сервере, где и само приложение.

Зачастую дополнительно существует файл app.config и в можно изменить параметры лога, а именно задать значения для следующих характеристик:

Dlogback.property.log_extension - расширение файла (log.zip или log.gz)
Dlogback.property.max_history - сколько хранить архивированные логи
Dlogback.property.max_file_size - размер одного .log файла
Dlogback.property.total_size_cap - максимальный размер всех архивированных логов (0 - не удаляются, 500MB - будет храниться только 500MB архивированных логов, старые удалятся. В вашем случае надо ставить 0)

Сам файл (будь то app.log или app.error) по сути является обычным текстовым файлом, для их открытия можно использовать разный софт, лучше всего подходит notepad++ (файлы по 1гб он открыть не сможет, для открытия таких больших файлов я обычно использую TotalComander или GitBash).

Итак, мы с вами разобрались с тем, какие логи бывают, чем их открывать,  даже как их настраивать, но вот вопрос, все ли ошибки фиксируются в логе приложения?

Ответ на данный вопрос, к сожалению, отрицательный, лог приложения не фиксирует ошибки, возникающие на уровне «фронта», но и тут тоже есть небольшой нюанс, который разберем в одной из следующих частей.