2.2. Red Hat OpenShift의 로깅 하위 시스템 배포 정보
OpenShift Container Platform 클러스터 관리자는 OpenShift Container Platform 웹 콘솔 또는 CLI를 사용하여 로깅 하위 시스템을 배포하여 OpenShift Elasticsearch Operator 및 Red Hat OpenShift Logging Operator를 설치할 수 있습니다. Operator가 설치되면 ClusterLogging
사용자 정의 리소스(CR)를 생성하여 로깅 하위 시스템 Pod 및 로깅 하위 시스템을 지원하는 데 필요한 기타 리소스를 예약합니다. Operator는 로깅 하위 시스템의 배포, 업그레이드 및 유지 관리를 담당합니다.
ClusterLogging
CR은 로그를 수집, 저장 및 시각화하기 위해 로깅 스택의 모든 구성 요소를 포함하는 완전한 로깅 하위 시스템 환경을 정의합니다. Red Hat OpenShift Logging Operator는 로깅 하위 시스템 CR을 감시하고 그에 따라 로깅 배포를 조정합니다.
관리자와 애플리케이션 개발자는 보기 권한이 있는 프로젝트의 로그를 볼 수 있습니다.
자세한 내용은 로그 수집기 구성을 참조하십시오.
2.2.1. JSON OpenShift Container Platform 로깅 정보
JSON 로깅을 사용하여 구조화된 오브젝트로 JSON 문자열을 구문 분석하도록 Log Forwarding API를 구성할 수 있습니다. 다음 작업을 수행할 수 있습니다.
- JSON 로그 구문 분석
- Elasticsearch의 JSON 로그 데이터 구성
- Elasticsearch 로그 저장소로 JSON 로그를 전달
2.2.2. Kubernetes 이벤트 수집 및 저장 정보
OpenShift Container Platform 이벤트 라우터는 Kubernetes 이벤트를 감시하고 OpenShift Container Platform 로깅에 의한 수집을 위해 해당 이벤트를 기록하는 Pod입니다. 이벤트 라우터를 수동으로 배포해야 합니다.
자세한 내용은 Kubernetes 이벤트 수집 및 저장을 참조하십시오.
2.2.3. OpenShift Container Platform Logging 업데이트 정보
OpenShift Container Platform을 사용하면 OpenShift Container Platform 로깅을 업데이트할 수 있습니다. OpenShift Container Platform Logging을 업데이트하는 동안 다음 Operator를 업데이트해야 합니다.
- Elasticsearch Operator
- Cluster Logging Operator
자세한 내용은 OpenShift Container Platform 로깅 업데이트 정보를 참조하십시오.
2.2.4. 클러스터 대시보드 보기 정보
OpenShift Container Platform 로깅 대시보드에는 클러스터 수준에서 Elasticsearch 인스턴스에 대한 세부 정보를 보여주는 차트가 포함되어 있습니다. 이 차트는 문제를 진단하고 예측하는 데 도움이 됩니다.
자세한 내용은 클러스터 대시보드 보기 정보를 참조하십시오.
2.2.5. OpenShift Container Platform 로깅 문제 해결 정보
다음 작업을 수행하여 로깅 문제를 해결할 수 있습니다.
- 로깅 상태 보기
- 로그 저장소의 상태 보기
- 로깅 경고 이해
- Red Hat 지원을 위한 로깅 데이터 수집
- 심각한 경고 문제 해결
2.2.6. OpenShift Container Platform 로깅 설치 제거 정보
ClusterLogging 사용자 정의 리소스(CR)를 삭제하여 로그 집계를 중지할 수 있습니다. CR을 삭제한 후 다른 클러스터 로깅 구성 요소는 남아 있으며 선택적으로 제거할 수 있습니다.
자세한 내용은 OpenShift Container Platform 로깅 설치 제거를 참조하십시오.
2.2.7. 필드 내보내기 정보
로깅 시스템 내보내기 필드. 내보낸 필드는 로그 레코드에 있으며 Elasticsearch 및 Kibana에서 검색할 수 있습니다.
자세한 내용은 필드 내보내기 정보를 참조하십시오.
2.2.8. 로깅 하위 시스템 구성 요소 정보
로깅 하위 시스템 구성 요소에는 OpenShift Container Platform 클러스터의 각 노드에 배포된 수집기가 포함되어 있습니다. 이 수집기는 모든 노드와 컨테이너 로그를 수집하여 로그 저장소에 씁니다. 중앙 집중식 웹 UI에서 이렇게 집계된 데이터를 사용하여 고급 시각화 및 대시보드를 생성할 수 있습니다.
로깅 하위 시스템의 주요 구성 요소는 다음과 같습니다.
- 수집 - 클러스터에서 로그를 수집하고 형식을 지정한 후 로그 저장소로 전달하는 구성 요소입니다. 최신 구현은 Fluentd입니다.
- 로그 저장소 - 로그가 저장되는 위치입니다. 기본 구현은 Elasticsearch입니다. 기본 Elasticsearch 로그 저장소를 사용하거나 외부 로그 저장소로 로그를 전달할 수 있습니다. 기본 로그 저장소는 테스트를 거쳐 단기 스토리지용으로 최적화되었습니다.
- 시각화 - 로그, 그래프, 차트 등을 보는 데 사용할 수 있는 UI 구성 요소입니다. 최신 구현은 Kibana입니다.
이 문서에서는 달리 표시된 경우를 제외하고 로그 저장소와 Elasticsearch, 시각화와 Kibana, 수집과 Fluentd를 서로 바꾸어 사용할 수 있습니다.
2.2.9. 로깅 수집기 정보
Red Hat OpenShift의 로깅 하위 시스템은 컨테이너 및 노드 로그를 수집합니다.
기본적으로 로그 수집기는 다음 소스를 사용합니다.
- 모든 시스템 로그에 대한 journald
-
모든 컨테이너 로그에 대한
/var/log/containers/*.log
감사 로그를 수집하기 위해 로그 수집기를 구성하면 /var/log/audit/audit.log
에서 해당 로그를 가져옵니다.
로깅 수집기는 데몬 세트로 각 OpenShift Container Platform 노드에 Pod를 배포합니다. 시스템 및 인프라 로그는 journald가 운영 체제, 컨테이너 런타임 및 OpenShift Container Platform의 로그 메시지를 사용하여 생성합니다. 애플리케이션 로그는 CRI-O 컨테이너 엔진에 의해 생성됩니다. Fluentd는 이러한 소스에서 로그를 수집하여 OpenShift Container Platform의 구성에 따라 내부 또는 외부로 전달합니다.
컨테이너 런타임은 로그 메시지의 소스(프로젝트, Pod 이름 및 컨테이너 ID)를 식별하기 위한 최소한의 정보를 제공합니다. 이 정보로는 로그 소스를 고유하게 식별하기에 부족합니다. 로그 수집기에서 로그 처리를 시작하기 전에 지정된 이름과 프로젝트가 있는 Pod를 삭제하면 레이블 및 주석과 같은 API 서버의 정보를 사용할 수 없게 됩니다. 로그 메시지를 비슷한 이름의 Pod 및 프로젝트와 구별할 방법 또는 로그의 소스를 추적할 방법이 없을 수 있습니다. 이 제한은 로그 수집 및 정규화가 최선의 노력으로 간주된다는 의미입니다.
사용 가능한 컨테이너 런타임은 로그 메시지의 소스를 식별할 수 있는 최소한의 정보를 제공하며, 고유한 개별 로그 메시지 또는 그러한 메시지의 소스 추적을 보장하지 않습니다.
자세한 내용은 로그 수집기 구성을 참조하십시오.
2.2.10. 로그 저장소 정보
기본적으로 OpenShift Container Platform은 ES(Elasticsearch)를 사용하여 로그 데이터를 저장합니다. 선택적으로 Log Forwarder API를 사용하여 로그를 외부 저장소로 전달할 수 있습니다. fluentd, rsyslog, kafka 등 여러 유형의 저장소를 지원합니다.
로깅 하위 시스템 Elasticsearch 인스턴스는 약 7일 동안의 단기 스토리지용으로 최적화 및 테스트되었습니다. 로그를 장기간 유지하려면 데이터를 타사 스토리지 시스템으로 이동하는 것이 좋습니다.
Elasticsearch는 Fluentd의 로그 데이터를 데이터 저장소 또는 인덱스로 구성한 다음 각 인덱스를 shards라고 하는 조각 여러 개로 다시 세분화합니다. 그리고 이 조각을 Elasticsearch 클러스터의 Elasticsearch 노드 세트에 분산 배치합니다. 복제본이라는 이름의 shard 사본을 작성하도록 Elasticsearch를 구성할 수 있습니다. Elasticsearch는 이 역시 Elasticsearch 노드에 분산 배치합니다. ClusterLogging
사용자 정의 리소스(CR)를 사용하면 shard의 복제 방식을 지정하여 데이터 중복성과 장애에 대한 회복 탄력성을 제공할 수 있습니다. ClusterLogging
CR의 보존 정책을 사용하여 다양한 로그 유형의 보존 기간을 지정할 수도 있습니다.
인덱스 템플릿의 기본 shard 수는 Elasticsearch 데이터 노드 수와 같습니다.
Red Hat OpenShift Logging Operator 및 그에 동반되는 OpenShift Elasticsearch Operator는 각 Elasticsearch 노드가 자체 스토리지 볼륨이 있는 고유한 배포를 사용하여 배포되도록 합니다. 필요에 따라 ClusterLogging
사용자 정의 리소스(CR)를 사용하여 Elasticsearch 노드 수를 늘릴 수 있습니다. 스토리지 구성과 관련된 고려 사항은 Elasticsearch 설명서를 참조하십시오.
고가용성 Elasticsearch 환경에는 각각 서로 다른 호스트에 있는 최소 3개의 Elasticsearch 노드가 필요합니다.
Elasticsearch 인덱스에 적용된 RBAC(역할 기반 액세스 제어)를 사용하면 개발자에 대한 로그 액세스를 제어할 수 있습니다. 관리자는 모든 로그에 액세스할 수 있으며 개발자는 프로젝트의 로그에만 액세스할 수 있습니다.
자세한 내용은 로그 저장소 구성을 참조하십시오.
2.2.11. 로깅 시각화 정보
OpenShift Container Platform은 Kibana를 사용하여 Fluentd에서 수집하고 Elasticsearch에서 인덱싱된 로그 데이터를 표시합니다.
Kibana는 히스토그램, 선 그래프, 원형 차트 및 기타 시각화를 통해 Elasticsearch 데이터를 쿼리, 검색 및 시각화할 수 있는 브라우저 기반 콘솔 인터페이스입니다.
자세한 내용은 로그 시각화 프로그램 구성을 참조하십시오.
2.2.12. 이벤트 라우팅 정보
이벤트 라우터는 Red Hat OpenShift의 로깅 하위 시스템에서 수집할 수 있도록 OpenShift Container Platform 이벤트를 감시하는 Pod입니다. 이벤트 라우터는 모든 프로젝트에서 이벤트를 수집하여 STDOUT
에 씁니다. Fluentd는 이러한 이벤트를 수집하여 OpenShift Container Platform Elasticsearch 인스턴스로 전달합니다. Elasticsearch는 이벤트를 인프라
인덱스에 인덱싱합니다.
이벤트 라우터를 수동으로 배포해야 합니다.
자세한 내용은 Kubernetes 이벤트 수집 및 저장을 참조하십시오.
2.2.13. 로그 전송 정보
기본적으로 Red Hat OpenShift의 로깅 하위 시스템은 ClusterLogging
사용자 정의 리소스(CR)에 정의된 기본 내부 Elasticsearch 로그 저장소로 로그를 보냅니다. 로그를 기타 로그 집계기로 전달하려면 로그 전달 기능을 사용하여 클러스터 내부 또는 외부의 특정 끝점으로 로그를 보내면 됩니다.
자세한 내용은 타사 시스템으로 로그 전달을 참조하십시오.