로깅

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

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

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

프로세스

1. openshift-logging 프로젝트에서 ClusterLogging 사용자 정의 리소스(CR)를 편집합니다.

   $ oc edit ClusterLogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ....
   
   spec:
     collection:
       logs:
         fluentd:
           resources:
             limits: 1
               memory: 736Mi
             requests:
               cpu: 100m
               memory: 736Mi

   1

   필요에 따라 CPU 및 메모리 제한 및 요청을 지정합니다. 표시된 값이 기본값입니다.

프로세스

1. openshift-logging 프로젝트에서 ClusterLogging 사용자 정의 리소스(CR)를 편집합니다.

   $ oc edit ClusterLogging instance

2. 다음 매개변수를 추가하거나 수정합니다.

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   metadata:
     name: instance
     namespace: openshift-logging
   spec:
     forwarder:
       fluentd:
         buffer:
           chunkLimitSize: 8m 1
           flushInterval: 5s 2
           flushMode: interval 3
           flushThreadCount: 3 4
           overflowAction: throw_exception 5
           retryMaxInterval: "300s" 6
           retryType: periodic 7
           retryWait: 1s 8
           totalLimitSize: 32m 9
   ...

   1

   플러시를 위해 큐에 추가되기 전에 각 청크의 최대 크기를 지정합니다.

   2

   청크 플러시 간격을 지정합니다.

   3

   lazy, interval 또는 immediate 등 청크 플러시를 수행할 방법을 지정합니다.

   4

   청크 플러시에 사용할 스레드 수를 지정합니다.

   5

   throw_exception, block 또는 drop_oldest_chunk 등 큐가 가득 찼을 때의 청크 동작을 지정합니다.

   6

   exponential_backoff 청크 플러시 방법의 최대 간격(초)을 지정합니다.

   7

   청크 플러시 실패 시 재시도 유형을 exponential_backoff 또는 periodic으로 지정합니다.

   8

   다음 청크 플러시 전 시간(초)을 지정합니다.

   9

   청크 버퍼의 최대 크기를 지정합니다.

3. Fluentd Pod가 재배포되었는지 확인합니다.

   $ oc get pods -n openshift-logging

4. 새 값이 fluentd 구성 맵에 있는지 확인합니다.

   $ oc extract configmap/fluentd --confirm

   예: fluentd.conf

   <buffer>
    @type file
    path '/var/lib/fluentd/default'
    flush_mode interval
    flush_interval 5s
    flush_thread_count 3
    retry_type periodic
    retry_wait 1s
    retry_max_interval 300s
    retry_timeout 60m
    queued_chunks_limit_size "#{ENV['BUFFER_QUEUE_LIMIT'] || '32'}"
    total_limit_size 32m
    chunk_limit_size 8m
    overflow_action throw_exception
   </buffer>

프로세스

1. openshift-logging 프로젝트에서 ClusterLogging 사용자 정의 리소스(CR)를 편집합니다.

   $ oc edit ClusterLogging instance

2. ClusterLogging CR에서 logStore, visualization, curation 스탠자를 제거하십시오.

3. ClusterLogging CR의 collection 스탠자를 유지합니다. 결과는 다음 예와 유사해야 합니다.

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
     namespace: "openshift-logging"
   spec:
     managementState: "Managed"
     collection:
       logs:
         type: "fluentd"
         fluentd: {}

4. Fluentd Pod가 재배포되었는지 확인합니다.

   $ oc get pods -n openshift-logging

1. ClusterLogForwarder CR YAML 파일을 생성하거나 기존 CR을 편집합니다.

   • 모든 로그 유형을 내부 Elasticsearch 인스턴스로 보내는 CR을 생성합니다. 다음 예제를 변경하지 않고 그대로 사용할 수 있습니다.

     apiVersion: logging.openshift.io/v1
     kind: ClusterLogForwarder
     metadata:
       name: instance
       namespace: openshift-logging
     spec:
       pipelines: 1
       - name: all-to-default
         inputRefs:
         - infrastructure
         - application
         - audit
         outputRefs:
         - default

     1

     파이프라인은 지정된 출력을 사용하여 전달할 로그 유형을 정의합니다. 기본 출력은 로그를 내부 Elasticsearch 인스턴스로 전달합니다.

     참고

     파이프라인에서 애플리케이션, 인프라 및 감사의 세 가지 유형의 로그를 모두 지정해야 합니다. 로그 유형을 지정하지 않으면 해당 로그가 저장되지 않고 손실됩니다.

   • 기존 ClusterLogForwarder CR이 있는 경우 감사 로그의 기본 출력에 파이프라인을 추가합니다. 기본 출력을 정의할 필요가 없습니다. 예를 들면 다음과 같습니다.

     apiVersion: "logging.openshift.io/v1"
     kind: ClusterLogForwarder
     metadata:
       name: instance
       namespace: openshift-logging
     spec:
       outputs:
        - name: elasticsearch-insecure
          type: "elasticsearch"
          url: http://elasticsearch-insecure.messaging.svc.cluster.local
          insecure: true
        - name: elasticsearch-secure
          type: "elasticsearch"
          url: https://elasticsearch-secure.messaging.svc.cluster.local
          secret:
            name: es-audit
        - name: secureforward-offcluster
          type: "fluentdForward"
          url: https://secureforward.offcluster.com:24224
          secret:
            name: secureforward
       pipelines:
        - name: container-logs
          inputRefs:
          - application
          outputRefs:
          - secureforward-offcluster
        - name: infra-logs
          inputRefs:
          - infrastructure
          outputRefs:
          - elasticsearch-insecure
        - name: audit-logs
          inputRefs:
          - audit
          outputRefs:
          - elasticsearch-secure
          - default 1

     1

     이 파이프라인은 외부 인스턴스와 함께 내부 Elasticsearch 인스턴스로 감사 로그를 보냅니다.

