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

Parsing log data

로그 parsing은 정의한 규칙에 따라 정형화되지 않은 로그 데이터를 속성(키:값 쌍)으로 변환하는 프로세스입니다. NRQL 쿼리에서 이 속성을 사용하면 편리하게 로그를 패싯하거나 필터링할 수 있습니다.

뉴렐릭은 특정 구문 분석 규칙에 따라 로그 데이터를 자동으로 구문 분석합니다. 이 문서에서는 로그 구문 분석이 작동하는 방식과 커스텀 구문 분석 규칙을 만드는 방법을 배웁니다.

GraphQL API인 NerdGraph를 사용하여 로그 구문 분석 규칙을 생성, 쿼리 및 관리할 수도 있습니다. 이를 위한 유용한 도구는 Nerdgraph API 탐색기입니다. 보다 자세한 내용은 구문 분석에 대한 NerdGraph 튜토리얼을 참조하십시오.

로그 구문 분석에 대한 5분 길이 동영상을 확인해 보십시오.

구문 분석 예시

좋은 예는 정형화되지 않은 텍스트를 포함하는 기본 NGINX 액세스 로그입니다. 검색할 때 유용하지만 그 외에는 그다지 유용하지 않습니다. 다음은 일반적인 라인의 예입니다.

127.180.71.3 - - [10/May/1997:08:05:32 +0000] "GET /downloads/product_1 HTTP/1.1" 304 0 "-" "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.21)"

구문 분석되지 않은 포맷에서는 대부분의 질문에 답하기 위해 전체 텍스트 검색을 수행해야 합니다. 구문 분석 후, 로그는 response coderequest URL 같은 속성으로 구성됩니다.

{
"remote_addr": "93.180.71.3",
"time": "1586514731",
"method": "GET",
"path": "/downloads/product_1",
"version": "HTTP/1.1",
"response": "304",
"bytesSent": 0,
"user_agent": "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.21)"
}

구문 분석을 사용하면 해당 값을 패싯하는 커스텀 쿼리를 더 쉽게 만들 수 있습니다. 이를 통해 요청 URL당 응답 코드의 분포를 이해하고 문제가 있는 페이지를 빠르게 찾을 수 있습니다.

로그 구문 분석의 작동 방식

다음은 뉴렐릭이 로그 구문 분석을 구현하는 방법에 대한 간단한 설명입니다.

로그 구문 분석

작동 원리

대상

  • 구문 분석은 선택된 특정 필드에 적용됩니다. 기본적으로 message 필드가 사용됩니다. 그러나 현재 데이터에 존재하지 않는 필드/속성까지 포함해, 모든 필드/속성을 선택할 수 있습니다.
  • 각 구문 분석 규칙은 규칙이 구문 분석을 시도할 로그를 결정하는 NRQL WHERE 절을 사용하여 생성됩니다.
  • 매칭 프로세스를 간소화하려면 로그에 logtype 속성을 추가하는 것이 좋습니다. 그러나 logtype 사용하는 것으로 제한되지 않습니다. NRQL WHERE 절에서 하나 이상의 속성을 매칭 기준으로 사용할 수 있습니다.

시기

  • 구문 분석은 각 로그 메시지에 한 번만 적용됩니다. 여러 구문 분석 규칙이 로그와 매치하는 경우 성공한 첫 번째 규칙만 적용됩니다.
  • 구문 분석 규칙은 순서가 없습니다. 둘 이상의 구문 분석 규칙이 로그와 매치되는 경우 무작위로 하나가 선택됩니다. 동일한 로그와 매치되지 않도록 구문 분석 규칙을 작성해야 합니다.
  • 구문 분석은 데이터가 NRDB에 기록되기 전에 로그 수집 중에 실행됩니다. 데이터가 스토리지에 기록되면 더 이상 구문 분석을 할 수 없습니다.
  • 데이터 보강이 이뤄지기 전에(before) 파이프라인에서 구문 분석이 실행됩니다. 구문 분석 규칙에 대한 매칭 기준을 정의할 때는 주의해야 합니다. 기준이 구문 분석 또는 보강이 수행될 때까지 존재하지 않는 속성을 기반으로 하는 경우 매칭이 발생할 때 해당 데이터가 로그에 표시되지 않습니다. 결과적으로, 구문 분석이 실행되지 않습니다.

