9장. 로그 수집 및 전달
9.1. 로그 수집 및 전달 정보
Red Hat OpenShift Logging Operator는 ClusterLogForwarder 리소스 사양에 따라 수집기를 배포합니다. 이 Operator에서 지원하는 수집기 옵션은 레거시 Fluentd 수집기와 벡터 수집기의 두 가지입니다.
Fluentd는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않습니다. Fluentd 대신 Vector를 사용할 수 있습니다.
9.1.1. 로그 컬렉션
로그 수집기는 각 OpenShift Container Platform 노드에 Pod를 배포하여 컨테이너 및 노드 로그를 수집하는 데몬 세트입니다.
기본적으로 로그 수집기는 다음 소스를 사용합니다.
- 운영 체제, 컨테이너 런타임 및 OpenShift Container Platform의 journald 로그 메시지에 의해 생성된 시스템 및 인프라 로그입니다.
-
모든 컨테이너 로그에 대한
/var/log/containers/*.log
감사 로그를 수집하도록 로그 수집기를 구성하는 경우 /var/log/audit/audit.log 에서 해당 로그를 수집합니다.
로그 수집기는 이러한 소스에서 로그를 수집하여 로깅 구성에 따라 내부 또는 외부로 전달합니다.
9.1.1.1. 로그 수집기 유형
벡터 는 로깅을 위해 Fluentd의 대안으로 제공되는 로그 수집기입니다.
ClusterLogging 사용자 정의 리소스(CR) 컬렉션 사양을 수정하여 클러스터에서 사용하는 로깅 수집기 유형을 구성할 수 있습니다.
Vector를 수집기로 구성하는 ClusterLogging CR의 예
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
name: instance
namespace: openshift-logging
spec:
collection:
logs:
type: vector
vector: {}
# ...
9.1.1.2. 로그 컬렉션 제한 사항
컨테이너 런타임은 로그 메시지의 소스(프로젝트, Pod 이름 및 컨테이너 ID)를 식별하기 위한 최소한의 정보를 제공합니다. 이 정보로는 로그 소스를 고유하게 식별하기에 부족합니다. 로그 수집기에서 로그 처리를 시작하기 전에 지정된 이름과 프로젝트가 있는 Pod를 삭제하면 레이블 및 주석과 같은 API 서버의 정보를 사용할 수 없게 됩니다. 로그 메시지를 비슷한 이름의 Pod 및 프로젝트와 구별할 방법 또는 로그의 소스를 추적할 방법이 없을 수 있습니다. 이 제한은 로그 수집 및 정규화가 최선의 노력으로 간주됨을 의미합니다.
사용 가능한 컨테이너 런타임은 로그 메시지의 소스를 식별할 수 있는 최소한의 정보를 제공하며, 고유한 개별 로그 메시지 또는 그러한 메시지의 소스 추적을 보장하지 않습니다.
9.1.1.3. 유형별 로그 수집기 기능
| 기능 | Fluentd | vector |
|---|---|---|
| 앱 컨테이너 로그 | ✓ | ✓ |
| 앱별 라우팅 | ✓ | ✓ |
| 네임스페이스별 앱별 라우팅 | ✓ | ✓ |
| 인프라 컨테이너 로그 | ✓ | ✓ |
| 인프라 저널 로그 | ✓ | ✓ |
| kube API 감사 로그 | ✓ | ✓ |
| OpenShift API 감사 로그 | ✓ | ✓ |
| OVN(Virtual Network) 감사 로그 열기 | ✓ | ✓ |
| 기능 | Fluentd | vector |
|---|---|---|
| Elasticsearch 인증서 | ✓ | ✓ |
| Elasticsearch 사용자 이름 / 암호 | ✓ | ✓ |
| Amazon Cloudwatch 키 | ✓ | ✓ |
| Amazon Cloudwatch STS | ✓ | ✓ |
| Kafka 인증서 | ✓ | ✓ |
| Kafka 사용자 이름 / 암호 | ✓ | ✓ |
| Kafka SASL | ✓ | ✓ |
| Loki 전달자 토큰 | ✓ | ✓ |
| 기능 | Fluentd | vector |
|---|---|---|
| viaq 데이터 모델 - 앱 | ✓ | ✓ |
| viaq 데이터 모델 - 인프라 | ✓ | ✓ |
| viaq 데이터 모델 - infra(journal) | ✓ | ✓ |
| viaq 데이터 모델 - Linux 감사 | ✓ | ✓ |
| viaq 데이터 모델 - kube-apiserver audit | ✓ | ✓ |
| viaq 데이터 모델 - OpenShift API 감사 | ✓ | ✓ |
| viaq 데이터 모델 - OVN | ✓ | ✓ |
| loglevel Normalization | ✓ | ✓ |
| JSON 구문 분석 | ✓ | ✓ |
| 구조화된 인덱스 | ✓ | ✓ |
| 여러 줄 오류 탐지 | ✓ | ✓ |
| 멀티컨테이너 / 분할 인덱스 | ✓ | ✓ |
| 플랫 레이블 | ✓ | ✓ |
| CLF 정적 라벨 | ✓ | ✓ |
| 기능 | Fluentd | vector |
|---|---|---|
| Fluentd readlinelimit | ✓ | |
| Fluentd 버퍼 | ✓ | |
| - chunkLimitSize | ✓ | |
| - totalLimitSize | ✓ | |
| - overflowaction | ✓ | |
| - flushthreadcount | ✓ | |
| - flushmode | ✓ | |
| - flushinterval | ✓ | |
| - retryWait | ✓ | |
| - retrytype | ✓ | |
| - retrymaxinterval | ✓ | |
| - retrytimeout | ✓ |
| 기능 | Fluentd | vector |
|---|---|---|
| 지표 | ✓ | ✓ |
| 대시보드 | ✓ | ✓ |
| 경고 | ✓ | ✓ |
| 기능 | Fluentd | vector |
|---|---|---|
| 글로벌 프록시 지원 | ✓ | ✓ |
| x86 지원 | ✓ | ✓ |
| ARM 지원 | ✓ | ✓ |
| IBM Power® 지원 | ✓ | ✓ |
| IBM Z® support | ✓ | ✓ |
| IPv6 지원 | ✓ | ✓ |
| 로그 이벤트 버퍼링 | ✓ | |
| 연결이 끊긴 클러스터 | ✓ | ✓ |
9.1.1.4. 수집기 출력
다음 컬렉터 출력이 지원됩니다.
| 기능 | Fluentd | vector |
|---|---|---|
| Elasticsearch v6-v8 | ✓ | ✓ |
| fluent forward | ✓ | |
| Syslog RFC3164 | ✓ | Cryostat (로깅 5.7 이상) |
| Syslog RFC5424 | ✓ | Cryostat (로깅 5.7 이상) |
| Kafka | ✓ | ✓ |
| Amazon Cloudwatch | ✓ | ✓ |
| Amazon Cloudwatch STS | ✓ | ✓ |
| Loki | ✓ | ✓ |
| HTTP | ✓ | Cryostat (로깅 5.7 이상) |
| Google Cloud Logging | ✓ | ✓ |
| Splunk | Cryostat (logging 5.6 이상) |
9.1.2. 로그 전송
관리자는 수집되는 로그, 변환 방법, 전달되는 위치를 지정하는 ClusterLogForwarder 리소스를 생성할 수 있습니다.
ClusterLogForwarder 리소스는 컨테이너, 인프라 및 감사 로그를 클러스터 내부 또는 외부의 특정 끝점으로 전달하는 데 사용할 수 있습니다. TLS(Transport Layer Security)가 지원되므로 로그를 안전하게 전송하도록 로그 전달자를 구성할 수 있습니다.
관리자는 어떤 유형의 로그에 액세스하고 전달할 수 있는 서비스 계정 및 사용자를 정의하는 RBAC 권한을 부여할 수도 있습니다.
9.1.2.1. 로그 전달 구현
레거시 구현과 다중 로그 전달 기능이라는 두 가지 로그 전달 구현을 사용할 수 있습니다.
다중 로그 전달자 기능과 함께 사용할 수 있도록 Vector 수집기만 지원됩니다. Fluentd 수집기는 레거시 구현에서만 사용할 수 있습니다.
9.1.2.1.1. 기존 구현
기존 구현에서는 클러스터에서 하나의 로그 전달자만 사용할 수 있습니다. 이 모드의 ClusterLogForwarder 리소스는 instance 여야 하며 openshift-logging 네임스페이스에서 생성해야 합니다. ClusterLogForwarder 리소스에는 openshift-logging 네임스페이스에 instance 라는 해당 ClusterLogging 리소스도 필요합니다.
9.1.2.1.2. 다중 로그 전달자 기능
다중 로그 전달자 기능은 로깅 5.8 이상에서 사용할 수 있으며 다음과 같은 기능을 제공합니다.
- 관리자는 로그 컬렉션을 정의할 수 있는 사용자와 수집할 수 있는 로그를 제어할 수 있습니다.
- 필요한 권한이 있는 사용자는 추가 로그 컬렉션 구성을 지정할 수 있습니다.
- 더 이상 사용되지 않는 Fluentd 수집기에서 Vector 수집기로 마이그레이션하는 관리자는 새 로그 전달자를 기존 배포와 별도로 배포할 수 있습니다. 워크로드가 마이그레이션되는 동안 기존 및 새 로그 전달자가 동시에 작동할 수 있습니다.
다중 로그 전달자 구현에서는 ClusterLogForwarder 리소스에 대한 해당 ClusterLogging 리소스를 생성할 필요가 없습니다. 다음 예외를 제외하고 모든 네임스페이스에서 모든 이름을 사용하여 여러 ClusterLogForwarder 리소스를 생성할 수 있습니다.
-
Fluentd 수집기를 사용하는 레거시 워크플로우를 지원하는 로그 전달자를 위해 예약되어 있으므로
openshift-logging네임스페이스에instance라는ClusterLogForwarder리소스를 생성할 수 없습니다. -
수집기용으로 예약되어 있으므로
openshift-logging네임스페이스에서collector라는ClusterLogForwarder리소스를 생성할 수 없습니다.
9.1.2.2. 클러스터의 다중 로그 전달자 기능 활성화
다중 로그 전달자 기능을 사용하려면 해당 서비스 계정에 대한 서비스 계정 및 클러스터 역할 바인딩을 생성해야 합니다. 그런 다음 ClusterLogForwarder 리소스에서 서비스 계정을 참조하여 액세스 권한을 제어할 수 있습니다.
openshift-logging 네임스페이스 이외의 추가 네임스페이스에서 다중 로그 전달을 지원하려면 모든 네임스페이스를 조사하도록 Red Hat OpenShift Logging Operator를 업데이트해야 합니다. 이 기능은 새로운 Red Hat OpenShift Logging Operator 버전 5.8 설치에서 기본적으로 지원됩니다.
9.1.2.2.1. 로그 컬렉션 RBAC 권한 승인
로깅 5.8 이상에서 Red Hat OpenShift Logging Operator는 collect-audit-logs,collect-application-logs, collect-infrastructure-logs 클러스터 역할을 제공하여 수집기가 감사 로그, 애플리케이션 로그 및 인프라 로그를 각각 수집할 수 있습니다.
필요한 클러스터 역할을 서비스 계정에 바인딩하여 로그 컬렉션에 대한 RBAC 권한을 부여할 수 있습니다.
사전 요구 사항
-
Red Hat OpenShift Logging Operator는
openshift-logging네임스페이스에 설치됩니다. - 관리자 권한이 있습니다.
프로세스
- 수집기의 서비스 계정을 생성합니다. 인증을 위해 토큰이 필요한 스토리지에 로그를 작성하려면 서비스 계정에 토큰을 포함해야 합니다.
적절한 클러스터 역할을 서비스 계정에 바인딩합니다.
바인딩 명령 예
$ oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>
