• EnglishEspañol日本語한국어Português
  • 로그인지금 시작하기

이 한글 문서는 사용자의 편의를 위해 기계 번역되었습니다.

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

문제 신고

로깅 모범 사례 가이드

New Relic 로깅 모범 사례 가이드에 오신 것을 환영합니다. 여기에서 로그 기능을 최적화하고 데이터 소비를 관리하는 방법에 대한 자세한 권장 사항을 찾을 수 있습니다.

많은 로그가 있습니까? 최적화 및 관리 방법에 대한 자습서를확인하십시오.

전달 로그

다음은 로그 전달 문서 를 보완하기 위한 로그 전달에 대한 몇 가지 팁입니다.

  • 로그를 전달할 때 New Relic 인프라 에이전트 및/또는 APM 에이전트 를 사용하는 것이 좋습니다. New Relic 에이전트를 사용할 수 없는 경우 지원되는 다른 에이전트(예: FluentBit, Fluentd 및 Logstash)를 사용하십시오.

    지원되는 로깅 에이전트에 대한 몇 가지 Github 예제 구성은 다음과 같습니다.

  • 전달하는 모든 데이터에 logtype 속성을 추가합니다. 이 속성은 내장된 구문 분석 규칙을 사용하는 데 필요하며 데이터 유형을 기반으로 사용자 정의 구문 분석 규칙을 생성하는 데에도 사용할 수 있습니다. logtype 속성은 잘 알려진 속성으로 간주되며 로그 요약 정보를 위한 빠른 시작 대시보드에서 사용됩니다.

  • 잘 알려진 로그 유형에 대해 내장된 구문 분석 규칙 을 사용하십시오. 관련 logtype 속성을 설정하면 여러 잘 알려진 로그 유형의 로그를 자동으로 구문 분석합니다.

    다음은 인프라 에이전트가 전달한 로그에 logtype 속성을 추가하는 방법의 예입니다.

    logs:
    - name: mylog
    file: /var/log/mylog.log
    attributes:
    logtype: mylog
  • 다음과 같은 다른 일반적인 데이터 유형에 대한 로그를 전달하기 위해 New Relic 통합을 사용하십시오.

데이터 분할

하루에 1TB 이상의 로그 데이터를 사용하는 경우 기능적 및 주제별 그룹화를 제공하는 방식으로 데이터를 분할하는 계획을 포함하여 로그에 대한 수집 거버넌스 계획을 수립해야 합니다. 파티션당 1TB 이하의 모범 사례를 제안합니다. 이는 성능과 유용성을 모두 제공합니다. 모든 로그를 단일 계정의 하나의 거대한 "버킷"(기본 로그 파티션)으로 보낸 경우 쿼리 속도가 느려지거나 쿼리 실패가 발생할 수 있습니다. 자세한 내용은 NRQL 쿼리 비율 제한을 참조하세요.

쿼리 성능을 향상시키는 한 가지 방법은 검색되는 시간 범위를 제한하는 것입니다. 오랜 기간 동안 로그를 검색하면 더 많은 결과가 반환되고 더 많은 시간이 필요합니다. 가능하면 1주일보다 긴 검색을 피하고 시간 범위 선택기를 사용하여 더 작고 더 구체적인 기간으로 검색 범위를 좁힙니다.

