1. OpenShift Elasticsearch Operator를 설치합니다.

   1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
   2. 사용 가능한 Operator 목록에서 OpenShift Elasticsearch Operator를 선택한 다음 설치를 클릭합니다.
   3. 설치 모드에서 클러스터의 모든 네임스페이스가 선택되어 있는지 확인합니다.

   4. 설치된 네임스페이스에서 openshift-operators-redhat이 선택되어 있는지 확인합니다.

      openshift-operators-redhat 네임스페이스를 지정해야 합니다. openshift-operators 네임스페이스에 신뢰할 수 없는 Community Operator가 포함될 수 있고, 여기에서 OpenShift Container Platform 지표와 동일한 이름의 지표를 게시하면 충돌이 발생합니다.

   5. 이 네임스페이스에서 Operator 권장 클러스터 모니터링 사용을 선택합니다.

      이 옵션은 네임스페이스 오브젝트에서 openshift.io/cluster-monitoring: "true" 레이블을 설정합니다. 클러스터 모니터링이 openshift-operators-redhat 네임스페이스를 스크랩하도록 하려면 이 옵션을 선택해야 합니다.

   6. stable-5.x을 업데이트 채널로 선택합니다.

   7. 승인 전략을 선택합니다.

      • 자동 전략을 사용하면 Operator 새 버전이 준비될 때 OLM(Operator Lifecycle Manager)이 자동으로 Operator를 업데이트할 수 있습니다.
      • 수동 전략을 사용하려면 적절한 자격 증명을 가진 사용자가 Operator 업데이트를 승인해야 합니다.
   8. 설치를 클릭합니다.
   9. Operator → 설치된 Operator 페이지로 전환하여 OpenShift Elasticsearch Operator가 설치되었는지 확인합니다.
   10. 상태가 성공인 모든 프로젝트에 OpenShift Elasticsearch Operator가 나열되어 있는지 확인합니다.

2. Red Hat OpenShift Logging Operator를 설치합니다.

   1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
   2. 사용 가능한 Operator 목록에서 Red Hat OpenShift Logging을 선택한 다음 설치를 클릭합니다.
   3. 설치 모드에서 클러스터의 특정 네임스페이스가 선택되어 있는지 확인합니다.
   4. 설치된 네임스페이스에서 Operator 권장 네임스페이스가 openshift-logging인지 확인하십시오.

   5. 이 네임스페이스에서 Operator 권장 클러스터 모니터링 사용을 선택합니다.

      이 옵션은 네임스페이스 오브젝트에서 openshift.io/cluster-monitoring: "true" 레이블을 설정합니다. 클러스터 모니터링이 openshift-logging 네임스페이스를 스크랩하도록 하려면 이 옵션을 선택해야 합니다.

   6. stable-5.x을 업데이트 채널로 선택합니다.

   7. 승인 전략을 선택합니다.

      • 자동 전략을 사용하면 Operator 새 버전이 준비될 때 OLM(Operator Lifecycle Manager)이 자동으로 Operator를 업데이트할 수 있습니다.
      • 수동 전략을 사용하려면 적절한 자격 증명을 가진 사용자가 Operator 업데이트를 승인해야 합니다.
   8. 설치를 클릭합니다.
   9. Operator → 설치된 Operator 페이지로 전환하여 Red Hat OpenShift Logging Operator가 설치되었는지 확인합니다.

   10. Red Hat OpenShift Logging이 openshift-logging 프로젝트에 성공 상태로 나열되어 있는지 확인합니다.

       Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.

       • Operator → 설치된 Operator 페이지로 전환하여 상태 열에 오류 또는 실패가 있는지 점검합니다.
       • 워크로드 → Pod 페이지로 전환하고 openshift-logging 프로젝트에서 문제를 보고하는 Pod의 로그를 확인합니다.

3. OpenShift Logging 인스턴스를 생성합니다.

   1. 관리 → 사용자 정의 리소스 정의 페이지로 전환합니다.
   2. 사용자 정의 리소스 정의 페이지에서 ClusterLogging을 클릭합니다.
   3. 사용자 정의 리소스 정의 상세 정보 페이지의 작업 메뉴에서 인스턴스 보기를 선택합니다.

   4. ClusterLoggings 페이지에서 ClusterLogging 생성을 클릭합니다.

      데이터를 로드하기 위해 페이지를 새로 고쳐야 할 수도 있습니다.

   5. YAML 필드에서 코드를 다음으로 교체합니다.

      참고

      이 기본 OpenShift Logging 구성은 다양한 환경을 지원해야 합니다. OpenShift Logging 클러스터에 수행할 수 있는 수정 사항에 대한 정보는 OpenShift Logging 구성 요소 튜닝 및 구성 주제를 검토하십시오.

      apiVersion: "logging.openshift.io/v1"
      kind: "ClusterLogging"
      metadata:
        name: "instance" 1
        namespace: "openshift-logging"
      spec:
        managementState: "Managed"  2
        logStore:
          type: "elasticsearch"  3
          retentionPolicy: 4
            application:
              maxAge: 1d
            infra:
              maxAge: 7d
            audit:
              maxAge: 7d
          elasticsearch:
            nodeCount: 3 5
            storage:
              storageClassName: "<storage_class_name>" 6
              size: 200G
            resources: 7
                limits:
                  memory: "16Gi"
                requests:
                  memory: "16Gi"
            proxy: 8
              resources:
                limits:
                  memory: 256Mi
                requests:
                  memory: 256Mi
            redundancyPolicy: "SingleRedundancy"
        visualization:
          type: "kibana"  9
          kibana:
            replicas: 1
        collection:
          logs:
            type: "fluentd"  10
            fluentd: {}

      1

      이름은 instance이어야 합니다.

      2

      OpenShift Logging 관리 상태입니다. 경우에 따라 OpenShift Logging 기본값을 변경하는 경우 이를 Unmanaged로 설정해야 합니다. 그러나 관리되지 않는 배포는 OpenShift Logging이 다시 Managed 상태로 될 때까지 업데이트를 받지 않습니다.

      3

      Elasticsearch 구성을 위한 설정입니다. CR을 사용하여 shard 복제 정책 및 영구 스토리지를 구성할 수 있습니다.

      4

      Elasticsearch가 각 로그 소스를 유지해야 하는 시간을 지정합니다. 정수 및 시간 지정을 입력합니다(주(w), 시간(h/H), 분(m) 및 초(s)). 예를 들어 7일은 7d입니다. maxAge보다 오래된 로그는 삭제됩니다. 각 로그 소스에 대한 보존 정책을 지정해야 합니다. 그렇지 않으면 해당 소스에 대해 Elasticsearch 인덱스가 생성되지 않습니다.

      5

      Elasticsearch 노드 수를 지정합니다. 이 목록 뒤에 나오는 참고 사항을 참조하십시오.

      6

      Elasticsearch 스토리지의 기존 스토리지 클래스 이름을 입력합니다. 최상의 성능을 위해서는 블록 스토리지를 할당하는 스토리지 클래스를 지정합니다. 스토리지 클래스를 지정하지 않으면 OpenShift Logging은 임시 스토리지를 사용합니다.

      7

      필요에 따라 Elasticsearch에 대한 CPU 및 메모리 요청을 지정합니다. 이 값을 비워 두면 OpenShift Elasticsearch Operator가 대부분의 배포에 충분한 기본값으로 설정합니다. 기본값은 메모리 요청 시 16Gi이고 CPU 요청 시 1입니다.

      8

      필요에 따라 Elasticsearch 프록시에 대한 CPU 및 메모리 요청을 지정합니다. 이 값을 비워 두면 OpenShift Elasticsearch Operator가 대부분의 배포에 충분한 기본값으로 설정합니다. 기본값은 메모리 요청 시 256Mi이고 CPU 요청 시 100m입니다.

      9

      Kibana 구성을 위한 설정입니다. CR을 사용하여 중복성을 위해 Kibana를 확장하고 Kibana 노드의 CPU 및 메모리를 구성할 수 있습니다. 자세한 내용은 로그 시각화 프로그램 구성을 참조하십시오.

      10

      Fluentd 구성을 위한 설정입니다. CR을 사용하여 Fluentd CPU 및 메모리 제한을 구성할 수 있습니다. 자세한 내용은 Fluentd 구성을 참조하십시오.

      참고

      Elasticsearch 컨트롤 플레인 노드(마스터 노드라고도 함)의 최대 수는 3입니다. 3보다 큰 nodeCount를 지정하면 OpenShift Container Platform은 마스터, 클라이언트 및 데이터 역할을 가진 마스터 적격 노드인 Elasticsearch 노드 3개를 생성합니다. 추가 Elasticsearch 노드는 클라이언트 및 데이터 역할을 사용하여 데이터 전용 노드로 생성됩니다. 컨트롤 플레인 노드는 인덱스 작성 또는 삭제, shard 할당 및 추적 노드와 같은 클러스터 전체 작업을 수행합니다. 데이터 노드는 shard를 보유하고 CRUD, 검색 및 집계와 같은 데이터 관련 작업을 수행합니다. 데이터 관련 작업은 I/O, 메모리 및 CPU 집약적입니다. 현재 노드에 과부하가 걸리면 이러한 리소스를 모니터링하고 더 많은 데이터 노드를 추가하는 것이 중요합니다.

      예를 들어 nodeCount = 4인 경우 다음 노드가 생성됩니다.

      $ oc get deployment

      출력 예

      cluster-logging-operator       1/1     1            1           18h
      elasticsearch-cd-x6kdekli-1    0/1     1            0           6m54s
      elasticsearch-cdm-x6kdekli-1   1/1     1            1           18h
      elasticsearch-cdm-x6kdekli-2   0/1     1            0           6m49s
      elasticsearch-cdm-x6kdekli-3   0/1     1            0           6m44s

      인덱스 템플릿의 기본 shard 수는 Elasticsearch 데이터 노드 수와 같습니다.

   6. 생성을 클릭합니다. 이렇게 하면 OpenShift Logging 구성 요소, Elasticsearch 사용자 정의 리소스 및 구성 요소, Kibana 인터페이스가 생성됩니다.

