검색

로깅

download PDF
OpenShift Container Platform 4.12

OpenShift Logging 설치, 사용법, 릴리스 정보

Red Hat OpenShift Documentation Team

초록

이 문서에서는 다양한 OpenShift Container Platform 서비스에 대한 로그를 집계하는 OpenShift Logging의 설치, 구성 및 사용 방법을 설명합니다.

1장. 릴리스 노트

1.1. Logging 5.8

참고

로깅은 핵심 OpenShift Container Platform과 별도의 릴리스 주기와 함께 설치 가능한 구성 요소로 제공됩니다. Red Hat OpenShift Container Platform 라이프 사이클 정책은 릴리스 호환성에 대해 간단히 설명합니다.

참고

stable 채널은 최신 로깅 릴리스에 대한 업데이트만 제공합니다. 이전 릴리스에 대한 업데이트를 계속 받으려면 서브스크립션 채널을 stable-x.y 로 변경해야 합니다. 여기서 x.y 는 설치한 로깅 및 마이너 버전을 나타냅니다. 예를 들면 stable-5.7 입니다.

1.1.1. Logging 5.8.5

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.8.5 가 포함되어 있습니다.

1.1.1.1. 버그 수정
  • 이번 업데이트 이전에는 Loki Operator의 ServiceMonitor 구성이 여러 Kubernetes 서비스와 일치하여 Loki Operator의 메트릭이 여러 번 수집될 수 있었습니다. 이번 업데이트를 통해 ServiceMonitor 의 구성은 이제 전용 메트릭 서비스와만 일치합니다. (LOG-5250)
  • 이번 업데이트 이전에는 Red Hat 빌드 파이프라인에서 Loki 빌드의 기존 빌드 세부 정보와 revision, 분기, 버전과 같은 생략된 정보를 사용하지 않았습니다. 이번 업데이트를 통해 Red Hat 빌드 파이프라인에서 Loki 빌드에 이러한 세부 정보를 추가하여 문제를 해결합니다. (LOG-5201)
  • 이번 업데이트 이전에는 Loki Operator에서 LokiStack 이 준비되었는지 확인하기 위해 Pod가 실행 중인지 확인했습니다. 이번 업데이트를 통해 LokiStack 의 준비 상태가 해당 구성 요소의 상태를 반영하도록 Pod가 준비되었는지도 확인합니다. (LOG-5171)
  • 이번 업데이트 이전에는 로그 메트릭에 대한 쿼리를 실행하면 히스토그램에 오류가 발생했습니다. 이번 업데이트를 통해 히스토그램 토글 기능 및 히스토그램이 로그 메트릭에서 작동하지 않기 때문에 히스토그램 토글 기능이 비활성화되고 숨겨집니다. (LOG-5044)
  • 이번 업데이트 이전에는 Loki 및 Elasticsearch 번들에 잘못된 maxOpenShiftVersion 이 있어 IncompatibleOperatorsInstalled 경고가 생성되었습니다. 번들의 4.16을 maxOpenShiftVersion 속성으로 포함하여 이 업데이트를 통해 문제가 해결되었습니다. (LOG-5272)
  • 이번 업데이트 이전에는 빌드 파이프라인에 빌드 날짜에 대한 링커 플래그가 포함되어 있지 않아 Loki 빌드에 buildDategoVersion 의 빈 문자열이 표시되었습니다. 이번 업데이트를 통해 빌드 파이프라인에 누락된 링커 플래그를 추가하면 문제가 해결되었습니다. (LOG-5274)
  • 이번 업데이트 이전에는 LogQL 구문 분석의 버그로 인해 쿼리에서 일부 줄 필터가 남겼습니다. 이번 업데이트를 통해 이제 구문 분석에 원래 쿼리를 변경하지 않고 모든 줄 필터가 포함됩니다. (LOG-5270)
  • 이번 업데이트 이전에는 openshift-operators-redhat 네임스페이스의 Loki Operator ServiceMonitor 에서 인증에 정적 토큰과 CA 파일을 사용하여 ServiceMonitor 구성의 User Workload Monitoring 사양의 Prometheus Operator에 오류가 발생했습니다. 이번 업데이트를 통해 openshift-operators-redhat 네임스페이스의 Loki Operator ServiceMonitor 는 이제 LocalReference 오브젝트의 서비스 계정 토큰 시크릿을 참조합니다. 이 방법을 사용하면 Prometheus Operator의 User Workload Monitoring 사양에서 Loki Operator ServiceMonitor 를 성공적으로 처리할 수 있으므로 Prometheus가 Loki Operator 메트릭을 스크랩할 수 있습니다. (LOG-5240)
1.1.1.2. CVE

1.1.2. Logging 5.8.4

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.8.4 가 포함되어 있습니다.

1.1.2.1. 버그 수정
  • 이번 업데이트 이전에는 개발자 콘솔의 로그에서 현재 네임스페이스를 고려하지 않아 클러스터 전체 로그 액세스 권한이 없는 사용자에게 쿼리 거부가 발생했습니다. 이번 업데이트를 통해 지원되는 모든 OCP 버전은 올바른 네임스페이스를 포함해야 합니다. (LOG-4905)
  • 이번 업데이트 이전에는 Cluster Logging Operator가 기본 로그 출력이 LokiStack인 경우에만 LokiStack 배포를 지원하는 ClusterRoles 를 배포했습니다. 이번 업데이트를 통해 역할은 읽기 및 쓰기의 두 그룹으로 나뉩니다. 쓰기 역할은 이전에 수행하는 데 사용되는 모든 역할과 마찬가지로 기본 로그 스토리지 설정을 기반으로 배포됩니다. 읽기 역할은 로깅 콘솔 플러그인이 활성화되어 있는지 여부에 따라 배포됩니다. (LOG-4987)
  • 이번 업데이트 이전에는 하나의 서비스에서 ownerReferences 를 변경하기 때문에 동일한 입력 수신자 이름을 정의하는 ClusterLogForwarders 가 서비스를 끝없이 조정했습니다. 이번 업데이트를 통해 각 수신자 입력은 < CLF.Name>-<input.Name> 규칙을 사용하여 이름이 지정된 자체 서비스를 갖습니다. (LOG-5009)
  • 이번 업데이트 이전에는 시크릿 없이 cloudwatch로 로그를 전달할 때 ClusterLogForwarder 에서 오류를 보고하지 않았습니다. 이번 업데이트를 통해 시크릿 없이 cloudwatch로 로그를 전달할 때 다음 오류 메시지가 표시됩니다. cloudwatch 출력에 시크릿을 제공해야 합니다. (LOG-5021)
  • 이번 업데이트 이전에는 log_forwarder_input_info애플리케이션,인프라감사 입력 메트릭 포인트가 포함되었습니다. 이번 업데이트를 통해 http 도 지표 지점으로 추가됩니다. (LOG-5043)
1.1.2.2. CVE

1.1.3. Logging 5.8.3

이 릴리스에는 로깅 버그 수정 5.8.3로깅 보안 수정 5.8.3이 포함되어 있습니다.

1.1.3.1. 버그 수정
  • 이번 업데이트 이전에는 사용자 정의 S3 인증 기관을 읽도록 구성된 경우 Loki Operator는 ConfigMap 이름 또는 콘텐츠가 변경된 경우 구성을 자동으로 업데이트하지 않습니다. 이번 업데이트를 통해 Loki Operator에서 ConfigMap에 대한 변경 사항을 조사하고 생성된 구성을 자동으로 업데이트합니다. (LOG-4969)
  • 이번 업데이트 이전에는 유효한 URL 없이 Loki 출력이 구성되어 수집기 Pod가 충돌했습니다. 이번 업데이트를 통해 출력에 URL 검증이 적용되어 문제를 해결합니다. (LOG-4822)
  • 이번 업데이트 이전에는 Cluster Logging Operator가 서비스 계정 전달자 토큰을 사용할 시크릿을 지정하지 않은 출력에 대한 수집기 구성 필드를 생성합니다. 이번 업데이트를 통해 출력에 인증이 필요하지 않아 문제를 해결합니다. (LOG-4962)
  • 이번 업데이트 이전에는 출력의 tls.insecureSkipVerify 필드가 보안을 정의하지 않고 true 값으로 설정되지 않았습니다. 이번 업데이트를 통해 이 값을 설정하는 데 더 이상 시크릿이 필요하지 않습니다. (LOG-4963)
  • 이번 업데이트 이전에는 출력 구성에서 비보안 (HTTP) URL과 TLS 인증의 조합을 허용했습니다. 이번 업데이트를 통해 TLS 인증을 위해 구성된 출력에 보안(HTTPS) URL이 필요합니다. (LOG-4893)
1.1.3.2. CVE

1.1.4. Logging 5.8.2

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.8.2 가 포함되어 있습니다.

1.1.4.1. 버그 수정
  • 이번 업데이트 이전에는 LokiStack 규칙러 Pod에서 교차 Pod 통신에 사용되는 HTTP URL의 IPv6 Pod IP를 포맷하지 않아 Prometheus 호환 API를 통한 규칙 및 경고를 쿼리할 수 없었습니다. 이번 업데이트를 통해 LokiStack 룰러 Pod는 IPv6 포드 IP를 대괄호로 캡슐화하여 문제를 해결합니다. (LOG-4890)
  • 이번 업데이트 이전에는 개발자 콘솔 로그에서 현재 네임스페이스를 고려하지 않아 클러스터 전체 로그 액세스 권한이 없는 사용자에게 쿼리 거부가 발생했습니다. 이번 업데이트를 통해 네임스페이스 포함이 수정되어 문제를 해결합니다. (LOG-4947)
  • 이번 업데이트 이전에는 OpenShift Container Platform 웹 콘솔의 로깅 보기 플러그인에서 사용자 정의 노드 배치 및 허용 오차를 허용하지 않았습니다. 이번 업데이트를 통해 OpenShift Container Platform 웹 콘솔의 로깅 보기 플러그인에 사용자 정의 노드 배치 및 허용 오차가 추가되었습니다. (LOG-4912)
1.1.4.2. CVE

1.1.5. Logging 5.8.1

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.8.1OpenShift Logging 버그 수정 릴리스 5.8.1 Kibana 가 포함되어 있습니다.

1.1.5.1. 기능 개선
1.1.5.1.1. 로그 컬렉션
  • 이번 업데이트를 통해 Vector를 수집기로 구성하는 동안 Red Hat OpenShift Logging Operator에 논리를 추가하여 서비스 계정과 연결된 토큰 대신 시크릿에 지정된 토큰을 사용할 수 있습니다. (LOG-4780)
  • 이번 업데이트를 통해 BoltDB shipper Loki 대시보드의 이름이 Index 대시보드로 변경되었습니다. (LOG-4828)
1.1.5.2. 버그 수정
  • 이번 업데이트 이전에는 롤오버 조건이 충족되지 않은 경우에도 ClusterLogForwarder 에서 JSON 로그의 구문 분석을 활성화한 후 빈 인덱스를 생성했습니다. 이번 업데이트를 통해 write-index 가 비어 있을 때 ClusterLogForwarder 에서 롤오버를 건너뜁니다. (LOG-4452)
  • 이번 업데이트 이전에는 벡터가 기본 로그 수준을 잘못 설정했습니다. 이번 업데이트를 통해 로그 수준 탐지를 위해 정규식 또는 regexp 의 향상된 기능을 개선하여 올바른 로그 수준이 설정됩니다. (LOG-4480)
  • 이번 업데이트 이전에는 인덱스 패턴을 생성하는 프로세스 중에 각 로그 출력의 초기 인덱스에서 기본 별칭이 누락되었습니다. 결과적으로 Kibana 사용자는 OpenShift Elasticsearch Operator를 사용하여 인덱스 패턴을 생성할 수 없었습니다. 이번 업데이트에서는 OpenShift Elasticsearch Operator에 누락된 별칭이 추가되어 문제를 해결합니다. Kibana 사용자는 {app,infra,audit}-000001 인덱스를 포함하는 인덱스 패턴을 생성할 수 있습니다. (LOG-4683)
  • 이번 업데이트 이전에는 IPv6 클러스터에서 Prometheus 서버가 바인딩되어 Fluentd 수집기 Pod가 CrashLoopBackOff 상태에 있었습니다. 이번 업데이트를 통해 수집기는 IPv6 클러스터에서 제대로 작동합니다. (LOG-4706)
  • 이번 업데이트 이전에는 ClusterLogForwarder 가 변경될 때마다 Red Hat OpenShift Logging Operator가 다양한 조정을 수행했습니다. 이번 업데이트를 통해 Red Hat OpenShift Logging Operator는 조정을 트리거한 수집기 데몬 세트의 상태 변경을 무시합니다. (LOG-4741)
  • 이번 업데이트 이전에는 {ibm-power-title} 머신의 Vector 로그 수집기 Pod가 CrashLoopBackOff 상태로 중단되었습니다. 이번 업데이트를 통해 Vector 로그 수집기 Pod가 {ibm-power-title} 아키텍처 시스템에서 성공적으로 시작됩니다. (LOG-4768)
  • 이번 업데이트 이전에는 내부 LokiStack에 대한 레거시 전달자를 사용하여 전달하면 Fluentd 수집기 Pod를 사용하여 SSL 인증서 오류가 발생했습니다. 이번 업데이트를 통해 로그 수집기 서비스 계정은 기본적으로 연결된 토큰과 ca.crt 를 사용하여 인증에 사용됩니다. (LOG-4791)
  • 이번 업데이트 이전에는 내부 LokiStack에 대한 레거시 전달자를 사용하여 전달하면 Vector 수집기 Pod를 사용하여 SSL 인증서 오류가 발생했습니다. 이번 업데이트를 통해 기본적으로 로그 수집기 서비스 계정이 인증에 사용되며 연결된 토큰 및 ca.crt 를 사용합니다. (LOG-4852)
  • 이번 수정 이전에는 자리 표시자에 대해 호스트 또는 여러 호스트를 평가한 후 IPv6 주소가 올바르게 구문 분석되지 않았습니다. 이번 업데이트를 통해 IPv6 주소가 올바르게 구문 분석됩니다. (LOG-4811)
  • 이번 업데이트 이전에는 HTTP 수신자 입력에 대한 감사 권한을 수집하기 위해 ClusterRoleBinding 을 생성해야 했습니다. 이번 업데이트를 통해 끝점이 이미 클러스터 인증 기관에 따라 다르기 때문에 ClusterRoleBinding 을 생성할 필요가 없습니다. (LOG-4815)
  • 이번 업데이트 이전에는 Loki Operator에서 사용자 정의 CA 번들을 룰러 Pod에 마운트하지 않았습니다. 결과적으로 경고 또는 레코딩 규칙을 평가하는 프로세스 중에 오브젝트 스토리지 액세스가 실패했습니다. 이번 업데이트를 통해 Loki Operator는 모든 룰러 Pod에 사용자 정의 CA 번들을 마운트합니다. 규칙자 Pod는 오브젝트 스토리지에서 로그를 다운로드하여 경고 또는 레코딩 규칙을 평가할 수 있습니다. (LOG-4836)
  • 이번 업데이트 이전에는 ClusterLogForwarder 에서 inputs.receiver 섹션을 제거하는 동안 HTTP 입력 서비스 및 관련 보안이 삭제되지 않았습니다. 이번 업데이트를 통해 필요하지 않은 경우 HTTP 입력 리소스가 삭제됩니다. (LOG-4612)
  • 이번 업데이트 이전에는 ClusterLogForwarder 에서 상태에 검증 오류가 표시되었지만 출력 및 파이프라인 상태가 특정 문제를 정확하게 반영하지 않았습니다. 이번 업데이트를 통해 출력, 입력 또는 필터가 잘못 구성된 경우 파이프라인 상태에 검증 실패 이유가 올바르게 표시됩니다. (LOG-4821)
  • 이번 업데이트 이전에는 시간 범위 또는 심각도와 같은 제어를 사용하는 LogQL 쿼리를 변경하면 레이블 matcher Operator가 정규식처럼 정의되었습니다. 이번 업데이트를 통해 쿼리를 업데이트할 때 정규식 Operator가 변경되지 않은 상태로 유지됩니다. (LOG-4841)
1.1.5.3. CVE

1.1.6. Logging 5.8.0

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.8.0OpenShift Logging 버그 수정 릴리스 5.8.0 Kibana 가 포함되어 있습니다.

1.1.6.1. 사용 중단 알림

로깅 5.8에서 Elasticsearch, Fluentd, Kibana는 더 이상 사용되지 않으며 Logging 6.0에서 제거될 예정이며 향후 OpenShift Container Platform 릴리스와 함께 제공될 것으로 예상됩니다. Red Hat은 현재 릴리스 라이프사이클 동안 중요한 CVE 버그 수정 및 이러한 구성 요소에 대한 지원을 제공하지만 이러한 구성 요소는 더 이상 기능 개선 사항을 받지 않습니다. Loki Operator에서 제공하는 Red Hat OpenShift Logging Operator 및 LokiStack에서 제공하는 Vector 기반 수집기는 로그 수집 및 스토리지에 권장되는 Operator입니다. 모든 사용자가 Vector 및 Loki 로그 스택을 채택하도록 권장합니다. 이는 앞으로 개선될 스택이 되기 때문입니다.

1.1.6.2. 기능 개선
1.1.6.2.1. 로그 컬렉션
  • 이번 업데이트를 통해 LogFileMetricExporter는 기본적으로 수집기와 함께 더 이상 배포되지 않습니다. 컨테이너를 실행하여 생성된 로그에서 메트릭을 생성하려면 LogFileMetricExporter CR(사용자 정의 리소스)을 수동으로 생성해야 합니다. LogFileMetricExporter CR을 생성하지 않으면 OpenShift Container Platform 웹 콘솔 대시보드에 Produced LogsNo datapoints found 메시지가 표시될 수 있습니다. (LOG-3819)
  • 이번 업데이트를 통해 모든 네임스페이스에 여러 개의 격리된 ClusterLogForwarder CR(사용자 정의 리소스) 인스턴스를 배포할 수 있습니다. 이를 통해 독립 그룹은 다른 컬렉터 배포에서 구성을 격리하는 동안 원하는 로그를 대상으로 전달할 수 있습니다. (LOG-1343)

    중요

    openshift-logging 네임스페이스 이외의 추가 네임스페이스에서 다중 클러스터 로그 전달을 지원하려면 모든 네임스페이스를 조사하도록 Red Hat OpenShift Logging Operator를 업데이트해야 합니다. 이 기능은 새로운 Red Hat OpenShift Logging Operator 버전 5.8 설치에서 기본적으로 지원됩니다.

  • 이번 업데이트를 통해 흐름 제어 또는 속도 제한 메커니즘을 사용하여 과도한 로그 레코드를 삭제하여 수집하거나 전달할 수 있는 로그 데이터의 볼륨을 제한할 수 있습니다. 입력 제한으로 인해 성능이 좋지 않은 컨테이너가 로깅을 과부하하는 것을 방지하고 출력 제한으로 인해 지정된 데이터 저장소에 전달되는 로그의 비율에 문제가 발생합니다. (LOG-884)
  • 이번 업데이트를 통해 HTTP 연결을 찾고 웹 후크라고도 하는 HTTP 서버로 로그를 수신하도록 로그 수집기를 구성할 수 있습니다. (LOG-4562)
  • 이번 업데이트를 통해 감사 정책을 구성하여 로그 수집기에서 전달하는 Kubernetes 및 OpenShift API 서버 이벤트를 제어할 수 있습니다. (LOG-3982)
1.1.6.2.2. 로그 스토리지
  • 이번 업데이트를 통해 LokiStack 관리자는 네임스페이스에 따라 로그에 대한 액세스 권한을 부여하여 누가 로그에 액세스할 수 있는 사용자를 보다 세밀하게 제어할 수 있습니다. (LOG-3841)
  • 이번 업데이트를 통해 Loki Operator는 LokiStack 배포에 PodDisruptionBudget 구성을 도입하여 ingestion 및 쿼리 경로를 계속 사용하여 OpenShift Container Platform 클러스터를 재시작하는 동안 정상적인 작업을 보장합니다. (LOG-3839)
  • 이번 업데이트를 통해 기본 Affinity 및 anti-Affinity 정책 세트를 적용하여 기존 LokiStack 설치의 안정성이 원활하게 향상됩니다. (LOG-3840)
  • 이번 업데이트를 통해 영역 장애 발생 시 안정성을 높이기 위해 LokiStack에서 영역 인식 데이터 복제를 관리자로 관리할 수 있습니다. (LOG-3266)
  • 이번 업데이트를 통해 몇 가지 워크로드와 작은 수집 볼륨(최대 100GB/일)을 호스팅하는 OpenShift Container Platform 클러스터에 지원되는 새로운 소규모 LokiStack 크기가 1x.extra-tekton가 도입되었습니다. (LOG-4329)
  • 이번 업데이트를 통해 LokiStack 관리자는 공식 Loki 대시보드에 액세스하여 스토리지 성능 및 각 구성 요소의 상태를 검사할 수 있습니다. (LOG-4327)
1.1.6.2.3. 로그 콘솔
  • 이번 업데이트를 통해 Elasticsearch가 기본 로그 저장소인 경우 로깅 콘솔 플러그인을 활성화할 수 있습니다. (LOG-3856)
  • 이번 업데이트를 통해 OpenShift Container Platform 애플리케이션 소유자는 OpenShift Container Platform 버전 4.14 이상의 OpenShift Container Platform 웹 콘솔 개발자 화면에서 애플리케이션 로그 기반 경고에 대한 알림을 수신할 수 있습니다. (LOG-3548)
1.1.6.3. 확인된 문제
  • 현재 Red Hat OpenShift Logging Operator의 버전 5.8로 업그레이드한 후 Splunk 로그 전달이 작동하지 않을 수 있습니다. 이 문제는 OpenSSL 버전 1.1.1에서 버전 3.0.7로 전환하여 발생합니다. 최신 OpenSSL 버전에서는 기본 동작 변경 사항이 있습니다. 여기서 RFC 5746 확장을 노출하지 않으면 TLS 1.2 끝점에 대한 연결이 거부됩니다.

    이 문제를 해결하려면 Splunk HEC(HTTP 이벤트 수집기) 끝점 앞에 있는 TLS 종료 로드 밸런서에서 TLS 1.3 지원을 활성화합니다. Splunk는 타사 시스템이며 Splunk 끝에서 구성해야 합니다.

  • 현재 HTTP/2 프로토콜에서 멀티플렉싱된 스트림을 처리하는 데 결함이 있습니다. 여기서 새로운 멀티플렉션을 반복적으로 요청하고 이를 취소하기 위해 RST_STREAM 프레임을 즉시 보낼 수 있습니다. 이로 인해 서버가 스트림을 설정하고 축소하여 서버 리소스 사용으로 인해 서비스가 거부되었습니다. 현재 이 문제에 대한 해결방법이 없습니다. (LOG-4609)
  • 현재 FluentD를 수집기로 사용할 때 수집기 Pod는 OpenShift Container Platform IPv6 지원 클러스터에서 시작할 수 없습니다. Pod 로그는 fluentd pod [error]: unexpected error_class=SocketError error="getaddrinfo: Name 또는 service notknown 오류를 생성합니다. 현재 이 문제에 대한 해결방법이 없습니다. (LOG-4706)
  • 현재 IPv6 지원 클러스터에서는 로그 경고를 사용할 수 없습니다. 현재 이 문제에 대한 해결방법이 없습니다. (LOG-4709)
  • 현재 cluster-logging-rhel9-operator 에서 필요한 OpenSSL 라이브러리를 사용할 수 없기 때문에 FIPS 지원 클러스터에서 must-gather 는 로그를 수집할 수 없습니다. 현재 이 문제에 대한 해결방법이 없습니다. (LOG-4403)
  • 현재 FIPS 지원 클러스터에 로깅 버전 5.8을 배포할 때 컬렉터 Pod는 시작할 수 없으며 FluentD를 수집기로 사용하는 동안 CrashLoopBackOff 상태에서 멈춥니다. 현재 이 문제에 대한 해결방법이 없습니다. (LOG-3933)
1.1.6.4. CVE

1.2. Logging 5.7

참고

로깅은 핵심 OpenShift Container Platform과 별도의 릴리스 주기와 함께 설치 가능한 구성 요소로 제공됩니다. Red Hat OpenShift Container Platform 라이프 사이클 정책은 릴리스 호환성에 대해 간단히 설명합니다.

참고

stable 채널은 최신 로깅 릴리스에 대한 업데이트만 제공합니다. 이전 릴리스에 대한 업데이트를 계속 받으려면 서브스크립션 채널을 stable-x.y 로 변경해야 합니다. 여기서 x.y 는 설치한 로깅 및 마이너 버전을 나타냅니다. 예를 들면 stable-5.7 입니다.

1.2.1. Logging 5.7.12

이 릴리스에는 OpenShift Logging 버그 수정 5.7.12 가 포함되어 있습니다.

1.2.1.1. 버그 수정
  • 이번 업데이트 이전에는 Loki Operator에서 LokiStack 이 준비되었는지 확인하기 위해 Pod가 실행 중인지 확인했습니다. 이번 업데이트를 통해 LokiStack 의 준비 상태가 해당 구성 요소의 상태를 반영하도록 Pod가 준비되었는지도 확인합니다. (LOG-5172)
  • 이번 업데이트 이전에는 Red Hat 빌드 파이프라인에서 Loki 빌드의 기존 빌드 세부 정보와 revision, 분기, 버전과 같은 생략된 정보를 사용하지 않았습니다. 이번 업데이트를 통해 Red Hat 빌드 파이프라인에서 Loki 빌드에 이러한 세부 정보를 추가하여 문제를 해결합니다. (LOG-5202)
  • 이번 업데이트 이전에는 Loki Operator의 ServiceMonitor 구성이 여러 Kubernetes 서비스와 일치하여 Loki Operator의 메트릭이 여러 번 수집될 수 있었습니다. 이번 업데이트를 통해 ServiceMonitor 의 구성은 이제 전용 메트릭 서비스와만 일치합니다. (LOG-5251)
  • 이번 업데이트 이전에는 빌드 파이프라인에 빌드 날짜에 대한 링커 플래그가 포함되어 있지 않아 Loki 빌드에 buildDategoVersion 의 빈 문자열이 표시되었습니다. 이번 업데이트를 통해 빌드 파이프라인에 누락된 링커 플래그를 추가하면 문제가 해결되었습니다. (LOG-5275)
  • 이번 업데이트 이전에는 openshift-operators-redhat 네임스페이스의 Loki Operator ServiceMonitor 에서 인증에 정적 토큰과 CA 파일을 사용하여 ServiceMonitor 구성의 User Workload Monitoring 사양의 Prometheus Operator에 오류가 발생했습니다. 이번 업데이트를 통해 openshift-operators-redhat 네임스페이스의 Loki Operator ServiceMonitor 는 이제 LocalReference 오브젝트의 서비스 계정 토큰 시크릿을 참조합니다. 이 방법을 사용하면 Prometheus Operator의 User Workload Monitoring 사양에서 Loki Operator ServiceMonitor 를 성공적으로 처리할 수 있으므로 Prometheus가 Loki Operator 메트릭을 스크랩할 수 있습니다. (LOG-5241)
