App log что это такое

Лог-файл

Лог (log) — это текстовый файл, куда автоматически записывается важная информация о работе системы или программы. Чаще всего говорят о логах сервера. Их записывает программное обеспечение, которое управляет внутренней частью сайта или онлайн-системы. Лог-файл — своеобразный журнал событий.

«IT-специалист с нуля» наш лучший курс для старта в IT

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

Лог-файл (log file) содержит в себе информацию в сокращенном формате. Для обычного пользователя это непонятный набор символов. Но у записей есть смысл, и специалисты должны уметь читать их — в файлах много важной информации о работе.

Профессия / 8 месяцев
IT-специалист с нуля

Попробуйте 9 профессий за 2 месяца и выберите подходящую вам

Для чего нужны логи

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

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

Проверка стабильности. Даже если с системой все хорошо, рекомендуется периодически проверять ее логи. Так можно на ранних этапах найти уязвимость или недочет — еще до того, как он станет проблемой.

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

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

Читайте также Как выбрать IT-специальность в новых реалиях?

Какими бывают логи

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

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

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

Станьте Fullstack-разработчик на Python и найдите стабильную работу
на удаленке

Что может содержаться в логах

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

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

Как правильно читать лог

Вручную. Логи хранятся в файлах с расширением .log. Их можно открыть как обычные текстовые файлы и просмотреть содержимое. Перед этим стоит посмотреть, как настроен формат записи логов, если у вас есть доступ к этим параметрам.

Например, так выглядит формат по умолчанию для лога доступа с веб-сервера:

[доменное имя сайта][IP-адрес пользователя][дата и время визита][тип запроса][URL, к которому обратился пользователь][протокол, по которому пользователь соединился с сайтом][код ответа сервера][количество байт информации, которую передали пользователю][дополнительная информация]

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

Это не единственный возможный способ записи лога. Например, в логе ошибок каждая строчка — это запись об ошибке с полной информацией о ней: датой и временем, адресом страницы, на которой возник сбой, и так далее.

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

Анализаторы бывают разными, например Weblog Expert, Analog и пр. Некоторые из них также умеют интегрироваться с сервисами для сбора статистики, чтобы показывать более полную картинку.

Проверять и читать логи вам понадобится, если вы будете работать с профессиональным ПО для разработчиков, вебмастеров или инженеров. Это сложно только с первого взгляда — если понять принцип, расшифровать их не составит труда. А анализаторы помогут лучше и быстрее сориентироваться в записях.

Таблица лог-файлов

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

Таблицы для файлов ошибок обычно состоят из следующих столбцов:

1. Время и дата: Дата и время возникновения ошибки. Это позволяет определить последовательность ошибок и выявить временные интервалы, в которые они происходят.
2. Уровень ошибки: Уровень критичности ошибки, выраженный текстом (например, DEBUG, INFO, WARNING, ERROR, CRITICAL). Это помогает классифицировать ошибки по степени их важности и срочности исправления.
3. Компонент: Идентификатор или название компонента, в котором произошла ошибка. Это может быть имя модуля, функции, сервиса или другой части программы, что помогает быстро локализовать проблему.
4. Сообщение об ошибке: Текстовое описание самой ошибки. Здесь обычно указывается информация о том, что пошло не так, и какие конкретно ошибки произошли.
5. Пользователь: Информация о пользователе, если применимо. Например, это может быть идентификатор пользователя, который испытал ошибку.
6. Дополнительные атрибуты: В зависимости от характера и требований логирования, таблицы для файлов ошибок могут содержать дополнительные столбцы, такие как IP-адрес клиента, версия программного обеспечения, тип операционной системы и другие атрибуты, которые могут быть полезны для диагностики и анализа ошибок.

Пример таблицы для файлов ошибок:

