9.3. JSON 로그 전달 활성화
JSON 문자열을 구조화된 오브젝트로 구문 분석하도록 Log Forwarding API를 구성할 수 있습니다.
9.3.1. JSON 로그 구문 분석
ClusterLogForwarder
오브젝트를 사용하여 JSON 로그를 구조화된 오브젝트로 구문 분석하고 지원되는 출력으로 전달할 수 있습니다.
이 작동 방식을 설명하기 위해 다음과 같은 구조화된 JSON 로그 항목이 있다고 가정합니다.
구조화된 JSON 로그 항목 예
{"level":"info","name":"fred","home":"bedrock"}
JSON 로그를 구문 분석할 수 있도록 다음 예와 같이 parse: json
을 ClusterLogForwarder
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
필드가 없습니다.
9.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=apache
및logFormat=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
이 경우 다음과 같은 구조화된 로그 레코드가 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
이 경우 다음과 같은 구조화된 로그 레코드가 app-myValue-write
인덱스로 이동합니다.
{ "structured":{"name":"fred","home":"bedrock"}, "openshift":{"labels":{"myLabel": "myValue", ...}} }
추가 고려 사항
- 구조화된 레코드에 대한 Elasticsearch 인덱스는 구조화된 유형 앞에 "app-"를 추가하고 "-write"를 추가하여 구성됩니다.
- 구조화되지 않은 레코드는 구조화된 인덱스로 전송되지 않습니다. 애플리케이션, 인프라 또는 감사 인덱스에서 일반적으로 인덱싱됩니다.
-
비어 있지 않은 구조화된 유형이 없는 경우
structured
필드없이 unstructured 레코드를 전달합니다.
Elasticsearch에 너무 많은 인덱스로 과부하가 발생하지 않는 것이 중요합니다. 각 애플리케이션 또는 네임스페이스에는 별도의 구조화된 유형만 사용하는것이 아니라 별도의 로그 형식에만 사용합니다. 예를 들어 대부분의 Apache 애플리케이션은 LogApache
와 같은 동일한 JSON 로그 형식과 구조화된 유형을 사용합니다.
9.3.3. Elasticsearch 로그 저장소로 JSON 로그 전달
Elasticsearch 로그 저장소의 경우 JSON 로그 항목이 다른 스키마를 따르는 경우 ClusterLogForwarder
사용자 정의 리소스(CR)를 구성하여 각 JSON 스키마를 단일 출력 정의로 그룹화합니다. 이렇게 하면 Elasticsearch는 각 스키마에 대해 별도의 인덱스를 사용합니다.
동일한 인덱스로 다른 스키마를 전달하면 유형 충돌 및 카디널리티 문제가 발생할 수 있으므로 Elasticsearch 저장소로 데이터를 전달하기 전에 이 구성을 수행해야 합니다.
너무 많은 인덱스를 보유하는 것과 관련된 성능 문제를 방지하려면 공통 스키마로 표준화하여 가능한 스키마 수를 유지하는 것이 좋습니다.
절차
다음 조각을
ClusterLogForwarder
CR YAML 파일에 추가합니다.outputDefaults: elasticsearch: structuredTypeKey: <log record field> structuredTypeName: <name> pipelines: - inputRefs: - application outputRefs: default parse: json
-
structuredTypeKey
필드를 사용하여 로그 레코드 필드 중 하나를 지정합니다. structuredTypeName
필드를 사용하여 이름을 지정합니다.중요JSON 로그를 구문 분석하려면
structuredTypeKey
및structuredTypeName
필드를 모두 설정해야 합니다.-
inputRefs
의 경우application,
infrastructure
, 또는audit
등 해당 파이프라인을 사용하여 전달해야 하는 로그 유형을 지정합니다. -
parse: json
요소를 파이프라인에 추가합니다. CR 오브젝트를 생성합니다.
$ oc create -f <filename>.yaml
Red Hat OpenShift Logging Operator는 수집기 Pod를 재배포합니다. 그러나 재배포되지 않으면 수집기 Pod를 삭제하여 강제로 재배포합니다.
$ oc delete pod --selector logging-infra=collector
9.3.4. 동일한 Pod의 컨테이너에서 JSON 로그를 전달하여 인덱스를 분리
동일한 Pod 내의 다른 컨테이너에서 다른 인덱스로 구조화된 로그를 전달할 수 있습니다. 이 기능을 사용하려면 다중 컨테이너 지원을 사용하여 파이프라인을 구성하고 Pod에 주석을 달아야 합니다. 로그는 접두사가 app-
인 인덱스에 작성됩니다. Elasticsearch는 이를 수용할 수 있도록 별칭으로 구성하는 것이 좋습니다.
JSON 형식의 로그는 애플리케이션에 따라 다릅니다. 너무 많은 인덱스를 생성하면 성능에 영향을 미치기 때문에 이 기능을 사용하여 호환되지 않는 JSON 형식의 로그 인덱스를 생성할 수 있습니다. 쿼리를 사용하여 서로 다른 네임스페이스 또는 호환되는 JSON 형식의 애플리케이션을 분리합니다.
사전 요구 사항
- Red Hat OpenShift용 로깅: 5.5
절차
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
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
이 구성은 클러스터의 shard 수를 크게 늘릴 수 있습니다.
추가 리소스
추가 리소스