Logging

Spring Boot는 모든 내부 로깅에 Commons Logging을 사용하지만 기본 로그 구현은 열어둡니다. Java Util Logging, Log4j2 및 Logback에 대한 기본 구성이 제공됩니다. 각 경우에 로거는 콘솔 출력을 사용하도록 사전 구성되어 있으며, 선택적으로 파일 출력도 사용할 수 있습니다.

기본적으로 스타터를 사용하면 Logback이 로깅에 사용됩니다. 또한 Java Util Logging, Commons Logging, Log4J 또는 SLF4J를 사용하는 종속 라이브러리가 모두 올바르게 작동하도록 적절한 Logback 라우팅도 포함되어 있습니다.

Java에는 많은 로깅 프레임워크가 있습니다. 위 목록이 혼란스러워 보여도 걱정하지 마세요. 일반적으로 로깅 종속성을 변경할 필요가 없으며 Spring Boot 기본값이 잘 작동합니다.

애플리케이션을 서블릿 컨테이너나 애플리케이션 서버에 배포할 때, Java Util Logging API로 수행된 로깅은 애플리케이션의 로그로 라우팅되지 않습니다. 이는 컨테이너나 배포된 다른 애플리케이션에서 수행한 로깅이 애플리케이션의 로그에 나타나는 것을 방지합니다.

로그 형식

Spring Boot의 기본 로그 출력은 다음 예제와 유사합니다:

2025-02-20T14:15:52.373Z  INFO 125657 --- [myapp] [           main] o.s.b.d.f.logexample.MyApplication       : Starting MyApplication using Java 17.0.14 with PID 125657 (/opt/apps/myapp.jar started by myuser in /opt/apps/)
2025-02-20T14:15:52.385Z  INFO 125657 --- [myapp] [           main] o.s.b.d.f.logexample.MyApplication       : No active profile set, falling back to 1 default profile: "default"

다음 항목이 출력됩니다:

• 날짜와 시간: 밀리초 단위로 정밀하며 ISO-8601 형식입니다.
• 로그 레벨: ERROR, WARN, INFO, DEBUG, 또는 TRACE입니다.
• 프로세스 ID.
• 애플리케이션 이름: 대괄호로 구분된 애플리케이션 이름입니다. 이는 spring.application.name 속성을 사용하여 설정할 수 있습니다.
• 스레드 이름: 대괄호로 구분됩니다(콘솔 출력에서는 잘릴 수 있음).
• 로거 이름: 일반적으로 소스 클래스 이름입니다(종종 축약됨).
• 로그 메시지.

Logback은 FATAL 레벨을 ERROR로 매핑합니다.

콘솔 출력

기본 로그 구성은 메시지가 콘솔에 출력되도록 합니다. 기본적으로 ERROR, WARN 및 INFO 레벨 메시지가 로깅됩니다. --debug 플래그로 애플리케이션을 시작하여 “디버그” 모드를 활성화할 수도 있습니다.

$ java -jar myapp.jar --debug

또한 application.properties에서 debug=true를 지정할 수도 있습니다.

디버그 모드가 활성화되면 핵심 로거(임베디드 컨테이너, Hibernate, Spring Boot)가 더 많은 정보를 출력하도록 구성됩니다. 디버그 모드를 활성화해도 애플리케이션이 모든 메시지를 DEBUG 레벨로 로깅하도록 구성되지는 않습니다.

또는 --trace 플래그(또는 application.properties에서 trace=true)로 애플리케이션을 시작하여 “트레이스” 모드를 활성화할 수 있습니다. 이렇게 하면 핵심 로거(임베디드 컨테이너, Hibernate 스키마 생성, Spring 전체)에 대한 트레이스 로깅이 활성화됩니다.

색상 코드 출력

터미널이 ANSI를 지원하는 경우 색상 출력이 가독성을 향상시키는 데 도움이 됩니다. spring.output.ansi.enabled를 설정하여 자동 감지를 재정의할 수 있습니다.

색상 코딩은 로그 레벨에 따라 구성됩니다. 다음 항목을 application.properties에 추가하여 지원되는 색상을 확인할 수 있습니다:

spring.output.ansi.enabled=always

기본 색상은 다음과 같습니다:

또는 %clr 변환 단어를 사용하여 색상을 프로그래밍 방식으로 지정할 수 있습니다. 예를 들어, 다음 설정을 사용하면 텍스트가 노란색으로 출력됩니다:

%clr(%d{yyyy-MM-dd'T'HH:mm:ss.SSSXXX}){yellow}

다음 색상이 지원됩니다:

• blue
• cyan
• faint
• green
• magenta
• red
• yellow

파일 출력

기본적으로 Spring Boot는 콘솔에만 로깅하며 로그 파일을 작성하지 않습니다. 콘솔 출력 외에도 로그 파일을 작성하려면 logging.file.name 또는 logging.file.path 속성을 설정해야 합니다(예: application.properties에서). 두 속성이 모두 설정된 경우 logging.file.path는 무시되고 logging.file.name만 사용됩니다.

다음 표는 logging.* 속성이 함께 사용되는 방법을 보여줍니다:

표 1. 로깅 속성

로그 파일은 10MB에 도달하면 회전하며, 콘솔 출력과 마찬가지로 기본적으로 ERROR 레벨, WARN 레벨 및 INFO 레벨 메시지가 로깅됩니다.

로깅 속성은 실제 로깅 인프라와 독립적입니다. 결과적으로, 특정 구성 키(예: Logback의 logback.configurationFile)는 Spring Boot에서 관리되지 않습니다.

파일 회전

Logback을 사용하는 경우 application.properties 또는 application.yaml 파일에서 로그 회전 속성을 미세 조정할 수 있습니다. 다른 로깅 시스템의 경우 적절한 구성 파일을 직접 제공하거나 기본 구성 위치를 사용하여 로그 회전 설정을 구성해야 합니다.

다음 회전 정책 속성을 사용할 수 있습니다:

로그 레벨

지원되는 모든 로깅 시스템은 logging.level.<logger-name>=<level>을 사용하여 Spring Environment(예: application.properties)에서 로거 레벨을 설정할 수 있습니다. 여기서 level은 TRACE, DEBUG, INFO, WARN, ERROR, FATAL, OFF 중 하나입니다. root 로거는 logging.level.root를 사용하여 구성할 수 있습니다.

다음 예제는 application.properties에서 가능한 로깅 설정을 보여줍니다:

logging.level.root=warn
logging.level.org.springframework.web=debug
logging.level.org.hibernate=error

다음 예제는 application.yaml에서 가능한 로깅 설정을 보여줍니다:

logging:
  level:
    root: "warn"
    org.springframework.web: "debug"
    org.hibernate: "error"

또한 --logging.level.org.springframework=TRACE 명령줄 스위치를 사용하여 로깅 레벨을 설정할 수도 있습니다.

로그 레벨 매핑은 Spring Boot의 로깅 시스템에 독립적입니다. Logback, Log4j2 및 Java Logging API는 모두 다른 레벨 매핑을 사용합니다. 예를 들어, Logback의 TRACE는 Java Logging API의 FINEST와 동일합니다. 또한 Spring Boot의 로깅 시스템은 로깅 시스템 간의 매핑을 제공합니다. 이는 Spring Boot 애플리케이션이 다양한 로깅 시스템을 사용하는 라이브러리에 의존할 때 유용합니다.

로그 그룹

Spring Boot는 관련 로거를 함께 그룹화하여 동시에 구성할 수 있습니다. 예를 들어, 일반적으로 모든 Tomcat 관련 로거를 변경하는 것이 유용할 수 있지만 정확한 이름을 쉽게 기억할 수 없습니다.

이를 위해 Spring Boot는 로그 그룹을 application.properties 또는 application.yaml에서 정의할 수 있도록 허용합니다. 예를 들어, 다음 예제는 “tomcat” 그룹을 application.properties에서 정의합니다:

logging.group.tomcat=org.apache.catalina, org.apache.coyote, org.apache.tomcat

다음 예제는 “tomcat” 그룹을 application.yaml에서 정의합니다:

logging:
  group:
    tomcat: "org.apache.catalina, org.apache.coyote, org.apache.tomcat"

정의되면 그룹의 모든 로거에 대한 로그 레벨을 한 번에 변경할 수 있습니다:

logging.level.tomcat=trace

Spring Boot에는 다음과 같은 사전 정의된 로깅 그룹이 포함되어 있습니다:

사용자 정의 로그 구성

다양한 로깅 시스템은 클래스패스에 적절한 라이브러리를 포함시켜 활성화할 수 있으며, 클래스패스의 루트 또는 다음 Spring Environment 속성으로 지정된 위치에 적절한 구성 파일을 제공하여 추가로 사용자 정의할 수 있습니다: logging.config.

org.springframework.boot.logging.LoggingSystem 시스템 속성을 사용하여 Spring Boot가 특정 로깅 시스템을 사용하도록 강제할 수 있습니다. 값은 LoggingSystem 구현의 정규화된 클래스 이름이어야 합니다. none 값을 사용하여 Spring Boot의 로깅 구성을 완전히 비활성화할 수도 있습니다.

로깅은 ApplicationContext가 생성되기 전에 초기화되므로, Spring @Configuration 파일의 @PropertySources에서 로깅을 제어하는 것은 불가능합니다. 로깅 시스템을 변경하거나 완전히 비활성화하는 유일한 방법은 시스템 속성을 통하는 것입니다.

로깅 시스템에 따라 다음 파일이 로드됩니다:

가능하면 로깅 구성에 -spring 변형을 사용하는 것이 좋습니다(예: logback-spring.xml보다 logback.xml). 표준 구성 위치를 사용하는 경우 Spring이 로그 초기화를 완전히 제어할 수 없습니다.

Java Util Logging에는 ‘실행 가능한 jar’에서 실행할 때 문제를 일으키는 알려진 클래스 로딩 문제가 있습니다. 가능하면 ‘실행 가능한 jar’에서 실행할 때 이를 피하는 것이 좋습니다.

사용자 정의를 돕기 위해 일부 다른 속성이 Spring Environment에서 시스템 속성으로 전송됩니다. 이를 통해 로깅 시스템 구성에서 속성을 사용할 수 있습니다. 예를 들어, application.properties에서 logging.file.name을 설정하거나 환경 변수로 LOGGING_FILE_NAME을 설정하면 LOG_FILE 시스템 속성이 설정됩니다. 전송되는 속성은 다음 표에 설명되어 있습니다:

Logback을 사용하는 경우 다음 속성도 전송됩니다:

지원되는 모든 로깅 시스템은 구성 파일을 구문 분석할 때 시스템 속성을 참조할 수 있습니다. 예제는 spring-boot.jar의 기본 구성을 참조하세요:

• Logback
• Log4j 2
• Java Util logging

로깅 속성에 플레이스홀더를 사용하려면 기본 프레임워크의 구문이 아닌 Spring Boot의 구문을 사용해야 합니다. 특히 Logback을 사용하는 경우 속성 이름과 기본값 사이의 구분자로 : 를 사용해야 하며 :-를 사용하지 않아야 합니다.

LOG_LEVEL_PATTERN(또는 Logback의 경우 logging.pattern.level)만 재정의하여 로그 라인에 MDC 및 기타 임시 콘텐츠를 추가할 수 있습니다. 예를 들어, logging.pattern.level=user:%X{user} %5p를 사용하면 다음 예제와 같이 기본 로그 형식에 “user"에 대한 MDC 항목이 포함됩니다(존재하는 경우).

2019-08-30 12:30:04.031 user:someone INFO 22174 --- [  nio-8080-exec-0] demo.Controller
Handling authenticated request

구조화된 로깅

구조화된 로깅은 로그 출력이 잘 정의된, 종종 기계가 읽을 수 있는 형식으로 작성되는 기술입니다. Spring Boot는 구조화된 로깅을 지원하며 다음 JSON 형식을 기본적으로 지원합니다:

• Elastic Common Schema (ECS)
• Graylog Extended Log Format (GELF)
• Logstash

