1. must-gather 정보를 저장하려는 디렉터리로 이동합니다.

2. 로깅 이미지에 대해 oc adm must-gather 명령을 실행합니다.

   $ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}')

   must-gather 툴에서 현재 디렉터리 내에 must-gather.local로 시작하는 새 디렉터리를 만듭니다. 예: must-gather.local.4157245944708210408.

3. 방금 생성한 must-gather 디렉터리에서 압축 파일을 만듭니다. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다.

   $ tar -cvaf must-gather.tar.gz must-gather.local.4157245944708210408

4. Red Hat Customer Portal에서 해당 지원 사례에 압축 파일을 첨부합니다.

절차

1. 다음 명령을 실행하여 openshift-logging 프로젝트로 변경합니다.

   $ oc project openshift-logging

2. 다음 명령을 실행하여 ClusterLogging 인스턴스 상태를 가져옵니다.

   $ oc get clusterlogging instance -o yaml

   출력 예

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   # ...
   status:  1
     collection:
       logs:
         fluentdStatus:
           daemonSet: fluentd  2
           nodes:
             collector-2rhqp: ip-10-0-169-13.ec2.internal
             collector-6fgjh: ip-10-0-165-244.ec2.internal
             collector-6l2ff: ip-10-0-128-218.ec2.internal
             collector-54nx5: ip-10-0-139-30.ec2.internal
             collector-flpnn: ip-10-0-147-228.ec2.internal
             collector-n2frh: ip-10-0-157-45.ec2.internal
           pods:
             failed: []
             notReady: []
             ready:
             - collector-2rhqp
             - collector-54nx5
             - collector-6fgjh
             - collector-6l2ff
             - collector-flpnn
             - collector-n2frh
     logstore: 3
       elasticsearchStatus:
       - ShardAllocationEnabled:  all
         cluster:
           activePrimaryShards:    5
           activeShards:           5
           initializingShards:     0
           numDataNodes:           1
           numNodes:               1
           pendingTasks:           0
           relocatingShards:       0
           status:                 green
           unassignedShards:       0
         clusterName:             elasticsearch
         nodeConditions:
           elasticsearch-cdm-mkkdys93-1:
         nodeCount:  1
         pods:
           client:
             failed:
             notReady:
             ready:
             - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c
           data:
             failed:
             notReady:
             ready:
             - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c
           master:
             failed:
             notReady:
             ready:
             - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c
   visualization:  4
       kibanaStatus:
       - deployment: kibana
         pods:
           failed: []
           notReady: []
           ready:
           - kibana-7fb4fd4cc9-f2nls
         replicaSets:
         - kibana-7fb4fd4cc9
         replicas: 1

   1

   출력에서 클러스터 상태 필드가 상태 스탠자에 나타납니다.

   2

   Fluentd Pod에 대한 정보.

   3

   Elasticsearch 클러스터 건강, 녹색, 노란색 또는 빨간색을 포함한 Elasticsearch Pod에 대한 정보입니다.

   4

   Kibana Pod에 대한 정보.

절차

1. openshift-logging 프로젝트로 변경합니다.

   $ oc project openshift-logging

2. 로깅 환경의 상태 보기:

   $ oc describe deployment cluster-logging-operator

   출력 예

   Name:                   cluster-logging-operator
   
   ....
   
   Conditions:
     Type           Status  Reason
     ----           ------  ------
     Available      True    MinimumReplicasAvailable
     Progressing    True    NewReplicaSetAvailable
   
   ....
   
   Events:
     Type    Reason             Age   From                   Message
     ----    ------             ----  ----                   -------
     Normal  ScalingReplicaSet  62m   deployment-controller  Scaled up replica set cluster-logging-operator-574b8987df to 1----

3. 로깅 복제본 세트의 상태를 확인합니다.

   1. 복제본 세트의 이름을 가져옵니다.

      출력 예

      $ oc get replicaset

      출력 예

      NAME                                      DESIRED   CURRENT   READY   AGE
      cluster-logging-operator-574b8987df       1         1         1       159m
      elasticsearch-cdm-uhr537yu-1-6869694fb    1         1         1       157m
      elasticsearch-cdm-uhr537yu-2-857b6d676f   1         1         1       156m
      elasticsearch-cdm-uhr537yu-3-5b6fdd8cfd   1         1         1       155m
      kibana-5bd5544f87                         1         1         1       157m

   2. 복제본 세트의 상태를 가져옵니다.

      $ oc describe replicaset cluster-logging-operator-574b8987df

      출력 예

      Name:           cluster-logging-operator-574b8987df
      
      ....
      
      Replicas:       1 current / 1 desired
      Pods Status:    1 Running / 0 Waiting / 0 Succeeded / 0 Failed
      
      ....
      
      Events:
        Type    Reason            Age   From                   Message
        ----    ------            ----  ----                   -------
        Normal  SuccessfulCreate  66m   replicaset-controller  Created pod: cluster-logging-operator-574b8987df-qjhqv----

절차