4. 설치를 확인합니다.

   1. 워크로드 → Pod 페이지로 전환합니다.

   2. openshift-logging 프로젝트를 선택합니다.

      다음 목록과 유사한 OpenShift Logging, Elasticsearch, Fluentd 및 Kibana에 대한 여러 Pod가 표시됩니다.

      • cluster-logging-operator-cb795f8dc-xkckc
      • elasticsearch-cdm-b3nqzchd-1-5c6797-67kfz
      • elasticsearch-cdm-b3nqzchd-2-6657f4-wtprv
      • elasticsearch-cdm-b3nqzchd-3-588c65-clg7g
      • fluentd-2c7dg
      • fluentd-9z7kk
      • fluentd-br7r2
      • fluentd-fn2sb
      • fluentd-pb2f8
      • fluentd-zqgqx
      • kibana-7fb4fd4cc9-bvt4p

1. OpenShift Elasticsearch Operator의 네임스페이스를 생성합니다.

   1. OpenShift Elasticsearch Operator를 위한 네임스페이스 오브젝트 YAML 파일(예: eo-namespace.yaml)을 생성합니다.

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-operators-redhat 1
        annotations:
          openshift.io/node-selector: ""
        labels:
          openshift.io/cluster-monitoring: "true" 2

      1

      openshift-operators-redhat 네임스페이스를 지정해야 합니다. 지표의 충돌을 방지하려면 openshift-operators 네임스페이스가 아니라 openshift-operators-redhat 네임스페이스에서 지표를 스크랩하도록 Prometheus 클러스터 모니터링 스택을 구성해야 합니다. openshift-operators 네임스페이스에 신뢰할 수 없는 Community Operator가 포함될 수 있고, 여기에서 OpenShift Container Platform 지표와 동일한 이름의 지표를 게시하면 충돌이 발생합니다.

      2

      문자열. 클러스터 모니터링이 openshift-operators-redhat 네임스페이스를 스크랩하도록 하려면 표시된 이 레이블을 지정해야 합니다.

   2. 네임스페이스를 생성합니다.

      $ oc create -f <file-name>.yaml

      예를 들면 다음과 같습니다.

      $ oc create -f eo-namespace.yaml

2. Red Hat OpenShift Logging Operator의 네임스페이스를 생성합니다.

   1. Red Hat OpenShift Logging Operator를 위한 네임스페이스 오브젝트 YAML 파일(예: olo-namespace.yaml)을 생성합니다.

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-logging
        annotations:
          openshift.io/node-selector: ""
        labels:
          openshift.io/cluster-monitoring: "true"

   2. 네임스페이스를 생성합니다.

      $ oc create -f <file-name>.yaml

      예를 들면 다음과 같습니다.

      $ oc create -f olo-namespace.yaml

3. 다음 오브젝트를 생성하여 OpenShift Elasticsearch Operator를 설치합니다.

   1. OpenShift Elasticsearch Operator를 위한 Operator 그룹 오브젝트 YAML 파일(예: eo-og.yaml)을 생성합니다.

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: openshift-operators-redhat
        namespace: openshift-operators-redhat 1
      spec: {}

      1

      openshift-operators-redhat 네임스페이스를 지정해야 합니다.

   2. Operator 그룹 오브젝트를 생성합니다.

      $ oc create -f <file-name>.yaml

      예를 들면 다음과 같습니다.

      $ oc create -f eo-og.yaml

   3. 서브스크립션 오브젝트 YAML 파일(예: eo-sub.yaml)을 생성하여 네임스페이스에서 OpenShift Elasticsearch Operator를 서브스크립션합니다.

      서브스크립션의 예

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: "elasticsearch-operator"
        namespace: "openshift-operators-redhat" 1
      spec:
        channel: "stable-5.1" 2
        installPlanApproval: "Automatic"
        source: "redhat-operators" 3
        sourceNamespace: "openshift-marketplace"
        name: "elasticsearch-operator"

      1

      openshift-operators-redhat 네임스페이스를 지정해야 합니다.

      2

      5.0, stable 또는 stable-5.<x>를 채널로 지정합니다. 다음 참고 사항을 참조하십시오.

      3

      redhat-operators를 지정합니다. OpenShift Container Platform 클러스터가 제한된 네트워크(연결이 끊긴 클러스터)에 설치된 경우 OLM(Operator Lifecycle Manager)을 구성할 때 생성된 CatalogSource 오브젝트의 이름을 지정합니다.

      참고

      stable을 지정하면 안정적인 최신 릴리스의 현재 버전이 설치됩니다. installPlanApproval으로 stable 사용: "automatic" 는 자동으로 운영 프로그램을 안정적인 최신 주 릴리스 및 마이너 릴리스로 업그레이드합니다.

      stable-5.<x>를 지정하면 특정 주요 릴리스의 현재 마이너 버전이 설치됩니다. installPlanApproval과 함께 stable-5.<x> 사용: "automatic" 은(는) 자동으로 x로 지정한 주요 릴리스 내의 안정적인 최신 마이너 릴리스로 업그레이드합니다.

   4. 서브스크립션 오브젝트를 생성합니다.

      $ oc create -f <file-name>.yaml

      예를 들면 다음과 같습니다.

      $ oc create -f eo-sub.yaml

      OpenShift Elasticsearch Operator는 openshift-operators-redhat 네임스페이스에 설치되고 클러스터의 각 프로젝트에 복사됩니다.

   5. Operator 설치를 확인합니다.

      $ oc get csv --all-namespaces

      출력 예

      NAMESPACE                                               NAME                                            DISPLAY                  VERSION               REPLACES   PHASE
      default                                                 elasticsearch-operator.5.1.0-202007012112.p0    OpenShift Elasticsearch Operator   5.1.0-202007012112.p0               Succeeded
      kube-node-lease                                         elasticsearch-operator.5.1.0-202007012112.p0    OpenShift Elasticsearch Operator   5.1.0-202007012112.p0               Succeeded
      kube-public                                             elasticsearch-operator.5.1.0-202007012112.p0    OpenShift Elasticsearch Operator   5.1.0-202007012112.p0               Succeeded
      kube-system                                             elasticsearch-operator.5.1.0-202007012112.p0    OpenShift Elasticsearch Operator   5.1.0-202007012112.p0               Succeeded
      openshift-apiserver-operator                            elasticsearch-operator.5.1.0-202007012112.p0    OpenShift Elasticsearch Operator   5.1.0-202007012112.p0               Succeeded
      openshift-apiserver                                     elasticsearch-operator.5.1.0-202007012112.p0    OpenShift Elasticsearch Operator   5.1.0-202007012112.p0               Succeeded
      openshift-authentication-operator                       elasticsearch-operator.5.1.0-202007012112.p0    OpenShift Elasticsearch Operator   5.1.0-202007012112.p0               Succeeded
      openshift-authentication                                elasticsearch-operator.5.1.0-202007012112.p0    OpenShift Elasticsearch Operator   5.1.0-202007012112.p0               Succeeded
      ...

      각 네임스페이스에 OpenShift Elasticsearch Operator가 있어야 합니다. 버전 번호가 표시된 것과 다를 수 있습니다.

4. 다음 오브젝트를 생성하여 Red Hat OpenShift Logging Operator를 설치합니다.

   1. Red Hat OpenShift Logging Operator를 위한 OperatorGroup 오브젝트 YAML 파일(예: olo-og.yaml)을 생성합니다.

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: cluster-logging
        namespace: openshift-logging 1
      spec:
        targetNamespaces:
        - openshift-logging 2

      1 2

      openshift-logging 네임스페이스를 지정해야 합니다.

   2. OperatorGroup 개체를 생성합니다.

      $ oc create -f <file-name>.yaml

      예를 들면 다음과 같습니다.

      $ oc create -f olo-og.yaml

   3. 서브스크립션 오브젝트 YAML 파일(예: olo-sub.yaml)을 생성하여 네임스페이스에서 Red Hat OpenShift Logging Operator를 서브스크립션합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: cluster-logging
        namespace: openshift-logging 1
      spec:
        channel: "stable" 2
        name: cluster-logging
        source: redhat-operators 3
        sourceNamespace: openshift-marketplace

      1

      openshift-logging 네임스페이스를 지정해야 합니다.

      2

      5.0, stable 또는 stable-5.<x>를 채널로 지정합니다.

      3

      redhat-operators를 지정합니다. OpenShift Container Platform 클러스터가 제한된 네트워크(연결이 끊긴 클러스터)에 설치된 경우 OLM(Operator Lifecycle Manager)을 구성할 때 생성된 CatalogSource 오브젝트의 이름을 지정합니다.

      $ oc create -f <file-name>.yaml

      예를 들면 다음과 같습니다.

      $ oc create -f olo-sub.yaml

      Red Hat OpenShift Logging Operator는 openshift-logging 네임스페이스에 설치됩니다.

   4. Operator 설치를 확인합니다.

      openshift-logging 네임스페이스에 Red Hat OpenShift Logging Operator가 있어야 합니다. 버전 번호가 표시된 것과 다를 수 있습니다.

      $ oc get csv -n openshift-logging

      출력 예

      NAMESPACE                                               NAME                                         DISPLAY                  VERSION               REPLACES   PHASE
      ...
      openshift-logging                                       clusterlogging.5.1.0-202007012112.p0         OpenShift Logging          5.1.0-202007012112.p0              Succeeded
      ...