구조화된 로깅을 활성화하려면 logging.structured.format.console(콘솔 출력용) 또는 logging.structured.format.file(파일 출력용) 속성을 사용하려는 형식의 ID로 설정하세요.

사용자 정의 로그 구성을 사용하는 경우 CONSOLE_LOG_STRUCTURED_FORMAT 및 FILE_LOG_STRUCTURED_FORMAT 시스템 속성을 존중하도록 구성을 업데이트하세요. 예를 들어 CONSOLE_LOG_STRUCTURED_FORMAT의 경우:

Logback

<!-- 인코더를 StructuredLogEncoder로 교체 -->
<encoder class="org.springframework.boot.logging.logback.StructuredLogEncoder">
    <format>${CONSOLE_LOG_STRUCTURED_FORMAT}</format>
    <charset>${CONSOLE_LOG_CHARSET}</charset>
</encoder>

Log4j2

<!-- 레이아웃을 StructuredLogLayout으로 교체 -->
<StructuredLogLayout format="${sys:CONSOLE_LOG_STRUCTURED_FORMAT}" charset="${sys:CONSOLE_LOG_CHARSET}"/>

Spring Boot에 포함된 기본 구성을 참조할 수도 있습니다:

• Logback 구조화된 콘솔 어펜더
• Logback 구조화된 파일 어펜더

Elastic Common Schema

Elastic Common Schema는 JSON 기반 로깅 형식입니다.

Elastic Common Schema 로그 형식을 활성화하려면 적절한 형식 속성을 ecs로 설정하세요:

Properties

logging.structured.format.console=ecs
logging.structured.format.file=ecs

YAML

logging:
  structured:
    format:
      console: "ecs"
      file: "ecs"

로그 라인은 다음과 같이 표시됩니다:

{"@timestamp":"2024-01-01T10:15:00.067462556Z","log.level":"INFO","process.pid":39599,"process.thread.name":"main","service.name":"simple","log.logger":"org.example.Application","message":"No active profile set, falling back to 1 default profile: \"default\"","ecs.version":"8.11"}

이 형식은 MDC에 포함된 모든 키-값 쌍을 JSON 객체에 추가합니다. SLF4J 유창한 로깅 API를 사용하여 addKeyValue 메서드로 로깅된 JSON 객체에 키-값 쌍을 추가할 수도 있습니다.

서비스 값은 logging.structured.ecs.service 속성을 사용하여 사용자 정의할 수 있습니다:

Properties

logging.structured.ecs.service.name=MyService
logging.structured.ecs.service.version=1
logging.structured.ecs.service.environment=Production
logging.structured.ecs.service.node-name=Primary

YAML

logging:
  structured:
    ecs:
      service:
        name: "MyService"
        version: "1"
        environment: "Production"
        node-name: "Primary"

logging.structured.ecs.service.name은 지정되지 않은 경우 spring.application.name으로 기본 설정됩니다. logging.structured.ecs.service.version은 지정되지 않은 경우 spring.application.version으로 기본 설정됩니다.

Graylog Extended Log Format (GELF)

Graylog Extended Log Format은 Graylog 로그 분석 플랫폼을 위한 JSON 기반 로깅 형식입니다.

Graylog Extended Log Format을 활성화하려면 적절한 형식 속성을 gelf로 설정하세요:

Properties

logging.structured.format.console=gelf
logging.structured.format.file=gelf

YAML

logging:
  structured:
    format:
      console: "gelf"
      file: "gelf"

로그 라인은 다음과 같이 표시됩니다:

{"version":"1.1","short_message":"No active profile set, falling back to 1 default profile: \"default\"","timestamp":1725958035.857,"level":6,"_level_name":"INFO","_process_pid":47649,"_process_thread_name":"main","_log_logger":"org.example.Application"}

이 형식은 MDC에 포함된 모든 키-값 쌍을 JSON 객체에 추가합니다. SLF4J 유창한 로깅 API를 사용하여 addKeyValue 메서드로 로깅된 JSON 객체에 키-값 쌍을 추가할 수도 있습니다.

