 |
|
로그 파일 변환과 분석
지속적인 모니터링을 위해 보통 로그 파일을 뽑아 내려고 개발 기간 동안 복잡한 애플리케이션, 아마도 지속적으로 실행되어야 하는 애플리케이션이 사용된다. 여기에서 로그 파일은 애플리케이션의 동작을 기록한 것이다. 몇몇 동작은 상세한 내부 진단이 될 수 있다. 여기에는 버그를 격리하고 타 시스템 및 소프트웨어 컴포넌트와 상호작용하는 실타래를 푸는 데 필요한 핵심 정보가 들어있다. 몇몇 기록된 동작은 애플리케이션에 의해 초기화된다. 즉 설정 파일을 읽거나 혹은 리스닝을 위해 포트를 여는 것을 말한다. 다른 동작은 서비스를 위한 요청에 의해 생성될 수도 있다.
문제점: 옛 애플리케이션을 위한 지속적인 모니터링
애플리케이션의 목적에 따라, 시스템 관리자는 에러가 발생하거나 긴급한 상황에 실시간으로 대응해야 할 때 프로그램의 해당 로그 파일을 살펴 본다. 로그는 어떤 일이 있었는지 보여주는 충분히 가치 있는 정보가 된다. 예를 들어 아파치 HTTP 서버 로그에서만 찾을 수 있는 트래픽과 사용 패턴에 대해 생각해 보라.
확보된 모든 로그 파일이 적어도 최소한의 정보를 포함하고 있다면 이상적이다. 모든 로그 파일의 포맷이 통합되어 있다면 특히, 시스템 관리자 관점에서 보면 훨씬 더 좋다고 할 수 있다. 일관성이 있으면 로그를 더 쉽게 읽을 수 있고, 동질성이 있으면 정보에서 핵심이 되는 사건을 뽑아내는 자동화된 도구를 더 쉽게 개발할(비용이 더 싸진다는 것을 언급하는 것이 아님) 수 있다.
그러나 현실은 그렇지 않다. 개별 애플리케이션마다 차이가 매우 심하다(기반으로 하고 있는 운영체제와 프로그래밍 언어 라이브러리 등처럼 말이다). 몇몇 애플리케이션은 이미 확고히 자리 잡고 있어서, 통일성을 획득하기 위한 변경이 불가능하다(이른바 "레거시 애플리케이션"이다). 그리고 비용이 많이 들어 가며, 여유가 없는 개발 주기는 새로운 기능을 위해 쓰이지, 개선을 위해서는 쓰이지 않는 것이 추하지만 현실이다.
해법: 로그 파일 데이터 변환
한 가지 해법이 모든 것을 제대로 돌려 놓을 수 없음을 깨닫는다면 로그 파일 데이터를 발전되고 있는 표준 또는 사실상(de-facto) 표준이나 또 다른 기준에 맞춰 변환하고, 최신 분석 도구에 적용하는 것이 훨씬 더 실용적이다. 예를 들어, CBE 포맷은 컴퓨팅 시스템에서 발생하는 상황과 사건을 기록, 추적, 분석하는 폭넓은 표준을 정의하기 위한 노력의 일환이다. XML 기반의 CBE 데이터를 분석하고 처리하는 많은 도구가 존재한다.
그러나 실제로 임의의 로그 파일을 CBE로 변환하는 것은 실용적일지는 모르나 처리가 쉽지도 않고, 비용도 만만치 않다. 애플리케이션과 로그 파일 포맷이 너무나 다양해 매우 많은 변환을 작성하는 것 자체가 초인적인 노력을 요하는 작업이 될 수 있다.
이클립스 TPTP GLA와 어댑터 설정 편집기를 사용하면 변환 생성이 단순해지고, 그럼으로써 CBE 전환(migration)이 쉬워진다. GLA는 어댑터 설정 편집기에서 만든 어댑터를 로그 파일에 적용해 CBE 데이터를 내놓는다. 어댑터 설정 편집기는 필요하면 수제(handmade) 자바 클래스(즉 정적 어댑터)를 실행할 수 있고 로그 파일을 레코드, 필드, 값으로 분리하고, CBE 데이터로 다시 조합하기 위해 일련의 규칙을 실행할 수도 있다. 후자의 어댑터 형식은 규칙 기반 어댑터(rule-based adapter)로 코딩이 전혀 필요 없다. 더욱 좋은 것은 어댑터 설정 편집기는 이클립스에서 실행되며, 점진적으로 어댑터를 정의하고 테스트할 수 있는 풍부한 어댑터 개발 환경을 제공한다. 마지막으로 결과로 나온 CBE 이벤트 파일을 면밀히 조사하기 위해, 자신이 작성한 코드를 GLA를 통합하거나 IBM Log와 Trace Analyzer 같은 써드 파티 도구를 사용할 수 있다.
이번 튜토리얼에서는 일반적인 리눅스 애플리케이션 로그 파일을 CBE 이벤트로 변환해주는 이클립스 TPTP GLA와 어댑터 설정 편집기의 기능을 어떻게 이용하는지 보여준다. 직접 다루던 로그 파일과 약간의 정규 표현식 노하우로 로그를 통합되고, 구조화된 CBE 포맷으로 변환할 수 있다.
| 
