로그에서 최대값을 추출하는 방법

로깅은 관찰 솔루션의 가장 중요한 요소일 것입니다. 로그는 시스템 동작에 대한 기초적이고 풍부한 정보를 제공합니다. 이상적인 세상에서는 로깅에 대한 모든 결정을 내리고 전체 시스템에 걸쳐 일관된 접근 방식을 구현합니다.

그러나 실제 세계에서는 레거시 소프트웨어로 작업하거나 각각 고유한 로깅 형식과 구조를 가진 다양한 프로그래밍 언어, 프레임워크 및 오픈 소스 패키지를 처리할 수 있습니다.

시스템 전반에 걸쳐 로그 형식이 매우 다양하므로 모든 로그에서 가장 많은 가치를 추출하기 위해 취할 수 있는 조치는 무엇입니까? 이것이 바로 이 게시물에서 다룰 내용입니다.

로그를 설계하는 방법, 대규모 시스템 로그인에 대한 과제와 솔루션, 로그 기반 지표와 장기 보존에 대해 생각하는 방법을 살펴보겠습니다.

로그 수준과 형식을 자세히 살펴보겠습니다.

로깅 설계

로그 디자인에는 많은 고려 사항이 있지만 가장 중요한 두 가지 측면은 로그 수준 사용과 구조화된 로그 형식을 사용할지, 구조화되지 않은 로그 형식을 사용할지 여부입니다.

로그 수준

로그 수준은 심각도에 따라 로그 메시지를 분류하는 데 사용됩니다. 사용되는 특정 로그 수준은 로깅 프레임워크나 시스템에 따라 달라질 수 있습니다. 그러나 일반적으로 사용되는 로그 수준에는 다음이 포함됩니다(상세한 정도에 따라 가장 높은 것부터 가장 낮은 것까지).

• TRACE : 포괄적인 기록을 재구성하고 상태 변경을 설명하기 위해 시스템에서 수행하는 모든 작업을 캡처합니다.

• DEBUG : 디버깅 목적으로 자세한 정보를 캡처합니다. 이러한 메시지는 일반적으로 개발 중에만 관련되며 프로덕션 환경에서는 활성화하면 안 됩니다.

• INFO : 시스템 실행에 있어서 중요한 이벤트나 이정표를 전달하기 위해 시스템 작동에 대한 일반적인 정보를 제공합니다.

• 경고 : 주의가 필요할 수 있는 잠재적인 문제나 상황을 나타냅니다. 이러한 메시지는 중요하지 않지만 필요한 경우 기록하고 조사해야 합니다.

• ERROR : 시스템 실행 중 발생한 오류를 나타냅니다. 이러한 메시지는 일반적으로 해결해야 할 문제를 강조하며 시스템 기능에 영향을 미칠 수 있습니다.

적절한 수준에서 로깅하면 시스템 동작을 이해하고, 문제를 식별하고, 문제를 효과적으로 해결하는 데 도움이 됩니다.

구축하는 시스템 구성 요소의 경우 유용한 로그 수준 집합을 정의하는 데 시간을 할애하는 것이 좋습니다. 각 로그 수준에서 메시지에 어떤 종류의 정보가 포함되어야 하는지 이해하고, 로그 수준을 일관되게 사용합니다.

나중에 로그 수준을 제어할 수 없는 타사 애플리케이션을 처리하는 방법에 대해 설명하겠습니다. 또한 귀하가 제어하지만 너무 광범위해서 표준 로그 수준으로 마이그레이션할 수 없는 레거시 애플리케이션도 살펴보겠습니다.

구조화된 로그와 구조화되지 않은 로그

구조화된 로그의 항목은 일반적으로 키-값 쌍 또는 JSON 객체로 잘 정의된 형식을 갖습니다. 이를 통해 일관되고 기계가 읽을 수 있는 로그 항목이 가능하므로 프로그래밍 방식으로 로그 데이터를 더 쉽게 구문 분석하고 분석할 수 있습니다.

구조화된 로깅을 사용하면 고급 로그 쿼리 및 분석이 가능하므로 대규모 시스템에서 특히 유용합니다.

반면, 구조화되지 않은(자유 형식) 로깅은 미리 정의된 구조 없이 사람이 더 읽기 쉬운 형식으로 메시지를 캡처합니다. 이 접근 방식을 통해 개발자는 보다 자연스럽고 유연하게 메시지를 기록할 수 있습니다.

그러나 결과 로그에서 특정 정보를 프로그래밍 방식으로 추출하는 것은 매우 어려울 수 있습니다.