Время и дата	Уровень ошибки	Компонент	Сообщение об ошибке	Пользователь	IP-адрес
2023-08-05 09:15:27	ERROR	MainApp	Ошибка при сохранении данных в базу данных	User123	192.168.1.100
2023-08-05 09:16:42	WARNING	MainApp	Недостаточно свободного места на диске	—	192.168.1.102
2023-08-05 09:17:10	CRITICAL	Database	Сбой при подключении к базе данных	Admin	192.168.1.103
2023-08-05 09:18:55	ERROR	MainApp	Ошибка валидации данных пользователя	User456	192.168.1.104
2023-08-05 09:19:30	DEBUG	MainApp	Дополнительные данные для отладки	—	192.168.1.105

Таблица для лог-файлов

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

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

IT-специалист с нуля

Наш лучший курс для старта в IT. За 2 месяца вы пробуете себя в девяти разных профессиях: мобильной и веб-разработке, тестировании, аналитике и даже Data Science — выберите подходящую и сразу освойте ее.

Как снять логи для iOS и Android приложений

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

Загружаются из магазина приложений (Google Play или App Store) на мобильном устройстве.

Виды мобильных приложений:

• Нативные
• Веб-приложения
• Гибридные

Распространенные причины возникновения багов в мобильных приложениях:

• Проблемы при установке/удалении мобильных приложений
• Проблемы с поддержкой различных версий ОС и устройств
• Проблемы с соблюдением принципов безопасности
• Проблемы с большим потреблением ресурсов девайса
• Проблемы со скоростью запуска и работы приложения
• Проблемы локализации
• Проблемы при вращении экрана
• Проблемы с непонятными пользователям сообщениями об ошибке
• Проблемы при подключении к интернету
• Проблемы, связанные с условиями работы офлайн
• Проблемы, связанные с низким уровнем заряда батареи
• Проблемы после перезагрузки телефона
• Проблемы после входящих звонков и SMS

Важную роль при диагностировании ошибок в мобильных приложениях играют логи.

Логи и их виды

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

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

Виды логов

Логи мобильных приложений делятся на два основных вида: консольные (обычные) логи и креш-логи.

Консольные логи — это лог-файлы, являющиеся журналом событий и содержащие все записи о системных событиях, ответы устройства на действия пользователя, которые обновляются в режиме реального времени.

Креш-логи — это лог-файлы, которые создаются после экстренного завершения работы программы (креша). Файлы креш-логов имеют расширение .crash или .ips. Креш-логи содержат информацию с момента запуска программы и до экстренного завершения программы.

Как снять логи мобильных приложений

Существуют разные варианты снятия логов для мобильных приложений в зависимости от операционной системы телефона (Android, iOS).

Как снять логи с iOS

Одним из самых распространенных способов для получения логов для приложений iOS является получение с помощью XCode.

XCode — это среда разработки программного обеспечения для платформ macOS и iOS.

Для снятия логов через XCode необходимо:

• Установить XCode
• Подключите устройство к Mac
• Запустить XCode
• Открыть вкладку «Window» — «Devices and Simulators»

• Нажать кнопку «View Device Logs»

• Найти нужный лог-файл и скопировать его в текстовый файл

Также получить логи можно с помощью iMazing (доступно как для Windows, так и для MacOS).

Как снять логи с Андроид

Для того, чтобы снять с Android логи приложения, понадобится Android Studio.

Android Studio — интегрированная среда разработки (IDE) для платформы Android.

Для снятия логов с помощью Android Studio нужно:

• Установить Android Studio
• Создать новый проект в «Android Studio» (при создании нового проекта нужно правильно указать версию Android девайса, с которого необходимо снять логи)

• Включить режим разработчика на Android девайсе
• Подключить устройство через USB к компьютеру
• Выбрать девайс в Android Studio
• Выберите вкладку LogCat
• Воспроизвести ошибку на девайсе или найти по дате воспроизведения логи (если мы знаем время, когда воспроизводилась проблема)