1.2.1.2. CVE

1.2.2. 로깅 5.7.11

이 릴리스에는 로깅 버그 수정 5.7.11 이 포함되어 있습니다.

1.2.2.1. 버그 수정
  • 이번 업데이트 이전에는 사용자 정의 S3 인증 기관을 읽도록 구성된 경우 Loki Operator는 ConfigMap 오브젝트의 이름 또는 콘텐츠가 변경된 경우 구성을 자동으로 업데이트하지 않았습니다. 이번 업데이트를 통해 Loki Operator는 ConfigMap 오브젝트의 변경 사항을 감시하고 생성된 구성을 자동으로 업데이트합니다. (LOG-4968)
1.2.2.2. CVE

1.2.3. Logging 5.7.10

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.7.10 이 포함되어 있습니다.

1.2.3.1. 버그 수정

이번 업데이트 이전에는 LokiStack 규칙러 Pod에서 교차 Pod 통신에 사용되는 HTTP URL의 IPv6 Pod IP를 포맷하지 않아 Prometheus 호환 API를 통한 규칙 및 경고를 쿼리할 수 없었습니다. 이번 업데이트를 통해 LokiStack 룰러 Pod는 IPv6 포드 IP를 대괄호로 캡슐화하여 문제를 해결합니다. (LOG-4891)

1.2.3.2. CVE

1.2.4. Logging 5.7.9

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.7.9 가 포함되어 있습니다.

1.2.4.1. 버그 수정
  • 이번 수정 이전에는 자리 표시자에 대해 호스트 또는 여러 호스트를 평가한 후 IPv6 주소가 올바르게 구문 분석되지 않았습니다. 이번 업데이트를 통해 IPv6 주소가 올바르게 구문 분석됩니다. (LOG-4281)
  • 이번 업데이트 이전에는 IPv4 전용 노드에서 벡터를 시작하지 못했습니다. 결과적으로 다음 오류와 함께 지표 끝점에 대한 리스너를 생성하지 못했습니다. Failed to start Prometheus exporter: TCP bind failed: Address family not supported by protocol (os error 97). 이번 업데이트를 통해 벡터는 IPv4 전용 노드에서 정상적으로 작동합니다. (LOG-4589)
  • 이번 업데이트 이전에는 인덱스 패턴을 생성하는 프로세스 중에 각 로그 출력의 초기 인덱스에서 기본 별칭이 누락되었습니다. 결과적으로 Kibana 사용자는 OpenShift Elasticsearch Operator를 사용하여 인덱스 패턴을 생성할 수 없었습니다. 이번 업데이트에서는 OpenShift Elasticsearch Operator에 누락된 별칭이 추가되어 문제를 해결합니다. Kibana 사용자는 {app,infra,audit}-000001 인덱스를 포함하는 인덱스 패턴을 생성할 수 있습니다. (LOG-4806)
  • 이번 업데이트 이전에는 Loki Operator에서 사용자 정의 CA 번들을 룰러 Pod에 마운트하지 않았습니다. 결과적으로 경고 또는 레코딩 규칙을 평가하는 프로세스 중에 오브젝트 스토리지 액세스가 실패했습니다. 이번 업데이트를 통해 Loki Operator는 모든 룰러 Pod에 사용자 정의 CA 번들을 마운트합니다. 규칙자 Pod는 오브젝트 스토리지에서 로그를 다운로드하여 경고 또는 레코딩 규칙을 평가할 수 있습니다. (LOG-4837)
  • 이번 업데이트 이전에는 시간 범위 또는 심각도와 같은 제어를 사용하여 LogQL 쿼리를 변경하면 정규식처럼 레이블 matcher Operator가 변경되었습니다. 이번 업데이트를 통해 쿼리를 업데이트할 때 정규식 Operator가 변경되지 않은 상태로 유지됩니다. (LOG-4842)
  • 이번 업데이트 이전에는 Vector 수집기 배포가 기본 재시도 및 버퍼링 동작에 의존했습니다. 결과적으로 출력 가용성이 불안정한 경우 전달 파이프라인이 모든 메시지를 전달하려고 백업했습니다. 이번 업데이트를 통해 Vector 수집기 배포는 임계값을 초과한 후 메시지 재시도 및 삭제 메시지 수를 제한합니다. (LOG-4536)
1.2.4.2. CVE

1.2.5. Logging 5.7.8

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.7.8 이 포함되어 있습니다.

1.2.5.1. 버그 수정
  • 이번 업데이트 이전에는 ClusterLogForwarder 사용자 정의 리소스(CR)의 outputRefsinputRefs 매개변수에 동일한 이름을 사용할 때 잠재적인 충돌이 있었습니다. 그 결과 수집기 Pod가 CrashLoopBackOff 상태에 진입했습니다. 이번 업데이트를 통해 출력 라벨에 OUTPUT_ 접두사가 포함되어 출력 라벨과 파이프라인 이름을 구분할 수 있습니다. (LOG-4383)
  • 이번 업데이트 이전에는 JSON 로그 구문 분석기를 구성하는 동안 Cluster Logging Operator에 대한 structuredTypeKey 또는 structuredTypeName 매개변수를 설정하지 않은 경우 잘못된 구성에 대한 경고가 표시되지 않았습니다. 이번 업데이트를 통해 Cluster Logging Operator에 구성 문제를 알려줍니다. (LOG-4441)
  • 이번 업데이트 이전에는 Splunk 출력에 지정된 시크릿에 hecToken 키가 없거나 잘못된 경우 Vector에서 토큰 없이 Splunk로 로그를 전달했기 때문에 유효성 검사가 실패했습니다. 이번 업데이트를 통해 hecToken 키가 없거나 잘못된 경우 A 비어 있지 않은 hecToken 항목과 함께 검증이 실패합니다. (LOG-4580)
  • 이번 업데이트 이전에는 로그의 사용자 정의 시간 범위에서 날짜를 선택하면 웹 콘솔에서 오류가 발생했습니다. 이번 업데이트를 통해 웹 콘솔의 시간 범위 모델에서 날짜를 선택할 수 있습니다. (LOG-4684)
1.2.5.2. CVE

1.2.6. 로깅 5.7.7

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.7.7 이 포함되어 있습니다.

1.2.6.1. 버그 수정
  • 이번 업데이트 이전에는 FluentD가 EventRouter에서 출력하는 로그를 Vector와 다르게 정규화했습니다. 이번 업데이트를 통해 벡터는 일관된 형식으로 로그 레코드를 생성합니다. (LOG-4178)
  • 이번 업데이트 이전에는 최소 버퍼 사용량이 표시되는 것처럼 Cluster Logging Operator가 생성한 지표 대시보드의 FluentD Buffer Availability 그래프에 사용된 쿼리에 오류가 발생했습니다. 이번 업데이트를 통해 그래프에는 최대 버퍼 사용량이 표시되고 이제 FluentD Buffer Usage 로 이름이 변경되었습니다. (LOG-4555)
  • 이번 업데이트 이전에는 IPv6 전용 또는 듀얼 스택 OpenShift Container Platform 클러스터에 LokiStack을 배포하면 LokiStack 멤버 목록 등록이 실패했습니다. 그 결과 배포자 Pod가 크래시 루프에 진입했습니다. 이번 업데이트를 통해 관리자는 lokistack.spec.hashRing.memberlist.enableIPv6: 값을 true 로 설정하여 IPv6를 활성화하여 문제를 해결할 수 있습니다. (LOG-4569)
  • 이번 업데이트 이전에는 로그 수집기가 컨테이너 로그 행을 읽기 위해 기본 구성 설정에 의존했습니다. 그 결과 로그 수집기에서 순환된 파일을 효율적으로 읽지 않았습니다. 이번 업데이트를 통해 로그 수집기에서 순환된 파일을 효율적으로 처리할 수 있는 바이트 읽기 수가 증가합니다. (LOG-4575)
  • 이번 업데이트 이전에는 이벤트 라우터에서 사용되지 않는 메트릭으로 인해 과도한 메모리 사용량으로 인해 컨테이너가 실패했습니다. 이번 업데이트를 통해 사용되지 않은 메트릭을 제거하여 이벤트 라우터의 메모리 사용량이 줄어듭니다. (LOG-4686)
1.2.6.2. CVE

1.2.7. 로깅 5.7.6

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.7.6 이 포함되어 있습니다.

1.2.7.1. 버그 수정
  • 이번 업데이트 이전에는 수집기가 컨테이너 로그 행을 읽기 위해 기본 구성 설정에 의존했습니다. 그 결과 수집기에서 교체된 파일을 효율적으로 읽지 않았습니다. 이번 업데이트를 통해 바이트 읽기 수가 증가하여 수집기에서 순환된 파일을 효율적으로 처리할 수 있습니다. (LOG-4501)
  • 이번 업데이트 이전에는 사용자가 사전 정의된 필터를 사용하여 URL을 붙여넣을 때 일부 필터가 반영되지 않았습니다. 이번 업데이트를 통해 UI는 URL의 모든 필터를 반영합니다. (LOG-4459)
  • 이번 업데이트 이전에는 사용자 정의 라벨을 사용하여 Loki로 전달하면 Fluentd에서 Vector로 전환할 때 오류가 발생했습니다. 이번 업데이트를 통해 Vector 구성은 Fluentd와 동일한 방식으로 라벨을 종료하여 수집기가 레이블을 시작하고 올바르게 처리하도록 합니다. (LOG-4460)
  • 이번 업데이트 이전에는 Observability Logs 콘솔 검색 필드에서 이스케이프해야 하는 특수 문자를 허용하지 않았습니다. 이번 업데이트를 통해 쿼리에서 특수 문자를 올바르게 이스케이프합니다. (LOG-4456)
  • 이번 업데이트 이전에는 Splunk로 로그를 보내는 동안 다음 경고 메시지가 표시 되었습니다. Timestamp를 찾을 수 없었습니다. 이번 업데이트를 통해 변경 사항은 Timestamp를 검색하는 데 사용되는 로그 필드의 이름을 재정의하고 경고 없이 Splunk로 보냅니다. (LOG-4413)
  • 이번 업데이트 이전에는 벡터의 CPU 및 메모리 사용량이 시간이 지남에 따라 증가하고 있었습니다. 이번 업데이트를 통해 이제 지표의 수명을 제한하고 관련 CPU 사용량 및 메모리 풋프린트를 제한하기 위해 Vector 구성에 expire_metrics_secs=60 설정이 포함됩니다. (LOG-4171)
  • 이번 업데이트 이전에는 LokiStack 게이트웨이가 인증된 요청을 매우 광범위하게 캐시했습니다. 이로 인해 잘못된 권한 부여 결과가 발생했습니다. 이번 업데이트를 통해 LokiStack 게이트웨이 캐시는 이 문제를 보다 세분화하여 해결합니다. (LOG-4393)
  • 이번 업데이트 이전에는 Fluentd 런타임 이미지에 런타임 시 필요하지 않은 빌더 툴이 포함되었습니다. 이번 업데이트를 통해 빌더 툴이 제거되어 문제를 해결합니다. (LOG-4467)
1.2.7.2. CVE

1.2.8. 로깅 5.7.4

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.7.4 가 포함되어 있습니다.

1.2.8.1. 버그 수정
  • 이번 업데이트 이전에는 CloudMonitor로 로그를 전달할 때 namespaceUUID 값이 logGroupName 필드에 추가되지 않았습니다. 이번 업데이트를 통해 CloudWatch의 namespaceUUID 값이 포함되므로 CloudWatch의 logGroupNamelogGroupName으로 표시됩니다. vectorcw.b443fb9e-bd4c-4b6a-b9d3-c0097f9ed286. (LOG-2701)
  • 이번 업데이트 이전에는 HTTP를 클러스터 외부 대상으로 전달할 때 프록시 URL에 올바른 인증 정보가 제공되어도 벡터 수집기에서 클러스터 전체 HTTP 프록시에 인증할 수 없었습니다. 이번 업데이트를 통해 Vector 로그 수집기에서 클러스터 전체 HTTP 프록시를 인증할 수 있습니다. (LOG-3381)
  • 이번 업데이트 이전에는 이 구성이 지원되지 않기 때문에 Fluentd 수집기가 Splunk를 사용하여 출력으로 구성된 경우 Operator가 실패했습니다. 이번 업데이트를 통해 구성 검증에서 지원되지 않는 출력을 거부하여 문제를 해결합니다. (LOG-4237)
  • 이번 업데이트 이전에는 AWS Cloudwatch 로그의 TLS 구성에서 Vector 수집기가 활성화된 = true 값을 업데이트하고 GCP Stackdriver로 인해 구성 오류가 발생했습니다. 이번 업데이트를 통해 이러한 출력에 대해 enabled = true 값이 제거되어 문제를 해결합니다. (LOG-4242)
  • 이번 업데이트 이전에는 로그에서 Vector 수집기에서 다음과 같은 오류 메시지를 패닉시킬 수 있습니다. '모든 분기에서 'vector-worker' panicked가 비활성화되고 다른 분기', src/kubernetes/reflector.rs:26:9 입니다. 이번 업데이트를 통해 오류가 해결되었습니다. (LOG-4275)
  • 이번 업데이트 이전에는 Operator가 해당 테넌트에 대한 추가 옵션으로 구성된 경우 Loki Operator의 문제로 인해 애플리케이션 테넌트에 대한 alert-manager 구성이 사라졌습니다. 이번 업데이트를 통해 생성된 Loki 구성에 사용자 정의 및 자동 생성 구성이 모두 포함됩니다. (LOG-4361)
  • 이번 업데이트 이전에는 AWS Cloudwatch 전달에서 STS를 사용하여 여러 역할을 인증하는 데 사용된 경우 최근 업데이트로 인해 인증 정보가 고유하지 않았습니다. 이번 업데이트를 통해 STS 역할 및 정적 인증 정보의 여러 조합을 다시 사용하여 AWS Cloudwatch로 인증할 수 있습니다. (LOG-4368)
  • 이번 업데이트 이전에는 Loki에서 활성 스트림의 레이블 값을 필터링하지만 중복은 제거되지 않아 Grafana의 Label Browser를 사용할 수 없게 되었습니다. 이번 업데이트를 통해 Loki는 활성 스트림에 대해 중복 레이블 값을 필터링하여 문제를 해결합니다. (LOG-4389)
  • ClusterLogForwarder 사용자 정의 리소스(CR)에 지정된 name 필드가 없는 파이프라인은 OpenShift Logging 5.7으로 업그레이드한 후 작업을 중지했습니다. 이번 업데이트를 통해 오류가 해결되었습니다. (LOG-4120)
1.2.8.2. CVE

1.2.9. 로깅 5.7.3

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.7.3 이 포함되어 있습니다.

1.2.9.1. 버그 수정
  • 이번 업데이트 이전에는 OpenShift Container Platform 웹 콘솔 내에서 로그를 볼 때 캐시된 파일로 인해 데이터가 새로 고쳐지지 않았습니다. 이번 업데이트를 통해 부트스트랩 파일이 캐시되지 않아 문제를 해결합니다. (LOG-4100)
  • 이번 업데이트 이전에는 Loki Operator가 구성 문제를 확인하기 어려운 방식으로 오류를 재설정했습니다. 이번 업데이트를 통해 구성 오류가 해결될 때까지 오류가 지속됩니다. (LOG-4156)
  • 이번 업데이트 이전에는 RulerConfig CR(사용자 정의 리소스)을 변경한 후 LokiStack 룰러가 다시 시작되지 않았습니다. 이번 업데이트를 통해 Loki Operator는 RulerConfig CR을 업데이트한 후 룰러 Pod를 다시 시작합니다. (LOG-4161)
  • 이번 업데이트 이전에는 입력 일치 레이블 값에 ClusterLogForwarder 내에 / 문자가 포함된 경우 벡터 수집기가 예기치 않게 종료되었습니다. 이번 업데이트에서는 match 레이블을 quoting하여 수집기가 로그를 시작하고 수집할 수 있도록 하여 문제를 해결합니다. (LOG-4176)
  • 이번 업데이트 이전에는 LokiStack CR이 테넌트 제한을 정의했지만 글로벌 제한이 아닌 경우 Loki Operator가 예기치 않게 종료되었습니다. 이번 업데이트를 통해 Loki Operator는 글로벌 제한 없이 LokiStack CR을 처리하여 문제를 해결할 수 있습니다. (LOG-4198)
  • 이번 업데이트 이전에는 제공된 개인 키가 암호로 보호되는 경우 Fluentd에서 Elasticsearch 클러스터에 로그를 보내지 않았습니다. 이번 업데이트를 통해 Elasticsearch와의 연결을 설정할 때 Fluentd가 암호로 보호된 개인 키를 올바르게 처리합니다. (LOG-4258)
  • 이번 업데이트 이전에는 네임스페이스가 8,000개 이상인 클러스터로 인해 네임스페이스 목록이 http.max_header_size 설정보다 크므로 Elasticsearch가 쿼리를 거부했습니다. 이번 업데이트를 통해 헤더 크기의 기본값이 증가하여 문제를 해결합니다. (LOG-4277)
  • 이번 업데이트 이전에는 ClusterLogForwarder CR 내에 / 문자가 포함된 라벨 값으로 인해 수집기가 예기치 않게 종료되었습니다. 이번 업데이트를 통해 슬래시가 밑줄로 교체되어 문제를 해결합니다. (LOG-4095)
  • 이번 업데이트 이전에는 관리되지 않는 상태로 설정된 경우 Cluster Logging Operator가 예기치 않게 종료되었습니다. 이번 업데이트를 통해 ClusterLogForwarder CR 조정을 시작하기 전에 ClusterLogging 리소스가 올바른 관리 상태에 있는지 확인하고 문제를 해결합니다. (LOG-4177)
  • 이번 업데이트 이전에는 OpenShift Container Platform 웹 콘솔 내에서 로그를 볼 때 히스토그램을 통해 드래그하여 시간 범위를 선택하면 Pod 세부 정보 내부의 집계된 로그 뷰에서 작동하지 않았습니다. 이번 업데이트를 통해 이 뷰의 히스토그램을 드래그하여 시간 범위를 선택할 수 있습니다. (LOG-4108)
  • 이번 업데이트 이전에는 OpenShift Container Platform 웹 콘솔 내에서 로그를 볼 때 30초 이상 시간 초과를 쿼리합니다. 이번 업데이트를 통해 configmap/logging-view-plugin에 시간 초과 값을 구성할 수 있습니다. (LOG-3498)
  • 이번 업데이트 이전에는 OpenShift Container Platform 웹 콘솔 내에서 로그를 볼 때 사용 가능한 추가 옵션을 클릭하면 처음 클릭할 때만 더 많은 로그 항목이 로드되었습니다. 이번 업데이트를 통해 각 클릭마다 더 많은 항목이 로드됩니다. (OU-188)
  • 이번 업데이트 이전에는 OpenShift Container Platform 웹 콘솔 내에서 로그를 볼 때 streaming 옵션을 클릭하면 실제 로그를 표시하지 않고 streaming 로그만 표시됩니다. 이번 업데이트를 통해 메시지와 로그 스트림이 모두 올바르게 표시됩니다. (OU-166)
1.2.9.2. CVE

1.2.10. 로깅 5.7.2

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.7.2 가 포함되어 있습니다.

1.2.10.1. 버그 수정
  • 이번 업데이트 이전에는 보류 중인 종료자가 있기 때문에 openshift-logging 네임스페이스를 직접 삭제할 수 없었습니다. 이번 업데이트를 통해 종료자가 더 이상 사용되지 않으므로 네임스페이스를 직접 삭제할 수 있습니다. (LOG-3316)
  • 이번 업데이트 이전에는 OpenShift Container Platform 설명서에 따라 변경된 경우 run.sh 스크립트에서 잘못된 chunk_limit_size 값을 표시했습니다. 그러나 환경 변수 $BUFFER_SIZE_LIMIT 를 통해 chunk_limit_size 를 설정할 때 스크립트에 올바른 값이 표시되었습니다. 이번 업데이트를 통해 이제 run.sh 스크립트에서 두 시나리오에 올바른 chunk_limit_size 값을 일관되게 표시합니다. (LOG-3330)
  • 이번 업데이트 이전에는 OpenShift Container Platform 웹 콘솔의 로깅 보기 플러그인에서 사용자 정의 노드 배치 또는 허용 오차를 허용하지 않았습니다. 이번 업데이트에서는 로깅 보기 플러그인에 대한 노드 배치 및 허용 오차를 정의하는 기능이 추가되었습니다. (LOG-3749)
  • 이번 업데이트 이전에는 Fluentd HTTP 플러그인을 통해 DataDog에 로그를 보낼 때 Cluster Logging Operator에 Unsupported Media Type 예외가 발생했습니다. 이번 업데이트를 통해 사용자는 HTTP 헤더 Content-Type을 구성하여 로그 전달을 위해 콘텐츠 유형을 원활하게 할당할 수 있습니다. 제공된 값은 플러그인 내의 content_type 매개변수에 자동으로 할당되어 로그 전송에 성공합니다. (LOG-3784)
  • 이번 업데이트 이전에는 ClusterLogForwarder CR(사용자 정의 리소스)에서 detectMultilineErrors 필드가 true 로 설정된 경우 PHP 다중 줄 오류가 별도의 로그 항목으로 기록되어 스택 추적이 여러 메시지에 분할되었습니다. 이번 업데이트를 통해 PHP에 대한 다중 줄 오류 탐지가 활성화되어 전체 스택 추적이 단일 로그 메시지에 포함됩니다. (LOG-3878)
  • 이번 업데이트 이전에는 이름에 공간이 포함된 ClusterLogForwarder 파이프라인으로 인해 Vector 수집기 Pod가 지속적으로 충돌했습니다. 이번 업데이트를 통해 파이프라인 이름의 모든 공백, 대시(-) 및 점(.)이 밑줄(_)으로 교체됩니다. (LOG-3945)
  • 이번 업데이트 이전에는 log_forwarder_output 지표에 http 매개변수가 포함되지 않았습니다. 이번 업데이트에서는 누락된 매개변수가 메트릭에 추가되었습니다. (LOG-3997)
  • 이번 업데이트 이전에는 콜론으로 종료될 때 Fluentd에서 일부 다중 줄 JavaScript 클라이언트 예외를 식별하지 못했습니다. 이번 업데이트를 통해 Fluentd 버퍼 이름 앞에 밑줄이 표시되어 문제를 해결합니다. (LOG-4019)
  • 이번 업데이트 이전에는 페이로드의 키와 일치하는 Kafka 출력 항목에 기록하도록 로그 전달을 구성할 때 오류로 인해 로그가 삭제되었습니다. 이번 업데이트를 통해 Fluentd의 버퍼 이름 앞에 밑줄이 지정되어 문제를 해결합니다.(LOG-4027)
  • 이번 업데이트 이전에는 LokiStack 게이트웨이에서 사용자의 액세스 권한을 적용하지 않고 네임스페이스의 레이블 값을 반환했습니다. 이번 업데이트를 통해 LokiStack 게이트웨이는 값 요청에 레이블을 지정하여 문제를 해결합니다. (LOG-4049)
  • 이번 업데이트 이전에는 tls.insecureSkipVerify 옵션이 true 로 설정된 경우 Cluster Logging Operator API에 시크릿에서 제공할 인증서가 필요했습니다. 이번 업데이트를 통해 Cluster Logging Operator API에서 이러한 경우 시크릿에서 더 이상 인증서를 제공할 필요가 없습니다. Operator의 CR에 다음 구성이 추가되었습니다.

    tls.verify_certificate = false
    tls.verify_hostname = false

    (LOG-3445)

  • 이번 업데이트 이전에는 LokiStack 경로 구성으로 인해 30초 이상 실행되는 쿼리가 시간 초과되었습니다. 이번 업데이트를 통해 LokiStack 글로벌 및 테넌트별 쿼리Timeout 설정은 경로 시간 초과 설정에 영향을 미치므로 문제를 해결합니다. (LOG-4052)
  • 이번 업데이트 이전에는 collection.type 기본값을 제거하기 전에 수정되어 Operator에서 더 이상 리소스, 노드 선택, 허용 오차에 대해 더 이상 사용되지 않는 사양을 준수하지 않았습니다. 이번 업데이트에서는 컬렉션보다 collection.logs 사양을 항상 선호하도록 Operator 동작을 수정합니다. 이는 기본 필드와 더 이상 사용되지 않는 필드를 모두 사용하여 허용되는 이전 동작과 다르지만, collection.type 이 채워지면 더 이상 사용되지 않는 필드는 무시됩니다. (LOG-4185)
  • 이번 업데이트 이전에는 출력에 브로커 URL이 지정되지 않은 경우 벡터 로그 수집기에서 여러 Kafka 브로커로 로그를 전달하기 위한 TLS 구성을 생성하지 않았습니다. 이번 업데이트를 통해 여러 브로커에 대해 TLS 구성이 적절하게 생성됩니다. (LOG-4163)
  • 이번 업데이트 이전에는 Kafka로의 로그 전달을 위해 암호를 활성화하는 옵션을 사용할 수 없었습니다. 이 제한은 민감한 정보를 잠재적으로 노출할 수 있으므로 보안 위험이 발생했습니다. 이번 업데이트를 통해 이제 Kafka로 로그 전달을 위해 암호를 활성화할 수 있는 원활한 옵션이 제공됩니다. (LOG-3314)
  • 이번 업데이트 이전에는 Vector 로그 수집기에서 발신 TLS 연결에 대한 tlsSecurityProfile 설정을 준수하지 않았습니다. 이번 업데이트 후 벡터는 TLS 연결 설정을 적절하게 처리합니다. (LOG-4011)
  • 이번 업데이트 이전에는 log_forwarder_output_info 메트릭에 사용 가능한 모든 출력 유형이 포함되지 않았습니다. 이번 업데이트를 통해 메트릭에는 이전에 누락된 Splunk 및 Google Cloud Logging 데이터가 포함되어 있습니다. (LOG-4098)
  • 이번 업데이트 이전에는 follow_inodestrue 로 설정된 경우 Fluentd 수집기가 파일 교체 시 충돌할 수 있었습니다. 이번 업데이트를 통해 follow_inodes 설정이 수집기가 충돌하지 않습니다. (LOG-4151)
  • 이번 업데이트 이전에는 Fluentd 수집기에서 해당 파일이 추적되는 방식으로 모니터링해야 하는 파일을 잘못 닫을 수 있었습니다. 이번 업데이트를 통해 추적 매개변수가 수정되었습니다. (LOG-4149)
  • 이번 업데이트 이전에는 Vector 수집기로 로그를 전달하고 ClusterLogForwarder 인스턴스 감사,애플리케이션 또는 인프라에서 파이프라인 이름을 지정하여 수집기 로그에서 다음 오류와 함께 수집기 Pod가 CrashLoopBackOff 상태를 유지했습니다.

    ERROR vector::cli: Configuration error. error=redefinition of table transforms.audit for key transforms.audit

    이번 업데이트 후 파이프라인 이름은 예약된 입력 이름과 충돌하지 않으며 파이프라인의 이름을 audit,application 또는 infrastructure 로 지정할 수 있습니다. (LOG-4218)

  • 이번 업데이트 이전에는 Vector 수집기를 사용하여 로그를 syslog 대상으로 전달하고 addLogSource 플래그를 true 로 설정할 때 namespace_name=, container_name=, pod_name= 이라는 전달된 메시지에 다음과 같은 빈 필드가 추가되었습니다. 이번 업데이트를 통해 이러한 필드는 더 이상 저널 로그에 추가되지 않습니다. (LOG-4219)
  • 이번 업데이트 이전에는 structuredTypeKey 를 찾을 수 없고 structuredTypeName 이 지정되지 않은 경우 로그 메시지가 구조화된 오브젝트로 계속 구문 분석되었습니다. 이번 업데이트를 통해 로그 구문 분석이 예상대로 수행됩니다. (LOG-4220)