5. OpenShift Logging 인스턴스를 생성합니다.

   1. Red Hat OpenShift Logging Operator를 위한 인스턴스 오브젝트 YAML 파일(예: olo-instance.yaml)을 생성합니다.

      참고

      이 기본 OpenShift Logging 구성은 다양한 환경을 지원해야 합니다. OpenShift Logging 클러스터에 수행할 수 있는 수정 사항에 대한 정보는 OpenShift Logging 구성 요소 튜닝 및 구성 주제를 검토하십시오.

      apiVersion: "logging.openshift.io/v1"
      kind: "ClusterLogging"
      metadata:
        name: "instance" 1
        namespace: "openshift-logging"
      spec:
        managementState: "Managed"  2
        logStore:
          type: "elasticsearch"  3
          retentionPolicy: 4
            application:
              maxAge: 1d
            infra:
              maxAge: 7d
            audit:
              maxAge: 7d
          elasticsearch:
            nodeCount: 3 5
            storage:
              storageClassName: "<storage-class-name>" 6
              size: 200G
            resources: 7
              limits:
                memory: "16Gi"
              requests:
                memory: "16Gi"
            proxy: 8
              resources:
                limits:
                  memory: 256Mi
                requests:
                   memory: 256Mi
            redundancyPolicy: "SingleRedundancy"
        visualization:
          type: "kibana"  9
          kibana:
            replicas: 1
        collection:
          logs:
            type: "fluentd"  10
            fluentd: {}

      1

      이름은 instance이어야 합니다.

      2

      OpenShift Logging 관리 상태입니다. 경우에 따라 OpenShift Logging 기본값을 변경하는 경우 이를 Unmanaged로 설정해야 합니다. 그러나 관리되지 않는 배포는 OpenShift Logging이 다시 Managed 상태로 될 때까지 업데이트를 받지 않습니다. 배포를 다시 Managed 상태로 설정하면 수정한 내용이 취소될 수 있습니다.

      3

      Elasticsearch 구성을 위한 설정입니다. CR(사용자 정의 리소스)을 사용하여 shard 복제 정책 및 영구 스토리지를 구성할 수 있습니다.

      4

      Elasticsearch가 각 로그 소스를 유지해야 하는 시간을 지정합니다. 정수 및 시간 지정을 입력합니다(주(w), 시간(h/H), 분(m) 및 초(s)). 예를 들어 7일은 7d입니다. maxAge보다 오래된 로그는 삭제됩니다. 각 로그 소스에 대한 보존 정책을 지정해야 합니다. 그렇지 않으면 해당 소스에 대해 Elasticsearch 인덱스가 생성되지 않습니다.

      5

      Elasticsearch 노드 수를 지정합니다. 이 목록 뒤에 나오는 참고 사항을 참조하십시오.

      6

      Elasticsearch 스토리지의 기존 스토리지 클래스 이름을 입력합니다. 최상의 성능을 위해서는 블록 스토리지를 할당하는 스토리지 클래스를 지정합니다. 스토리지 클래스를 지정하지 않으면 OpenShift Container Platform은 임시 스토리지로만 OpenShift Logging을 배포합니다.

      7

      필요에 따라 Elasticsearch에 대한 CPU 및 메모리 요청을 지정합니다. 이러한 값을 비워 두면 OpenShift Elasticsearch Operator는 대부분의 배포에 충분한 기본값을 설정합니다. 기본값은 메모리 요청 시 16Gi이고 CPU 요청 시 1입니다.

      8

      필요에 따라 Elasticsearch 프록시에 대한 CPU 및 메모리 요청을 지정합니다. 이 값을 비워 두면 OpenShift Elasticsearch Operator가 대부분의 배포에 충분한 기본값으로 설정합니다. 기본값은 메모리 요청 시 256Mi이고 CPU 요청 시 100m입니다.

      9

      Kibana 구성을 위한 설정입니다. CR을 사용하여 중복성을 위해 Kibana를 확장하고 Kibana 노드의 CPU 및 메모리를 구성할 수 있습니다. 자세한 내용은 로그 시각화 프로그램 구성을 참조하십시오.

      10

      Fluentd 구성을 위한 설정입니다. CR을 사용하여 Fluentd CPU 및 메모리 제한을 구성할 수 있습니다. 자세한 내용은 Fluentd 구성을 참조하십시오.

      참고

      Elasticsearch 컨트롤 플레인 노드의 최대 수는 3입니다. 3보다 큰 nodeCount를 지정하면 OpenShift Container Platform은 마스터, 클라이언트 및 데이터 역할을 가진 마스터 적격 노드인 Elasticsearch 노드 3개를 생성합니다. 추가 Elasticsearch 노드는 클라이언트 및 데이터 역할을 사용하여 데이터 전용 노드로 생성됩니다. 컨트롤 플레인 노드는 인덱스 작성 또는 삭제, shard 할당 및 추적 노드와 같은 클러스터 전체 작업을 수행합니다. 데이터 노드는 shard를 보유하고 CRUD, 검색 및 집계와 같은 데이터 관련 작업을 수행합니다. 데이터 관련 작업은 I/O, 메모리 및 CPU 집약적입니다. 현재 노드에 과부하가 걸리면 이러한 리소스를 모니터링하고 더 많은 데이터 노드를 추가하는 것이 중요합니다.

      예를 들어 nodeCount = 4인 경우 다음 노드가 생성됩니다.

      $ oc get deployment

      출력 예

      cluster-logging-operator       1/1     1            1           18h
      elasticsearch-cd-x6kdekli-1    1/1     1            0           6m54s
      elasticsearch-cdm-x6kdekli-1   1/1     1            1           18h
      elasticsearch-cdm-x6kdekli-2   1/1     1            0           6m49s
      elasticsearch-cdm-x6kdekli-3   1/1     1            0           6m44s

      인덱스 템플릿의 기본 shard 수는 Elasticsearch 데이터 노드 수와 같습니다.

   2. 인스턴스를 생성합니다.

      $ oc create -f <file-name>.yaml

      예를 들면 다음과 같습니다.

      $ oc create -f olo-instance.yaml

      이렇게 하면 OpenShift Logging 구성 요소, Elasticsearch 사용자 정의 리소스 및 구성 요소, Kibana 인터페이스가 생성됩니다.

6. openshift-logging 프로젝트에 Pod를 나열하여 설치를 확인합니다.

   다음 목록과 유사한 OpenShift Logging, Elasticsearch, Fluentd 및 Kibana에 대한 여러 Pod가 표시됩니다.

   $ oc get pods -n openshift-logging

   출력 예

   NAME                                            READY   STATUS    RESTARTS   AGE
   cluster-logging-operator-66f77ffccb-ppzbg       1/1     Running   0          7m
   elasticsearch-cdm-ftuhduuw-1-ffc4b9566-q6bhp    2/2     Running   0          2m40s
   elasticsearch-cdm-ftuhduuw-2-7b4994dbfc-rd2gc   2/2     Running   0          2m36s
   elasticsearch-cdm-ftuhduuw-3-84b5ff7ff8-gqnm2   2/2     Running   0          2m4s
   fluentd-587vb                                   1/1     Running   0          2m26s
   fluentd-7mpb9                                   1/1     Running   0          2m30s
   fluentd-flm6j                                   1/1     Running   0          2m33s
   fluentd-gn4rn                                   1/1     Running   0          2m26s
   fluentd-nlgb6                                   1/1     Running   0          2m30s
   fluentd-snpkt                                   1/1     Running   0          2m28s
   kibana-d6d5668c5-rppqm                          2/2     Running   0          2m39s

프로세스(UI)

1. OpenShift Container Platform 콘솔에서 워크로드 → Pod로 이동하거나 조사하려는 리소스를 통해 Pod로 이동합니다.

   참고

   빌드와 같은 일부 리소스에는 직접 쿼리할 Pod가 없습니다. 이러한 인스턴스에서 리소스의 세부 정보 페이지에서 로그 링크를 찾을 수 있습니다.

2. 드롭다운 메뉴에서 프로젝트를 선택합니다.
3. 조사할 Pod 이름을 클릭합니다.
4. 로그를 클릭합니다.

1. OpenShift Container Platform 콘솔에서 Application Launcher 를 클릭하고 로깅을 선택합니다.

2. 관리 → 인덱스 패턴 → 인덱스 패턴 생성을 클릭하여 Kibana 인덱스 패턴을 생성합니다.

   • 각 사용자는 프로젝트의 로그를 보려면 Kibana에 로그인할 때 수동으로 인덱스 패턴을 생성해야 합니다. 사용자는 app이라는 새 인덱스 패턴을 생성하고 @timestamp 시간 필드를 사용하여 컨테이너 로그를 확인해야 합니다.
   • 관리자는 @timestamp 시간 필드를 사용하여 app, infra, audit 인덱스에 대해 처음 Kibana에 로그인할 때 인덱스 패턴을 생성해야 합니다.
3. 새로운 인덱스 패턴에서 Kibana 시각화를 생성합니다.

1. OpenShift Container Platform 콘솔에서 Application Launcher 를 클릭하고 로깅을 선택합니다.

2. OpenShift Container Platform 콘솔에 로그인할 때 사용하는 것과 동일한 자격 증명을 사용하여 로그인합니다.

   Kibana 인터페이스가 시작됩니다.

3. Kibana에서 검색을 클릭합니다.

4. 왼쪽 상단 드롭다운 메뉴에서 생성한 인덱스 패턴(app, audit 또는 infra)을 선택합니다.

   로그 데이터가 타임스탬프가 있는 문서로 표시됩니다.

5. 타임스탬프가 있는 문서 중 하나를 확장합니다.