1. Elasticsearch 클러스터 상태를 확인하고 다음 명령을 실행하여 클러스터 상태가 빨간색인지 확인합니다.

   $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- health

2. 다음 명령을 실행하여 클러스터에 참여한 노드를 나열합니다.

   $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
     -- es_util --query=_cat/nodes?v

3. 다음 명령을 실행하여 Elasticsearch Pod를 나열하고 이전 단계의 명령 출력의 노드와 비교합니다.

   $ oc -n openshift-logging get pods -l component=elasticsearch

4. 일부 Elasticsearch 노드가 클러스터에 참여하지 않은 경우 다음 단계를 수행합니다.

   1. 다음 명령을 실행하고 출력을 관찰하여 Elasticsearch에 선택한 마스터 노드가 있는지 확인합니다.

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=_cat/master?v

   2. 다음 명령을 실행하고 출력을 관찰하여 선택한 마스터 노드의 Pod 로그를 검토합니다.

      $ oc logs <elasticsearch_master_pod_name> -c elasticsearch -n openshift-logging

   3. 다음 명령을 실행하고 출력을 관찰하여 클러스터에 참여하지 않은 노드의 로그를 확인합니다.

      $ oc logs <elasticsearch_node_name> -c elasticsearch -n openshift-logging

5. 모든 노드가 클러스터에 참여한 경우 다음 명령을 실행하고 출력을 관찰하여 클러스터가 복구 프로세스 중인지 확인합니다.

   $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
     -- es_util --query=_cat/recovery?active_only=true

   명령 출력이 없는 경우 복구 프로세스가 보류 중인 작업에서 지연되거나 중단될 수 있습니다.

6. 다음 명령을 실행하고 출력을 관찰하여 보류 중인 작업이 있는지 확인합니다.

   $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
     -- health | grep number_of_pending_tasks

7. 보류 중인 작업이 있는 경우 상태를 모니터링합니다. 상태가 변경되고 클러스터가 복구 중임을 나타내는 경우 계속 대기합니다. 복구 시간은 클러스터의 크기와 기타 요인에 따라 다릅니다. 그렇지 않으면 보류 중인 작업의 상태가 변경되지 않는 경우 복구가 중지되었음을 나타냅니다.

8. 복구가 중단된 것처럼 보이면 다음 명령을 실행하고 출력을 관찰하여 cluster.routing.allocation.enable 값이 none 으로 설정되어 있는지 확인합니다.

   $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
     -- es_util --query=_cluster/settings?pretty

9. cluster.routing.allocation.enable 값이 none 으로 설정된 경우 다음 명령을 실행하여 all 로 설정합니다.

   $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
     -- es_util --query=_cluster/settings?pretty \
     -X PUT -d '{"persistent": {"cluster.routing.allocation.enable":"all"}}'

10. 다음 명령을 실행하고 출력을 관찰하여 인덱스가 빨간색인지 확인합니다.

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
      -- es_util --query=_cat/indices?v

11. 인덱스가 빨간색이면 다음 단계를 수행하여 지웁니다.

    1. 다음 명령을 실행하여 캐시를 지웁니다.

       $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
         -- es_util --query=<elasticsearch_index_name>/_cache/clear?pretty

    2. 다음 명령을 실행하여 최대 할당 재시도 횟수를 늘립니다.

       $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
         -- es_util --query=<elasticsearch_index_name>/_settings?pretty \
         -X PUT -d '{"index.allocation.max_retries":10}'

    3. 다음 명령을 실행하여 스크롤 항목을 모두 삭제합니다.

       $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
         -- es_util --query=_search/scroll/_all -X DELETE

    4. 다음 명령을 실행하여 시간 초과를 늘립니다.

       $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
         -- es_util --query=<elasticsearch_index_name>/_settings?pretty \
         -X PUT -d '{"index.unassigned.node_left.delayed_timeout":"10m"}'

12. 이전 단계에서 빨간색 인덱스를 지우지 않으면 인덱스를 개별적으로 삭제합니다.

    1. 다음 명령을 실행하여 빨간색 인덱스 이름을 확인합니다.

       $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
         -- es_util --query=_cat/indices?v

    2. 다음 명령을 실행하여 빨간색 인덱스를 삭제합니다.

       $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
         -- es_util --query=<elasticsearch_red_index_name> -X DELETE

13. 빨간색 인덱스가 없고 클러스터 상태가 빨간색이면 데이터 노드에서 지속적으로 처리 로드가 높은지 확인합니다.

    1. 다음 명령을 실행하여 Elasticsearch JVM 힙 사용량이 높은지 확인합니다.

       $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
         -- es_util --query=_nodes/stats?pretty

       명령 출력에서 node_name.jvm.mem.heap_used_percent 필드를 검토하여 JVM 힙 사용량을 확인합니다.

    2. CPU 사용률이 높은지 확인합니다. CPU 활용에 대한 자세한 내용은 Red Hat OpenShift Service on AWS " monitoring dashboards" 설명서를 참조하십시오.