1.2.10.2. CVE

1.2.11. 로깅 5.7.1

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.7.1 가 포함되어 있습니다.

1.2.11.1. 버그 수정
  • 이번 업데이트 이전에는 Cluster Logging Operator Pod 로그 내에 다양한 주의 메시지가 있으면 로그 가독성이 감소하고 중요한 시스템 이벤트를 식별하는 데 어려움이 발생했습니다. 이번 업데이트를 통해 Cluster Logging Operator Pod 로그 내에서 noisy 메시지를 크게 줄임으로써 문제가 해결됩니다. (LOG-3482)
  • 이번 업데이트 이전에는 사용자 정의 리소스가 다른 값을 사용한 경우에도 API 서버에서 CollectorSpec.Type 필드의 값을 벡터 로 재설정합니다. 이번 업데이트에서는 CollectorSpec.Type 필드의 기본값을 제거하여 이전 동작을 복원합니다. (LOG-4086)
  • 이번 업데이트 이전에는 로그 히스토그램을 클릭하고 끌어서 OpenShift Container Platform 웹 콘솔에서 시간 범위를 선택할 수 없었습니다. 이번 업데이트를 통해 클릭 및 드래그를 사용하여 시간 범위를 성공적으로 선택할 수 있습니다. (LOG-4501)
  • 이번 업데이트 이전에는 OpenShift Container Platform 웹 콘솔의 리소스 표시 링크를 클릭하면 적용되지 않았습니다. 이번 업데이트를 통해 "Forwarded Resources" 링크의 기능을 수정하여 각 로그 항목에 대한 리소스 표시를 전환하여 문제가 해결됩니다. (LOG-3218)
1.2.11.2. CVE

1.2.12. Logging 5.7.0

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.7.0 이 포함되어 있습니다.

1.2.12.1. 기능 개선

이번 업데이트를 통해 로깅을 활성화하여 여러 줄 예외를 감지하고 단일 로그 항목으로 재조정할 수 있습니다.

로깅을 사용하여 다중 줄 예외를 감지하고 단일 로그 항목으로 재조정할 수 있도록 하려면 ClusterLogForwarder 사용자 정의 리소스(CR)에 값이 truedetectMultilineErrors 필드가 포함되어 있는지 확인합니다.

1.2.12.2. 확인된 문제

없음.

1.2.12.3. 버그 수정
  • 이번 업데이트 이전에는 CloudEventStack의 게이트웨이 구성 요소에 대한 nodeSelector 속성이 노드 예약에 영향을 미치지 않았습니다. 이번 업데이트를 통해 nodeSelector 특성이 예상대로 작동합니다. (LOG-3713)
1.2.12.4. CVE

1.3. 로깅 5.6

참고

로깅은 핵심 OpenShift Container Platform과 별도의 릴리스 주기와 함께 설치 가능한 구성 요소로 제공됩니다. Red Hat OpenShift Container Platform 라이프 사이클 정책은 릴리스 호환성에 대해 간단히 설명합니다.

참고

stable 채널은 최신 로깅 릴리스에 대한 업데이트만 제공합니다. 이전 릴리스에 대한 업데이트를 계속 받으려면 서브스크립션 채널을 stable-x.y 로 변경해야 합니다. 여기서 x.y 는 설치한 로깅 및 마이너 버전을 나타냅니다. 예를 들면 stable-5.7 입니다.

1.3.1. Logging 5.6.17

이 릴리스에는 OpenShift Logging 버그 수정 5.6.17이 포함되어 있습니다.

1.3.1.1. 버그 수정
  • 이번 업데이트 이전에는 Red Hat 빌드 파이프라인에서 Loki 빌드의 기존 빌드 세부 정보와 revision, 분기, 버전과 같은 생략된 정보를 사용하지 않았습니다. 이번 업데이트를 통해 Red Hat 빌드 파이프라인에서 Loki 빌드에 이러한 세부 정보를 추가하여 문제를 해결합니다. (LOG-5203)
  • 이번 업데이트 이전에는 Loki Operator의 ServiceMonitor 구성이 여러 Kubernetes 서비스와 일치하여 Loki Operator의 메트릭이 여러 번 수집될 수 있었습니다. 이번 업데이트를 통해 ServiceMonitor 설정은 이제 전용 메트릭 서비스와만 일치합니다. (LOG-5252)
  • 이번 업데이트 이전에는 빌드 파이프라인에 빌드 날짜에 대한 링커 플래그가 포함되어 있지 않아 Loki 빌드에 buildDategoVersion 의 빈 문자열이 표시되었습니다. 이번 업데이트를 통해 빌드 파이프라인에 누락된 링커 플래그를 추가하면 문제가 해결되었습니다. (LOG-5276)
  • 이번 업데이트 이전에는 openshift-operators-redhat 네임스페이스의 Loki Operator ServiceMonitor 에서 인증에 정적 토큰과 CA 파일을 사용하여 ServiceMonitor 구성의 User Workload Monitoring 사양의 Prometheus Operator에 오류가 발생했습니다. 이번 업데이트를 통해 openshift-operators-redhat 네임스페이스의 Loki Operator ServiceMonitor 는 이제 LocalReference 오브젝트의 서비스 계정 토큰 시크릿을 참조합니다. 이 방법을 사용하면 Prometheus Operator의 User Workload Monitoring 사양에서 Loki Operator ServiceMonitor 를 성공적으로 처리할 수 있으므로 Prometheus가 Loki Operator 메트릭을 스크랩할 수 있습니다. (LOG-5242)
1.3.1.2. CVE

1.3.2. 로깅 5.6.16

이 릴리스에는 로깅 버그 수정 5.6.16이 포함되어 있습니다.

1.3.2.1. 버그 수정
  • 이번 업데이트 이전에는 사용자 정의 S3 인증 기관을 읽도록 구성된 경우 Loki Operator는 ConfigMap 이름 또는 콘텐츠가 변경된 경우 구성을 자동으로 업데이트하지 않습니다. 이번 업데이트를 통해 Loki Operator에서 ConfigMap에 대한 변경 사항을 조사하고 생성된 구성을 자동으로 업데이트합니다. (LOG-4967)
1.3.2.2. CVE

1.3.3. 로깅 5.6.15

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.6.15 가 포함되어 있습니다.

1.3.3.1. 버그 수정

이번 업데이트 이전에는 LokiStack 규칙러 Pod에서 교차 Pod 통신에 사용되는 HTTP URL의 IPv6 Pod IP를 포맷하지 않아 Prometheus 호환 API를 통한 규칙 및 경고를 쿼리할 수 없었습니다. 이번 업데이트를 통해 LokiStack 룰러 Pod는 IPv6 포드 IP를 대괄호로 캡슐화하여 문제를 해결합니다. (LOG-4892)

1.3.3.2. CVE

1.3.4. Logging 5.6.14

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.6.14 가 포함되어 있습니다.

1.3.4.1. 버그 수정
  • 이번 업데이트 이전에는 인덱스 패턴을 생성하는 프로세스 중에 각 로그 출력의 초기 인덱스에서 기본 별칭이 누락되었습니다. 결과적으로 Kibana 사용자는 OpenShift Elasticsearch Operator를 사용하여 인덱스 패턴을 생성할 수 없었습니다. 이번 업데이트에서는 OpenShift Elasticsearch Operator에 누락된 별칭이 추가되어 문제를 해결합니다. Kibana 사용자는 {app,infra,audit}-000001 인덱스를 포함하는 인덱스 패턴을 생성할 수 있습니다. (LOG-4807)
  • 이번 업데이트 이전에는 Loki Operator에서 사용자 정의 CA 번들을 룰러 Pod에 마운트하지 않았습니다. 결과적으로 경고 또는 레코딩 규칙을 평가하는 프로세스 중에 오브젝트 스토리지 액세스가 실패했습니다. 이번 업데이트를 통해 Loki Operator는 모든 룰러 Pod에 사용자 정의 CA 번들을 마운트합니다. 규칙자 Pod는 오브젝트 스토리지에서 로그를 다운로드하여 경고 또는 레코딩 규칙을 평가할 수 있습니다. (LOG-4838)
1.3.4.2. CVE

1.3.5. Logging 5.6.13

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.6.13 이 포함되어 있습니다.

1.3.5.1. 버그 수정

없음.

1.3.5.2. CVE

1.3.6. 로깅 5.6.12

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.6.12 가 포함되어 있습니다.

1.3.6.1. 버그 수정
  • 이번 업데이트 이전에는 IPv6 전용 또는 듀얼 스택 OpenShift Container Platform 클러스터에 LokiStack을 배포하면 LokiStack 멤버 목록 등록이 실패했습니다. 그 결과 배포자 Pod가 크래시 루프에 진입했습니다. 이번 업데이트를 통해 관리자는 lokistack.spec.hashRing.memberlist.enableIPv6: 값을 true 로 설정하여 IPv6를 활성화하여 문제를 해결할 수 있습니다. 현재 IPv6 지원 클러스터에서는 로그 경고를 사용할 수 없습니다. (LOG-4570)
  • 이번 업데이트 이전에는 최소 버퍼 사용량이 표시되는 것처럼 Cluster Logging Operator가 생성한 지표 대시보드의 FluentD Buffer Availability 그래프에 사용된 쿼리에 오류가 발생했습니다. 이번 업데이트를 통해 그래프에는 최대 버퍼 사용량이 표시되고 이제 FluentD Buffer Usage 로 이름이 변경되었습니다. (LOG-4579)
  • 이번 업데이트 이전에는 이벤트 라우터에서 사용되지 않는 메트릭으로 인해 과도한 메모리 사용량으로 인해 컨테이너가 실패했습니다. 이번 업데이트를 통해 사용되지 않은 메트릭을 제거하여 이벤트 라우터의 메모리 사용량이 줄어듭니다. (LOG-4687)
1.3.6.2. CVE

1.3.7. 로깅 5.6.11

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.6.11 이 포함되어 있습니다.

1.3.7.1. 버그 수정
  • 이번 업데이트 이전에는 LokiStack 게이트웨이가 인증된 요청을 매우 광범위하게 캐시했습니다. 이로 인해 잘못된 권한 부여 결과가 발생했습니다. 이번 업데이트를 통해 LokiStack 게이트웨이 캐시는 이 문제를 보다 세분화하여 해결합니다. (LOG-4435)
1.3.7.2. CVE

1.3.8. 로깅 5.6.9

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.6.9 가 포함되어 있습니다.

1.3.8.1. 버그 수정
  • 이번 업데이트 이전에는 AWS Cloudwatch 전달에서 STS를 사용하여 여러 역할을 인증하는 데 사용된 경우 최근 업데이트로 인해 인증 정보가 고유하지 않았습니다. 이번 업데이트를 통해 STS 역할 및 정적 인증 정보의 여러 조합을 다시 사용하여 AWS Cloudwatch로 인증할 수 있습니다. (LOG-4084)
  • 이번 업데이트 이전에는 로그에서 Vector 수집기에서 다음과 같은 오류 메시지를 패닉시킬 수 있습니다. '모든 분기에서 'vector-worker' panicked가 비활성화되고 다른 분기', src/kubernetes/reflector.rs:26:9 입니다. 이번 업데이트를 통해 오류가 해결되었습니다. (LOG-4276)
  • 이번 업데이트 이전에는 Loki에서 활성 스트림의 레이블 값을 필터링하지만 중복은 제거되지 않아 Grafana의 Label Browser를 사용할 수 없게 되었습니다. 이번 업데이트를 통해 Loki는 활성 스트림에 대해 중복 레이블 값을 필터링하여 문제를 해결합니다. (LOG-4390)
1.3.8.2. CVE

1.3.9. 로깅 5.6.8

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.6.8 이 포함되어 있습니다.

1.3.9.1. 버그 수정
  • 이번 업데이트 이전에는 입력 일치 레이블 값에 ClusterLogForwarder 내에 / 문자가 포함된 경우 벡터 수집기가 예기치 않게 종료되었습니다. 이번 업데이트에서는 match 레이블을 quoting하여 수집기가 로그를 시작하고 수집할 수 있도록 하여 문제를 해결합니다. (LOG-4091)
  • 이번 업데이트 이전에는 OpenShift Container Platform 웹 콘솔 내에서 로그를 볼 때 사용 가능한 추가 옵션을 클릭하면 처음 클릭할 때만 더 많은 로그 항목이 로드되었습니다. 이번 업데이트를 통해 각 클릭마다 더 많은 항목이 로드됩니다. (OU-187)
  • 이번 업데이트 이전에는 OpenShift Container Platform 웹 콘솔 내에서 로그를 볼 때 streaming 옵션을 클릭하면 실제 로그를 표시하지 않고 streaming 로그만 표시됩니다. 이번 업데이트를 통해 메시지와 로그 스트림이 모두 올바르게 표시됩니다. (OU-189)
  • 이번 업데이트 이전에는 Loki Operator가 구성 문제를 확인하기 어려운 방식으로 오류를 재설정했습니다. 이번 업데이트를 통해 구성 오류가 해결될 때까지 오류가 지속됩니다. (LOG-4158)
  • 이번 업데이트 이전에는 네임스페이스가 8,000개 이상인 클러스터로 인해 네임스페이스 목록이 http.max_header_size 설정보다 크므로 Elasticsearch가 쿼리를 거부했습니다. 이번 업데이트를 통해 헤더 크기의 기본값이 증가하여 문제를 해결합니다. (LOG-4278)
1.3.9.2. CVE

1.3.10. Logging 5.6.5

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.6.5 가 포함되어 있습니다.

1.3.10.1. 버그 수정
  • 이번 업데이트 이전에는 템플릿 정의로 인해 Elasticsearch에서 일부 레이블과 namespace_labels를 인덱싱할 수 없어 데이터 수집 문제가 발생했습니다. 이번 업데이트를 통해 수정으로 레이블의 점과 슬래시가 교체되어 문제를 효과적으로 해결하기 위해 레이블의 점과 슬래시가 교체됩니다. (LOG-3419)
  • 이번 업데이트 이전에는 OpenShift 웹 콘솔의 로그 페이지가 10.0.0.1Stack에 연결하지 못하면 일반적인 오류 메시지가 표시되어 추가 컨텍스트 또는 문제 해결 제안이 제공되지 않았습니다. 이번 업데이트를 통해 보다 구체적인 세부 정보와 문제 해결을 위한 권장 사항을 포함하도록 오류 메시지가 개선되었습니다. (LOG-3750)
  • 이번 업데이트 이전에는 시간 범위 형식이 검증되지 않아 사용자 지정 날짜 범위를 선택하는 데 오류가 발생했습니다. 이번 업데이트를 통해 이제 시간 형식이 검증되어 사용자가 유효한 범위를 선택할 수 있습니다. 잘못된 시간 범위 형식을 선택하면 사용자에게 오류 메시지가 표시됩니다. (LOG-3583)
  • 이번 업데이트 이전에는 표현식의 길이가 5120자를 초과하지 않더라도, 대부분의 경우 로그를 검색할 때 쿼리가 실패했습니다. 이번 업데이트를 통해 쿼리 권한 부여 라벨 일치자가 최적화되어 문제를 해결합니다. (LOG-3480)
  • 이번 업데이트 이전에는 CloudEvent Operator에서 개인 IP에 멤버 목록을 사용할 때 모든 구성 요소를 배치하기에 충분한 멤버 목록 구성을 생성하지 못했습니다. 이번 업데이트를 통해 생성된 구성에 공개된 포트가 포함되어 모든 구성 요소를 성공적으로 조회할 수 있습니다. (LOG-4008)
1.3.10.2. CVE

1.3.11. Logging 5.6.4

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.6.4 가 포함되어 있습니다.

1.3.11.1. 버그 수정
  • 이번 업데이트 이전에는 로그 저장소로 ScanSettingStack이 배포된 경우 CloudEvent Pod에서 생성한 로그가 수집되어 stack으로 전송되었습니다. 이번 업데이트를 통해 CloudEvent에서 생성된 로그는 컬렉션에서 제외되며 저장되지 않습니다. (LOG-3280)
  • 이번 업데이트 이전에는 OpenShift 웹 콘솔의 로그 페이지에 있는 쿼리 편집기가 비어 있으면 드롭다운 메뉴가 채워지지 않았습니다. 이번 업데이트를 통해 빈 쿼리를 시도하면 오류 메시지가 표시되고 드롭다운 메뉴가 예상대로 채워집니다. (LOG-3454)
  • 이번 업데이트 이전에는 tls.insecureSkipVerify 옵션이 true 로 설정되면 Cluster Logging Operator가 잘못된 구성을 생성했습니다. 결과적으로 Operator는 인증서 검증을 건너뛰려고 할 때 Elasticsearch에 데이터를 보내지 못했습니다. 이번 업데이트를 통해 tls.insecureSkipVerify 이 활성화된 경우에도 Cluster Logging Operator에서 올바른 TLS 구성을 생성합니다. 결과적으로 인증서 검증을 건너뛰는 경우에도 데이터를 Elasticsearch로 성공적으로 전송할 수 있습니다. (LOG-3475)
  • 이번 업데이트 이전에는 구조화된 구문 분석이 활성화되고 메시지가 여러 대상으로 전달되면 깊은 복사되지 않았습니다. 이로 인해 구조화된 메시지를 포함하여 수신된 로그 중 일부가 생성되었지만 다른 로그는 그렇지 않았습니다. 이번 업데이트를 통해 JSON 구문 분석 전에 구성 생성이 깊은 복사 메시지로 수정되었습니다. 결과적으로 여러 대상으로 전달되는 경우에도 수신된 모든 메시지에 구조화된 메시지가 포함됩니다. (LOG-3640)
  • 이번 업데이트 이전에는 컬렉션 필드에 {} 이 포함된 경우 Operator가 충돌할 수 있습니다. 이번 업데이트를 통해 Operator는 이 값을 무시하여 Operator가 중단 없이 원활하게 실행할 수 있습니다. (LOG-3733)
  • 이번 업데이트 이전에는 CloudEventStack의 게이트웨이 구성 요소에 대한 nodeSelector 속성이 적용되지 않았습니다. 이번 업데이트를 통해 nodeSelector 특성이 예상대로 작동합니다. (LOG-3783)
  • 이번 업데이트 이전에는 정적 ScanSettingStack 멤버 목록 구성은 개인 IP 네트워크에만 의존했습니다. 결과적으로 OpenShift Container Platform 클러스터 Pod 네트워크가 공용 IP 범위로 구성되면 CloudEventStack Pod가 크래시 루프가 발생했습니다. 이번 업데이트를 통해 이제 ScanSettingStack 관리자에게 memberlist 구성에 Pod 네트워크를 사용하는 옵션이 있습니다. 이렇게 하면 OpenShift Container Platform 클러스터 pod 네트워크가 공용 IP 범위로 구성되면 이 문제를 해결하고 stack Pod가 크래시 루프 상태가 되지 않습니다. (LOG-3814)
  • 이번 업데이트 이전에는 tls.insecureSkipVerify 필드가 true 로 설정된 경우 Cluster Logging Operator가 잘못된 구성을 생성했습니다. 결과적으로 Operator는 인증서 검증을 생략할 때 Elasticsearch에 데이터를 보내지 못했습니다. 이번 업데이트를 통해 tls.insecureSkipVerify 이 활성화된 경우에도 Operator에서 올바른 TLS 구성을 생성합니다. 결과적으로 인증서 검증을 건너뛰는 경우에도 데이터를 Elasticsearch로 성공적으로 전송할 수 있습니다. (LOG-3838)
  • 이번 업데이트 이전에는 Elasticsearch Operator 없이 CLO(Cluster Logging Operator)를 설치한 경우 CLO Pod에 Elasticsearch 삭제와 관련된 오류 메시지가 계속 표시되었습니다. 이번 업데이트를 통해 이제 CLO에서 오류 메시지를 표시하기 전에 추가 검사를 수행합니다. 결과적으로 Elasticsearch 삭제와 관련된 오류 메시지가 Elasticsearch Operator가 없으면 더 이상 표시되지 않습니다. (LOG-3763)
1.3.11.2. CVE

1.3.12. Logging 5.6.3

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.6.3 이 포함되어 있습니다.

1.3.12.1. 버그 수정
  • 이번 업데이트 이전에는 Operator에서 게이트웨이 테넌트 시크릿 정보를 구성 맵에 저장했습니다. 이번 업데이트를 통해 Operator는 이 정보를 시크릿에 저장합니다. (LOG-3717)
  • 이번 업데이트 이전에는 Fluentd 수집기에서 /var/log/auth-server/audit.log 에 저장된 OAuth 로그인 이벤트를 캡처하지 않았습니다. 이번 업데이트를 통해 Fluentd는 이러한 OAuth 로그인 이벤트를 캡처하여 문제를 해결합니다. (LOG-3729)
1.3.12.2. CVE

1.3.13. Logging 5.6.2

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.6.2 가 포함되어 있습니다.

1.3.13.1. 버그 수정
  • 이번 업데이트 이전에는 systemd 로그의 우선 순위에 따라 수집기에서 수준 필드를 올바르게 설정하지 않았습니다. 이번 업데이트를 통해 수준 필드가 올바르게 설정됩니다. (LOG-3429)
  • 이번 업데이트 이전에는 Operator가 OpenShift Container Platform 4.12 이상에서 비호환 경고가 잘못 생성되었습니다. 이번 업데이트를 통해 Operator max OpenShift Container Platform 버전 값이 수정되어 문제를 해결합니다. (LOG-3584)
  • 이번 업데이트 이전에는 output 값이 defaultClusterLogForwarder CR(사용자 정의 리소스)을 생성하면 오류가 발생하지 않았습니다. 이번 업데이트를 통해 이 값이 유효하지 않음을 알리는 오류 경고가 적절하게 생성됩니다. (LOG-3437)
  • 이번 업데이트 이전에는 ClusterLogForwarder CR(사용자 정의 리소스)에 하나의 출력이 기본으로 설정된 여러 파이프라인이 구성된 경우 수집기 Pod가 다시 시작됩니다. 이번 업데이트를 통해 출력 검증 논리가 수정되어 문제를 해결합니다. (LOG-3559)
  • 이번 업데이트 이전에는 생성 후 수집기 Pod가 다시 시작됩니다. 이번 업데이트를 통해 배포된 수집기가 자체적으로 다시 시작되지 않습니다. (LOG-3608)
  • 이번 업데이트 이전에는 패치 릴리스가 카탈로그에서 이전 버전의 Operator를 제거했습니다. 이로 인해 이전 버전을 설치할 수 없습니다. 이번 업데이트에서는 동일한 마이너 버전의 이전 릴리스가 카탈로그에 남아 있도록 번들 구성을 변경합니다. (LOG-3635)
1.3.13.2. CVE

1.3.14. Logging 5.6.1

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.6.1 이 포함되어 있습니다.

1.3.14.1. 버그 수정
  • 이번 업데이트 이전에는 보존이 활성 상태일 때 querier와의 통신에서 TLS 인증서 오류를 보고합니다. 이번 업데이트를 통해 compactor 및 querier는 더 이상 HTTP를 통해 잘못 통신하지 않습니다. (LOG-3494)
  • 이번 업데이트 이전에는 로키스 Operator에서 LokiStack CR의 상태 설정을 재시도하지 않아 오래된 상태 정보가 발생했습니다. 이번 업데이트를 통해 Operator는 충돌 시 상태 정보 업데이트를 다시 시도합니다. (LOG-3496)
  • 이번 업데이트 이전에는 kube-apiserver-operator Operator가 Webhook 유효성을 검사할 때 Loki Operator Webhook 서버에서 TLS 오류가 발생했습니다. 이번 업데이트를 통해 Loki Operator Webhook PKI는 OLM(Operator Lifecycle Manager)에서 관리하며 문제를 해결합니다. (LOG-3510)
  • 이번 업데이트 이전에는 LokiStack Gateway Labels Enforcer에서 부울 표현식과 결합된 라벨 필터를 사용할 때 유효한 LogQL 쿼리에 대한 구문 분석 오류가 발생했습니다. 이번 업데이트를 통해 LokiStack LogQL 구현에서는 부울 표현식이 있는 라벨 필터를 지원하고 문제를 해결합니다. (LOG-3441), (LOG-3397)
  • 이번 업데이트 이전에는 여러 라벨 키에 동일한 접두사와 일부 키가 포함된 경우 Elasticsearch에 작성된 레코드가 실패했습니다. 이번 업데이트를 통해 밑줄이 레이블 키의 점을 교체하여 문제를 해결합니다. (LOG-3463)
  • 이번 업데이트 이전에는 OpenShift Container Platform 콘솔과 logging-view-plugin 간의 비호환성으로 인해 OpenShift Container Platform 4.10 클러스터에 Red Hat OpenShift Logging Operator를 사용할 수 없었습니다. 이번 업데이트를 통해 플러그인이 OpenShift Container Platform 4.10 관리 콘솔과 올바르게 통합됩니다. (LOG-3447)
  • 이 업데이트 이전에는 ClusterLogForwarder 사용자 정의 리소스의 조정이 기본 로그 저장소를 참조하는 파이프라인의 성능이 저하된 상태를 잘못 보고했습니다. 이번 업데이트를 통해 파이프라인이 올바르게 검증됩니다. (LOG-3477)