구조화된 로그와 구조화되지 않은 로그 중에서 선택하는 것은 특정 요구 사항과 시스템의 요구 사항 및 제약 조건에 따라 달라집니다. 고급 로그 분석이나 로그 분석 도구와의 통합이 필요할 것으로 예상되는 경우 구조화된 로그는 상당한 이점을 제공할 수 있습니다.

그러나 단순성과 가독성만 필요한 경우에는 구조화되지 않은 로그로도 충분할 수 있습니다.

경우에 따라 중요한 이벤트에는 구조화된 로그를 사용하고 보다 일반적인 메시지에는 구조화되지 않은 로그를 사용하는 하이브리드 접근 방식을 사용할 수도 있습니다.

대규모 시스템의 경우 가능하면 구조화된 로깅에 의지해야 하지만 이렇게 하면 계획에 또 다른 차원이 추가된다는 점에 유의하세요. 구조화된 로그 메시지에 대한 기대는 동일한 필드 집합이 시스템 구성 요소 전체에서 일관되게 사용된다는 것입니다. 이를 위해서는 전략적 계획이 필요합니다.

로깅 문제

여러 구성 요소로 구성된 시스템의 경우 각 구성 요소에는 로그를 관리하기 위한 자체 모델이 있을 가능성이 높습니다. 이로 인해 발생하는 문제를 검토해 보겠습니다.

서로 다른 목적지

구성 요소는 파일, 시스템 로그, stdout 또는 stderr 등 다양한 대상에 기록됩니다. 분산 시스템에서는 효과적인 사용을 위해 이렇게 분산된 로그를 수집하는 것이 번거롭습니다.

이를 위해서는 Sumo Logic의 설치된 수집기 및 호스팅된 수집기를 사용하는 등 로그 수집에 대한 다양한 접근 방식이 필요합니다.

다양한 형식

일부 구성 요소는 특정 형식을 따르지 않고 구조화되지 않은 자유 형식 로깅을 사용합니다. 한편 구조화된 로그는 더 체계적으로 구성될 수 있지만 구조화된 로그가 있는 구성 요소는 완전히 다른 필드 집합을 사용할 수 있습니다.

다양한 로그와 형식에서 얻은 정보를 통합하려면 올바른 도구가 필요합니다.

일관되지 않은 로그 수준

시스템의 구성 요소는 다양한 범위의 로그 수준을 사용할 수 있습니다. 모든 로그 메시지를 중앙 로깅 시스템에 통합하더라도(원하는 대로) 모든 로그 수준의 통합을 처리해야 합니다.

발생하는 한 가지 문제는 서로 다른 로그 수준을 동일하게 처리해야 하는 경우입니다. 예를 들어, 한 구성 요소의 ERROR는 다른 구성 요소의 CRITICAL과 동일할 수 있으므로 즉각적인 에스컬레이션이 필요합니다.

서로 다른 구성 요소의 동일한 로그 수준이 서로 다른 의미를 갖는 경우 반대 문제에 직면하게 됩니다. 예를 들어, 한 구성 요소의 INFO 메시지는 시스템 상태를 이해하는 데 필수적일 수 있지만 다른 구성 요소에서는 너무 장황할 수 있습니다.

로그 저장 비용

대규모 분산 시스템은 많은 로그를 축적합니다. 이러한 로그를 수집하고 저장하는 것은 저렴하지 않습니다. 클라우드의 로그 관련 비용은 시스템 전체 비용의 상당 부분을 차지할 수 있습니다.

이러한 과제에 대처하기

대규모 분산 시스템에 로그인하는 데 따른 어려움은 상당하지만 다음 사례 중 일부를 통해 솔루션을 찾을 수 있습니다.

로그 집계

분산 시스템을 실행할 때는 중앙 집중식 로깅 솔루션을 사용해야 합니다. 시스템의 각 머신에서 로그 수집 에이전트를 실행하면 이러한 수집기가 모든 로그를 중앙 관찰 플랫폼으로 보냅니다.

항상 로그 관리 및 분석 에 중점을 둔 Sumo Logic은 로그 집계 측면에서 동급 최고입니다.

통합 형식으로 이동

애플리케이션과 구성 요소 전반에 걸쳐 분석 및 문제 해결을 위해 로그 데이터를 연관시키려는 경우 다양한 형식의 로그를 처리하는 것은 큰 문제입니다. 한 가지 해결책은 다양한 로그를 통합 형식으로 변환하는 것입니다.

