내 연락처 정보
우편메소피아@프로톤메일.com
2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
목차
2. 적절한 로그 수준을 선택합니다(여기서는 logbkck를 예로 사용).
1. ELK Stack(Elasticsearch、Logstash、Kibana)
최신 소프트웨어 개발에서 로깅은 시스템 안정성, 문제 해결 및 성능 모니터링을 보장하는 데 중요한 부분입니다. 이 기사에서는 프로젝트의 로그 수집에 대한 실제 경험을 살펴보고 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>
위 구성은 두 개의 Appender(콘솔 출력용과 파일 출력용)를 정의하고 로그 수준과 출력 형식을 설정합니다.
프로젝트에서 적절한 로깅 수준을 사용하는 것은 로깅 시스템의 효율성을 최대화하는 핵심 요소 중 하나입니다. 적절한 로그 수준을 선택하면 다양한 환경과 단계에서 적절한 수준의 자세한 로그 정보를 얻을 수 있으며 로그가 너무 많거나 적은 것을 방지하여 시스템의 성능과 유지 관리 가능성을 향상시킬 수 있습니다.
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로 설정합니다.
경고 및 오류 처리: 잠재적인 문제 및 오류 조건의 경우 WARN 및 ERROR 수준을 사용합니다. 이러한 수준의 로깅은 팀이 시스템의 문제를 신속하게 식별하고 해결하는 데 도움이 됩니다.
일부 로깅 프레임워크에서는 런타임 시 로그 수준을 동적으로 조정할 수 있습니다. 이는 애플리케이션을 다시 시작하지 않고도 로깅의 자세한 정도를 조정하는 데 유용할 수 있습니다.
적절한 로그 수준을 사용함으로써 개발 팀은 정보 세부 사항과 성능 오버헤드의 균형을 더 잘 맞출 수 있어 다양한 환경과 시나리오에서 최적의 로깅 결과를 보장할 수 있습니다.
로그 컨텍스트 정보를 결합한다는 것은 로그 이벤트의 배경을 더 잘 이해할 수 있도록 로그 레코드에 추가 컨텍스트 정보를 추가하는 것입니다. 이는 특정 요청, 사용자 세션 또는 기타 비즈니스 프로세스를 추적하는 데 유용합니다. Java 프로젝트에서는 SLF4J의 MDC(Mapped Diagnostic Context) 또는 Log4j 2의 ThreadContext를 사용하여 로그 컨텍스트 정보를 추가하는 것이 일반적인 방법입니다.
SLF4J의 MDC를 사용하면 요청 또는 비즈니스 프로세스 내의 로그 컨텍스트에 키-값 정보를 추가하여 전체 처리 과정에서 해당 정보가 지속되도록 할 수 있습니다.
- 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는 SLF4J의 MDC와 유사하고 스레드 범위 내에서 키-값 쌍의 컨텍스트 정보를 저장할 수도 있는 ThreadContext를 제공합니다.
- 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();
- }
- }
- }
로그 상황별 정보를 통합하면 일련의 관련 로그 이벤트를 상호 연결할 수 있어 특정 요청의 흐름이나 사용자 작업을 더 쉽게 추적할 수 있다는 이점이 있습니다. 예를 들어 분산 시스템에서는 고유한 요청 ID를 로그에 추가하여 여러 서비스에서 전체 요청 처리 프로세스를 추적할 수 있습니다.
- 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 스택은 로그 수집, 저장 및 시각화를 위한 오픈 소스 도구 세트입니다.
엘라스틱서치: 대량의 로그 데이터를 저장하고 검색하는 데 사용됩니다. 실시간 데이터에 대한 강력한 검색 및 분석 기능을 제공합니다.
로그스태시: 로그 수집, 필터링, 전달에 사용됩니다. 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"
- }
- }
이 예에서는 지정된 경로 아래의 로그 파일을 모니터링하고 이를 Elasticsearch로 출력하도록 Logstash 입력 플러그인을 구성합니다. 필터 섹션에서는 추가 정보를 구문 분석, 필터링하거나 로그에 추가하는 추가 규칙을 추가할 수 있습니다.
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
이 방법을 사용하여 로그 파일을 보관할 수 있습니다.
로그 롤링 및 보관을 구현함으로써 프로젝트는 로그 파일을 보다 효율적으로 관리하고 시스템이 장기간에 걸쳐 우수한 성능을 유지하도록 보장할 수 있습니다. 이는 문제 해결에 도움이 될 뿐만 아니라 규정 준수 요구 사항에도 도움이 됩니다.
적절한 로깅 프레임워크를 선택하고, 적절하게 구성하고, 적절한 로그 수준을 사용하고, 상황에 맞는 정보를 결합함으로써 프로젝트는 문제 해결, 성능 최적화 및 시스템 모니터링을 강력하게 지원하는 강력한 로깅 시스템을 구축할 수 있습니다. 동시에 실시간 모니터링과 중앙 집중식 스토리지는 팀에게 시스템 상태를 추적할 수 있는 보다 편리한 수단을 제공합니다. 꼼꼼한 로깅은 프로젝트 개발을 위한 기술적 관행일 뿐만 아니라 팀의 전반적인 효율성과 프로젝트 품질을 향상시키는 중요한 보장입니다.