방법

  • 규칙은 Grok, 정규식 또는 이 둘을 혼합하여 작성할 수 있습니다. Grok은 복잡한 정규식을 추상화하는 패턴 모음입니다.
  • 뉴렐릭의 Parsing UI는 Java Regex 구문을 지원합니다. 캡처 그룹의 속성 또는 필드 이름의 경우, Java Regex는 [A-Za-z0-9]만 허용합니다.

Grok을 사용한 속성 구문 분석

구문 분석 패턴은 로그 메시지 구문 분석을 위한 업계 표준인 Grok를 사용하여 지정됩니다.logtype 필드가 있는 수신 로그는 내장된 구문 분석 과 비교 확인되며 가능한 경우 연결된 Grok 패턴이 로그에 적용됩니다.

Grok은 복잡한 리터럴 정규식 대신 사용될 내장 및 명명된 패턴을 추가하는 정규식의 상위 집합입니다. 예를 들어 정수가 정규식 (?:[+-]?(?:[0-9]+))과 매칭될 수 있다는 것을 기억할 필요 없이 동일한 정규식을 나타내는 Grok 패턴 INT를 사용하도록 %{INT}을 작성할 수 있습니다.

Grok 패턴의 구문은 다음과 같습니다.

%{PATTERN_NAME[:OPTIONAL_EXTRACTED_ATTRIBUTE_NAME[:OPTIONAL_TYPE[:OPTIONAL_PARAMETER]]]}

Where:

  • PATTERN_NAME 지원 Grok 패턴 중 하나입니다. 패턴 이름은 정규식을 나타내는 사용자 친화적인 이름입니다. 해당 정규식과 정확히 동일합니다.
  • OPTIONAL_EXTRACTED_ATTRIBUTE_NAME이 제공된 경우, 패턴 이름과 매치되는 값으로 로그 메시지에 추가될 속성의 이름입니다. 정규식을 사용하여 명명된 캡처 그룹을 사용하는 것과 같습니다. 이것이 제공되지 않으면 구문 분석 규칙은 문자열의 영역과 매치되지만 해당 값으로 속성을 추출하지는 않습니다.
  • OPTIONAL_TYPE 은 추출할 속성 값의 유형을 지정합니다. 생략하면, 값이 문자열로 추출됩니다. 예를 들어, "File Size: 123"의 값 123을 숫자에서 file_size 속성으로 추출하려면 value: %{INT:file_size:int}을 사용합니다.
  • OPTIONAL_PARAMETER 특정 유형에 대해 선택적으로 파라미터를 지정합니다. 현재는 datetime 유형만 파라미터를 지정할 수 있습니다. 자세한 내용은 아래를 참조하십시오.

매치되는 문자열에서 정규식과 Grok 패턴 이름을 혼합하여 사용할 수도 있습니다.

지원되는 Grok 패턴 목록을 보려면 이 링크를 클릭하고, 지원되는 Grok 유형 목록을 보려면 여기를 클릭하십시오.

변수 이름은 명시적으로 설정해야 하며 %{URI:uri} 같이 소문자여야 한다는 데 유의하십시오. %{URI} 또는 %{URI:URI} 같은 표현식은 안됩니다.

로그 유형별 정리

뉴렐릭의 로그 수집 파이프라인은 로그를 구문 분석하는 방법을 설명하는 규칙에 로그 이벤트를 매칭시켜 데이터를 구문 분석할 수 있습니다. 다음 두 가지 방법으로 로그 이벤트를 구문 분석할 수 있습니다.

규칙은 매칭되는 로직과 구문 분석 로직의 조합입니다. 매칭은 로그의 속성에 대한 쿼리 매치를 정의함으로써 수행됩니다. 규칙은 소급 적용되지 않습니다. 규칙이 생성되기 전에 수집된 로그는 해당 규칙에 의해 구문 분석되지 않습니다.

로그를 구성하고 구문 분석하는 가장 간단한 방법은 로그 이벤트에 logtype 필드를 포함하는 것입니다. 이것은 로그에 적용할 내장된 규칙을 뉴렐릭에 알려줍니다.