• Выделить нужные логи и скопировать их (правой клавишей мыши → Copy или Ctrl+C)
• Создать файл .txt, добавить в него логи и сохранить их

Также для снятия логов с Android девайсов можно использовать Minimal ADB приложение.

1. XCode — https://developer.apple.com/xc.
2. Android Studio — https://developer.android.com/.
3. iMazing — https://imazing.com/download

Запись значений логов в приложении

Логирование — важная часть процессов разработки. Запись логов помогает обезопасить разработчиков и пользователей от возникновения масштабных сбоев и проблем в приложениях и системах.

Разберемся, что представляют собой лог-файлы и как сделать запись значения лога в AppMaster.

Что такое логи?

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

Зачем нужны логи?

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

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

Логирование и анализ логов — важнейший инструмент в работе IT-специалистов. Он позволяет быстро определять причины и источники проблем и сбоев и исправлять их. В приложениях логи помогают мониторить их работу, вовремя находить баги.

Уровни и типы логов

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

Выделяют четыре основных уровня логов:

• Debug — запись масштабных переходов состояний: обращения к базам данных, запуск и остановка сервиса;
• Warning — внештатные ситуации, например, неправильный формат запроса;
• Error — запись типичных ошибок;
• Fatal — фатальные сбои в работе: отказ доступа к базе данных, нехватка места на диске.

Есть еще два дополнительных уровня логирования:

• Trace — запись процесса по шагам; нужен, когда трудно локализовать проблему;
• Info — общая информация о работе сервиса, службы.

Типы логов:

• Серверные — обращения к серверу и ошибки, которые возникают во время обращений;
• Системные — все системные события;
• Логи авторизации и аутентификации — процессы входа в систему и выхода из нее, проблемы с доступом и другие;
• Логи приложений, которые находятся в этой системе;
• Логи баз данных — обращения к БД.

Как правильно записывать логи?

Чтобы вести логирование, которое удобно использовать, нужно грамотно записывать логи:

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

Логирование в AppMaster

Каждый проект AppMaster поддерживает стандартное логирование. Для работы с логами перейдите во вкладку Project / Deploy Stats. Здесь во вкладке Application Logs вы найдете все логи вашего приложения.

Как записать значение лога в файл приложения?

Система автоматически записывает определенные события в файл, но вы можете записывать необходимые данные дополнительно. Для этого в редакторе бизнес-процессов есть специальный блок Write to log.

У блока два входных поля:

• Label – заголовок, который записывается в лог в формате string;
• Input – любое значение, которое нужно сохранить в логе.

Создание логера

В AppMaster также можно создать логер. Это очень удобно, чтобы записывать только то, что необходимо вам.

Для создания логера создадим модель данных – Log и добавим в нее поля:

• Label – для названия записи;
• Text – для тела записи.

Чтобы сохранять нужные значения в лог, понадобится бизнес-процесс. Создайте новый БП и для задайте поля для блока Start:

• Label – в формате string;
• Text – в формате string.

Дальше добавьте блок Make и создайте запись, передав в нее поля из блока Start.

Запись в БД нужно сохранить, использовав блок Create.

Необходимо создать endpoint для нового БП, чтобы к нему можно было обращаться с фронтенда. Перейдите во вкладку Endpoints и создайте новый эндпоинт. Установите параметры:

1. Выберите метод POST;
2. Задайте URL;
3. Выберите группу;
4. Установите созданный БП.

Созданный бизнес-процесс можно использовать там, где необходимо записать значение лога в приложении.

Подводим итог: что такое логи и зачем они нужны

Лог-файлы — это записи событий, происходящих в приложении. Их можно использовать для устранения неполадок, отслеживания работы и мониторинга безопасности.

Без лог-журналов может быть трудно определить, что вызвало проблему или где она возникла. Логирование поможет определить ошибки, чтобы вы могли решить их до того, как они вызовут серьезные неполадки.

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

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