검색 성능을 향상시키는 또 다른 방법은 데이터 파티션 을 사용하는 것입니다. 다음은 데이터 파티션에 대한 몇 가지 모범 사례입니다.

  • 로그 온보딩 프로세스 초기에 파티션을 사용해야 합니다. 사용자가 특정 로그를 검색하고 찾는 위치를 알 수 있도록 파티션 사용 전략을 만듭니다. 이렇게 하면 나중에 로그 여정에서 파티션을 구현하는 경우 경고, 대시보드 및 저장된 보기를 수정할 필요가 없습니다.

  • 제한을 피하고 쿼리 시간을 개선하려면 총 일일 수집이 하루에 1TB를 초과할 때 특정 데이터 유형에 대한 데이터 파티션 규칙 을 만듭니다. 특정 대용량 인프라 로그(예: K8S 로그, CDN 로그, VPC 로그, Syslog 로그 또는 웹 로그)는 자체 파티션의 좋은 후보가 될 수 있습니다.

  • 수집 볼륨이 낮은 경우에도 데이터를 논리적으로 분리하거나 개별 데이터 유형에서 쿼리 성능을 향상시키기 위해 데이터 파티션을 사용할 수도 있습니다.

  • 더 짧은 보존 시간을 원하는 데이터에 대해 보조 데이터 파티션 네임스페이스 를 사용하십시오. 보조 데이터 파티션에는 기본적으로 30일의 보존 기간이 있습니다.

  • 로그 UI에서 데이터 파티션을 검색 하려면 적절한 파티션을 선택하고 파티션 선택기를 열고 검색하려는 파티션을 확인해야 합니다. NRQL을 사용하는 경우 FROM 절을 사용하여 검색할 Log 또는 Log_<partion> 를 지정합니다. 예를 들어:

    FROM Log_<my_partition_name> SELECT * SINCE 1 hour ago

    또는 여러 파티션에서 로그를 검색하려면:

    FROM Log, Log_<my_partition_name> SELECT * SINCE 1 hour ago

파싱 로그

수집 시 로그를 구문 분석하는 것은 귀하와 조직의 다른 사용자가 로그 데이터를 더 쉽게 사용할 수 있도록 하는 가장 좋은 방법입니다. 속성을 구문 분석하면 쿼리 시 데이터를 구문 분석할 필요 없이 해당 속성을 사용하여 쉽게 Logs [로그] UI 및 NRQL에서 검색할 수 있습니다. 이를 통해 다음과 같은 환경에서도 쉽게 사용할 수 있습니다. 그리고 대시보드.

로그를 구문 분석하려면 다음을 수행하는 것이 좋습니다.

  • 수집 시 로그를 구문 분석하여 검색 또는 생성 시 사용할 수 있는 attributes (또는 필드)를 생성합니다. 그리고 알림. 속성은 데이터 또는 숫자 값의 문자열일 수 있습니다.

  • 다른 NRQL WHERE 절과 함께 수집 시 로그에 추가한 logtype 속성을 사용하여 구문 분석하려는 데이터와 일치시킵니다. 가능한 한 정확하게 로그를 필터링하기 위해 특정 일치 규칙을 작성합니다. 예를 들어:

    WHERE logtype='mylog' AND message LIKE '%error%'
  • 가능할 때마다 내장된 구문 분석 규칙 및 관련 logtype 속성을 사용하십시오. 기본 제공 규칙이 데이터에 작동하지 않으면 다른 logtype 속성 이름(예: apache_logsapache, iis_w3c_customiis_w3c)을 사용한 다음 다음에서 새 구문 분석 규칙을 만듭니다. 로그 데이터 형식에 맞게 작동하도록 기본 제공 규칙의 수정된 버전을 사용하는 UI입니다.

  • Parsing UI를 사용하여 Grok 규칙을 테스트하고 검증하십시오. Paste log 옵션을 사용하면 영구 파싱 규칙을 만들고 저장하기 전에 로그 메시지 중 하나에 붙여넣어 Grok 표현식을 테스트할 수 있습니다.

  • 외부 FluentBit 구성을 사용하여 다중 라인 로그 구문 분석 및 New Relic에 수집하기 전에 기타 보다 광범위한 사전 구문 분석을 수행합니다. 인프라 에이전트를 사용한 다중 라인 구문 분석에 대한 자세한 내용 및 구성은 이 블로그 게시물 을 참조하십시오.

  • 필터링된 로그와 일치하도록 최적화된 Grok 패턴을 생성하여 속성을 추출합니다. GREEDYDATA와 같은 고가의 Grok 패턴을 과도하게 사용하지 마십시오. 최적이 아닌 구문 분석 규칙을 식별하는 데 도움이 필요한 경우 New Relic 계정 담당자에게 문의하십시오.