여러 필드는 logging.structured.gelf 속성을 사용하여 사용자 정의할 수 있습니다:

Properties

logging.structured.gelf.host=MyService
logging.structured.gelf.service.version=1

YAML

logging:
  structured:
    gelf:
      host: "MyService"
      service:
        version: "1"

logging.structured.gelf.host는 지정되지 않은 경우 spring.application.name으로 기본 설정됩니다. logging.structured.gelf.service.version은 지정되지 않은 경우 spring.application.version으로 기본 설정됩니다.

Logstash JSON 형식

Logstash JSON 형식은 JSON 기반 로깅 형식입니다.

Logstash JSON 로그 형식을 활성화하려면 적절한 형식 속성을 logstash로 설정하세요:

Properties

logging.structured.format.console=logstash
logging.structured.format.file=logstash

YAML

logging:
  structured:
    format:
      console: "logstash"
      file: "logstash"

로그 라인은 다음과 같이 표시됩니다:

{"@timestamp":"2024-01-01T10:15:00.111037681+02:00","@version":"1","message":"No active profile set, falling back to 1 default profile: \"default\"","logger_name":"org.example.Application","thread_name":"main","level":"INFO","level_value":20000}

이 형식은 MDC에 포함된 모든 키-값 쌍을 JSON 객체에 추가합니다. SLF4J 유창한 로깅 API를 사용하여 addKeyValue 메서드로 로깅된 JSON 객체에 키-값 쌍을 추가할 수도 있습니다.

마커를 추가하면 JSON에 tags 문자열 배열로 표시됩니다.

구조화된 로깅 JSON 사용자 정의

Spring Boot는 구조화된 로깅을 위해 출력되는 JSON 이름과 값에 대해 합리적인 기본값을 선택하려고 시도합니다. 그러나 때로는 자신의 필요에 맞게 JSON을 약간 조정하고 싶을 수 있습니다. 예를 들어, 로그 수집 시스템의 기대에 맞게 일부 이름을 변경하고 싶을 수 있습니다. 또한 유용하지 않다고 생각되는 특정 멤버를 필터링하고 싶을 수도 있습니다.

다음 속성을 사용하면 구조화된 로깅 JSON이 작성되는 방식을 변경할 수 있습니다:

예를 들어, 다음은 log.level을 제외하고, process.id를 procid로 이름을 바꾸고, 고정된 corpname 필드를 추가합니다:

Properties

logging.structured.json.exclude=log.level
logging.structured.json.rename.process.id=procid
logging.structured.json.add.corpname=mycorp

YAML

logging:
  structured:
    json:
      exclude: "log.level"
      rename:
        process:
          id: "procid"
      add:
        corpname: "mycorp"

더 고급 사용자 정의를 위해 StructuredLoggingJsonMembersCustomizer 인터페이스를 구현하는 자체 클래스를 작성하고 logging.structured.json.customizer 속성을 사용하여 선언할 수 있습니다. 또한 META-INF/spring.factories 파일에 나열하여 구현을 선언할 수도 있습니다.

다른 구조화된 로깅 형식 지원

Spring Boot의 구조화된 로깅 지원은 확장 가능하여 자체 사용자 정의 형식을 정의할 수 있습니다. 이를 위해 StructuredLogFormatter 인터페이스를 구현하세요. 제네릭 타입 인수는 Logback을 사용할 때 ILoggingEvent이고 Log4j2를 사용할 때 LogEvent여야 합니다(즉, 구현이 특정 로깅 시스템에 연결됨). 그런 다음 구현은 로그 이벤트로 호출되고 다음 예제와 같이 로깅할 문자열을 반환합니다:

Java

import ch.qos.logback.classic.spi.ILoggingEvent;

import org.springframework.boot.logging.structured.StructuredLogFormatter;

class MyCustomFormat implements StructuredLogFormatter<ILoggingEvent> {

    @Override
    public String format(ILoggingEvent event) {
        return "time=" + event.getInstant() + " level=" + event.getLevel() + " message=" + event.getMessage() + "\n";
    }

}

Kotlin