절차

1. 다음 명령을 실행하여 Elasticsearch가 배포된 노드를 식별합니다.

   $ oc -n openshift-logging get po -o wide

2. 다음 명령을 실행하여 할당되지 않은 shard가 있는지 확인합니다.

   $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
     -- es_util --query=_cluster/health?pretty | grep unassigned_shards

3. 할당되지 않은 shard가 있는 경우 다음 명령을 실행하여 각 노드에서 디스크 공간을 확인합니다.

   $ for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; \
     do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod \
     -- df -h /elasticsearch/persistent; done

4. 명령 출력에서 Use 열을 확인하여 해당 노드에서 사용된 디스크 백분율을 확인합니다.

   출력 예

   elasticsearch-cdm-kcrsda6l-1-586cc95d4f-h8zq8
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/nvme1n1     19G  522M   19G   3% /elasticsearch/persistent
   elasticsearch-cdm-kcrsda6l-2-5b548fc7b-cwwk7
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/nvme2n1     19G  522M   19G   3% /elasticsearch/persistent
   elasticsearch-cdm-kcrsda6l-3-5dfc884d99-59tjw
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/nvme3n1     19G  528M   19G   3% /elasticsearch/persistent

   사용된 디스크 백분율이 85%를 초과하는 경우 노드가 낮은 워터마크를 초과하여 더 이상 이 노드에 shard를 할당할 수 없습니다.

5. 현재 redundancyPolicy 를 확인하려면 다음 명령을 실행합니다.

   $ oc -n openshift-logging get es elasticsearch \
     -o jsonpath='{.spec.redundancyPolicy}'

   클러스터에서 ClusterLogging 리소스를 사용하는 경우 다음 명령을 실행합니다.

   $ oc -n openshift-logging get cl \
     -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'

   클러스터 redundancyPolicy 값이 SingleRedundancy 값보다 크면 SingleRedundancy 값으로 설정하고 이 변경 사항을 저장합니다.

6. 이전 단계에서 문제가 해결되지 않으면 이전 인덱스를 삭제합니다.

   1. 다음 명령을 실행하여 Elasticsearch의 모든 인덱스의 상태를 확인합니다.

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- indices

   2. 삭제할 수 있는 이전 인덱스를 확인합니다.

   3. 다음 명령을 실행하여 인덱스를 삭제합니다.

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=<elasticsearch_index_name> -X DELETE

프로세스

1. 다음 명령을 실행하여 Elasticsearch가 배포된 노드를 식별합니다.

   $ oc -n openshift-logging get po -o wide

2. 각 노드의 디스크 공간을 확인합니다.

   $ for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; \
     do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod \
     -- df -h /elasticsearch/persistent; done

3. 클러스터가 재조정 중인지 확인합니다.

   $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
     -- es_util --query=_cluster/health?pretty | grep relocating_shards

   명령 출력에 shard 재배치가 표시되면 높은 워터마크가 초과되었습니다. 높은 워터마크의 기본값은 90%입니다.

4. 모든 노드의 디스크 공간을 늘립니다. 디스크 공간을 늘릴 수 없는 경우 클러스터에 새 데이터 노드를 추가하거나 총 클러스터 중복 정책을 줄입니다.

5. 현재 redundancyPolicy 를 확인하려면 다음 명령을 실행합니다.

   $ oc -n openshift-logging get es elasticsearch \
     -o jsonpath='{.spec.redundancyPolicy}'

   클러스터에서 ClusterLogging 리소스를 사용하는 경우 다음 명령을 실행합니다.

   $ oc -n openshift-logging get cl \
     -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'

   클러스터 redundancyPolicy 값이 SingleRedundancy 값보다 크면 SingleRedundancy 값으로 설정하고 이 변경 사항을 저장합니다.

6. 이전 단계에서 문제가 해결되지 않으면 이전 인덱스를 삭제합니다.

   1. 다음 명령을 실행하여 Elasticsearch의 모든 인덱스의 상태를 확인합니다.

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- indices

   2. 삭제할 수 있는 이전 인덱스를 확인합니다.

   3. 다음 명령을 실행하여 인덱스를 삭제합니다.

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=<elasticsearch_index_name> -X DELETE

프로세스

1. Elasticsearch 노드의 디스크 공간을 가져옵니다.

   $ for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; \
     do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod \
     -- df -h /elasticsearch/persistent; done

2. 명령 출력에서 Avail 열을 확인하여 해당 노드에서 사용 가능한 디스크 공간을 확인합니다.

   출력 예

   elasticsearch-cdm-kcrsda6l-1-586cc95d4f-h8zq8
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/nvme1n1     19G  522M   19G   3% /elasticsearch/persistent
   elasticsearch-cdm-kcrsda6l-2-5b548fc7b-cwwk7
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/nvme2n1     19G  522M   19G   3% /elasticsearch/persistent
   elasticsearch-cdm-kcrsda6l-3-5dfc884d99-59tjw
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/nvme3n1     19G  528M   19G   3% /elasticsearch/persistent

