8.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가 설정되지 않았거나 키가 없으면 OpenShift Logging은 구조화된 유형으로 structuredTypeName 값을 사용합니다. structuredTypeKey 및 structuredTypeName을 함께 사용하면 structuredTypeKey의 키가 JSON 로그 데이터에서 누락된 경우 structuredTypeName은 대체 인덱스 이름을 제공합니다.
참고

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

A structuredTypeKey: kubernetes.labels.<key> example

다음을 확인합니다.

  • 클러스터에서 "apache" 및 "google"의 두 가지 형식으로 JSON 로그를 생성하는 애플리케이션 Pod를 실행하고 있습니다.
  • 사용자는 logFormat=apache 및 logFormat=google를 사용하여 이러한 애플리케이션 pod에 레이블을 지정합니다.
  • ClusterLogForwarder CR YAML 파일에서 다음 코드 조각을 사용합니다. 
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 로그 형식과 구조화된 유형을 사용합니다.