import ch.qos.logback.classic.spi.ILoggingEvent

import org.springframework.boot.logging.structured.StructuredLogFormatter

class MyCustomFormat : StructuredLogFormatter<ILoggingEvent> {

    override fun format(event: ILoggingEvent): String {
        return "time=" + event.instant + " level=" + event.level + " message=" + event.message + "\n"
    }

}

예제에서 볼 수 있듯이 JSON일 필요는 없고 어떤 형식이든 반환할 수 있습니다.

사용자 정의 형식을 활성화하려면 logging.structured.format.console 또는 logging.structured.format.file 속성을 구현의 정규화된 클래스 이름으로 설정하세요.

구현은 자동으로 주입되는 일부 생성자 매개변수를 사용할 수 있습니다. 자세한 내용은 StructuredLogFormatter의 JavaDoc을 참조하세요.

Logback 확장

Spring Boot에는 고급 구성에 도움이 될 수 있는 Logback에 대한 여러 확장 기능이 포함되어 있습니다. logback-spring.xml 구성 파일에서 이러한 확장 기능을 사용할 수 있습니다.

표준 logback.xml 구성 파일은 너무 일찍 로드되기 때문에 확장 기능을 사용할 수 없습니다. logback-spring.xml을 사용하거나 logging.config 속성을 정의해야 합니다.

확장 기능은 Logback의 구성 스캐닝과 함께 사용할 수 없습니다. 그렇게 하려고 하면 구성 파일을 변경할 때 다음과 유사한 오류가 로깅됩니다:

ERROR in ch.qos.logback.core.joran.spi.Interpreter@4:71 - no applicable action for [springProperty], current ElementPath is [[configuration][springProperty]]
ERROR in ch.qos.logback.core.joran.spi.Interpreter@4:71 - no applicable action for [springProfile], current ElementPath is [[configuration][springProfile]]

프로필별 구성

<springProfile> 태그를 사용하면 활성 Spring 프로필을 기반으로 구성 섹션을 선택적으로 포함하거나 제외할 수 있습니다. 프로필 섹션은 <configuration> 요소 내 어디에서나 지원됩니다. name 속성을 사용하여 구성을 수락하는 프로필을 지정하세요. <springProfile> 태그는 프로필 이름(예: staging) 또는 프로필 표현식을 포함할 수 있습니다. 프로필 표현식을 사용하면 더 복잡한 프로필 로직을 표현할 수 있습니다(예: production & (eu-central | eu-west)). 자세한 내용은 Spring Framework 참조 가이드를 확인하세요. 다음 목록은 세 가지 샘플 프로필을 보여줍니다:

<springProfile name="staging">
    <!-- "staging" 프로필이 활성화되었을 때 활성화될 구성 -->
</springProfile>

<springProfile name="dev | staging">
    <!-- "dev" 또는 "staging" 프로필이 활성화되었을 때 활성화될 구성 -->
</springProfile>

<springProfile name="!production">
    <!-- "production" 프로필이 활성화되지 않았을 때 활성화될 구성 -->
</springProfile>

환경 속성

<springProperty> 태그를 사용하면 Logback 내에서 사용할 Spring Environment의 속성을 노출할 수 있습니다. 이는 Logback 구성에서 application.properties 파일의 값에 접근하려는 경우 유용할 수 있습니다. 이 태그는 Logback의 표준 <property> 태그와 유사한 방식으로 작동합니다. 그러나 직접 value를 지정하는 대신 (Environment에서) 속성의 source를 지정합니다. 속성을 local 범위 이외의 다른 곳에 저장해야 하는 경우 scope 속성을 사용할 수 있습니다. 대체 값(속성이 Environment에 설정되지 않은 경우)이 필요한 경우 defaultValue 속성을 사용할 수 있습니다. 다음 예제는 Logback 내에서 사용할 속성을 노출하는 방법을 보여줍니다:

<springProperty scope="context" name="fluentHost" source="myapp.fluentd.host"
        defaultValue="localhost"/>
<appender name="FLUENT" class="ch.qos.logback.more.appenders.DataFluentAppender">
    <remoteHost>${fluentHost}</remoteHost>
    ...