3. 모든 노드의 디스크 공간을 늘립니다. 디스크 공간을 늘릴 수 없는 경우 클러스터에 새 데이터 노드를 추가하거나 총 클러스터 중복 정책을 줄입니다.

4. 현재 redundancyPolicy 를 확인하려면 다음 명령을 실행합니다.

   $ oc -n openshift-logging get es elasticsearch \
     -o jsonpath='{.spec.redundancyPolicy}'

   클러스터에서 ClusterLogging 리소스를 사용하는 경우 다음 명령을 실행합니다.

   $ oc -n openshift-logging get cl \
     -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'

   클러스터 redundancyPolicy 값이 SingleRedundancy 값보다 크면 SingleRedundancy 값으로 설정하고 이 변경 사항을 저장합니다.

5. 이전 단계에서 문제가 해결되지 않으면 이전 인덱스를 삭제합니다.

   1. 다음 명령을 실행하여 Elasticsearch의 모든 인덱스의 상태를 확인합니다.

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- indices

   2. 삭제할 수 있는 이전 인덱스를 확인합니다.

   3. 다음 명령을 실행하여 인덱스를 삭제합니다.

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=<elasticsearch_index_name> -X DELETE

6. 디스크 공간을 계속 확보하고 모니터링합니다. 사용된 디스크 공간이 90% 미만으로 떨어지면 다음 명령을 실행하여 이 노드에 쓰기 차단을 해제합니다.

   $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
     -- es_util --query=_all/_settings?pretty \
     -X PUT -d '{"index.blocks.read_only_allow_delete": null}'

프로세스

1. Elasticsearch 노드의 디스크 공간을 가져옵니다.

   $ for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; \
     do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod \
     -- df -h /elasticsearch/persistent; done

2. 명령 출력에서 Avail 열을 확인하여 해당 노드에서 사용 가능한 디스크 공간을 확인합니다.

   출력 예

   elasticsearch-cdm-kcrsda6l-1-586cc95d4f-h8zq8
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/nvme1n1     19G  522M   19G   3% /elasticsearch/persistent
   elasticsearch-cdm-kcrsda6l-2-5b548fc7b-cwwk7
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/nvme2n1     19G  522M   19G   3% /elasticsearch/persistent
   elasticsearch-cdm-kcrsda6l-3-5dfc884d99-59tjw
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/nvme3n1     19G  528M   19G   3% /elasticsearch/persistent

3. 모든 노드의 디스크 공간을 늘립니다. 디스크 공간을 늘릴 수 없는 경우 클러스터에 새 데이터 노드를 추가하거나 총 클러스터 중복 정책을 줄입니다.

4. 현재 redundancyPolicy 를 확인하려면 다음 명령을 실행합니다.

   $ oc -n openshift-logging get es elasticsearch -o jsonpath='{.spec.redundancyPolicy}'

   클러스터에서 ClusterLogging 리소스를 사용하는 경우 다음 명령을 실행합니다.

   $ oc -n openshift-logging get cl \
     -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'

   클러스터 redundancyPolicy 값이 SingleRedundancy 값보다 크면 SingleRedundancy 값으로 설정하고 이 변경 사항을 저장합니다.

5. 이전 단계에서 문제가 해결되지 않으면 이전 인덱스를 삭제합니다.

   1. 다음 명령을 실행하여 Elasticsearch의 모든 인덱스의 상태를 확인합니다.

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- indices

   2. 삭제할 수 있는 이전 인덱스를 확인합니다.

   3. 다음 명령을 실행하여 인덱스를 삭제합니다.

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=<elasticsearch_index_name> -X DELETE

절차

1. 다음 명령을 실행하여 openshift-logging 프로젝트로 변경합니다.

   $ oc project openshift-logging

