Parsing log data

로그 레코드는 다음과 같은 형식을 띌 수 있습니다.

{
  "message": "54.3.120.2 2048 0"
}

이 정보는 정확하지만 그 의미가 직관적이지 않습니다. Grok 패턴은 원하는 텔레메트리 데이터를 추출하고 이해하는 데 도움이 됩니다. 예를 들어 다음과 같은 로그 레코드는 사용하기가 훨씬 쉽습니다.

{
  "host_ip": "43.3.120.2",
  "bytes_received": 2048,
  "bytes_sent": 0
}

이를 위해서는 이 세 필드를 추출하는 Grok 패턴을 만들어야 합니다. 예를 들어:

%{IP:host_ip} %{INT:bytes_received} %{INT:bytes_sent}

프로세싱 후, 로그 레코드에는 host_ip, bytes_received 및 bytes_sent 필드가 포함됩니다. 이제 뉴렐릭에서 이러한 필드를 사용하여 로그 데이터에 대한 통계 연산을 필터링, 패싯 및 수행할 수 있습니다. 뉴렐릭에서 Grok 패턴으로 로그를 구문 분석하는 방법에 대한 보다 자세한 내용은 블로그 게시물을 참조하십시오.

올바른 권한이 있는 경우 UI에서 구문 분석 규칙을 만들어 Grok 구문 분석을 생성, 테스트 및 활성화할 수 있습니다. 예를 들어 Inventory Services라는 마이크로 서비스에 대한 특정 유형의 오류 메시지를 가져오려면, 특정 오류 메시지와 제품을 찾는 Grok 구문 분석 규칙을 만듭니다. 이를 위해서는:

1. 규칙에 이름을 지정합니다. 예: Inventory Services error parsing

2. 구문 분석할 기존 필드를 선택(기본값 = message)하거나 새 필드 이름을 입력합니다.

3. 들어오는 로그에 대한 사전 필터 역할을 하는 NRQL WHERE절을 식별합니다. 예: entity.name='Inventory Service'. 이 사전 필터는 규칙에서 처리해야 하는 로그 수를 줄여 불필요한 프로세싱을 제거합니다.

4. 매치되는 로그가 있으면 선택하거나 Paste log 탭을 클릭하여 샘플 로그에 붙여넣습니다.

5. Grok 구문 분석 규칙을 추가합니다. 예:

   Inventory error: %{DATA:error_message} for product %{INT:product_id}

   카피

   Where:

• Inventory error: 파싱 규칙의 이름
• error_message: 선택하려는 오류 메시지
• product_id: Inventory Service의 제품 ID

6. 구문 분석 규칙을 활성화하고 저장합니다.

   곧 Inventory Service 로그가 2개의 새로운 필드 error_message와 product_id로 강화된 것을 볼 수 있습니다. 여기에서 이러한 필드에 대해 쿼리하고, 차트 및 대시보드를 만들고, 알림을 설정하는 등의 작업을 수행할 수 있습니다.

   보다 자세한 내용은 UI에 커스텀 구문 분석 규칙을 추가하는 방법을 참조하십시오.

OPTIONAL_TYPE 필드는 추출할 속성 값의 유형을 지정합니다. 생략하면, 값이 문자열로 추출됩니다.

지원되는 유형:

멀티라인 로그의 경우 GREEDYDATA Grok 패턴은 새로운 줄을 매치하지 않습니다. ( .*와 동일)

따라서 %{GREEDYDATA:some_attribute}를 직접 사용하는 것이 아니라 그 앞에 멀티라인 플래그를 추가해야 합니다. (?s)%{GREEDYDATA:some_attribute}

뉴렐릭 로그 파이프라인은 기본적으로 로그 JSON 메시지를 구문 분석하지만, 때로 일반 텍스트와 혼합된 JSON 로그 메시지가 있는 경우가 있습니다. 이런 상황에서, 메시지를 구문 분석한 다음 JSON 속성을 사용하여 필터링하길 원할 수 있습니다. 이 경우 json grok 유형을 사용할 수 있습니다. 이 유형은 grok 패턴에서 캡처한 JSON을 구문 분석합니다. 이 포맷은 3가지 주요 부분, 즉 grok 구문, 구문 분석된 json 속성에 할당하려는 접두사 및 json grok 유형에 의존합니다. json grok 유형을 사용하면 포맷이 올바르지 않은 로그에서 JSON을 추출하고 구문 분석할 수 있습니다. 예를 들어, 로그에 날짜/시간 문자열이 접두사로 붙는 경우:

2015-05-13T23:39:43.945958Z {"event": "TestRequest", "status": 200, "response": {"headers": {"X-Custom": "foo"}}, "request": {"headers": {"X-Custom": "bar"}}}

이 로그 형식에서 JSON 데이터를 추출하고 구문 분석하려면 다음 Grok 표현식을 작성합니다.

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json}

결과 로그는 다음과 같습니다.

containerTimestamp: "2015-05-13T23:39:43.945958Z"
my_attribute_prefix.event: "TestRequest"
my_attribute_prefix.status: 200
my_attribute_prefix.response.headers.X-Custom: "foo"
my_attribute_prefix.request.headers.X-Custom: "bar"

keepAttributes 또는 dropAttributes 옵션을 사용하여 추출하거나 드롭할 속성 목록을 정의할 수 있습니다. 예를 들어, 다음 Grok 표현식을 사용하면:

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json({"keepAttributes": ["my_attribute_prefix.event", "my_attribute_prefix.response.headers.X-Custom"]})}

결과 로그는 다음과 같습니다.

containerTimestamp: "2015-05-13T23:39:43.945958Z"
my_attribute_prefix.event: "TestRequest"
my_attribute_prefix.request.headers.X-Custom: "bar"

my_attribute_prefix 접두사를 생략하려면 설정에 "noPrefix": true를 포함할 수 있습니다.

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json({"noPrefix": true})}

my_attribute_prefix 접두사를 생략하고 status 속성만 유지하려는 경우 설정에 "noPrefix": true 및 "keepAttributes: ["status"]를 포함할 수 있습니다.

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:my_attribute_prefix:json({"noPrefix": true, "keepAttributes": ["status"]})}

JSON이 이스케이프된 경우 isEscaped 옵션을 사용하여 구문 분석을 할 수 있습니다. JSON이 이스케이프되고 인용이 된 경우 아래와 같이 인용 부호도 일치시켜야 합니다. 예를 들어, 다음 Grok 표현식을 사용하면:

%{TIMESTAMP_ISO8601:containerTimestamp} "%{GREEDYDATA:my_attribute_prefix:json({"isEscaped": true})}"

이스케이프된 메시지를 구문 분석할 수 있습니다.

2015-05-13T23:39:43.945958Z "{\"event\": \"TestRequest\", \"status\": 200, \"response\": {\"headers\": {\"X-Custom\": \"foo\"}}, \"request\": {\"headers\": {\"X-Custom\": \"bar\"}}}"

결과 로그는 다음과 같습니다.

containerTimestamp: "2015-05-13T23:39:43.945958Z"
my_attribute_prefix.event: "TestRequest"
my_attribute_prefix.status: 200
my_attribute_prefix.response.headers.X-Custom: "foo"
my_attribute_prefix.request.headers.X-Custom: "bar"

json Grok 유형을 구성하려면 :json(_CONFIG_)를 사용합니다.