</appender>

소스는 케밥 케이스(예: my.property-name)로 지정해야 합니다. 그러나 속성은 완화된 규칙을 사용하여 Environment에 추가할 수 있습니다.

Log4j2 확장

Spring Boot에는 고급 구성에 도움이 될 수 있는 Log4j2에 대한 여러 확장 기능이 포함되어 있습니다. 모든 log4j2-spring.xml 구성 파일에서 이러한 확장 기능을 사용할 수 있습니다.

표준 log4j2.xml 구성 파일은 너무 일찍 로드되기 때문에 확장 기능을 사용할 수 없습니다. log4j2-spring.xml을 사용하거나 logging.config 속성을 정의해야 합니다.

확장 기능은 Log4J에서 제공하는 Spring Boot 지원을 대체합니다. 빌드에 org.apache.logging.log4j:log4j-spring-boot 모듈을 포함하지 않도록 해야 합니다.

프로필별 구성

<SpringProfile> 태그를 사용하면 활성 Spring 프로필을 기반으로 구성 섹션을 선택적으로 포함하거나 제외할 수 있습니다. 프로필 섹션은 <Configuration> 요소 내 어디에서나 지원됩니다. name 속성을 사용하여 구성을 수락하는 프로필을 지정하세요. <SpringProfile> 태그는 프로필 이름(예: staging) 또는 프로필 표현식을 포함할 수 있습니다. 프로필 표현식을 사용하면 더 복잡한 프로필 로직을 표현할 수 있습니다(예: production & (eu-central | eu-west)). 자세한 내용은 Spring Framework 참조 가이드를 확인하세요. 다음 목록은 세 가지 샘플 프로필을 보여줍니다:

<SpringProfile name="staging">
    <!-- "staging" 프로필이 활성화되었을 때 활성화될 구성 -->
</SpringProfile>

<SpringProfile name="dev | staging">
    <!-- "dev" 또는 "staging" 프로필이 활성화되었을 때 활성화될 구성 -->
</SpringProfile>

<SpringProfile name="!production">
    <!-- "production" 프로필이 활성화되지 않았을 때 활성화될 구성 -->
</SpringProfile>

환경 속성 조회

Log4j2 구성 내에서 Spring Environment의 속성을 참조하려면 spring: 접두사가 붙은 조회를 사용할 수 있습니다. 이는 Log4j2 구성에서 application.properties 파일의 값에 접근하려는 경우 유용할 수 있습니다.

다음 예제는 Spring Environment에서 spring.application.name 및 spring.application.group을 읽는 applicationName 및 applicationGroup이라는 Log4j2 속성을 설정하는 방법을 보여줍니다:

<Properties>
    <Property name="applicationName">${spring:spring.application.name}</Property>
    <Property name="applicationGroup">${spring:spring.application.group}</Property>
</Properties>

조회 키는 케밥 케이스(예: my.property-name)로 지정해야 합니다.

Log4j2 시스템 속성

Log4j2는 다양한 항목을 구성하는 데 사용할 수 있는 여러 시스템 속성을 지원합니다. 예를 들어, log4j2.skipJansi 시스템 속성을 사용하여 ConsoleAppender가 Windows에서 Jansi 출력 스트림을 사용하려고 시도할지 여부를 구성할 수 있습니다.

Log4j2 초기화 후에 로드되는 모든 시스템 속성은 Spring Environment에서 얻을 수 있습니다. 예를 들어, application.properties 파일에 log4j2.skipJansi=false를 추가하여 ConsoleAppender가 Windows에서 Jansi를 사용하도록 할 수 있습니다.

Spring Environment는 시스템 속성 및 OS 환경 변수에 로드되는 값이 포함되지 않은 경우에만 고려됩니다.

초기 Log4j2 초기화 중에 로드되는 시스템 속성은 Spring Environment를 참조할 수 없습니다. 예를 들어, Log4j2가 기본 Log4j2 구현을 선택할 수 있도록 하는 데 사용하는 속성은 Spring Environment를 사용할 수 있기 전에 사용됩니다.