2. 상태를 보려면 다음을 수행합니다.

   1. 다음 명령을 실행하여 Elasticsearch 로그 저장소 인스턴스의 이름을 가져옵니다.

      $ oc get Elasticsearch

      출력 예

      NAME            AGE
      elasticsearch   5h9m

   2. 다음 명령을 실행하여 Elasticsearch 로그 저장소 상태를 가져옵니다.

      $ oc get Elasticsearch <Elasticsearch-instance> -o yaml

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

      $ oc get Elasticsearch elasticsearch -n openshift-logging -o yaml

      출력에는 다음과 유사한 정보가 포함됩니다.

      출력 예

      status: 1
        cluster: 2
          activePrimaryShards: 30
          activeShards: 60
          initializingShards: 0
          numDataNodes: 3
          numNodes: 3
          pendingTasks: 0
          relocatingShards: 0
          status: green
          unassignedShards: 0
        clusterHealth: ""
        conditions: [] 3
        nodes: 4
        - deploymentName: elasticsearch-cdm-zjf34ved-1
          upgradeStatus: {}
        - deploymentName: elasticsearch-cdm-zjf34ved-2
          upgradeStatus: {}
        - deploymentName: elasticsearch-cdm-zjf34ved-3
          upgradeStatus: {}
        pods: 5
          client:
            failed: []
            notReady: []
            ready:
            - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
            - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
            - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
          data:
            failed: []
            notReady: []
            ready:
            - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
            - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
            - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
          master:
            failed: []
            notReady: []
            ready:
            - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
            - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
            - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
        shardAllocationEnabled: all

      1

      출력에서 클러스터 상태 필드가 상태 스탠자에 나타납니다.

      2

      Elasticsearch 로그 저장소의 상태:

      • 활성 기본 shard 수입니다.
      • 활성 shard 수입니다.
      • 초기화 중인 shard 수입니다.
      • Elasticsearch 로그 저장소 데이터 노드의 수입니다.
      • 총 Elasticsearch 로그 저장소 노드 수입니다.
      • 보류 중인 작업 수입니다.
      • Elasticsearch 로그 저장소 상태: green,red,yellow.
      • 할당되지 않은 shard 수

      3

      존재하는 경우 모든 상태 조건. Elasticsearch 로그 저장소 상태는 Pod를 배치할 수 없는 경우 스케줄러의 이유를 나타냅니다. 다음 조건과 관련된 모든 이벤트가 표시됩니다.

      • 컨테이너는 Elasticsearch 로그 저장소 및 프록시 컨테이너를 모두 대기합니다.
      • 컨테이너는 Elasticsearch 로그 저장소 및 프록시 컨테이너 모두에 대해 종료되었습니다.
      • Pod 예약 불가. 또한 여러 가지 문제에 대한 조건이 표시됩니다(조건 메시지 예 참조).

      4

      upgradeStatus 가 있는 클러스터의 Elasticsearch 로그 저장소 노드

      5

      실패한,notReady 또는 ready 상태에 나열된 클러스터의 Elasticsearch 로그 저장소 클라이언트, 데이터 및 마스터 Pod

프로세스

1. ClusterLogging CR logStore 사양을 수정합니다.

   ClusterLogging CR 예

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   metadata:
   # ...
   spec:
   # ...
     logStore:
       type: <log_store_type> 1
       elasticsearch: 2
         nodeCount: <integer>
         resources: {}
         storage: {}
         redundancyPolicy: <redundancy_type> 3
       lokistack: 4
         name: {}
   # ...

   1

   로그 저장소 유형을 지정합니다. lokistack 또는 elasticsearch 일 수 있습니다.

   2

   Elasticsearch 로그 저장소에 대한 선택적 구성 옵션입니다.

   3

   중복 유형을 지정합니다. 이 값은 ZeroRedundancy,SingleRedundancy,MultipleRedundancy 또는 FullRedundancy 일 수 있습니다.

   4

   LokiStack에 대한 선택적 구성 옵션입니다.

   LokiStack을 로그 저장소로 지정하는 ClusterLogging CR의 예

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   metadata:
     name: instance
     namespace: openshift-logging
   spec:
     managementState: Managed
     logStore:
       type: lokistack
       lokistack:
         name: logging-loki
   # ...

2. 다음 명령을 실행하여 ClusterLogging CR을 적용합니다.

   $ oc apply -f <filename>.yaml

프로세스

1. ClusterLogging CR 컬렉션 사양을 수정합니다.

   ClusterLogging CR 예

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   metadata:
   # ...
   spec:
   # ...
     collection:
       type: <log_collector_type> 1
       resources: {}
       tolerations: {}
   # ...

   1

   로깅에 사용할 로그 수집기 유형입니다. 벡터 또는 fluentd 일 수 있습니다.

2. 다음 명령을 실행하여 ClusterLogging CR을 적용합니다.

   $ oc apply -f <filename>.yaml

프로세스

1. ClusterLogging CR 시각화 사양을 수정합니다.

   ClusterLogging CR 예

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   metadata:
   # ...
   spec:
   # ...
     visualization:
       type: <visualizer_type> 1
       kibana: 2
         resources: {}
         nodeSelector: {}
         proxy: {}
         replicas: {}
         tolerations: {}
       ocpConsole: 3
         logsLimit: {}
         timeout: {}
   # ...

   1

   로깅에 사용할 시각화 프로그램 유형입니다. kibana 또는 ocp-console 일 수 있습니다. Kibana 콘솔은 Elasticsearch 로그 스토리지를 사용하는 배포와만 호환되지만 AWS 콘솔의 Red Hat OpenShift Service는 LokiStack 배포와만 호환됩니다.

   2

   Kibana 콘솔의 선택적 구성입니다.

   3

   AWS 웹 콘솔에서 Red Hat OpenShift Service에 대한 선택적 구성입니다.

2. 다음 명령을 실행하여 ClusterLogging CR을 적용합니다.

   $ oc apply -f <filename>.yaml

절차