1.3.14.2. CVE

1.3.15. Logging 5.6.0

이 릴리스에는 OpenShift Logging 릴리스 5.6 이 포함되어 있습니다.

1.3.15.1. 사용 중단 알림

버전 5.6에서 Fluentd는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 제공하지 않으며 제거됩니다. Fluentd 대신 Vector를 사용할 수 있습니다.

1.3.15.2. 기능 개선
  • 이번 업데이트를 통해 로깅은 OpenShift Container Platform 클러스터 전체 암호화 정책을 준수합니다. (로그-895)
  • 이번 업데이트를 통해 RokiStack 사용자 정의 리소스를 통해 테넌트별, 스트림별, 글로벌 정책 보존 정책을 우선 순위에 따라 선언할 수 있습니다. (LOG-2695)
  • 이번 업데이트를 통해 Splunk는 로그 전달에 사용할 수 있는 출력 옵션입니다. (LOG-2913)
  • 이번 업데이트를 통해 Vector가 Fluentd를 기본 수집기로 대체합니다. (로그-2222)
  • 이번 업데이트를 통해 Developer 역할은 OpenShift Container Platform 4.11 이상을 실행하는 클러스터의 로그 콘솔 플러그인 내에서 할당된 프로젝트별 워크로드 로그에 액세스할 수 있습니다. (LOG-3388)
  • 이번 업데이트를 통해 모든 소스의 로그에 Operator가 배포된 클러스터의 고유 식별자인 openshift.cluster_id 필드가 포함됩니다. 다음 명령을 사용하여 clusterID 값을 볼 수 있습니다.

    $ oc get clusterversion/version -o jsonpath='{.spec.clusterID}{"\n"}'

    (LOG-2715)

1.3.15.3. 확인된 문제
  • 이번 업데이트 이전에는 여러 라벨 키에 동일한 접두사와 일부 키가 포함된 경우 Elasticsearch에서 로그를 거부합니다 . 이로 인해 레이블 키의 를 _ 로 교체하여 Elasticsearch의 제한이 수정되었습니다 . 이 문제를 해결하려면 오류를 유발하는 라벨을 제거하거나 라벨에 네임스페이스를 추가합니다. (LOG-3463)
1.3.15.4. 버그 수정
  • 이번 업데이트 이전에는 Kibana 사용자 정의 리소스를 삭제한 경우 OpenShift Container Platform 웹 콘솔에 Kibana에 대한 링크가 계속 표시됩니다. 이번 업데이트를 통해 Kibana 사용자 정의 리소스를 제거하면 해당 링크도 제거됩니다. (LOG-2993)
  • 이번 업데이트 이전에는 사용자가 액세스할 수 있는 네임스페이스의 애플리케이션 로그를 볼 수 없었습니다. 이번 업데이트를 통해 Loki Operator는 클러스터 역할 및 클러스터 역할 바인딩을 자동으로 생성하여 사용자가 애플리케이션 로그를 읽을 수 있습니다. (로그-3072)
  • 이번 업데이트 이전에는 Operator에서 LokiStack을 기본 로그 스토리지로 사용할 때 ClusterLogForwarder 사용자 정의 리소스에 정의된 모든 사용자 정의 출력을 제거했습니다. 이번 업데이트를 통해 Operator는 ClusterLogForwarder 사용자 정의 리소스를 처리할 때 기본 출력과 사용자 정의 출력을 병합합니다. (로그-3090)
  • 이번 업데이트 이전에는 CA 키를 로키에 마운트하기 위해 볼륨 이름으로 사용되었으며 CA 키에 점과 같은 비 조정 문자가 포함된 경우 오류 상태가 발생했습니다. 이번 업데이트를 통해 볼륨 이름이 문제를 해결하는 내부 문자열로 표준화됩니다. (LOG-3331)
  • 이번 업데이트 이전에는 LokiStack 사용자 정의 리소스 정의에 설정된 기본값으로 인해 Replication ECDHE가 1인 1 이 없이 로키스Stack 인스턴스를 생성할 수 없었습니다. 이번 업데이트를 통해 Operator는 사용된 크기의 실제 값을 설정합니다. (LOG-3296)
  • 이번 업데이트 이전에는 structuredTypeKey 또는 structuredTypeName 값을 정의하지 않고 JSON 구문 분석이 활성화된 경우 Vector에서 message 필드를 구문 분석했습니다. 이번 업데이트를 통해 Elasticsearch에 구조화된 로그를 작성할 때 structuredTypeKey 또는 structuredTypeName 에 값이 필요합니다. (LOG-3195)
  • 이번 업데이트 이전에는 Elasticsearch Operator의 보안 생성 구성 요소가 내부 보안을 지속적으로 수정했습니다. 이번 업데이트를 통해 기존 보안이 올바르게 처리됩니다. (LOG-3161)
  • 이번 업데이트 이전에는 Elasticsearch 또는 Kibana 배포에 상태가 변경된 동안 Operator에서 제거 및 수집기 데몬 세트를 다시 생성하는 루프를 입력할 수 있었습니다. 이번 업데이트를 통해 Operator 상태 처리의 수정으로 문제가 해결됩니다. (LOG-3157)
  • 이번 업데이트 이전에는 Kibana에 24h OAuth 쿠키 만료 시간이 고정되어 있었기 때문에 accessTokenInactivityTimeout 필드가 24h 보다 낮은 값으로 설정될 때마다 Kibana에서 401 오류가 발생했습니다. 이번 업데이트를 통해 Kibana의 OAuth 쿠키 만료 시간이 기본값인 24h 값을 사용하여 accessTokenInactivityTimeout 과 동기화됩니다. (LOG-3129)
  • 이번 업데이트 이전에는 리소스 조정을 위한 Operator 일반 패턴이 생성 후 지속적인 HTTP 409 응답을 가져오기 또는 업데이트하기 전에 생성을 시도하는 것이었습니다. 이번 업데이트를 통해 Operator는 먼저 오브젝트를 검색하고 오브젝트가 누락되었거나 지정되지 않은 경우에만 오브젝트를 생성하거나 업데이트합니다. (LOG-2919)
  • 이번 업데이트 이전에는 Fluentd의 .level 및'.structure.level' 필드에 다른 값이 포함될 수 있습니다. 이번 업데이트를 통해 값은 각 필드에 대해 동일합니다. (LOG-2819)
  • 이번 업데이트 이전에는 Operator에서 신뢰할 수 있는 CA 번들 채우기를 기다리지 않고 번들이 업데이트되면 수집기를 두 번째로 배포했습니다. 이번 업데이트를 통해 Operator는 번들이 수집기 배포를 계속하기 전에 채워졌는지 여부를 간략하게 기다립니다. (LOG-2789)
  • 이번 업데이트 이전에는 지표를 검토할 때 로깅 Telemetry 정보가 두 번 표시되었습니다. 이번 업데이트를 통해 로깅 Telemetry 정보가 예상대로 표시됩니다. (로그-2315)
  • 이번 업데이트 이전에는 JSON 구문 분석 추가를 활성화한 후 Fluentd Pod 로그에 경고 메시지가 표시되었습니다. 이번 업데이트를 통해 해당 경고 메시지가 표시되지 않습니다. (로그-1806)
  • 이번 업데이트 이전에는 oc 에 캐시를 빌드하는 데 쓰기 권한이 있는 폴더가 필요하므로 must-gather 스크립트가 완료되지 않았습니다. 이번 업데이트를 통해 oc 는 폴더에 대한 쓰기 권한이 있고 must-gather 스크립트가 성공적으로 완료됩니다. (LOG-3446)
  • 이번 업데이트 이전에는 로그 수집기 SCC를 클러스터의 다른 SCC로 대체하여 컬렉터를 사용할 수 없게 됩니다. 이번 업데이트에서는 로그 수집기 SCC의 우선 순위를 설정하여 다른 것보다 우선합니다. (LOG-3235)
  • 이번 업데이트 이전에는 벡터가 필드 시퀀스 가 누락되었으며 실제 나노초 부족을 처리하는 방법으로 fluentd에 추가되었습니다. 이번 업데이트를 통해 openshift.sequence 필드가 이벤트 로그에 추가되었습니다. (LOG-3106)
1.3.15.5. CVE

1.4. logging 5.5

참고

로깅은 핵심 OpenShift Container Platform과 별도의 릴리스 주기와 함께 설치 가능한 구성 요소로 제공됩니다. Red Hat OpenShift Container Platform 라이프 사이클 정책은 릴리스 호환성에 대해 간단히 설명합니다.

1.4.1. Logging 5.5.18

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.18 이 포함되어 있습니다.

1.4.1.1. 버그 수정

없음.

1.4.1.2. CVE

1.4.2. 로깅 5.5.17

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.17 이 포함되어 있습니다.

1.4.2.1. 버그 수정
  • 이번 업데이트 이전에는 이벤트 라우터에서 사용되지 않는 메트릭으로 인해 과도한 메모리 사용량으로 인해 컨테이너가 실패했습니다. 이번 업데이트를 통해 사용되지 않은 메트릭을 제거하여 이벤트 라우터의 메모리 사용량이 줄어듭니다. (LOG-4688)
1.4.2.2. CVE

1.4.3. 로깅 5.5.16

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.16 이 포함되어 있습니다.

1.4.3.1. 버그 수정
  • 이번 업데이트 이전에는 LokiStack 게이트웨이가 인증된 요청을 매우 광범위하게 캐시했습니다. 이로 인해 잘못된 권한 부여 결과가 발생했습니다. 이번 업데이트를 통해 LokiStack 게이트웨이 캐시는 이 문제를 보다 세분화하여 해결합니다. (LOG-4434)
1.4.3.2. CVE

1.4.4. 로깅 5.5.14

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.14 가 포함되어 있습니다.

1.4.4.1. 버그 수정
  • 이번 업데이트 이전에는 로그에서 Vector 수집기에서 다음과 같은 오류 메시지를 패닉시킬 수 있습니다. '모든 분기에서 'vector-worker' panicked가 비활성화되고 다른 분기', src/kubernetes/reflector.rs:26:9 입니다. 이번 업데이트를 통해 벡터 수집기에 오류가 표시되지 않습니다. (LOG-4279)
1.4.4.2. CVE

1.4.5. 로깅 5.5.13

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.13 이 포함되어 있습니다.

1.4.5.1. 버그 수정

없음.

1.4.5.2. CVE

1.4.6. 로깅 5.5.12

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.12 가 포함되어 있습니다.

1.4.6.1. 버그 수정

없음.

1.4.6.2. CVE

1.4.7. 로깅 5.5.11

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.11 이 포함되어 있습니다.

1.4.7.1. 버그 수정
  • 이번 업데이트 이전에는 로그 히스토그램을 클릭하고 끌어서 OpenShift Container Platform 웹 콘솔에서 시간 범위를 선택할 수 없었습니다. 이번 업데이트를 통해 클릭 및 드래그를 사용하여 시간 범위를 성공적으로 선택할 수 있습니다. (LOG-4102)
  • 이번 업데이트 이전에는 OpenShift Container Platform 웹 콘솔의 리소스 표시 링크를 클릭하면 적용되지 않았습니다. 이번 업데이트를 통해 리소스 표시 링크의 기능을 수정하여 각 로그 항목에 대한 리소스 표시를 전환하여 문제가 해결됩니다. (LOG-4117)
1.4.7.2. CVE

1.4.8. Logging 5.5.10

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.10 이 포함되어 있습니다.

1.4.8.1. 버그 수정
  • 이번 업데이트 이전에는 OpenShift 웹 콘솔의 로깅 보기 플러그인에 연결할 수 없는 경우 오류 텍스트만 표시되었습니다. 이번 업데이트 후 플러그인에 연결할 수 없는stack을 수정하는 방법에 대한 세부 사항이 포함된 적절한 오류 메시지가 표시됩니다. (LOG-2874)
1.4.8.2. CVE

1.4.9. Logging 5.5.9

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.9 가 포함되어 있습니다.

1.4.9.1. 버그 수정
  • 이번 업데이트 이전에는 Fluentd 수집기의 문제로 인해 /var/log/auth-server/audit.log 에 저장된 OAuth 로그인 이벤트가 캡처되지 않았습니다. 이로 인해 OAuth 서비스에서 로그인 이벤트가 불완전해졌습니다. 이번 업데이트를 통해 Fluentd 수집기는 이제 예상대로 /var/log/auth-server/audit.log 에 저장된 항목을 포함하여 OAuth 서비스에서 모든 로그인 이벤트를 캡처하여 이 문제를 해결합니다.https://issues.redhat.com/browse/LOG-3730
  • 이번 업데이트 이전에는 구조화된 구문 분석이 활성화되고 메시지가 여러 대상으로 전달되면 깊은 복사되지 않았습니다. 이로 인해 구조화된 메시지를 포함하여 수신된 로그 중 일부가 생성되었지만 다른 로그는 그렇지 않았습니다. 이번 업데이트를 통해 JSON 구문 분석 전에 구성 생성이 깊은 복사 메시지로 수정되었습니다. 결과적으로 여러 대상으로 전달되는 경우에도 수신된 모든 로그에 구조화된 메시지가 포함됩니다.(LOG-3767).
1.4.9.2. CVE

1.4.10. Logging 5.5.8

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.8 이 포함되어 있습니다.

1.4.10.1. 버그 수정
  • 이번 업데이트 이전에는 수집기가 수준 필드를 설정하는 방법에 오류가 있기 때문에 systemd 로그에서 priority 필드가 누락되었습니다. 이번 업데이트를 통해 이러한 필드가 올바르게 설정되어 문제를 해결합니다. (LOG-3630)
1.4.10.2. CVE

1.4.11. Logging 5.5.7

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.7 이 포함되어 있습니다.

1.4.11.1. 버그 수정
  • 이번 업데이트 이전에는 LokiStack Gateway Labels Enforcer에서 부울 표현식과 결합된 라벨 필터를 사용할 때 유효한 LogQL 쿼리에 대한 구문 분석 오류가 발생했습니다. 이번 업데이트를 통해 LokiStack LogQL 구현에서는 부울 표현식이 있는 라벨 필터를 지원하고 문제를 해결합니다. (LOG-3534)
  • 이번 업데이트 이전에는 ClusterLogForwarder CR(사용자 정의 리소스)에서 syslog 출력의 TLS 인증 정보를 Fluentd에 전달하지 않아 전송 중에 오류가 발생했습니다. 이번 업데이트를 통해 인증 정보가 Fluentd에 올바르게 전달되어 문제를 해결합니다. (LOG-3533)
1.4.11.2. CVE

CVE-2021-46848CVE-2022-3821CVE-2022-35737CVE-2022-42010CVE-2022-42011CVE-2022-42898CVE-2022-43680

1.4.12. 로깅 5.5.6

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.6 이 포함되어 있습니다.

1.4.12.1. 버그 수정
  • 이번 업데이트 이전에는 Pod 보안 승인 컨트롤러가 openshift-logging 네임스페이스에 라벨 podSecurityLabelSync = true 를 추가했습니다. 이로 인해 지정된 보안 레이블을 덮어쓰고 결과적으로 Collector Pod가 시작되지 않았습니다. 이번 업데이트를 통해 podSecurityLabelSync = false 레이블은 보안 라벨을 유지합니다. 수집기 Pod는 예상대로 배포됩니다. (LOG-3340)
  • 이번 업데이트 이전에는 Operator가 클러스터에서 활성화되지 않은 경우에도 콘솔 보기 플러그인을 설치했습니다. 이로 인해 Operator가 충돌했습니다. 이번 업데이트를 통해 클러스터의 계정에 콘솔 보기가 활성화되어 있지 않으면 Operator가 정상적으로 작동하고 콘솔 보기를 설치하지 않습니다. (LOG-3407)
  • 이번 업데이트 이전에는 Elasticsearch 배포 상태를 업데이트하지 않는 경우 Red Hat Elasticsearch Operator 가 배포되지 않은 경우 Operator가 충돌하는 회귀를 지원하기 위한 사전 수정입니다. 이번 업데이트를 통해 해당 수정 사항이 복원되어 Operator가 안정적이지만 보고된 상태와 관련된 이전 문제가 다시 도입되었습니다. (LOG-3428)
  • 이번 업데이트 이전에는 Loki Operator가 선택한 스택 크기에 관계없이 LokiStack 게이트웨이의 복제본 하나를 배포했습니다. 이번 업데이트를 통해 선택한 크기에 따라 복제본 수가 올바르게 구성됩니다. (로그-3478)
  • 이번 업데이트 이전에는 여러 라벨 키에 동일한 접두사와 일부 키가 포함된 경우 Elasticsearch에 작성된 레코드가 실패했습니다. 이번 업데이트를 통해 밑줄이 레이블 키의 점을 교체하여 문제를 해결합니다. (LOG-3341)
  • 이번 업데이트 이전에는 로깅 보기 플러그인에 특정 버전의 OpenShift Container Platform에 대한 호환되지 않는 기능이 포함되어 있었습니다. 이번 업데이트를 통해 플러그인의 올바른 릴리스 스트림이 문제를 해결합니다. (로그-3467)
  • 이번 업데이트 이전에는 ClusterLogForwarder 사용자 정의 리소스의 조정이 하나 이상의 파이프라인의 성능 저하 상태를 잘못 보고하여 수집기 Pod가 8-10초 마다 다시 시작됩니다. 이번 업데이트를 통해 ClusterLogForwarder 사용자 정의 리소스 프로세스를 올바르게 조정하여 문제를 해결합니다. (LOG-3469)
  • 이를 변경하기 전에 ClusterLogForwarder 사용자 정의 리소스의 outputDefaults 필드에 대한 사양이 선언된 모든 Elasticsearch 출력 유형에 설정을 적용합니다. 이 변경으로 인해 설정이 기본 관리 Elasticsearch 저장소에 구체적으로 적용되는 개선 사양과 일치하도록 동작이 수정되었습니다. (LOG-3342)
  • 이번 업데이트 이전에는 OpenShift CLI(oc)에 캐시를 빌드할 수 있는 쓰기 권한이 있는 폴더가 필요하므로 OpenShift CLI(oc) must-gather 스크립트가 완료되지 않았습니다. 이번 업데이트를 통해 OpenShift CLI(oc)에 폴더에 대한 쓰기 권한이 있으며 must-gather 스크립트가 성공적으로 완료됩니다. (LOG-3472)
  • 이번 업데이트 이전에는 Loki Operator 웹 후크 서버에서 TLS 오류가 발생했습니다. 이번 업데이트를 통해 Loki Operator webhook PKI는 Operator Lifecycle Manager의 동적 웹 후크 관리에서 이 문제를 해결합니다. (LOG-3511)
1.4.12.2. CVE

1.4.13. 로깅 5.5.5

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.5 가 포함되어 있습니다.

1.4.13.1. 버그 수정
  • 이번 업데이트 이전에는 Kibana에 24h OAuth 쿠키 만료 시간이 고정되어 있었기 때문에 accessTokenInactivityTimeout 필드가 24h 보다 낮은 값으로 설정될 때마다 Kibana에서 401 오류가 발생했습니다. 이번 업데이트를 통해 Kibana의 OAuth 쿠키 만료 시간이 기본값인 24h 값을 사용하여 accessTokenInactivityTimeout 과 동기화됩니다. (LOG-3305)
  • 이번 업데이트 이전에는 structuredTypeKey 또는 structuredTypeName 값을 정의하지 않고 JSON 구문 분석이 활성화된 경우 Vector에서 message 필드를 구문 분석했습니다. 이번 업데이트를 통해 Elasticsearch에 구조화된 로그를 작성할 때 structuredTypeKey 또는 structuredTypeName 에 값이 필요합니다. (LOG-3284)
  • 이번 업데이트 이전에는 이 경고 표현식에서 반환된 라벨 세트에 카디널리티 문제가 있을 때 FluentdQueueLengthIncreasing 경고가 실행되지 않을 수 있었습니다. 이번 업데이트에서는 경고에 필요한 레이블만 포함하도록 라벨을 줄입니다. (LOG-3226)
  • 이번 업데이트 이전에는 로키가 연결이 끊긴 클러스터의 외부 스토리지에 도달할 수 있는 기능을 지원하지 않았습니다. 이번 업데이트를 통해 프록시 환경 변수 및 프록시 신뢰할 수 있는 CA 번들이 컨테이너 이미지에 포함되어 이러한 연결을 지원합니다. (LOG-2860)
  • 이번 업데이트 이전에는 OpenShift Container Platform 웹 콘솔 사용자가 로키에 대한 CA 인증서가 포함된 ConfigMap 오브젝트를 선택할 수 없어 CA 없이 Pod가 작동할 수 없었습니다. 이번 업데이트를 통해 웹 콘솔 사용자는 구성 맵을 선택하여 문제를 해결할 수 있습니다. (LOG-3310)
  • 이번 업데이트 이전에는 CA 키를 로키에 마운트하기 위해 볼륨 이름으로 사용되었으며 CA 키에 비 조정 문자(예: dots)가 포함된 경우 오류 상태가 발생했습니다. 이번 업데이트를 통해 볼륨 이름이 문제를 해결하는 내부 문자열로 표준화됩니다. (LOG-3332)
1.4.13.2. CVE

1.4.14. 로깅 5.5.4

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.4 가 포함되어 있습니다.

1.4.14.1. 버그 수정
  • 이번 업데이트 이전에는 로깅 보기 플러그인의 쿼리 구문 분석기에 있는 오류로 인해 쿼리에 중괄호 {} 가 포함되어 있는 경우 로그 쿼리의 일부가 사라졌습니다. 이로 인해 쿼리가 유효하지 않아 유효한 쿼리에 대해 오류가 반환되었습니다. 이번 업데이트를 통해 구문 분석기는 이러한 쿼리를 올바르게 처리합니다. (로그-3042)
  • 이번 업데이트 이전에는 Elasticsearch 또는 Kibana 배포에 상태가 변경된 동안 Operator에서 제거 및 수집기 데몬 세트를 다시 생성하는 루프를 입력할 수 있었습니다. 이번 업데이트를 통해 Operator 상태 처리의 수정으로 문제가 해결됩니다. (로그-3049)
  • 이번 업데이트 이전에는 Vector의 수집기 구현을 지원하기 위해 경고가 구현되지 않았습니다. 이 변경으로 벡터 경고가 추가되고 선택한 수집기 구현에 따라 별도의 경고를 배포합니다. (LOG-3127)
  • 이번 업데이트 이전에는 Elasticsearch Operator의 보안 생성 구성 요소가 내부 보안을 지속적으로 수정했습니다. 이번 업데이트를 통해 기존 보안이 올바르게 처리됩니다. (LOG-3138)
  • 이번 업데이트 이전에는 로깅 must-gather 스크립트를 사전 리팩터링하여 아티팩트에 대한 예상 위치를 제거했습니다. 이번 업데이트에서는 아티팩트를 /must-gather 폴더에 작성하도록 변경 사항을 되돌립니다. (LOG-3213)
  • 이번 업데이트 이전에는 특정 클러스터에서 Prometheus 내보내기를 IPv6 대신 IPv4에 바인딩했습니다. 이번 업데이트 후 Fluentd는 IP 버전을 감지하고 IPv4의 경우 0.0.0.0 또는 IPv6의 경우 [::] 에 바인딩합니다. (LOG-3162)
1.4.14.2. CVE

1.4.15. Logging 5.5.3

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.3 이 포함되어 있습니다.

1.4.15.1. 버그 수정
  • 이번 업데이트 이전에는 구조화된 메시지가 포함된 로그 항목에 원래 메시지 필드가 포함되어 있었기 때문에 항목이 더 커졌습니다. 이번 업데이트에서는 구조화된 로그의 message 필드를 제거하여 증가된 크기를 줄입니다. (LOG-2759)
  • 이번 업데이트 이전에는 수집기 구성이 수집기 ,default-log-storevisualization Pod에서 로그를 제외했지만 .gz 파일에 보관된 로그를 제외할 수 없었습니다. 이번 업데이트를 통해 수집기,default-log-storevisualization 포드의 .gz 파일로 저장된 아카이브 로그도 제외됩니다. (LOG-2844)
  • 이번 업데이트 이전에는 게이트웨이를 통해 사용할 수 없는 pod에 대한 요청이 전송되면 중단에 대한 경고 메시지가 표시되지 않습니다. 이번 업데이트를 통해 게이트웨이에 쓰기 또는 읽기에 문제가 있는 경우 개별 경고가 생성됩니다. (LOG-2884)
  • 이번 업데이트 이전에는 파이프라인을 통해 참조를 통해 전달된 값 때문에 fluent 플러그인에 의해 pod 메타데이터를 변경할 수 있었습니다. 이번 업데이트를 통해 각 로그 메시지가 개별적으로 처리할 수 있도록 Pod 메타데이터 복사본을 수신합니다. (로그-3046)
  • 이번 업데이트 이전에는 OpenShift 콘솔 로그에서 알 수 없는 심각도를 선택하면 level=unknown 값이 있는 제외된 로그를 확인합니다. 이번 업데이트를 통해 수준이 없고 level= unknown 값이 없는 로그가 알 수 없는 심각도로 필터링될 때 표시됩니다. (로그-3062)
  • 이번 업데이트 이전에는 Elasticsearch로 전송된 로그 레코드에 로그를 보낼 인덱스 이름이 포함된 write-index 라는 추가 필드가 있었습니다. 이 필드는 데이터 모델의 일부가 아닙니다. 이번 업데이트 후에는 이 필드가 더 이상 전송되지 않습니다. (로그-3075)
  • 새로운 내장 Pod 보안 승인 컨트롤러가 도입됨에 따라 Pod는 전역 또는 네임스페이스 수준에서 정의된 적용된 보안 표준에 따라 구성되지 않습니다. 이번 업데이트를 통해 Operator 및 수집기는 권한 있는 실행을 허용하고 보안 감사 경고 또는 오류 없이 실행됩니다. (로그-3077)
  • 이번 업데이트 이전에는 Operator에서 LokiStack을 기본 로그 스토리지로 사용할 때 ClusterLogForwarder 사용자 정의 리소스에 정의된 모든 사용자 정의 출력을 제거했습니다. 이번 업데이트를 통해 Operator는 ClusterLogForwarder 사용자 정의 리소스를 처리할 때 기본 출력과 사용자 정의 출력을 병합합니다. (로그-3095)
