3.3. 로깅 아키텍처 이해
로깅 하위 시스템은 다음과 같은 논리 구성 요소로 구성됩니다.
-
collector- 각 노드에서 컨테이너 로그 데이터를 읽고 구성된 출력으로 로그 데이터를 전달합니다. -
store - 분석을 위해 로그 데이터를
저장하며 전달자의 기본 출력입니다. -
시각화- 저장된 로그 검색, 쿼리 및 보기를 위한 그래픽 인터페이스입니다.
이러한 구성 요소는 Operator 및 CR(사용자 정의 리소스) YAML 파일에서 관리합니다.
Red Hat OpenShift의 로깅 하위 시스템은 컨테이너 로그 및 노드 로그를 수집합니다. 이는 다음과 같은 유형으로 분류됩니다.
-
애플리케이션- 인프라 이외의 컨테이너에서 생성한 컨테이너 로그입니다. -
인프라- 네임스페이스kube-*및openshift-\*의 컨테이너 로그 및journald의 노드 로그입니다. -
audit-auditd,kube-apiserver,openshift-apiserver,ovn(활성화된 경우)의 로그입니다.
로깅 수집기는 각 OpenShift Container Platform 노드에 Pod를 배포하는 데몬 세트입니다. 시스템 및 인프라 로그는 journald가 운영 체제, 컨테이너 런타임 및 OpenShift Container Platform의 로그 메시지를 사용하여 생성합니다.
컨테이너 로그는 클러스터에서 실행 중인 포드에서 실행 중인 컨테이너에 의해 생성됩니다. 각 컨테이너는 별도의 로그 스트림을 생성합니다. 수집기는 이러한 소스에서 로그를 수집하고 ClusterLogForwarder 사용자 정의 리소스에 구성된 대로 내부 또는 외부로 전달합니다.
3.3.1. 로깅에 대한 지원 고려 사항
로깅은 핵심 OpenShift Container Platform과 별도의 릴리스 주기와 함께 설치 가능한 구성 요소로 제공됩니다. Red Hat OpenShift Container Platform 라이프 사이클 정책은 릴리스 호환성에 대해 설명합니다.
Red Hat OpenShift에 대해 지원되는 로깅 하위 시스템을 구성하는 방법은 이 설명서에 설명된 옵션을 사용하여 구성하는 것입니다. 다른 구성은 지원되지 않으므로 사용하지 마십시오. 구성 패러다임은 OpenShift Container Platform 릴리스마다 변경될 수 있으며 이러한 경우는 모든 구성 가능성이 제어되는 경우에만 정상적으로 처리될 수 있습니다. 이 문서에 설명된 것과 다른 구성을 사용하는 경우 Operator가 차이를 조정하므로 변경 사항이 사라집니다. Operator는 원래 기본적으로 모든 항목을 정의된 상태로 되돌립니다.
OpenShift Container Platform 설명서에 설명되어 있지 않은 구성을 수행해야 하는 경우 Red Hat OpenShift Logging Operator를 Unmanaged 상태로 설정해야 합니다. 관리되지 않는 OpenShift Logging 환경은 지원되지 않으며 OpenShift Logging을 Managed 상태로 되돌릴 때까지 업데이트를 받지 않습니다.
다음과 같은 수정 사항은 명시적으로 지원되지 않습니다.
- 설명서에 지정되지 않은 네임스페이스에 로깅을 배포합니다.
- OpenShift Container Platform에 사용자 정의 Elasticsearch, Kibana, Fluentd 또는 10.0.0.1 인스턴스 설치.
- Kibana 사용자 정의 리소스(CR) 또는 Elasticsearch CR로 변경
- 문서에 지정되지 않은 시크릿 또는 구성 맵 변경 사항
Red Hat OpenShift의 로깅 하위 시스템은 애플리케이션, 인프라 및 감사 로그의 피드백 수집기 및 노멀라이저입니다. 지원되는 다양한 시스템으로 로그를 전달하는 데 사용됩니다.
Red Hat OpenShift의 로깅 하위 시스템은 다음과 같습니다.
- 대규모 로그 수집 시스템
- SIEM(Security Information and Event Monitoring) 준수
- 기록 또는 장기 로그 보존 또는 스토리지
- 보장된 로그 싱크
- 보안 스토리지 - 감사 로그는 기본적으로 저장되지 않습니다.