1. retentionPolicy 매개변수를 추가하거나 수정하려면 ClusterLogging CR을 편집합니다.

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   ...
   spec:
     managementState: "Managed"
     logStore:
       type: "elasticsearch"
       retentionPolicy: 1
         application:
           maxAge: 1d
         infra:
           maxAge: 7d
         audit:
           maxAge: 7d
       elasticsearch:
         nodeCount: 3
   ...

   1

   Elasticsearch가 각 로그 소스를 유지해야 하는 시간을 지정합니다. 정수 및 시간 지정을 입력합니다(주(w), 시간(h/H), 분(m) 및 초(s)). 예를 들어 1일은 1d입니다. maxAge보다 오래된 로그는 삭제됩니다. 기본적으로 로그는 7일 동안 유지됩니다.

2. Elasticsearch 사용자 정의 리소스(CR)에서 설정을 확인할 수 있습니다.

   예를 들어 Cluster Logging Operator는 8시간마다 인프라 로그의 활성 인덱스를 롤오버하는 설정이 포함된 보존 정책을 구성하기 위해 다음 Elasticsearch CR을 업데이트했으며 롤오버된 인덱스는 롤오버 후 7일 후에 삭제됩니다. OpenShift Container Platform은 15분마다 인덱스를 롤오버해야 하는지 확인합니다.

   apiVersion: "logging.openshift.io/v1"
   kind: "Elasticsearch"
   metadata:
     name: "elasticsearch"
   spec:
   ...
     indexManagement:
       policies: 1
         - name: infra-policy
           phases:
             delete:
               minAge: 7d 2
             hot:
               actions:
                 rollover:
                   maxAge: 8h 3
           pollInterval: 15m 4
   ...

   1

   보존 정책은 각 로그 소스에 대해 해당 소스의 로그를 삭제하고 롤오버할 시기를 나타냅니다.

   2

   OpenShift Container Platform이 롤오버된 인덱스를 삭제하는 경우 이 설정은 ClusterLogging CR에서 설정한 maxAge입니다.

   3

   인덱스를 롤오버할 때 고려해야 할 OpenShift Container Platform의 인덱스 수명입니다. 이 값은 ClusterLogging CR에서 설정한 maxAge에서 결정됩니다.

   4

   OpenShift Container Platform에서 인덱스를 롤오버해야 하는지 확인하는 경우 이 설정은 기본값이며 변경할 수 없습니다.

   참고

   Elasticsearch CR 수정은 지원되지 않습니다. 보존 정책에 대한 모든 변경은 ClusterLogging CR에서 수행해야 합니다.

   OpenShift Elasticsearch Operator는 Cron 작업을 배포하고 pollInterval로 예약한 정의된 정책에 따라 각 매핑의 인덱스를 갱신합니다.

   $ oc get cronjob

   출력 예

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

프로세스

1. openshift-logging 프로젝트에서 ClusterLogging 사용자 정의 리소스(CR)를 편집합니다.

   $ oc edit ClusterLogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   ....
   spec:
       logStore:
         type: "elasticsearch"
         elasticsearch:
           resources: 1
             limits:
               memory: "16Gi"
             requests:
               cpu: "1"
               memory: "16Gi"
           proxy: 2
             resources:
               limits:
                 memory: 100Mi
               requests:
                 memory: 100Mi

   1

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

   2

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

프로세스