이 작업에 대한 노력의 수준이 높을 수 있으므로 가장 중요한 구성 요소부터 시작하여 단계적으로 작업하는 것을 고려하십시오.

애플리케이션 전반에 걸쳐 로깅 표준 설정

자신의 애플리케이션에 대해 균일한 로그 수준 집합, 구조화된 단일 로그 형식 및 일관된 의미 체계를 채택하는 표준 로깅 접근 방식을 확립하기 위해 노력하세요.

레거시 애플리케이션도 있는 경우 표준을 준수하기 위해 마이그레이션하는 데 따른 위험 및 비용 수준을 평가하세요.

마이그레이션이 불가능할 경우 레거시 애플리케이션을 타사 애플리케이션처럼 취급하십시오.

타사 소스의 로그 강화

타사 소스의 로그를 강화하려면 외부 시스템이나 서비스의 상황별 정보로 로그 데이터를 강화해야 합니다. 이를 통해 로그 이벤트를 더 잘 이해할 수 있으며 문제 해결, 분석 및 모니터링 활동에 도움이 됩니다.

로그를 강화하려면 외부 시스템(예: API 또는 메시지 대기열)을 통합하여 로그 이벤트와 관련된 보충 데이터(예: 사용자 정보, 고객 세부 정보 또는 시스템 지표)를 가져올 수 있습니다.

로그 볼륨, 빈도, 보존 관리

효율적인 로그 관리 및 저장을 위해서는 로그 볼륨, 빈도 및 보존을 신중하게 관리하는 것이 중요합니다.

• 볼륨 : 생성된 로그 볼륨을 모니터링하면 리소스 소비 및 성능 영향을 제어하는 데 도움이 됩니다.

• 빈도 : 이벤트의 중요도와 원하는 모니터링 수준에 따라 기록 빈도를 결정합니다.

• 보존 : 규정 준수 요구 사항, 운영 요구 사항 및 사용 가능한 저장소에 적합한 로그 보존 정책을 정의합니다.

• 순환 : 로그 파일 크기를 효과적으로 관리하기 위해 오래된 로그 파일을 주기적으로 보관하거나 제거합니다.

• 압축 : 로그 파일을 압축하여 스토리지 요구 사항을 줄입니다.

로그 기반 측정항목

로그 데이터 분석에서 파생된 지표는 시스템 동작 및 성능에 대한 통찰력을 제공할 수 있습니다. 작업 로그 기반 측정항목에는 장점과 과제가 있습니다.

이익

• 세분화된 통찰력 : 로그 기반 측정항목은 시스템 이벤트에 대한 상세하고 세분화된 통찰력을 제공하여 패턴, 이상 현상, 잠재적인 문제를 식별할 수 있도록 해줍니다.

• 포괄적인 모니터링 : 로그 기반 지표를 활용하면 시스템을 포괄적으로 모니터링하여 가용성, 성능 및 사용자 경험과 관련된 중요한 지표에 대한 가시성을 확보할 수 있습니다.

• 기록 분석 : 로그 기반 메트릭은 추세 분석, 용량 계획 및 성능 최적화에 사용할 수 있는 기록 데이터를 제공합니다. 시간 경과에 따른 로그 추세를 조사하면 데이터 기반 결정을 내려 효율성과 확장성을 높일 수 있습니다.

• 유연성 및 사용자 정의 : 요구 사항에 가장 의미 있는 이벤트와 데이터 포인트에 초점을 맞춰 애플리케이션이나 시스템에 맞게 로그 기반 지표 추출을 맞춤 설정할 수 있습니다.

도전과제

• 의미 있는 측정항목 정의 : 모든 구성 요소에서 사용할 수 있는 측정항목 세트는 엄청나게 방대하고 이를 모두 캡처하는 것은 의미가 없으므로 로그에서 캡처하고 추출할 측정항목을 식별하는 것은 복잡한 작업이 될 수 있습니다.

  
  

  이를 식별하려면 시스템 동작에 대한 깊은 이해와 비즈니스 목표와의 긴밀한 연계가 필요합니다.

• 데이터 추출 및 구문 분석 : 유용한 측정항목을 추출하기 위해 로그를 구문 분석하려면 특수 도구나 사용자 지정 파서가 필요할 수 있습니다. 로그가 구조화되지 않았거나 한 구성 요소에서 다음 구성 요소로 일관되지 않게 형식이 지정된 경우 특히 그렇습니다.

  
  

  이를 설정하는 데 시간이 많이 걸릴 수 있으며 로그 형식이 변경되거나 새로운 로그 소스가 등장함에 따라 유지 관리가 필요할 수 있습니다.

