로그, 트레이스 등 여러 가지 이름이 있지만, 여기서 이야기하는 것은 프로그램이 돌아가는 상황을 한 군데에다 모아서 나중에 따로 볼 수 있도록 만드는 시스템을 말한다.
주로 디버깅 용도로 많이 사용하지만, 서버 프로그램의 로그 시스템 같은 경우는 모니터링용으로도 사용하기도 한다. 예를 들자면, 게임 서버에서 플레이어의 행동을 일일이 기록해 뒀다가 나중에 문제가 생겨 플레이어로부터 클레임이 들어왔을 때, 이전에 기록해뒀던 로그를 증거자료로 활용하는 일이 대표적이라 할 수 있겠다.
2 로그 시스템이 갖춰야할 요건
2.1 필수적인 기능
간단하고 견고해야 한다.
프로그램 전체에서 액세스 가능해야한다.
메시지의 분류를 지원해야 한다.
ON/OFF를 설정할 수 있어야 한다.
2.2 부가적인 기능
메시지가 들어온 시간을 기록해야 한다.
다중 스레드에 안전해야 한다.
빨라야한다.
3 플랫폼에서 미리 제공하는 로그 관련 기능
WindowsEventLog - 윈도우즈에서는 이벤트 로그라는 기능을 통하여, 중앙 집중화된 로그를 만들 수 있다.
UnixSysLog - 유닉스에서는 syslog 데몬이 제공하는 서비스를 이용하여, 중앙 집중화된 로그를 만들 수 있다.
4 로그 시스템을 새로 만들어야 하는가?
플랫폼에서 제공하는 로그 기능의 가장 큰 문제점(?)은 분류를 자세하게 만들 수 없다는 점이다. 그냥 하나의 레벨값으로만 로그를 분류하는 것은 프로그래머에게 생각보다 큰 고민(?)을 안겨준다.
예를 들어 로그를 다음과 같이 분류하고 싶다고 하자. 앞쪽이 대분류이고, 뒤쪽이 대분류 안에서의 소분류다.
이 하나하나를 정밀하게 분류해, 어떤 류의 로그는 남기고, 어떤 것은 남기지 않는다...라는 걸 적어도 WindowsEventLog, UnixSysLog는 지원하지 않는다. 물론 로그를 남길 때, 로그 앞에다가 해당 문자열을 붙여서 무조건 로그한 다음에, 나중에 볼 때 필터링을 통해 볼 수?있다. 하지만 여기서의 목표는 해당 분류의 로그를 끈 경우, 로그 자체가 남지 않는 것이다.
![[WWW]](/img/moin-www.gif){kind=small}
Apache Logging Services Project 