6. JSON 탭을 클릭하여 해당 문서에 대한 로그 항목을 표시합니다.

   예 6.1. Kibana의 샘플 인프라 로그 항목

   {
     "_index": "infra-000001",
     "_type": "_doc",
     "_id": "YmJmYTBlNDkZTRmLTliMGQtMjE3NmFiOGUyOWM3",
     "_version": 1,
     "_score": null,
     "_source": {
       "docker": {
         "container_id": "f85fa55bbef7bb783f041066be1e7c267a6b88c4603dfce213e32c1"
       },
       "kubernetes": {
         "container_name": "registry-server",
         "namespace_name": "openshift-marketplace",
         "pod_name": "redhat-marketplace-n64gc",
         "container_image": "registry.redhat.io/redhat/redhat-marketplace-index:v4.7",
         "container_image_id": "registry.redhat.io/redhat/redhat-marketplace-index@sha256:65fc0c45aabb95809e376feb065771ecda9e5e59cc8b3024c4545c168f",
         "pod_id": "8f594ea2-c866-4b5c-a1c8-a50756704b2a",
         "host": "ip-10-0-182-28.us-east-2.compute.internal",
         "master_url": "https://kubernetes.default.svc",
         "namespace_id": "3abab127-7669-4eb3-b9ef-44c04ad68d38",
         "namespace_labels": {
           "openshift_io/cluster-monitoring": "true"
         },
         "flat_labels": [
           "catalogsource_operators_coreos_com/update=redhat-marketplace"
         ]
       },
       "message": "time=\"2020-09-23T20:47:03Z\" level=info msg=\"serving registry\" database=/database/index.db port=50051",
       "level": "unknown",
       "hostname": "ip-10-0-182-28.internal",
       "pipeline_metadata": {
         "collector": {
           "ipaddr4": "10.0.182.28",
           "inputname": "fluent-plugin-systemd",
           "name": "fluentd",
           "received_at": "2020-09-23T20:47:15.007583+00:00",
           "version": "1.7.4 1.6.0"
         }
       },
       "@timestamp": "2020-09-23T20:47:03.422465+00:00",
       "viaq_msg_id": "YmJmYTBlNDktMDMGQtMjE3NmFiOGUyOWM3",
       "openshift": {
         "labels": {
           "logging": "infra"
         }
       }
     },
     "fields": {
       "@timestamp": [
         "2020-09-23T20:47:03.422Z"
       ],
       "pipeline_metadata.collector.received_at": [
         "2020-09-23T20:47:15.007Z"
       ]
     },
     "sort": [
       1600894023422
     ]
   }

절차

1. 다음과 유사한 ClusterLogForwarder CR YAML 파일을 생성합니다.

   apiVersion: "logging.openshift.io/v1"
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: elasticsearch-insecure 3
        type: "elasticsearch" 4
        url: http://elasticsearch.insecure.com:9200 5
      - name: elasticsearch-secure
        type: "elasticsearch"
        url: https://elasticsearch.secure.com:9200
        secret:
           name: es-secret 6
     pipelines:
      - name: application-logs 7
        inputRefs: 8
        - application
        - audit
        outputRefs:
        - elasticsearch-secure 9
        - default 10
        parse: json 11
        labels:
          myLabel: "myValue" 12
      - name: infrastructure-audit-logs 13
        inputRefs:
        - infrastructure
        outputRefs:
        - elasticsearch-insecure
        labels:
          logs: "audit-infra"

   1

   ClusterLogForwarder CR의 이름은 instance여야 합니다.

   2

   ClusterLogForwarder CR의 네임스페이스는 openshift-logging이어야 합니다.

   3

   출력 이름을 지정합니다.

   4

   elasticsearch 유형을 지정합니다.

   5

   외부 Elasticsearch 인스턴스의 URL과 포트를 유효한 절대 URL로 지정합니다. http(비보안) 또는 https(보안 HTTP) 프로토콜을 사용할 수 있습니다. CIDR 주석을 사용하는 클러스터 전체 프록시가 활성화된 경우 출력은 IP 주소가 아닌 서버 이름 또는 FQDN이어야 합니다.

   6

   https 접두사를 사용하는 경우 TLS 통신을 위해 끝점에서 요구하는 시크릿 이름을 지정해야 합니다. 시크릿은 openshift-logging 프로젝트에 있어야 하며 각각의 인증서를 가리키는 tls.crt, tls.key 및 ca-bundle.crt 키가 있어야 합니다.

   7

   선택 사항: 파이프라인의 이름을 지정합니다.

   8

   application, infrastructure, 또는 audit등 해당 파이프라인을 사용하여 전달해야 하는 로그 유형을 지정합니다.

   9

   로그 전달을 위해 해당 파이프라인과 함께 사용할 출력을 지정합니다.

   10

   선택 사항: 로그를 내부 Elasticsearch 인스턴스로 보내려면 기본 출력을 지정합니다.

   11

   선택 사항: 구조화된 필드의 JSON 오브젝트로 구조화된 JSON 로그 항목을 전달합니다. 로그 항목에 유효한 구조화된 JSON이 포함되어야 합니다. 그렇지 않으면 OpenShift Logging이 structured 필드를 제거하고 대신 기본 인덱스인 app-00000x로 로그 항목을 보냅니다.

   12

   선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.

   13

   선택 사항: 지원되는 유형의 다른 외부 로그 집계기로 로그를 전달하도록 다중 출력을 구성합니다.

   • 선택 사항: 파이프라인을 설명하는 이름입니다.
   • inputRefs는 application, infrastructure 또는 audit 등 해당 파이프라인을 사용하여 전달할 로그 유형입니다.
   • outputRefs는 사용할 출력의 이름입니다.
   • 선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.

2. CR 오브젝트를 생성합니다.

   $ oc create -f <file-name>.yaml

절차

1. 다음과 유사한 ClusterLogForwarder CR YAML 파일을 생성합니다.

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: fluentd-server-secure 3
        type: fluentdForward 4
        url: 'tls://fluentdserver.security.example.com:24224' 5
        secret: 6
           name: fluentd-secret
      - name: fluentd-server-insecure
        type: fluentdForward
        url: 'tcp://fluentdserver.home.example.com:24224'
     pipelines:
      - name: forward-to-fluentd-secure 7
        inputRefs:  8
        - application
        - audit
        outputRefs:
        - fluentd-server-secure 9
        - default 10
        parse: json 11
        labels:
          clusterId: "C1234" 12
      - name: forward-to-fluentd-insecure 13
        inputRefs:
        - infrastructure
        outputRefs:
        - fluentd-server-insecure
        labels:
          clusterId: "C1234"

   1

   ClusterLogForwarder CR의 이름은 instance여야 합니다.

   2

   ClusterLogForwarder CR의 네임스페이스는 openshift-logging이어야 합니다.

   3

   출력 이름을 지정합니다.

   4

   fluentdForward 유형을 지정합니다.

   5

   유효한 절대 URL로 외부 Fluentd 인스턴스의 URL 및 포트를 지정합니다. tcp(비보안) 또는 tls(보안 TCP) 프로토콜을 사용할 수 있습니다. CIDR 주석을 사용하는 클러스터 전체 프록시가 활성화된 경우 출력은 IP 주소가 아닌 서버 이름 또는 FQDN이어야 합니다.

   6

   tls 접두사를 사용하는 경우 TLS 통신을 위해 끝점에서 요구하는 시크릿 이름을 지정해야 합니다. 시크릿은 openshift-logging 프로젝트에 있어야 하며 각각의 인증서를 가리키는 tls.crt, tls.key 및 ca-bundle.crt 키가 있어야 합니다.

   7

   선택 사항입니다. 파이프라인의 이름을 지정합니다.

   8

   application, infrastructure, 또는 audit등 해당 파이프라인을 사용하여 전달해야 하는 로그 유형을 지정합니다.

   9

   로그 전달을 위해 해당 파이프라인과 함께 사용할 출력을 지정합니다.

   10

   선택 사항입니다. 로그를 내부 Elasticsearch 인스턴스로 전달하려면 default 출력을 지정합니다.

   11

   선택 사항: 구조화된 필드의 JSON 오브젝트로 구조화된 JSON 로그 항목을 전달합니다. 로그 항목에 유효한 구조화된 JSON이 포함되어야 합니다. 그렇지 않으면 OpenShift Logging이 structured 필드를 제거하고 대신 기본 인덱스인 app-00000x로 로그 항목을 보냅니다.

   12

   선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.

   13

   선택 사항: 지원되는 유형의 다른 외부 로그 집계기로 로그를 전달하도록 다중 출력을 구성합니다.

   • 선택 사항: 파이프라인을 설명하는 이름입니다.
   • inputRefs는 application, infrastructure 또는 audit 등 해당 파이프라인을 사용하여 전달할 로그 유형입니다.
   • outputRefs는 사용할 출력의 이름입니다.
   • 선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.

2. CR 오브젝트를 생성합니다.

   $ oc create -f <file-name>.yaml

절차

