7장. 모니터

7.1. OpenShift Serverless에서 OpenShift Logging 사용

7.1.1. 클러스터 로깅 배포 정보

OpenShift Container Platform 클러스터 관리자는 OpenShift Container Platform 웹 콘솔 또는 CLI에서 클러스터 로깅을 배포하여 Elasticsearch Operator 및 Cluster Logging Operator를 설치할 수 있습니다. Operator가 설치되면 ClusterLogging 사용자 정의 리소스(CR)를 생성하여 클러스터 로깅 Pod 및 클러스터 로깅을 지원하는 데 필요한 기타 리소스를 예약합니다. Operator는 클러스터 로깅의 배포, 업그레이드 및 유지보수를 담당합니다.

ClusterLogging CR은 로그를 수집, 저장 및 시각화하기 위해 로깅 스택의 모든 구성 요소를 포함하는 전체 클러스터 로깅 환경을 정의합니다. Cluster Logging Operator는 클러스터 로깅 CR을 감시하고 그에 따라 로깅 배포를 조정합니다.

관리자와 애플리케이션 개발자는 보기 권한이 있는 프로젝트의 로그를 볼 수 있습니다.

7.1.2. 클러스터 로깅 배포 및 구성 정보

OpenShift Container Platform 클러스터 로깅은 중소 규모의 OpenShift Container Platform 클러스터에 맞게 조정되는 기본 구성과 함께 사용하도록 설계되었습니다.

다음 설치 지침에는 클러스터 로깅 인스턴스를 생성하고 클러스터 로깅 환경을 구성하는 데 사용할 수 있는 샘플 ClusterLogging 사용자 정의 리소스(CR)가 포함되어 있습니다.

기본 클러스터 로깅 설치를 사용하려면 샘플 CR을 직접 사용할 수 있습니다.

배포를 사용자 정의하려면 필요에 따라 샘플 CR을 변경합니다. 다음은 클러스터 로깅 인스턴스를 설치할 때 수행하거나 설치 후 수정할 수 있는 구성에 대해 설명합니다. ClusterLogging 사용자 정의 리소스 외부에서 수행할 수 있는 수정을 포함하여 각 구성 요소의 작업에 대한 자세한 내용은 구성 섹션을 참조하십시오.

7.1.2.1. 클러스터 로깅 구성 및 튜닝

openshift-logging 프로젝트에 배포된 ClusterLogging 사용자 정의 리소스를 수정하여 클러스터 로깅 환경을 구성할 수 있습니다.

설치 시 또는 설치 후 다음 구성 요소를 수정할 수 있습니다.

메모리 및 CPU
유효한 메모리 및 CPU 값으로 resources 블록을 수정하여 각 구성 요소의 CPU 및 메모리 제한을 모두 조정할 수 있습니다.
spec:
  logStore:
    elasticsearch:
      resources:
        limits:
          cpu:
          memory: 16Gi
        requests:
          cpu: 500m
          memory: 16Gi
      type: "elasticsearch"
  collection:
    logs:
      fluentd:
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
        type: "fluentd"
  visualization:
    kibana:
      resources:
        limits:
          cpu:
          memory:
        requests:
          cpu:
          memory:
     type: kibana
  curation:
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      type: "curator"
Elasticsearch 스토리지
storageClass namesize 매개변수를 사용하여 Elasticsearch 클러스터의 영구 스토리지 클래스 및 크기를 구성할 수 있습니다. Cluster Logging Operator는 이러한 매개변수를 기반으로 Elasticsearch 클러스터의 각 데이터 노드에 대한 PVC(영구 볼륨 클레임)를 생성합니다.
  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage:
          storageClassName: "gp2"
          size: "200G"

이 예제에서는 클러스터의 각 데이터 노드가 "gp2" 스토리지의 "200G"를 요청하는 PVC에 바인딩되도록 지정합니다. 각 기본 분할은 단일 복제본에서 지원합니다.

참고

storage 블록을 생략하면 임시 스토리지만 포함하는 배포가 생성됩니다.

  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage: {}
Elasticsearch 복제 정책