1.4.15.2. CVE

1.4.16. logging 5.5.2

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.2 가 포함되어 있습니다.

1.4.16.1. 버그 수정
  • 이번 업데이트 이전에는 Fluentd 수집기에 대한 경고 규칙이 OpenShift Container Platform 모니터링 스타일 지침을 준수하지 않았습니다. 이번 업데이트에서는 네임스페이스 레이블을 포함하도록 이러한 경고를 수정하여 문제를 해결합니다. (LOG-1823)
  • 이번 업데이트 이전에는 인덱스 이름에 하이픈 문자가 두 개 이상 있을 때마다 인덱스 관리 롤오버 스크립트가 새 인덱스 이름을 생성하지 못했습니다. 이번 업데이트를 통해 인덱스 이름이 올바르게 생성됩니다. (LOG-2644)
  • 이번 업데이트 이전에는 Kibana 경로가 인증서가 없는 caCertificate 값을 설정했습니다. 이번 업데이트를 통해 caCertificate 값이 설정되지 않았습니다. (LOG-2661)
  • 이번 업데이트 이전에는 수집기 종속성을 변경하면 사용되지 않는 매개변수에 대한 경고 메시지가 표시되었습니다. 이번 업데이트를 통해 사용하지 않는 설정 매개변수를 제거하면 문제가 해결됩니다. (LOG-2859)
  • 이번 업데이트 이전에는 Loki Operator가 생성한 배포에 생성된 Pod가 Linux가 아닌 운영 체제가 있는 노드에 실수로 예약되었습니다(Operator가 실행 중인 클러스터에서 이러한 노드를 사용할 수 있는 경우). 이번 업데이트를 통해 Operator는 Linux 기반 노드에서만 Pod를 예약할 수 있는 Pod 정의에 추가 노드 선택기를 연결합니다. (LOG-2895)
  • 이번 업데이트 이전에는 LokiStack 게이트웨이의 LogQL 구문 분석기 문제로 인해 OpenShift 콘솔 로그 보기가 심각도별로 로그를 필터링하지 않았습니다. 이번 업데이트를 통해 구문 분석 수정으로 문제가 해결되고 OpenShift Console Logs 보기에서 심각도별로 필터링할 수 있습니다. (LOG-2908)
  • 이번 업데이트 이전에는 Fluentd 수집기 플러그인 리팩터링이 이벤트의 타임 스탬프 필드를 제거했습니다. 이번 업데이트에서는 이벤트의 수신된 시간에서 가져온 타임스탬프 필드를 복원합니다. (LOG-2923)
  • 이번 업데이트 이전에는 감사 로그에 수준 필드가 없으면 벡터 로그에서 오류가 발생했습니다. 이번 업데이트를 통해 감사 로그 레코드에 수준 필드를 추가하면 문제가 해결됩니다. (LOG-2961)
  • 이번 업데이트 이전에는 Kibana 사용자 정의 리소스를 삭제한 경우 OpenShift Container Platform 웹 콘솔에 Kibana에 대한 링크가 계속 표시됩니다. 이번 업데이트를 통해 Kibana 사용자 정의 리소스를 제거하면 해당 링크도 제거됩니다. (LOG-3053)
  • 이번 업데이트 이전에는 ClusterLogForwarder 사용자 정의 리소스에 JSON 구문 분석이 정의된 경우 각 롤오버 작업이 빈 인덱스를 생성했습니다. 이번 업데이트를 통해 새 인덱스가 비어 있지 않습니다. (LOG-3063)
  • 이번 업데이트 이전에는 Loki Operator 5.4에서 처음 생성한 Loki Operator 5.5 리소스가 업데이트 된 후 사용자가 LokiStack을 삭제한 경우 남아 있습니다. 이번 업데이트를 통해 리소스의 소유자가 5.5 LokiStack을 가리킵니다. (LOG-2945)
  • 이번 업데이트 이전에는 사용자가 액세스할 수 있는 네임스페이스의 애플리케이션 로그를 볼 수 없었습니다. 이번 업데이트를 통해 Loki Operator는 클러스터 역할 및 클러스터 역할 바인딩을 자동으로 생성하여 사용자가 애플리케이션 로그를 읽을 수 있습니다. (LOG-2918)
  • 이번 업데이트 이전에는 cluster-admin 권한이 있는 사용자가 로깅 콘솔을 사용하여 인프라 및 감사 로그를 올바르게 볼 수 없었습니다. 이번 업데이트를 통해 cluster-admin 및 dedicated-admin 그룹의 사용자도 admins로 인식하도록 권한 부여 검사가 확장되었습니다. (LOG-2970)
1.4.16.2. CVE

1.4.17. 5.5.1 로깅

이 릴리스에는 OpenShift Logging 버그 수정 릴리스 5.5.1 이 포함되어 있습니다.

1.4.17.1. 기능 개선
  • 이번 개선된 기능에는 로깅 콘솔 플러그인을 사용할 때 OpenShift Container Platform 웹 콘솔의 Pod 세부 정보 페이지에 집계된 로그 탭이 추가되었습니다. 이 향상된 기능은 OpenShift Container Platform 4.10 이상에서만 사용할 수 있습니다. (LOG-2647)
  • 이번 개선된 기능에는 Google Cloud Logging이 로그 전달의 출력 옵션으로 추가되었습니다. (LOG-1482)
1.4.17.2. 버그 수정
  • 이번 업데이트 이전에는 Operator에서 Pod가 준비되었는지 확인하지 않아 클러스터를 다시 시작하는 동안 클러스터가 작동하지 않는 상태에 도달했습니다. 이번 업데이트를 통해 Operator는 재시작 중에 새 Pod를 계속 진행하기 전에 새 Pod를 준비 상태로 표시하여 문제를 해결합니다. (LOG-2745)
  • 이번 업데이트 이전에는 Fluentd가 Kubernetes 플랫폼이 로그 파일을 회전시키고 더 이상 로그 메시지를 읽지 않음을 인식하지 못하는 경우가 있었습니다. 이번 업데이트에서는 업스트림 개발 팀에서 권장하는 구성 매개 변수를 설정하여 이를 수정합니다. (LOG-2995)
  • 이번 업데이트 이전에는 여러 줄 오류 감지 기능을 추가하여 내부 라우팅이 변경되어 레코드를 잘못된 대상으로 전달했습니다. 이번 업데이트를 통해 내부 라우팅이 잘못되었습니다. (LOG-2801)
  • 이번 업데이트 이전에는 OpenShift Container Platform 웹 콘솔의 새로 고침 간격을 변경하면 쿼리 필드가 비어 있을 때 오류가 발생했습니다. 이번 업데이트를 통해 쿼리 필드가 비어 있을 때 간격을 변경할 수 있는 옵션이 아닙니다. (LOG-2917)
1.4.17.3. CVE

1.4.18. Logging 5.5.0

이 릴리스에는OpenShift Logging 버그 수정 릴리스 5.5.0 이 포함되어 있습니다.

1.4.18.1. 기능 개선
  • 이번 업데이트를 통해 동일한 Pod 내의 다른 컨테이너에서 다른 인덱스로 구조화된 로그를 전달할 수 있습니다. 이 기능을 사용하려면 다중 컨테이너 지원을 사용하여 파이프라인을 구성하고 Pod에 주석을 달아야 합니다. (LOG-1296)
중요

JSON 형식의 로그는 애플리케이션에 따라 다릅니다. 너무 많은 인덱스를 생성하면 성능에 영향을 미치기 때문에 이 기능을 사용하여 호환되지 않는 JSON 형식의 로그 인덱스를 생성할 수 있습니다. 쿼리를 사용하여 서로 다른 네임스페이스 또는 호환되는 JSON 형식의 애플리케이션을 분리합니다.

  • 이번 업데이트를 통해 Kubernetes 공통 레이블인 app.kubernetes.io/component,app.kubernetes.io/managed-by,app.kubernetes.io/part-of, app.kubernetes.io/version 을 사용하여 Elasticsearch 출력으로 로그를 필터링할 수 있습니다. Elasticsearch가 아닌 출력 유형은 kubernetes.labels 에 포함된 모든 레이블을 사용할 수 있습니다. (LOG-2388)
  • 이번 업데이트를 통해 AWS STS(Security Token Service)가 활성화된 클러스터는 STS 인증을 사용하여 로그를 Amazon NetNamespace로 전달할 수 있습니다. (LOG-1976)
  • 이번 업데이트를 통해 Loki Operator 및 Vector 수집기가 기술 프리뷰에서 일반 가용성으로 이동합니다. 이전 릴리스와의 전체 기능 패리티가 보류 중이며 일부 API는 기술 프리뷰로 남아 있습니다. 자세한 내용은 LokiStack을 사용한 로깅 섹션을 참조하십시오.
1.4.18.2. 버그 수정
  • 이번 업데이트 이전에는 로그를 Amazon ONTAP에 전달하도록 구성된 클러스터는 거부된 로그 파일을 임시 스토리지로 전달하여 시간이 지남에 따라 클러스터 불안정을 초래했습니다. 이번 업데이트를 통해 모든 스토리지 옵션의 청크 백업이 비활성화되어 문제를 해결합니다. (LOG-2746)
  • 이번 업데이트 이전에는 Operator가 더 이상 사용되지 않고 향후 OpenShift Container Platform 버전에서 제거될 계획인 일부 API 버전을 사용하고 있었습니다. 이번 업데이트에서는 종속 항목을 지원되는 API 버전으로 이동합니다. (LOG-2656)
  • 이번 업데이트 이전에는 다중 줄 오류 탐지를 위해 구성된 여러 ClusterLogForwarder 파이프라인으로 인해 수집기가 크래시 루프 복구 오류 상태로 전환되었습니다. 이번 업데이트에서는 여러 구성 섹션에 동일한 고유 ID가 있는 문제가 해결되었습니다. (LOG-2241)
  • 이번 업데이트 이전에는 수집기에서 UTF-8 이외의 기호를 Elasticsearch 스토리지 로그에 저장할 수 없었습니다. 이번 업데이트를 통해 수집기는 UTF-8 이외의 기호를 인코딩하여 문제를 해결합니다. (LOG-2203)
  • 이번 업데이트 이전에는 Kibana에 올바르지 않은 문자가 잘못 표시되었습니다. 이번 업데이트를 통해 Kibana가 모든 유효한 UTF-8 기호를 올바르게 표시합니다. (LOG-2784)
1.4.18.3. CVE

2장. 지원

이 문서에 설명된 구성 옵션만 로깅에 지원됩니다.

다른 구성 옵션은 지원되지 않으므로 사용하지 마십시오. 구성 패러다임은 OpenShift Container Platform 릴리스마다 변경될 수 있으며 이러한 경우는 모든 구성 가능성이 제어되는 경우에만 정상적으로 처리될 수 있습니다. 이 문서에 설명된 것과 다른 구성을 사용하는 경우 Operator는 차이점을 조정하도록 설계되었으므로 변경 사항을 덮어씁니다.

참고

OpenShift Container Platform 설명서에 설명되어 있지 않은 구성을 수행해야 하는 경우 Red Hat OpenShift Logging Operator를 Unmanaged 상태로 설정해야 합니다. 관리되지 않는 로깅 인스턴스는 지원되지 않으며 Managed 로 상태를 반환할 때까지 업데이트를 받지 않습니다.

참고

로깅은 핵심 OpenShift Container Platform과 별도의 릴리스 주기와 함께 설치 가능한 구성 요소로 제공됩니다. Red Hat OpenShift Container Platform 라이프 사이클 정책은 릴리스 호환성에 대해 간단히 설명합니다.

Red Hat OpenShift에 대한 로깅은 애플리케이션, 인프라 및 감사 로그의 의견이 지정된 수집기 및 노멀라이저입니다. 지원되는 다양한 시스템으로 로그를 전달하는 데 사용됩니다.

로깅은 다음과 같습니다.

  • 대규모 로그 수집 시스템
  • SIEM(Security Information and Event Monitoring) 준수
  • 기록 또는 장기 로그 보존 또는 스토리지
  • 보장된 로그 싱크
  • 보안 스토리지 - 감사 로그는 기본적으로 저장되지 않습니다.

2.1. 지원되는 API 사용자 정의 리소스 정의

LokiStack 개발이 진행 중입니다. 현재 일부 API는 지원되지 않습니다.

표 2.1. Loki API 지원 상태
CRD(CustomResourceDefinition)ApiVersion지원 상태

LokiStack

lokistack.loki.grafana.com/v1

5.5에서 지원됨

RulerConfig

rulerconfig.loki.grafana/v1

5.7에서 지원

AlertingRule

alertingrule.loki.grafana/v1

5.7에서 지원

RecordingRule

recordingrule.loki.grafana/v1

5.7에서 지원

2.2. 지원되지 않는 로깅 구성

다음 구성 요소를 수정하려면 Red Hat OpenShift Logging Operator를 Unmanaged 상태로 설정해야 합니다.

  • Elasticsearch CR(사용자 정의 리소스)
  • Kibana 배포
  • fluent.conf 파일
  • Fluentd 데몬 세트

Elasticsearch 배포 파일을 수정하려면 OpenShift Elasticsearch Operator를 Unmanaged 상태로 설정해야 합니다.

명시적으로 지원되지 않는 경우는 다음과 같습니다.

  • 기본 로그 회전 구성. 기본 로그 회전 구성을 수정할 수 없습니다.
  • 수집된 로그 위치 구성. 로그 수집기 출력 파일의 위치는 기본적으로 /var/log/fluentd/fluentd.log입니다.
  • 제한 로그 수집. 로그 수집기에서 로그를 읽는 속도를 조절할 수 없습니다.
  • 환경 변수를 사용하여 로깅 수집기 구성. 환경 변수를 사용하여 로그 수집기를 수정할 수 없습니다.
  • 로그 수집기에서 로그를 정규화하는 방법 구성. 기본 로그 정규화를 수정할 수 없습니다.

2.3. 관리되지 않는 Operator에 대한 지원 정책

Operator의 관리 상태는 Operator가 설계 의도에 따라 클러스터의 해당 구성 요소에 대한 리소스를 적극적으로 관리하고 있는지 여부를 판별합니다. Unmanaged 상태로 설정된 Operator는 구성 변경에 응답하지 않고 업데이트되지도 않습니다.

비프로덕션 클러스터 또는 디버깅 중에는 이 기능이 유용할 수 있지만, Unmanaged 상태의 Operator는 지원되지 않으며 개별 구성 요소의 구성 및 업그레이드를 클러스터 관리자가 전적으로 통제하게 됩니다.

다음과 같은 방법으로 Operator를 Unmanaged 상태로 설정할 수 있습니다.

  • 개별 Operator 구성

    개별 Operator는 구성에 managementState 매개변수가 있습니다. Operator에 따라 다양한 방식으로 이 매개변수에 액세스할 수 있습니다. 예를 들어, Red HAt OpenShift Logging Operator는 관리 대상인 사용자 정의 리소스(CR)를 수정하여 이를 수행하는 반면 Cluster Samples Operator는 클러스터 전체의 구성 리소스를 사용합니다.

    managementState 매개변수를 Unmanaged로 변경하면 Operator가 리소스를 적극적으로 관리하지 않으며 해당하는 구성 요소와 관련된 조치도 수행하지 않습니다. 클러스터가 손상되고 수동 복구가 필요할 가능성이 있으므로 이 관리 상태를 지원하지 않는 Operator도 있습니다.

    주의

    개별 Operator를 Unmanaged 상태로 변경하면 특정 구성 요소 및 기능이 지원되지 않습니다. 지원을 계속하려면 보고된 문제를 Managed 상태에서 재현해야 합니다.

  • Cluster Version Operator(CVO) 재정의

    spec.overrides 매개변수를 CVO 구성에 추가하여 관리자가 구성 요소에 대한 CVO 동작에 대한 재정의 목록을 제공할 수 있습니다. 구성 요소에 대해 spec.overrides[].unmanaged 매개변수를 true로 설정하면 클러스터 업그레이드가 차단되고 CVO 재정의가 설정된 후 관리자에게 경고합니다.

    Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
    주의

    CVO 재정의를 설정하면 전체 클러스터가 지원되지 않는 상태가 됩니다. 지원을 계속하려면 재정의를 제거한 후 보고된 문제를 재현해야 합니다.

2.4. Red Hat 지원을 위한 로깅 데이터 수집

지원 케이스를 열 때 클러스터에 대한 디버깅 정보를 Red Hat 지원에 제공하는 것이 좋습니다.

must-gather 을 사용하여 프로젝트 수준 리소스, 클러스터 수준 리소스 및 각 로깅 구성 요소에 대한 진단 정보를 수집할 수 있습니다.

즉각 지원을 받을 수 있도록 OpenShift Container Platform 및 로깅 둘 다에 대한 진단 정보를 제공하십시오.

참고

hack/logging-dump.sh 스크립트를 사용하지 마십시오. 이 스크립트는 더 이상 지원되지 않으며 데이터를 수집하지 않습니다.

2.4.1. must-gather 툴 정보

oc adm must-gather CLI 명령은 문제를 디버깅하는 데 필요할 가능성이 높은 클러스터에서 정보를 수집합니다.

로깅의 경우 must-gather 는 다음 정보를 수집합니다.

  • 프로젝트 수준의 Pod, 구성 맵, 서비스 계정, 역할, 역할 바인딩, 이벤트를 포함한 프로젝트 수준 리소스
  • 클러스터 수준의 노드, 역할, 역할 바인딩을 포함한 클러스터 수준 리소스
  • 로그 수집기, 로그 저장소, 로그 시각화 프로그램의 상태를 포함하여 openshift-loggingopenshift-operators-redhat 네임스페이스의 OpenShift Logging 리소스

oc adm must-gather를 실행하면 클러스터에 새 Pod가 생성됩니다. 해당 Pod에 대한 데이터가 수집되어 must-gather.local로 시작하는 새 디렉터리에 저장됩니다. 이 디렉터리는 현재 작업 중인 디렉터리에 생성되어 있습니다.

2.4.2. 로깅 데이터 수집

oc adm must-gather CLI 명령을 사용하여 로깅에 대한 정보를 수집할 수 있습니다.

프로세스

must-gather 로 로깅 정보를 수집하려면 다음을 수행합니다.

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

3장. 로깅 문제 해결

3.1. 로깅 상태 보기

Red Hat OpenShift Logging Operator 및 기타 로깅 구성 요소의 상태를 볼 수 있습니다.

3.1.1. Red Hat OpenShift Logging Operator의 상태 보기

Red Hat OpenShift Logging Operator의 상태를 볼 수 있습니다.

사전 요구 사항

  • Red Hat OpenShift Logging Operator 및 OpenShift Elasticsearch Operator가 설치되어 있습니다.

절차

  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에 대한 정보.
3.1.1.1. 상태 메시지 예

다음은 ClusterLogging 인스턴스의 Status.Nodes 섹션에 있는 일부 조건 메시지의 예입니다.

다음과 유사한 상태 메시지는 노드가 구성된 낮은 워터마크를 초과했으며 이 노드에 shard가 할당되지 않음을 나타냅니다.

출력 예

  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T15:57:22Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be not
        be allocated on this node.
      reason: Disk Watermark Low
      status: "True"
      type: NodeStorage
    deploymentName: example-elasticsearch-clientdatamaster-0-1
    upgradeStatus: {}

다음과 유사한 상태 메시지는 노드가 구성된 높은 워터마크를 초과했으며 shard가 다른 노드로 재배치됨을 나타냅니다.

출력 예

  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T16:04:45Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be relocated
        from this node.
      reason: Disk Watermark High
      status: "True"
      type: NodeStorage
    deploymentName: cluster-logging-operator
    upgradeStatus: {}

다음과 유사한 상태 메시지는 CR의 Elasticsearch 노드 선택기가 클러스터의 노드와 일치하지 않음을 나타냅니다.

출력 예

    Elasticsearch Status:
      Shard Allocation Enabled:  shard allocation unknown
      Cluster:
        Active Primary Shards:  0
        Active Shards:          0
        Initializing Shards:    0
        Num Data Nodes:         0
        Num Nodes:              0
        Pending Tasks:          0
        Relocating Shards:      0
        Status:                 cluster health unknown
        Unassigned Shards:      0
      Cluster Name:             elasticsearch
      Node Conditions:
        elasticsearch-cdm-mkkdys93-1:
          Last Transition Time:  2019-06-26T03:37:32Z
          Message:               0/5 nodes are available: 5 node(s) didn't match node selector.
          Reason:                Unschedulable
          Status:                True
          Type:                  Unschedulable
        elasticsearch-cdm-mkkdys93-2:
      Node Count:  2
      Pods:
        Client:
          Failed:
          Not Ready:
            elasticsearch-cdm-mkkdys93-1-75dd69dccd-f7f49
            elasticsearch-cdm-mkkdys93-2-67c64f5f4c-n58vl
          Ready:
        Data:
          Failed:
          Not Ready:
            elasticsearch-cdm-mkkdys93-1-75dd69dccd-f7f49
            elasticsearch-cdm-mkkdys93-2-67c64f5f4c-n58vl
          Ready:
        Master:
          Failed:
          Not Ready:
            elasticsearch-cdm-mkkdys93-1-75dd69dccd-f7f49
            elasticsearch-cdm-mkkdys93-2-67c64f5f4c-n58vl
          Ready:

다음과 유사한 상태 메시지는 요청한 PVC가 PV에 바인딩할 수 없음을 나타냅니다.

출력 예

      Node Conditions:
        elasticsearch-cdm-mkkdys93-1:
          Last Transition Time:  2019-06-26T03:37:32Z
          Message:               pod has unbound immediate PersistentVolumeClaims (repeated 5 times)
          Reason:                Unschedulable
          Status:                True
          Type:                  Unschedulable

다음과 유사한 상태 메시지는 노드 선택기가 노드와 일치하지 않기 때문에 Fluentd Pod를 예약할 수 없음을 나타냅니다.

출력 예

Status:
  Collection:
    Logs:
      Fluentd Status:
        Daemon Set:  fluentd
        Nodes:
        Pods:
          Failed:
          Not Ready:
          Ready:

3.1.2. 로깅 구성 요소의 상태 보기

여러 로깅 구성 요소의 상태를 볼 수 있습니다.

사전 요구 사항

  • Red Hat OpenShift Logging Operator 및 OpenShift Elasticsearch Operator가 설치되어 있습니다.

프로세스

  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----

3.2. 로그 전달 문제 해결

3.2.1. Fluentd Pod 재배포

ClusterLogForwarder CR(사용자 정의 리소스)을 생성할 때 Red Hat OpenShift Logging Operator가 Fluentd Pod를 자동으로 재배포하지 않으면 Fluentd Pod를 삭제하여 강제로 재배포할 수 있습니다.

사전 요구 사항

  • ClusterLogForwarder CR(사용자 정의 리소스) 오브젝트가 생성되어 있습니다.

프로세스

  • 다음 명령을 실행하여 Fluentd Pod를 삭제하여 강제로 재배포합니다.

    $ oc delete pod --selector logging-infra=collector

3.2.2. Loki 속도 제한 오류 문제 해결

로그 전달자 API에서 속도 제한을 초과하는 대규모 메시지 블록을 Loki로 전달하면 Loki는 속도 제한(429) 오류를 생성합니다.

이러한 오류는 정상적인 작동 중에 발생할 수 있습니다. 예를 들어 이미 일부 로그가 있는 클러스터에 로깅을 추가할 때 로깅이 기존 로그 항목을 모두 수집하는 동안 속도 제한 오류가 발생할 수 있습니다. 이 경우 새 로그 추가 속도가 총 속도 제한보다 작으면 기록 데이터가 결국 수집되고 사용자 개입 없이도 속도 제한 오류가 해결됩니다.

속도 제한 오류가 계속 발생하는 경우 LokiStack CR(사용자 정의 리소스)을 수정하여 문제를 해결할 수 있습니다.

중요

LokiStack CR은 Grafana 호스팅 Loki에서 사용할 수 없습니다. 이는 Grafana 호스팅 Loki 서버에는 적용되지 않습니다.

조건

  • Log Forwarder API는 로그를 Loki로 전달하도록 구성되어 있습니다.
  • 시스템에서 2MB보다 큰 메시지 블록을 Loki로 보냅니다. 예를 들면 다음과 같습니다.

    "values":[["1630410392689800468","{\"kind\":\"Event\",\"apiVersion\":\
    .......
    ......
    ......
    ......
    \"received_at\":\"2021-08-31T11:46:32.800278+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-31T11:46:32.799692+00:00\",\"viaq_index_name\":\"audit-write\",\"viaq_msg_id\":\"MzFjYjJkZjItNjY0MC00YWU4LWIwMTEtNGNmM2E5ZmViMGU4\",\"log_type\":\"audit\"}"]]}]}
  • oc logs -n openshift-logging -l component=collector 를 입력하면 클러스터의 수집기 로그에 다음 오류 메시지 중 하나가 포함된 행이 표시됩니다.

    429 Too Many Requests Ingestion rate limit exceeded

    Vector 오류 메시지의 예

    2023-08-25T16:08:49.301780Z  WARN sink{component_kind="sink" component_id=default_loki_infra component_type=loki component_name=default_loki_infra}: vector::sinks::util::retries: Retrying after error. error=Server responded with an error: 429 Too Many Requests internal_log_rate_limit=true

    Fluentd 오류 메시지의 예

    2023-08-30 14:52:15 +0000 [warn]: [default_loki_infra] failed to flush the buffer. retry_times=2 next_retry_time=2023-08-30 14:52:19 +0000 chunk="604251225bf5378ed1567231a1c03b8b" error_class=Fluent::Plugin::LokiOutput::LogPostError error="429 Too Many Requests Ingestion rate limit exceeded for user infrastructure (limit: 4194304 bytes/sec) while attempting to ingest '4082' lines totaling '7820025' bytes, reduce log volume or contact your Loki administrator to see if the limit can be increased\n"

    이 오류는 수신 끝점에도 표시됩니다. 예를 들어 LokiStack ingester Pod에서 다음을 수행합니다.

    Loki ingester 오류 메시지의 예

    level=warn ts=2023-08-30T14:57:34.155592243Z caller=grpc_logging.go:43 duration=1.434942ms method=/logproto.Pusher/Push err="rpc error: code = Code(429) desc = entry with timestamp 2023-08-30 14:57:32.012778399 +0000 UTC ignored, reason: 'Per stream rate limit exceeded (limit: 3MB/sec) while attempting to ingest for stream