1. ClusterLogging CR 시각화 사양을 수정합니다.

   ClusterLogging CR 예

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   metadata:
   # ...
   spec:
   # ...
     visualization:
       type: <visualizer_type> 1
       kibana: 2
         resources: {}
         nodeSelector: {}
         proxy: {}
         replicas: {}
         tolerations: {}
       ocpConsole: 3
         logsLimit: {}
         timeout: {}
   # ...

   1

   로깅에 사용할 시각화 프로그램 유형입니다. kibana 또는 ocp-console 일 수 있습니다. Kibana 콘솔은 Elasticsearch 로그 스토리지를 사용하는 배포와만 호환되지만 AWS 콘솔의 Red Hat OpenShift Service는 LokiStack 배포와만 호환됩니다.

   2

   Kibana 콘솔의 선택적 구성입니다.

   3

   AWS 웹 콘솔에서 Red Hat OpenShift Service에 대한 선택적 구성입니다.

2. 다음 명령을 실행하여 ClusterLogging CR을 적용합니다.

   $ oc apply -f <filename>.yaml

절차

1. AWS 웹 콘솔의 Red Hat OpenShift Service 관리자 화면에서 Operator → 설치된 Operator 로 이동합니다.
2. Red Hat OpenShift Logging 을 클릭합니다. 그러면 Operator 세부 정보 페이지로 이동합니다.
3. 세부 정보 페이지에서 Console 플러그인 옵션에 대해 Disabled 를 클릭합니다.
4. 콘솔 플러그인 활성화 대화 상자에서 Enable 을 선택합니다.
5. 저장을 클릭합니다.
6. Console 플러그인 옵션에 Enabled 가 표시되는지 확인합니다.
7. 변경 사항이 적용되면 웹 콘솔에 팝업 창이 표시됩니다. 웹 콘솔을 다시 로드하라는 창이 표시됩니다. 팝업 창이 표시되면 브라우저를 새로 고침하여 변경 사항을 적용합니다.

절차

1. 다음 명령을 실행하여 로깅 콘솔 플러그인이 활성화되어 있는지 확인합니다.

   $ oc get consoles.operator.openshift.io cluster -o yaml |grep logging-view-plugin  \
   || oc patch consoles.operator.openshift.io cluster  --type=merge \
   --patch '{ "spec": { "plugins": ["logging-view-plugin"]}}'

2. 다음 명령을 실행하여 ClusterLogging CR에 .metadata.annotations.logging.openshift.io/ocp-console-migration-target: lokistack-dev 주석을 추가합니다.

   $ oc patch clusterlogging instance --type=merge --patch \
   '{ "metadata": { "annotations": { "logging.openshift.io/ocp-console-migration-target": "lokistack-dev" }}}' \
   -n openshift-logging

   출력 예

   clusterlogging.logging.openshift.io/instance patched

1. AWS Red Hat Hybrid Cloud Console의 Red Hat OpenShift Service에서 모니터링 → 대시보드 를 클릭합니다.

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

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

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

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

1. AWS 콘솔의 Red Hat OpenShift Service에서 애플리케이션 시작 프로그램 을 클릭하고 로깅 을 선택합니다.

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

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

1. AWS 콘솔의 Red Hat OpenShift Service에서 애플리케이션 시작 프로그램 을 클릭하고 로깅 을 선택합니다.

2. 사용하는 것과 동일한 자격 증명을 사용하여 AWS 콘솔의 Red Hat OpenShift Service에 로그인합니다.

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

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

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

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

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

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

   예 7.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. openshift-logging 프로젝트에서 ClusterLogging 사용자 정의 리소스(CR)를 편집합니다.

   $ oc -n openshift-logging edit ClusterLogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
     namespace: openshift-logging
   
   ...
   
   spec:
     managementState: "Managed"
     logStore:
       type: "elasticsearch"
       elasticsearch:
         nodeCount: 3
         resources: 1
           limits:
             memory: 16Gi
           requests:
             cpu: 200m
             memory: 16Gi
         storage:
           storageClassName: "gp2"
           size: "200G"
         redundancyPolicy: "SingleRedundancy"
     visualization:
       type: "kibana"
       kibana:
         resources: 2
           limits:
             memory: 1Gi
           requests:
             cpu: 500m
             memory: 1Gi
         proxy:
           resources: 3
             limits:
               memory: 100Mi
             requests:
               cpu: 100m
               memory: 100Mi
         replicas: 2
     collection:
       logs:
         type: "fluentd"
         fluentd:
           resources: 4
             limits:
               memory: 736Mi
             requests:
               cpu: 200m
               memory: 736Mi

   1

   필요에 따라 로그 저장소에 대한 CPU 및 메모리 제한 및 요청을 지정합니다. Elasticsearch의 경우 요청 값과 제한 값을 모두 조정해야 합니다.

   2 3

   필요에 따라 로그 시각화 프로그램에 대한 CPU 및 메모리 제한 및 요청을 지정합니다.

   4

   필요에 따라 로그 수집기에 대한 CPU 및 메모리 제한 및 요청을 지정합니다.

