구조화된 로깅 : 장점, 방법, 이유

이 게시물에서는 구조화된 로깅과 그 사용에 대한 근거를 소개합니다. 이해를 강화하기 위해 몇 가지 간단한 예를 제공합니다. AWS Lambda와 Java로 서버리스 함수를 작성하는 방법을 배울 때 구조화된 로깅 개념을 접하게 되었습니다. 이를 계기로 Structured Logs의 개념이 궁금해져서 더 자세히 살펴보기로 했습니다.

 

 

구조화된 로깅

일반적으로 응용 프로그램에서 생성된 로그는 어떤 식으로든 형식이 지정된 일반 텍스트입니다. 예를 들어 Java 응용 프로그램의 일반적인 로그 형식은 다음과 같습니다:

[Sun Apr 02 09:29:16 GMT] book.api.WeatherEventLambda INFO: [locationName: London, UK temperature: 22 action: record timestamp: 1564428928]

 

 

이 로그는 포맷되어 있지만 구성되어 있지 않습니다. 다음 구성 요소로 포맷된 것을 확인할 수 있습니다:

1. 타임스탬프(발생 시점)
2. 정규화된 클래스 이름(발생 위치)
3. 로깅 수준(이벤트 유형)
4. 메시지(이 부분은 일반적으로 표준화되지 않은 부분이므로 앞으로 살펴보겠지만 일부 구조를 갖추면 가장 큰 이점을 얻을 수 있습니다.)

 

구조화된 로그는 일반 텍스트 형식을 사용하지 않고 XML 또는 일반적으로 JSON과 같은 보다 형식적인 구조를 사용합니다. 이전에 표시된 로그는 구성된 경우 다음과 같이 합니다:

구조화된 통나무

 

 

로그의 메시지 부분은 일반적으로 관심이 있는 부분입니다. 그러나 메시지 주변에는 메타데이터가 많이 있으며, 이는 사용자가 하려는 작업의 맥락에서 유용하거나 유용하지 않을 수 있습니다.

사용 중인 로깅 프레임워크에 따라 표시되는 메타데이터를 사용자 지정할 수 있습니다. 위의 예는 Log4J2 로깅 프레임워크를 통해 AWS Lambda 함수(Java로 작성)에서 생성되었습니다.

구성은 다음과 같습니다:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration packages="com.amazonaws.services.lambda.runtime.log4j2">
    <Appenders>
        <Lambda name="Lambda">
            <JsonLayout compact="true" eventEol="true" objectMessageAsJsonObject="true" properties="true"/>
        </Lambda>
    </Appenders>
    <Loggers>
        <Root level="info">
            <AppenderRef ref="Lambda"/>
        </Root>
    </Loggers>
</Configuration>

 

 

JsonLayout 태그는 이 경우 로거에 구조화된 형식(즉, JSON)을 사용하도록 지시하는 태그입니다.

이를 INFO 수준 로그의 appender로 사용하고 있으므로 ERROR 또는 DEBUG와 같은 다른 수준의 로그는 구조화되지 않습니다. 이러한 유연성은 모든 로그를 구성하는 것이 아니라 모니터링 또는 분석에 필요한 부분만 구성하는 것이 좋습니다.

다음은 로그를 생성하는 AWS Lambda 함수의 일부입니다. 날씨 이벤트를 읽고 기록할 값을 맵에 입력한 다음 해당 맵을 로거에 전달합니다.

final WeatherEvent weatherEvent = objectMapper.readValue(request.getBody(), WeatherEvent.class);

HashMap<Object, Object> message = new HashMap<>();
message.put("action", "record");
message.put("locationName", weatherEvent.locationName);
message.put("temperature", weatherEvent.temperature);
message.put("timestamp", weatherEvent.timestamp);

logger.info(new ObjectMessage(message));

 

 

이를 달성하는 데는 여러 가지 방법이 있습니다. Log4J2에서 인터페이스를 구현하는 고유한 클래스를 작성한 다음 이 클래스의 인스턴스 필드를 채우고 이 인스턴스를 로거에 전달할 수 있습니다.

 

 

이 모든 것의 요점

로그를 구조화하는 이유는 무엇입니까? 이 질문에 답하려면 로그 더미(실제 목재 로그)가 있다고 가정합니다: 

"왼쪽 아래 로그 위에 있는 로그를 검사하십시오."라고 말하면 어떤 로그를 참조하고 있는지 추측해야 합니다.

