Как аналитик учился java log читать. Часть первая: логи бывают разные
Когда я пришёл работать в компанию Гриндата шесть лет назад, мои задачи были достаточно стандартными для аналитика, который работает с low-code решениями. Работа с объектной моделью, написание алгоритмов, настройка визуалов — всё что обычно выполняет начинающий специалист в данной области. Однако в процессе моей работы и роста иногда я сталкивался с необходимостью разбираться в тонкостях работы Java, а именно с ошибками, которые возникали в процессе её исполнения.
Эти встречи с Java сначала были случайностью, но со временем превратились в моё новое профессиональное увлечение. Каждый случай сбоя или нестандартного поведения программы становился для меня вызовом; я понял, что за ошибками стоят не просто коды и сообщения, а целые истории о том, как работает система. Этот интерес постепенно перерос в глубокое погружение в мир Java-логов, благодаря чему я стал одним из ведущих экспертов по анализу программных сбоев в GreenData.
В этом цикле статьей я хочу поделиться своим опытом изучения логов Java, чтобы помочь вам лучше понять, как использовать этот навык для диагностики и улучшения работы программных систем.
В первой статье поговорим о том
зачем аналитикам уметь читать логи?
какие логи бывают для приложений на GreenData?
какие уровни логирования можно установить?
как и какие настройки для сбора логов можно задать?
что использовать, чтобы открыть лог на чтение?
Зачем аналитикам, интеграторам уметь читать java-логи?
Для начала нужно принять тот факт, что мы так или иначе допускаем ошибки в своей работе, иногда такие проблемы возникают по не знанию функционала, особенностей решения или просто сегодня плохой день и все валится из рук.
В такие моменты нам нужно понять, что такого мы делаем неправильно, от чего возникает многих пугающая ошибка «Обратитесь к администратору».
Первое, что мы делаем — начинаем паниковать, что всё сломали, что всё пропало, но, к счастью, за частую это не так, иногда так, но мы будем верить в лучшее =)
Чтобы на всех парах не мчать к своему руководителю и\или заводить суперблокирующиий блокер стоит успокоиться и попробовать разобраться (иногда это может занять часы, поэтому если сходу не понятно, то смело заводите суперблокирующий блокер), что же произошло, почему появился этот несчастный popUpmessage.
Для этого я предлагаю вам погрузится, в мир с которым наши замечательный разработчики сталкиваются почти ежедневно, немного приоткрыть дверь в мир, где кругом непонятные словесночисловые конструкции.
Для начала давайте узнаем, какие логи вы можете встретить при работе с приложениями на базе GreenData.
Логирование действий происходящих в Базе данных. В наших проектах используются разные СУБД, сейчас чаще всего это Postgres SQL. В зависимости от проекта такое логирование может быть включено на уровне самой базы данных.
Логирование на уровне Балансировщика, Операционной системы, Reddis, в данном списке стоит выделить в первую очередь логирование Redisson, которое мы иногда можем запрашивать для разбора проблем, возникающих при взаимодействии нод нашей платформы.
Логирование самого приложения.
Логирование приложения может иметь различные уровни:
ERROR: в этом случае фиксируются критические ошибки, из-за которых невозможно продолжать выполнение программы без её исправления. Примерами являются необработанные исключения или недопустимые состояния данных.
WARN (Предупреждение): уровень логирования, при котором фиксируются важные сообщения, которые указывают на потенциальные проблемы в работе приложения. Например, использование устаревших API или возможные неправильные конфигурации. Приложение все еще может продолжать выполнение, но требуются проверка и возможная коррекция.
INFO (Информация): логи будут хранить сообщения общего характера, отражающие основную работу приложения. Это может включать в себя успех операций, состояние системы, статистическую информацию и т.д. Информационные сообщения полезны при обычном мониторинге приложения.
DEBUG (Отладка): в этом случае логи содержат детальные технические сообщения, предназначенные для разработчиков приложений в процессе отладки. Включают в себя переменные, состояния объектов, выполнение определенных блоков кода и другую детализированную информацию, которая помогает в поиске и исправлении ошибок.
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).
Итак, мы с вами разобрались с тем, какие логи бывают, чем их открывать, даже как их настраивать, но вот вопрос, все ли ошибки фиксируются в логе приложения?
Ответ на данный вопрос, к сожалению, отрицательный, лог приложения не фиксирует ошибки, возникающие на уровне «фронта», но и тут тоже есть небольшой нюанс, который разберем в одной из следующих частей.
