로깅 옵션 이해

기본 제공 Red Hat OpenShift 도구 또는 IBM Cloud 통합의 사용 시기를 이해하려면 다음 정보를 검토하십시오.

IBM Cloud Logs

로그 추적, 실시간 문제점 해결, 경보 발행, 로그 아카이브의 실시간 스트리밍을 위한 사용자 정의할 수 있는 사용자 인터페이스

• 스크립트를 통한 클러스터와 신속한 통합
• 클러스터 및 클라우드 제공자 전반에서 집계된 로그
• 선택한 플랜을 기준으로 하는 로그에 대한 히스토리 액세스
• 가용성이 높고 스케일링이 가능하며 업계 보안 표준 준수
• 사용자 액세스 관리를 위해 IBM Cloud IAM과 통합됨

Red Hat OpenShift on IBM Cloud API에서 생성된 클러스터 관리 이벤트를 확인합니다. 이러한 로그에 액세스하려면 IBM Cloud Logs의 인스턴스를 프로비저닝하십시오. 추적할 수 있는 IBM Cloud Kubernetes Service 이벤트의 유형에 대한 자세한 정보는 Activity Tracker 이벤트를 참조하십시오.

기본 제공 Red Hat OpenShift 로깅 도구

Red Hat OpenShift 웹 콘솔에 있는 팟(Pod) 로그의 기본 제공 보기입니다.

• 기본 제공 팟(Pod) 로그는 지속적 스토리지를 사용하도록 구성되지 않았습니다. 로깅 데이터를 백업하고 가용성을 높이려면 클라우드 데이터베이스와 통합해야 하며 로그를 직접 관리해야 합니다.

OpenShift Container Platform(Elasticsearch), Fluentd 및 Kibana(EFK)스택을 구성하려면 클러스터 로깅 오퍼레이터 설치 방법을 참조하십시오. 클러스터 로깅 스택을 실행하려면 작업자 노드에 최소한 4개의 코어 및 32GB의 메모리가 있어야 한다는 점에 유의하십시오.

기본 제공 Red Hat OpenShift 감사 로깅 도구

사용자가 시작한 활동을 모니터하기 위한 API 감사 로깅은 현재 지원되지 않습니다.

로깅 및 모니터링 에이전트를 Cloud Logs로 마이그레이션하기

통합 가시성 CLI 플러그인 ibmcloud ob 및 v2/observe 엔드포인트는 더 이상 지원되지 않습니다. 직접적인 대체 기능은 없지만, 이제 콘솔이나 차트를 Helm 통해 로깅 및 모니터링 통합을 관리할 수 있습니다. 최신 단계: OpenShift 클러스터용 로깅 에이전트 배포 및 Red Hat OpenShift 클러스터 모니터링.

더 이상 ob 플러그인, Terraform 또는 API를 사용하여 클러스터에 통합 가시성 에이전트를 설치하거나 기존 구성을 수정할 수 없습니다. Sysdig 에이전트는 지정된 IBM Cloud Monitoring 인스턴스로 메트릭을 계속 전송합니다.

클러스터 로깅 오퍼레이터 사용

Red Hat OpenShift on IBM Cloud 클러스터에 OpenShift Container Platform 클러스터 로깅 오퍼레이터 및 스택을 배포하려면 Red Hat OpenShift 문서를 참조하십시오. 또한 IBM Cloud Block Storage 스토리지 클래스를 사용하도록 클러스터 로깅 인스턴스를 업데이트해야 합니다.

1. 오퍼레이터를 실행하기 위해 작업자 풀을 준비하십시오.

   1. 최소 4코어, 32GB 메모리 사양의 VPC 또는 클래식 워커 풀을 생성하고, 워커 노드를 3개 설정합니다.
   2. 작업자 풀에 레이블을 지정하십시오.
   3. 다른 워크로드를 이 작업자 풀에서 실행할 수 없도록 작업자 풀을 오염시키십시오.

2. Red Hat OpenShift 클러스터에 액세스하십시오.

3. Red Hat OpenShift 웹 콘솔에서 관리자 관점에서 [ 운영자] > [설치된 운영자 ]를 클릭합니다.

4. 클러스터 로깅을 클릭하십시오.

5. 제공된 API 섹션의 클러스터 로깅 타일에서 인스턴스 작성을 클릭하십시오.

6. Elasticsearch 로그 스토리지의 스토리지 클래스를 gp2에서 다음 스토리지 클래스 중 하나(클러스터 인프라 제공자에 따라 달라짐)로 변경하도록 구성 YAML을 수정하십시오.

   • 클래식 클러스터: ibmc-block-gold
   • VPC 클러스터: ibmc-vpc-block-10iops-tier

   ...
       elasticsearch:
         nodeCount: 3
         redundancyPolicy: SingleRedundancy
         storage:
           storageClassName: ibmc-block-gold #or ibmc-vpc-block-10iops-tier for VPC clusters
           size: 200G
   ...
   

7. 이전에 작성한 작업자 풀 레이블 및 오염에 대한 노드 선택기 및 허용을 포함하도록 구성 YAML을 수정하십시오. 자세한 정보 및 예는 다음 Red Hat OpenShift 문서를 참조하십시오. 예에서는 logging: clo-efk의 레이블 및 허용을 사용합니다.

   • Node 선택기. Elasticsearch(logstore), Kibana(visualization) 및 Fluentd(collector.logs) 팟(Pod)에 노드 선택기를 추가하십시오.

       spec:
       logStore:
         elasticsearch:
           nodeSelector:
             logging: clo-efk
       ...
       visualization:
         kibana:
           nodeSelector:
             logging: clo-efk
       ...
       collection:
         logs:
           fluentd:
             nodeSelector:
               logging: clo-efk
       ```
   * [허용](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/nodes/controlling-pod-placement-onto-nodes-scheduling#nodes-scheduler-taints-tolerations-about_nodes-scheduler-taints-tolerations){: external}. Elasticsearch(`logstore`), Kibana(`visualization`) 및 Fluentd(`collector.logs`) 팟(Pod)에 노드 선택기를 추가하십시오.
   ```yaml {: codeblock}
       spec:
       logStore:
         elasticsearch:
           tolerations:
           - key: app
             value: clo-efk
             operator: "Exists"
             effect: "NoExecute"
       ...
       visualization:
         kibana:
           tolerations:
           - key: app
             value: clo-efk
             operator: "Exists"
             effect: "NoExecute"
       ...
       collection:
         logs:
           fluentd:
             tolerations:
             - key: app
               value: clo-efk
               operator: "Exists"
               effect: "NoExecute"
       ```
   

8. 작성을 클릭하십시오.

9. 오퍼레이터, Elasticsearch, Fluentd 및 Kibana 팟(Pod)이 모두 실행 중인지 확인하십시오.