이제 이 통나무들이 오두막집으로 구성되었다고 가정해 보겠습니다.

"앞문을 구성하는 통나무들을 검사하라."라고 말한다면, 여러분은 정확히 어디를 봐야 할지 알 것입니다.

이것이 구조가 좋은 이유입니다. 그것은 물건을 찾는 것을 더 쉽게 만듭니다.

 

 

로그 쿼리

구조화된 로그는 AWS CloudWatch, Kibana 및 Splunk와 같은 모니터링 도구를 통해 효율적으로 인덱싱할 수 있습니다. 즉, 원하는 로그를 훨씬 쉽게 찾을 수 있습니다. 이러한 도구는 로그를 쿼리하는 정교한 방법을 제공하므로 문제 해결 또는 분석을 보다 쉽게 수행할 수 있습니다.

예를 들어, 이 스크린샷은 AWS CloudWatch Insights에서 옥스포드의 날씨 이벤트가 발생한 로그를 검색하는 방법을 보여줍니다. 로그의 메시지 구성 요소 아래에 있는 locationName 속성을 참조하고 있습니다.

필터링 및 정렬을 통해 훨씬 정교한 쿼리를 수행할 수 있습니다.

예를 들어, "온도가 20도 이상이었던 상위 10개의 날씨 이벤트를 보여주세요"라고 말할 수 있습니다(영국에서는 드물게 발생).

 

 

로그에서 이벤트 트리거

로그를 쿼리할 수 있는 또 다른 이점은 측정을 시작할 수 있다는 것입니다. 그런 다음 이러한 측정(AWS CloudWatch 용어로 메트릭이라고 함)을 사용하여 알림 전송과 같은 이벤트를 트리거할 수 있습니다.

AWS에서는 측정할 항목을 나타내는 메트릭을 만든 다음 해당 메트릭의 조건에 따라 CloudWatch Alarm을 설정하고 경보를 사용하여 예를 들어 SNS에 알림을 트리거하면 됩니다.

예를 들어, 런던의 온도가 20도를 넘을 때마다 이메일을 보내려고 하면, 예를 들어 5시간 동안 런던에서 읽은 평균 온도에 대한 메트릭을 만든 다음 이 메트릭이 20도를 초과할 때 활성화되는 경보를 생성할 수 있습니다. 그런 다음 이 경보를 사용하여 SNS 항목에 대한 알림을 트리거할 수 있습니다. 그러면 SNS 주제의 구독자들은 따뜻한 옷을 입지 말아야 한다는 것을 알게 될 것입니다.

 

 

구조화된 로그에는 단점

구조화된 로그를 사용할지 여부는 시스템에 대해 구상하는 전체 모니터링 및 분석 전략에 따라 결정되어야 합니다. 예를 들어, 다른 서비스에 연결되는 광범위한 시스템의 일부인 서버리스 애플리케이션이 있는 경우에는 이러한 다양한 서비스의 로그를 중앙 집중화하여 시스템을 통합적으로 볼 수 있도록 해야 합니다. 이 시나리오에서는 로그를 구성하면 모니터링 및 분석에 큰 도움이 됩니다.

반면에 단일 데이터 소스의 데이터만 제공하고 다른 서비스에 연결하지 않는 매우 단순한 애플리케이션을 사용하는 경우에는 로그를 구성할 필요가 없을 수 있습니다. 오래된 격언을 잊지 말자꾸나: 간단하게 해 멍청아.

따라서 "구조화된 로그에 단점이 있습니까?"라는 질문에 답하려면 필요하지 않은 곳에서 로그를 사용해야 합니다. 추가 구성에 시간을 낭비할 필요가 없으며 간단한 로그만 있으면 문제가 해결됩니다.

 

 

결론

구조화된 로깅은 로그를 보다 효율적으로 분석할 수 있을 뿐만 아니라 시스템에서 더 나은 모니터링 기능을 구축하는 데도 도움이 됩니다. 또한 시스템의 추세를 알릴 수 있는 관련 쿼리 및 메트릭 및 알림 설정을 통해 비즈니스 분석 기능을 향상시킬 수 있습니다.

간단히 말해서, 구조화된 로깅은 단순히 로깅에 관한 것이 아닙니다. 모니터링과 분석을 모두 향상시키는 아키텍처 패턴을 주도하는 도구입니다.