1. openshift-logging 프로젝트에서 ClusterLogging 사용자 정의 리소스(CR)를 편집합니다.

   $ oc edit clusterlogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ....
   
   spec:
     logStore:
       type: "elasticsearch"
       elasticsearch:
         redundancyPolicy: "SingleRedundancy" 1

   1

   shard에 대한 중복 정책을 지정합니다. 변경 사항을 저장하면 변경 사항이 적용됩니다.

   • FullRedundancy. Elasticsearch는 각 인덱스의 기본 shard를 모든 데이터 노드에 완전히 복제합니다. 이 방법은 안전성이 가장 높지만 필요한 디스크 양이 가장 많고 성능이 가장 낮습니다.
   • MultipleRedundancy. Elasticsearch는 각 인덱스의 기본 shard를 데이터 노드의 절반으로 완전히 복제합니다. 이 방법은 안전성과 성능 사이의 균형이 우수합니다.
   • SingleRedundancy. Elasticsearch는 각 인덱스에 대해 기본 shard의 사본 하나를 만듭니다. 두 개 이상의 데이터 노드가 존재하는 한 항상 로그를 사용할 수 있고 복구할 수 있습니다. 5개 이상의 노드를 사용하는 경우 MultipleRedundancy보다 성능이 향상됩니다. 단일 Elasticsearch 노드 배포에는 이 정책을 적용할 수 없습니다.
   • ZeroRedundancy. Elasticsearch는 기본 shard의 사본을 만들지 않습니다. 노드가 다운되거나 실패하는 경우 로그를 사용할 수 없거나 로그가 손실될 수 있습니다. 안전보다 성능이 더 중요하거나 자체 디스크/PVC 백업/복원 전략을 구현한 경우 이 모드를 사용합니다.

프로세스

1. ClusterLogging CR을 편집하여 클러스터의 각 데이터 노드가 영구 볼륨 클레임에 바인딩되도록 지정합니다.

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   # ...
   spec:
     logStore:
       type: "elasticsearch"
       elasticsearch:
         nodeCount: 3
         storage:
           storageClassName: "gp2"
           size: "200G"

프로세스

1. emptyDir을 지정하려면 ClusterLogging CR을 편집합니다.

    spec:
       logStore:
         type: "elasticsearch"
         elasticsearch:
           nodeCount: 3
           storage: {}

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

   $ oc project openshift-logging

2. Elasticsearch pod의 이름을 가져옵니다.

   $ oc get pods | grep elasticsearch-

3. Fluentd Pod를 축소하여 Elasticsearch로 새 로그 전송을 중지합니다.

   $ oc -n openshift-logging patch daemonset/logging-fluentd -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-fluentd": "false"}}}}}'

4. OpenShift Container Platform es_util 툴을 사용하여 shard 동기화 플러시를 수행하여 종료하기 전에 디스크에 쓰기 대기 중인 작업이 없는지 확인하십시오.

   $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_flush/synced" -XPOST

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

   $ oc exec -c elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6  -c elasticsearch -- es_util --query="_flush/synced" -XPOST

   출력 예

   {"_shards":{"total":4,"successful":4,"failed":0},".security":{"total":2,"successful":2,"failed":0},".kibana_1":{"total":2,"successful":2,"failed":0}}

