• English日本語한국어
  • 로그인지금 시작하기

사용자의 편의를 위해 제공되는 기계 번역입니다.

영문본과 번역본이 일치하지 않는 경우 영문본이 우선합니다. 보다 자세한 내용은 이 페이지를 방문하십시오.

문제 신고

대규모 로그 수집 구성

수집하고 저장할 로그를 결정했으면 이제 로그를 정리할 차례입니다. 여전히 수백 기가바이트 또는 수십 테라바이트의 로그를 수집하고 있을 가능성이 높습니다. 원래 가지고 있던 것보다 훨씬 적지만 효과적으로 사용하려면 여전히 수고해야 합니다.

이 문제를 해결하기 위해 남아 있는 로그를 주제별 파티션으로 그룹화하고 로그를 구문 분석하여 귀중한 속성을 추출하고 태그를 지정합니다. 이러한 방식으로 로그를 구성하면 다음을 수행할 수 있습니다.

  • 로그 내의 모든 속성에 대한 쿼리
  • 프런트엔드 로그 vs 백엔드 로그와 같은 특정 파티션을 한 번에 관리
  • 쿼리 로드 시간 단축

로그를 분할하는 이유

로그를 개별 파티션으로 분리하면 성능이 향상되고 로그를 더 쉽게 관리할 수 있습니다. 예를 들어 프런트 엔드 로그에서만 찾을 수 있는 특성을 쿼리한다고 가정합니다. 5TB의 로그를 통해 쿼리하면 프런트 엔드 로그만 있는 특정 1TB 파티션을 통해 쿼리하는 것보다 훨씬 오래 걸립니다.

데이터 분할의 목표:

  • 정적이거나 자주 변경되지 않는(예: 사업부, 팀, 환경, 서비스 등) 환경 또는 조직의 개념과 일치하는 데이터 파티션을 만듭니다.
  • 최적의 성능을 위해 각 파티션이 일일 수집 1TB 미만으로 유지되도록 합니다.

파티션에는 두 가지 유형의 보존이 있습니다. 최대 보존을 위해 Standard [표준을] 선택하십시오. 먼 미래에 쿼리할 수 있는 귀중한 데이터에 이것을 사용하십시오. 30일 보존을 위해 Secondary [보조를] 선택하십시오. 덜 가치 있는 데이터 또는 가까운 장래에 필요할 데이터에 사용하십시오.

로그를 구문 분석하는 이유

수집 시 로그를 구문 분석하는 것은 귀하와 조직의 다른 사용자가 로그 데이터를 더 많이 사용할 수 있도록 하는 가장 좋은 방법입니다. 예를 들어 Grok 구문 분석 규칙을 사용하여 구문 분석 전 및 구문 분석 후 두 로그를 비교합니다.

사전 구문 분석:

{
"message": "32 4329 store_Portland"
}

구문 분석 후:

{
"transaction_total": "32",
"purchase_number": "4329",
"store_location": "store_Portland",
}

이를 통해 대시보드 및 경고에서 transaction_total 와 같이 새로 정의된 속성을 쉽게 쿼리할 수 있습니다.

로그 구성

ACME Corp에서 앞으로 몇 달 동안 약 2TB의 로그를 수집할 것임을 알고 있다고 가정해 보겠습니다. Java 앱과 인프라 에이전트에서 오는 로그에 대한 파티션을 생성하려고 합니다. 그들은 표준 보존을 사용하기로 결정하기 위해 먼 미래에 Java 로그를 쿼리해야 할 수도 있다고 생각합니다. 한편, 그들은 최근 인프라 로그만 필요하므로 이에 대해 보조 보존을 사용합니다.

이렇게 하려면:

로그 분할

  1. 왼쪽 탐색 메뉴의 Manage data [데이터 관리] 에서 Data partitions [데이터 파티션 을]클릭한 다음 Create partition rule [파티션 규칙 생성 을]클릭합니다.
  2. Log_로 시작하는 영숫자 문자열로 파티션 이름을 정의합니다. 이 경우 Log_java.
  3. 선택적 설명을 추가합니다.
  4. 파티션에 대한 표준 네임스페이스 보존을 선택합니다.
  5. 규칙의 일치 기준 설정: 유효한 NRQL WHERE 절을 입력하여 이 파티션에 저장할 로그를 일치시킵니다. 이 경우 logtype=java.
  6. 만들기를 클릭하여 새 파티션을 저장합니다.

이렇게 하면 모든 Java 로그에 대해 표준 데이터 보존이 있는 데이터 파티션이 생성됩니다. 인프라 로그를 구성하려면 위와 동일한 단계를 따르되 보존을 보조로 변경하고 쿼리를 logtype=infrastructure로 변경하면 됩니다.

로그 구문 분석

이제 로그가 분할되었으므로 구문 분석할 차례입니다. 이를 구문 분석하면 더 쉽게 쿼리하고 액세스할 수 있도록 로그 내에서 관련 데이터를 가져올 수 있습니다.

로그를 구문 분석하려면:

  1. 로그 UI의 왼쪽 탐색 메뉴에 있는 Manage Data [데이터 관리] 에서 Parsing [구문 분석 을]클릭한 다음 Create parsing rule [구문 분석 규칙 생성 을]클릭합니다.
  2. 새 구문 분석 규칙의 이름을 입력합니다.
  3. 구문 분석할 기존 필드를 선택하거나(기본값은 message) 새 필드 이름을 입력합니다.
  4. 구문 분석하려는 로그와 매치되는 유효한 NRQL WHERE 절을 입력합니다.
  5. 일치하는 로그가 있는 경우 선택하거나 로그 붙여넣기 탭을 클릭하여 샘플 로그에 붙여넣습니다.
  6. 구문 분석 규칙을 입력하고 Output [출력] 섹션에서 결과를 확인하여 작동하는지 확인합니다. (아래 예 참조)
  7. 사용자 정의 구문 분석 규칙을 활성화하고 저장합니다.

다음 예는 구문 분석 규칙을 만드는 구체적인 예를 안내합니다.

로그를 구문 분석하기 위한 Grok 패턴 생성에 대한 자세한 내용은 블로그 게시물 을 참조하십시오.

무엇 향후 계획

로그의 진정한 가치를 발견하고 팀이 로그로 인해 좌절하는 시간을 절약할 수 있게 된 것을 축하합니다! 시스템이 성장하고 수집함에 따라 구문 분석 규칙과 파티션을 유지해야 합니다. New Relic에 대해 더 깊이 알아보고 싶다면 당신을 위해 할 수 있습니다. 다음 문서를 확인하십시오.

  • 로그 데이터 구문 분석: Grok를 사용한 로그 구문 분석을 자세히 살펴보고 GraphQL API인 NerdGraph를 사용하여 로그 구문 분석 규칙을 생성, 쿼리 및 관리하는 방법을 알아봅니다.
  • 로그 패턴: 로그 패턴은 검색 없이 로그 데이터에서 값을 발견하는 가장 빠른 방법입니다.
  • 로그 난독화: 로그 난독화 규칙을 사용하면 특정 유형의 정보가 New Relic에 저장되는 것을 방지할 수 있습니다.
  • 긴 로그(BLOB)에서 데이터 찾기: 광범위한 로그 데이터는 문제를 해결하는 데 도움이 될 수 있습니다. 하지만 로그의 속성에 수천 개의 문자가 포함되어 있다면 어떻게 될까요? New Relic은 이 데이터 중 얼마나 많은 데이터를 저장할 수 있습니까? 그리고 이 모든 데이터에서 유용한 정보를 어떻게 찾을 수 있습니까?

1Get started

2Filter and reduce your log ingest

3Organize your logs

You are here
Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.