1. Fluentd는 로깅 버전 5.6.2에서 Elasticsearch 8을 지원하지 않습니다.
2. 벡터는 로깅 버전 5.7 이상에서 Syslog를 지원합니다.

절차

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

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

2. structuredTypeKey 필드를 사용하여 로그 레코드 필드 중 하나를 지정합니다.

3. structuredTypeName 필드를 사용하여 이름을 지정합니다.

   중요

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

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

프로세스

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

   주석 이름이 컨테이너 이름과 일치해야 함

절차

1. Base64로 인코딩된 Splunk HEC 토큰을 사용하여 시크릿을 생성합니다.

   $ oc -n openshift-logging create secret generic vector-splunk-secret --from-literal hecToken=<HEC_Token>

2. 아래 템플릿을 사용하여 ClusterLogForwarder 사용자 정의 리소스(CR)를 생성하거나 편집합니다.

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 1
     namespace: <log_forwarder_namespace> 2
   spec:
     serviceAccountName: <service_account_name> 3
     outputs:
       - name: splunk-receiver 4
         secret:
           name: vector-splunk-secret 5
         type: splunk 6
         url: <http://your.splunk.hec.url:8088> 7
     pipelines: 8
       - inputRefs:
           - application
           - infrastructure
         name: 9
         outputRefs:
           - splunk-receiver 10

   1

   레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.

   2

   레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.

   3

   서비스 계정의 이름입니다. 서비스 계정은 로그 전달자가 openshift-logging 네임스페이스에 배포되지 않은 경우에만 다중 로그 전달자 구현에 필요합니다.

   4

   출력 이름을 지정합니다.

   5

   HEC 토큰이 포함된 시크릿의 이름을 지정합니다.

   6

   출력 유형을 splunk 로 지정합니다.

   7

   Splunk HEC의 URL(포트 포함)을 지정합니다.

   8

   파이프라인을 사용하여 전달할 로그 유형을 지정합니다( 애플리케이션,인프라 또는 감사 ).

   9

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

   10

   이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.

절차

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

   ClusterLogForwarder CR의 예

   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 8
     pipelines:
      - name: forward-to-fluentd-insecure 9
        inputRefs: 10
        - my-app-logs
        outputRefs: 11
        - fluentd-server-insecure
        labels:
          project: "my-project" 12
      - name: forward-to-fluentd-secure 13
        inputRefs:
        - application 14
        - 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

   네임스페이스를 지정하지 않으면 모든 네임스페이스에서 로그가 수집됩니다.

   9

   파이프라인 구성은 이름이 지정된 입력의 로그를 이름이 지정된 출력으로 보냅니다. 이 예에서 forward-to-fluentd-insecure 라는 파이프라인은 my-app-logs 라는 입력에서 fluentd-server-insecure 라는 출력으로 로그를 전달합니다.

   10

   입력 목록입니다.

   11

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

   12

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

   13

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

   • 선택사항: 파이프라인의 이름을 지정합니다.
   • 파이프라인을 사용하여 전달할 로그 유형 (application, infrastructure, 또는 audit)을 지정합니다.
   • 이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.
   • 선택 사항: default 출력을 지정하여 로그를 기본 로그 저장소로 전달합니다.
   • 선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.

   14

   이 구성을 사용할 때 모든 네임스페이스의 애플리케이션 로그가 수집됩니다.

2. 다음 명령을 실행하여 ClusterLogForwarder CR을 적용합니다.

   $ oc apply -f <filename>.yaml

절차

1. ClusterLogForwarder CR 오브젝트를 정의하는 YAML 파일을 생성하거나 편집합니다. 파일에서 다음 예와 같이 inputs[].name.application.selector.matchLabels에서 간단한 동일성 기반 선택기를 사용하여 Pod 레이블을 지정합니다.

   ClusterLogForwarder CR YAML 파일의 예

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

   1

   레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.

   2

   레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.

   3

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

   4

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

   5

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

   6

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

   7

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

   8

   로그 데이터를 전달할 출력을 하나 이상 지정합니다.

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

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

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

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

      - inputRefs: [ myAppLogData, myOtherAppLogData ]

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

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

