8.3. 클러스터 로깅


8.3.1. OpenShift Serverless에서 OpenShift Logging 사용

8.3.1.1. Red Hat OpenShift의 로깅 하위 시스템 배포 정보

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

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

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

8.3.1.2. Red Hat OpenShift의 로깅 하위 시스템 배포 및 구성 정보

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

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

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

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

8.3.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
Elasticsearch 스토리지
storageClass namesize 매개변수를 사용하여 Elasticsearch 클러스터의 영구 스토리지 클래스 및 크기를 구성할 수 있습니다. Red Hat OpenShift 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. 분할 복사본이 없습니다. 노드가 다운되거나 실패하는 경우 로그를 사용할 수 없거나 로그가 손실될 수 있습니다.
8.3.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
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 1Gi

8.3.2. Knative Serving 구성 요소의 로그 검색

다음 절차를 사용하여 Knative Serving 구성 요소의 로그를 찾을 수 있습니다.

8.3.2.1. OpenShift 로깅을 사용하여 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에서는 기본적으로 구조화된 로깅을 사용합니다. OpenShift Logging Fluentd 설정을 사용자 정의하여 이러한 로그의 구문 분석을 활성화할 수 있습니다. 이렇게 하면 로그를 더 쉽게 검색할 수 있고 로그 수준에서 필터링하여 문제를 빠르게 확인할 수 있습니다.

8.3.3. Knative Serving 서비스의 로그 찾기

다음 절차를 사용하여 Knative Serving 서비스의 로그를 확인할 수 있습니다.

8.3.3.1. OpenShift Logging을 사용하여 Knative Serving으로 배포한 서비스의 로그 찾기

OpenShift Logging을 사용하면 애플리케이션에서 콘솔에 쓰는 로그가 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 기반 구조의 로깅을 사용하면 프로덕션 환경에서 이러한 로그를 빠르게 필터링할 수 있습니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.