10.3. JSON 로그 전달 활성화


JSON 문자열을 구조화된 오브젝트로 구문 분석하도록 Log Forwarding API를 구성할 수 있습니다.

10.3.1. JSON 로그 구문 분석

ClusterLogForwarder 오브젝트를 사용하여 JSON 로그를 구조화된 오브젝트로 구문 분석하고 지원되는 출력으로 전달할 수 있습니다.

이 작동 방식을 설명하기 위해 다음과 같은 구조화된 JSON 로그 항목이 있다고 가정합니다.

구조화된 JSON 로그 항목 예

{"level":"info","name":"fred","home":"bedrock"}

JSON 로그를 구문 분석할 수 있도록 다음 예와 같이 parse: jsonClusterLogForwarder CR의 파이프라인에 추가합니다.

parse: json을 보여주는 코드 조각 예

pipelines:
- inputRefs: [ application ]
  outputRefs: myFluentd
  parse: json

parse: json 을 사용하여 JSON 로그를 구문 분석할 때 CR은 다음 예와 같이 structured 필드에 JSON 구조화된 로그 항목을 복사합니다.

구조화된 JSON 로그 항목이 포함된 structured 출력 예

{"structured": { "level": "info", "name": "fred", "home": "bedrock" },
 "more fields..."}

중요

로그 항목에 유효한 구조화된 JSON이 포함되어 있지 않으면 structured 필드가 없습니다.

10.3.2. Elasticsearch의 JSON 로그 데이터 구성

JSON 로그가 두 개 이상의 스키마를 따르는 경우 단일 인덱스에 저장하면 유형 충돌 및 카디널리티 문제가 발생할 수 있습니다. 이를 방지하려면 ClusterLogForwarder 사용자 정의 리소스(CR)를 구성하여 각 스키마를 단일 출력 정의로 그룹화해야 합니다. 이렇게 하면 각 스키마가 별도의 인덱스로 전달됩니다.

중요

OpenShift Logging에서 관리하는 기본 Elasticsearch 인스턴스로 JSON 로그를 전달하면 구성에 따라 새 인덱스가 생성됩니다. 너무 많은 인덱스를 보유하는 것과 관련된 성능 문제를 방지하려면 공통 스키마로 표준화하여 가능한 스키마 수를 유지하는 것이 좋습니다.

구조 유형

ClusterLogForwarder CR에서 다음 구조 유형을 사용하여 Elasticsearch 로그 저장소의 인덱스 이름을 구성할 수 있습니다.

  • structuredTypeKey 는 메시지 필드의 이름입니다. 해당 필드의 값은 인덱스 이름을 구성하는 데 사용됩니다.

    • kubernetes.labels.<key >는 인덱스 이름을 구성하는 데 사용되는 Kubernetes Pod 레이블입니다.
    • openshift.labels.<key>ClusterLogForwarder CR의 pipeline.label.<key> 요소이며 인덱스 이름을 구성하는 데 사용되는 값이 있습니다.
    • kubernetes.container_name은 컨테이너 이름을 사용하여 인덱스 이름을 구성합니다.
  • structuredTypeName: structuredTypeKey 필드가 설정되지 않았거나 키가 없으면 structured 유형으로 structuredTypeName 값이 사용됩니다. structuredTypeKey 필드와 structuredTypeName 필드를 함께 사용하면 structuredTypeKey 필드의 키가 JSON 로그 데이터에서 누락된 경우 structuredTypeName 값은 대체 인덱스 이름을 제공합니다.
참고

structuredTypeKey 값을 "Log Record Fields(로그 레코드 필드)" 항목에 표시된 모든 필드로 설정할 수 있지만 가장 유용한 필드가 앞의 구조 유형 목록에 표시됩니다.

A structuredTypeKey: kubernetes.labels.<key> example

다음을 확인합니다.

  • 클러스터에서 "apache" 및 "google"의 두 가지 형식으로 JSON 로그를 생성하는 애플리케이션 Pod를 실행하고 있습니다.
  • 사용자는 logFormat=apachelogFormat=google를 사용하여 이러한 애플리케이션 pod에 레이블을 지정합니다.
  • ClusterLogForwarder CR YAML 파일에서 다음 코드 조각을 사용합니다.
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
# ...
  outputDefaults:
    elasticsearch:
      structuredTypeKey: kubernetes.labels.logFormat 1
      structuredTypeName: nologformat
  pipelines:
  - inputRefs:
    - application
    outputRefs:
    - default
    parse: json 2
1
Kubernetes logFormat 레이블로 구성된 키-값 쌍의 값을 사용합니다.
2
JSON 로그를 구문 분석할 수 있습니다.

이 경우 다음과 같은 구조화된 로그 레코드가 app-apache-write 인덱스로 이동합니다.

{
  "structured":{"name":"fred","home":"bedrock"},
  "kubernetes":{"labels":{"logFormat": "apache", ...}}
}

다음과 같은 구조화된 로그 레코드는 app-google-write 인덱스로 이동합니다.

{
  "structured":{"name":"wilma","home":"bedrock"},
  "kubernetes":{"labels":{"logFormat": "google", ...}}
}

A structuredTypeKey: openshift.labels.<key> example

ClusterLogForwarder CR YAML 파일에서 다음 코드 조각을 사용한다고 가정합니다.

outputDefaults:
 elasticsearch:
    structuredTypeKey: openshift.labels.myLabel 1
    structuredTypeName: nologformat
pipelines:
 - name: application-logs
   inputRefs:
   - application
   - audit
   outputRefs:
   - elasticsearch-secure
   - default
   parse: json
   labels:
     myLabel: myValue 2