중요

구문 분석 규칙이 활성화되면, 규칙에 의해 구문 분석된 데이터는 영구적으로 변경됩니다. 변경 사항은 되돌릴 수 없습니다.

제한

구문 분석은 계산 비용이 많이 들고 위험이 따릅니다. 계정에 정의된 커스텀 규칙과 패턴을 로그에 매칭시키기 위해 구문 분석이 수행됩니다. 많은 수의 패턴이나 잘못 정의된 커스텀 규칙은 엄청난 양의 메모리와 CPU 리소스를 소비할 뿐아니라 완료하는 데도 오랜 시간이 걸립니다.

문제를 방지하기 위해, 규칙당 메시지당, 계정당 2회의 구문 분석 제한을 적용합니다.

제한

설명

Per-message-per-rule

규칙당 메시지당 제한으로 단일 메시지를 구문 분석하는 데 소요되는 시간이 100ms를 초과하는 것을 방지합니다. 이 제한에 도달하면 시스템은 해당 규칙을 사용하여 로그 메시지를 구문 분석하려는 시도를 중지합니다.

인제스트 파이프라인은 해당 메시지에 적용 가능한 다른 모든 항목을 실행하려고 시도하며, 메시지는 여전히 수집 파이프라인을 통해 전달되고 NRDB에 저장됩니다. 로그 메시지는 원래의 구문 분석되지 않은 포맷입니다.

Per-account

계정당 제한은 계정이 공정한 리소스 할당량 이상을 사용하는 것을 방지하기 위함입니다. 이 제한은 계정에 대한 분당 모든(all) 로그 메시지를 처리하는 데 소요된 총 시간을 고려합니다.

제한에 도달했는지 쉽게 확인하려면 뉴렐릭 UI의 시스템 Limits 페이지로 이동합니다.

기본 구문 분석 규칙

공통 로그 포맷에는 잘 정립된 구문 분석 규칙이 이미 생성되어 있습니다. 내장된 구문 분석 규칙의 이점을 얻으려면, 로그를 전달할 때 logtype 속성을 추가합니다. 값을 다음 표에 나열된 값으로 설정하면, 해당 유형의 로그에 대한 규칙이 자동으로 적용됩니다.

내장된 규칙 목록

다음 logtype 속성 값은 사전 정의된 구문 분석 규칙에 매핑됩니다. 예를 들어, Application Load Balancer를 쿼리하려면:

  • 뉴렐릭 UI에서 logtype:"alb" 포맷을 사용합니다.
  • NerdGraph에서 logtype = 'alb' 포맷을 사용합니다.

각 규칙에 대해 구문 분석되는 필드를 알아보려면 내장된 구문 분석 규칙에 대한 문서를 참조하십시오.

logtype

로그 소스

매칭 쿼리의 예

apache

Apache 액세스 로그

logtype:"apache"

apache_error

Apache 오류 로그

logtype:"apache_error"

alb

애플리케이션 로드 밸런서 로그

logtype:"alb"

cassandra

Cassandra 로그

logtype:"cassandra"

cloudfront-web

CloudFront (표준 웹 로그)

logtype:"cloudfront-web"

cloudfront-rtl

CloudFront (실시간 웹 로그)

logtype:"cloudfront-rtl"

elb

Elastic 로드 밸런서 로그

logtype:"elb"

haproxy_http

HAProxy 로그

logtype:"haproxy_http"

ktranslate-health

KTranslate 컨테이너 상태 로그

logtype:"ktranslate-health"

linux_cron

Linux cron

logtype:"linux_cron"

linux_messages

Linux 메시지

logtype:"linux_messages"

iis_w3c

Microsoft IIS 서버 로그 - W3C 포맷

logtype:"iis_w3c"

mongodb

MongoDB 로그

logtype:"mongodb"

monit

Monit 로그

logtype:"monit"

mysql-error

MySQL 오류 로그

logtype:"mysql-error"

nginx

NGINX 액세스 로그

logtype:"nginx"

nginx-error

NGINX 오류 로그

logtype:"nginx-error"

postgresql

PostgreSQL 로그

logtype:"postgresql"

