|
말씀하시는 것이.
Level 별로 차등을 두어 로그를 나기게 하시는 건지?
debug와 error를 구분해서 로그를 남기기 하는 기법인지?
아니면 로그를 저장하는 기법인지 정확히 나와있지 않아. 답변을 드리기가 곤란하네요.
전자는 log4net, log4j에 이미 기능이 있습니다.
후자 역시 이미 log4net, log4j에 지원합니다.
저장하는 기법을 정리한 자료는 다음과 같습니다 .
http://arload.wordpress.com/2008/06/02/log-data-management/
소프트웨어의 현재 상태를 모니터링하거나, 오류시 원인을 파악하기 위해 Log를 남기실 겁니다. 많은 분이 Log4J , Log4NET을 이용하십니다.
하루에 쌓이는 엄청난 로그양때문에, 골치 아프신 경험이 있다면 이 논문을 꼭 읽어 보시길 바랍니다.
이 패턴은 Logging 데이터의 Overflow를 막기 위해 우리가 어떻게 해야되는지 접근 법을 설명하고, Log4XXX(.NET, Java …) 의 내부기능과 비교하여 설명을 합니다.
Linear Bound Log
Assign the log with a maximal size. Once this size is reached, recycle the log space ? the next message will be written to the beginning of the same log, and all previous events are
erased.
로그 최대 사이즈를 할당하는 방법으로, 최대 사이즈에 도달하게 되면, 로그 파일을 재사용하는 방법입니다. 다음 메세지는 동일한 로그파일 시작부분에 쓰여집니다.
하지만 그전에 있었던 모든 events에 대한 정보 (즉 로그 데이터)들은 다 지워지게 됩니다.
Nx Linear Bound Log
Estimate the size you can allocate for log messages, divide it among N Linear Bound Logs. Start writing log messages into the first log. Once the log reaches the predetermined size, create a new log. Once you have reached the end of the size allocated to the N-th log, reuse the first log.
위 Linear Bound Log의 단점을 극복하기 위해, Linerar Bound Log를 여러개를 만드는 방법입니다. 하나의 로그가 맥시엄 사이즈에 도달하게 되면, 새로운 로그를 생성하게 되고 N번 만큼 생성하게 되면 다시 처음 Log 부터 Wirte하는 방법입니다.
Cyclic Buffer Log
Estimate the size you can allocate for log messages. Once the log reaches the predetermined size, overwrite the oldest message with the newest, using the allocated log storage size as a cyclic buffer or a finite FIFO.
가장 이상적인 방법으로 맥시엄 사이즈까지 도달하게 되면, 로그 파일을 다 지우지 않고 처음부터 덮어 쓰는 (OverWritten) 형태의 로그입니다. Log4XXX 에서는 RollingFileAppender를 이용해서 맥시엄 사이즈를 정할수 있을 뿐만 아니라, 좀더 향상된 Feature로 Daily Rolling 을 제공합니다. 약간의 설정으로 Monthly도 가능합니다. ^^ 많은 분들에게 이 방법을 추천합니다.
Database Log
Log messages into a database. By logging to a database instead of a stream, you also gain random access to single events, as well as easy access to event statistic
로그 메세지를 파일 대신에 Database에 남기는 방법입니다. 가장 선호되는 방식이며, 추후 통계나 OLAP과 같은 데이터를 추출하기 용이한 방식입니다.
하지만 오래된 데이터들을 지우는 것이 무조건 좋은 일은 아닐겁니다. 이중에 가치있는 데이터들은 따로 뽑아내야죠 ^^.
위 4가지 정책과 함께 맞물려 같이 사용할수 있는 Purging (불순물을 제거하는) 방법이 존재합니다.
Peoridic Log shrink
Provide the logging system with a mechanism to execute a periodic shrink of the logs by deleting events or logs.
Use a scheduling mechanism to trigger code to go over the logs at pre-determined schedule and delete events from the logs, delete the logs or move events and logs to secondary storage.
가장 기본적인 방법은 미리 정의된 스케줄러를 이용하여 로그들을 지우는 것입니다. 물론 지우기 전에 로그를 다른 매체에 옮기는 방법도 있을겁니다.
Log Digest
When the log management policy is reusing a log, have it create a digest of its contents, before they are lost.
The digest can range from a statistical summary of the events to keeping a few selected events (such as the most severe events) all the way to compressing the entire log.
또 다른 방식으로 Digest하는 방법이 있을 겁니다. Log 데이터들을 요약 정리하는 방법입니다. 어느 시점에 어떤 서비스에 많은 트래픽이 발생했다. 뭐 이런식으로 말이죠 ^^
기존의 파일들을 분석한후 특정 이벤트 (즉 정상적이지 않은 상황에서 발생한 이벤트 코드)를 분석한 후 그 데이터들을 별도로 뽑아내는 방법도 있을 것입다.
이 글의 출처는 PLOP 05년 Conference에 발표된 Log Data Management Pattern 입니다. 간략히 개요를 잡아드렸고, 큰 글자와 그림, 작은 페이지수로 구성된 Paper 이니 읽어보시길 권해드립니다. |