절차

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

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 1
     namespace: <log_forwarder_namespace> 2
   spec:
     serviceAccountName: <service_account_name> 3
     outputs:
     - name: loki-insecure 4
       type: "loki" 5
       url: http://loki.insecure.com:3100 6
       loki:
         tenantKey: kubernetes.namespace_name
         labelKeys:
         - kubernetes.labels.foo
     - name: loki-secure 7
       type: "loki"
       url: https://loki.secure.com:3100
       secret:
         name: loki-secret 8
       loki:
         tenantKey: kubernetes.namespace_name 9
         labelKeys:
         - kubernetes.labels.foo 10
     pipelines:
     - name: application-logs 11
       inputRefs:  12
       - application
       - audit
       outputRefs: 13
       - loki-secure

   1

   레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.

   2

   레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.

   3

   서비스 계정의 이름입니다. 서비스 계정은 로그 전달자가 openshift-logging 네임스페이스에 배포되지 않은 경우에만 다중 로그 전달자 구현에 필요합니다.

   4

   출력 이름을 지정합니다.

   5

   유형을 "loki"로 지정합니다.

   6

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

   7

   보안 연결의 경우 secret을 지정하여 인증하는 https 또는 http URL을 지정할 수 있습니다.

   8

   https 접두사의 경우 TLS 통신의 엔드포인트에 필요한 보안 이름을 지정합니다. 시크릿에는 나타내는 인증서를 가리키는 ca-bundle.crt 키가 포함되어야 합니다. 그러지 않으면 http 및 https 접두사의 경우 사용자 이름과 암호가 포함된 시크릿을 지정할 수 있습니다. 레거시 구현에서는 openshift-logging 프로젝트에 시크릿이 있어야 합니다. 자세한 내용은 다음 "사용자 이름 및 암호가 포함된 시크릿 설정 예"를 참조하십시오.

   9

   선택 사항: metadata 키 필드를 지정하여 Loki의 TenantID 필드 값을 생성합니다. 예를 들어 tenantKey: kubernetes.namespace_name을 설정하면 Kubernetes 네임스페이스의 이름이 Loki의 테넌트 ID 값으로 사용됩니다. 지정할 수 있는 다른 로그 레코드 필드를 보려면 다음 "추가 리소스" 섹션의 "로그 레코드 필드" 링크를 참조하십시오.

   10

   선택 사항: 메타데이터 필드 키 목록을 지정하여 기본 Loki 레이블을 교체합니다. Loki 레이블 이름은 정규식 [a-zA-Z_:][a-zA-Z0-9_:]*와 일치해야 합니다. 메타데이터 키의 잘못된 문자는 레이블 이름을 형성하기 위해 _ 로 교체됩니다. 예를 들어 kubernetes.labels.foo 메타데이터 키는 Loki 레이블 kubernetes_labels_foo 가 됩니다. labelKeys를 설정하지 않으면 기본값은 [log_type, kubernetes.namespace_name, kubernetes.pod_name, kubernetes_host] 입니다. Loki는 허용되는 레이블의 크기와 수를 제한하므로 레이블 세트를 작게 유지합니다. Configuring Loki, limits_config를 참조하십시오. 쿼리 필터를 사용하여 로그 레코드 필드를 기반으로 쿼리할 수 있습니다.

   11

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

   12

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

   13

   이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.

   참고

   Loki는 타임스탬프에 의해 로그 스트림을 올바르게 정렬해야 하므로 labelKeys에는 항상 kubernetes_host 레이블 세트가 포함됩니다. 이렇게 하면 각 스트림이 단일 호스트에서 시작되도록 하여 서로 다른 호스트의 클록 차이로 인해 타임스탬프가 무질서해지는 것을 방지할 수 있습니다.

2. 다음 명령을 실행하여 ClusterLogForwarder CR 오브젝트를 적용합니다.

   $ oc apply -f <filename>.yaml

절차

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

   ClusterLogForwarder CR의 예

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: <log_forwarder_name> 1
     namespace: <log_forwarder_namespace> 2
   spec:
     serviceAccountName: <service_account_name> 3
     outputs:
      - name: elasticsearch-example 4
        type: elasticsearch 5
        elasticsearch:
          version: 8 6
        url: http://elasticsearch.example.com:9200 7
        secret:
          name: es-secret 8
     pipelines:
      - name: application-logs 9
        inputRefs: 10
        - application
        - audit
        outputRefs:
        - elasticsearch-example 11
        - default 12
        labels:
          myLabel: "myValue" 13
   # ...

   1

   레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.

   2

   레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.

   3

   서비스 계정의 이름입니다. 서비스 계정은 로그 전달자가 openshift-logging 네임스페이스에 배포되지 않은 경우에만 다중 로그 전달자 구현에 필요합니다.

   4

   출력 이름을 지정합니다.

   5

   elasticsearch 유형을 지정합니다.

   6

   Elasticsearch 버전을 지정합니다. 6,7 또는 8 일 수 있습니다.

   7

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

   8

   https 접두사의 경우 TLS 통신의 엔드포인트에 필요한 보안 이름을 지정합니다. 시크릿에는 나타내는 인증서를 가리키는 ca-bundle.crt 키가 포함되어야 합니다. 그러지 않으면 http 및 https 접두사의 경우 사용자 이름과 암호가 포함된 시크릿을 지정할 수 있습니다. 레거시 구현에서는 openshift-logging 프로젝트에 시크릿이 있어야 합니다. 자세한 내용은 다음 "사용자 이름 및 암호가 포함된 시크릿 설정 예"를 참조하십시오.

   9

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

   10

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

   11

   이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.

   12

   선택사항: default 출력을 지정하여 내부 Elasticsearch 인스턴스로 로그를 보냅니다.

   13

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

2. ClusterLogForwarder CR을 적용합니다.

   $ oc apply -f <filename>.yaml