프로세스

  • LokiStack CR에서 ingestionBurstSizeingestionRate 필드를 업데이트합니다.

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki
      namespace: openshift-logging
    spec:
      limits:
        global:
          ingestion:
            ingestionBurstSize: 16 1
            ingestionRate: 8 2
    # ...
    1
    ingestionBurstSize 필드는 배포자 복제본당 최대 로컬 속도 제한 샘플 크기를 MB로 정의합니다. 이 값은 하드 제한입니다. 이 값을 단일 푸시 요청에 예상되는 최대 로그 크기로 설정합니다. ingestionBurstSize 값보다 큰 단일 요청은 허용되지 않습니다.
    2
    ingestionRate 필드는 초당 수집된 샘플의 최대 양(MB)에 대한 소프트 제한입니다. 로그 비율이 제한을 초과하는 경우 속도 제한 오류가 발생하지만 수집기는 로그를 다시 시도합니다. 총 평균이 제한보다 작으면 사용자 개입 없이 시스템을 복구하고 오류가 해결됩니다.

3.3. 로깅 경고 문제 해결

다음 절차를 사용하여 클러스터의 로깅 경고 문제를 해결할 수 있습니다.

3.3.1. Elasticsearch 클러스터 상태가 빨간색

하나 이상의 기본 shard와 해당 복제본이 노드에 할당되지 않습니다. 다음 절차에 따라 이 경고 문제를 해결합니다.

작은 정보

이 문서의 일부 명령은 $ES_POD_NAME 쉘 변수를 사용하여 Elasticsearch Pod를 참조합니다. 이 문서에서 직접 명령을 복사하여 붙여넣려면 이 변수를 Elasticsearch 클러스터에 유효한 값으로 설정해야 합니다.

다음 명령을 실행하여 사용 가능한 Elasticsearch Pod를 나열할 수 있습니다.

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

나열된 Pod 중 하나를 선택하고 다음 명령을 실행하여 $ES_POD_NAME 변수를 설정합니다.

$ export ES_POD_NAME=<elasticsearch_pod_name>

이제 명령에 $ES_POD_NAME 변수를 사용할 수 있습니다.

프로세스

  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 활용에 대한 자세한 내용은 OpenShift Container Platform "모듈 대시보드 검토" 설명서를 참조하십시오.

3.3.2. Elasticsearch 클러스터 상태가 노란색임

하나 이상의 기본 shard의 복제본 shard는 노드에 할당되지 않습니다. ClusterLogging 사용자 정의 리소스(CR)에서 nodeCount 값을 조정하여 노드 수를 늘립니다.

3.3.3. Elasticsearch 노드 디스크 낮은 워터마크 도달

Elasticsearch는 낮은 워터마크에 도달하는 노드에 shard를 할당하지 않습니다.

작은 정보

이 문서의 일부 명령은 $ES_POD_NAME 쉘 변수를 사용하여 Elasticsearch Pod를 참조합니다. 이 문서에서 직접 명령을 복사하여 붙여넣려면 이 변수를 Elasticsearch 클러스터에 유효한 값으로 설정해야 합니다.

다음 명령을 실행하여 사용 가능한 Elasticsearch Pod를 나열할 수 있습니다.

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

나열된 Pod 중 하나를 선택하고 다음 명령을 실행하여 $ES_POD_NAME 변수를 설정합니다.

$ export ES_POD_NAME=<elasticsearch_pod_name>

이제 명령에 $ES_POD_NAME 변수를 사용할 수 있습니다.

프로세스

  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

3.3.4. 높은 워터마크에 도달한 Elasticsearch 노드 디스크

Elasticsearch는 워터마크 임계값 제한을 초과하지 않은 디스크 사용량이 낮은 노드로 높은 워터마크에 도달한 노드에서 shard를 재배치하려고 합니다.

특정 노드에 shard를 할당하려면 해당 노드에서 일부 공간을 확보해야 합니다. 디스크 공간을 늘릴 수 없는 경우 클러스터에 새 데이터 노드를 추가하거나 총 클러스터 중복 정책을 줄입니다.

작은 정보

이 문서의 일부 명령은 $ES_POD_NAME 쉘 변수를 사용하여 Elasticsearch Pod를 참조합니다. 이 문서에서 직접 명령을 복사하여 붙여넣려면 이 변수를 Elasticsearch 클러스터에 유효한 값으로 설정해야 합니다.

다음 명령을 실행하여 사용 가능한 Elasticsearch Pod를 나열할 수 있습니다.

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

나열된 Pod 중 하나를 선택하고 다음 명령을 실행하여 $ES_POD_NAME 변수를 설정합니다.

$ export ES_POD_NAME=<elasticsearch_pod_name>

이제 명령에 $ES_POD_NAME 변수를 사용할 수 있습니다.

프로세스

  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

3.3.5. Elasticsearch 노드 디스크 플러드 워터마크에 도달했습니다

Elasticsearch는 이러한 두 조건을 모두 충족하는 모든 인덱스에 읽기 전용 인덱스 블록을 적용합니다.

  • 하나 이상의 shard가 노드에 할당됩니다.
  • 하나 이상의 디스크가 플러드 단계를 초과합니다.

다음 절차에 따라 이 경고 문제를 해결합니다.

작은 정보

이 문서의 일부 명령은 $ES_POD_NAME 쉘 변수를 사용하여 Elasticsearch Pod를 참조합니다. 이 문서에서 직접 명령을 복사하여 붙여넣려면 이 변수를 Elasticsearch 클러스터에 유효한 값으로 설정해야 합니다.

다음 명령을 실행하여 사용 가능한 Elasticsearch Pod를 나열할 수 있습니다.

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

나열된 Pod 중 하나를 선택하고 다음 명령을 실행하여 $ES_POD_NAME 변수를 설정합니다.

$ export ES_POD_NAME=<elasticsearch_pod_name>

이제 명령에 $ES_POD_NAME 변수를 사용할 수 있습니다.

프로세스

  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}'

3.3.6. Elasticsearch JVM 힙 사용량이 높음

사용된 Elasticsearch 노드 JVM(Java 가상 머신) 힙 메모리는 75% 이상입니다. 힙 크기를 늘리는 것이 좋습니다.

3.3.7. 집계된 로깅 시스템 CPU가 높음

노드의 시스템 CPU 사용량이 높습니다. 클러스터 노드의 CPU를 확인합니다. 더 많은 CPU 리소스를 노드에 할당하는 것이 좋습니다.

3.3.8. Elasticsearch 프로세스 CPU가 높음

노드의 Elasticsearch 프로세스 CPU 사용량이 높습니다. 클러스터 노드의 CPU를 확인합니다. 더 많은 CPU 리소스를 노드에 할당하는 것이 좋습니다.

3.3.9. Elasticsearch 디스크 공간이 부족합니다.

Elasticsearch는 현재 디스크 사용량에 따라 향후 6시간 이내에 디스크 공간이 부족해질 것으로 예상됩니다. 다음 절차에 따라 이 경고 문제를 해결합니다.

프로세스

  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

3.3.10. Elasticsearch FileDescriptor 사용량이 높음

현재 사용 추세를 기준으로 노드의 예상 파일 설명자 수가 충분하지 않습니다. Elasticsearch File Descriptors 문서에 설명된 대로 각 노드의 max_file_descriptors 값을 확인합니다.

3.4. Elasticsearch 로그 저장소의 상태 보기

OpenShift Elasticsearch Operator 및 여러 Elasticsearch 구성 요소의 상태를 볼 수 있습니다.

3.4.1. Elasticsearch 로그 저장소의 상태 보기

Elasticsearch 로그 저장소의 상태를 볼 수 있습니다.

사전 요구 사항

  • Red Hat OpenShift Logging Operator 및 OpenShift Elasticsearch Operator가 설치되어 있습니다.

절차

  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
3.4.1.1. 상태 메시지 예

다음은 Elasticsearch 인스턴스의 상태 섹션에 있는 일부 조건 메시지의 예입니다.

다음 상태 메시지는 노드가 구성된 낮은 워터마크를 초과했으며 이 노드에 shard가 할당되지 않음을 나타냅니다.

status:
  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T15:57:22Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be not
        be allocated on this node.
      reason: Disk Watermark Low
      status: "True"
      type: NodeStorage
    deploymentName: example-elasticsearch-cdm-0-1
    upgradeStatus: {}

다음 상태 메시지는 노드가 구성된 높은 워터마크를 초과했으며 shard가 다른 노드로 재배치됨을 나타냅니다.

status:
  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T16:04:45Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be relocated
        from this node.
      reason: Disk Watermark High
      status: "True"
      type: NodeStorage
    deploymentName: example-elasticsearch-cdm-0-1
    upgradeStatus: {}

다음 상태 메시지는 CR(사용자 정의 리소스)의 Elasticsearch 로그 저장소 노드 선택기가 클러스터의 노드와 일치하지 않음을 나타냅니다.

status:
    nodes:
    - conditions:
      - lastTransitionTime: 2019-04-10T02:26:24Z
        message: '0/8 nodes are available: 8 node(s) didn''t match node selector.'
        reason: Unschedulable
        status: "True"
        type: Unschedulable

다음 상태 메시지는 Elasticsearch 로그 저장소 CR에서 PVC(영구 볼륨 클레임)가 존재하지 않음을 나타냅니다.

status:
   nodes:
   - conditions:
     - last Transition Time:  2019-04-10T05:55:51Z
       message:               pod has unbound immediate PersistentVolumeClaims (repeated 5 times)
       reason:                Unschedulable
       status:                True
       type:                  Unschedulable

다음 상태 메시지는 Elasticsearch 로그 저장소 클러스터에 중복 정책을 지원하기에 충분한 노드가 없음을 나타냅니다.

status:
  clusterHealth: ""
  conditions:
  - lastTransitionTime: 2019-04-17T20:01:31Z
    message: Wrong RedundancyPolicy selected. Choose different RedundancyPolicy or
      add more nodes with data roles
    reason: Invalid Settings
    status: "True"
    type: InvalidRedundancy

이 상태 메시지는 클러스터에 컨트롤 플레인 노드가 너무 많음을 나타냅니다.

status:
  clusterHealth: green
  conditions:
    - lastTransitionTime: '2019-04-17T20:12:34Z'
      message: >-
        Invalid master nodes count. Please ensure there are no more than 3 total
        nodes with master roles
      reason: Invalid Settings
      status: 'True'
      type: InvalidMasters

다음 상태 메시지는 Elasticsearch 스토리지가 변경 작업을 지원하지 않음을 나타냅니다.

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

status:
  clusterHealth: green
  conditions:
    - lastTransitionTime: "2021-05-07T01:05:13Z"
      message: Changing the storage structure for a custom resource is not supported
      reason: StorageStructureChangeIgnored
      status: 'True'
      type: StorageStructureChangeIgnored

reasontype 필드는 지원되지 않는 변경 유형을 지정합니다.

StorageClassNameChangeIgnored
스토리지 클래스 이름에 대한 지원되지 않는 변경 사항입니다.
StorageSizeChangeIgnored
스토리지 크기에 대한 지원되지 않는 변경 사항입니다.
StorageStructureChangeIgnored

임시 스토리지 구조와 영구저장장치 구조 간에는 지원되지 않는 변경 사항입니다.

중요

임시 스토리지에서 영구 스토리지로 전환하도록 ClusterLogging CR을 구성하려고 하면 OpenShift Elasticsearch Operator는 PVC(영구 볼륨 클레임)를 생성하지만 PV(영구 볼륨)를 생성하지 않습니다. StorageStructureChangeIgnored 상태를 지우려면 ClusterLogging CR로 변경 사항을 취소하고 PVC를 삭제해야 합니다.

3.4.2. 로그 저장소 구성 요소의 상태 보기

여러 로그 저장소 구성 요소의 상태를 볼 수 있습니다.

Elasticsearch 인덱스

Elasticsearch 인덱스의 상태를 볼 수 있습니다.

  1. Elasticsearch Pod의 이름을 가져옵니다.

    $ oc get pods --selector component=elasticsearch -o name

    출력 예

    pod/elasticsearch-cdm-1godmszn-1-6f8495-vp4lw
    pod/elasticsearch-cdm-1godmszn-2-5769cf-9ms2n
    pod/elasticsearch-cdm-1godmszn-3-f66f7d-zqkz7

  2. 인덱스의 상태를 가져옵니다.

    $ oc exec elasticsearch-cdm-4vjor49p-2-6d4d7db474-q2w7z -- indices

    출력 예

    Defaulting container name to elasticsearch.
    Use 'oc describe pod/elasticsearch-cdm-4vjor49p-2-6d4d7db474-q2w7z -n openshift-logging' to see all of the containers in this pod.
    
    green  open   infra-000002                                                     S4QANnf1QP6NgCegfnrnbQ   3   1     119926            0        157             78
    green  open   audit-000001                                                     8_EQx77iQCSTzFOXtxRqFw   3   1          0            0          0              0
    green  open   .security                                                        iDjscH7aSUGhIdq0LheLBQ   1   1          5            0          0              0
    green  open   .kibana_-377444158_kubeadmin                                     yBywZ9GfSrKebz5gWBZbjw   3   1          1            0          0              0
    green  open   infra-000001                                                     z6Dpe__ORgiopEpW6Yl44A   3   1     871000            0        874            436
    green  open   app-000001                                                       hIrazQCeSISewG3c2VIvsQ   3   1       2453            0          3              1
    green  open   .kibana_1                                                        JCitcBMSQxKOvIq6iQW6wg   1   1          0            0          0              0
    green  open   .kibana_-1595131456_user1                                        gIYFIEGRRe-ka0W3okS-mQ   3   1          1            0          0              0

로그 저장소 Pod

로그 저장소를 호스팅하는 Pod의 상태를 볼 수 있습니다.

  1. Pod 이름을 가져옵니다.

    $ oc get pods --selector component=elasticsearch -o name

    출력 예

    pod/elasticsearch-cdm-1godmszn-1-6f8495-vp4lw
    pod/elasticsearch-cdm-1godmszn-2-5769cf-9ms2n
    pod/elasticsearch-cdm-1godmszn-3-f66f7d-zqkz7

  2. Pod 상태를 가져옵니다.

    $ oc describe pod elasticsearch-cdm-1godmszn-1-6f8495-vp4lw

    출력에는 다음 상태 정보가 포함됩니다.

    출력 예

    ....
    Status:             Running
    
    ....
    
    Containers:
      elasticsearch:
        Container ID:   cri-o://b7d44e0a9ea486e27f47763f5bb4c39dfd2
        State:          Running
          Started:      Mon, 08 Jun 2020 10:17:56 -0400
        Ready:          True
        Restart Count:  0
        Readiness:  exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3
    
    ....
    
      proxy:
        Container ID:  cri-o://3f77032abaddbb1652c116278652908dc01860320b8a4e741d06894b2f8f9aa1
        State:          Running
          Started:      Mon, 08 Jun 2020 10:18:38 -0400
        Ready:          True
        Restart Count:  0
    
    ....
    
    Conditions:
      Type              Status
      Initialized       True
      Ready             True
      ContainersReady   True
      PodScheduled      True
    
    ....
    
    Events:          <none>

로그 스토리지 Pod 배포 구성

로그 저장소 배포 구성의 상태를 볼 수 있습니다.

  1. 배포 구성의 이름을 가져옵니다.

    $ oc get deployment --selector component=elasticsearch -o name

    출력 예

    deployment.extensions/elasticsearch-cdm-1gon-1
    deployment.extensions/elasticsearch-cdm-1gon-2
    deployment.extensions/elasticsearch-cdm-1gon-3

  2. 배포 구성 상태를 가져옵니다.

    $ oc describe deployment elasticsearch-cdm-1gon-1

    출력에는 다음 상태 정보가 포함됩니다.

    출력 예

    ....
      Containers:
       elasticsearch:
        Image:      registry.redhat.io/openshift-logging/elasticsearch6-rhel8
        Readiness:  exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3
    
    ....
    
    Conditions:
      Type           Status   Reason
      ----           ------   ------
      Progressing    Unknown  DeploymentPaused
      Available      True     MinimumReplicasAvailable
    
    ....
    
    Events:          <none>

로그 저장소 복제본 세트

로그 저장소 복제본 세트의 상태를 볼 수 있습니다.

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

    $ oc get replicaSet --selector component=elasticsearch -o name
    
    replicaset.extensions/elasticsearch-cdm-1gon-1-6f8495
    replicaset.extensions/elasticsearch-cdm-1gon-2-5769cf
    replicaset.extensions/elasticsearch-cdm-1gon-3-f66f7d
  2. 복제본 세트의 상태를 가져옵니다.

    $ oc describe replicaSet elasticsearch-cdm-1gon-1-6f8495

    출력에는 다음 상태 정보가 포함됩니다.

    출력 예

    ....
      Containers:
       elasticsearch:
        Image:      registry.redhat.io/openshift-logging/elasticsearch6-rhel8@sha256:4265742c7cdd85359140e2d7d703e4311b6497eec7676957f455d6908e7b1c25
        Readiness:  exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3
    
    ....
    
    Events:          <none>

3.4.3. Elasticsearch 클러스터 상태

OpenShift Container Platform 웹 콘솔의 Observe 섹션에 있는 대시보드에는 Elasticsearch 클러스터의 상태가 표시됩니다.

OpenShift Elasticsearch 클러스터의 상태를 가져오려면 <cluster _url>/monitoring/dashboards/grafana-dashboard-cluster-logging에 있는 OpenShift Container Platform 웹 콘솔의 Observe 섹션에서 대시보드 를 참조하십시오.

Elasticsearch 상태 필드

eo_elasticsearch_cr_cluster_management_state

Elasticsearch 클러스터가 관리 상태인지 또는 관리되지 않는 상태에 있는지를 표시합니다. 예를 들면 다음과 같습니다.

eo_elasticsearch_cr_cluster_management_state{state="managed"} 1
eo_elasticsearch_cr_cluster_management_state{state="unmanaged"} 0
eo_elasticsearch_cr_restart_total

인증서 재시작, 롤링 재시작 또는 예약된 재시작을 위해 Elasticsearch 노드가 다시 시작된 횟수를 표시합니다. 예를 들면 다음과 같습니다.

eo_elasticsearch_cr_restart_total{reason="cert_restart"} 1
eo_elasticsearch_cr_restart_total{reason="rolling_restart"} 1
eo_elasticsearch_cr_restart_total{reason="scheduled_restart"} 3
es_index_namespaces_total

Elasticsearch 인덱스 네임스페이스의 총 수를 표시합니다. 예를 들면 다음과 같습니다.

Total number of Namespaces.
es_index_namespaces_total 5
es_index_document_count

각 네임스페이스에 대한 레코드 수가 표시됩니다. 예를 들면 다음과 같습니다.

es_index_document_count{namespace="namespace_1"} 25
es_index_document_count{namespace="namespace_2"} 10
es_index_document_count{namespace="namespace_3"} 5

"Secret Elasticsearch 필드가 누락되었거나 비어 있음" 메시지

Elasticsearch에 admin-cert,admin-key,logging-es.crt 또는 logging-es.key 파일이 없는 경우 대시보드에는 다음 예와 유사한 상태 메시지가 표시됩니다.

message": "Secret \"elasticsearch\" fields are either missing or empty: [admin-cert, admin-key, logging-es.crt, logging-es.key]",
"reason": "Missing Required Secrets",

4장. 로깅 정보

클러스터 관리자는 OpenShift Container Platform 클러스터에 로깅을 배포하고 이를 사용하여 노드 시스템 감사 로그, 애플리케이션 컨테이너 로그 및 인프라 로그를 수집하고 집계할 수 있습니다. 온-클러스터, Red Hat 관리 로그 스토리지를 포함하여 선택한 로그 출력에 로그를 전달할 수 있습니다. 배포된 로그 스토리지 솔루션에 따라 OpenShift Container Platform 웹 콘솔 또는 Kibana 웹 콘솔에서 로그 데이터를 시각화할 수도 있습니다.

참고

Kibana 웹 콘솔은 향후 로깅 릴리스에서 더 이상 사용되지 않습니다.

OpenShift Container Platform 클러스터 관리자는 Operator를 사용하여 로깅을 배포할 수 있습니다. 자세한 내용은 로깅 설치를 참조하십시오.

Operator는 로깅 배포, 업그레이드 및 유지보수를 담당합니다. Operator가 설치되면 ClusterLogging 사용자 정의 리소스(CR)를 생성하여 로깅 Pod 및 로깅을 지원하는 데 필요한 기타 리소스를 예약할 수 있습니다. ClusterLogForwarder CR을 생성하여 수집되는 로그, 변환 방법, 전달되는 위치를 지정할 수도 있습니다.

참고

내부 OpenShift Container Platform Elasticsearch 로그 저장소는 감사 로그를 위한 보안 스토리지를 제공하지 않기 때문에 감사 로그는 기본적으로 내부 Elasticsearch 인스턴스에 저장되지 않습니다. 예를 들어 Kibana에서 감사 로그를 보려면 감사 로그를 기본 내부 Elasticsearch 로그 저장소로 보내려면 로그 저장소에 감사 로그 전달에 설명된 대로 로그 전달 API를 사용해야 합니다.

4.1. 로깅 아키텍처

로깅의 주요 구성 요소는 다음과 같습니다.

수집기

수집기는 데몬 세트로 각 OpenShift Container Platform 노드에 Pod를 배포합니다. 각 노드에서 로그 데이터를 수집하고 데이터를 변환한 다음 구성된 출력으로 전달합니다. Vector 수집기 또는 레거시 Fluentd 수집기를 사용할 수 있습니다.

참고

Fluentd는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않습니다. Fluentd 대신 Vector를 사용할 수 있습니다.

로그 저장소

로그 저장소는 분석을 위해 로그 데이터를 저장하고 로그 전달자의 기본 출력입니다. 기본 LokiStack 로그 저장소, 레거시 Elasticsearch 로그 저장소를 사용하거나 로그를 추가 외부 로그 저장소로 전달할 수 있습니다.

참고

로깅 5.9 릴리스에는 업데이트된 OpenShift Elasticsearch Operator 버전이 포함되어 있지 않습니다. 현재 Logging 5.8과 함께 릴리스된 OpenShift Elasticsearch Operator를 사용하는 경우 로깅 5.8의 EOL까지 로깅에서 계속 작동합니다. OpenShift Elasticsearch Operator를 사용하여 기본 로그 스토리지를 관리하는 대신 Loki Operator를 사용할 수 있습니다. 로깅 라이프사이클 날짜에 대한 자세한 내용은 Platform Agnostic Operators 를 참조하십시오.

시각화

UI 구성 요소를 사용하여 로그 데이터의 시각적 표현을 볼 수 있습니다. UI는 저장된 로그를 검색, 쿼리 및 볼 수 있는 그래픽 인터페이스를 제공합니다. OpenShift Container Platform 웹 콘솔 UI는 OpenShift Container Platform 콘솔 플러그인을 활성화하면 제공됩니다.

참고

Kibana 웹 콘솔은 향후 로깅 릴리스에서 더 이상 사용되지 않습니다.

로깅은 컨테이너 로그 및 노드 로그를 수집합니다. 이는 다음과 같은 유형으로 분류됩니다.

애플리케이션 로그
인프라 컨테이너 애플리케이션을 제외하고 클러스터에서 실행 중인 사용자 애플리케이션에 의해 생성된 컨테이너 로그입니다.
인프라 로그
인프라 네임스페이스에서 생성된 컨테이너 로그: openshift*, kube* 또는 default 및 노드의 journald 메시지입니다.
감사 로그
/var/log/audit/audit.log 파일에 저장되는 노드 감사 시스템인 auditd에서 생성된 로그와 auditd,kube-apiserver,openshift-apiserver 서비스 및 활성화된 경우 ovn 프로젝트의 로그입니다.

4.2. 로깅 배포 정보

관리자는 OpenShift Container Platform 웹 콘솔 또는 OpenShift CLI(oc)를 사용하여 로깅 Operator를 설치하여 로깅을 배포할 수 있습니다. Operator는 로깅의 배포, 업그레이드 및 유지보수를 담당합니다.

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

4.2.1. 사용자 정의 리소스 로깅

각 Operator에서 구현하는 CR(사용자 정의 리소스) YAML 파일을 사용하여 로깅 배포를 구성할 수 있습니다.

Red Hat OpenShift Logging Operator:

  • ClusterLogging (CL) - Operator가 설치된 후 ClusterLogging 사용자 정의 리소스(CR)를 생성하여 로깅 Pod 및 로깅 지원에 필요한 기타 리소스를 예약합니다. ClusterLogging CR은 수집기 및 전달자를 배포합니다. 현재 각 노드에서 실행되는 데몬 세트로 둘 다 구현됩니다. Red Hat OpenShift Logging Operator는 ClusterLogging CR을 감시하고 그에 따라 로깅 배포를 조정합니다.
  • ClusterLogForwarder (CLF) - 사용자 구성별로 로그를 전달하도록 수집기 구성을 생성합니다.

ScanSetting Operator:

  • MellanoxStack - CloudEvent 클러스터를 로그 저장소로 제어하고 OpenShift Container Platform 인증 통합을 통해 웹 프록시를 제어하여 멀티 테넌시를 적용합니다.

OpenShift Elasticsearch Operator:

참고

이러한 CR은 OpenShift Elasticsearch Operator에서 생성하고 관리합니다. Operator에서 덮어쓰지 않고 수동 변경을 수행할 수 없습니다.

  • Elasticsearch - Elasticsearch 인스턴스를 기본 로그 저장소로 구성하고 배포합니다.
  • Kibana - 로그를 검색, 쿼리 및 볼 수 있도록 Kibana 인스턴스를 구성하고 배포합니다.

4.2.2. JSON OpenShift Container Platform 로깅 정보

JSON 로깅을 사용하여 JSON 문자열을 구조화된 오브젝트로 구문 분석하도록 Log Forwarding API를 구성할 수 있습니다. 다음 작업을 수행할 수 있습니다.

  • JSON 로그 구문 분석
  • Elasticsearch의 JSON 로그 데이터 구성
  • Elasticsearch 로그 저장소로 JSON 로그 전달

4.2.3. Kubernetes 이벤트 수집 및 저장 정보

OpenShift Container Platform 이벤트 라우터는 Kubernetes 이벤트를 감시하고 OpenShift Container Platform 로깅의 수집을 위해 해당 이벤트를 기록하는 Pod입니다. 이벤트 라우터를 수동으로 배포해야 합니다.