Новый подход к просмотру логов

Одно время, приходилось много работать с логами. Они могли быть большими и находиться на разных серверах. Требовалось не найти что-то конкретное, а понять почему система ведёт себя не так как надо. По некоторым причинам, лог-агрегатора не было.

Хотелось иметь просмотрщик логов, позволяющий, в любой момент, открыть любой файл, без скачивания на локальную машину, как команда less в linux консоли. Но при этом, должна быть удобная подсветка текста, как в IDE, и фильтрация записей по различным параметрам. Фильтрация и поиск должны работать по событиям в логе, а не по строкам, как grep, это важно когда есть многострочные записи, например ошибки со стектрейсами. Так же должна быть возможность просматривать записи сразу из нескольких файлов на одной странице, смёржив их по таймстемпу, даже если файлы находятся на разных нодах.

И я придумал как сделать такую утилиту!

Log Viewer — это небольшое web-приложение, которое работает на нодах, где лежат логи, и показывает эти логи через Web интерфейс. Это именно просмотрщик, а не агрегатор, нет никакой индексации или считывания всего лога в память, читается только та часть лога, которую пользователь смотрит в текущий момент. Такой подход позволяет почти не занимать ресурсов.

Предвижу вопросы о производительности типа «Разве можно быстро фильтровать записи без индексации? В плохих случаях придётся остcканировать весь лог чтобы найти хоть одну запись подходящую под фильтр». Во первых, сканирование лога работает довольно быстро, 1Гб читается около 3,5сек, это терпимо. Во вторых, обычно известен временной интервал, в котором ищем проблему, если задан фильтр по дате, то будет сканироваться только та часть файла, в которой находятся записи относящиеся к тому времени. Найти границу временного интервала в файле можно очень быстро бинарным поиском.

Отображение лога

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

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

Имя логгера тоже сокращено: «~.SecurityManager». Показывается только имя класса, а пакет сворачивается в «~».

Фолдинг влияет только на отображение, поиск работает по оригинальному тексту. Если совпадение найдётся в сокращённой части текста, то эта часть текста автоматически появится. Также, если пользователь выделит текст и нажмёт Ctrl+C, в буфер скопируется исходный текст, без всяких сокращений.

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

Фильтрация

Набор фильтров зависит от формата лога. Некоторые фильтры доступны всегда, например фильтр по подстроке, а некоторые появляются если в логе присутствует поле определённого типа. Это позволяет создавать специализированные фильтры для некоторых типов полей. Например, если в логе есть поле severity, то в верхней панельке появится такой UI компонент:

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

Добавление фильтров из контекстного меню

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

Для сложных случаев можно задать фильтр с условием написанным на JavaScript. Такой фильтр представляет из себя функцию принимающую одну записи и возвращающую true или false.

Пример фильтра на JavaScript

function isVisibleEvent(text, fields) < var match = text.match(/Task completed, elapsed time: (\d+)ms$/) if (!match) return false // Don't show events not matched the pattern var time = parseInt(match[1]) return time >500 // Show only events where elapsed time is more than a threshold >

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

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

Мелкие, но полезные фичи

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

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

Конфигурация

Я старался сделать конфигурацию как можно проще, чтобы всё работало из коробки. Если попросить пользователя задать формат лога, то большинство просто закроют приложение и пойдут смотреть по старинке. Поэтому формат лога распознаётся автоматически. Конечно, это работает не всегда и часто не точно. Для таких случаев можно задать формат лога вручную в файле конфигурации. Можно использовать паттерны log4j, logback или просто регексп. Если ваш лог не распознался, но вам кажется что должен — создайте issue на GitHub, этим вы поможете проекту.

Самая нужная настройка — список видимых файлов. По умолчанию доступны все файлы с расширением «.log» и видна вся структура каталогов, но это не очень хорошо с точки зрения секьюрити. В конфигурационном файле можно ограничить видимость файлов с помощью списка паттернов типа такого:

logs = [ < path: "/opt/my-app/logs/*.log" >, < path: $"/work/**" > ]

Пользователю будут доступны только .log файлы в директории /opt/my-app/logs и любые файлы в директории ~/work и её поддиректориях.

Более подробная информация в документации на GitHub.

Работа с несколькими нодами

Мёрж файлов, расположенных на разных нодах — это киллер фича, ради которой и затевался проект. Как я уже говорил, файл никогда не скачивается полностью с одной ноды на другую и не индексируется. Поэтому, на каждой из нод должен быть запущен Log Viewer. Пользователь открывает web UI на одной из нод, указывает расположение логов, и Log Viewer коннектится к другим инстансам LogViewer чтобы подгружать содержимое лога через них. Записи из всех открытых файлов мёржатся по таймстемпу и показываются как буд-то это один файл.

Вкратце опишу как это работает под капотом. Когда пользователь открывает страницу, надо показать конец лога, для этого на каждую ноду отправляется запрос «дай последние N записей», где N — количество строк помещающихся на экран. Полученные записи сортируются по таймстемпу, берутся последние N записей и показываются пользователю. Когда пользователь скролит страницу вверх, на все ноды посылается запрос «дай последние N записей с таймстемпом меньше T», где T — таймстемп самой верхней записи на экране. Полученные записи сортируются и добавляются на страницу. При скроле вниз происходит тоже самое, только в другую сторону. Поиск позиции в файле, где находятся записи старше/младше T, работает очень быстро, так как записи отсортированы по таймстемпу и можно использовать бинарный поиск. Там есть много нюансов, но общая схема такая. Мёрж работает только если система смогла определить фомат лога и в каждой записи задан полный тайстемп.

На данный момент, нет UI для выбора файлов на разных нодах, приходится прописывать файлы в параметрах URL в таком виде:
http://localhost:8111/log?path=/opt/my-app/logs/a.log@hostname1&path=/opt/my-app/logs/b.log@hostname1&path=/opt/my-app/logs/c.log@hostname2
здесь каждый параметр «path» задаёт один файл, после «@» указывается хост, на котором лежит файл и запущен инстанс просмотрщика логов. Можно указать несколько хостов через запятую. Если «@» отсутствует — файл находится на текущей ноде. Чтобы не иметь дела с огромными URL, есть возможность задать короткие ссылки в конфигурации, в разделе log-paths = < … >.

Встраивание просмотрщика в своё приложение

Log Viewer можно подключить к своему Java Web приложению как библиотеку, чтобы оно могло показывать пользователю свои логи. Иногда это удобней чем запуск отдельным приложением. Достаточно просто добавить зависимость на библиотеку библиотеку через Maven/Gradle и подключить один конфигурационный класс в spring context. Всё остальное сконфигурится автоматически, log viewer сам распознает какая система логгирования используется и возьмёт из её конфигурации расположение и формат логов. По умолчанию UI маппится на /logs, но всё можно кастомизировать. Пока автоматическая конфигурация работает только с Log4j и Logback.

Это тестировалось на маленьком количестве приложений, если у вас возникнут проблемы — смело пишите в discussions на GitHub.

Что планируется сделать в будущем

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

Есть много идей по мелкому улучшению UI. Например, если в тексте встретился кусок JSON, то хочется чтобы просмотрщик умел показывать его в отформатированном виде, а не одной строкой. Хочется иметь возможность задать фильтр по severity для отдельного класса, а не сразу для всех.

Иногда нет возможности открыть порт на сервере для просмотра логов, есть только SSH доступ. Можно сделать поддержку работы через SSH. Web UI будет подниматься на локальной машине, коннектиться через SSH к серверу и запускать там специального агента. Агент будет принимать команды через input stream и возвращать нужные части лога через output stream.

Буду рад услышать фидбэк.