5. OpenShift Container Platform es_util 도구를 사용하여 의도적으로 노드를 중단할 때 shard 밸런싱을 방지합니다.

   $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'

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

   $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'

   출력 예

   {"acknowledged":true,"persistent":{"cluster":{"routing":{"allocation":{"enable":"primaries"}}}},"transient":

6. 명령이 완료되면 ES 클러스터의 각 배포에 대해 다음을 수행합니다.

   1. 기본적으로 OpenShift Container Platform Elasticsearch 클러스터는 노드에 대한 롤아웃을 차단합니다. 다음 명령을 사용하여 롤아웃을 허용하고 Pod가 변경 사항을 선택하도록 합니다.

      $ oc rollout resume deployment/<deployment-name>

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

      $ oc rollout resume deployment/elasticsearch-cdm-0-1

      출력 예

      deployment.extensions/elasticsearch-cdm-0-1 resumed

      새 Pod가 배포되었습니다. Pod에 컨테이너가 준비되면 다음 배포로 이동할 수 있습니다.

      $ oc get pods | grep elasticsearch-

      출력 예

      NAME                                            READY   STATUS    RESTARTS   AGE
      elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6k    2/2     Running   0          22h
      elasticsearch-cdm-5ceex6ts-2-f799564cb-l9mj7    2/2     Running   0          22h
      elasticsearch-cdm-5ceex6ts-3-585968dc68-k7kjr   2/2     Running   0          22h

   2. 배포가 완료되면 롤아웃을 허용하지 않도록 Pod를 재설정합니다.

      $ oc rollout pause deployment/<deployment-name>

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

      $ oc rollout pause deployment/elasticsearch-cdm-0-1

      출력 예

      deployment.extensions/elasticsearch-cdm-0-1 paused

   3. Elasticsearch 클러스터가 green 또는 yellow 상태인지 확인하십시오.

      $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/health?pretty=true

      참고

      이전 명령에서 사용한 Elasticsearch Pod에서 롤아웃을 수행한 경우 그 Pod는 더 이상 존재하지 않으며 여기에 새 Pod 이름이 필요합니다.

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

      $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/health?pretty=true

      {
        "cluster_name" : "elasticsearch",
        "status" : "yellow", 1
        "timed_out" : false,
        "number_of_nodes" : 3,
        "number_of_data_nodes" : 3,
        "active_primary_shards" : 8,
        "active_shards" : 16,
        "relocating_shards" : 0,
        "initializing_shards" : 0,
        "unassigned_shards" : 1,
        "delayed_unassigned_shards" : 0,
        "number_of_pending_tasks" : 0,
        "number_of_in_flight_fetch" : 0,
        "task_max_waiting_in_queue_millis" : 0,
        "active_shards_percent_as_number" : 100.0
      }

      1

      계속하기 전에 이 매개변수 값이 green 또는 yellow인지 확인하십시오.

7. Elasticsearch ConfigMap을 변경한 경우 각 Elasticsearch Pod에 대해 이 단계를 반복합니다.

8. 클러스터의 모든 배포가 롤아웃되면 shard 밸런싱을 다시 활성화합니다.

   $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'

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

   $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'

   출력 예

   {
     "acknowledged" : true,
     "persistent" : { },
     "transient" : {
       "cluster" : {
         "routing" : {
           "allocation" : {
             "enable" : "all"
           }
         }
       }
     }
   }

9. Fluentd Pod를 확장하여 Elasticsearch에 새 로그를 전송합니다.

   $ oc -n openshift-logging patch daemonset/logging-fluentd -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-fluentd": "true"}}}}}'

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

   $ oc project openshift-logging

2. 로그 저장소에서 CA 인증서를 추출하고 admin-ca 파일에 씁니다.

   $ oc extract secret/elasticsearch --to=. --keys=admin-ca

   출력 예

   admin-ca

3. 로그 저장소 서비스의 경로를 YAML 파일로 생성합니다.

   1. 다음을 사용하여 YAML 파일을 생성합니다.

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        name: elasticsearch
        namespace: openshift-logging
      spec:
        host:
        to:
          kind: Service
          name: elasticsearch
        tls:
          termination: reencrypt
          destinationCACertificate: | 1

      1

      로그 저장소 CA 인증서를 추가하거나 다음 단계에서 명령을 사용합니다. 일부 재암호화 경로에 필요한 spec.tls.key, spec.tls.certificate 및 spec.tls.caCertificate 매개변수를 설정할 필요는 없습니다.

   2. 다음 명령을 실행하여 이전 단계에서 생성한 경로 YAML에 로그 저장소 CA 인증서를 추가합니다.

      $ cat ./admin-ca | sed -e "s/^/      /" >> <file-name>.yaml

   3. 경로를 생성합니다.

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

      출력 예

      route.route.openshift.io/elasticsearch created

4. Elasticsearch 서비스가 노출되어 있는지 확인합니다.

   1. 요청에 사용할 이 서비스 계정의 토큰을 가져옵니다.

      $ token=$(oc whoami -t)

   2. 생성한 elasticsearch 경로를 환경 변수로 설정합니다.

      $ routeES=`oc get route elasticsearch -o jsonpath={.spec.host}`

   3. 경로가 성공적으로 생성되었는지 확인하려면 노출된 경로를 통해 Elasticsearch에 액세스하는 다음 명령을 실행합니다.

      curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://${routeES}"

      응답은 다음과 유사하게 나타납니다.

      출력 예

      {
        "name" : "elasticsearch-cdm-i40ktba0-1",
        "cluster_name" : "elasticsearch",
        "cluster_uuid" : "0eY-tJzcR3KOdpgeMJo-MQ",
        "version" : {
        "number" : "6.8.1",
        "build_flavor" : "oss",
        "build_type" : "zip",
        "build_hash" : "Unknown",
        "build_date" : "Unknown",
        "build_snapshot" : true,
        "lucene_version" : "7.7.0",
        "minimum_wire_compatibility_version" : "5.6.0",
        "minimum_index_compatibility_version" : "5.0.0"
      },
        "<tagline>" : "<for search>"
      }

프로세스

1. openshift-logging 프로젝트에서 ClusterLogging 사용자 정의 리소스(CR)를 편집합니다.

   $ oc edit ClusterLogging instance -n openshift-logging

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ....
   
   spec:
     managementState: "Managed"
     logStore:
       type: "elasticsearch"
       elasticsearch:
         nodeCount: 2
         resources: 1
           limits:
             memory: 2Gi
           requests:
             cpu: 200m
             memory: 2Gi
         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
     curation:
       type: "curator"
       curator:
         resources: 4
           limits:
             memory: 200Mi
           requests:
             cpu: 200m
             memory: 200Mi
         schedule: "*/10 * * * *"
     collection:
       logs:
         type: "fluentd"
         fluentd:
           resources: 5
             limits:
               memory: 736Mi
             requests:
               cpu: 200m
               memory: 736Mi

   1

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

   2 3

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

   4

   필요에 따라 로그 큐레이터에 대한 CPU 및 메모리 제한 및 요청을 지정합니다.

   5

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

프로세스

1. openshift-logging 프로젝트에서 ClusterLogging 사용자 정의 리소스(CR)를 편집합니다.

   $ oc edit ClusterLogging instance

   $ oc edit ClusterLogging instance
   
   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ....
   
   spec:
       visualization:
         type: "kibana"
         kibana:
           replicas: 1 1

   1

   Kibana 노드의 수를 지정합니다.

프로세스

1. openshift-logging 프로젝트에서 ClusterLogging 사용자 정의 리소스(CR)를 편집합니다.

   $ oc edit ClusterLogging instance -n openshift-logging

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ....
   
   spec:
     managementState: "Managed"
     logStore:
       type: "elasticsearch"
       elasticsearch:
         nodeCount: 2
         resources: 1
           limits:
             memory: 2Gi
           requests:
             cpu: 200m
             memory: 2Gi
         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
     curation:
       type: "curator"
       curator:
         resources: 4
           limits:
             memory: 200Mi
           requests:
             cpu: 200m
             memory: 200Mi
         schedule: "*/10 * * * *"
     collection:
       logs:
         type: "fluentd"
         fluentd:
           resources: 5
             limits:
               memory: 736Mi
             requests:
               cpu: 200m
               memory: 736Mi

   1

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

   2 3

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

   4

   필요에 따라 로그 큐레이터에 대한 CPU 및 메모리 제한 및 요청을 지정합니다.

   5

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

프로세스

1. 다음 명령을 사용하여 클러스터 로깅 Pod를 예약하려는 노드에 taint를 추가합니다.

   $ oc adm taint nodes <node-name> <key>=<value>:<effect>

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

   $ oc adm taint nodes node1 elasticsearch=node:NoExecute

   이 예에서는 키 elasticsearch, 값 node 및 taint 효과 NoExecute로 node1에 taint를 배치합니다. NoExecute 효과가 있는 노드는 taint와 일치하는 Pod만 스케줄링하고 일치하지 않는 기존 Pod는 제거합니다.

2. Elasticsearch Pod에 대한 허용 오차를 구성하려면 ClusterLogging CR의 logstore 섹션을 편집합니다.

     logStore:
       type: "elasticsearch"
       elasticsearch:
         nodeCount: 1
         tolerations:
         - key: "elasticsearch"  1
           operator: "Exists"  2
           effect: "NoExecute"  3
           tolerationSeconds: 6000  4

   1

   노드에 추가한 키를 지정합니다.

   2

   노드에 elasticsearch 키의 taint가 존재할 것을 요구하도록 Exists Operator를 지정합니다.

   3

   NoExecute 효과를 지정합니다.

   4

   선택적으로 tolerationSeconds 매개변수를 지정하여 Pod가 제거되기 전까지 노드에 바인딩되는 시간을 설정합니다.

프로세스

1. 다음 명령을 사용하여 로그 시각화 프로그램 Pod를 예약하려는 노드에 taint를 추가합니다.

   $ oc adm taint nodes <node-name> <key>=<value>:<effect>

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

   $ oc adm taint nodes node1 kibana=node:NoExecute

   이 예에서는 키 kibana, 값 node 및 taint 효과 NoExecute로 node1에 taint를 배치합니다. NoExecute taint 효과를 사용해야 합니다. NoExecute는 taint와 일치하는 Pod만 스케줄링하고 일치하지 않는 기존 Pod는 제거합니다.

2. Kibana Pod에 대한 허용 오차를 구성하려면 ClusterLogging CR의 visualization 섹션을 편집합니다.

     visualization:
       type: "kibana"
       kibana:
         tolerations:
         - key: "kibana"  1
           operator: "Exists"  2
           effect: "NoExecute"  3
           tolerationSeconds: 6000 4

   1

   노드에 추가한 키를 지정합니다.

   2

   key/value/effect 매개변수가 일치할 것을 요구하도록 Exists Operator를 지정합니다.

   3

   NoExecute 효과를 지정합니다.

   4

   선택적으로 tolerationSeconds 매개변수를 지정하여 Pod가 제거되기 전까지 노드에 바인딩되는 시간을 설정합니다.

프로세스

1. 다음 명령을 사용하여 로깅 수집기 Pod에서 로깅 수집기 Pod를 스케줄링할 노드에 taint를 추가합니다.

   $ oc adm taint nodes <node-name> <key>=<value>:<effect>

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

   $ oc adm taint nodes node1 collector=node:NoExecute

   이 예에서는 키 collector, 값 node 및 taint 효과 NoExecute로 node1에 taint를 배치합니다. NoExecute taint 효과를 사용해야 합니다. NoExecute는 taint와 일치하는 Pod만 스케줄링하고 일치하지 않는 기존 Pod는 제거합니다.

2. ClusterLogging 사용자 정의 리소스(CR)의 collection 스탠자를 편집하여 로깅 수집기 Pod에 대한 허용 오차를 구성합니다.

     collection:
       logs:
         type: "fluentd"
         fluentd:
           tolerations:
           - key: "collector"  1
             operator: "Exists"  2
             effect: "NoExecute"  3
             tolerationSeconds: 6000  4

   1

   노드에 추가한 키를 지정합니다.

   2

   key/value/effect 매개변수가 일치할 것을 요구하도록 Exists Operator를 지정합니다.

   3

   NoExecute 효과를 지정합니다.

   4

   선택적으로 tolerationSeconds 매개변수를 지정하여 Pod가 제거되기 전까지 노드에 바인딩되는 시간을 설정합니다.

프로세스

1. openshift-logging 프로젝트에서 ClusterLogging 사용자 정의 리소스(CR)를 편집합니다.

   $ oc edit ClusterLogging instance

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   
   ...
   
   spec:
     collection:
       logs:
         fluentd:
           resources: null
         type: fluentd
     curation:
       curator:
         nodeSelector: 1
           node-role.kubernetes.io/infra: ''
         resources: null
         schedule: 30 3 * * *
       type: curator
     logStore:
       elasticsearch:
         nodeCount: 3
         nodeSelector: 2
           node-role.kubernetes.io/infra: ''
         redundancyPolicy: SingleRedundancy
         resources:
           limits:
             cpu: 500m
             memory: 16Gi
           requests:
             cpu: 500m
             memory: 16Gi
         storage: {}
       type: elasticsearch
     managementState: Managed
     visualization:
       kibana:
         nodeSelector: 3
           node-role.kubernetes.io/infra: ''
         proxy:
           resources: null
         replicas: 1
         resources: null
       type: kibana
   
   ...

프로세스

1. 필요한 설정으로 journald.conf 파일을 생성합니다.

   Compress=yes 1
   ForwardToConsole=no 2
   ForwardToSyslog=no
   MaxRetentionSec=1month 3
   RateLimitBurst=10000 4
   RateLimitIntervalSec=30s
   Storage=persistent 5
   SyncIntervalSec=1s 6
   SystemMaxUse=8g 7
   SystemKeepFree=20% 8
   SystemMaxFileSize=10M 9

   1

   로그를 파일 시스템에 쓰기 전에 압축할지 여부를 지정합니다. 메시지를 압축하려면 yes를 지정하고 압축하지 않으려면 no를 지정합니다. 기본값은 yes입니다.

   2

   로그 메시지를 전달할지 여부를 구성합니다. 각각에 대해 기본값은 no입니다. 다음을 지정합니다.

   • 시스템 콘솔에 로그를 전달하려면 ForwardToConsole을 지정합니다.
   • 로그를 커널 로그 버퍼로 전달하려면 ForwardToKsmg를 지정합니다.
   • syslog 데몬으로 전달하려면 ForwardToSyslog를 지정합니다.
   • 로그인한 모든 사용자에게 월(wall) 메시지로 메시지를 전달하려면 ForwardToWall을 지정합니다.

   3

   저널 항목을 저장할 최대 시간을 지정합니다. 초를 지정하려면 숫자를 입력합니다. 또는 "year", "month", "week", "day", "h"또는 "m"과 같은 단위를 포함합니다. 비활성화하려면 0을 입력합니다. 기본값은 1month입니다.

   4

   속도 제한을 구성합니다. RateLimitIntervalSec에서 정의한 시간 간격 동안, RateLimitBurst에 지정된 것보다 더 많은 로그를 수신하는 경우 간격이 끝날 때까지 간격 내의 모든 추가 메시지는 삭제됩니다. 기본값인 RateLimitIntervalSec=30s 및 RateLimitBurst=10000을 설정하는 것이 좋습니다.

   5

   로그 저장 방법을 지정합니다. 기본값은 persistent입니다.

   • /var/log/journal/에서 메모리에 로그를 저장하기 위한 volatile입니다.
   • /var/log/journal/의 디스크에 로그를 저장하기 위한 persistent입니다. systemd는 디렉토리가 없는 경우 디렉토리를 생성합니다.
   • 디렉토리가 존재하는 경우 /var/log/journal/에 로그를 저장하기 위한 auto입니다. 존재하지 않는 경우 systemd는 /run/systemd/journal에 로그를 임시 저장합니다.
   • 로그를 저장하지 않는 none입니다. systemd는 모든 로그를 삭제합니다.

   6

   ERR, WARNING, NOTICE, INFO 및 DEBUG 로그에 대해 저널 파일을 디스크에 동기화하기 전에 제한 시간을 지정합니다. CRIT, ALERT 또는 EMERG 로그를 수신하면 systemd가 즉시 동기화됩니다. 기본값은 1s입니다.

   7

   저널이 사용할 수 있는 최대 크기를 지정합니다. 기본값은 8g입니다.

   8

   시스템에서 사용 가능한 디스크 공간을 지정합니다. 기본값은 20%입니다.

   9

   /var/log/journal에 지속적으로 저장된 개별 저널 파일의 최대 크기를 지정합니다. 기본값은 10M입니다.

   참고

   속도 제한을 제거하는 경우 이전에 제한되었던 메시지를 처리할 때 시스템 로깅 데몬에서 CPU 사용률이 증가할 수 있습니다.

   시스템 설정에 대한 자세한 내용은 https://www.freedesktop.org/software/systemd/man/journald.conf.html을 참조하십시오. 해당 페이지에 나열된 기본 설정은 OpenShift Container Platform에 적용되지 않을 수 있습니다.

2. journal.conf 파일을 base64로 변환하고 다음 명령을 실행하여 jrnl_cnf 라는 변수에 저장합니다.

   $ export jrnl_cnf=$( cat journald.conf | base64 -w0 )

3. 이전 단계에서 만든 jrnl_cnf 변수가 포함된 MachineConfig 오브젝트를 만듭니다. 다음 샘플 명령은 작업자에 대한 MachineConfig 오브젝트를 생성합니다.

   $ cat << EOF > ./40-worker-custom-journald.yaml 1
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker 2
     name: 40-worker-custom-journald 3
   spec:
     config:
       ignition:
         config: {}
         security:
           tls: {}
         timeouts: {}
         version: 3.1.0
       networkd: {}
       passwd: {}
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64,${jrnl_cnf} 4
             verification: {}
           filesystem: root
           mode: 0644 5
           path: /etc/systemd/journald.conf.d/custom.conf
     osImageURL: ""
   EOF

   1

   선택 사항: 컨트롤 플레인 (마스터) 노드의 경우 파일 이름을 40-master-custom-journald.yaml 로 지정할 수 있습니다.

   2

   선택 사항: 컨트롤 플레인 (마스터) 노드의 경우 역할을 master 로 제공합니다.

   3

   선택 사항: 컨트롤 플레인 (마스터) 노드의 경우 이름을 40-master-custom-journald 로 지정할 수 있습니다.

   4

   선택 사항: the journald.conf 파일에 매개 변수의 정적 사본을 포함하려면 ${jrnl_cnf} 를 echo $jrnl_cnf 명령의 출력으로 바꿉니다.

   5

   journal.conf 파일에 대한 권한을 설정합니다. 0644 권한을 설정하는 것이 좋습니다.

4. 머신 구성을 생성합니다.

   $ oc apply -f <file_name>.yaml

   컨트롤러는 새로운 MachineConfig를 감지하고 새로운 rendered-worker-<hash> 버전을 생성합니다.

5. 각 노드에 새로 렌더링된 구성의 롤아웃 상태를 모니터링합니다.

   $ oc describe machineconfigpool/<node> 1

   1

   노드를 master 또는 worker 로 지정합니다.

   작업자의 출력 예

   Name:         worker
   Namespace:
   Labels:       machineconfiguration.openshift.io/mco-built-in=
   Annotations:  <none>
   API Version:  machineconfiguration.openshift.io/v1
   Kind:         MachineConfigPool
   
   ...
   
   Conditions:
     Message:
     Reason:                All nodes are updating to rendered-worker-913514517bcea7c93bd446f4830bc64e

1. openshift-logging 프로젝트에서 ClusterLogging 사용자 정의 리소스를 편집합니다.

   $ oc edit clusterlogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ...
   
     curation:
       curator:
         schedule: 30 3 * * * 1
       type: curator

   1

   cron 형식으로 Curator의 일정을 지정합니다.

   참고

   시간대는 Curator Pod가 실행되는 호스트 노드를 기준으로 설정됩니다.

1. OpenShift Container Platform 사용자 정의 Curator 구성 파일을 편집합니다.

   $ oc edit configmap/curator

2. 필요한 대로 다음 매개변수를 설정합니다.

   config.yaml: |
     project_name:
       action
         unit:value

   사용 가능한 매개변수는 다음과 같습니다.

   표 3.2. 프로젝트 옵션

   변수 이름	설명
   project_name	myapp-devel과 같은 프로젝트의 실제 이름입니다. OpenShift Container Platform 작업 로그의 경우 프로젝트 이름으로 이름 .operations를 사용합니다.
   작업	수행할 작업으로, 현재 삭제만 허용됩니다.
   단위	삭제에 사용할 기간으로,days, weeks, 또는 months이 있습니다.
   값	단위 수입니다.

   표 3.3. 필터 옵션

   변수 이름	설명
   .defaults	.defaults를 project_name으로 사용하여 지정되지 않은 프로젝트의 기본값을 설정합니다.
   .regex	프로젝트 이름과 일치하는 정규식 목록입니다.
   패턴	작은 따옴표로 묶은 유효하고 올바르게 이스케이프 된 정규 표현식 패턴입니다.

절차

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
        labels:
          myLabel: "myValue" 11
      - name: infrastructure-audit-logs 12
        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

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

   12

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

   • 선택 사항: 파이프라인을 설명하는 이름입니다.
   • 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
        labels:
          clusterId: "C1234" 11
      - name: forward-to-fluentd-insecure 12
        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

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

   12

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

   • 선택 사항: 파이프라인을 설명하는 이름입니다.
   • 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
        labels:
          secure: "true" 12
          syslog: "east"
      - name: syslog-west 13
        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

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

   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: 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
        labels:
          logType: "application" 11
      - name: infra-topic 12
        inputRefs:
        - infrastructure
        outputRefs:
        - infra-logs
        labels:
          logType: "infra"
      - name: audit-topic
        inputRefs:
        - audit
        outputRefs:
        - audit-logs
        - default 13
        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

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

   12

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

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

   13

   선택 사항: 내부 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
        labels: 11
          project: "my-project"
      - name: forward-to-fluentd-secure 12
        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

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

   12

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

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

2. 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. openshift-logging 프로젝트로 변경합니다.

   $ oc project openshift-logging

2. 클러스터 로깅 상태를 보려면 다음을 수행합니다.

   1. 클러스터 로깅 상태를 가져옵니다.

      $ oc get clusterlogging instance -o yaml

      출력 예

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogging
      
      ....
      
      status:  1
        collection:
          logs:
            fluentdStatus:
              daemonSet: fluentd  2
              nodes:
                fluentd-2rhqp: ip-10-0-169-13.ec2.internal
                fluentd-6fgjh: ip-10-0-165-244.ec2.internal
                fluentd-6l2ff: ip-10-0-128-218.ec2.internal
                fluentd-54nx5: ip-10-0-139-30.ec2.internal
                fluentd-flpnn: ip-10-0-147-228.ec2.internal
                fluentd-n2frh: ip-10-0-157-45.ec2.internal
              pods:
                failed: []
                notReady: []
                ready:
                - fluentd-2rhqp
                - fluentd-54nx5
                - fluentd-6fgjh
                - fluentd-6l2ff
                - fluentd-flpnn
                - fluentd-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. openshift-logging 프로젝트로 변경합니다.

   $ oc project openshift-logging

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

   1. 로그 저장소 인스턴스의 이름을 가져옵니다.

      $ oc get Elasticsearch

      출력 예

      NAME            AGE
      elasticsearch   5h9m

   2. 로그 저장소 상태를 가져옵니다.

      $ 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

      로그 저장소의 상태:

      • 활성 기본 shard 수입니다.
      • 활성 shard 수입니다.
      • 초기화 중인 shard 수입니다.
      • 로그 저장소 데이터 노드 수입니다.
      • 총 로그 저장소 노드 수입니다.
      • 보류 중인 작업 수입니다.
      • 로그 저장소 상태는 녹색, 빨간색, 노란색입니다.
      • 할당되지 않은 shard 수

      3

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

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

      4

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

      5

      'failed`, notReady 또는 준비 상태 아래에 나열된 클러스터의 로그를 저장 클라이언트, 데이터 및 마스터 Pod.

1. OpenShift Container Platform 콘솔에서 모니터링 → 경고를 클릭합니다.
2. 경고 탭을 클릭합니다. 선택한 필터에 따라 경고가 나열됩니다.

1. Curator의 디버그 로그를 활성화합니다.

   $ oc set env cronjob/curator CURATOR_LOG_LEVEL=DEBUG CURATOR_SCRIPT_LOG_LEVEL=DEBUG

   로그 수준을 지정합니다.

   • CRITICAL. Curatior가 심각한 메시지만 표시합니다.
   • ERROR. Curator가 오류 및 심각한 메시지만 표시합니다.
   • WARNING. Curator가 오류, 경고 및 심각한 메시지만 표시합니다.
   • INFO. Curator가 정보, 오류, 경고 및 심각한 메시지만 표시합니다.

   • DEBUG. Curator가 위의 모든 항목 외에도 디버그 메시지만 표시합니다.

     기본값은 INFO입니다.

     참고

     클러스터 로깅은 OpenShift Container Platform 래퍼 스크립트(run.sh 및 convert.py)에서 OpenShift Container Platform 사용자 정의 환경 변수 CURATOR_SCRIPT_LOG_LEVEL을 사용합니다. 환경 변수는 필요에 따라 스크립트 디버깅을 위해 CURATOR_LOG_LEVEL과 동일한 값을 갖습니다.

2. 다음 Curator 반복을 트리거합니다.

   $ oc create job --from=cronjob/curator <job_name>

3. 다음 명령을 사용하여 Cron 작업을 제어합니다.

   • Cron 작업 일시 중단:

     $ oc patch cronjob curator -p '{"spec":{"suspend":true}}'

   • Cron 작업 다시 시작:

     $ oc patch cronjob curator -p '{"spec":{"suspend":false}}'

   • Cron 작업 일정 변경:

     $ oc patch cronjob curator -p '{"spec":{"schedule":"0 0 * * *"}}' 1

     1

     schedule 옵션은 cron 형식의 일정을 승인합니다.

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에서 해당 지원 사례에 압축 파일을 첨부합니다.