Elasticsearch 분할이 클러스터의 여러 데이터 노드에 복제되는 방법을 정의하는 정책을 설정할 수 있습니다.

  • FullRedundancy. 각 인덱스의 분할이 모든 데이터 노드에 완전히 복제됩니다.
  • MultipleRedundancy. 각 인덱스의 분할이 데이터 노드의 1/2에 걸쳐 있습니다.
  • SingleRedundancy. 각 분할의 단일 사본입니다. 두 개 이상의 데이터 노드가 존재하는 한 항상 로그를 사용할 수 있고 복구할 수 있습니다.
  • ZeroRedundancy. 분할 복사본이 없습니다. 노드가 다운되거나 실패하는 경우 로그를 사용할 수 없거나 로그가 손실될 수 있습니다.
Curator 일정
Curator 일정을 cron 형식으로 지정합니다.
  spec:
    curation:
    type: "curator"
    resources:
    curator:
      schedule: "30 3 * * *"

7.1.2.2. 수정된 ClusterLogging 사용자 정의 리소스 샘플

다음은 이전에 설명한 옵션을 사용하여 수정한 ClusterLogging 사용자 정의 리소스의 예입니다.

수정된 ClusterLogging 사용자 정의 리소스 샘플

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    retentionPolicy:
      application:
        maxAge: 1d
      infra:
        maxAge: 7d
      audit:
        maxAge: 7d
    elasticsearch:
      nodeCount: 3
      resources:
        limits:
          memory: 32Gi
        requests:
          cpu: 3
          memory: 32Gi
        storage:
          storageClassName: "gp2"
          size: "200G"
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources:
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      replicas: 1
  curation:
    type: "curator"
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      schedule: "*/5 * * * *"
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 1Gi

7.1.3. 클러스터 로깅을 사용하여 Knative Serving 구성 요소 로그 찾기

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.

프로세스

  1. Kibana 경로를 가져옵니다.

    $ oc -n openshift-logging get route kibana
  2. 경로의 URL을 사용하여 Kibana 대시보드로 이동한 후 로그인합니다.
  3. 인덱스가 .all로 설정되어 있는지 확인합니다. 인덱스가 .all로 설정되어 있지 않으면 OpenShift Container Platform 시스템 로그만 나열됩니다.
  4. knative-serving 네임스페이스를 사용하여 로그를 필터링합니다. 검색 상자에 kubernetes.namespace_name:knative-serving을 입력하여 결과를 필터링합니다.
참고

Knative Serving에서는 기본적으로 구조화된 로깅을 사용합니다. 클러스터 로깅 Fluentd 설정을 사용자 정의하여 이러한 로그의 구문 분석을 활성화할 수 있습니다. 이렇게 하면 로그를 더 쉽게 검색할 수 있고 로그 수준에서 필터링하여 문제를 빠르게 확인할 수 있습니다.

7.1.4. 클러스터 로깅을 사용하여 Knative Serving으로 배포된 서비스의 로그 찾기

OpenShift 클러스터 로깅을 사용하면 애플리케이션에 콘솔에 쓰는 로그가 Elasticsearch에 수집됩니다. 다음 절차에서는 Knative Serving을 사용하여 배포한 애플리케이션에 이러한 기능을 적용하는 방법을 간략하게 설명합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.

프로세스

  1. Kibana 경로를 가져옵니다.

    $ oc -n openshift-logging get route kibana
  2. 경로의 URL을 사용하여 Kibana 대시보드로 이동한 후 로그인합니다.
  3. 인덱스가 .all로 설정되어 있는지 확인합니다. 인덱스가 .all로 설정되어 있지 않으면 OpenShift 시스템 로그만 나열됩니다.
  4. knative-serving 네임스페이스를 사용하여 로그를 필터링합니다. 검색 상자에 서비스 필터를 입력하여 결과를 필터링합니다.

    필터 예제

    kubernetes.namespace_name:default AND kubernetes.labels.serving_knative_dev\/service:{service_name}

    /configuration 또는 /revision을 사용하여 필터링할 수도 있습니다.

  5. 애플리케이션에서 생성한 로그만 표시하려면 kubernetes.container_name:<user_container>를 사용하여 검색 범위를 좁힙니다. 그러지 않으면 큐 프록시의 로그가 표시됩니다.
참고

애플리케이션에서 JSON 기반 구조의 로깅을 사용하면 프로덕션 환경에서 이러한 로그를 빠르게 필터링할 수 있습니다.