1. 다음과 유사한 ClusterLogForwarder CR YAML 파일을 생성합니다.

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: rsyslog-east 3
        type: syslog 4
        syslog: 5
          facility: local0
          rfc: RFC3164
          payloadKey: message
          severity: informational
        url: 'tls://rsyslogserver.east.example.com:514' 6
        secret: 7
           name: syslog-secret
      - name: rsyslog-west
        type: syslog
        syslog:
         appName: myapp
         facility: user
         msgID: mymsg
         procID: myproc
         rfc: RFC5424
         severity: debug
        url: 'udp://rsyslogserver.west.example.com:514'
     pipelines:
      - name: syslog-east 8
        inputRefs: 9
        - audit
        - application
        outputRefs: 10
        - rsyslog-east
        - default 11
        parse: json 12
        labels:
          secure: "true" 13
          syslog: "east"
      - name: syslog-west 14
        inputRefs:
        - infrastructure
        outputRefs:
        - rsyslog-west
        - default
        labels:
          syslog: "west"

   1

   ClusterLogForwarder CR의 이름은 instance여야 합니다.

   2

   ClusterLogForwarder CR의 네임스페이스는 openshift-logging이어야 합니다.

   3

   출력 이름을 지정합니다.

   4

   syslog 유형을 지정합니다.

   5

   선택 사항입니다. 아래 나열된 syslog 매개변수를 지정합니다.

   6

   외부 syslog 인스턴스의 URL 및 포트를 지정합니다. udp(비보안), tcp(비보안) 또는 tls(보안 TCP) 프로토콜을 사용할 수 있습니다. CIDR 주석을 사용하는 클러스터 전체 프록시가 활성화된 경우 출력은 IP 주소가 아닌 서버 이름 또는 FQDN이어야 합니다.

   7

   tls 접두사를 사용하는 경우 TLS 통신을 위해 끝점에서 요구하는 시크릿 이름을 지정해야 합니다. 시크릿은 openshift-logging 프로젝트에 있어야 하며 각각의 인증서를 가리키는 tls.crt, tls.key 및 ca-bundle.crt 키가 있어야 합니다.

   8

   선택 사항: 파이프라인의 이름을 지정합니다.

   9

   application, infrastructure, 또는 audit등 해당 파이프라인을 사용하여 전달해야 하는 로그 유형을 지정합니다.

   10

   로그 전달을 위해 해당 파이프라인과 함께 사용할 출력을 지정합니다.

   11

   선택 사항: 로그를 내부 Elasticsearch 인스턴스로 전달하려면 default 출력을 지정합니다.

   12

   선택 사항: 구조화된 필드의 JSON 오브젝트로 구조화된 JSON 로그 항목을 전달합니다. 로그 항목에 유효한 구조화된 JSON이 포함되어야 합니다. 그렇지 않으면 OpenShift Logging이 structured 필드를 제거하고 대신 기본 인덱스인 app-00000x로 로그 항목을 보냅니다.

   13

   선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다. "true"와 같은 인용 값은 부울 값이 아닌 문자열 값으로 인식됩니다.

   14

   선택 사항: 지원되는 유형의 다른 외부 로그 집계기로 로그를 전달하도록 다중 출력을 구성합니다.

   • 선택 사항: 파이프라인을 설명하는 이름입니다.
   • inputRefs는 application, infrastructure 또는 audit 등 해당 파이프라인을 사용하여 전달할 로그 유형입니다.
   • outputRefs는 사용할 출력의 이름입니다.
   • 선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.

2. CR 오브젝트를 생성합니다.

   $ oc create -f <file-name>.yaml

프로세스

1. 다음과 유사한 ClusterLogForwarder CR YAML 파일을 생성합니다.

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: app-logs 3
        type: kafka 4
        url: tls://kafka.example.devlab.com:9093/app-topic 5
        secret:
          name: kafka-secret 6
      - name: infra-logs
        type: kafka
        url: tcp://kafka.devlab2.example.com:9093/infra-topic 7
      - name: audit-logs
        type: kafka
        url: tls://kafka.qelab.example.com:9093/audit-topic
        secret:
           name: kafka-secret-qe
     pipelines:
      - name: app-topic 8
        inputRefs: 9
        - application
        outputRefs: 10
        - app-logs
        parse: json 11
        labels:
          logType: "application" 12
      - name: infra-topic 13
        inputRefs:
        - infrastructure
        outputRefs:
        - infra-logs
        labels:
          logType: "infra"
      - name: audit-topic
        inputRefs:
        - audit
        outputRefs:
        - audit-logs
        - default 14
        labels:
          logType: "audit"

   1

   ClusterLogForwarder CR의 이름은 instance여야 합니다.

   2

   ClusterLogForwarder CR의 네임스페이스는 openshift-logging이어야 합니다.

   3

   출력 이름을 지정합니다.

   4

   kafka 유형을 지정합니다.

   5

   Kafka 브로커의 URL과 포트를 유효한 절대 URL로 지정하고 선택적으로 특정 주제를 사용합니다. tcp(비보안) 또는 tls(보안 TCP) 프로토콜을 사용할 수 있습니다. CIDR 주석을 사용하는 클러스터 전체 프록시가 활성화된 경우 출력은 IP 주소가 아닌 서버 이름 또는 FQDN이어야 합니다.

   6

   tls 접두사를 사용하는 경우 TLS 통신을 위해 끝점에서 요구하는 시크릿 이름을 지정해야 합니다. 시크릿은 openshift-logging 프로젝트에 있어야 하며 각각의 인증서를 가리키는 tls.crt, tls.key 및 ca-bundle.crt 키가 있어야 합니다.

   7

   선택 사항: 안전하지 않은 출력을 보내려면 URL 앞에 있는 tcp 접두사를 사용합니다. 이 출력에서 secret 키와 해당 name을 생략합니다.

   8

   선택 사항: 파이프라인의 이름을 지정합니다.

   9

   application, infrastructure, 또는 audit등 해당 파이프라인을 사용하여 전달해야 하는 로그 유형을 지정합니다.

   10

   로그 전달을 위해 해당 파이프라인과 함께 사용할 출력을 지정합니다.

   11

   선택 사항: 구조화된 필드의 JSON 오브젝트로 구조화된 JSON 로그 항목을 전달합니다. 로그 항목에 유효한 구조화된 JSON이 포함되어야 합니다. 그렇지 않으면 OpenShift Logging이 structured 필드를 제거하고 대신 기본 인덱스인 app-00000x로 로그 항목을 보냅니다.

   12

   선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.

   13

   선택 사항: 지원되는 유형의 다른 외부 로그 집계기로 로그를 전달하도록 다중 출력을 구성합니다.

   • 선택 사항: 파이프라인을 설명하는 이름입니다.
   • inputRefs는 application, infrastructure 또는 audit 등 해당 파이프라인을 사용하여 전달할 로그 유형입니다.
   • outputRefs는 사용할 출력의 이름입니다.
   • 선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.

   14

   선택 사항: 내부 Elasticsearch 인스턴스로 로그를 전달하려면 기본값 을 지정합니다.

2. 선택 사항: 단일 출력을 여러 Kafka 브로커로 전달하려면 다음 예와 같이 Kafka 브로커 배열을 지정합니다.

   ...
   spec:
     outputs:
     - name: app-logs
       type: kafka
       secret:
         name: kafka-secret-dev
       kafka:  1
         brokers: 2
           - tls://kafka-broker1.example.com:9093/
           - tls://kafka-broker2.example.com:9093/
         topic: app-topic 3
   ...

   1

   brokers 및 topic 키가 있는 kafka 키를 지정합니다.

   2

   brokers 키를 사용하여 하나 이상의 브로커 배열을 지정합니다.

   3

   topic 키를 사용하여 로그를 수신할 대상 항목을 지정합니다.

3. CR 오브젝트를 생성합니다.

   $ oc create -f <file-name>.yaml

절차

1. 다음과 유사한 ClusterLogForwarder CR YAML 파일을 생성합니다.

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: fluentd-server-secure 3
        type: fluentdForward 4
        url: 'tls://fluentdserver.security.example.com:24224' 5
        secret: 6
           name: fluentd-secret
      - name: fluentd-server-insecure
        type: fluentdForward
        url: 'tcp://fluentdserver.home.example.com:24224'
     inputs: 7
      - name: my-app-logs
        application:
           namespaces:
           - my-project
     pipelines:
      - name: forward-to-fluentd-insecure 8
        inputRefs: 9
        - my-app-logs
        outputRefs: 10
        - fluentd-server-insecure
        parse: json 11
        labels:
          project: "my-project" 12
      - name: forward-to-fluentd-secure 13
        inputRefs:
        - application
        - audit
        - infrastructure
        outputRefs:
        - fluentd-server-secure
        - default
        labels:
          clusterId: "C1234"

   1

   ClusterLogForwarder CR의 이름은 instance여야 합니다.

   2

   ClusterLogForwarder CR의 네임스페이스는 openshift-logging이어야 합니다.

   3

   출력 이름을 지정합니다.

   4

   출력 유형을 elasticsearch, fluentdForward, syslog 또는 kafka로 지정합니다.

   5

   외부 로그 집계기의 URL 및 포트를 유효한 절대 URL로 지정합니다. CIDR 주석을 사용하는 클러스터 전체 프록시가 활성화된 경우 출력은 IP 주소가 아닌 서버 이름 또는 FQDN이어야 합니다.

   6

   tls 접두사를 사용하는 경우 TLS 통신을 위해 끝점에서 요구하는 시크릿 이름을 지정해야 합니다. 시크릿은 openshift-logging 프로젝트에 있어야 하며 각각의 인증서를 가리키는 tls.crt, tls.key, 및 ca-bundle.crt 키가 있어야 합니다.

   7

   지정된 프로젝트에서 애플리케이션 로그를 필터링하기 위한 입력 구성입니다.

   8

   입력을 사용하여 프로젝트 애플리케이션 로그를 외부 Fluentd 인스턴스로 보내는 파이프라인 구성입니다.

   9

   my-app-logs 입력입니다.

   10

   사용할 출력의 이름입니다.

   11

   선택 사항: 구조화된 필드의 JSON 오브젝트로 구조화된 JSON 로그 항목을 전달합니다. 로그 항목에 유효한 구조화된 JSON이 포함되어야 합니다. 그렇지 않으면 OpenShift Logging이 structured 필드를 제거하고 대신 기본 인덱스인 app-00000x로 로그 항목을 보냅니다.

   12

   선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.

   13

   로그를 다른 로그 집계기로 보내는 파이프라인 구성입니다.

   • 선택 사항: 파이프라인의 이름을 지정합니다.
   • application, infrastructure, 또는 audit등 해당 파이프라인을 사용하여 전달해야 하는 로그 유형을 지정합니다.
   • 로그 전달을 위해 해당 파이프라인과 함께 사용할 출력을 지정합니다.
   • 선택 사항: 로그를 내부 Elasticsearch 인스턴스로 전달하려면 default 출력을 지정합니다.
   • 선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.

2. CR 오브젝트를 생성합니다.

   $ oc create -f <file-name>.yaml

프로세스

1. ClusterLogForwarder CR(사용자 정의 리소스) YAML 파일을 생성합니다.