자세한 내용은 Kubernetes 이벤트 수집 및 저장을 참조하십시오.

4.2.4. OpenShift Container Platform 로깅 문제 해결 정보

다음 작업을 수행하여 로깅 문제를 해결할 수 있습니다.

  • 로깅 상태 보기
  • 로그 저장소의 상태 보기
  • 로깅 경고 이해
  • Red Hat 지원을 위한 로깅 데이터 수집
  • 심각한 경고 문제 해결

4.2.5. 필드 내보내기 정보

로깅 시스템 내보내기 필드입니다. 내보낸 필드는 로그 레코드에 있으며 Elasticsearch 및 Kibana에서 검색할 수 있습니다.

자세한 내용은 내보내기 필드 정보를 참조하십시오.

4.2.6. 이벤트 라우팅 정보

이벤트 라우터는 로깅을 통해 수집할 수 있도록 OpenShift Container Platform 이벤트를 감시하는 Pod입니다. 이벤트 라우터는 모든 프로젝트에서 이벤트를 수집하여 STDOUT에 씁니다. Fluentd는 이러한 이벤트를 수집하여 OpenShift Container Platform Elasticsearch 인스턴스로 전달합니다. Elasticsearch는 이벤트를 인프라 인덱스에 인덱싱합니다.

이벤트 라우터를 수동으로 배포해야 합니다.

자세한 내용은 Kubernetes 이벤트 수집 및 저장을 참조하십시오.

5장. 로깅 설치

Red Hat OpenShift Logging Operator를 설치하여 로깅을 배포할 수 있습니다. Red Hat OpenShift Logging Operator는 로깅 스택의 구성 요소를 생성하고 관리합니다.

참고

로깅은 핵심 OpenShift Container Platform과 별도의 릴리스 주기와 함께 설치 가능한 구성 요소로 제공됩니다. Red Hat OpenShift Container Platform 라이프 사이클 정책은 릴리스 호환성에 대해 간단히 설명합니다.

중요

새 설치의 경우 Vector 및 LokiStack을 사용합니다. Elasticsearch 및 Fluentd는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다.

5.1. 웹 콘솔을 사용하여 Red Hat OpenShift Logging Operator 설치

OpenShift Container Platform 웹 콘솔을 사용하여 Red Hat OpenShift Logging Operator를 설치할 수 있습니다.

사전 요구 사항

  • 관리자 권한이 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
  2. 키워드로 필터링 상자에 OpenShift Logging 을 입력합니다.
  3. 사용 가능한 Operator 목록에서 Red Hat OpenShift Logging을 선택한 다음 설치를 클릭합니다.
  4. 설치 모드에서 클러스터의 특정 네임스페이스 가 선택되어 있는지 확인합니다.
  5. 설치된 네임스페이스에서 Operator 권장 네임스페이스openshift-logging인지 확인하십시오.
  6. 이 네임스페이스에서 Operator 권장 클러스터 모니터링 사용을 선택합니다.

    이 옵션은 Namespace 오브젝트에서 openshift.io/cluster-monitoring: "true" 라벨을 설정합니다. 클러스터 모니터링이 openshift-logging 네임스페이스를 스크랩하도록 하려면 이 옵션을 선택해야 합니다.

  7. stable-5.y업데이트 채널로 선택합니다.

    참고

    stable 채널은 최신 로깅 릴리스에 대한 업데이트만 제공합니다. 이전 릴리스에 대한 업데이트를 계속 받으려면 서브스크립션 채널을 stable-x.y 로 변경해야 합니다. 여기서 x.y 는 설치한 로깅 및 마이너 버전을 나타냅니다. 예를 들면 stable-5.7 입니다.

  8. 업데이트 승인을 선택합니다.

    • 자동 전략을 사용하면 Operator 새 버전이 준비될 때 OLM(Operator Lifecycle Manager)이 자동으로 Operator를 업데이트할 수 있습니다.
    • 수동 전략을 사용하려면 적절한 자격 증명을 가진 사용자가 Operator 업데이트를 승인해야 합니다.
  9. 콘솔 플러그인에 대해 활성화 또는 비활성화 선택합니다.
  10. 설치를 클릭합니다.

검증

  1. Operator → 설치된 Operator 페이지로 전환하여 Red Hat OpenShift Logging Operator 설치되었는지 확인합니다.
  2. 상태 열에서 InstallSucceeded 가 포함된 녹색 확인 표시와 최대 날짜 텍스트가 표시되는지 확인합니다.
중요

Operator는 설치가 완료되기 전에 실패 상태를 표시할 수 있습니다. Operator 설치가 InstallSucceeded 메시지와 함께 완료되면 페이지를 새로 고칩니다.

Operator가 설치된 것으로 표시되지 않으면 다음 문제 해결 옵션 중 하나를 선택합니다.

  • Operator → 설치된 Operator 페이지로 이동하여 상태 열에 오류 또는 실패가 있는지 검사합니다.
  • 워크로드Pod 페이지로 이동하여 openshift-logging 프로젝트에서 문제를 보고하는 Pod의 로그를 확인합니다.

5.2. 웹 콘솔을 사용하여 ClusterLogging 오브젝트 생성

로깅 Operator를 설치한 후 클러스터의 로그 스토리지, 시각화 및 로그 수집기를 구성하려면 ClusterLogging 사용자 정의 리소스를 생성해야 합니다.

사전 요구 사항

  • Red Hat OpenShift Logging Operator가 설치되어 있습니다.
  • OpenShift Container Platform 웹 콘솔 관리자 화면에 액세스할 수 있습니다.

프로세스

  1. Custom Resource Definitions 페이지로 이동합니다.
  2. 사용자 정의 리소스 정의 페이지에서 ClusterLogging을 클릭합니다.
  3. 사용자 정의 리소스 정의 상세 정보 페이지의 작업 메뉴에서 인스턴스 보기를 선택합니다.
  4. ClusterLoggings 페이지에서 ClusterLogging 생성을 클릭합니다.
  5. 컬렉션 섹션에서 수집기 구현을 선택합니다.

    참고

    Fluentd는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않습니다. Fluentd 대신 Vector를 사용할 수 있습니다.

  6. logStore 섹션에서 유형을 선택합니다.

    참고

    로깅 5.9 릴리스에는 업데이트된 OpenShift Elasticsearch Operator 버전이 포함되어 있지 않습니다. 현재 Logging 5.8과 함께 릴리스된 OpenShift Elasticsearch Operator를 사용하는 경우 로깅 5.8의 EOL까지 로깅에서 계속 작동합니다. OpenShift Elasticsearch Operator를 사용하여 기본 로그 스토리지를 관리하는 대신 Loki Operator를 사용할 수 있습니다. 로깅 라이프사이클 날짜에 대한 자세한 내용은 Platform Agnostic Operators 를 참조하십시오.

  7. 생성을 클릭합니다.

5.3. CLI를 사용하여 Red Hat OpenShift Logging Operator 설치

OpenShift CLI(oc)를 사용하여 Red Hat OpenShift Logging Operator를 설치할 수 있습니다.

사전 요구 사항

  • 관리자 권한이 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. Namespace 오브젝트를 YAML 파일로 생성합니다.

    Namespace 오브젝트의 예

    apiVersion: v1
    kind: Namespace
    metadata:
      name: <name> 1
      annotations:
        openshift.io/node-selector: ""
      labels:
        openshift.io/cluster-monitoring: "true"

    1
    로깅 버전 5.7 및 이전 버전의 네임스페이스 이름으로 openshift-logging 을 지정해야 합니다. 로깅 5.8 이상 버전의 경우 모든 이름을 사용할 수 있습니다.
  2. 다음 명령을 실행하여 Namespace 오브젝트를 적용합니다.

    $ oc apply -f <filename>.yaml
  3. OperatorGroup 오브젝트를 YAML 파일로 생성합니다.

    OperatorGroup 오브젝트의 예

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: cluster-logging
      namespace: openshift-logging 1
    spec:
      targetNamespaces:
      - openshift-logging 2

    1 2
    로깅 버전 5.7 이상에는 openshift-logging 네임스페이스를 지정해야 합니다. 로깅 5.8 이상 버전의 경우 모든 네임스페이스를 사용할 수 있습니다.
  4. 다음 명령을 실행하여 OperatorGroup 오브젝트를 적용합니다.

    $ oc apply -f <filename>.yaml
  5. Red Hat OpenShift Logging Operator에 네임스페이스를 서브스크립션하는 Subscription 오브젝트를 생성합니다.

    Subscription 개체 예

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: cluster-logging
      namespace: openshift-logging 1
    spec:
      channel: stable 2
      name: cluster-logging
      source: redhat-operators 3
      sourceNamespace: openshift-marketplace

    1
    로깅 버전 5.7 이상에는 openshift-logging 네임스페이스를 지정해야 합니다. 로깅 5.8 이상 버전의 경우 모든 네임스페이스를 사용할 수 있습니다.
    2
    stable 또는 stable-x.y 를 채널로 지정합니다.
    3
    redhat-operators를 지정합니다. OpenShift Container Platform 클러스터가 제한된 네트워크(연결이 끊긴 클러스터)에 설치된 경우 OLM(Operator Lifecycle Manager)을 구성할 때 생성된 CatalogSource 오브젝트의 이름을 지정합니다.
  6. 다음 명령을 실행하여 서브스크립션을 적용합니다.

    $ oc apply -f <filename>.yaml

    Red Hat OpenShift Logging Operator는 openshift-logging 네임스페이스에 설치됩니다.

검증

  1. 다음 명령을 실행합니다.

    $ oc get csv -n <namespace>
  2. 출력을 관찰하고 네임스페이스에 Red Hat OpenShift Logging Operator가 있는지 확인합니다.

    출력 예

    NAMESPACE                                               NAME                                         DISPLAY                  VERSION               REPLACES   PHASE
    ...
    openshift-logging                                       clusterlogging.5.8.0-202007012112.p0         OpenShift Logging          5.8.0-202007012112.p0              Succeeded
    ...

5.4. CLI를 사용하여 ClusterLogging 오브젝트 생성

이 기본 로깅 구성은 다양한 환경을 지원합니다. 수행할 수 있는 수정 사항에 대한 정보는 구성 요소 튜닝 및 구성 주제를 검토하십시오.

사전 요구 사항

  • Red Hat OpenShift Logging Operator가 설치되어 있습니다.
  • 로그 저장소에 대해 OpenShift Elasticsearch Operator를 설치했습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. ClusterLogging 오브젝트를 YAML 파일로 생성합니다.

    ClusterLogging 오브젝트의 예

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
      name: instance 1
      namespace: openshift-logging
    spec:
      managementState: Managed 2
      logStore:
        type: elasticsearch 3
        retentionPolicy: 4
          application:
            maxAge: 1d
          infra:
            maxAge: 7d
          audit:
            maxAge: 7d
        elasticsearch:
          nodeCount: 3 5
          storage:
            storageClassName: <storage_class_name> 6
            size: 200G
          resources: 7
              limits:
                memory: 16Gi
              requests:
                memory: 16Gi
          proxy: 8
            resources:
              limits:
                memory: 256Mi
              requests:
                memory: 256Mi
          redundancyPolicy: SingleRedundancy
      visualization:
        type: kibana 9
        kibana:
          replicas: 1
      collection:
        type: fluentd 10
        fluentd: {}

    1
    이름은 instance이어야 합니다.
    2
    OpenShift Logging 관리 상태입니다. 경우에 따라 OpenShift Logging 기본값을 변경하는 경우 이를 Unmanaged로 설정해야 합니다. 그러나 관리되지 않는 배포는 OpenShift Logging이 다시 Managed 상태로 될 때까지 업데이트를 받지 않습니다.
    3
    Elasticsearch 구성을 위한 설정입니다. CR을 사용하여 shard 복제 정책 및 영구 스토리지를 구성할 수 있습니다.
    4
    Elasticsearch가 각 로그 소스를 유지해야 하는 시간을 지정합니다. 정수 및 시간 지정을 입력합니다(주(w), 시간(h/H), 분(m) 및 초(s)). 예를 들어 7일은 7d입니다. maxAge보다 오래된 로그는 삭제됩니다. 각 로그 소스에 대한 보존 정책을 지정해야 합니다. 그렇지 않으면 해당 소스에 대해 Elasticsearch 인덱스가 생성되지 않습니다.
    5
    Elasticsearch 노드 수를 지정합니다. 이 목록 뒤에 나오는 참고 사항을 참조하십시오.
    6
    Elasticsearch 스토리지의 기존 스토리지 클래스 이름을 입력합니다. 최상의 성능을 위해서는 블록 스토리지를 할당하는 스토리지 클래스를 지정합니다. 스토리지 클래스를 지정하지 않으면 OpenShift Logging은 임시 스토리지를 사용합니다.
    7
    필요에 따라 Elasticsearch에 대한 CPU 및 메모리 요청을 지정합니다. 이 값을 비워 두면 OpenShift Elasticsearch Operator가 대부분의 배포에 충분한 기본값으로 설정합니다. 기본값은 메모리 요청 시 16Gi이고 CPU 요청 시 1입니다.
    8
    필요에 따라 Elasticsearch 프록시에 대한 CPU 및 메모리 요청을 지정합니다. 이 값을 비워 두면 OpenShift Elasticsearch Operator가 대부분의 배포에 충분한 기본값으로 설정합니다. 기본값은 메모리 요청 시 256Mi이고 CPU 요청 시 100m입니다.
    9
    Kibana 구성을 위한 설정입니다. CR을 사용하여 중복성을 위해 Kibana를 확장하고 Kibana 노드의 CPU 및 메모리를 구성할 수 있습니다. 자세한 내용은 로그 시각화 프로그램 구성을 참조하십시오.
    10
    Fluentd 구성을 위한 설정입니다. CR을 사용하여 Fluentd CPU 및 메모리 제한을 구성할 수 있습니다. 자세한 내용은 " Fluentd 구성"을 참조하십시오.
    참고

    Elasticsearch 컨트롤 플레인 노드의 최대 수는 3입니다. 3보다 큰 nodeCount를 지정하면 OpenShift Container Platform은 마스터, 클라이언트 및 데이터 역할을 가진 마스터 적격 노드인 Elasticsearch 노드 3개를 생성합니다. 추가 Elasticsearch 노드는 클라이언트 및 데이터 역할을 사용하여 데이터 전용 노드로 생성됩니다. 컨트롤 플레인 노드는 인덱스 작성 또는 삭제, shard 할당 및 추적 노드와 같은 클러스터 전체 작업을 수행합니다. 데이터 노드는 shard를 보유하고 CRUD, 검색 및 집계와 같은 데이터 관련 작업을 수행합니다. 데이터 관련 작업은 I/O, 메모리 및 CPU 집약적입니다. 현재 노드에 과부하가 걸리면 이러한 리소스를 모니터링하고 더 많은 데이터 노드를 추가하는 것이 중요합니다.

    예를 들어 nodeCount = 4인 경우 다음 노드가 생성됩니다.

    $ oc get deployment

    출력 예

    NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
    cluster-logging-operator       1/1     1            1           18h
    elasticsearch-cd-x6kdekli-1    1/1     1            1          6m54s
    elasticsearch-cdm-x6kdekli-1   1/1     1            1           18h
    elasticsearch-cdm-x6kdekli-2   1/1     1            1           6m49s
    elasticsearch-cdm-x6kdekli-3   1/1     1            1           6m44s

    인덱스 템플릿의 기본 shard 수는 Elasticsearch 데이터 노드 수와 같습니다.

검증

openshift-logging 프로젝트에 Pod를 나열하여 설치를 확인할 수 있습니다.

  • 다음 명령을 실행하여 Pod를 나열합니다.

    $ oc get pods -n openshift-logging

    다음 목록과 유사하게 로깅 구성 요소의 Pod를 관찰합니다.

    출력 예

    NAME                                            READY   STATUS    RESTARTS   AGE
    cluster-logging-operator-66f77ffccb-ppzbg       1/1     Running   0          7m
    elasticsearch-cdm-ftuhduuw-1-ffc4b9566-q6bhp    2/2     Running   0          2m40s
    elasticsearch-cdm-ftuhduuw-2-7b4994dbfc-rd2gc   2/2     Running   0          2m36s
    elasticsearch-cdm-ftuhduuw-3-84b5ff7ff8-gqnm2   2/2     Running   0          2m4s
    collector-587vb                                   1/1     Running   0          2m26s
    collector-7mpb9                                   1/1     Running   0          2m30s
    collector-flm6j                                   1/1     Running   0          2m33s
    collector-gn4rn                                   1/1     Running   0          2m26s
    collector-nlgb6                                   1/1     Running   0          2m30s
    collector-snpkt                                   1/1     Running   0          2m28s
    kibana-d6d5668c5-rppqm                          2/2     Running   0          2m39s

5.5. 설치 후 작업

Red Hat OpenShift Logging Operator를 설치한 후 ClusterLogging 사용자 정의 리소스(CR)를 생성하고 수정하여 배포를 구성할 수 있습니다.

작은 정보

Elasticsearch 로그 저장소를 사용하지 않는 경우 ClusterLogging 사용자 정의 리소스(CR)에서 내부 Elasticsearch logStore 및 Kibana visualization 구성 요소를 제거할 수 있습니다. 이러한 구성 요소를 제거하는 것은 선택 사항이지만 리소스를 절약할 수 있습니다. Elasticsearch 로그 저장소를 사용하지 않는 경우 사용되지 않는 구성 요소 제거를 참조하십시오.

5.5.1. 클러스터 로깅 사용자 정의 리소스 정보

로깅 환경을 변경하려면 ClusterLogging 사용자 정의 리소스(CR)를 생성하고 수정합니다.

ClusterLogging 사용자 정의 리소스 (CR) 샘플

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance 1
  namespace: openshift-logging 2
spec:
  managementState: Managed 3
# ...

1
CR 이름은 instance여야 합니다.
2
CR은 openshift-logging 네임스페이스에 설치해야 합니다.
3
Red Hat OpenShift Logging Operator 관리 상태입니다. 상태가 Unmanaged 로 설정된 경우 Operator는 지원되지 않는 상태에 있으며 업데이트가 제공되지 않습니다.

5.5.2. 로그 스토리지 구성

ClusterLogging 사용자 정의 리소스(CR)를 수정하여 로깅에서 사용하는 로그 스토리지 유형을 구성할 수 있습니다.

사전 요구 사항

  • 관리자 권한이 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • Red Hat OpenShift Logging Operator와 LokiStack 또는 Elasticsearch인 내부 로그 저장소를 설치했습니다.
  • ClusterLogging CR을 생성했습니다.
참고

로깅 5.9 릴리스에는 업데이트된 OpenShift Elasticsearch Operator 버전이 포함되어 있지 않습니다. 현재 Logging 5.8과 함께 릴리스된 OpenShift Elasticsearch Operator를 사용하는 경우 로깅 5.8의 EOL까지 로깅에서 계속 작동합니다. OpenShift Elasticsearch Operator를 사용하여 기본 로그 스토리지를 관리하는 대신 Loki Operator를 사용할 수 있습니다. 로깅 라이프사이클 날짜에 대한 자세한 내용은 Platform Agnostic Operators 를 참조하십시오.

프로세스

  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

5.5.3. 로그 수집기 구성

ClusterLogging 사용자 정의 리소스(CR)를 수정하여 로깅에서 사용하는 로그 수집기 유형을 구성할 수 있습니다.

참고

Fluentd는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않습니다. Fluentd 대신 Vector를 사용할 수 있습니다.

사전 요구 사항

  • 관리자 권한이 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • Red Hat OpenShift Logging Operator가 설치되어 있습니다.
  • ClusterLogging CR을 생성했습니다.

프로세스

  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

5.5.4. 로그 시각화 프로그램 구성

ClusterLogging 사용자 정의 리소스(CR)를 수정하여 로깅에서 사용하는 로그 시각화 프로그램 유형을 구성할 수 있습니다.

사전 요구 사항

  • 관리자 권한이 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • Red Hat OpenShift Logging Operator가 설치되어 있습니다.
  • ClusterLogging CR을 생성했습니다.
중요

시각화에 OpenShift Container Platform 웹 콘솔을 사용하려면 로깅 콘솔 플러그인을 활성화해야 합니다. "웹 콘솔을 사용한 로그 시각화"에 대한 설명서를 참조하십시오.

프로세스

  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 로그 스토리지를 사용하는 배포와만 호환되며 OpenShift Container Platform 콘솔은 LokiStack 배포와만 호환됩니다.
    2
    Kibana 콘솔의 선택적 구성입니다.
    3
    OpenShift Container Platform 웹 콘솔의 선택적 구성입니다.
  2. 다음 명령을 실행하여 ClusterLogging CR을 적용합니다.

    $ oc apply -f <filename>.yaml

5.5.5. 네트워크 분리가 활성화될 때 프로젝트 간 트래픽 허용

클러스터 네트워크 플러그인에서 네트워크 분리를 적용할 수 있습니다. 이 경우 OpenShift Logging에서 배포한 operator가 포함된 프로젝트 간 네트워크 트래픽을 허용해야 합니다.

네트워크 분리는 다른 프로젝트에 있는 pod 또는 서비스 간의 네트워크 트래픽을 차단합니다. 로깅은 openshift-operators-redhat 프로젝트에 OpenShift Elasticsearch Operator 를 설치하고 openshift-logging 프로젝트에 Red Hat OpenShift Logging Operator 를 설치합니다. 따라서 이 두 프로젝트 간 트래픽을 허용해야 합니다.

OpenShift Container Platform은 네트워크 플러그인인 OpenShift SDN 및 OVN-Kubernetes에 대해 지원되는 두 가지 옵션을 제공합니다. 이 두 공급업체는 다양한 네트워크 분리 정책을 구현합니다.

OpenShift SDN에는 다음 세 가지 모드가 있습니다.

네트워크 정책
이는 기본값 모드입니다. 정책을 정의하지 않은 경우 모든 트래픽을 허용합니다. 그러나 사용자가 정책을 정의하는 경우 일반적으로 모든 트래픽을 거부한 다음 예외를 추가하여 시작합니다. 이 프로세스에서는 다른 프로젝트에서 실행 중인 애플리케이션을 중단할 수 있습니다. 따라서 하나의 로깅 관련 프로젝트에서 다른 프로젝트로 트래픽이 송신될 수 있도록 명시적으로 정책을 구성합니다.
다중 테넌트
이 모드에서는 네트워크 분리가 적용됩니다. 두 개의 로깅 관련 프로젝트에 참여하여 트래픽을 허용해야 합니다.
서브넷
이 모드에서는 모든 트래픽을 허용합니다. 네트워크 분리를 적용하지 않습니다. 아무 작업도 필요하지 않습니다.

OVN-Kubernetes는 항상 네트워크 정책을 사용합니다. 따라서 OpenShift SDN과 마찬가지로 하나의 로깅 관련 프로젝트에서 다른 프로젝트로 트래픽이 송신될 수 있도록 정책을 구성해야 합니다.

프로세스

  • 다중 테넌트 모드에서 OpenShift SDN을 사용하는 경우 두 프로젝트에 참여합니다. 예를 들면 다음과 같습니다.

    $ oc adm pod-network join-projects --to=openshift-operators-redhat openshift-logging
  • 또는 네트워크 정책 모드 및 OVN-Kubernetes의 OpenShift SDN의 경우 다음 작업을 수행합니다.

    1. openshift-operators-redhat 네임스페이스에서 레이블을 설정합니다. 예를 들면 다음과 같습니다.

      $ oc label namespace openshift-operators-redhat project=openshift-operators-redhat
    2. openshift-operators-redhat,openshift-monitoringopenshift-ingress 프로젝트에서 openshift-logging 프로젝트로 수신할 수 있는 openshift-logging 네임스페이스에 네트워크 정책 오브젝트를 생성합니다. 예를 들면 다음과 같습니다.

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-monitoring-ingress-operators-redhat
      spec:
        ingress:
        - from:
          - podSelector: {}
        - from:
          - namespaceSelector:
              matchLabels:
                project: "openshift-operators-redhat"
        - from:
          - namespaceSelector:
              matchLabels:
                name: "openshift-monitoring"
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: ingress
        podSelector: {}
        policyTypes:
        - Ingress

6장. 로깅 업데이트

로깅 업데이트에는 마이너 릴리스 업데이트(5.y.z) 및 주요 릴리스 업데이트(5.y)의 두 가지 유형이 있습니다.

6.1. 마이너 릴리스 업데이트

자동 업데이트 승인 옵션을 사용하여 로깅 Operator를 설치한 경우 Operator에 마이너 버전 업데이트가 자동으로 제공됩니다. 수동 업데이트 단계를 완료할 필요가 없습니다.

수동 업데이트 승인 옵션을 사용하여 로깅 Operator를 설치한 경우 마이너 버전 업데이트를 수동으로 승인해야 합니다.

자세한 내용은 보류 중인 Operator 업데이트 수동 승인 을 참조하십시오.

6.2. 주요 릴리스 업데이트

주요 버전 업데이트의 경우 일부 수동 단계를 완료해야 합니다.

주요 릴리스 버전 호환성 및 지원 정보는 OpenShift Operator 라이프 사이클 을 참조하십시오.

6.3. 모든 네임스페이스를 조사하도록 Red Hat OpenShift Logging Operator 업그레이드

로깅 5.7 이전 버전에서는 Red Hat OpenShift Logging Operator는 openshift-logging 네임스페이스만 감시합니다. Red Hat OpenShift Logging Operator에서 클러스터의 모든 네임스페이스를 조사하려면 Operator를 재배포해야 합니다. 로깅 구성 요소를 삭제하지 않고 Operator를 재배포하려면 다음 절차를 완료할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • 관리자 권한이 있습니다.

프로세스

  1. 다음 명령을 실행하여 서브스크립션을 삭제합니다.

    $ oc -n openshift-logging delete subscription <subscription>
  2. 다음 명령을 실행하여 Operator group을 삭제합니다.

    $ oc -n openshift-logging delete operatorgroup <operator_group_name>
  3. 다음 명령을 실행하여 CSV(클러스터 서비스 버전)를 삭제합니다.

    $ oc delete clusterserviceversion cluster-logging.<version>
  4. "로깅 설치" 설명서에 따라 Red Hat OpenShift Logging Operator를 재배포합니다.

검증

  • OperatorGroup 리소스의 targetNamespaces 필드가 없거나 빈 문자열로 설정되어 있는지 확인합니다.

    이렇게 하려면 다음 명령을 실행하고 출력을 검사합니다.

    $ oc get operatorgroup <operator_group_name> -o yaml

    출력 예

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: openshift-logging-f52cn
      namespace: openshift-logging
    spec:
      upgradeStrategy: Default
    status:
      namespaces:
      - ""
    # ...

