Logging에 대하여

Logging는 단순히 문제 해결에만 집중하면 Logging 시스템 자체를 한번 더 검토 해볼 필요가 있다고 생각한다. 단순히 생각했을 때 아래 같은 질문에 쉽게 답변을 할 수 있어야 한다고 생각한다.

• 장애가 어디에서 어떤식으로 발생 했는지 ? 원인은 ?
• 시스템 자체가 잘 동작하는지 ?
• 퍼포먼스는 어떠한지?
• 정보에 대한 보안 조치는 제대로 되고 있는지?
• 어떤 작업자(사용자 혹은 관리자)가 무엇을 하고 있는지 ? 문제는 없는지

이런 물음에 쉽게 답변 할 수 있는 Logging 시스템을 설계하려면 기존의 Logging 시스템들은 어떻게 설계 되었는지 한번 볼 필요가 있다.

기존의 Logging 시스템은 로그의 중요도에 따라 보통 Security logging, Operational logging, Application logging 등으로 나뉘는데 여기서 앞의 두개는 operation system level에서의 Log이고 이 글에서는 중점적으로 Application logging에 대해 다룰 예정이다.

아래 Application Logging 을 설계함에 있어서 Transport, format, contents에 대하여 논의해 보자.

Log Transport

Log를 전달함에 있어서 우리가 사용할 수 있는 방법은 여러 가지가 있다. 기존의 대부분 시스템에서는 Local에 저장하는 방식을 택했지만 MSA로 서비스를 구성하고 클러스터링으로 서비스를 하다보니 중앙 집중식으로 관리하는 방식을 많이 택한다.

TCP 방식

제일 간단한 방식으로 open source로 제공하는 서비스는 fluent 등이 있다. AWS CloudWatch도 이 방식을 지원한다. 이 방식의 유일한 단점은 만약 Logging 서버가 가용하지 않으면 Application 동작도 지장을 받는다. ( 잃어버려서는 않될 데이터는 이 방식으로 구성 하는 것도 좋은 방식이다.)

UDP 방식

이 방식은 UDP로 Logging서버로 전송함으로써 application에서는 데이터의 전달의 정확성에 대하여 고려하지 않는다. 이방식을 채용하면 Logging문제로 application 서비스가 다운되거나 올라가지 않는 문제를 해결할 수 있다. 하지만 UDP는 데이터의 신뢰성을 보장하지 않으므로 중요한 데이터(결제 정보) 같은 건 UDP로 전송하는 것을 추천 하지 않는다

Write to file

이 방식은 전통적인 방식이므로 추가로 설명하지 않겠다. 현재 거의 모든 Logging 라이브러리는 이것을 지원한다. 더 나아가서 FTPS혹은 SCP로 Logging 서버에 전송 할 수 있다.

위의 Transport 방식에 대해 설명 및 장단점에 대하여 정리하였다. Log transport 방식 선택에 있어 Logging 데이터의 중요도에 따라 보안 혹은 민감한 데이터는 file 방식, 그외 데이터는 UDP 방식을 선택하는 것이 좋을 것 같다.

Log format

Format에 대하여 역사적으로 많은 시도와 이에 대한 고찰이 있었다. Anton Chuvakin의 Logging and Log Management 책을 보면 log format에대하여 자세히 다루고 있다. 간략히 요약하면 plain-text(ASCII부터 Unicode로 발전) 부터 복합해진 xml 등 발전 과정을 거쳤는데 최종적으로 퍼포먼스와 공간때문에 binery를 사용하는 것으로 발전되었다고 한다. 또한 보안 등 문제 떄문에 암호화된 binary를 사용하게 되었다고 한다.

이 책은 2012년에 출판된 책이라 현재 json으로 된 log format에 대해 다루지 않고 있다. 또한 지단로보트의 이글을 통해서 graylog를 알게 되었다. 또한 graylog의 GELF format에 찾아보았더니 이것이 내가 생각하는 기능을 모두 제공하는 format이라는 것도 알게 되었다.

간단하게 GELF format의 특징을 알아보면

• UDP로 전송할 수 있다
• 기본적으로 압축을 지원한다
• Log contents에 담고싶은 contents을 key:value 형식으로 담을 수 있다(2차원 json은 지원하지 않음)

현재 docker log format도 GELF format를 사용하는 것으로 파악된다.

Log Content

Log의 존재 목적은 Log를 통해서 우리가 무언가를 얻기 위함이다. 시스템 장애, 시스템 정상 동작 여부, 이상 동작 여부, 해킹 공격 여부, 처리된 값이 정상적인지, 퍼포먼스 정보 등이 있다. 이런 정보들을 수요에 따라 분류하고 잘 formatting를 하여야만 후단의 Log 분석과 Log 모티터링을 잘 할 수 있다.

기존에는 모든 Log를 plain text 형식으로만 전송하고 plain text에 특정한 패턴의 문자들을 넣어 분석 혹은 모티터링에서 filtering를 할 수 있게 만들었다. 이런 방식은 log 색인 하기도 쉽지 않고 검색하기 위하여 Computing power도 많이 사용된다.

위에서 언급했듯이 GELF format를 사용하게 되면 이런 문제를 해결 할 수 있다. 이 format은 log를 생성할때부터 key:value 방식으로 생성하여 graylog로 하여금 쉽게 분류하여 저장하게 만든다.(graylog에 대하여 다음에 한편의 문장으로 정리할 예정이다.)

마치며..

이번 글에서는 Logging에 대하여 이모저모를 정리해 보았다. 결국에는 쉽게 모니터링하고 쉽게 분석하고 다른 시스템에 dependency를 줄이는 것이 logging 시스템 설계에서 핵심인것 같다.

추후 글에서는 graylog에 대하여 설명하고 spring에서 graylog를 어떻게 사용하는지에 대하여 다루어 볼 생각이다.

 

Ref:

Anton Chuvakin의 Logging and Log Management 

https://jsonobject.tistory.com/299https://jsonobject.tistory.com/299

오픈 소스 로그 수집 관리 플랫폼, Graylog 기술 및 도입 전략 정리