2. YAML 파일에서 다음 예와 같이 inputs[].name.application.selector.matchLabels에서 간단한 동일성 기반 선택기를 사용하여 Pod 레이블을 지정합니다.

   ClusterLogForwarder CR YAML 파일의 예

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     pipelines:
       - inputRefs: [ myAppLogData ] 3
         outputRefs: [ default ] 4
         parse: json 5
     inputs: 6
       - name: myAppLogData
         application:
           selector:
             matchLabels: 7
               environment: production
               app: nginx
           namespaces: 8
           - app1
           - app2
     outputs: 9
       - default
       ...

   1

   ClusterLogForwarder CR의 이름은 instance여야 합니다.

   2

   ClusterLogForwarder CR의 네임스페이스는 openshift-logging이어야 합니다.

   3

   inputs[].name에서 하나 이상의 쉼표로 구분된 값을 지정합니다.

   4

   outputs[]에서 하나 이상의 쉼표로 구분된 값을 지정합니다.

   5

   선택 사항: 구조화된 필드의 JSON 오브젝트로 구조화된 JSON 로그 항목을 전달합니다. 로그 항목에 유효한 구조화된 JSON이 포함되어야 합니다. 그렇지 않으면 OpenShift Logging이 structured 필드를 제거하고 대신 기본 인덱스인 app-00000x로 로그 항목을 보냅니다.

   6

   고유한 pod 레이블 집합이 있는 각 애플리케이션에 대해 고유한 inputs[].name을 정의합니다.

   7

   수집하려는 로그 데이터가 있는 Pod 라벨의 키-값 쌍을 지정합니다. 키뿐만 아니라 키와 값 모두를 지정해야 합니다. 선택하려면 Pod가 모든 키-값 쌍과 일치해야 합니다.

   8

   선택 사항: 하나 이상의 네임스페이스를 지정합니다.

   9

   로그 데이터를 전달할 출력을 하나 이상 지정합니다. 여기에 표시된 default 출력 (선택 사항)은 로그 데이터를 내부 Elasticsearch 인스턴스로 전송합니다.

3. 선택 사항: 로그 데이터 수집을 특정 네임스페이스로 제한하려면 위 예제와 같이 inputs[].name.application.namespaces 를 사용합니다.

4. 선택 사항: 다른 Pod 라벨이 있는 추가 애플리케이션에서 동일한 파이프라인으로 로그 데이터를 보낼 수 있습니다.

   1. Pod 레이블의 고유한 조합마다 표시된 항목과 유사한 추가 inputs[].name 섹션을 생성합니다.
   2. 이 애플리케이션의 Pod 레이블과 일치하도록 selectors를 업데이트합니다.

   3. 새 inputs[].name 값을 inputRefs에 추가합니다. 예를 들면 다음과 같습니다.

      - inputRefs: [ myAppLogData, myOtherAppLogData ]

5. CR 오브젝트를 생성합니다.

   $ oc create -f <file-name>.yaml

1. secure-forward라는 구성 파일을 생성하고 <store> 스탠자에서 다음과 유사한 매개변수를 지정합니다.

   <store>
     @type forward
     <security>
       self_hostname ${hostname}
       shared_key <key> 1
     </security>
     transport tls 2
     tls_verify_hostname <value> 3
     tls_cert_path <path_to_file> 4
     <buffer> 5
       @type file
       path '/var/lib/fluentd/secureforwardlegacy'
       queued_chunks_limit_size "#{ENV['BUFFER_QUEUE_LIMIT'] || '1024' }"
       chunk_limit_size "#{ENV['BUFFER_SIZE_LIMIT'] || '1m' }"
       flush_interval "#{ENV['FORWARD_FLUSH_INTERVAL'] || '5s'}"
       flush_at_shutdown "#{ENV['FLUSH_AT_SHUTDOWN'] || 'false'}"
       flush_thread_count "#{ENV['FLUSH_THREAD_COUNT'] || 2}"
       retry_max_interval "#{ENV['FORWARD_RETRY_WAIT'] || '300'}"
       retry_forever true
     </buffer>
     <server>
       name 6
       host 7
       hostlabel 8
       port 9
     </server>
     <server> 10
       name
       host
     </server>

   1

   노드 간 공유 키를 입력합니다.

   2

   TLS 유효성 검증을 사용하려면 tls를 지정합니다.

   3

   서버 인증서 호스트 이름을 확인하려면 true로 설정합니다. 서버 인증서 호스트 이름을 무시하려면 false로 설정합니다.

   4

   사설 CA 인증서 파일의 경로를 /etc/ocp-forward/ca_cert.pem으로 지정합니다.

   5

   필요에 따라 Fluentd 버퍼 매개변수를 지정합니다.

   6

   선택적으로 이 서버의 이름을 입력합니다.

   7

   서버의 호스트 이름 또는 IP를 지정합니다.

   8

   서버의 호스트 레이블을 지정합니다.

   9

   서버의 포트를 지정합니다.

   10

   선택적으로 추가 서버를 추가합니다. 둘 이상의 서버를 지정하면 forward는 이러한 서버 노드를 라운드 로빈 순서로 사용합니다.

   상호 TLS(mTLS) 인증을 사용하려면 Fluentd 설명서에서 클라이언트 인증서, 키 매개변수 및 기타 설정에 대한 정보를 참조하십시오.

2. 구성 파일에서 openshift-logging 프로젝트에 secure-forward라는 구성 맵을 생성합니다.

   $ oc create configmap secure-forward --from-file=secure-forward.conf -n openshift-logging

1. syslog.conf라는 구성 파일을 생성하고 <store> 스탠자에서 다음과 유사한 매개변수를 지정합니다.

   <store>
   @type <type> 1
   remote_syslog <syslog-server> 2
   port 514 3
   hostname ${hostname}
   remove_tag_prefix <prefix> 4
   facility <value>
   severity <value>
   use_record <value>
   payload_key message
   rfc 3164 5
   </store>

   1

   사용할 프로토콜을 syslog 또는 syslog_buffered로 지정합니다.

   2

   syslog 서버의 FQDN 또는 IP 주소를 지정합니다.

   3

   syslog 서버의 포트를 지정합니다.

   4

   선택 사항: 적절한 syslog 매개변수를 지정합니다. 예를 들면 다음과 같습니다.

   • syslog 접두사에서 지정된 태그 필드를 제거하기 위한 매개변수입니다.
   • 지정된 필드를 syslog 키로 설정하는 매개변수입니다.
   • syslog 로그 기능 또는 소스를 지정하는 매개변수입니다.
   • syslog 로그 심각도를 지정하는 매개변수입니다.
   • 가능한 경우 레코드에서 심각도 및 기능을 사용하는 매개변수입니다. true인 경우 container_name, namespace_name, pod_name이 출력 콘텐츠에 포함됩니다.
   • syslog 메시지의 페이로드를 설정하기 위한 키를 지정하는 매개변수입니다. 기본값은 message입니다.

   5

   기존 syslog 방법을 사용하여 rfc 값으로 3164를 지정해야 합니다.

2. 구성 파일에서 openshift-logging 프로젝트에 syslog라는 구성 맵을 생성합니다.

   $ oc create configmap syslog --from-file=syslog.conf -n openshift-logging

절차

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

   outputDefaults:
   - elasticsearch:
       structuredTypeKey: <log record field>
       structuredTypeName: <name>
   pipelines:
   - inputRefs:
     - application
     outputRefs: default
     parse: json

2. 선택 사항: structuredTypeKey 를 사용하여 이전 항목에 설명된 대로 로그 레코드 필드 중 하나를 지정하고 Elasticsearch에 대한 JSON 로그 데이터 구성을 지정합니다. 그렇지 않으면 다음 행을 제거합니다.

3. 선택 사항: structuredTypeName 을 사용하여 이전 항목에 설명된 <name> 을 지정하고 Elasticsearch에 대한 JSON 로그 데이터를 구성합니다. 그렇지 않으면 다음 행을 제거합니다.

   중요

   JSON 로그를 구문 분석하려면 structuredTypeKey 또는 structuredTypeName, structuredTypeKey 및 structuredTypeName 모두를 설정해야 합니다.

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

6. CR 오브젝트를 생성합니다.

   $ oc create -f <file-name>.yaml

   Red Hat OpenShift Logging Operator는 Fluentd Pod를 재배포합니다. Pod가 재배포되지 않으면 Fluentd Pod를 삭제하여 강제로 재배포할 수 있습니다.

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

프로세스