rabbitmq

Rabbitmq 로그

logtype:"rabbitmq"

redis

Redis 로그

logtype:"redis"

route-53

Route 53 로그

logtype:"route-53"

syslog-rfc5424

RFC5424 포맷 Syslog

logtype:"syslog-rfc5424"

추가하다 logtype

로그를 집계할 때는 로그를 쉽게 구성, 검색 및 구문 분석할 수 있도록 메타데이터를 제공하는 것이 중요합니다. 이를 위한 한 가지 간단한 방법은 전송될 때 로그 메시지에 속성 logtype을 추가하는 것입니다. 내장된 구문 분석 규칙은 특정 logtype 값에 기본적으로 적용됩니다.

logType, logtypeLOGTYPE 필드는 모두 내장된 규칙을 지원합니다. 검색을 쉽게 하려면 조직이 단일 구문으로 정렬하는 것이 좋습니다.

다음은 지원되는 전송 방법 중 일부에서 보낸 로그에 logtype을 추가하는 몇 가지 방법의 예입니다.

커스텀 구문 분석 규칙 생성 및 보기

많은 로그가 고유한 방식으로 형식화되거나 구조화됩니다. 이를 구문 분석하려면 커스텀 로직을 빌드하고 적용해야 합니다.

Screenshot of log parsing in UI

로그 UI의 왼쪽 탐색 메뉴에서 Parsing을 선택한 다음 유효한 NRQL WHERE 절과 Grok 패턴을 사용하여 고유한 커스텀 구문 분석 규칙을 생성합니다.

고유한 커스텀 구문 분석 규칙을 만들고 관리하려면 다음을 수행합니다.

  1. one.newrelic.com > All capabilities > Logs으로 이동합니다.
  2. 로그 UI 왼쪽 탐색 메뉴의 Manage data에서 Parsing을 클릭한 다음 Create parsing rule을 클릭합니다.
  3. 새 구문 분석 규칙의 이름을 입력합니다.
  4. 구문 분석할 기존 필드를 선택(기본값 = message)하거나 새 필드 이름을 입력합니다.
  5. 구문 분석하려는 로그와 매치되는 유효한 NRQL WHERE 절을 입력합니다.
  6. 매치하는 로그가 있으면 선택하거나 Paste log 탭을 클릭하여 샘플 로그를 붙여넣습니다. 로그 UI 또는 쿼리 빌더에서 텍스트를 복사하여 구문 분석 UI에 붙여넣는 경우 해당 버전이 Unformatted 버전인지 확인합니다.
  7. 구문 분석 규칙을 입력하고 Output 섹션의 결과를 확인하여 작동하는지 확인합니다. Grok 및 커스텀 구문 분석 규칙에 대해 보다 자세히 알아보려면 Grok 패턴으로 로그를 구문 분석하는 방법에 대한 블로그 게시물을 확인해보십시오.
  8. 커스텀 구문 분석 규칙을 활성화하고 저장합니다.

기존 구문 분석 규칙을 보려면:

  1. one.newrelic.com > All capabilities > Logs으로 이동합니다.
  2. 로그 UI 왼쪽 탐색 메뉴의 Manage data에서 Parsing을 클릭합니다.

문제 해결

구문 분석이 의도한 대로 작동하지 않는 경우 다음과 같은 이유 때문일 수 있습니다.

  • Logic: 구문 분석 규칙 매칭 로직이 원하는 로그와 일치하지 않습니다.
  • Timing: 구문 분석 매칭 규칙이 아직 존재하지 않는 값을 대상으로 하는 경우, 구문 분석이 실패합니다. 보강 프로세스의 일부로 나중에 파이프라인에 값을 추가하면 이런 일이 발생할 수 있습니다.
  • Limits: 분당 구문 분석, 패턴, 드롭 필터 등을 통해 로그를 처리하는 데 사용할 수 있는 시간이 한정되어 있습니다. 최대 시간이 소요된 경우 추가 로그 이벤트 레코드에 대한 구문 분석을 건너뜁니다.

이러한 문제를 해결하려면 커스텀 구문 분석 규칙을 만들거나 조정해야 합니다.

Copyright © 2024 New Relic Inc.

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