1.
오래전 개발자와 함께 일을 할 때 가장 많이 했던 작업이 시험입니다. 화면으로 하는 경우도 있지만 서버에 남아 있는 로그를 확인합니다. 이 때 syslog가 남긴 파일을 명령어로 살핍니다.
Syslog.유닉스나 리눅스에서 프로그램을 개발하는 분들에게 아주 익숙한 표준입니다.
syslog는 Unix시스템에서 로그메시지를 처리하기 위해서 제공하는 (매우 오래된)표준 인터페이스 중 하나다. 이것을 이용하면, 시스템이나 응용 프로그램에서 발생하는 각종 메시지를 체계적으로 관리할 수 있다. 또한 표준이기 때문에, 운영체제에 관계없이 동일하게 사용할 수 있다는 장점도 제공한다.
응용프로그램에서 굳이 이러한 메시지를 처리하는 루틴을 만들지 않고, syslog를 사용하는데에는 몇가지 이유가 있다. 일단 메시지처리를 위한 루틴에 특별히 신경쓰지 않고 다른 특화된 모듈에 맡김으로써, 작은것이 아름답다 라는 unix 철학에 부합됨과 동시에, 코딩시 라인수를 대단히 많이 줄일수 있다라는 점 그리고 검증된 안전한 도구라는 점이다.
syslog 사용중에서
아주 오랜 연인같은 syslog이지만 계속 진화하고 있습니다. syslog-ng가 나온지 오래이지고 rsyslog와 같이 LOG의 수집에 촛점을 맞춘 프로젝트도 있습니다. 그러면 성능에서 어떤 차이가 있을까요? “Comparative Analysis of Open-Source Log Management Solutions for Security Monitoring and Network Forensics”는 글입니다.
위의 분석에 오류가 있다고 하는 글도 있습니다. 같이 참고하세요.
Measuring log collection performance
2.
syslog는 표준입니다. 아래와 같은 기능을 하도록 만들어진 RFC5424가 syslog입니다.
로그의 생산, 저장, 분석의 분리를 허가한다.
로그의 생산자는 Facility를 로그 메세지에 붙임으로서 어디서 로그가 왔는지 표시 할 수 있다.
로그의 중요도를 표시한다.
만약 syslog를 이용하지않은 LOG를 통하여 모니터링하고자 할 때 어떻게 하여야 할까요? 요즘과 같이 다양한 시스템들이 넘치는 조건일 때 통합하고자 하는 요구는 더 커집니다. 필요가 있어서 검색하던 중 rsyslog와 비슷하지만 다른 역할을 하는 프로젝트를 찾았습니다. Fluentd입니다. 상세한 기능을 살피기 전에 그림 한장으로 깊은 인상을 받았습니다.
단순합니다. 그래서 아름답습니다.(^^) Fluentd의 기능중 다양한 Plugin을 통하여 다양한 방식으로 output을 처리할 수 있는 점이 좋더군요. 특히 DB와 관련한 부분에 관심이 갔습니다.
국내도 Fluentd를 소개하는 글이 많습니다. 구글링을 하면 설치부터 활용법까지 다양합니다. 그중 최근에 ‘엘라스틱 서치와 fluentd를 이용한 웹서버 로그분석’로 발표한 글입니다.
3.
리눅스를 사용하는 환경이 늘어나면서 서버를 모니터링하는 일이 중요해집니다. 최소한 로그라도 통합관리하면 무척 편합니다. 이와 같은 제품을 LOG Aggregator라고 하네요. Fluentd 말고 다양한 오픈소스가 있습니다. 비교해보시고 환경과 요구에 맞는 제품을 선택하시길.