GROK 모범 사례

  • 추출할 속성 값의 유형을 지정하려면 Grok 유형을 사용하십시오. 생략하면 값이 문자열로 추출됩니다. 이러한 속성에서 NRQL 함수(즉, monthOf() , max() , avg() , > , < 등)를 사용할 수 있기를 원하는 경우 숫자 값에 특히 중요합니다.
  • Parsing UI를 사용하여 Grok 패턴을 테스트하십시오. Parsing UI에 샘플 로그를 붙여넣어 Grok 또는 Regex 패턴의 유효성을 검사하고 예상대로 속성을 추출하는지 여부를 확인할 수 있습니다.
  • 구문 분석 로직(즉, ^ )에 앵커를 추가하여 줄의 시작을 나타내거나 줄의 끝에서 $ 을 나타냅니다.
  • 패턴 주위에 ()? 를 사용하여 선택적 필드를 식별합니다.
  • '%{GREEDYDATA} 와 같은 값비싼 Grok 패턴을 과도하게 사용하지 마십시오. 속성을 추출할 때 항상 유효한 Grok 패턴과 Grok 유형을 사용하십시오.

드롭 필터 규칙

수집 시 로그 삭제

  • 유용하지 않거나 대시보드, 경고 또는 문제 해결에 대한 사용 사례를 충족하는 데 필요하지 않은 로그를 삭제하는 삭제 필터 규칙 을 만듭니다.

수집 시 로그에서 속성 삭제

  • 로그에서 사용하지 않는 속성을 삭제하려면 삭제 규칙을 만드세요.
  • 구문 분석 후 message 속성을 삭제합니다. 데이터에서 새 속성을 생성하기 위해 메시지 속성을 구문 분석하는 경우 메시지 필드를 삭제하십시오.
  • 예: AWS 인프라에서 데이터를 전달하는 경우 원치 않는 데이터 팽창을 생성할 수 있는 AWS 속성을 삭제하는 삭제 규칙을 생성할 수 있습니다.

New Relic 로그 크기 조정

  • 스토리지 비용 청구 방식은 일부 경쟁업체와 다를 수 있습니다. 로그 데이터를 측정하는 방법은 사용량 계산 에 정의된 다른 유형의 데이터를 측정하고 요금을 청구하는 방법과 유사합니다.

  • 클라우드 통합(AWS, Azure, GCP)이 설치된 경우 모든 로그 레코드에 클라우드 메타데이터를 추가하여 전체 수집 청구서에 추가합니다. 수집을 줄이기 위해 이 데이터를 삭제할 수 있습니다.

  • 로그 데이터 오버헤드의 주요 동인은 영향 순서대로 다음과 같습니다.

로그 검색

  • 일반적인 로그 검색의 경우 UI에서 저장된 보기 를 만들고 사용합니다. 데이터에 대한 검색을 생성하고 + 열 추가 를 클릭하여 UI 테이블에 추가 특성을 추가합니다. 그런 다음 원하는 순서대로 표시되도록 열을 이동한 다음 비공개 또는 공개 권한으로 저장된 보기로 저장할 수 있습니다. 귀하와 다른 사용자가 표시된 모든 관련 속성 데이터로 일반 검색을 쉽게 실행할 수 있도록 저장된 보기를 공용으로 구성하십시오. 이는 apache, nginx 등과 같은 타사 애플리케이션에 대한 좋은 사례이므로 사용자는 검색하지 않고도 해당 로그를 쉽게 볼 수 있습니다.
  • 쿼리 빌더 를 사용하여 NRQL을 사용하여 검색을 실행합니다. 쿼리 작성기를 사용하면 NRQL에서 사용할 수 있는 모든 고급 기능을 사용할 수 있습니다.
  • 만들다 또는 사용 가능한 빠른 시작 대시보드를 사용하여 로그에 대한 일반적인 질문에 답하고 시계열 그래프에서 시간 경과에 따른 로그 데이터를 살펴보십시오. 여러 패널이 있는 대시보드를 생성하여 로그 데이터를 다양한 방식으로 분할합니다.
  • capture() 또는 aparse() 와 같은 고급 NRQL 기능을 사용하여 검색 시 데이터를 구문 분석합니다.
  • 로그 분석 및/또는 APM 로그 모니터링 빠른 시작 대시보드를 설치하여 로그 데이터에 대한 더 많은 통찰력을 빠르게 얻으십시오. 이러한 대시보드를 추가하려면 one.newrelic.com > Add Data > Logging > Dashboards 이동하십시오.

다음은 뭐지?

시작하기를 참조하세요. .

Copyright © 2024 New Relic Inc.

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