6.4. Red Hat OpenShift Logging Operator 업데이트

Red Hat OpenShift Logging Operator를 새 주요 릴리스 버전으로 업데이트하려면 Operator 서브스크립션의 업데이트 채널을 수정해야 합니다.

사전 요구 사항

  • Red Hat OpenShift Logging Operator가 설치되어 있습니다.
  • 관리자 권한이 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스하고 관리자 화면을 보고 있습니다.

프로세스

  1. Operators설치된 Operator로 이동합니다.
  2. openshift-logging 프로젝트를 선택합니다.
  3. Red Hat OpenShift Logging Operator를 클릭합니다.
  4. 서브스크립션 을 클릭합니다. 서브스크립션 세부 정보 섹션에서 채널 업데이트 링크를 클릭합니다. 이 링크 텍스트는 현재 업데이트 채널에 따라 stable 또는 stable-5.y 일 수 있습니다.
  5. 서브스크립션 업데이트 채널 변경 창에서 최신 주요 버전 업데이트 채널, stable-5.y 를 선택하고 저장을 클릭합니다. cluster-logging.v5.y.z 버전을 확인합니다.

검증

  1. 몇 초 정도 기다린 후 Operator설치된 Operator를 클릭합니다. Red Hat OpenShift Logging Operator 버전이 최신 cluster-logging.v5.y.z 버전과 일치하는지 확인합니다.
  2. Operator설치된 Operator 페이지에서 Status 필드가 성공으로 표시될 때까지 기다립니다.

6.5. Loki Operator 업데이트

Loki Operator를 새 주요 릴리스 버전으로 업데이트하려면 Operator 서브스크립션의 업데이트 채널을 수정해야 합니다.

사전 요구 사항

  • Loki Operator를 설치했습니다.
  • 관리자 권한이 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스하고 관리자 화면을 보고 있습니다.

프로세스

  1. Operators설치된 Operator로 이동합니다.
  2. openshift-operators-redhat 프로젝트를 선택합니다.
  3. Loki Operator 를 클릭합니다.
  4. 서브스크립션 을 클릭합니다. 서브스크립션 세부 정보 섹션에서 채널 업데이트 링크를 클릭합니다. 이 링크 텍스트는 현재 업데이트 채널에 따라 stable 또는 stable-5.y 일 수 있습니다.
  5. 서브스크립션 업데이트 채널 변경 창에서 최신 주요 버전 업데이트 채널, stable-5.y 를 선택하고 저장을 클릭합니다. loki-operator.v5.y.z 버전을 확인합니다.

검증

  1. 몇 초 정도 기다린 후 Operator설치된 Operator를 클릭합니다. Loki Operator 버전이 최신 loki-operator.v5.y.z 버전과 일치하는지 확인합니다.
  2. Operator설치된 Operator 페이지에서 Status 필드가 성공으로 표시될 때까지 기다립니다.

6.6. OpenShift Elasticsearch Operator 업데이트

OpenShift Elasticsearch Operator를 현재 버전으로 업데이트하려면 서브스크립션을 수정해야 합니다.

참고

로깅 5.9 릴리스에는 업데이트된 OpenShift Elasticsearch Operator 버전이 포함되어 있지 않습니다. 현재 Logging 5.8과 함께 릴리스된 OpenShift Elasticsearch Operator를 사용하는 경우 로깅 5.8의 EOL까지 로깅에서 계속 작동합니다. OpenShift Elasticsearch Operator를 사용하여 기본 로그 스토리지를 관리하는 대신 Loki Operator를 사용할 수 있습니다. 로깅 라이프사이클 날짜에 대한 자세한 내용은 Platform Agnostic Operators 를 참조하십시오.

사전 요구 사항

  • Elasticsearch를 기본 로그 저장소로 사용하고 UI로 Kibana를 사용하는 경우 Red Hat OpenShift Logging Operator를 업데이트하기 전에 OpenShift Elasticsearch Operator를 업데이트합니다.

    중요

    Operator를 잘못된 순서로 업데이트하면 Kibana가 업데이트되지 않고 Kibana 사용자 정의 리소스(CR)가 생성되지 않습니다. 이 문제를 해결하려면 Red Hat OpenShift Logging Operator Pod를 삭제합니다. Red Hat OpenShift Logging Operator Pod가 재배포되면 Kibana CR을 생성하고 Kibana를 다시 사용할 수 있게 됩니다.

  • 로깅 상태가 정상입니다.

    • 모든 Pod의 상태가 ready 입니다.
    • Elasticsearch 클러스터는 정상입니다.
  • Elasticsearch 및 Kibana 데이터가 백업됩니다.
  • 관리자 권한이 있습니다.
  • 확인 단계를 위해 OpenShift CLI(oc)를 설치했습니다.

절차

  1. OpenShift Container Platform 웹 콘솔에서 Operator설치된 Operator를 클릭합니다.
  2. openshift-operators-redhat 프로젝트를 선택합니다.
  3. OpenShift Elasticsearch Operator 를 클릭합니다.
  4. 서브스크립션채널을 클릭합니다.
  5. 서브스크립션 업데이트 채널 변경 창에서 stable-5.y 를 선택하고 저장을 클릭합니다. elasticsearch-operator.v5.y.z 버전을 확인합니다.
  6. 몇 초 정도 기다린 후 Operator설치된 Operator를 클릭합니다. OpenShift Elasticsearch Operator 버전이 최신 elasticsearch-operator.v5.y.z 버전과 일치하는지 확인합니다.
  7. Operator설치된 Operator 페이지에서 Status 필드가 성공으로 표시될 때까지 기다립니다.

검증

  1. 다음 명령을 입력하고 출력을 관찰하여 모든 Elasticsearch Pod의 상태가 Ready 인지 확인합니다.

    $ oc get pod -n openshift-logging --selector component=elasticsearch

    출력 예

    NAME                                            READY   STATUS    RESTARTS   AGE
    elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk   2/2     Running   0          31m
    elasticsearch-cdm-1pbrl44l-2-5c6d87589f-gx5hk   2/2     Running   0          30m
    elasticsearch-cdm-1pbrl44l-3-88df5d47-m45jc     2/2     Running   0          29m

  2. 다음 명령을 입력하고 출력을 관찰하여 Elasticsearch 클러스터 상태가 녹색 인지 확인합니다.

    $ oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk -- health

    출력 예

    {
      "cluster_name" : "elasticsearch",
      "status" : "green",
    }

  3. 다음 명령을 입력하고 출력을 관찰하여 Elasticsearch cron 작업이 생성되었는지 확인합니다.

    $ oc project openshift-logging
    $ oc get cronjob

    출력 예

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

  4. 다음 명령을 입력하고 출력을 관찰하여 로그 저장소가 올바른 버전으로 업데이트되고 인덱스가 녹색 인지 확인합니다.

    $ oc exec -c elasticsearch <any_es_pod_in_the_cluster> -- indices

    출력에 app-00000x,infra-00000x,audit-00000x,.security 인덱스가 포함되어 있는지 확인합니다.

    예 6.1. 인덱스가 녹색 상태인 샘플 출력

    Tue Jun 30 14:30:54 UTC 2020
    health status index                                                                 uuid                   pri rep docs.count docs.deleted store.size pri.store.size
    green  open   infra-000008                                                          bnBvUFEXTWi92z3zWAzieQ   3 1       222195            0        289            144
    green  open   infra-000004                                                          rtDSzoqsSl6saisSK7Au1Q   3 1       226717            0        297            148
    green  open   infra-000012                                                          RSf_kUwDSR2xEuKRZMPqZQ   3 1       227623            0        295            147
    green  open   .kibana_7                                                             1SJdCqlZTPWlIAaOUd78yg   1 1            4            0          0              0
    green  open   infra-000010                                                          iXwL3bnqTuGEABbUDa6OVw   3 1       248368            0        317            158
    green  open   infra-000009                                                          YN9EsULWSNaxWeeNvOs0RA   3 1       258799            0        337            168
    green  open   infra-000014                                                          YP0U6R7FQ_GVQVQZ6Yh9Ig   3 1       223788            0        292            146
    green  open   infra-000015                                                          JRBbAbEmSMqK5X40df9HbQ   3 1       224371            0        291            145
    green  open   .orphaned.2020.06.30                                                  n_xQC2dWQzConkvQqei3YA   3 1            9            0          0              0
    green  open   infra-000007                                                          llkkAVSzSOmosWTSAJM_hg   3 1       228584            0        296            148
    green  open   infra-000005                                                          d9BoGQdiQASsS3BBFm2iRA   3 1       227987            0        297            148
    green  open   infra-000003                                                          1-goREK1QUKlQPAIVkWVaQ   3 1       226719            0        295            147
    green  open   .security                                                             zeT65uOuRTKZMjg_bbUc1g   1 1            5            0          0              0
    green  open   .kibana-377444158_kubeadmin                                           wvMhDwJkR-mRZQO84K0gUQ   3 1            1            0          0              0
    green  open   infra-000006                                                          5H-KBSXGQKiO7hdapDE23g   3 1       226676            0        295            147
    green  open   infra-000001                                                          eH53BQ-bSxSWR5xYZB6lVg   3 1       341800            0        443            220
    green  open   .kibana-6                                                             RVp7TemSSemGJcsSUmuf3A   1 1            4            0          0              0
    green  open   infra-000011                                                          J7XWBauWSTe0jnzX02fU6A   3 1       226100            0        293            146
    green  open   app-000001                                                            axSAFfONQDmKwatkjPXdtw   3 1       103186            0        126             57
    green  open   infra-000016                                                          m9c1iRLtStWSF1GopaRyCg   3 1        13685            0         19              9
    green  open   infra-000002                                                          Hz6WvINtTvKcQzw-ewmbYg   3 1       228994            0        296            148
    green  open   infra-000013                                                          KR9mMFUpQl-jraYtanyIGw   3 1       228166            0        298            148
    green  open   audit-000001                                                          eERqLdLmQOiQDFES1LBATQ   3 1            0            0          0              0
  5. 다음 명령을 입력하고 출력을 관찰하여 로그 시각화 프로그램이 올바른 버전으로 업데이트되었는지 확인합니다.

    $ oc get kibana kibana -o json

    출력에 ready 상태가 있는 Kibana pod가 포함되어 있는지 확인합니다.

    예 6.2. Kibana Pod가 준비된 샘플 출력

    [
    {
    "clusterCondition": {
    "kibana-5fdd766ffd-nb2jj": [
    {
    "lastTransitionTime": "2020-06-30T14:11:07Z",
    "reason": "ContainerCreating",
    "status": "True",
    "type": ""
    },
    {
    "lastTransitionTime": "2020-06-30T14:11:07Z",
    "reason": "ContainerCreating",
    "status": "True",
    "type": ""
    }
    ]
    },
    "deployment": "kibana",
    "pods": {
    "failed": [],
    "notReady": []
    "ready": []
    },
    "replicaSets": [
    "kibana-5fdd766ffd"
    ],
    "replicas": 1
    }
    ]

7장. 로그 시각화

7.1. 로그 시각화 정보

배포된 로그 스토리지 솔루션에 따라 OpenShift Container Platform 웹 콘솔 또는 Kibana 웹 콘솔에서 로그 데이터를 시각화할 수 있습니다. Kibana 콘솔은 ElasticSearch 로그 저장소와 함께 사용할 수 있으며 OpenShift Container Platform 웹 콘솔은 ElasticSearch 로그 저장소 또는 LokiStack과 함께 사용할 수 있습니다.

참고

Kibana 웹 콘솔은 향후 로깅 릴리스에서 더 이상 사용되지 않습니다.

7.1.1. 로그 시각화 프로그램 구성

ClusterLogging 사용자 정의 리소스(CR)를 수정하여 로깅에서 사용하는 로그 시각화 프로그램 유형을 구성할 수 있습니다.

사전 요구 사항

  • 관리자 권한이 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • Red Hat OpenShift Logging Operator가 설치되어 있습니다.
  • ClusterLogging CR을 생성했습니다.
중요

시각화에 OpenShift Container Platform 웹 콘솔을 사용하려면 로깅 콘솔 플러그인을 활성화해야 합니다. "웹 콘솔을 사용한 로그 시각화"에 대한 설명서를 참조하십시오.

절차

  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 로그 스토리지를 사용하는 배포와만 호환되며 OpenShift Container Platform 콘솔은 LokiStack 배포와만 호환됩니다.
    2
    Kibana 콘솔의 선택적 구성입니다.
    3
    OpenShift Container Platform 웹 콘솔의 선택적 구성입니다.
  2. 다음 명령을 실행하여 ClusterLogging CR을 적용합니다.

    $ oc apply -f <filename>.yaml

7.1.2. 리소스의 로그 보기

리소스 로그는 제한된 로그 보기 기능을 제공하는 기본 기능입니다. OpenShift CLI(oc) 및 웹 콘솔을 사용하여 빌드, 배포 및 Pod와 같은 다양한 리소스의 로그를 볼 수 있습니다.

작은 정보

로그 검색 및 보기 환경을 개선하려면 로깅을 설치합니다. 로깅은 노드 시스템 감사 로그, 애플리케이션 컨테이너 로그 및 인프라 로그와 같은 OpenShift Container Platform 클러스터의 모든 로그를 전용 로그 저장소로 집계합니다. 그런 다음 Kibana 콘솔 또는 OpenShift Container Platform 웹 콘솔을 통해 로그 데이터를 쿼리, 검색 및 시각화할 수 있습니다. 리소스 로그는 로깅 로그 저장소에 액세스하지 않습니다.

7.1.2.1. 리소스 로그 보기

OpenShift CLI(oc) 및 웹 콘솔에서 다양한 리소스의 로그를 볼 수 있습니다. 로그는 로그의 말미 또는 끝에서 읽습니다.

사전 요구 사항

  • OpenShift CLI(oc)에 액세스합니다.

프로세스(UI)

  1. OpenShift Container Platform 콘솔에서 워크로드Pod로 이동하거나 조사하려는 리소스를 통해 Pod로 이동합니다.

    참고

    빌드와 같은 일부 리소스에는 직접 쿼리할 Pod가 없습니다. 이러한 인스턴스에서 리소스의 세부 정보 페이지에서 로그 링크를 찾을 수 있습니다.

  2. 드롭다운 메뉴에서 프로젝트를 선택합니다.
  3. 조사할 Pod 이름을 클릭합니다.
  4. 로그를 클릭합니다.

프로세스(CLI)

  • 특정 Pod의 로그를 확인합니다.

    $ oc logs -f <pod_name> -c <container_name>

    다음과 같습니다.

    -f
    선택 사항: 출력에서 로그에 기록되는 내용을 따르도록 지정합니다.
    <pod_name>
    pod 이름을 지정합니다.
    <container_name>
    선택 사항: 컨테이너의 이름을 지정합니다. Pod에 여러 컨테이너가 있는 경우 컨테이너 이름을 지정해야 합니다.

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

    $ oc logs ruby-58cd97df55-mww7r
    $ oc logs -f ruby-57f7f4855b-znl92 -c ruby

    로그 파일의 내용이 출력됩니다.

  • 특정 리소스의 로그를 확인합니다.

    $ oc logs <object_type>/<resource_name> 1
    1
    리소스 유형 및 이름을 지정합니다.

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

    $ oc logs deployment/ruby

    로그 파일의 내용이 출력됩니다.

7.2. 웹 콘솔을 사용한 로그 시각화

OpenShift Container Platform 웹 콘솔을 사용하여 로깅 콘솔 플러그인을 구성하여 로그 데이터를 시각화할 수 있습니다.

로깅 설치 중에 플러그인을 구성하는 방법에 대한 자세한 내용은 웹 콘솔을 사용하여 로깅 설치를 참조하십시오.

이미 로깅을 설치하고 플러그인을 구성하려면 다음 절차 중 하나를 사용합니다.

7.2.1. Red Hat OpenShift Logging Operator를 설치한 후 로깅 콘솔 플러그인 활성화

Red Hat OpenShift Logging Operator 설치의 일부로 로깅 콘솔 플러그인을 활성화할 수 있지만 플러그인이 비활성화된 상태에서 Red Hat OpenShift Logging Operator를 이미 설치한 경우 플러그인을 활성화할 수도 있습니다.

사전 요구 사항

  • 관리자 권한이 있습니다.
  • Red Hat OpenShift Logging Operator를 설치하고 Console 플러그인에 대해 Disabled 를 선택했습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.

절차

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

7.2.2. Elasticsearch 로그 저장소 및 LokiStack이 설치된 경우 로깅 콘솔 플러그인 구성

로깅 버전 5.8 이상에서는 Elasticsearch 로그 저장소가 기본 로그 저장소이지만 LokiStack도 설치한 경우 다음 절차를 사용하여 로깅 콘솔 플러그인을 활성화할 수 있습니다.

사전 요구 사항

  • 관리자 권한이 있습니다.
  • Red Hat OpenShift Logging Operator, OpenShift Elasticsearch Operator 및 Loki Operator를 설치했습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • ClusterLogging 사용자 정의 리소스(CR)를 생성했습니다.

절차

  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

검증

  • 다음 명령을 실행하고 출력을 관찰하여 주석이 성공적으로 추가되었는지 확인합니다.

    $ oc get clusterlogging instance \
    -o=jsonpath='{.metadata.annotations.logging\.openshift\.io/ocp-console-migration-target}' \
    -n openshift-logging

    출력 예

    "lokistack-dev"

이제 로깅 콘솔 플러그인 포드가 배포됩니다. OpenShift Container Platform 웹 콘솔로 이동하여 모니터링로그 페이지를 확인하여 로깅 데이터를 볼 수 있습니다.

7.3. 클러스터 대시보드 보기

OpenShift Container Platform 웹 콘솔의 로깅/Elasticsearch 노드 및 Openshift 로깅 대시보드에는 문제를 방지하고 진단하는 데 사용할 수 있는 Elasticsearch 인스턴스 및 개별 Elasticsearch 노드에 대한 자세한 정보가 포함되어 있습니다.

OpenShift 로깅 대시보드에는 클러스터 리소스, 가비지 수집, 클러스터의 shard 및 Fluentd 통계를 포함하여 클러스터 수준에서 Elasticsearch 인스턴스에 대한 세부 정보를 보여주는 차트가 포함되어 있습니다.

로깅/Elasticsearch 노드 대시보드에는 인덱싱, shard, 리소스 등에 대한 세부 정보를 포함하여 노드 수준에서 많은 Elasticsearch 인스턴스에 대한 세부 정보를 보여주는 차트가 포함되어 있습니다.

7.3.1. Elasticsearch 및 OpenShift Logging 대시보드에 액세스

OpenShift Container Platform 웹 콘솔에서 로깅/Elasticsearch 노드OpenShift Logging 대시보드를 볼 수 있습니다.

절차

대시보드를 시작하려면 다음을 수행합니다.

  1. OpenShift Container Platform 웹 콘솔에서 ObserveDashboards 를 클릭합니다.
  2. 대시보드 페이지의 대시보드 메뉴에서 로깅/Elasticsearch 노드 또는 OpenShift Logging 을 선택합니다.

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

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

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

대시보드 차트에 대한 자세한 내용은 OpenShift 로깅 대시보드 정보 및 로깅 /Elastisearch 노드 대시보드 정보를 참조하십시오.

7.3.2. OpenShift 로깅 대시보드 정보

OpenShift 로깅 대시보드에는 문제를 진단하고 예측하는 데 사용할 수 있는 클러스터 수준에서 Elasticsearch 인스턴스에 대한 세부 정보를 보여주는 차트가 포함되어 있습니다.

표 7.1. OpenShift 로깅 차트
지표설명

Elastic 클러스터 상태

현재 Elasticsearch 상태:

  • 온라인 - Elasticsearch 인스턴스가 온라인 상태임을 나타냅니다.
  • 오프라인 - Elasticsearch 인스턴스가 오프라인 상태임을 나타냅니다.

Elastic 노드

Elasticsearch 인스턴스의 총 Elasticsearch 노드 수입니다.

Elastic Shard

Elasticsearch 인스턴스의 총 Elasticsearch shard 수입니다.

Elastic 문서

Elasticsearch 인스턴스의 총 Elasticsearch 문서 수입니다.

디스크의 총 인덱스 크기

Elasticsearch 인덱스에 사용 중인 총 디스크 공간입니다.

Elastic 보류 작업

인덱스 생성, 인덱스 매핑, shard 할당 또는 shard 오류와 같이 완료되지 않은 Elasticsearch 변경의 총 수입니다.

Elastic JVM GC 시간

JVM이 클러스터에서 Elasticsearch 가비지 수집 작업을 실행하는 데 소비한 시간입니다.

Elastic JVM GC 속도

JVM이 초당 가비지 활동을 실행한 총 횟수입니다.

Elastic 쿼리/가져오기 대기 시간 합계

  • 쿼리 대기 시간: 각 Elasticsearch 검색 쿼리를 실행하는 데 걸리는 평균 시간입니다.
  • 가져오기 대기 시간: 각 Elasticsearch 검색 쿼리가 데이터를 가져오는 데 소요되는 평균 시간입니다.

가져오기 대기 시간은 일반적으로 쿼리 대기 시간보다 더 짧습니다. 가져오기 대기 시간이 지속적으로 증가하는 경우 느린 디스크, 데이터 보강 또는 결과가 너무 많은 대규모 요청을 나타낼 수 있습니다.

Elastic 쿼리 속도

각 Elasticsearch 노드에 대해 Elasticsearch 인스턴스에 대해 실행된 초당 총 쿼리입니다.

CPU

Elasticsearch, Fluentd 및 Kibana에서 사용하는 CPU 양(각 구성 요소에 대해 표시됨).

사용된 Elastic JVM 힙

사용된 JVM 메모리 양입니다. 정상 클러스터에서 그래프는 JVM 가비지 수집에 의해 메모리가 해제됨에 따라 정기적으로 감소를 표시합니다.

Elasticsearch 디스크 사용량

각 Elasticsearch 노드에 대해 Elasticsearch 인스턴스에서 사용하는 총 디스크 공간입니다.

사용 중인 파일 설명자

Elasticsearch, Fluentd 및 Kibana에서 사용하는 총 파일 설명자 수입니다.

FluentD 방출 수

Fluentd 기본 출력에 대한 초당 총 Fluentd 메시지 수 및 기본 출력에 대한 재시도 횟수입니다.

Fluentd 버퍼 사용

청크에 사용되는 Fluentd 버퍼의 백분율입니다. 가득 찬 버퍼는 Fluentd가 수신된 로그 수를 처리할 수 없음을 나타낼 수 있습니다.

Elastic rx 바이트

Elasticsearch가 FluentD, Elasticsearch 노드 및 기타 소스에서 수신한 총 바이트 수입니다.

Elastic 인덱스 실패율

Elasticsearch 인덱스가 실패하는 초당 총 횟수입니다. 높은 비율은 인덱싱 문제를 나타낼 수 있습니다.

FluentD 출력 오류율

FluentD가 로그를 출력할 수 없는 초당 총 횟수입니다.

7.3.3. 로깅/Elasticsearch 노드 대시보드의 차트

로깅/Elasticsearch 노드 대시보드에는 추가 진단을 위해 많은 노드 수준에서 Elasticsearch 인스턴스에 대한 세부 정보를 보여주는 차트가 포함되어 있습니다.

Elasticsearch 상태
로깅/Elasticsearch 노드 대시보드에는 Elasticsearch 인스턴스의 상태에 대한 다음 차트가 포함되어 있습니다.
표 7.2. Elasticsearch 상태 필드
지표설명

클러스터 상태

Elasticsearch 녹색, 노란색 및 빨간색 상태를 사용하여 선택한 기간 동안의 클러스터 상태:

  • 0 - Elasticsearch 인스턴스가 녹색 상태임을 나타냅니다. 이는 모든 shard가 할당되었음을 의미합니다.
  • 1 - Elasticsearch 인스턴스가 노란색 상태임을 나타냅니다. 이는 하나 이상의 shard에 대한 복제본 shard가 할당되지 않았음을 의미합니다.
  • 2 - Elasticsearch 인스턴스가 빨간색 상태임을 나타냅니다. 이는 하나 이상의 기본 shard와 해당 복제본이 할당되지 않았음을 의미합니다.

클러스터 노드

클러스터의 총 Elasticsearch 노드 수입니다.

클러스터 데이터 노드

클러스터에 있는 Elasticsearch 데이터 노드의 수입니다.

클러스터 보류 작업

완료되지 않고 클러스터 큐에서 대기 중인 클러스터 상태 변경 수(예: 인덱스 생성, 인덱스 삭제 또는 shard 할당)입니다. 증가 추세는 클러스터가 변경 사항을 따라갈 수 없음을 나타냅니다.

Elasticsearch 클러스터 인덱스 shard 상태
각 Elasticsearch 인덱스는 지속되는 데이터의 기본 단위인 하나 이상의 shard로 구성된 논리적 그룹입니다. 인덱스 shard는 기본 shard와 복제본 shard의 두 가지 유형이 있습니다. 문서가 인덱스로 인덱싱되면 기본 shard 중 하나에 저장되고 해당 shard의 모든 복제본에 복사됩니다. 기본 shard의 수는 인덱스가 생성될 때 지정되며 인덱스 수명 중에는 변경할 수 없습니다. 언제든지 복제본 shard 수를 변경할 수 있습니다.

인덱스 shard는 수명 주기 단계 또는 클러스터에서 발생하는 이벤트에 따라 여러 상태가 될 수 있습니다. shard가 검색 및 인덱싱 요청을 수행할 수 있으면 shard가 활성화됩니다. shard가 이러한 요청을 수행할 수 없는 경우 shard는 비활성 상태입니다. shard가 초기화, 재할당, 할당 해제 등의 경우 shard는 비활성 상태일 수 있습니다.

인덱스 shard는 데이터의 물리적 표현인 인덱스 세그먼트라고 하는 여러 개의 작은 내부 블록으로 구성됩니다. 인덱스 세그먼트는 Lucene이 새로 인덱싱된 데이터를 커밋할 때 생성되는 비교적 작고 변경 불가능한 Lucene 인덱스입니다. Elasticsearch에서 사용하는 검색 라이브러리인 Lucene은 인덱스 세그먼트를 백그라운드에서 더 큰 세그먼트로 병합하여 총 세그먼트 수를 낮게 유지합니다. 세그먼트 병합 프로세스가 새 세그먼트가 생성되는 속도보다