• 실시간 분석의 필요성 : 로그 기반 지표 처리가 지연되면 오래되거나 관련 없는 지표가 발생할 수 있습니다. 대부분의 상황에서 로그 기반 측정항목을 효과적으로 활용하려면 수신 데이터를 실시간으로 빠르게 처리할 수 있는 플랫폼이 필요합니다.

• 성능 영향 : 구성 요소 프로파일링 메트릭을 지속적으로 캡처하면 시스템 리소스에 추가적인 부담이 가해집니다. 충분한 로그 기반 지표를 캡처하는 것과 적절한 시스템 성능을 유지하는 것 사이에서 적절한 균형을 찾아야 합니다.

• 데이터 노이즈 및 관련성 : 로그 데이터에는 의미 있는 지표에 기여하지 않는 많은 노이즈와 관련 없는 정보가 포함되어 있는 경우가 많습니다. 관련 이벤트에 대한 데이터 수집에 집중하려면 신중한 로그 필터링 및 정규화가 필요합니다.

장기 로그 보존

중앙 집중식 시스템에서 로그 집계로 전환한 후에도 장기 로그 보존 정책을 고려해야 합니다. 이 분야에 대한 중요한 질문을 다루겠습니다.

로그를 얼마나 오랫동안 보관해야 합니까?

로그를 보관해야 하는 기간은 다음을 포함한 여러 요인에 따라 달라집니다.

• 로그 유형 : 일부 로그(접속 로그 등)는 잠시 후 삭제될 수 있습니다. 다른 로그(예: 오류 로그)는 문제 해결에 필요할 경우를 대비해 더 오랫동안 보관해야 할 수도 있습니다.

• 규제 요구 사항 : 의료 및 금융과 같은 산업에는 조직이 특정 기간, 때로는 몇 년 동안 로그를 보관해야 하는 규정이 있습니다.

• 회사 정책 : 회사에는 로그 보관 기간을 규정하는 정책이 있을 수 있습니다.

• 로그 크기 : 로그가 큰 경우 로그를 더 자주 순환하거나 삭제해야 할 수 있습니다.

• 스토리지 비용 : 온프레미스든 클라우드든 로그를 저장하는 위치에 관계없이 스토리지 비용을 고려해야 합니다.

오래된 로그의 세부 수준과 비용을 어떻게 줄이나요?

물론 오래된 로그를 삭제하는 것은 스토리지 비용을 줄이는 가장 간단한 방법입니다. 그러나 이는 다소 부담스러울 수 있으며 때로는 오래된 로그의 정보를 보관하고 싶을 수도 있습니다.

이전 로그의 정보를 유지하면서도 비용 효율적이기를 원하는 경우 다음 조치 중 일부를 취하는 것을 고려하십시오.

• 로그 다운샘플링 : 반복적인 로그 문을 많이 생성하는 구성 요소의 경우 문의 하위 집합(예: 10개 중 1개)만 수집할 수 있습니다.

• 로그 정리 : 대용량 메시지가 포함된 로그의 경우 일부 필드를 삭제할 수 있습니다. 예를 들어 오류 로그에 오류 코드와 오류 설명이 있는 경우 오류 코드만 유지하면 필요한 모든 정보를 얻을 수 있습니다.

• 압축 및 보관 : 오래된 로그를 압축하여 더 저렴하고 접근하기 어려운 저장소(특히 클라우드)로 이동할 수 있습니다. 이는 규정 준수 요구 사항을 충족하기 위해 수년간 저장해야 하는 로그를 위한 훌륭한 솔루션입니다.

결론

이 기사에서는 대규모 시스템에서 로그인을 최대한 활용하는 방법을 살펴보았습니다.

이러한 시스템에 로그인하면 고유한 문제가 발생하지만 로그 집계, 로그를 통합 형식으로 변환, 타사 소스의 데이터로 로그 강화 등 이러한 문제에 대한 잠재적인 솔루션을 살펴보았습니다.

로깅은 관찰 가능성의 중요한 부분입니다. 이 문서에 설명된 사례를 따르면 로그를 효과적으로 관리하여 문제를 해결하고 식별하며 시스템 동작에 대한 통찰력을 얻을 수 있습니다.

그리고 벌목 비용을 최소화하면서 이를 수행할 수 있습니다.

여기에도 게시됨