1. 이벤트 라우터용 템플릿을 생성합니다.

   kind: Template
   apiVersion: template.openshift.io/v1
   metadata:
     name: eventrouter-template
     annotations:
       description: "A pod forwarding kubernetes events to OpenShift Logging stack."
       tags: "events,EFK,logging,cluster-logging"
   objects:
     - kind: ServiceAccount 1
       apiVersion: v1
       metadata:
         name: eventrouter
         namespace: ${NAMESPACE}
     - kind: ClusterRole 2
       apiVersion: rbac.authorization.k8s.io/v1
       metadata:
         name: event-reader
       rules:
       - apiGroups: [""]
         resources: ["events"]
         verbs: ["get", "watch", "list"]
     - kind: ClusterRoleBinding  3
       apiVersion: rbac.authorization.k8s.io/v1
       metadata:
         name: event-reader-binding
       subjects:
       - kind: ServiceAccount
         name: eventrouter
         namespace: ${NAMESPACE}
       roleRef:
         kind: ClusterRole
         name: event-reader
     - kind: ConfigMap 4
       apiVersion: v1
       metadata:
         name: eventrouter
         namespace: ${NAMESPACE}
       data:
         config.json: |-
           {
             "sink": "stdout"
           }
     - kind: Deployment 5
       apiVersion: apps/v1
       metadata:
         name: eventrouter
         namespace: ${NAMESPACE}
         labels:
           component: "eventrouter"
           logging-infra: "eventrouter"
           provider: "openshift"
       spec:
         selector:
           matchLabels:
             component: "eventrouter"
             logging-infra: "eventrouter"
             provider: "openshift"
         replicas: 1
         template:
           metadata:
             labels:
               component: "eventrouter"
               logging-infra: "eventrouter"
               provider: "openshift"
             name: eventrouter
           spec:
             serviceAccount: eventrouter
             containers:
               - name: kube-eventrouter
                 image: ${IMAGE}
                 imagePullPolicy: IfNotPresent
                 resources:
                   requests:
                     cpu: ${CPU}
                     memory: ${MEMORY}
                 volumeMounts:
                 - name: config-volume
                   mountPath: /etc/eventrouter
             volumes:
               - name: config-volume
                 configMap:
                   name: eventrouter
   parameters:
     - name: IMAGE 6
       displayName: Image
       value: "registry.redhat.io/openshift-logging/eventrouter-rhel8:v0.3"
     - name: CPU  7
       displayName: CPU
       value: "100m"
     - name: MEMORY 8
       displayName: Memory
       value: "128Mi"
     - name: NAMESPACE
       displayName: Namespace
       value: "openshift-logging" 9

   1

   openshift-logging 프로젝트에서 이벤트 라우터용 서비스 계정을 생성합니다.

   2

   클러스터의 이벤트를 모니터링할 ClusterRole을 생성합니다.

   3

   ClusterRole을 서비스 계정에 바인딩하는 ClusterRoleBinding을 생성합니다.

   4

   openshift-logging 프로젝트에서 구성 맵을 생성하여 필요한 config.json 파일을 생성합니다.

   5

   openshift-logging 프로젝트에서 배포를 생성하여 이벤트 라우터 Pod를 생성하고 구성합니다.

   6

   v0.3 과 같은 태그로 식별되는 이미지를 지정합니다.

   7

   이벤트 라우터 Pod에 할당할 최소 메모리 양을 지정합니다. 기본값은 128Mi입니다.

   8

   이벤트 라우터 Pod에 할당할 최소 CPU 양을 지정합니다. 기본값은 100m입니다.

   9

   오브젝트를 설치할 openshift-logging 프로젝트를 지정합니다.

2. 다음 명령을 사용하여 템플릿을 처리하고 적용합니다.

   $ oc process -f <templatefile> | oc apply -n openshift-logging -f -

   예를 들면 다음과 같습니다.

   $ oc process -f eventrouter.yaml | oc apply -n openshift-logging -f -

   출력 예

   serviceaccount/eventrouter created
   clusterrole.authorization.openshift.io/event-reader created
   clusterrolebinding.authorization.openshift.io/event-reader-binding created
   configmap/eventrouter created
   deployment.apps/eventrouter created

3. openshift-logging 프로젝트에 이벤트 라우터가 설치되었는지 확인합니다.

   1. 새 이벤트 라우터 Pod 보기:

      $ oc get pods --selector  component=eventrouter -o name -n openshift-logging

      출력 예

      pod/cluster-logging-eventrouter-d649f97c8-qvv8r

   2. 이벤트 라우터에서 수집한 이벤트 보기:

      $ oc logs <cluster_logging_eventrouter_pod> -n openshift-logging

      예를 들면 다음과 같습니다.

      $ oc logs cluster-logging-eventrouter-d649f97c8-qvv8r -n openshift-logging

      출력 예

      {"verb":"ADDED","event":{"metadata":{"name":"openshift-service-catalog-controller-manager-remover.1632d931e88fcd8f","namespace":"openshift-service-catalog-removed","selfLink":"/api/v1/namespaces/openshift-service-catalog-removed/events/openshift-service-catalog-controller-manager-remover.1632d931e88fcd8f","uid":"787d7b26-3d2f-4017-b0b0-420db4ae62c0","resourceVersion":"21399","creationTimestamp":"2020-09-08T15:40:26Z"},"involvedObject":{"kind":"Job","namespace":"openshift-service-catalog-removed","name":"openshift-service-catalog-controller-manager-remover","uid":"fac9f479-4ad5-4a57-8adc-cb25d3d9cf8f","apiVersion":"batch/v1","resourceVersion":"21280"},"reason":"Completed","message":"Job completed","source":{"component":"job-controller"},"firstTimestamp":"2020-09-08T15:40:26Z","lastTimestamp":"2020-09-08T15:40:26Z","count":1,"type":"Normal"}}

      Elasticsearch 인프라 인덱스를 사용하는 인덱스 패턴을 생성하여 이벤트를 보도록 Kibana을 사용할 수도 있습니다.

절차

1. OpenShift Elasticsearch Operator를 업데이트합니다.

   1. 웹 콘솔에서 Operator → 설치된 Operator를 클릭합니다.
   2. openshift-operators-redhat 프로젝트를 선택합니다.
   3. OpenShift Elasticsearch Operator를 클릭합니다.
   4. 서브스크립션 → 채널을 클릭합니다.
   5. 서브스크립션 업데이트 채널 변경 창에서 5.0 또는 stable-5.1을 선택하고 저장을 클릭합니다.

   6. 몇 초 정도 기다린 후 Operator → 설치된 Operator를 클릭합니다.

      OpenShift Elasticsearch Operator 버전이 5.x.x인지 확인합니다.

      상태 필드가 성공으로 표시될 때까지 기다립니다.

2. Cluster Logging Operator 업데이트:

   1. 웹 콘솔에서 Operator → 설치된 Operator를 클릭합니다.
   2. openshift-logging 프로젝트를 선택합니다.
   3. Cluster Logging Operator를 클릭합니다.
   4. 서브스크립션 → 채널을 클릭합니다.
   5. 서브스크립션 업데이트 채널 변경 창에서 5.0 또는 stable-5.1을 선택하고 저장을 클릭합니다.

   6. 몇 초 정도 기다린 후 Operator → 설치된 Operator를 클릭합니다.

      Red Hat OpenShif Logging Operator 버전이 5.0.x 또는 5.1.x인지 확인합니다.

      상태 필드가 성공으로 표시될 때까지 기다립니다.

3. 로깅 구성 요소를 확인합니다.

   1. 모든 Elasticsearch Pod가 ready 상태인지 확인합니다.

      $ oc get pod -n openshift-logging --selector component=elasticsearch

      출력 예

      NAME                                            READY   STATUS    RESTARTS   AGE
      elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk   2/2     Running   0          31m
      elasticsearch-cdm-1pbrl44l-2-5c6d87589f-gx5hk   2/2     Running   0          30m
      elasticsearch-cdm-1pbrl44l-3-88df5d47-m45jc     2/2     Running   0          29m

   2. Elasticsearch 클러스터가 정상인지 확인합니다.

      $ oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk -- health

      {
        "cluster_name" : "elasticsearch",
        "status" : "green",
      }

   3. Elasticsearch Cron 작업이 생성되었는지 확인합니다.

      $ oc project openshift-logging

      $ oc get cronjob

      NAME                     SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
      elasticsearch-im-app     */15 * * * *   False     0        <none>          56s
      elasticsearch-im-audit   */15 * * * *   False     0        <none>          56s
      elasticsearch-im-infra   */15 * * * *   False     0        <none>          56s

   4. 로그 저장소가 5.0 또는 5.1로 업데이트되고 인덱스가 green인지 확인합니다.

      $ oc exec -c elasticsearch <any_es_pod_in_the_cluster> -- indices

      출력에 app-00000x, infra-00000x, audit-00000x, .security 인덱스가 포함되어 있는지 확인합니다.

      예 10.1. 인덱스가 녹색 상태인 샘플 출력

      Tue Jun 30 14:30:54 UTC 2020
      health status index                                                                 uuid                   pri rep docs.count docs.deleted store.size pri.store.size
      green  open   infra-000008                                                          bnBvUFEXTWi92z3zWAzieQ   3 1       222195            0        289            144
      green  open   infra-000004                                                          rtDSzoqsSl6saisSK7Au1Q   3 1       226717            0        297            148
      green  open   infra-000012                                                          RSf_kUwDSR2xEuKRZMPqZQ   3 1       227623            0        295            147
      green  open   .kibana_7                                                             1SJdCqlZTPWlIAaOUd78yg   1 1            4            0          0              0
      green  open   infra-000010                                                          iXwL3bnqTuGEABbUDa6OVw   3 1       248368            0        317            158
      green  open   infra-000009                                                          YN9EsULWSNaxWeeNvOs0RA   3 1       258799            0        337            168
      green  open   infra-000014                                                          YP0U6R7FQ_GVQVQZ6Yh9Ig   3 1       223788            0        292            146
      green  open   infra-000015                                                          JRBbAbEmSMqK5X40df9HbQ   3 1       224371            0        291            145
      green  open   .orphaned.2020.06.30                                                  n_xQC2dWQzConkvQqei3YA   3 1            9            0          0              0
      green  open   infra-000007                                                          llkkAVSzSOmosWTSAJM_hg   3 1       228584            0        296            148
      green  open   infra-000005                                                          d9BoGQdiQASsS3BBFm2iRA   3 1       227987            0        297            148
      green  open   infra-000003                                                          1-goREK1QUKlQPAIVkWVaQ   3 1       226719            0        295            147
      green  open   .security                                                             zeT65uOuRTKZMjg_bbUc1g   1 1            5            0          0              0
      green  open   .kibana-377444158_kubeadmin                                           wvMhDwJkR-mRZQO84K0gUQ   3 1            1            0          0              0
      green  open   infra-000006                                                          5H-KBSXGQKiO7hdapDE23g   3 1       226676            0        295            147
      green  open   infra-000001                                                          eH53BQ-bSxSWR5xYZB6lVg   3 1       341800            0        443            220
      green  open   .kibana-6                                                             RVp7TemSSemGJcsSUmuf3A   1 1            4            0          0              0
      green  open   infra-000011                                                          J7XWBauWSTe0jnzX02fU6A   3 1       226100            0        293            146
      green  open   app-000001                                                            axSAFfONQDmKwatkjPXdtw   3 1       103186            0        126             57
      green  open   infra-000016                                                          m9c1iRLtStWSF1GopaRyCg   3 1        13685            0         19              9
      green  open   infra-000002                                                          Hz6WvINtTvKcQzw-ewmbYg   3 1       228994            0        296            148
      green  open   infra-000013                                                          KR9mMFUpQl-jraYtanyIGw   3 1       228166            0        298            148
      green  open   audit-000001                                                          eERqLdLmQOiQDFES1LBATQ   3 1            0            0          0              0

   5. 로그 수집기가 5.0 또는 5.1로 업데이트되었는지 확인합니다.

      $ oc get ds fluentd -o json | grep fluentd-init

      출력에 fluentd-init 컨테이너가 포함되어 있는지 확인합니다.

      "containerName": "fluentd-init"

   6. 로그 시각화 프로그램이 Kibana CRD를 사용하여 5.0 또는 5.1로 업데이트되었는지 확인합니다.

      $ oc get kibana kibana -o json

      출력에 ready 상태가 있는 Kibana pod가 포함되어 있는지 확인합니다.

      예 10.2. Kibana Pod가 준비된 샘플 출력

      [
      {
      "clusterCondition": {
      "kibana-5fdd766ffd-nb2jj": [
      {
      "lastTransitionTime": "2020-06-30T14:11:07Z",
      "reason": "ContainerCreating",
      "status": "True",
      "type": ""
      },
      {
      "lastTransitionTime": "2020-06-30T14:11:07Z",
      "reason": "ContainerCreating",
      "status": "True",
      "type": ""
      }
      ]
      },
      "deployment": "kibana",
      "pods": {
      "failed": [],
      "notReady": []
      "ready": []
      },
      "replicaSets": [
      "kibana-5fdd766ffd"
      ],
      "replicas": 1
      }
      ]

