моя контактная информация
Почтамезофия@protonmail.com
2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Оглавление
1. Выберите подходящую систему ведения журналов.
2. Настройте структуру журналов
3. Используйте соответствующие уровни журналирования.
2. Выберите соответствующий уровень журнала (в качестве примера возьмите logbkck).
3. Динамическая настройка уровней журнала.
4. В сочетании с контекстной информацией журнала.
2. Использование ThreadContext в Log4j 2.
3. Используйте контекстную информацию
5. Мониторинг в реальном времени и централизованное хранение.
1. Стек ELK (Elasticsearch, Logstash, Kibana)
2. Настройте Logstash для сбора журналов.
3. Используйте Kibana для визуализации и анализа.
5. Централизованное хранилище и масштабируемость
6. Перенос и архивирование журналов
1. Настройте стратегию прокрутки системы журналов.
2. Прокрутка в зависимости от размера файла.
3. Настройте стратегию прокрутки
4. Архивируйте старые файлы журналов.
В современной разработке программного обеспечения ведение журнала является важной частью обеспечения стабильности системы, устранения неполадок и мониторинга производительности. В этой статье будет рассмотрен практический опыт сбора журналов в проектах, а также представлены технологии, инструменты и некоторые передовые методы сбора журналов, обычно используемые в проектах Java.
В проектах Java выбор подходящей структуры журналов является первым шагом в сборе журналов. Распространенные платформы ведения журналов включают Log4j, Logback и SLF4J. Вот несколько соображений по выбору фреймворка:
После выбора платформы ведения журналов ее необходимо настроить соответствующим образом в соответствии с потребностями проекта. Вообще говоря, файлы конфигурации обычно представляют собой XML-файлы или файлы свойств, которые содержат информацию об уровнях журнала, форматах вывода, местоположениях назначения и т. д.
Если взять в качестве примера Logback, то простой пример файла конфигурации выглядит следующим образом:
- <!-- logback.xml -->
- <configuration>
-
- <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
- <encoder>
- <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
- </encoder>
- </appender>
-
- <appender name="FILE" class="ch.qos.logback.core.FileAppender">
- <file>logs/myapp.log</file>
- <encoder>
- <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
- </encoder>
- </appender>
-
- <logger name="com.example" level="DEBUG"/>
-
- <root level="INFO">
- <appender-ref ref="CONSOLE"/>
- <appender-ref ref="FILE"/>
- </root>
-
- </configuration>
Приведенная выше конфигурация определяет два Appenders, один для вывода на консоль, а другой для вывода в файл, а также устанавливает уровень журнала и формат вывода.
Использование соответствующих уровней журналирования в вашем проекте является одним из ключевых факторов обеспечения максимальной эффективности вашей системы журналирования. Выбор подходящего уровня журнала может гарантировать получение соответствующего уровня подробной информации журнала в различных средах и на разных этапах, избегая при этом слишком большого или слишком малого количества журналов для повышения производительности и удобства обслуживания системы.
В системе ведения журналов Java общие уровни журналирования включают в себя:
Используйте DEBUG на этапе разработки: На этапе разработки используйте уровень DEBUG, чтобы получить более подробную информацию журнала, которая поможет разработчикам отслеживать и отлаживать код.
- public class ExampleClass {
- private static final Logger logger = LoggerFactory.getLogger(ExampleClass.class);
-
- public void someMethod() {
- // ...
- logger.debug("Debug information for developers");
- // ...
- }
- }
Производственная среда использует INFO: В производственной среде установите уровень журнала INFO, чтобы обеспечить регистрацию критической информации во время выполнения и одновременно сократить количество избыточной отладочной информации.
Предупреждения и обработка ошибок: Для потенциальных проблем и ошибок используйте уровни WARN и ERROR. Эти уровни журналирования помогут командам быстро выявлять и устранять проблемы в системе.
Некоторые платформы ведения журнала допускают динамическую настройку уровней журнала во время выполнения, что может быть полезно для настройки подробностей журнала без перезапуска приложения.
Используя соответствующие уровни журналирования, группы разработчиков могут лучше сбалансировать детализацию информации и затраты на производительность, обеспечивая оптимальные результаты журналирования в различных средах и сценариях.
Объединение контекстной информации журнала заключается в добавлении дополнительной контекстной информации в записи журнала, чтобы лучше понять предысторию событий журнала. Это полезно для отслеживания конкретных запросов, пользовательских сеансов или других бизнес-процессов. В проектах Java обычной практикой является использование MDC (сопоставленного диагностического контекста) SLF4J или ThreadContext Log4j 2 для добавления информации о контексте журнала.
MDC SLF4J позволяет добавлять информацию о ключе и значении в контекст журнала внутри запроса или бизнес-процесса, чтобы она сохранялась на протяжении всей обработки.
- import org.slf4j.Logger;
- import org.slf4j.LoggerFactory;
- import org.slf4j.MDC;
-
- public class RequestContextLogger {
- private static final Logger logger = LoggerFactory.getLogger(RequestContextLogger.class);
-
- public void processRequest(String requestId, String userId) {
- try {
- // 将请求ID和用户ID放入日志上下文
- MDC.put("requestId", requestId);
- MDC.put("userId", userId);
-
- // 处理请求
- logger.info("Processing request");
-
- // ...
- } catch (Exception e) {
- logger.error("Error processing request", e);
- } finally {
- // 清理日志上下文,确保不影响其他请求
- MDC.clear();
- }
- }
- }
Log4j 2 предоставляет ThreadContext, который похож на MDC SLF4J и также может хранить контекстную информацию пар ключ-значение в области потока.
- import org.apache.logging.log4j.LogManager;
- import org.apache.logging.log4j.Logger;
- import org.apache.logging.log4j.ThreadContext;
-
- public class RequestContextLogger {
- private static final Logger logger = LogManager.getLogger(RequestContextLogger.class);
-
- public void processRequest(String requestId, String userId) {
- try {
- // 将请求ID和用户ID放入日志上下文
- ThreadContext.put("requestId", requestId);
- ThreadContext.put("userId", userId);
-
- // 处理请求
- logger.info("Processing request");
-
- // ...
- } catch (Exception e) {
- logger.error("Error processing request", e);
- } finally {
- // 清理日志上下文,确保不影响其他请求
- ThreadContext.clearAll();
- }
- }
- }
Преимущество включения контекстной информации журнала заключается в том, что вы можете сопоставить ряд связанных событий журнала, что упрощает отслеживание потока конкретного запроса или действий пользователя. Например, в распределенной системе весь процесс обработки запроса можно проследить по нескольким сервисам, добавив в журнал уникальный идентификатор запроса.
- public class DistributedService {
- private static final Logger logger = LoggerFactory.getLogger(DistributedService.class);
-
- public void processDistributedRequest(String requestId) {
- try {
- MDC.put("requestId", requestId);
-
- // 处理分布式请求
- logger.info("Processing distributed request");
-
- // ...
- } catch (Exception e) {
- logger.error("Error processing distributed request", e);
- } finally {
- MDC.clear();
- }
- }
- }
Благодаря объединению контекстной информации записи журнала больше не являются изолированными событиями, а органически связаны друг с другом, предоставляя более мощный инструмент для устранения неполадок системы и оптимизации производительности.
Мониторинг в реальном времени и централизованное хранение являются важными аспектами управления журналами в проекте. Благодаря этим средствам команда может отслеживать рабочее состояние системы в режиме реального времени, обнаруживать потенциальные проблемы и при необходимости своевременно устранять неполадки. В проектах Java обычно используемые инструменты включают ELK Stack (Elasticsearch, Logstash, Kibana), Splunk и т. д.
ELK Stack — это набор инструментов с открытым исходным кодом для сбора, хранения и визуализации журналов.
Elasticsearch: Используется для хранения и извлечения больших объемов данных журнала. Он предоставляет мощные возможности поиска и анализа данных в реальном времени.
Логсташ: Используется для сбора, фильтрации и пересылки журналов. Logstash может нормализовать данные журналов из разных источников и отправить их в Elasticsearch для хранения.
Кибана: Предоставляет интуитивно понятный пользовательский интерфейс для запроса, визуализации и анализа данных журналов, хранящихся в Elasticsearch. С помощью Kibana команды могут создавать информационные панели, диаграммы и выполнять углубленный анализ данных журналов.
Настройка Logstash в вашем проекте для сбора журналов является важным шагом для ELK Stack. Logstash поддерживает множество источников ввода и целей вывода, которые можно определить с помощью простых файлов конфигурации.
- # logstash.conf
-
- input {
- file {
- path => "/path/to/your/application.log"
- start_position => "beginning"
- }
- }
-
- filter {
- # 可添加过滤规则
- }
-
- output {
- elasticsearch {
- hosts => ["localhost:9200"]
- index => "your_index_name"
- }
- }
В этом примере настраивается входной плагин Logstash для мониторинга файлов журналов по указанному пути и вывода их в Elasticsearch. В разделе фильтра можно добавлять дополнительные правила для анализа, фильтрации или добавления дополнительной информации в журналы.
Kibana предоставляет интуитивно понятный пользовательский интерфейс, доступ к которому можно получить через веб-браузер. В Kibana вы можете создавать информационные панели, диаграммы и выполнять сложные запросы и анализ.
С Kibana вы можете легко:
мониторинг в реальном времени: Просматривайте данные журнала в реальном времени и в любой момент узнавайте о рабочем состоянии системы.
Поиск неисправностей: Выполняйте поиск в журналах по конкретным критериям, чтобы найти основную причину потенциальных проблем.
Анализ производительности: Используйте диаграммы и инструменты визуализации для анализа узких мест в производительности системы.
Splunk — еще один широко используемый инструмент управления журналами, который предоставляет комплексное решение для сбора, поиска, анализа и визуализации журналов.
Сбор журналов: Splunk поддерживает сбор данных журналов из нескольких источников (файлов, баз данных, сетевого трафика и т. д.).
Поиск и анализ в реальном времени: Предоставляет функции поиска и анализа в реальном времени, поддерживает сложные запросы и отображает результаты поиска через визуальный интерфейс.
Панели мониторинга и отчеты: Пользователи могут создавать собственные информационные панели и отчеты для мониторинга и анализа производительности системы.
И ELK Stack, и Splunk имеют мощные механизмы централизованного хранения, которые могут хранить большие объемы данных журналов. Это централизованное хранилище не только облегчает поиск и анализ журналов, но также обеспечивает масштабируемость системы и позволяет обрабатывать крупномасштабные журналы приложений.
Мониторинг в реальном времени и централизованное хранилище являются ключом к обеспечению стабильности и производительности проекта. Используя такие инструменты, как ELK Stack и Splunk, команда проекта может отслеживать журналы в режиме реального времени в сложных системных средах, а также своевременно устранять неполадки и оптимизировать производительность. Возможности этих инструментов не только повышают эффективность команды, но также обеспечивают лучшую поддержку и масштабируемость проектов.
Прокрутка и архивирование журналов являются важными практиками в проекте. Это обеспечивает разумное управление файлами журналов, предотвращает проблемы с хранением, вызванные чрезмерным количеством файлов журналов, и помогает поддерживать нормальную работу системы. Ниже приведены некоторые распространенные методы реализации прокрутки журналов и архивирования в проектах Java.
Большинство платформ ведения журналов предоставляют стратегии чередования, которые можно установить через файлы конфигурации. Эти политики определяют, когда следует переходить к новым файлам журнала, а когда удалять старые файлы журнала. На примере Logback настройте базовую стратегию роллинга:
- <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
- <file>logs/myapp.log</file>
- <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
- <fileNamePattern>logs/myapp.%d{yyyy-MM-dd}.log</fileNamePattern>
- <maxHistory>30</maxHistory>
- </rollingPolicy>
- <encoder>
- <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
- </encoder>
- </appender>
В приведенной выше конфигурации используетсяTimeBasedRollingPolicy
, который будет обновлять файл журнала в зависимости от времени.maxHistory
Указывает количество сохраняемых файлов журнала. Файлы журнала, превышающие это число, будут удалены.
Иногда прокрутки по времени может быть недостаточно, и вам также необходимо выполнить прокрутку в зависимости от размера файла журнала. Этого можно добиться, настроив размер файла:
- <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
- <file>logs/myapp.log</file>
- <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
- <fileNamePattern>logs/myapp.%d{yyyy-MM-dd}.%i.log</fileNamePattern>
- <maxFileSize>5MB</maxFileSize>
- <maxHistory>30</maxHistory>
- </rollingPolicy>
- <encoder>
- <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
- </encoder>
- </appender>
В приведенной выше конфигурации используетсяSizeAndTimeBasedRollingPolicy
, который сортирует файлы журналов в зависимости от размера файла и времени.maxFileSize
Указывает максимальный размер каждого файла журнала.
Иногда в проектах может потребоваться смена журналов в зависимости от пользовательских условий. В этом случае рассмотрите возможность реализации собственной стратегии прокрутки. Например, смена файлов журналов на основе определенных бизнес-правил:
- public class CustomRollingPolicy extends TimeBasedRollingPolicy<ILoggingEvent> {
- // 实现自定义的滚动逻辑
- }
Затем используйте собственную стратегию прокрутки в файле конфигурации:
- <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
- <file>logs/myapp.log</file>
- <rollingPolicy class="com.example.CustomRollingPolicy">
- <!-- 自定义配置 -->
- </rollingPolicy>
- <encoder>
- <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
- </encoder>
- </appender>
Помимо обновления файлов журналов, обычной практикой также является архивирование старых файлов журналов. Этого можно добиться, регулярно перемещая старые файлы журналов в каталог архива, чтобы они не занимали слишком много места на диске.
Или используйте программный подход для реализации его в коде Java:
- import java.io.File;
- import java.nio.file.Files;
- import java.nio.file.Path;
- import java.nio.file.StandardCopyOption;
- import java.time.LocalDate;
- import java.time.format.DateTimeFormatter;
-
- public class LogArchiver {
- public static void archiveLogFile(String logFileName, String archiveDirectory) {
- String currentDate = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd"));
- File logFile = new File(logFileName);
- File archiveDir = new File(archiveDirectory);
-
- if (!archiveDir.exists()) {
- archiveDir.mkdirs();
- }
-
- Path sourcePath = logFile.toPath();
- Path targetPath = new File(archiveDir, logFile.getName() + "." + currentDate + ".log").toPath();
-
- try {
- Files.move(sourcePath, targetPath, StandardCopyOption.REPLACE_EXISTING);
- } catch (Exception e) {
- e.printStackTrace();
- }
- }
- }
Вызывается в периодических задачахarchiveLogFile
Этот метод можно использовать для архивирования файлов журналов.
Внедряя прокрутку и архивирование журналов, проекты могут более эффективно управлять файлами журналов и гарантировать, что система будет поддерживать хорошую производительность в течение длительных периодов времени. Это не только полезно для устранения неполадок, но также помогает обеспечить соответствие требованиям.
Выбрав подходящую структуру журналирования, настроив ее соответствующим образом, используя соответствующие уровни журналирования и объединив контекстную информацию, проекты могут создать мощную систему журналирования, которая обеспечивает надежную поддержку для устранения неполадок, оптимизации производительности и мониторинга системы. В то же время мониторинг в реальном времени и централизованное хранилище предоставляют командам более удобные средства отслеживания состояния системы. Тщательное ведение журнала — это не только техническая практика разработки проекта, но и важная гарантия повышения общей эффективности команды и качества проекта.