1
OpenShift myLabel 레이블로 구성된 키-값 쌍의 값을 사용합니다.
2
myLabel 요소는 구조화된 로그 레코드에 문자열 값 myValue를 제공합니다.

이 경우 다음과 같은 구조화된 로그 레코드가 app-myValue-write 인덱스로 이동합니다.

{
  "structured":{"name":"fred","home":"bedrock"},
  "openshift":{"labels":{"myLabel": "myValue", ...}}
}

추가 고려 사항

  • 구조화된 레코드에 대한 Elasticsearch 인덱스는 구조화된 유형 앞에 "app-"를 추가하고 "-write"를 추가하여 구성됩니다.
  • 구조화되지 않은 레코드는 구조화된 인덱스로 전송되지 않습니다. 애플리케이션, 인프라 또는 감사 인덱스에서 일반적으로 인덱싱됩니다.
  • 비어 있지 않은 구조화된 유형이 없는 경우 structured 필드없이 unstructured 레코드를 전달합니다.

Elasticsearch에 너무 많은 인덱스로 과부하가 발생하지 않는 것이 중요합니다. 각 애플리케이션 또는 네임스페이스에는 별도의 구조화된 유형만 사용하는것이 아니라 별도의 로그 형식에만 사용합니다. 예를 들어 대부분의 Apache 애플리케이션은 LogApache와 같은 동일한 JSON 로그 형식과 구조화된 유형을 사용합니다.

10.3.3. Elasticsearch 로그 저장소로 JSON 로그 전달

Elasticsearch 로그 저장소의 경우 JSON 로그 항목이 다른 스키마를 따르는 경우 ClusterLogForwarder 사용자 정의 리소스(CR)를 구성하여 각 JSON 스키마를 단일 출력 정의로 그룹화합니다. 이렇게 하면 Elasticsearch는 각 스키마에 대해 별도의 인덱스를 사용합니다.

중요

동일한 인덱스로 다른 스키마를 전달하면 유형 충돌 및 카디널리티 문제가 발생할 수 있으므로 Elasticsearch 저장소로 데이터를 전달하기 전에 이 구성을 수행해야 합니다.

너무 많은 인덱스를 보유하는 것과 관련된 성능 문제를 방지하려면 공통 스키마로 표준화하여 가능한 스키마 수를 유지하는 것이 좋습니다.

절차

  1. 다음 조각을 ClusterLogForwarder CR YAML 파일에 추가합니다.

    outputDefaults:
     elasticsearch:
        structuredTypeKey: <log record field>
        structuredTypeName: <name>
    pipelines:
    - inputRefs:
      - application
      outputRefs: default
      parse: json
  2. structuredTypeKey 필드를 사용하여 로그 레코드 필드 중 하나를 지정합니다.
  3. structuredTypeName 필드를 사용하여 이름을 지정합니다.

    중요

    JSON 로그를 구문 분석하려면 structuredTypeKeystructuredTypeName 필드를 모두 설정해야 합니다.

  4. inputRefs의 경우 application, infrastructure, 또는 audit 등 해당 파이프라인을 사용하여 전달해야 하는 로그 유형을 지정합니다.
  5. parse: json 요소를 파이프라인에 추가합니다.
  6. CR 오브젝트를 생성합니다.

    $ oc create -f <filename>.yaml

    Red Hat OpenShift Logging Operator는 수집기 Pod를 재배포합니다. 그러나 재배포되지 않으면 수집기 Pod를 삭제하여 강제로 재배포합니다.

    $ oc delete pod --selector logging-infra=collector

10.3.4. 동일한 Pod의 컨테이너에서 JSON 로그를 별도의 인덱스로 전달

동일한 Pod 내의 여러 컨테이너에서 다른 인덱스로 구조화된 로그를 전달할 수 있습니다. 이 기능을 사용하려면 멀티컨테이너 지원을 사용하여 파이프라인을 구성하고 Pod에 주석을 달아야 합니다. 로그는 접두사 app- 가 있는 인덱스에 기록됩니다. 이를 수용하려면 Elasticsearch를 별칭으로 구성하는 것이 좋습니다.

중요

로그의 JSON 형식은 애플리케이션에 따라 다릅니다. 너무 많은 인덱스를 생성하면 성능에 영향을 미치므로 호환되지 않는 JSON 형식이 있는 로그에 대한 인덱스를 생성하기 위해 이 기능 사용을 제한합니다. 쿼리를 사용하여 다른 네임스페이스 또는 호환되는 JSON 형식의 로그를 분리합니다.

사전 요구 사항

  • Red Hat OpenShift용 로깅: 5.5

프로세스

  1. ClusterLogForwarder CR 오브젝트를 정의하는 YAML 파일을 생성하거나 편집합니다.

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      outputDefaults:
        elasticsearch:
          structuredTypeKey: kubernetes.labels.logFormat 1
          structuredTypeName: nologformat
          enableStructuredContainerLogs: true 2
      pipelines:
      - inputRefs:
        - application
        name: application-logs
        outputRefs:
        - default
        parse: json
    1
    Kubernetes logFormat 레이블로 구성된 키-값 쌍의 값을 사용합니다.
    2
    멀티컨테이너 출력을 활성화합니다.
  2. Pod CR 오브젝트를 정의하는 YAML 파일을 생성하거나 편집합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      annotations:
        containerType.logging.openshift.io/heavy: heavy 1
        containerType.logging.openshift.io/low: low
    spec:
      containers:
      - name: heavy 2
        image: heavyimage
      - name: low
        image: lowimage
    1
    Format: containerType.logging.openshift.io/<container-name>: <index>
    2
    주석 이름이 컨테이너 이름과 일치해야 함
주의

이 설정을 사용하면 클러스터의 shard 수가 크게 증가할 수 있습니다.

추가 리소스

추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.