절차

1. OpenShift Elasticsearch Operator를 업데이트합니다.

   1. 웹 콘솔에서 Operator → 설치된 Operator를 클릭합니다.
   2. openshift-operators-redhat 프로젝트를 선택합니다.
   3. OpenShift Elasticsearch Operator를 클릭합니다.
   4. 서브스크립션 → 채널을 클릭합니다.
   5. 서브스크립션 업데이트 채널 변경 창에서 stable-5.x을 선택하고 저장을 클릭합니다.

   6. 몇 초 정도 기다린 후 Operator → 설치된 Operator를 클릭합니다.

      OpenShift Elasticsearch Operator 버전이 5.x.x인지 확인합니다.

      상태 필드가 성공으로 표시될 때까지 기다립니다.

2. Red Hat OpenShift Logging Operator를 업데이트합니다.

   1. 웹 콘솔에서 Operator → 설치된 Operator를 클릭합니다.
   2. openshift-logging 프로젝트를 선택합니다.
   3. Red Hat OpenShift Logging Operator를 클릭합니다.
   4. 서브스크립션 → 채널을 클릭합니다.
   5. 서브스크립션 업데이트 채널 변경 창에서 stable-5.x을 선택하고 저장을 클릭합니다.

   6. 몇 초 정도 기다린 후 Operator → 설치된 Operator를 클릭합니다.

      Red Hat OpenShif Logging Operator 버전이 5.x.x인지 확인합니다.

      상태 필드가 성공으로 표시될 때까지 기다립니다.

3. 로깅 구성 요소를 확인합니다.

   1. 모든 Elasticsearch Pod가 ready 상태인지 확인합니다.

      $ oc get pod -n openshift-logging --selector component=elasticsearch

      출력 예

      NAME                                            READY   STATUS    RESTARTS   AGE
      elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk   2/2     Running   0          31m
      elasticsearch-cdm-1pbrl44l-2-5c6d87589f-gx5hk   2/2     Running   0          30m
      elasticsearch-cdm-1pbrl44l-3-88df5d47-m45jc     2/2     Running   0          29m

   2. Elasticsearch 클러스터가 정상인지 확인합니다.

      $ oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk -- health

      {
        "cluster_name" : "elasticsearch",
        "status" : "green",
      }

   3. Elasticsearch Cron 작업이 생성되었는지 확인합니다.

      $ oc project openshift-logging

      $ oc get cronjob

      NAME                     SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
      elasticsearch-im-app     */15 * * * *   False     0        <none>          56s
      elasticsearch-im-audit   */15 * * * *   False     0        <none>          56s
      elasticsearch-im-infra   */15 * * * *   False     0        <none>          56s

   4. 로그 저장소가 5.x로 업데이트되고 인덱스가 green인지 확인합니다.

      $ oc exec -c elasticsearch <any_es_pod_in_the_cluster> -- indices

      출력에 app-00000x, infra-00000x, audit-00000x, .security 인덱스가 포함되어 있는지 확인합니다.

      예 10.3. 인덱스가 녹색 상태인 샘플 출력

      Tue Jun 30 14:30:54 UTC 2020
      health status index                                                                 uuid                   pri rep docs.count docs.deleted store.size pri.store.size
      green  open   infra-000008                                                          bnBvUFEXTWi92z3zWAzieQ   3 1       222195            0        289            144
      green  open   infra-000004                                                          rtDSzoqsSl6saisSK7Au1Q   3 1       226717            0        297            148
      green  open   infra-000012                                                          RSf_kUwDSR2xEuKRZMPqZQ   3 1       227623            0        295            147
      green  open   .kibana_7                                                             1SJdCqlZTPWlIAaOUd78yg   1 1            4            0          0              0
      green  open   infra-000010                                                          iXwL3bnqTuGEABbUDa6OVw   3 1       248368            0        317            158
      green  open   infra-000009                                                          YN9EsULWSNaxWeeNvOs0RA   3 1       258799            0        337            168
      green  open   infra-000014                                                          YP0U6R7FQ_GVQVQZ6Yh9Ig   3 1       223788            0        292            146
      green  open   infra-000015                                                          JRBbAbEmSMqK5X40df9HbQ   3 1       224371            0        291            145
      green  open   .orphaned.2020.06.30                                                  n_xQC2dWQzConkvQqei3YA   3 1            9            0          0              0
      green  open   infra-000007                                                          llkkAVSzSOmosWTSAJM_hg   3 1       228584            0        296            148
      green  open   infra-000005                                                          d9BoGQdiQASsS3BBFm2iRA   3 1       227987            0        297            148
      green  open   infra-000003                                                          1-goREK1QUKlQPAIVkWVaQ   3 1       226719            0        295            147
      green  open   .security                                                             zeT65uOuRTKZMjg_bbUc1g   1 1            5            0          0              0
      green  open   .kibana-377444158_kubeadmin                                           wvMhDwJkR-mRZQO84K0gUQ   3 1            1            0          0              0
      green  open   infra-000006                                                          5H-KBSXGQKiO7hdapDE23g   3 1       226676            0        295            147
      green  open   infra-000001                                                          eH53BQ-bSxSWR5xYZB6lVg   3 1       341800            0        443            220
      green  open   .kibana-6                                                             RVp7TemSSemGJcsSUmuf3A   1 1            4            0          0              0
      green  open   infra-000011                                                          J7XWBauWSTe0jnzX02fU6A   3 1       226100            0        293            146
      green  open   app-000001                                                            axSAFfONQDmKwatkjPXdtw   3 1       103186            0        126             57
      green  open   infra-000016                                                          m9c1iRLtStWSF1GopaRyCg   3 1        13685            0         19              9
      green  open   infra-000002                                                          Hz6WvINtTvKcQzw-ewmbYg   3 1       228994            0        296            148
      green  open   infra-000013                                                          KR9mMFUpQl-jraYtanyIGw   3 1       228166            0        298            148
      green  open   audit-000001                                                          eERqLdLmQOiQDFES1LBATQ   3 1            0            0          0              0

   5. 로그 수집기가 5.x로 업데이트되었는지 확인합니다.

      $ oc get ds fluentd -o json | grep fluentd-init

      출력에 fluentd-init 컨테이너가 포함되어 있는지 확인합니다.

      "containerName": "fluentd-init"

   6. 로그 시각화 프로그램이 Kibana CRD를 사용하여 5.x로 업데이트되었는지 확인합니다.

      $ oc get kibana kibana -o json

      출력에 ready 상태가 있는 Kibana pod가 포함되어 있는지 확인합니다.

      예 10.4. Kibana Pod가 준비된 샘플 출력

      [
      {
      "clusterCondition": {
      "kibana-5fdd766ffd-nb2jj": [
      {
      "lastTransitionTime": "2020-06-30T14:11:07Z",
      "reason": "ContainerCreating",
      "status": "True",
      "type": ""
      },
      {
      "lastTransitionTime": "2020-06-30T14:11:07Z",
      "reason": "ContainerCreating",
      "status": "True",
      "type": ""
      }
      ]
      },
      "deployment": "kibana",
      "pods": {
      "failed": [],
      "notReady": []
      "ready": []
      },
      "replicaSets": [
      "kibana-5fdd766ffd"
      ],
      "replicas": 1
      }
      ]

1. OpenShift Container Platform 웹 콘솔에서 모니터링 → 대시보드를 클릭합니다.

2. 대시보드 페이지의 대시보드 메뉴에서 로깅/Elasticsearch 노드 또는 OpenShift 로깅 을 선택합니다.

   로깅/Elasticsearch 노드 대시보드의 경우 보려는 Elasticsearch 노드를 선택하고 데이터 해상도를 설정할 수 있습니다.

   여러 데이터 차트를 보여주는 적절한 대시보드가 표시됩니다.

3. 선택적으로 시간 범위 및 새로 고침 간격 메뉴에서 데이터를 표시하거나 새로 고칠 다른 시간 범위를 선택합니다.