• json({"dropOriginal": true}): 구문 분석에 사용된 JSON 스니펫을 삭제합니다. true(기본값)로 설정하면 구문 분석 규칙이 원본 JSON 스니펫을 삭제합니다. JSON 속성은 메시지 필드에 유지됩니다.
• json({"dropOriginal": false}): 추출된 JSON 페이로드를 보여줍니다. false로 설정하면 전체 JSON 전용 페이로드가 위의 my_attribute_prefix에 이름이 지정된 속성 아래에 표시됩니다. JSON 속성은 여기 메시지 필드에 남아 있을 뿐만 아니라 사용자에게 JSON 데이터에 대한 3가지 다른 뷰를 제공합니다. 세 가지 버전 모두 저장하는 것이 우려되는 경우 여기에서 기본값인 true를 사용하는 것이 좋습니다.
• json({"depth": 62}): JSON 값을 구문 분석하려는 깊이 수준(기본값은 62)입니다.
• json({"keepAttributes": ["attr1", "attr2", ..., "attrN"]}): JSON에서 추출할 속성을 지정합니다. 제공된 목록은 공백으로 둘 수 없습니다. 이 구성 옵션을 설정하지 않으면 모든 속성이 추출됩니다.
• json({"dropAttributes": ["attr1", "attr2", ..., "attrN"]}): JSON에서 드롭할 속성을 지정합니다. 이 구성 옵션이 설정되지 않으면 속성이 드롭되지 않습니다.
• json({"noPrefix": true}): JSON에서 추출된 속성에서 접두사를 제거하려면 이 옵션을 true로 설정합니다.
• json({"isEscaped": true}): 이스케이프된 JSON을 구문 분석하려면 이 옵션을 true로 설정합니다. (일반적으로 JSON이 문자열화될 때 볼 수 있습니다. 예: {\"key\": \"value\"})

시스템이 쉼표로 구분된 값(CSV) 로그를 보내고 이를 뉴렐릭에서 구문 분석해야 하는 경우 Grok 패턴으로 캡처한 CSV를 구문 분석하는 csv Grok 유형을 사용할 수 있습니다. 이 형식은 Grok 구문, 구문 분석된 CSV 속성에 할당하려는 접두사 및 csv Grok 유형의 세 가지 주요 부분에 의존합니다. csv Grok 유형을 사용하여 로그에서 CSV를 추출하고 구문 분석할 수 있습니다.

예를 들어 다음 CSV 로그 줄과

"2015-05-13T23:39:43.945958Z,202,POST,/shopcart/checkout,142,10"

다음 형태의 구문 분석 규칙의 경우:

%{GREEDYDATA:log:csv({"columns": ["timestamp", "status", "method", "url", "time", "bytes"]})}

다음과 같이 로그를 구문 분석합니다.

log.timestamp: "2015-05-13T23:39:43.945958Z"
log.status: "202"
log.method: "POST"
log.url: "/shopcart/checkout"
log.time: "142"
log.bytes: "10"

"log" 접두사를 생략해야 하는 경우 구성에 "noPrefix": true를 포함할 수 있습니다.

%{GREEDYDATA:log:csv({"columns": ["timestamp", "status", "method", "url", "time", "bytes"], "noPrefix": true})}

열 구성:

• CSV Grok 유형 구성(유효한 JSON이어야 함)에서 필수적으로 열을 지시해야 합니다.
• 열 이름으로 "_"(밑줄)을 설정하여 결과 객체에서 열을 삭제하면 모든 열을 무시할 수 있습니다.

선택적 구성 옵션:

"열" 구성은 필수이지만 다음 설정을 사용하여 CSV 구문 분석을 변경할 수 있습니다.

• dropOriginal: (기본값은 true) 구문 분석에 사용된 CSV 스니펫을 삭제합니다. true (기본값)으로 설정하면 구문 분석 규칙이 원래 필드를 삭제합니다.
• noPrefix: (기본값은 false) Grok 필드 이름을 결과 객체의 접두사로 포함하지 않습니다.
• separator: (기본값은 ,) 각 열을 분할하는 문자/문자열을 정의합니다.
  • 또 다른 일반적인 시나리오는 \t를 구분 기호로 지정해야 하는 TSV(탭으로 구분된 값)입니다. %{GREEDYDATA:log:csv({"columns": ["timestamp", "status", "method", "url", "time", "bytes"], "separator": "\t"})
• quoteChar: (기본값은 ") 열 내용을 선택적으로 둘러싸는 문자를 정의합니다.

시스템이 IPv4 주소가 포함된 로그를 보내는 경우 뉴렐릭은 지리적으로 주소를 찾고 지정된 속성으로 로그 이벤트를 보강할 수 있습니다. Grok 패턴이 캡처한 IP 주소의 위치를 찾는 geo Grok type을 사용할 수 있습니다. 이 포맷은 IP의 도시, 국가, 위도/경도 등 주소와 관련된 하나 이상의 필드를 반환하도록 구성할 수 있습니다.

예를 들어 다음 로그 줄이 주어집니다.

2015-05-13T23:39:43.945958Z 146.190.212.184

다음 형태의 구문 분석 규칙의 경우:

%{TIMESTAMP_ISO8601:containerTimestamp} %{GREEDYDATA:ip:geo({"lookup":["city","region","countryCode", "latitude","longitude"]})}

다음과 같이 로그를 구문 분석합니다.

ip: 146.190.212.184
ip.city: North Bergen
ip.countryCode: US
ip.countryName: United States
ip.latitude: 40.793
ip.longitude: -74.0247
ip.postalCode: 07047
ip.region: NJ
ip.regionName: New Jersey
containerTimestamp:2015-05-13T23:39:43.945958Z
ISO8601_TIMEZONE:Z

룩업 구성:

반드시 geo 작업에서 반환된 원하는 lookup 필드를 지정해야 합니다. 다음 옵션 중 적어도 1개 항목이 필요합니다.

• city: 도시 이름
• countryCode: 국가의 약자
• countryName: 국가 이름
• latitude: 위도
• longitude: 경도
• postalCode: 우편번호 또는 이와 유사한 것
• region: 주, 도, 지역의 약자
• regionName: 주, 도, 지역의 이름

logtype을 attribute로 추가합니다. 명명된 각 소스에 대해 로그 유형을 설정해야 합니다.

logs:
  - name: file-simple
    file: /path/to/file
    attributes:
      logtype: fileRaw
  - name: nginx-example
    file: /var/log/nginx.log
    attributes:
      logtype: nginx

record_transformer를 사용하여 새 필드를 추가하는 .conf 파일에 필터 블록을 추가합니다. 이 예에서는 nginx의 logtype을 사용하여 내장 NGINX 구문 분석 규칙을 트리거합니다. 다른 Fluentd 예제들을 확인해 보십시오.

<filter containers>
  @type record_transformer
  enable_ruby true
  <record>
    #Add logtype to trigger a built-in parsing rule for nginx access logs
    logtype nginx
    #Set timestamp from the value contained in the field "time"
    timestamp record["time"]
    #Add hostname and tag fields to all records
    hostname "#{Socket.gethostname}"
    tag ${tag}
  </record>
</filter>

record_modifier를 사용하여 새 필드를 추가하는 필터 블록을 .conf 파일에 추가합니다.이 예에서는 nginx의 logtype을 사용하여 내장된 NGINX 구문 분석 규칙을 트리거합니다. 다른 Fluent Bit 예시를 확인해보십시오.

[FILTER]
    Name   record_modifier
    Match  *
    Record logtype nginx
    Record hostname ${HOSTNAME}
    Record service_name Sample-App-Name

add_field mutate 필터를 사용해 새 필드를 추가하는 필터 블록을 Logstash 구성에 추가합니다. 이 예에서는 nginx의 logtype을 사용하여 내장된 NGINX 구문 분석 규칙을 트리거합니다. 다른 Logstash 예시를 확인해보십시오.

filter {
  mutate {
    add_field => {
      "logtype" => "nginx"
      "service_name" => "myservicename"
      "hostname" => "%{host}"
    }
  }
}

뉴렐릭으로 전송된 JSON 요청에 속성을 추가할 수 있습니다. 이 예에서는 값이 nginx인 logtype 속성을 추가하여 내장된 NGINX 구문 분석 규칙을 트리거합니다. Logs API를 사용하는 방법을 보다 자세히 알아보십시오.

POST /log/v1 HTTP/1.1
Host: log-api.newrelic.com
Content-Type: application/json
X-License-Key: YOUR_LICENSE_KEY
Accept: */*
Content-Length: 133
{
  "timestamp": TIMESTAMP_IN_UNIX_EPOCH,
  "message": "User 'xyz' logged in",
  "logtype": "nginx",
  "service": "login-service",
  "hostname": "login.example.com"
}