로깅

OpenShift Container Platform 4.16

OpenShift Container Platform에서 로깅 구성 및 사용

Red Hat OpenShift Documentation Team

초록

로깅을 사용하여 로그 데이터를 수집, 시각화, 전달 및 저장하여 문제를 해결하고 성능 병목 현상을 식별하고 OpenShift Container Platform에서 보안 위협을 감지합니다.

1장. 릴리스 노트

1.1. Logging 5.9

로깅은 코어 OpenShift Container Platform과 별도의 릴리스 사이클을 사용하여 설치 가능한 구성 요소로 제공됩니다. Red Hat OpenShift Container Platform 라이프 사이클 정책은 릴리스 호환성에 대해 간단히 설명합니다.

참고

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

1.1.1. 로깅 5.9.9

이 릴리스에는 RHBA-2024:10049 가 포함되어 있습니다.

1.1.1.1. 버그 수정

이번 업데이트 이전에는 Log File Metric Exporter 인스턴스가 있는 경우 버전 6.0으로 업그레이드하지 못했습니다. 이번 업데이트에서는 문제가 해결되어 오류 없이 업그레이드를 원활하게 진행할 수 있습니다. (LOG-6201)
이번 업데이트 이전에는 Loki가 일부 구성을 올바르게 로드하지 않아 Alibaba Cloud 또는 IBM Cloud 오브젝트 스토리지를 사용할 때 문제가 발생했습니다. 이번 업데이트에서는 Loki의 구성 로드 코드가 수정되어 문제를 해결합니다. (LOG-6293)

1.1.1.2. CVE

CVE-2024-6119

1.1.2. 로깅 5.9.8

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

1.1.2.1. 버그 수정

이번 업데이트 이전에는 Loki Operator가 모든 AlertingRule 리소스에 기본 네임스페이스 레이블을 추가하지 않아 User-Workload-Monitoring Alertmanager가 이러한 경고의 라우팅을 건너뛰었습니다. 이번 업데이트에서는 규칙 네임스페이스를 모든 경고 및 레코딩 규칙에 레이블로 추가하고 문제를 해결하고 Alertmanager에서 적절한 경고 라우팅을 복원합니다. (LOG-6181)
이번 업데이트 이전에는 LokiStack 룰러 구성 요소 뷰가 올바르게 초기화되지 않아 ruler 구성 요소가 비활성화된 경우 잘못된 필드 오류가 발생했습니다. 이번 업데이트에서는 구성 요소 뷰가 빈 값으로 초기화되어 문제를 해결합니다. (LOG-6183)
이번 업데이트 이전에는 ES 인증 구성에 있는 vector.toml 파일의 LF 문자로 인해 수집기 Pod가 충돌했습니다. 이번 업데이트에서는 사용자 이름 및 암호 필드에서 줄 바꿈 문자가 제거되어 문제를 해결합니다. (LOG-6206)
이번 업데이트 이전에는 ClusterLogForwarder 사용자 정의 리소스에서 .containerLimit.maxRecordsPerSecond 매개변수를 0 으로 설정하여 Vector를 시작하는 동안 예외가 발생할 수 있었습니다. 이번 업데이트를 통해 구성이 적용되기 전에 유효성이 검사되고 유효하지 않은 값(0 이 아님)이 거부됩니다. (LOG-6214)

1.1.2.2. CVE

1.1.3. 로깅 5.9.7

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

1.1.3.1. 버그 수정

이번 업데이트 이전에는 Fluentd를 수집기 유형으로 사용할 때 clusterlogforwarder.spec.outputs.http.timeout 매개변수가 Fluentd 구성에 적용되지 않아 HTTP 시간 초과가 잘못 구성됩니다. 이번 업데이트를 통해 clusterlogforwarder.spec.outputs.http.timeout 매개변수가 올바르게 적용되어 Fluentd가 지정된 타임아웃을 준수하고 사용자 구성에 따라 HTTP 연결을 처리합니다. (LOG-6125)
이번 업데이트 이전에는 브로커 URL 스키마를 확인하지 않고 TLS 섹션이 추가되어 URL이 tls 로 시작되지 않은 경우 SSL 연결 오류가 발생했습니다. 이번 업데이트를 통해 브로커 URL이 tls 로 시작하는 경우에만 TLS 섹션이 추가되어 SSL 연결 오류가 발생하지 않습니다. (LOG-6041)

1.1.3.2. CVE

참고

Red Hat 보안 등급에 대한 자세한 내용은 심각도 등급을 참조하십시오.

1.1.4. 로깅 5.9.6

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

1.1.4.1. 버그 수정

이번 업데이트 이전에는 수집기 배포에서 시크릿 변경을 무시하여 수신자가 로그를 거부합니다. 이번 업데이트를 통해 시크릿 값이 변경될 때 시스템에서 새 Pod를 롤아웃하여 수집기에서 업데이트된 보안을 다시 로드합니다. (LOG-5525)
이번 업데이트 이전에는 벡터가 단일 달러 기호($)를 포함하는 필드 값을 올바르게 구문 분석할 수 없었습니다. 이번 업데이트를 통해 단일 달러 기호가 있는 필드 값은 자동으로 두 달러 기호( $ $ )로 변경되어 벡터에서 올바르게 구문 분석합니다. (LOG-5602)
이번 업데이트 이전에는 drop 필터에서 문자열이 아닌 값을 처리할 수 없었습니다(예: .responseStatus.code: 403). 이번 업데이트를 통해 이제 drop 필터가 이러한 값과 제대로 작동합니다. (LOG-5815)
이번 업데이트 이전에는 수집기에서 기본 설정을 사용하여 출력 수신자의 백로드를 처리하지 않고 감사 로그를 수집합니다. 이번 업데이트를 통해 파일 처리 및 로그 읽기 효율성을 보다 효과적으로 관리하도록 감사 로그 수집 프로세스가 개선되었습니다. (LOG-5866)
이번 업데이트 이전에는 ARM(Azure Resource Manager) 또는 PowerPC와 같이AMD64 이외의 아키텍처가 있는 클러스터에서 must-gather 툴이 실패했습니다. 이번 업데이트를 통해 이제 툴에서 런타임 시 클러스터 아키텍처를 감지하고 아키텍처 독립적인 경로와 종속 항목을 사용합니다. 탐지를 통해 ARM 및 PowerPC와 같은 플랫폼에서 must-gather 를 원활하게 실행할 수 있습니다. (LOG-5997)
이번 업데이트 이전에는 명확하지 않은 구조화된 키워드와 구조화되지 않은 키워드를 혼합하여 로그 수준을 설정했습니다. 이번 업데이트를 통해 로그 수준은 구조화된 키워드부터 시작하여 명확하고 문서화된 순서를 따릅니다. (LOG-6016)
이번 업데이트 이전에는 ClusterLogForwarder 의 기본 출력에 기록되지 않은 여러 파이프라인으로 인해 자동 생성 이름이 중복되어 검증 오류가 발생했습니다. 이번 업데이트를 통해 이제 중복 없이 파이프라인 이름이 생성됩니다. (LOG-6033)
이번 업데이트 이전에는 수집기 Pod에 PreferredScheduling 주석이 없었습니다. 이번 업데이트를 통해 수집기 데몬 세트에 PreferredScheduling 주석이 추가됩니다. (LOG-6023)

1.1.4.2. CVE

1.1.5. 로깅 5.9.5

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

1.1.5.1. 버그 수정

이번 업데이트 이전에는 LokiStack 리소스 상태의 중복 조건으로 인해 Loki Operator에서 유효하지 않은 지표가 발생했습니다. 이번 업데이트를 통해 Operator는 상태에서 중복 조건을 제거합니다. (LOG-5855)
이번 업데이트 이전에는 검증 실패로 인해 로그 이벤트를 삭제한 경우 Loki Operator에서 경고를 트리거하지 않았습니다. 이번 업데이트를 통해 Loki Operator에는 검증 실패로 인해 Loki가 로그 이벤트를 삭제하는 경우 경고를 트리거하는 새 경고 정의가 포함되어 있습니다. (LOG-5895)
이번 업데이트 이전에는 LokiStack Route 리소스에서 Loki Operator가 사용자 주석을 초과하여 사용자 지정이 삭제됩니다. 이번 업데이트를 통해 Loki Operator에서 더 이상 Route 주석을 덮어쓰지 않고 문제를 해결합니다. (LOG-5945)

1.1.5.2. CVE

없음.

1.1.6. Logging 5.9.4

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

1.1.6.1. 버그 수정

이번 업데이트 이전에는 잘못 포맷된 시간 초과 구성으로 인해 OCP 플러그인이 충돌했습니다. 이번 업데이트를 통해 검증에서 충돌을 방지하고 사용자에게 잘못된 구성을 알립니다. (LOG-5373)
이번 업데이트 이전에는 라벨이 포함된 워크로드 로 인해 로그 항목을 정규화할 때 수집기에서 오류가 발생했습니다. 이번 업데이트를 통해 구성 변경으로 수집기에서 올바른 구문을 사용할 수 있습니다. (LOG-5524)
이번 업데이트 이전에는 로그가 생성된 경우에도 더 이상 존재하지 않는 Pod를 선택하지 못했습니다. 이번 업데이트를 통해 이 문제가 해결되어 이러한 Pod를 선택할 수 있습니다. (LOG-5697)
이번 업데이트 이전에는 cloud-credentials-operator 가 없는 환경에 CredentialRequest 사양이 등록된 경우 Loki Operator가 충돌했습니다. 이번 업데이트를 통해 CredentialRequest 사양은 cloud-credentials-operator 가 활성화된 환경에만 등록됩니다. (LOG-5701)
이번 업데이트 이전에는 Logging Operator가 클러스터 전체에서 모든 구성 맵을 감시하고 처리했습니다. 이번 업데이트를 통해 대시보드 컨트롤러는 구성 맵에서 로깅 대시보드만 감시합니다. (LOG-5702)
이번 업데이트 이전에는 ClusterLogForwarder 에서 RFC3164 사양을 따르지 않은 메시지 페이로드에 추가 공간을 도입했습니다. 이번 업데이트를 통해 추가 공간이 제거되어 문제가 해결되었습니다. (LOG-5707)
이번 업데이트 이전에는 (LOG-5308)의 일부로 grafana-dashboard-cluster-logging 의 시드를 제거하면 대시보드 없이 새로운 녹색 필드 배포가 중단되었습니다. 이번 업데이트를 통해 Logging Operator는 처음에 대시보드를 조각화하고 변경 사항에 대해 계속 업데이트합니다. (LOG-5747)
이번 업데이트 이전에는 LokiStack에 볼륨 API의 경로가 누락되어 다음과 같은 오류가 발생했습니다. 404 not found. 이번 업데이트를 통해 LokiStack은 볼륨 API를 노출하여 문제를 해결합니다. (LOG-5749)

1.1.6.2. CVE

CVE-2024-24790

1.1.7. Logging 5.9.3

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

1.1.7.1. 버그 수정

이번 업데이트 이전에는 LokiStack을 구성할 때 LokiStack 을 구성할 때 Ingesters를 다시 시작할 때 Loki Operator가 1x.demo 크기의 write-ahead log replay_memory_ceiling 을 0바이트로 설정했기 때문에 지연이 발생했습니다. 이번 업데이트를 통해 replay_memory_ceiling 에 사용되는 최소 값이 지연을 방지하기 위해 증가했습니다. (LOG-5614)
이번 업데이트 이전에는 Vector 수집기 출력 버퍼 상태를 모니터링할 수 없었습니다. 이번 업데이트를 통해 Vector 수집기 출력 버퍼 크기를 모니터링하고 경고하여 관찰 기능을 개선하고 시스템을 최적으로 실행할 수 있습니다. (LOG-5586)

1.1.7.2. CVE

1.1.8. Logging 5.9.2

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

1.1.8.1. 버그 수정

이번 업데이트 이전에는 Logging Operator를 변경하면 ClusterLogForwarder CR의 잘못된 구성으로 인해 오류가 발생했습니다. 결과적으로 로깅으로 업그레이드하면 daemonset 수집기가 삭제되었습니다. 이번 업데이트를 통해 Not authorized to collect 오류가 발생하는 경우를 제외하고 Logging Operator는 수집기 데몬 세트를 다시 생성합니다. (LOG-4910)
이번 업데이트 이전에는 Vector 로그 수집기의 잘못된 구성으로 인해 일부 시나리오에서 순환된 인프라 로그 파일이 애플리케이션 인덱스로 전송되었습니다. 이번 업데이트를 통해 Vector 로그 수집기 구성에서 순환된 인프라 로그 파일을 수집하지 않습니다. (LOG-5156)
이번 업데이트 이전에는 Logging Operator에서 grafana-dashboard-cluster-logging 구성 맵에 대한 변경 사항을 모니터링하지 않았습니다. 이번 업데이트를 통해 Logging Operator는 ConfigMap 오브젝트의 변경 사항을 모니터링하여 시스템이 동기화 상태를 유지하고 구성 맵 수정에 효과적으로 응답할 수 있습니다. (LOG-5308)
이번 업데이트 이전에는 Logging Operator의 메트릭 컬렉션 코드의 문제로 인해 오래된 Telemetry 메트릭이 보고되었습니다. 이번 업데이트를 통해 Logging Operator는 오래된 Telemetry 메트릭을 보고하지 않습니다. (LOG-5426)
이러한 변경 이전에는 Fluentd out_http 플러그인이 no_proxy 환경 변수를 무시했습니다. 이번 업데이트를 통해 Fluentd는 ruby의 HTTP#start 메서드를 패치하여 no_proxy 환경 변수를 준수합니다. (LOG-5466)

1.1.8.2. CVE

1.1.9. Logging 5.9.1

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

1.1.9.1. 기능 개선

이번 업데이트 이전에는 Loki Operator에서 더 이상 사용되지 않는 Amazon Simple Storage Service(S3)에 경로 기반 스타일 액세스를 사용하도록 Loki를 구성했습니다. 이번 업데이트를 통해 Loki Operator는 사용자가 구성을 변경할 필요 없이 기본적으로 virtual-host 스타일로 설정됩니다. (LOG-5401)
이번 업데이트 이전에는 Loki Operator에서 스토리지 보안에 사용된 Amazon Simple Storage Service(S3) 끝점의 유효성을 검사하지 않았습니다. 이번 업데이트를 통해 검증 프로세스는 S3 끝점이 유효한 S3 URL이고 LokiStack 상태 업데이트를 통해 잘못된 URL을 나타냅니다. (LOG-5395)

1.1.9.2. 버그 수정

이번 업데이트 이전에는 LogQL 구문 분석의 버그로 인해 쿼리에서 일부 줄 필터가 남겼습니다. 이번 업데이트를 통해 이제 구문 분석에 원래 쿼리를 변경하지 않고 모든 줄 필터가 포함됩니다. (LOG-5268)
이번 업데이트 이전에는 pruneFilterSpec 이 없는 정리 필터로 인해 segfault가 발생했습니다. 이번 업데이트를 통해 prune 필터가 정의된 puneFilterSpec 이 없는 경우 검증 오류가 발생합니다. (LOG-5322)
이번 업데이트 이전에는 dropTestsSpec 이 정의되지 않은 drop 필터로 인해 segfault가 발생합니다. 이번 업데이트를 통해 prune 필터가 정의된 puneFilterSpec 이 없는 경우 검증 오류가 발생합니다. (LOG-5323)
이번 업데이트 이전에는 Loki Operator에서 스토리지 보안에 사용된 Amazon Simple Storage Service(S3) 끝점 URL 형식의 유효성을 검사하지 않았습니다. 이번 업데이트를 통해 S3 끝점 URL은 LokiStack 의 상태를 반영하는 검증 단계를 거칩니다. (LOG-5397)
이번 업데이트 이전에는 감사 로그 레코드에서 잘못된 형식의 타임스탬프 필드가 Red Hat OpenShift Logging Operator 로그의 WARN 메시지로 이어졌습니다. 이번 업데이트를 통해 재맵 변환을 통해 timestamp 필드가 올바르게 포맷됩니다. (LOG-4672)
이번 업데이트 이전에는 ClusterLogForwarder 리소스 이름과 네임스페이스를 검증하는 동안 발생한 오류 메시지가 올바른 오류와 일치하지 않았습니다. 이번 업데이트를 통해 시스템은 동일한 이름의 ClusterLogForwarder 리소스가 동일한 네임스페이스에 있는지 확인합니다. 그렇지 않으면 올바른 오류와 일치합니다. (LOG-5062)
이번 업데이트 이전에는 설계에 URL이 필요하지 않은 Amazon Cloud Logging과 같은 서비스에도 출력 구성에 대한 검증 기능에 TLS URL이 필요했습니다. 이번 업데이트를 통해 URL이 없는 서비스에 대한 검증 논리가 개선되고 오류 메시지가 더 도움이 됩니다. (LOG-5307)
이번 업데이트 이전에는 인프라 입력 유형을 정의해도 컬렉션에서 로깅 워크로드가 제외되지 않았습니다. 이번 업데이트를 통해 컬렉션은 피드백 루프를 방지하기 위해 로깅 서비스를 제외합니다. (LOG-5309)

1.1.9.3. CVE

CVE 없음.

1.1.10. Logging 5.9.0

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

1.1.10.1. 제거 알림

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

1.1.10.2. 사용 중단 알림

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

1.1.10.3. 기능 개선

1.1.10.3.1. 로그 컬렉션

이번 개선된 기능에는 워크로드의 메타데이터를 사용하여 콘텐츠를 기반으로 로그를 삭제하거나 정리하여 로그 수집 프로세스를 구체화할 수 있는 기능이 추가되었습니다. 또한 저널 또는 컨테이너 로그와 같은 인프라 로그 수집, kube api 또는 ovn 로그와 같은 감사 로그만 개별 소스를 수집할 수 있습니다. (LOG-2155)
이번 개선된 기능에는 syslog 수신자인 새로운 유형의 원격 로그 수신자가 도입되었습니다. 네트워크를 통해 포트를 노출하도록 구성하여 외부 시스템이 rsyslog와 같은 호환 가능한 도구를 사용하여 syslog 로그를 보낼 수 있도록 구성할 수 있습니다. (LOG-3527)
이번 업데이트를 통해 ClusterLogForwarder API에서 Azure Monitor 로그에 대한 로그 전달을 지원하여 사용자에게 더 나은 모니터링 기능을 제공합니다. 이 기능을 사용하면 사용자가 최적의 시스템 성능을 유지하고 Azure Monitor에서 로그 분석 프로세스를 간소화하여 문제 해결을 가속화하고 운영 효율성을 개선할 수 있습니다. (LOG-4605)
이번 개선된 기능을 통해 수집기를 두 개의 복제본이 있는 배포로 배포하여 수집기 리소스 사용률이 향상됩니다. 이는 ClusterLogForwarder CR(사용자 정의 리소스)에 정의된 유일한 입력 소스가 모든 노드에서 데몬 세트를 사용하는 대신 수신자 입력인 경우 발생합니다. 또한 이러한 방식으로 배포된 컬렉터는 호스트 파일 시스템을 마운트하지 않습니다. 이 향상된 기능을 사용하려면 logging.openshift.io/dev-preview-enable-collector-as-deployment 주석으로 ClusterLogForwarder CR에 주석을 답니다. (LOG-4779)
이번 개선된 기능을 통해 지원되는 모든 출력에서 사용자 정의 테넌트 구성 기능이 도입되어 논리적 방식으로 로그 레코드 조직을 수행할 수 있습니다. 그러나 관리 스토리지 로깅을 위한 사용자 지정 테넌트 구성은 허용하지 않습니다. (LOG-4843)
이번 업데이트를 통해 기본,openshift* 또는 kube* 와 같은 하나 이상의 인프라 네임스페이스로 애플리케이션 입력을 지정하는 ClusterLogForwarder CR에 이제 collect-infrastructure-logs 역할이 있는 서비스 계정이 필요합니다. (LOG-4943)
이번 개선된 기능을 통해 수신자의 특성과 일치하도록 압축, 재시도 기간 및 최대 페이로드와 같은 일부 출력 설정을 조정하는 기능이 도입되었습니다. 또한 이 기능에는 관리자가 처리량과 로그 지속성을 선택할 수 있는 전달 모드가 포함되어 있습니다. 예를 들어 AtLeastOnce 옵션은 수집기가 재시작 후 해당 로그를 제공할 수 있도록 수집된 로그의 최소 디스크 버퍼링을 구성합니다. (LOG-5026)
이번 개선된 기능에는 Elasticsearch, Fluentd 및 Kibana의 사용 중단에 대한 경고 사용자에게 세 가지 새로운 Prometheus 경고가 추가되었습니다. (LOG-5055)

1.1.10.3.2. 로그 스토리지

LokiStack의 이러한 개선 사항은 새로운 V13 오브젝트 스토리지 형식을 사용하고 기본적으로 자동 스트림 샤딩을 활성화하여 OTEL에 대한 지원을 개선합니다. 또한 수집기에서 향후 개선 사항 및 구성을 준비합니다. (LOG-4538)
이번 개선된 기능을 통해 STS의 Azure 및 AWS 로그 저장소와 함께 단기 토큰 워크로드 ID 페더레이션을 지원합니다. OpenShift Container Platform 4.14 이상 클러스터의 경우 로컬 스토리지에 LokiStack CR의 spec.storage.secret 에 CredentialMode: static 주석을 추가해야 합니다. (LOG-4540)
이번 업데이트를 통해 Azure 스토리지 보안 검증이 확장되어 특정 오류 조건에 대한 조기 경고가 제공됩니다. (LOG-4571)
이번 업데이트를 통해 Loki는 이제 GCP 워크로드 ID 페더레이션 메커니즘에 대한 업스트림 및 다운스트림 지원을 추가합니다. 이를 통해 해당 오브젝트 스토리지 서비스에 대한 인증 및 권한 있는 액세스를 허용합니다. (LOG-4754)

1.1.10.4. 버그 수정

이번 업데이트 이전에는 로깅 must-gather에서 FIPS 지원 클러스터에서 로그를 수집할 수 없었습니다. 이번 업데이트를 통해 cluster-logging-rhel9-operator 에서 새 oc 클라이언트를 사용할 수 있으며 FIPS 클러스터에서 must-gather가 제대로 작동합니다. (LOG-4403)
이번 업데이트 이전에는 LokiStack 룰러 Pod에서 포드 간 통신에 사용되는 HTTP URL의 IPv6 Pod IP를 포맷할 수 없었습니다. 이 문제로 인해 Prometheus 호환 API를 통한 규칙 및 경고를 쿼리하지 못했습니다. 이번 업데이트를 통해 LokiStack 룰러 Pod는 IPv6 포드 IP를 대괄호로 캡슐화하여 문제를 해결합니다. 이제 Prometheus 호환 API를 통해 규칙 및 경고를 쿼리하는 것이 IPv4 환경에서처럼 작동합니다. (LOG-4709)
이번 수정 이전에는 로깅 must-gather의 YAML 콘텐츠가 한 줄로 내보내 읽을 수 없게 되었습니다. 이번 업데이트를 통해 YAML 공백을 유지하여 파일을 올바르게 포맷합니다. (LOG-4792)
이번 업데이트 이전에는 ClusterLogging.Spec.Collection 이 nil인 경우 ClusterLogForwarder CR이 활성화된 경우 Red Hat OpenShift Logging Operator가 nil 포인터 예외로 실행될 수 있었습니다. 이번 업데이트를 통해 Red Hat OpenShift Logging Operator에서 문제가 해결되었습니다. (LOG-5006)
이번 업데이트 이전에는 특정 코너의 경우 ClusterLogForwarder CR 상태 필드를 교체하면 상태 조건의 타임스탬프 변경으로 인해 resourceVersion 이 지속적으로 업데이트되었습니다. 이 조건을 통해 무한 조정 루프가 발생했습니다. 이번 업데이트를 통해 조건이 동일하게 유지되는 경우 타임스탬프가 변경되지 않도록 모든 상태 조건이 동기화됩니다. (LOG-5007)
이번 업데이트 이전에는 수집기에서 높은 메모리 사용을 해결하기 위해 drop_newest 에 대한 내부 버퍼링 동작이 있었기 때문에 로그가 크게 손실되었습니다. 이번 업데이트를 통해 동작은 수집기 기본값을 사용하여 로 되돌아갑니다. (LOG-5123)
이번 업데이트 이전에는 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-5165)
이번 업데이트 이전에는 Loki Operator ServiceMonitor 의 구성이 여러 Kubernetes 서비스와 일치하여 Loki Operator 지표가 여러 번 수집될 수 있었습니다. 이번 업데이트를 통해 ServiceMonitor 의 구성은 이제 전용 메트릭 서비스와만 일치합니다. (LOG-5212)

1.1.10.5. 확인된 문제

없음.

1.1.10.6. CVE

2장. 로깅 6.0

2.1. 릴리스 노트

2.1.1. 로깅 6.0.2

이 릴리스에는 RHBA-2024:10051 이 포함되어 있습니다.

2.1.1.1. 버그 수정

이번 업데이트 이전에는 Loki가 일부 구성을 올바르게 로드하지 않아 Alibaba Cloud 또는 IBM Cloud 오브젝트 스토리지를 사용할 때 문제가 발생했습니다. 이번 업데이트에서는 Loki의 구성 로드 코드가 수정되어 문제를 해결합니다. (LOG-5325)
이번 업데이트 이전에는 수집기에서 구성된 임계값을 초과하는 감사 로그 메시지를 삭제합니다. 이렇게 하면 최대 행 크기와 읽기 주기 동안 읽은 바이트 수에 대한 감사 구성 임계값이 수정됩니다. (LOG-5998)
이번 업데이트 이전에는 Cluster Logging Operator가 이전 릴리스에서와 같이 ClusterLogForwarder 인스턴스와 연결된 리소스를 감시하고 조정하지 않았습니다. 이번 업데이트에서는 Operator가 수정되어 해당 Operator가 소유하고 생성하는 모든 리소스를 감시하고 조정합니다. (LOG-6264)
이번 업데이트 이전에는 Google Cloud Logging으로 전송되는 알 수 없는 심각도 수준의 로그 이벤트가 벡터 수집기에서 경고를 트리거하여 심각도를 'DEFAULT'로 설정합니다. 이번 업데이트를 통해 이제 로그 심각도 수준이 Google Cloud Logging 사양과 일치하도록 표준화되고 감사 로그에 'INFO' 심각도가 할당됩니다. (LOG-6296)
이번 업데이트 이전에는 인프라 네임스페이스가 애플리케이션 입력에 포함된 경우 log_type 이 application 로 설정되었습니다. 이번 업데이트를 통해 애플리케이션 입력에 포함된 인프라 네임스페이스의 log_type 이 인프라로 설정됩니다. (LOG-6354)
이번 업데이트 이전에는 ClusterLogForwarder에서 컨테이너 이외의 로그 메시지에 namespace_name,container_name, pod_name 이 추가된 ClusterLogForwarder의 syslog.enrichment 필드 값을 지정합니다. 이번 업데이트를 통해 syslog.enrichment 가 설정된 경우 컨테이너 로그에 namespace_name,container_name 및 pod_name 만 메시지에 포함됩니다. (LOG-6402)

2.1.1.2. CVE

2.1.2. 로깅 6.0.1

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

2.1.2.1. 버그 수정

이번 업데이트를 통해 수집기의 기본 메모리 제한이 1024 Mi에서 2024 Mi로 증가했습니다. 그러나 사용자는 항상 클러스터 사양 및 요구 사항에 따라 리소스 제한을 조정해야 합니다. (LOG-6180)
이번 업데이트 이전에는 Loki Operator가 모든 AlertingRule 리소스에 기본 네임스페이스 레이블을 추가하지 않아 User-Workload-Monitoring Alertmanager가 이러한 경고의 라우팅을 건너뛰었습니다. 이번 업데이트에서는 규칙 네임스페이스를 모든 경고 및 레코딩 규칙에 레이블로 추가하고 문제를 해결하고 Alertmanager에서 적절한 경고 라우팅을 복원합니다. (LOG-6151)
이번 업데이트 이전에는 LokiStack 룰러 구성 요소 뷰가 올바르게 초기화되지 않아 ruler 구성 요소가 비활성화된 경우 잘못된 필드 오류가 발생했습니다. 이번 업데이트에서는 구성 요소 뷰가 빈 값으로 초기화되어 문제를 해결합니다. (LOG-6129)
이번 업데이트 이전에는 prune 필터에서 log_source 를 설정하여 일관되지 않은 로그 데이터로 이어질 수 있었습니다. 이번 업데이트를 통해 구성이 적용되기 전에 유효성을 검사하고 prune 필터에 log_source 를 포함하는 구성이 거부됩니다. (LOG-6202)

2.1.2.2. CVE

2.1.3. 로깅 6.0.0

이 릴리스에는 Red Hat OpenShift 버그 수정 릴리스 6.0.0에 대한 로깅이 포함되어 있습니다.

참고

표 2.1. 업스트림 구성 요소 버전
로깅 버전	구성 요소 버전
Operator	`eventrouter`	`logfilemetricexporter`	`loki`	`lokistack-gateway`	`opa-openshift`	`vector`
6.0	0.4	1.1	3.1.0	0.1	0.1	0.37.1

2.1.4. 제거 알림

이번 릴리스에서는 로깅에서 ClusterLogging.logging.openshift.io 및 ClusterLogForwarder.logging.openshift.io 사용자 정의 리소스를 더 이상 지원하지 않습니다. 교체 기능에 대한 자세한 내용은 제품 설명서를 참조하십시오. (LOG-5803)
이번 릴리스에서는 로깅에서 로그 스토리지(예: Elasticsearch), 시각화(예: Kibana) 또는 Fluentd 기반 로그 수집기를 더 이상 관리하거나 배포하지 않습니다. (LOG-5368)

참고

elasticsearch-operator에서 관리하는 Elasticsearch 및 Kibana를 계속 사용하려면 관리자가 ClusterLogging 리소스를 삭제하기 전에 해당 오브젝트의 ownerRefs를 수정해야 합니다.

2.1.5. 새로운 기능 및 개선 사항

이 기능을 사용하면 구성 요소의 책임을 스토리지, 시각화 및 컬렉션과 같은 관련 Operator로 전환하여 Red Hat OpenShift에 대한 로깅을 위한 새로운 아키텍처가 도입되었습니다. 로그 수집 및 전달을 위해 ClusterLogForwarder.observability.openshift.io API가 도입되었습니다. Red Hat 관리 Elastic 스택(Elasticsearch 및 Kibana)과 함께 ClusterLogging.logging.openshift.io 및 ClusterLogForwarder.logging.openshift.io API에 대한 지원이 제거되었습니다. 사용자는 로그 스토리지를 위해 Red Hat LokiStack 으로 마이그레이션하는 것이 좋습니다. 기존 관리형 Elasticsearch 배포는 제한된 기간 동안 사용할 수 있습니다. 로그 수집에 대한 자동화된 마이그레이션이 제공되지 않으므로 관리자가 이전 사용자 정의 리소스를 교체하기 위해 새 ClusterLogForwarder.observability.openshift.io 사양을 생성해야 합니다. 자세한 내용은 공식 제품 설명서를 참조하십시오. (LOG-3493)
이번 릴리스에서는 로깅 보기 플러그인 배포 책임이 Red Hat OpenShift Logging Operator에서 COO(Cluster Observability Operator)로 전환됩니다. 시각화가 필요한 새 로그 스토리지 설치의 경우 Cluster Observability Operator 및 관련 UIPlugin 리소스를 배포해야 합니다. 자세한 내용은 Cluster Observability Operator 개요 제품 설명서를 참조하십시오. (LOG-5461)
이번 개선된 기능을 통해 벡터 수집기 배포 메모리 및 CPU 사용량에 대한 기본 요청 및 제한이 벡터 문서 권장 사항에 따라 설정됩니다. (LOG-4745)
이번 개선된 기능에서는 업스트림 버전 v0.37.1에 맞게 Vector를 업데이트합니다. (LOG-5296)
이번 개선된 기능으로 로그 수집기가 노드의 파일 시스템에 버퍼가 로그될 때 트리거되고 사용 가능한 공간의 15% 이상을 사용하여 잠재적인 백압 문제를 나타내는 경고가 추가되었습니다. (LOG-5381)
이번 개선된 기능을 통해 공통 Kubernetes 레이블을 사용하도록 모든 구성 요소의 선택기가 업데이트되었습니다. (LOG-5906)
이번 개선된 기능을 통해 시크릿 대신 ConfigMap으로 배포하도록 수집기 구성이 변경되어 ClusterLogForwarder가 Unmanaged로 설정된 경우 사용자가 구성을 보고 편집할 수 있습니다. (LOG-5599)
이번 개선된 기능에는 추적, debug, info, warn, error, off 등의 옵션과 함께 ClusterLogForwarder의 주석을 사용하여 Vector 수집기 로그 수준을 구성하는 기능이 추가되었습니다. (LOG-5372)
이번 개선된 기능에는 Amazon CloudMonitor 출력이 여러 AWS 역할을 사용하는 구성을 거부하기 위한 검증이 추가되어 잘못된 로그 라우팅이 발생하지 않습니다. (LOG-5640)
이번 개선된 기능을 통해 지표 대시보드에서 Log Cryostats Collected 및 Log Cryostats Sent 그래프가 제거됩니다. (LOG-5964)
이번 개선된 기능에서는 ClusterLogForwarder.observability.openshift.io 리소스 및 Red Hat managed LokiStack의 Vector 배포를 포함하여 로깅 6.0 구성 요소 검사에 대한 정보만 캡처하도록 must-gather 기능을 업데이트합니다. (LOG-5949)
이번 개선된 기능을 통해 특정 오류 조건에 대한 조기 경고를 제공하여 Azure 스토리지 시크릿 유효성 검사를 개선할 수 있습니다. (LOG-4571)

2.1.6. 기술 프리뷰 기능

이번 릴리스에서는 OpenTelemetry를 사용하여 로그 전달을 위한 기술 프리뷰 기능이 도입되었습니다. 새로운 출력 유형인 OTLP를 사용하면 OpenTelemetry 데이터 모델 및 리소스 의미 규칙을 사용하여 JSON 인코딩 로그 레코드를 보낼 수 있습니다. (LOG-4225)

2.1.7. 버그 수정

이번 업데이트 이전에는 CollectorHighErrorRate 및 CollectorVeryHighErrorRate 경고가 계속 표시되었습니다. 이번 업데이트를 통해 logging 6.0 릴리스에서 두 경고가 모두 제거되지만 향후 릴리스에서 반환될 수 있습니다. (LOG-3432)

2.1.8. CVE

CVE-2024-34397

2.2. 로깅 6.0

ClusterLogForwarder CR(사용자 정의 리소스)은 로그 수집 및 전달의 중앙 구성 지점입니다.

2.2.1. 입력 및 출력

입력은 전달할 로그 소스를 지정합니다. 로깅은 클러스터의 다른 부분에서 로그를 선택하는 애플리케이션,인프라 및 감사 와 같은 기본 입력 유형을 제공합니다. 네임스페이스 또는 Pod 레이블을 기반으로 사용자 정의 입력을 정의하여 로그 선택을 미세 조정할 수도 있습니다.

출력은 로그가 전송되는 대상을 정의합니다. 각 출력 유형에는 고유한 구성 옵션 세트가 있어 동작 및 인증 설정을 사용자 지정할 수 있습니다.

2.2.2. 수신자 입력 유형

수신자 입력 유형을 사용하면 로깅 시스템에서 외부 소스의 로그를 허용할 수 있습니다. 로그를 수신하기 위해 http 및 syslog 의 두 형식을 지원합니다.

ReceiverSpec 은 수신자 입력에 대한 구성을 정의합니다.

2.2.3. 파이프라인 및 필터

파이프라인은 입력에서 출력으로 로그 흐름을 결정합니다. 파이프라인은 하나 이상의 입력 참조, 출력 참조 및 선택적 필터 참조로 구성됩니다. 필터를 사용하여 파이프라인 내에서 로그 메시지를 변환하거나 삭제할 수 있습니다. 필터 순서는 순차적으로 적용되므로 중요하며 이전 필터로 인해 로그 메시지가 이후 단계에 도달하지 못할 수 있습니다.

2.2.4. Operator 동작

Cluster Logging Operator는 managementState 필드를 기반으로 수집기의 배포 및 구성을 관리합니다.

Managed (기본값)로 설정하면 Operator에서 사양에 정의된 구성과 일치하도록 로깅 리소스를 적극적으로 관리합니다.
Unmanaged 로 설정하면 Operator에서 작업을 수행하지 않으므로 로깅 구성 요소를 수동으로 관리할 수 있습니다.

2.2.5. 검증

로깅에는 광범위한 검증 규칙과 기본값이 포함되어 있어 원활하고 오류가 없는 구성 환경을 보장합니다. ClusterLogForwarder 리소스는 필수 필드, 필드 간 종속성 및 입력 값 형식에 대한 검증 검사를 적용합니다. 특정 필드에 기본값이 제공되어 일반적인 시나리오에서 명시적 구성의 필요성이 줄어듭니다.

2.2.5.1. 빠른 시작

사전 요구 사항

클러스터 관리자 권한

프로세스

OperatorHub에서 OpenShift Logging 및 Loki Operator를 설치합니다.

openshift-logging 네임스페이스에서 LokiStack CR(사용자 정의 리소스)을 생성합니다.

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  managementState: Managed
  size: 1x.extra-small
  storage:
    schemas:
    - effectiveDate: '2022-06-01'
      version: v13
    secret:
      name: logging-loki-s3
      type: s3
    storageClassName: gp3-csi
  tenants:
    mode: openshift-logging

수집기의 서비스 계정을 생성합니다.
```
$ oc create sa collector -n openshift-logging
```

수집기에 대한 ClusterRole 을 생성합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: logging-collector-logs-writer
rules:
- apiGroups:
  - loki.grafana.com
  resourceNames:
  - logs
  resources:
  - application
  - audit
  - infrastructure
  verbs:
  - create

ClusterRole 을 서비스 계정에 바인딩합니다.

$ oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z collector

Cluster Observability Operator를 설치합니다.

UIPlugin 을 생성하여 모니터링 탭의 로그 섹션을 활성화합니다.

apiVersion: observability.openshift.io/v1alpha1
kind: UIPlugin
metadata:
  name: logging
spec:
  type: Logging
  logging:
    lokiStack:
      name: logging-loki

수집기 서비스 계정에 역할을 추가합니다.

$ oc project openshift-logging
$ oc adm policy add-cluster-role-to-user collect-application-logs -z collector
$ oc adm policy add-cluster-role-to-user collect-audit-logs -z collector
$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z collector

ClusterLogForwarder CR을 생성하여 로그 전달을 구성합니다.

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  namespace: openshift-logging
spec:
  serviceAccount:
    name: collector
  outputs:
  - name: default-lokistack
    type: lokiStack
    lokiStack:
      target:
        name: logging-loki
        namespace: openshift-logging
      authentication:
        token:
          from: serviceAccount
    tls:
      ca:
        key: service-ca.crt
        configMapName: openshift-service-ca.crt
  pipelines:
  - name: default-logstore
    inputRefs:
    - application
    - infrastructure
    outputRefs:
    - default-lokistack

OpenShift 웹 콘솔의 Observe 탭의 Log 섹션에 로그가 표시되는지 확인합니다.

2.3. Logging 6.0으로 업그레이드

로깅 v6.0은 이전 릴리스에서 중요한 업그레이드로, 클러스터 로깅의 여러 장기 목표를 달성합니다.

로깅 구성 요소(예: 수집기, 스토리지, 시각화)를 관리하기 위한 별도의 운영자 소개.
Elastic 제품(예: Elasticsearch, Kibana)을 기반으로 관리형 로그 스토리지 및 시각화에 대한 지원 제거
Fluentd 로그 수집기 구현의 사용 중단
ClusterLogging.logging.openshift.io 및 ClusterLogForwarder.logging.openshift.io 리소스에 대한 지원 제거

참고

cluster-logging-operator 는 자동 업그레이드 프로세스를 제공하지 않습니다.

로그 수집, 전달 및 스토리지에 대한 다양한 구성이 제공되어 cluster-logging-operator 에서 자동 업그레이드가 제공되지 않습니다. 이 문서는 관리자가 기존 ClusterLogging.logging.openshift.io 및 ClusterLogForwarder.logging.openshift.io 사양을 새 API로 변환하는 데 도움이 됩니다. 일반적인 사용 사례에 대한 마이그레이션된 ClusterLogForwarder.observability.openshift.io 리소스의 예가 포함되어 있습니다.

2.3.1. `oc explain` 명령 사용

oc explain 명령은 OpenShift CLI oc 의 사용자 정의 리소스(CR) 내의 필드에 대한 자세한 설명을 제공하는 필수 툴입니다. 이 명령은 OpenShift 클러스터에서 리소스를 구성하거나 문제를 해결하는 관리자 및 개발자에게 매우 중요합니다.

2.3.1.1. 리소스 설명

oc explain 은 특정 오브젝트와 관련된 모든 필드에 대한 심층적인 설명을 제공합니다. 여기에는 Pod 및 서비스와 같은 표준 리소스뿐만 아니라 상태 저장 세트 및 Operator에서 정의한 사용자 정의 리소스와 같은 더 복잡한 엔티티가 포함됩니다.

ClusterLogForwarder 사용자 정의 리소스의 outputs 필드에 대한 문서를 보려면 다음을 사용합니다.

$ oc explain clusterlogforwarders.observability.openshift.io.spec.outputs

참고

clusterlogforwarder 대신 단축 형식을 사용할 수 있습니다.

그러면 유형, 기본값 및 관련 하위 필드를 포함하여 이러한 필드에 대한 자세한 정보가 표시됩니다.

2.3.1.2. 계층 구조 구조

명령은 리소스 필드의 구조를 계층 구조로 표시하여 다양한 구성 옵션 간의 관계를 명확히 합니다.

예를 들어 LokiStack 사용자 정의 리소스의 스토리지 구성을 드릴다운하는 방법은 다음과 같습니다.

$ oc explain lokistacks.loki.grafana.com
$ oc explain lokistacks.loki.grafana.com.spec
$ oc explain lokistacks.loki.grafana.com.spec.storage
$ oc explain lokistacks.loki.grafana.com.spec.storage.schemas

각 명령은 리소스 사양의 깊은 수준을 표시하여 구조를 지웁니다.

2.3.1.3. 유형 정보

oc explain 은 각 필드의 유형(예: 문자열, 정수 또는 부울)을 나타내며 리소스 정의가 올바른 데이터 유형을 사용하는지 확인할 수 있습니다.

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

$ oc explain lokistacks.loki.grafana.com.spec.size

이 경우 정수 값을 사용하여 크기를 정의해야 합니다.

2.3.1.4. 기본값

해당하는 경우 명령은 필드의 기본값을 표시하여 명시적으로 지정되지 않은 경우 사용할 값에 대한 통찰력을 제공합니다.

lokistacks.loki.grafana.com 을 예제로 다시 사용합니다.

$ oc explain lokistacks.spec.template.distributor.replicas

출력 예

GROUP:      loki.grafana.com
KIND:       LokiStack
VERSION:    v1

FIELD: replicas <integer>

DESCRIPTION:
    Replicas defines the number of replica pods of the component.

2.3.2. 로그 스토리지

이 릴리스에서 사용할 수 있는 유일한 관리형 로그 스토리지 솔루션은 loki-operator 에서 관리하는 Lokistack입니다. 이전에 관리형 Elasticsearch 오퍼링의 대안으로 사용 가능한 이 솔루션은 배포 프로세스에서 변경되지 않은 상태로 유지됩니다.

중요

elasticsearch-operator 에서 제공하는 기존 Red Hat 관리 Elasticsearch 또는 Kibana 배포를 계속 사용하려면 동일한 네임스페이스에서 ClusterLogging이라는 ClusterLogging 리소스를 제거하기 전에 elasticsearch elasticsearch 라는 Elasticsearch 리소스와 openshift-logging 네임스페이스의 kibana 라는 Kibana 리소스를 제거합니다.

임시로 ClusterLogging 을 Unmanaged상태로 설정

$ oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Unmanaged"}}' --type=merge

Elasticsearch 리소스에서 ClusterLogging ownerReferences 제거
다음 명령은 ClusterLogging 이 더 이상 Elasticsearch 리소스를 소유하지 않도록 합니다. ClusterLogging 리소스의 logStore 필드에 대한 업데이트는 더 이상 Elasticsearch 리소스에 영향을 미치지 않습니다.
```
$ oc -n openshift-logging patch elasticsearch/elasticsearch -p '{"metadata":{"ownerReferences": []}}' --type=merge
```
Kibana 리소스에서 ClusterLogging ownerReferences 제거
다음 명령은 ClusterLogging 이 더 이상 Kibana 리소스를 소유하지 않도록 합니다. ClusterLogging 리소스의 시각화 필드에 대한 업데이트는 더 이상 Kibana 리소스에 영향을 미치지 않습니다.
```
$ oc -n openshift-logging patch kibana/kibana -p '{"metadata":{"ownerReferences": []}}' --type=merge
```
ClusterLogging 을 state Managed로 설정

$ oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Managed"}}' --type=merge

2.3.3. 로그 시각화

로그 시각화를 위한 OpenShift 콘솔 UI 플러그인이 cluster-logging-operator 에서 cluster-observability-operator 로 이동되었습니다.

2.3.4. 로그 수집 및 전달

이제 observability.openshift.io API 그룹의 일부인 새 API 아래에 로그 수집 및 전달 구성이 지정됩니다. 다음 섹션에서는 이전 API 리소스의 차이점을 설명합니다.

참고

벡터는 지원되는 유일한 수집기 구현입니다.

2.3.5. 관리, 리소스 할당 및 워크로드 스케줄링

관리 상태(예: Managed, Unmanaged)에 대한 구성(예: Managed, Unmanaged), 리소스 요청 및 제한, 허용 오차 및 노드 선택이 이제 새 ClusterLogForwarder API의 일부입니다.

이전 설정

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
spec:
  managementState: "Managed"
  collection:
    resources:
      limits: {}
      requests: {}
    nodeSelector: {}
    tolerations: {}

현재 설정

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  managementState: Managed
  collector:
    resources:
      limits: {}
      requests: {}
    nodeSelector: {}
    tolerations: {}

2.3.6. 입력 사양

입력 사양은 ClusterLogForwarder 사양의 선택적 부분입니다. 관리자는 계속해서 애플리케이션,인프라 및 감사 의 사전 정의된 값을 사용하여 이러한 소스를 수집할 수 있습니다.

2.3.6.1. 애플리케이션 입력

네임스페이스 및 컨테이너 포함 및 제외가 단일 필드에 통합되었습니다.

5.9 네임스페이스 및 컨테이너가 포함된 애플리케이션 입력 및 제외

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
   - name: application-logs
     type: application
     application:
       namespaces:
       - foo
       - bar
       includes:
       - namespace: my-important
         container: main
       excludes:
       - container: too-verbose

6.0 애플리케이션 입력 네임스페이스 및 컨테이너 포함 및 제외

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
   - name: application-logs
     type: application
     application:
       includes:
       - namespace: foo
       - namespace: bar
       - namespace: my-important
         container: main
       excludes:
       - container: too-verbose

참고

애플리케이션,인프라, 감사 는 예약된 단어로, 입력을 정의할 때 이름으로 사용할 수 없습니다.

2.3.6.2. 입력 수신자

입력 수신자에 대한 변경 사항은 다음과 같습니다.

수신기 수준에서 유형의 명시적 구성입니다.
포트 설정이 수신자 수준으로 이동했습니다.

5.9 입력 수신자

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
  - name: an-http
    receiver:
      http:
        port: 8443
        format: kubeAPIAudit
  - name: a-syslog
    receiver:
      type: syslog
      syslog:
        port: 9442

6.0 입력 수신자

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
  - name: an-http
    type: receiver
    receiver:
      type: http
      port: 8443
      http:
        format: kubeAPIAudit
  - name: a-syslog
    type: receiver
    receiver:
      type: syslog
      port: 9442

2.3.7. 출력 사양

출력 사양에 대한 높은 수준의 변경 사항은 다음과 같습니다.

URL 설정은 각 출력 유형 사양으로 이동했습니다.
튜닝 매개변수는 각 출력 유형 사양으로 이동했습니다.
TLS 구성을 인증과 분리합니다.
TLS 및 인증을 위한 키 및 시크릿/구성 맵에 대한 명시적 구성입니다.

2.3.8. 보안 및 TLS 구성

보안 및 TLS 구성은 각 출력에 대한 인증 및 TLS 구성으로 구분됩니다. 관리자가 인식된 키로 시크릿을 정의하는 대신 사양에 명시적으로 정의해야 합니다. TLS 및 권한 부여 구성을 업그레이드하려면 관리자가 기존 보안을 계속 사용하려면 이전에 인식된 키를 이해해야 합니다. 다음 섹션의 예제에서는 기존 Red Hat 관리 로그 스토리지 솔루션으로 전달하도록 ClusterLogForwarder 시크릿을 구성하는 방법에 대한 세부 정보를 제공합니다.

2.3.9. Red Hat Managed Elasticsearch

v5.9 Red Hat Managed Elasticsearch로 전달

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  logStore:
    type: elasticsearch

v6.0, Red Hat Managed Elasticsearch로 전달

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: default-elasticsearch
    type: elasticsearch
    elasticsearch:
      url: https://elasticsearch:9200
      version: 6
      index: <log_type>-write-{+yyyy.MM.dd}
    tls:
      ca:
        key: ca-bundle.crt
        secretName: collector
      certificate:
        key: tls.crt
        secretName: collector
      key:
        key: tls.key
        secretName: collector
  pipelines:
  - outputRefs:
    - default-elasticsearch
  - inputRefs:
    - application
    - infrastructure

참고

이 예에서는 애플리케이션 로그가 app-write 대신 application-write alias/index에 기록됩니다.

2.3.10. Red Hat Managed LokiStack

v5.9 Red Hat Managed LokiStack으로 전달

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  logStore:
    type: lokistack
    lokistack:
      name: lokistack-dev

v6.0, Red Hat Managed LokiStack으로 전달

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: default-lokistack
    type: lokiStack
    lokiStack:
      target:
        name: lokistack-dev
        namespace: openshift-logging
      authentication:
        token:
          from: serviceAccount
    tls:
      ca:
        key: service-ca.crt
        configMapName: openshift-service-ca.crt
  pipelines:
  - outputRefs:
    - default-lokistack
  - inputRefs:
    - application
    - infrastructure

2.3.11. 필터 및 파이프라인 구성

이제 파이프라인 구성이 필요한 변환을 필터로 별도로 구성하여 출력 대상에 대한 입력 소스의 라우팅만 정의합니다. 이전 릴리스의 파이프라인의 모든 속성이 이 릴리스의 필터로 변환되었습니다. 개별 필터는 필터 사양에 정의되어 파이프라인에서 참조합니다.

5.9 필터

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
spec:
  pipelines:
   - name: application-logs
     parse: json
     labels:
       foo: bar
     detectMultilineErrors: true

6.0 필터 설정

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
spec:
  filters:
  - name: detectexception
    type: detectMultilineException
  - name: parse-json
    type: parse
  - name: labels
    type: openshiftLabels
    openshiftLabels:
      foo: bar
  pipelines:
  - name: application-logs
    filterRefs:
    - detectexception
    - labels
    - parse-json

2.3.12. 검증 및 상태

대부분의 검증은 리소스가 생성 또는 업데이트되어 즉각적인 피드백을 제공할 때 적용됩니다. 이는 이전 릴리스의 전환으로, 유효성 검사가 생성 후 수행되었으며 리소스 상태를 검사해야 합니다. 일부 검증은 생성 또는 업데이트 시 유효성을 검사할 수 없는 경우 생성 후 계속 수행됩니다.

ClusterLogForwarder.observability.openshift.io 의 인스턴스는 Operator가 로그 수집기를 배포하기 전에 다음과 같은 조건을 충족해야 합니다: Authorized, Valid, Ready. 이러한 조건의 예는 다음과 같습니다.

6.0 상태 조건

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
status:
  conditions:
  - lastTransitionTime: "2024-09-13T03:28:44Z"
    message: 'permitted to collect log types: [application]'
    reason: ClusterRolesExist
    status: "True"
    type: observability.openshift.io/Authorized
  - lastTransitionTime: "2024-09-13T12:16:45Z"
    message: ""
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/Valid
  - lastTransitionTime: "2024-09-13T12:16:45Z"
    message: ""
    reason: ReconciliationComplete
    status: "True"
    type: Ready
  filterConditions:
  - lastTransitionTime: "2024-09-13T13:02:59Z"
    message: filter "detectexception" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidFilter-detectexception
  - lastTransitionTime: "2024-09-13T13:02:59Z"
    message: filter "parse-json" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidFilter-parse-json
  inputConditions:
  - lastTransitionTime: "2024-09-13T12:23:03Z"
    message: input "application1" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidInput-application1
  outputConditions:
  - lastTransitionTime: "2024-09-13T13:02:59Z"
    message: output "default-lokistack-application1" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidOutput-default-lokistack-application1
  pipelineConditions:
  - lastTransitionTime: "2024-09-13T03:28:44Z"
    message: pipeline "default-before" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidPipeline-default-before

참고

충족되고 적용 가능한 조건은 "True"의 "상태" 값이 있습니다. "True" 이외의 상태가 있는 조건은 이유 및 문제를 설명하는 메시지를 제공합니다.

2.4. 로그 전달 구성

ClusterLogForwarder (CLF)를 사용하면 사용자가 다양한 대상으로 로그 전달을 구성할 수 있습니다. 다른 소스의 로그 메시지를 선택하고, 변환하거나 필터링할 수 있는 파이프라인을 통해 보내고, 하나 이상의 출력으로 전달할 수 있는 유연한 방법을 제공합니다.

ClusterLogForwarder의 주요 기능

입력을 사용하여 로그 메시지 선택
출력을 사용하여 외부 대상으로 로그를 전달
필터를 사용하여 로그 메시지를 필터링, 변환 및 삭제
입력, 필터 및 출력을 연결하는 로그 전달 파이프라인을 정의합니다.

2.4.1. 로그 컬렉션 설정

이 클러스터 로깅 릴리스에서는 관리자가 ClusterLogForwarder 와 연결된 서비스 계정에 로그 수집 권한을 명시적으로 부여해야 합니다. ClusterLogging 및 ClusterLogForwarder.logging.openshift.io 리소스로 구성된 레거시 로깅 시나리오의 이전 릴리스에서는 이 작업이 필요하지 않았습니다.

Red Hat OpenShift Logging Operator는 collect-audit-logs,collect-application-logs, collect-infrastructure-logs 클러스터 역할을 제공하여 수집기가 감사 로그, 애플리케이션 로그 및 인프라 로그를 각각 수집할 수 있습니다.

필요한 클러스터 역할을 서비스 계정에 바인딩하여 로그 컬렉션을 설정합니다.

2.4.1.1. 레거시 서비스 계정

기존 서비스 계정 logcollector 를 사용하려면 다음 ClusterRoleBinding 을 생성합니다.

$ oc adm policy add-cluster-role-to-user collect-application-logs system:serviceaccount:openshift-logging:logcollector
$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs system:serviceaccount:openshift-logging:logcollector

또한 감사 로그를 수집하는 경우 다음 ClusterRoleBinding 을 생성합니다.

$ oc adm policy add-cluster-role-to-user collect-audit-logs system:serviceaccount:openshift-logging:logcollector

2.4.1.2. 서비스 계정 생성

사전 요구 사항

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>

2.4.1.2.1. 서비스 계정의 클러스터 역할 바인딩

role_binding.yaml 파일은 ClusterLogging Operator의 ClusterRole을 특정 ServiceAccount에 바인딩하여 클러스터 전체에서 Kubernetes 리소스를 관리할 수 있습니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: manager-rolebinding
roleRef:                                           1
  apiGroup: rbac.authorization.k8s.io              2
  kind: ClusterRole                                3
  name: cluster-logging-operator                   4
subjects:                                          5
  - kind: ServiceAccount                           6
    name: cluster-logging-operator                 7
    namespace: openshift-logging                   8

1: roleRef: 바인딩이 적용되는 ClusterRole을 참조합니다.
2: apiGroup: RBAC API 그룹을 나타내며 ClusterRole이 Kubernetes RBAC 시스템의 일부임을 지정합니다.
3: kind: 참조된 역할이 클러스터 전체에서 적용되는 ClusterRole임을 지정합니다.
4: name: ServiceAccount에 바인딩되는 ClusterRole의 이름입니다. 여기서 cluster-logging-operator.
5: 제목: ClusterRole에서 권한을 부여하는 엔터티(사용자 또는 서비스 계정)를 정의합니다.
6: kind: subject가 ServiceAccount임을 지정합니다.
7: name: 권한이 부여된 ServiceAccount의 이름입니다.
8: namespace: ServiceAccount가 있는 네임스페이스를 나타냅니다.

2.4.1.2.2. 애플리케이션 로그 작성

write-application-logs-clusterrole.yaml 파일은 Loki 로깅 애플리케이션에 애플리케이션 로그를 작성할 수 있는 권한을 부여하는 ClusterRole을 정의합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-application-logs
rules:                                              1
  - apiGroups:                                      2
      - loki.grafana.com                            3
    resources:                                      4
      - application                                 5
    resourceNames:                                  6
      - logs                                        7
    verbs:                                          8
      - create                                      9
Annotations
<1> rules: Specifies the permissions granted by this ClusterRole.
<2> apiGroups: Refers to the API group loki.grafana.com, which relates to the Loki logging system.
<3> loki.grafana.com: The API group for managing Loki-related resources.
<4> resources: The resource type that the ClusterRole grants permission to interact with.
<5> application: Refers to the application resources within the Loki logging system.
<6> resourceNames: Specifies the names of resources that this role can manage.
<7> logs: Refers to the log resources that can be created.
<8> verbs: The actions allowed on the resources.
<9> create: Grants permission to create new logs in the Loki system.

2.4.1.2.3. 감사 로그 작성

write-audit-logs-clusterrole.yaml 파일은 Loki 로깅 시스템에서 감사 로그를 생성할 수 있는 권한을 부여하는 ClusterRole을 정의합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-audit-logs
rules:                                              1
  - apiGroups:                                      2
      - loki.grafana.com                            3
    resources:                                      4
      - audit                                       5
    resourceNames:                                  6
      - logs                                        7
    verbs:                                          8
      - create                                      9

1 1: rules: 이 ClusterRole에서 부여하는 권한을 정의합니다.
2 2: apiGroups: loki.grafana.com API 그룹을 지정합니다.
3 3: Loki.grafana.com: Loki 로깅 리소스를 담당하는 API 그룹입니다.
4 4: resources: 이 역할이 관리하는 리소스 유형을 나타냅니다(이 경우 audit).
5 5: audit: 역할이 Loki 내에서 감사 로그를 관리하도록 지정합니다.
6 6: resourceNames: 역할이 액세스할 수 있는 특정 리소스를 정의합니다.
7 7: logs: 이 역할에서 관리할 수 있는 로그를 참조합니다.
8 8: 동사: 리소스에서 허용되는 작업입니다.
9 9: create: 새 감사 로그를 생성할 수 있는 권한을 부여합니다.

2.4.1.2.4. 인프라 로그 작성

write-infrastructure-logs-clusterrole.yaml 파일은 Loki 로깅 시스템에서 인프라 로그를 생성할 수 있는 권한을 부여하는 ClusterRole을 정의합니다.

샘플 YAML

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-infrastructure-logs
rules:                                              1
  - apiGroups:                                      2
      - loki.grafana.com                            3
    resources:                                      4
      - infrastructure                              5
    resourceNames:                                  6
      - logs                                        7
    verbs:                                          8
      - create                                      9

1: rules: 이 ClusterRole에서 부여하는 권한을 지정합니다.
2: apiGroups: Loki 관련 리소스의 API 그룹을 지정합니다.
3: Loki.grafana.com: Loki 로깅 시스템을 관리하는 API 그룹입니다.
4: resources: 이 역할이 상호 작용할 수 있는 리소스 유형을 정의합니다.
5: 인프라: 이 역할이 관리하는 인프라 관련 리소스를 나타냅니다.
6: resourceNames: 이 역할이 관리할 수 있는 리소스의 이름을 지정합니다.
7: 로그: 인프라와 관련된 로그 리소스를 참조합니다.
8: 동사: 이 역할에서 허용하는 작업입니다.
9: 생성: Loki 시스템에서 인프라 로그를 생성할 수 있는 권한을 부여합니다.

2.4.1.2.5. ClusterLogForwarder 편집기 역할

clusterlogforwarder-editor-role.yaml 파일은 사용자가 OpenShift에서 ClusterLogForwarder를 관리할 수 있는 ClusterRole을 정의합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: clusterlogforwarder-editor-role
rules:                                              1
  - apiGroups:                                      2
      - observability.openshift.io                  3
    resources:                                      4
      - clusterlogforwarders                        5
    verbs:                                          6
      - create                                      7
      - delete                                      8
      - get                                         9
      - list                                        10
      - patch                                       11
      - update                                      12
      - watch                                       13

1: rules: 이 ClusterRole에서 부여하는 권한을 지정합니다.
2: apiGroups: OpenShift 관련 API 그룹을 참조합니다.
3: obervability.openshift.io: 로깅과 같은 관찰 기능 리소스를 관리하는 API 그룹입니다.
4: resources: 이 역할이 관리할 수 있는 리소스를 지정합니다.
5: clusterlogforwarders: OpenShift의 로그 전달 리소스를 참조합니다.
6: verbs: ClusterLogForwarders에 허용되는 작업을 지정합니다.
7: 생성: 새 ClusterLogForwarder를 생성할 수 있는 권한을 부여합니다.
8: delete: 기존 ClusterLogForwarder를 삭제할 수 있는 권한을 부여합니다.
9: get: 특정 ClusterLogForwarder에 대한 정보를 검색할 수 있는 권한을 부여합니다.
10: list: 모든 ClusterLogForwarder를 나열할 수 있습니다.
11: patch: ClusterLogForwarder를 부분적으로 수정할 수 있는 권한을 부여합니다.
12: update: 기존 ClusterLogForwarder를 업데이트할 수 있는 권한을 부여합니다.
13: watch: ClusterLogForwarder의 변경 사항을 모니터링할 수 있는 권한을 부여합니다.

2.4.2. 수집기에서 로그 수준 수정

수집기에서 로그 수준을 수정하려면 observability.openshift.io/log-level 주석을 추적 하도록 설정하고,디버그,info,warn,error, off 를 설정할 수 있습니다.

로그 수준 주석의 예

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  annotations:
    observability.openshift.io/log-level: debug
# ...

2.4.3. Operator 관리

ClusterLogForwarder 리소스에는 Operator가 리소스를 적극적으로 관리하는지 또는 Unmanaged 상태로 둘지 여부를 제어하는 managementState 필드가 있습니다.

관리됨: (기본값) Operator는 CLF 사양의 원하는 상태와 일치하도록 로깅 리소스를 구동합니다.
Unmanaged: Operator는 로깅 구성 요소와 관련된 작업을 수행하지 않습니다.

이를 통해 관리자는 managementState 를 Unmanaged 로 설정하여 로그 전달을 일시적으로 일시 중지할 수 있습니다.

2.4.4. ClusterLogForwarder의 구조

CLF에는 다음과 같은 주요 구성 요소가 포함된 spec 섹션이 있습니다.

입력: 전달할 로그 메시지를 선택합니다. 기본 입력 유형 애플리케이션,인프라 및 감사 는 클러스터의 다른 부분에서 로그를 전달합니다. 사용자 지정 입력을 정의할 수도 있습니다.
출력: 로그를 전달할 대상을 정의합니다. 각 출력에는 고유한 이름과 유형별 구성이 있습니다.
파이프라인: 입력에서 필터를 통해 출력으로 가져오는 경로 로그를 정의합니다. 파이프라인에는 고유한 이름이 있으며 입력, 출력 및 필터 이름 목록으로 구성됩니다.
필터: 파이프라인에서 로그 메시지를 변환하거나 삭제합니다. 사용자는 특정 로그 필드와 일치하는 필터를 정의하고 메시지를 삭제하거나 수정할 수 있습니다. 필터는 파이프라인에 지정된 순서로 적용됩니다.

2.4.4.1. 입력

입력은 spec.inputs 의 배열에 구성됩니다. 세 가지 기본 제공 입력 유형이 있습니다.

애플리케이션: 기본, openshift 또는 kube- 또는 openshift - 접두사가 있는 네임스페이스를 제외하고 모든 애플리케이션 컨테이너에서 로그를 선택합니다.
인프라: 기본 및 openshift 네임스페이스 및 노드 로그에서 실행되는 인프라 구성 요소에서 로그를 선택합니다.
audit: auditd에서 OpenShift API 서버 감사 로그, Kubernetes API 서버 감사 로그, ovn 감사 로그 및 노드 감사 로그에서 로그를 선택합니다.

사용자는 특정 네임스페이스에서 로그를 선택하거나 Pod 레이블을 사용하는 유형 애플리케이션 의 사용자 정의 입력을 정의할 수 있습니다.

2.4.4.2. 출력

출력은 spec.outputs 아래의 배열에 구성됩니다. 각 출력에는 고유한 이름과 유형이 있어야 합니다. 지원되는 유형은 다음과 같습니다.

azureMonitor: Azure Monitor로 로그를 전달합니다.
CloudMonitor: AWS CloudMonitor로 로그를 전달합니다.
elasticsearch: 로그를 외부 Elasticsearch 인스턴스로 전달합니다.
googleCloudLogging: Google Cloud Logging으로 로그를 전달합니다.
HTTP: 일반 HTTP 끝점으로 로그를 전달합니다.
kafka: Kafka 브로커로 로그를 전달합니다.
loki: 로그를 Loki 로깅 백엔드로 전달합니다.
lokistack: OpenShift Container Platform 인증 통합을 사용하여 Loki 및 웹 프록시의 로깅 지원 조합으로 로그를 전달합니다. LokiStack의 프록시는 OpenShift Container Platform 인증을 사용하여 멀티 테넌시 적용
otlp: OpenTelemetry 프로토콜을 사용하여 로그를 전달합니다.
splunk: Splunk로 로그를 전달합니다.
syslog: 로그를 외부 syslog 서버로 전달합니다.

각 출력 유형에는 고유한 구성 필드가 있습니다.

2.4.4.3. 파이프라인

파이프라인은 spec.pipelines 의 배열에 구성됩니다. 각 파이프라인에는 고유한 이름이 있어야 하며 다음으로 구성됩니다.

inputRefs: 로그가 이 파이프라인으로 전달되어야 하는 입력의 이름입니다.
outputRefs: 로그를 전송할 출력의 이름입니다.
filterRefs: (선택 사항) 적용할 필터 이름입니다.

filterRefs 순서가 순차적으로 적용되므로 중요합니다. 이전 필터는 이후 필터에서 처리되지 않는 메시지를 삭제할 수 있습니다.

2.4.4.4. 필터

필터는 spec.filters 아래의 배열에 구성됩니다. 구조화된 필드의 값을 기반으로 들어오는 로그 메시지를 일치시키고 수정하거나 삭제할 수 있습니다.

관리자는 다음 유형의 필터를 구성할 수 있습니다.

2.4.4.5. 여러 줄 예외 탐지 활성화

컨테이너 로그의 여러 줄 오류 감지를 활성화합니다.

주의

이 기능을 활성화하면 성능에 영향을 미칠 수 있으며 추가 컴퓨팅 리소스 또는 대체 로깅 솔루션이 필요할 수 있습니다.

로그 구문 분석기가 별도의 예외와 동일한 예외의 별도의 행을 잘못 식별하는 경우가 많습니다. 이로 인해 추가 로그 항목과 추적된 정보에 대한 불완전하거나 부정확한 보기가 발생합니다.

Java 예외 예

java.lang.NullPointerException: Cannot invoke "String.toString()" because "<param1>" is null
    at testjava.Main.handle(Main.java:47)
    at testjava.Main.printMe(Main.java:19)
    at testjava.Main.main(Main.java:10)

로깅을 사용하여 여러 줄 예외를 감지하고 이를 단일 로그 항목으로 재조정하려면 ClusterLogForwarder 사용자 정의 리소스(CR)에 .spec.filters 아래의 detectMultilineErrors 필드가 포함되어 있는지 확인합니다.

Example ClusterLogForwarder CR

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
  namespace: <log_forwarder_namespace>
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <name>
    type: detectMultilineException
  pipelines:
    - inputRefs:
        - <input-name>
      name: <pipeline-name>
      filterRefs:
        - <filter-name>
      outputRefs:
        - <output-name>

2.4.4.5.1. 세부 정보

로그 메시지가 예외 스택 추적을 형성하는 연속 시퀀스로 표시되면 단일 통합 로그 레코드로 결합됩니다. 첫 번째 로그 메시지의 콘텐츠는 시퀀스의 모든 메시지 필드의 연결된 콘텐츠로 교체됩니다.

수집기는 다음 언어를 지원합니다.

Java
JS
Ruby
Python
Golang
PHP
Dart

2.4.4.6. 원하지 않는 로그 레코드를 삭제하도록 콘텐츠 필터 구성

드롭 필터가 구성되면 로그 수집기는 전달 전에 필터에 따라 로그 스트림을 평가합니다. 수집기는 지정된 구성과 일치하는 원하지 않는 로그 레코드를 삭제합니다.

프로세스

ClusterLogForwarder CR의 필터 사양에 필터 구성을 추가합니다.
다음 예제에서는 정규식을 기반으로 로그 레코드를 삭제하도록 ClusterLogForwarder CR을 구성하는 방법을 보여줍니다.
ClusterLogForwarder CR의 예
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <filter_name>
    type: drop 1
    drop: 2
    - test: 3
      - field: .kubernetes.labels."foo-bar/baz" 4
        matches: .+ 5
      - field: .kubernetes.pod_name
        notMatches: "my-pod" 6
  pipelines:
  - name: <pipeline_name> 7
    filterRefs: ["<filter_name>"]
# ...
```
1
필터 유형을 지정합니다. drop 필터는 필터 구성과 일치하는 로그 레코드를 삭제합니다.
2
드롭 필터를 적용하기 위한 구성 옵션을 지정합니다.
3
로그 레코드 삭제 여부를 평가하는 데 사용되는 테스트에 대한 구성을 지정합니다.
테스트에 지정된 모든 조건이 true이면 테스트가 통과되고 로그 레코드가 삭제됩니다.
drop 필터 구성에 대해 여러 테스트가 지정되면 테스트가 통과하면 레코드가 삭제됩니다.
예를 들어 평가 중인 로그 레코드에서 필드가 누락되면 해당 조건이 false로 평가됩니다.
4
로그 레코드의 필드 경로인 점으로 구분된 필드 경로를 지정합니다. 경로에는 alpha-numeric 문자 및 밑줄(a-zA-Z0-9_)을 포함할 수 있습니다(예: .kubernetes.namespace_name ). 세그먼트에 이 범위를 벗어나는 문자가 포함된 경우 세그먼트는 따옴표로 묶어야 합니다(예: .kubernetes.labels."foo.bar-bar/baz". 단일 테스트 구성에 여러 필드 경로를 포함할 수 있지만 테스트가 통과하고 drop 필터를 적용하려면 모두 true로 평가되어야 합니다.
5
정규식을 지정합니다. 로그 레코드가 이 정규식과 일치하는 경우 해당 레코드가 삭제됩니다. 단일 필드 경로에 대해 matches 또는 notMatches 조건을 설정할 수 있지만 둘 다 설정할 수는 없습니다.
6
정규식을 지정합니다. 로그 레코드가 이 정규식과 일치하지 않으면 삭제됩니다. 단일 필드 경로에 대해 matches 또는 notMatches 조건을 설정할 수 있지만 둘 다 설정할 수는 없습니다.
7
drop 필터가 적용되는 파이프라인을 지정합니다.
다음 명령을 실행하여 ClusterLogForwarder CR을 적용합니다.
```
$ oc apply -f <filename>.yaml
```

추가 예

다음 추가 예제에서는 우선 순위가 높은 로그 레코드만 유지하도록 drop 필터를 구성하는 방법을 보여줍니다.

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: important
    type: drop
    drop:
    - test:
      - field: .message
        notMatches: "(?i)critical|error"
      - field: .level
        matches: "info|warning"
# ...

단일 테스트 구성에 여러 필드 경로를 포함하는 것 외에도 또는 검사로 처리되는 추가 테스트를 포함할 수도 있습니다. 다음 예에서는 테스트 구성이 true로 평가되면 레코드가 삭제됩니다. 그러나 두 번째 테스트 구성의 경우 두 필드 사양을 모두 true로 평가하려면 모두 true여야 합니다.

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: important
    type: drop
    drop:
    - test:
      - field: .kubernetes.namespace_name
        matches: "^open"
    - test:
      - field: .log_type
        matches: "application"
      - field: .kubernetes.pod_name
        notMatches: "my-pod"
# ...

2.4.4.7. API 감사 필터 개요

OpenShift API 서버는 각 API 호출에 대한 감사 이벤트를 생성하여 요청자의 요청, 응답 및 ID를 자세히 설명하여 대량의 데이터를 생성합니다. API 감사 필터는 규칙을 사용하여 필수가 아닌 이벤트를 제외하고 이벤트 크기 감소를 활성화하여 보다 관리가 용이한 감사 추적을 지원합니다. 규칙은 순서대로 확인되며 첫 번째 일치 시에 확인 중지됩니다. 이벤트에 포함된 데이터 양은 수준 필드의 값에 따라 결정됩니다.

없음: 이벤트가 삭제되었습니다.
metadata: 감사 메타데이터가 포함되어 요청 및 응답 본문이 제거됩니다.
요청: 감사 메타데이터와 요청 본문이 포함되어 응답 본문이 제거됩니다.
RequestResponse: 메타데이터, 요청 본문, 응답 본문 등 모든 데이터가 포함됩니다. 응답 본문은 매우 커질 수 있습니다. 예를 들어 oc get pods -A 는 클러스터의 모든 포드에 대한 YAML 설명이 포함된 응답 본문을 생성합니다.

ClusterLogForwarder CR(사용자 정의 리소스)은 다음과 같은 추가 기능을 제공하는 동안 표준 Kubernetes 감사 정책과 동일한 형식을 사용합니다.

와일드카드

사용자, 그룹, 네임스페이스 및 리소스의 이름에는 선행 또는 후행 * 별표 문자가 있을 수 있습니다. 예를 들어 openshift-\* 네임스페이스는 openshift-apiserver 또는 openshift-authentication 과 일치합니다. 리소스 \*/status 는 Pod/status 또는 Deployment/status 와 일치합니다.

기본 규칙

정책의 규칙과 일치하지 않는 이벤트는 다음과 같이 필터링됩니다.

get,list 및 watch 와 같은 읽기 전용 시스템 이벤트가 삭제됩니다.
서비스 계정은 서비스 계정과 동일한 네임스페이스 내에서 발생하는 이벤트를 기록합니다.
기타 모든 이벤트는 구성된 속도 제한에 따라 전달됩니다.

이러한 기본값을 비활성화하려면 수준 필드만 있는 규칙으로 규칙 목록을 종료하거나 빈 규칙을 추가합니다.

응답 코드 생략: 생략할 정수 상태 코드 목록입니다. 이벤트가 생성되지 않은 HTTP 상태 코드를 나열하는 OmitResponseCodes 필드를 사용하여 응답에서 HTTP 상태 코드를 기반으로 이벤트를 삭제할 수 있습니다. 기본값은 [404, 409, 422, 429] 입니다. 값이 빈 목록 [] 인 경우 상태 코드는 생략되지 않습니다.

ClusterLogForwarder CR 감사 정책은 OpenShift Container Platform 감사 정책 외에도 작동합니다. ClusterLogForwarder CR 감사 필터는 로그 수집기가 전달하는 내용을 변경하고 동사, 사용자, 그룹, 네임스페이스 또는 리소스별로 필터링하는 기능을 제공합니다. 여러 필터를 생성하여 동일한 감사 스트림의 다른 요약을 다른 위치로 보낼 수 있습니다. 예를 들어 자세한 스트림을 로컬 클러스터 로그 저장소로 전송하고 더 자세한 스트림을 원격 사이트로 보낼 수 있습니다.

참고

감사 로그를 수집하려면 클러스터 역할 collect-audit-logs 가 있어야 합니다. 제공된 다음 예제는 감사 정책에서 가능한 규칙 범위를 설명하기 위한 것이며 권장되는 구성은 아닙니다.

감사 정책의 예

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
  namespace: <log_forwarder_namespace>
spec:
  serviceAccount:
    name: <service_account_name>
  pipelines:
    - name: my-pipeline
      inputRefs: audit 1
      filterRefs: my-policy 2
  filters:
    - name: my-policy
      type: kubeAPIAudit
      kubeAPIAudit:
        # Don't generate audit events for all requests in RequestReceived stage.
        omitStages:
          - "RequestReceived"

        rules:
          # Log pod changes at RequestResponse level
          - level: RequestResponse
            resources:
            - group: ""
              resources: ["pods"]

          # Log "pods/log", "pods/status" at Metadata level
          - level: Metadata
            resources:
            - group: ""
              resources: ["pods/log", "pods/status"]

          # Don't log requests to a configmap called "controller-leader"
          - level: None
            resources:
            - group: ""
              resources: ["configmaps"]
              resourceNames: ["controller-leader"]

          # Don't log watch requests by the "system:kube-proxy" on endpoints or services
          - level: None
            users: ["system:kube-proxy"]
            verbs: ["watch"]
            resources:
            - group: "" # core API group
              resources: ["endpoints", "services"]

          # Don't log authenticated requests to certain non-resource URL paths.
          - level: None
            userGroups: ["system:authenticated"]
            nonResourceURLs:
            - "/api*" # Wildcard matching.
            - "/version"

          # Log the request body of configmap changes in kube-system.
          - level: Request
            resources:
            - group: "" # core API group
              resources: ["configmaps"]
            # This rule only applies to resources in the "kube-system" namespace.
            # The empty string "" can be used to select non-namespaced resources.
            namespaces: ["kube-system"]

          # Log configmap and secret changes in all other namespaces at the Metadata level.
          - level: Metadata
            resources:
            - group: "" # core API group
              resources: ["secrets", "configmaps"]

          # Log all other resources in core and extensions at the Request level.
          - level: Request
            resources:
            - group: "" # core API group
            - group: "extensions" # Version of group should NOT be included.

          # A catch-all rule to log all other requests at the Metadata level.
          - level: Metadata

1: 수집되는 로그 유형입니다. 이 필드의 값은 감사 로그, 애플리케이션 로그의 애플리케이션, 인프라 로그용 인프라 또는 애플리케이션에 대해 정의된 이름이 지정된 입력에 대한 감사일 수 있습니다.
2: 감사 정책의 이름입니다.

2.4.4.8. 레이블 표현식 또는 일치하는 라벨 키와 값을 포함하여 입력 시 애플리케이션 로그 필터링

입력 선택기를 사용하여 라벨 표현식 또는 일치하는 라벨 키와 해당 값을 기반으로 애플리케이션 로그를 포함할 수 있습니다.

프로세스

ClusterLogForwarder CR의 입력 사양에 필터 구성을 추가합니다.
다음 예제에서는 라벨 표현식 또는 일치하는 라벨 키/값에 따라 로그를 포함하도록 ClusterLogForwarder CR을 구성하는 방법을 보여줍니다.
ClusterLogForwarder CR의 예
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs
      application:
        selector:
          matchExpressions:
          - key: env 1
            operator: In 2
            values: ["prod", "qa"] 3
          - key: zone
            operator: NotIn
            values: ["east", "west"]
          matchLabels: 4
            app: one
            name: app1
      type: application
# ...
```
1
일치시킬 레이블 키를 지정합니다.
2
Operator를 지정합니다. 유효한 값에는 in,NotIn,Exists 및 DoesNotExist 가 있습니다.
3
문자열 값의 배열을 지정합니다. operator 값이 Exists 또는 DoesNotExist 이면 값 배열이 비어 있어야 합니다.
4
정확한 키 또는 값 매핑을 지정합니다.
다음 명령을 실행하여 ClusterLogForwarder CR을 적용합니다.
```
$ oc apply -f <filename>.yaml
```

2.4.4.9. 로그 레코드를 정리하도록 콘텐츠 필터 구성

정리 필터가 구성되면 로그 수집기는 전달 전에 필터에 따라 로그 스트림을 평가합니다. 수집기는 Pod 주석과 같은 낮은 값 필드를 제거하여 로그 레코드를 정리합니다.

프로세스

ClusterLogForwarder CR의 prune 사양에 필터 구성을 추가합니다.
다음 예제에서는 필드 경로를 기반으로 로그 레코드를 정리하도록 ClusterLogForwarder CR을 구성하는 방법을 보여줍니다.
중요
둘 다 지정된 경우 먼저 notIn 배열에 따라 레코드가 정리되며, 이 경우 in 배열보다 우선합니다. notIn 배열을 사용하여 레코드를 정리하면 in 배열을 사용하여 정리됩니다.
ClusterLogForwarder CR의 예
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <filter_name>
    type: prune 1
    prune: 2
      in: [.kubernetes.annotations, .kubernetes.namespace_id] 3
      notIn: [.kubernetes,.log_type,.message,."@timestamp"] 4
  pipelines:
  - name: <pipeline_name> 5
    filterRefs: ["<filter_name>"]
# ...
```
1
필터 유형을 지정합니다. prune 필터는 구성된 필드를 통해 로그 레코드를 정리합니다.
2
prune 필터를 적용하기 위한 구성 옵션을 지정합니다. in 및 notIn 필드는 로그 레코드의 필드 경로의 경로인 점으로 구분된 필드 경로의 배열로 지정됩니다. 이러한 경로에는 alpha-numeric 문자 및 밑줄(a-zA-Z0-9_)을 포함할 수 있습니다(예: .kubernetes.namespace_name ). 세그먼트에 이 범위를 벗어나는 문자가 포함된 경우 세그먼트는 따옴표로 묶어야 합니다(예: .kubernetes.labels."foo.bar-bar/baz".
3
선택 사항: 이 배열에 지정된 모든 필드는 로그 레코드에서 제거됩니다.
4
선택 사항: 이 배열에 지정되지 않은 모든 필드는 로그 레코드에서 제거됩니다.
5
prune 필터가 적용되는 파이프라인을 지정합니다.
참고
필터는 log_type,.log_source, .message 필드를 제외합니다.
다음 명령을 실행하여 ClusterLogForwarder CR을 적용합니다.
```
$ oc apply -f <filename>.yaml
```

2.4.5. 소스로 감사 및 인프라 로그 입력 필터링

입력 선택기를 사용하여 로그를 수집할 감사 및 인프라 소스 목록을 정의할 수 있습니다.

프로세스

ClusterLogForwarder CR에서 감사 및 인프라 소스를 정의하는 구성을 추가합니다.
다음 예제에서는 감사 및 인프라 소스를 정의하도록 ClusterLogForwarder CR을 구성하는 방법을 보여줍니다.
ClusterLogForwarder CR의 예
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs1
      type: infrastructure
      infrastructure:
        sources: 1
          - node
    - name: mylogs2
      type: audit
      audit:
        sources: 2
          - kubeAPI
          - openshiftAPI
          - ovn
# ...
```
1
수집할 인프라 소스 목록을 지정합니다. 유효한 소스는 다음과 같습니다.
Node: 노드에서 저널 로그
컨테이너: 네임스페이스에 배포된 워크로드의 로그
2
수집할 감사 소스 목록을 지정합니다. 유효한 소스는 다음과 같습니다.
kubeAPI: Kubernetes API 서버의 로그
openshiftAPI: OpenShift API 서버의 로그
auditd: 노드 auditd 서비스의 로그
OVN: 오픈 가상 네트워크 서비스의 로그
다음 명령을 실행하여 ClusterLogForwarder CR을 적용합니다.
```
$ oc apply -f <filename>.yaml
```

2.4.6. 네임스페이스 또는 컨테이너 이름을 포함하거나 제외하여 입력 시 애플리케이션 로그 필터링

입력 선택기를 사용하여 네임스페이스 및 컨테이너 이름을 기반으로 애플리케이션 로그를 포함하거나 제외할 수 있습니다.

프로세스

ClusterLogForwarder CR에 네임스페이스 및 컨테이너 이름을 포함하거나 제외하는 구성을 추가합니다.
다음 예제에서는 네임스페이스 및 컨테이너 이름을 포함하거나 제외하도록 ClusterLogForwarder CR을 구성하는 방법을 보여줍니다.
ClusterLogForwarder CR의 예
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs
      application:
        includes:
          - namespace: "my-project" 1
            container: "my-container" 2
        excludes:
          - container: "other-container*" 3
            namespace: "other-namespace" 4
      type: application
# ...
```
1
이러한 네임스페이스에서만 로그를 수집하도록 지정합니다.
2
이러한 컨테이너에서만 로그를 수집하도록 지정합니다.
3
로그를 수집할 때 무시할 네임스페이스 패턴을 지정합니다.
4
로그를 수집할 때 무시할 컨테이너 세트를 지정합니다.
참고
excludes 필드는 includes 필드보다 우선합니다.
다음 명령을 실행하여 ClusterLogForwarder CR을 적용합니다.
```
$ oc apply -f <filename>.yaml
```

2.5. LokiStack을 사용하여 로그 저장

애플리케이션, 감사 및 인프라 관련 로그를 저장하도록 LokiStack CR을 구성할 수 있습니다.

Loki는 수평으로 확장 가능한 고가용성 다중 테넌트 로그 집계 시스템으로 OpenShift Observability UI로 시각화할 수 있는 Red Hat OpenShift의 로깅을 위한 GA 로그 저장소로 제공됩니다. OpenShift Logging에서 제공하는 Loki 구성은 사용자가 수집된 로그를 사용하여 빠른 문제 해결을 수행할 수 있도록 설계된 단기 로그 저장소입니다. 이를 위해 Loki의 Red Hat OpenShift 구성에 대한 로깅은 단기 스토리지가 있으며 최근 쿼리에 최적화되어 있습니다.

중요

장기간의 기간 동안의 스토리지 또는 쿼리의 경우 사용자는 클러스터 외부에 있는 저장소를 로그하려고 합니다. Loki 크기 조정은 최대 30일 동안 단기 스토리지에서만 테스트 및 지원됩니다.

2.5.1. 사전 요구 사항

CLI 또는 웹 콘솔을 사용하여 Loki Operator를 설치했습니다.
ClusterLogForwarder 를 생성하는 동일한 네임스페이스에 serviceAccount 가 있습니다.
serviceAccount 에는 collect-audit-logs,collect-application-logs, collect-infrastructure-logs 클러스터 역할이 할당됩니다.

2.5.2. 코어 설정 및 구성

Loki를 배포하기 위한 역할 기반 액세스 제어, 기본 모니터링 및 Pod 배치입니다.

2.5.3. Loki 배포 크기 조정

Loki의 크기 조정은 1x.<size> 형식을 따릅니다. 여기서 1x 값은 인스턴스 수이고 < size >는 성능 기능을 지정합니다.

1x.pico 구성은 최소한의 리소스 및 제한 요구 사항으로 단일 Loki 배포를 정의하여 모든 Loki 구성 요소에 대한 HA(고가용성) 지원을 제공합니다. 이 구성은 단일 복제 요소 또는 자동 컴파일이 필요하지 않은 배포에 적합합니다.

디스크 요청은 크기 구성에서 유사합니다. 고객이 다양한 크기를 테스트하여 배포 요구 사항에 가장 적합한지 확인할 수 있습니다.

중요

배포 크기에 대해 숫자 1x 를 변경할 수 없습니다.

표 2.2. Loki 크기 조정
	1x.demo	1x.pico [6.1+ only]	1x.extra-windows	1x.small	1x.medium
데이터 전송	데모만 사용	50GB/일	100GB/일	500GB/일	2TB/일
초당 쿼리(QPS)	데모만 사용	200ms에서 1-25 QPS	200ms에서 1-25 QPS	25-50 QPS (200ms)	25-75 QPS (200ms)
복제 요인	없음	2	2	2	2
총 CPU 요청	없음	7개의 vCPU	14개의 vCPU	34 vCPU	54 vCPU
ruler을 사용하는 경우 총 CPU 요청	없음	8개의 vCPU	16개의 vCPU	42 vCPU	70개의 vCPU
총 메모리 요청	없음	17GI	31Gi	67Gi	139Gi
룰러를 사용하는 경우 총 메모리 요청	없음	18GI	35Gi	83Gi	171Gi
총 디스크 요청	40Gi	590Gi	430Gi	430Gi	590Gi
ruler을 사용하는 경우 총 디스크 요청	80Gi	910Gi	750Gi	750Gi	910Gi

2.5.4. LokiStack 규칙 RBAC 권한 승인

관리자는 클러스터 역할을 사용자 이름에 바인딩하여 사용자가 자체 경고 및 레코딩 규칙을 생성하고 관리할 수 있습니다. 클러스터 역할은 사용자에게 필요한 RBAC(역할 기반 액세스 제어) 권한이 포함된 ClusterRole 오브젝트로 정의됩니다.

경고 및 레코딩 규칙에 대한 다음 클러스터 역할은 LokiStack에 사용할 수 있습니다.

규칙 이름	설명
`alertingrules.loki.grafana.com-v1-admin`	이 역할의 사용자에게는 경고 규칙을 관리할 수 있는 관리 수준 액세스 권한이 있습니다. 이 클러스터 역할은 `loki.grafana.com/v1` API 그룹 내에서 `AlertingRule` 리소스를 생성, 읽기, 업데이트, 삭제, 나열 및 조사할 수 있는 권한을 부여합니다.
`alertingrules.loki.grafana.com-v1-crdview`	이 역할의 사용자는 `loki.grafana.com/v1` API 그룹 내의 `AlertingRule` 리소스와 관련된 CRD(Custom Resource Definitions)의 정의를 볼 수 있지만 이러한 리소스를 수정하거나 관리할 수 있는 권한은 없습니다.
`alertingrules.loki.grafana.com-v1-edit`	이 역할의 사용자는 `AlertingRule` 리소스를 생성, 업데이트 및 삭제할 수 있는 권한이 있습니다.
`alertingrules.loki.grafana.com-v1-view`	이 역할의 사용자는 `loki.grafana.com/v1` API 그룹 내에서 `AlertingRule` 리소스를 읽을 수 있습니다. 기존 경고 규칙에 대한 구성, 라벨 및 주석을 검사할 수 있지만 수정할 수는 없습니다.
`recordingrules.loki.grafana.com-v1-admin`	이 역할의 사용자는 레코딩 규칙을 관리할 수 있는 관리 수준의 액세스 권한이 있습니다. 이 클러스터 역할은 `loki.grafana.com/v1` API 그룹 내의 `RecordingRule` 리소스를 생성, 읽기, 업데이트, 삭제, 나열 및 감시할 수 있는 권한을 부여합니다.
`recordingrules.loki.grafana.com-v1-crdview`	이 역할의 사용자는 `loki.grafana.com/v1` API 그룹 내의 `RecordingRule` 리소스와 관련된 CRD(Custom Resource Definitions)의 정의를 볼 수 있지만 이러한 리소스를 수정하거나 관리할 수 있는 권한은 없습니다.
`recordingrules.loki.grafana.com-v1-edit`	이 역할의 사용자는 `RecordingRule` 리소스를 생성, 업데이트 및 삭제할 수 있는 권한이 있습니다.
`recordingrules.loki.grafana.com-v1-view`	이 역할의 사용자는 `loki.grafana.com/v1` API 그룹 내에서 `RecordingRule` 리소스를 읽을 수 있습니다. 기존 경고 규칙에 대한 구성, 라벨 및 주석을 검사할 수 있지만 수정할 수는 없습니다.

2.5.4.1. 예

사용자의 클러스터 역할을 적용하려면 기존 클러스터 역할을 특정 사용자 이름에 바인딩해야 합니다.

클러스터 역할은 사용하는 역할 바인딩 유형에 따라 클러스터 또는 네임스페이스 범위일 수 있습니다. RoleBinding 오브젝트가 사용되는 경우 oc adm policy add-role-to-user 명령을 사용하는 경우 클러스터 역할은 지정된 네임스페이스에만 적용됩니다. oc adm policy add-cluster-role-to-user 명령을 사용할 때 ClusterRoleBinding 오브젝트가 사용되는 경우 클러스터 역할은 클러스터의 모든 네임스페이스에 적용됩니다.

다음 예제 명령은 클러스터의 특정 네임스페이스의 경고 규칙에 대해 지정된 사용자 생성, 읽기, 업데이트 및 삭제(CRUD) 권한을 제공합니다.

특정 네임스페이스에서 경고 규칙 CRUD 권한에 대한 클러스터 역할 바인딩 명령의 예

$ oc adm policy add-role-to-user alertingrules.loki.grafana.com-v1-admin -n <namespace> <username>

다음 명령은 모든 네임스페이스의 경고 규칙에 대해 지정된 사용자 관리자 권한을 부여합니다.

관리자 권한에 대한 클러스터 역할 바인딩 명령의 예

$ oc adm policy add-cluster-role-to-user alertingrules.loki.grafana.com-v1-admin <username>

2.5.5. Loki를 사용하여 로그 기반 경고 규칙 생성

AlertingRule CR에는 단일 LokiStack 인스턴스에 대한 경고 규칙 그룹을 선언하는 일련의 사양 및 Webhook 검증 정의가 포함되어 있습니다. 또한 웹 후크 검증 정의에서는 규칙 검증 조건을 지원합니다.

AlertingRule CR에 잘못된 간격 기간이 포함된 경우 잘못된 경고 규칙입니다.
AlertingRule CR 에 기간 동안 유효하지 않은 항목이 포함된 경우 잘못된 경고 규칙입니다.
AlertingRule CR에 잘못된 LogQL expr 가 포함된 경우 잘못된 경고 규칙입니다.
AlertingRule CR에 동일한 이름의 두 개의 그룹이 포함된 경우 잘못된 경고 규칙입니다.
위의 어느 것도 적용되지 않으면 경고 규칙이 유효한 것으로 간주됩니다.

표 2.3. AlertingRule 정의
테넌트 유형	`AlertingRule` CR을 위한 유효한 네임스페이스
애플리케이션	`<your_application_namespace>`
audit	`openshift-logging`
인프라	`openshift-/`, `kube-/\`, `default`

프로세스

AlertingRule 사용자 정의 리소스(CR)를 생성합니다.

인프라 AlertingRule CR의 예

  apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: loki-operator-alerts
    namespace: openshift-operators-redhat 1
    labels: 2
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "infrastructure" 3
    groups:
      - name: LokiOperatorHighReconciliationError
        rules:
          - alert: HighPercentageError
            expr: | 4
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"} |= "error" [1m])) by (job)
                /
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"}[1m])) by (job)
                > 0.01
            for: 10s
            labels:
              severity: critical 5
            annotations:
              summary: High Loki Operator Reconciliation Errors 6
              description: High Loki Operator Reconciliation Errors 7

1: 이 AlertingRule CR이 생성되는 네임스페이스에는 LokiStack spec.rules.namespaceSelector 정의와 일치하는 레이블이 있어야 합니다.
2: labels 블록은 LokiStack spec.rules.selector 정의와 일치해야 합니다.
3: 인프라 테넌트에 대한 AlertingRule CR은 openshift-*, kube-\* 또는 default 네임스페이스에서만 지원됩니다.
4: kubernetes_namespace_name: 의 값은 metadata.namespace 값과 일치해야 합니다.
5: 이 필수 필드의 값은 중요,경고 또는 정보 여야 합니다.
6: 이 필드는 필수입니다.
7: 이 필드는 필수입니다.

애플리케이션 AlertingRule CR의 예

  apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: app-user-workload
    namespace: app-ns 1
    labels: 2
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "application"
    groups:
      - name: AppUserWorkloadHighError
        rules:
          - alert:
            expr: | 3
              sum(rate({kubernetes_namespace_name="app-ns", kubernetes_pod_name=~"podName.*"} |= "error" [1m])) by (job)
            for: 10s
            labels:
              severity: critical 4
            annotations:
              summary:  5
              description:  6

1: 이 AlertingRule CR이 생성되는 네임스페이스에는 LokiStack spec.rules.namespaceSelector 정의와 일치하는 레이블이 있어야 합니다.
2: labels 블록은 LokiStack spec.rules.selector 정의와 일치해야 합니다.
3: kubernetes_namespace_name: 의 값은 metadata.namespace 값과 일치해야 합니다.
4: 이 필수 필드의 값은 중요,경고 또는 정보 여야 합니다.
5: 이 필수 필드의 값은 규칙에 대한 요약입니다.
6: 이 필수 필드의 값은 규칙에 대한 자세한 설명입니다.

AlertingRule CR을 적용합니다.
```
$ oc apply -f <filename>.yaml
```

2.5.6. 멤버 목록 생성 실패를 허용하도록 Loki 구성

OpenShift Container Platform 클러스터에서 관리자는 일반적으로 개인 IP 네트워크 범위를 사용합니다. 결과적으로 LokiStack 멤버 목록 구성은 기본적으로 개인 IP 네트워크만 사용하므로 실패합니다.

관리자는 memberlist 구성에 대한 Pod 네트워크를 선택할 수 있습니다. hashRing 사양에서 podIP 주소를 사용하도록 LokiStack CR(사용자 정의 리소스)을 수정할 수 있습니다. LokiStack CR을 구성하려면 다음 명령을 사용합니다.

$ oc patch LokiStack logging-loki -n openshift-logging  --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP"},"type":"memberlist"}}}'

podIP를 포함하는 LokiStack의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  hashRing:
    type: memberlist
    memberlist:
      instanceAddrType: podIP
# ...

2.5.7. Loki를 사용하여 스트림 기반 보존 활성화

로그 스트림을 기반으로 보존 정책을 구성할 수 있습니다. 이러한 규칙에 대한 규칙은 전역적으로, 테넌트별로 또는 둘 다 설정할 수 있습니다. 둘 다 구성하는 경우 테넌트 규칙이 글로벌 규칙 앞에 적용됩니다.

중요

s3 버킷 또는 LokiStack 사용자 정의 리소스(CR)에 정의된 보존 기간이 없으면 로그가 정리되지 않고 s3 스토리지를 채울 수 있습니다.

참고

스키마 v13이 권장됩니다.

프로세스

LokiStack CR을 생성합니다.

다음 예와 같이 스트림 기반 보존을 전역적으로 활성화합니다.

AWS에 대한 글로벌 스트림 기반 보존의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
   global: 1
      retention: 2
        days: 20
        streams:
        - days: 4
          priority: 1
          selector: '{kubernetes_namespace_name=~"test.+"}' 3
        - days: 1
          priority: 1
          selector: '{log_type="infrastructure"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v13
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging

1: 모든 로그 스트림에 대한 보존 정책을 설정합니다. 참고: 이 필드는 오브젝트 스토리지에 저장된 로그의 보존 기간에는 영향을 미치지 않습니다.
2: 이 블록이 CR에 추가되면 클러스터에서 보존이 활성화됩니다.
3: 로그 스트림.spec: 제한을 정의하는 데 사용되는 LogQL 쿼리 를 포함합니다.

다음 예와 같이 테넌트별로 스트림 기반 보존을 활성화합니다.

AWS에 대한 테넌트별 스트림 기반 보존 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      retention:
        days: 20
    tenants: 1
      application:
        retention:
          days: 1
          streams:
            - days: 4
              selector: '{kubernetes_namespace_name=~"test.+"}' 2
      infrastructure:
        retention:
          days: 5
          streams:
            - days: 1
              selector: '{kubernetes_namespace_name=~"openshift-cluster.+"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v13
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging

1: 테넌트별 보존 정책을 설정합니다. 유효한 테넌트 유형은 애플리케이션,감사 및 인프라 입니다.
2: 로그 스트림을 정의하는 데 사용되는 LogQL 쿼리 를 포함합니다.

LokiStack CR을 적용합니다.
```
$ oc apply -f <filename>.yaml
```

2.5.8. Loki Pod 배치

Pod의 허용 오차 또는 노드 선택기를 사용하여 Loki Pod가 실행되는 노드를 제어하고 다른 워크로드가 해당 노드를 사용하지 못하도록 할 수 있습니다.

LokiStack CR(사용자 정의 리소스)을 사용하여 로그 저장소 Pod에 허용 오차를 적용하고 노드 사양이 있는 노드에 taint를 적용할 수 있습니다. 노드의 테인트는 테인트를 허용하지 않는 모든 Pod를 거절하도록 노드에 지시하는 키:값 쌍입니다. 다른 Pod에 없는 특정 키:값 쌍을 사용하면 해당 노드에서 로그 저장소 Pod만 실행할 수 있습니다.

노드 선택기가 있는 LokiStack의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor: 1
      nodeSelector:
        node-role.kubernetes.io/infra: "" 2
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
# ...

1: 노드 선택기에 적용되는 구성 요소 Pod 유형을 지정합니다.
2: 정의된 라벨이 포함된 노드로 이동되는 Pod를 지정합니다.

노드 선택기 및 허용 오차가 있는 LokiStack CR의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
# ...

LokiStack(CR)의 nodeSelector 및 허용 오차 필드를 구성하려면 oc explain 명령을 사용하여 특정 리소스에 대한 설명 및 필드를 볼 수 있습니다.

$ oc explain lokistack.spec.template

출력 예

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: template <Object>

DESCRIPTION:
     Template defines the resource/limits/tolerations/nodeselectors per
     component

FIELDS:
   compactor	<Object>
     Compactor defines the compaction component spec.

   distributor	<Object>
     Distributor defines the distributor component spec.
...

자세한 내용은 특정 필드를 추가할 수 있습니다.

$ oc explain lokistack.spec.template.compactor

출력 예

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: compactor <Object>

DESCRIPTION:
     Compactor defines the compaction component spec.

FIELDS:
   nodeSelector	<map[string]string>
     NodeSelector defines the labels required by a node to schedule the
     component onto it.
...

2.5.8.1. 향상된 신뢰성 및 성능

프로덕션 환경에서 Loki의 안정성 및 효율성을 보장하는 구성입니다.

2.5.8.2. 수명이 짧은 토큰을 사용하여 클라우드 기반 로그 저장소에 대한 인증 활성화

워크로드 ID 페더레이션을 통해 단기 토큰을 사용하여 클라우드 기반 로그 저장소에 인증할 수 있습니다.

프로세스

다음 옵션 중 하나를 사용하여 인증을 활성화합니다.

OpenShift Container Platform 웹 콘솔을 사용하여 Loki Operator를 설치하면 수명이 짧은 토큰을 사용하는 클러스터가 자동으로 감지됩니다. 역할을 생성하고 Loki Operator에서 보안을 채우는 CredentialsRequest 오브젝트를 생성하는 데 필요한 데이터를 제공하라는 메시지가 표시됩니다.

OpenShift CLI(oc)를 사용하여 Loki Operator를 설치하는 경우 다음 예와 같이 스토리지 공급자에 적절한 템플릿을 사용하여 Subscription 오브젝트를 수동으로 생성해야 합니다. 이 인증 전략은 표시된 스토리지 공급자에 대해서만 지원됩니다.

Azure 샘플 서브스크립션의 예

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-6.0"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
      - name: CLIENTID
        value: <your_client_id>
      - name: TENANTID
        value: <your_tenant_id>
      - name: SUBSCRIPTIONID
        value: <your_subscription_id>
      - name: REGION
        value: <your_region>

AWS 샘플 서브스크립션 예

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-6.0"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: ROLEARN
      value: <role_ARN>

2.5.8.3. 노드 장애를 허용하도록 Loki 구성

Loki Operator는 Pod 유사성 방지 규칙을 설정하여 동일한 구성 요소의 Pod가 클러스터의 다른 사용 가능한 노드에 예약되도록 요청할 수 있습니다.

유사성은 예약할 노드를 제어하는 Pod의 속성입니다. 유사성 방지는 Pod가 노드에서 예약되지 않도록 하는 Pod의 속성입니다.

OpenShift Container Platform에서 Pod 유사성 및 Pod 유사성 방지를 사용하면 다른 Pod의 키 값 라벨에 따라 Pod를 예약할 수 있는 노드를 제한할 수 있습니다.

Operator는 compactor,distributor,gateway,indexGateway,ingester,querier,queryFrontend 및 ruler 구성 요소를 포함하는 모든 Loki 구성 요소에 대해 기본 기본 podAntiAffinity 규칙을 설정합니다.

requiredDuringSchedulingIgnoredDuringExecution 필드에서 필요한 설정을 구성하여 Loki 구성 요소의 기본 podAntiAffinity 설정을 덮어쓸 수 있습니다.

ingester 구성 요소에 대한 사용자 설정 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    ingester:
      podAntiAffinity:
      # ...
        requiredDuringSchedulingIgnoredDuringExecution: 1
        - labelSelector:
            matchLabels: 2
              app.kubernetes.io/component: ingester
          topologyKey: kubernetes.io/hostname
# ...

1: 필수 규칙을 정의하는 스탠자입니다.
2: 규칙을 적용하려면 일치해야 하는 키-값 쌍(레이블)입니다.

2.5.8.4. 클러스터를 다시 시작하는 동안 LokiStack 동작

OpenShift Container Platform 클러스터가 다시 시작되면 LokiStack 수집 및 쿼리 경로가 노드에 사용 가능한 사용 가능한 CPU 및 메모리 리소스 내에서 계속 작동합니다. 즉, OpenShift Container Platform 클러스터 업데이트 중에 LokiStack에 대한 다운 타임이 없습니다. 이 동작은 PodDisruptionBudget 리소스를 사용하여 수행됩니다. Loki Operator는 특정 조건에서 정상적인 작업을 보장하기 위해 구성 요소별로 사용 가능한 최소 Pod 수를 결정하는 Loki의 PodDisruptionBudget 리소스를 프로비저닝합니다.

2.5.8.5. 고급 배포 및 확장성

고가용성, 확장성 및 오류 처리를 위한 특수 구성입니다.

2.5.8.6. 영역 인식 데이터 복제

Loki Operator는 Pod 토폴로지 분배 제약 조건을 통해 영역 인식 데이터 복제를 지원합니다. 이 기능을 사용하면 단일 영역 장애가 발생할 경우 로그 손실에 대한 안정성과 보호 장치가 향상됩니다. 배포 크기를 1x.extra- windows ,1x. ngressController 또는 1x.medium 으로 구성하는 경우 replication.factor 필드가 자동으로 2로 설정됩니다.

적절한 복제를 위해서는 복제 요인에서 지정한 만큼 이상의 가용성 영역이 있어야 합니다. 복제 요인보다 가용성 영역을 더 많이 보유할 수는 있지만 영역이 줄어들면 오류를 작성할 수 있습니다. 각 영역은 최적의 작업을 위해 동일한 수의 인스턴스를 호스팅해야 합니다.

영역 복제가 활성화된 LokiStack CR의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
 name: logging-loki
 namespace: openshift-logging
spec:
 replicationFactor: 2 1
 replication:
   factor: 2 2
   zones:
   -  maxSkew: 1 3
      topologyKey: topology.kubernetes.io/zone 4

1: 더 이상 사용되지 않는 필드로 입력된 값은 replication.factor 로 덮어씁니다.
2: 이 값은 배포 크기가 설정 시 선택되면 자동으로 설정됩니다.
3: 두 토폴로지 도메인 간 최대 Pod 수 차이입니다. 기본값은 1이며 값 0을 지정할 수 없습니다.
4: 노드 레이블에 해당하는 토폴로지 키 형태로 영역을 정의합니다.

2.5.8.7. 실패한 영역에서 Loki Pod 복구

OpenShift Container Platform에서 특정 가용성 영역 리소스에 액세스할 수 없게 되면 영역 오류가 발생합니다. 가용성 영역은 클라우드 공급자의 데이터 센터 내의 격리된 영역이며 중복성과 내결함성을 강화하기 위한 것입니다. OpenShift Container Platform 클러스터가 이를 처리하도록 구성되지 않은 경우 영역 실패로 인해 서비스 또는 데이터가 손실될 수 있습니다.

Loki 포드는 StatefulSet 의 일부이며 StorageClass 오브젝트에서 프로비저닝한 PVC(영구 볼륨 클레임)와 함께 제공됩니다. 각 Loki Pod 및 해당 PVC는 동일한 영역에 있습니다. 클러스터에서 영역 오류가 발생하면 StatefulSet 컨트롤러에서 실패한 영역에서 영향을 받는 Pod를 자동으로 복구하려고 합니다.

주의

다음 절차에서는 실패한 영역의 PVC와 그 안에 포함된 모든 데이터를 삭제합니다. 완전한 데이터 손실을 방지하려면 LokiStack CR의 복제 요소 필드를 항상 1보다 큰 값으로 설정하여 Loki가 복제되도록 해야 합니다.

사전 요구 사항

LokiStack CR에 1보다 큰 복제 인수가 있는지 확인합니다.
컨트롤 플레인에서 감지한 영역 장애와 실패한 영역의 노드는 클라우드 공급자 통합으로 표시됩니다.

StatefulSet 컨트롤러는 실패한 영역에서 Pod 일정 변경을 자동으로 시도합니다. 연결된 PVC도 실패한 영역에 있기 때문에 다른 영역으로 자동 일정 조정이 작동하지 않습니다. 새 영역에서 상태 저장 Loki Pod와 프로비저닝된 PVC를 다시 생성할 수 있도록 실패한 영역에서 PVC를 수동으로 삭제해야 합니다.

프로세스

다음 명령을 실행하여 Pending 상태의 Pod를 나열합니다.

$ oc get pods --field-selector status.phase==Pending -n openshift-logging

oc get pods 출력 예

NAME                           READY   STATUS    RESTARTS   AGE 1
logging-loki-index-gateway-1   0/1     Pending   0          17m
logging-loki-ingester-1        0/1     Pending   0          16m
logging-loki-ruler-1           0/1     Pending   0          16m

1: 해당 PVC가 실패한 영역에 있기 때문에 이러한 Pod는 Pending 상태입니다.

다음 명령을 실행하여 Pending 상태의 PVC를 나열합니다.

$ oc get pvc -o=json -n openshift-logging | jq '.items[] | select(.status.phase == "Pending") | .metadata.name' -r

oc get pvc 출력 예

storage-logging-loki-index-gateway-1
storage-logging-loki-ingester-1
wal-logging-loki-ingester-1
storage-logging-loki-ruler-1
wal-logging-loki-ruler-1

다음 명령을 실행하여 Pod의 PVC를 삭제합니다.
```
$ oc delete pvc <pvc_name>  -n openshift-logging
```
다음 명령을 실행하여 Pod를 삭제합니다.
```
$ oc delete pod <pod_name>  -n openshift-logging
```
이러한 오브젝트가 성공적으로 삭제되면 사용 가능한 영역에서 자동으로 다시 예약해야 합니다.

2.5.8.7.1. 종료 상태의 PVC 문제 해결

PVC 메타데이터 종료자가 kubernetes.io/pv-protection 으로 설정된 경우 PVC는 삭제 없이 종료 상태로 중단될 수 있습니다. 종료자를 제거하면 PVC가 성공적으로 삭제될 수 있습니다.

아래 명령을 실행하여 각 PVC의 종료자를 제거한 다음 삭제를 다시 시도합니다.
```
$ oc patch pvc <pvc_name> -p '{"metadata":{"finalizers":null}}' -n openshift-logging
```

2.5.8.8. 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에서 ingestionBurstSize 및 ingestionRate 필드를 업데이트합니다.
```
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)에 대한 소프트 제한입니다. 로그 비율이 제한을 초과하는 경우 속도 제한 오류가 발생하지만 수집기는 로그를 다시 시도합니다. 총 평균이 제한보다 작으면 사용자 개입 없이 시스템을 복구하고 오류가 해결됩니다.

2.6. 로깅 시각화

로깅을 위한 시각화는 Operator 설치가 필요한 Cluster Observability Operator 의 로깅 UI 플러그인 을 배포하여 제공됩니다.

중요

Red Hat은 현재 기술 프리뷰 (TP)에 있는 Cluster Observability Operator (COO)의 GA(General Availability) 릴리스까지 OpenShift Container Platform 4.14 이상에서 Logging UI 플러그인에 대해 Logging 6.0 이상을 사용하는 고객에게 지원을 제공합니다. COO에는 여전히 TP 기능이지만 로깅 UI 플러그인은 GA에 사용할 준비가 된 몇 가지 독립적인 기능이 포함되어 있기 때문에 이러한 지원 예외는 일시적입니다.

3장. 로깅 6.1

3.1. 로깅 6.1

3.1.1. 로깅 6.1.0 릴리스 노트

이 릴리스에는 Red Hat OpenShift 버그 수정 릴리스 6.1.0용 로깅 이 포함되어 있습니다.

3.1.1.1. 새로운 기능 및 기능 개선

3.1.1.1.1. 로그 컬렉션

이번 개선된 기능에는 수집된 컨테이너 로그에서 전송된 속성에 소스 iostream 이 추가되었습니다. 값은 수집기에서 수신한 방법에 따라 stdout 또는 stderr 로 설정됩니다. (LOG-5292)
이번 업데이트를 통해 수집기의 기본 메모리 제한이 1024 Mi에서 2048 Mi로 증가합니다. 사용자는 클러스터의 특정 요구 및 사양에 따라 리소스 제한을 조정해야 합니다. (LOG-6072)
이번 업데이트를 통해 이제 ClusterLogForwarder CR의 syslog 출력 전달 모드를 AtLeastOnce 또는 At CryostatOnce로 설정할 수 있습니다. (LOG-6355)

3.1.1.1.2. 로그 스토리지

이번 업데이트를 통해 새로운 1x.pico LokiStack 크기는 워크로드 수와 낮은 로그 볼륨(최대 50GB/일)이 있는 클러스터를 지원합니다. (LOG-5939)

3.1.1.2. 기술 프리뷰

중요

OTLP(OpenTelemetry Protocol) 출력 로그 전달자는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

이번 업데이트를 통해 OTel (OpenTelemetry) 데이터 모델을 사용하여 Red Hat Managed LokiStack 인스턴스로 OpenTelemetry 로그를 전달할 수 있습니다. 이 기능을 활성화하려면 observability.openshift.io/tech-preview-otlp-output: "enabled" 주석을 ClusterLogForwarder 구성에 추가합니다. 추가 구성 정보는 OTLP 전달을 참조하십시오.
이번 업데이트를 통해 lokiStack 출력 사양에 dataModel 필드가 추가되었습니다. OpenTelemetry 데이터 형식을 사용하여 로그 전달을 구성하려면 dataModel 을 Otel 으로 설정합니다. 기본값은 Viaq 로 설정됩니다. 데이터 매핑에 대한 자세한 내용은 OTLP 사양 을 참조하십시오.

3.1.1.3. 버그 수정

없음.

3.1.1.4. CVE

3.2. 로깅 6.1

context: logging-6x-6.1

ClusterLogForwarder CR(사용자 정의 리소스)은 로그 수집 및 전달의 중앙 구성 지점입니다.

3.2.1. 입력 및 출력

입력은 전달할 로그 소스를 지정합니다. 로깅은 클러스터의 다른 부분에서 로그를 선택하는 애플리케이션,수신자,인프라 및 감사 와 같은 기본 입력 유형을 제공합니다. 네임스페이스 또는 Pod 레이블을 기반으로 사용자 정의 입력을 정의하여 로그 선택을 미세 조정할 수도 있습니다.

출력은 로그가 전송되는 대상을 정의합니다. 각 출력 유형에는 고유한 구성 옵션 세트가 있어 동작 및 인증 설정을 사용자 지정할 수 있습니다.

3.2.2. 수신자 입력 유형

ReceiverSpec 은 수신자 입력에 대한 구성을 정의합니다.

3.2.3. 파이프라인 및 필터

3.2.4. Operator 동작

Cluster Logging Operator는 ClusterLogForwarder 리소스의 managementState 필드를 기반으로 수집기의 배포 및 구성을 관리합니다.

Managed (기본값)로 설정하면 Operator에서 사양에 정의된 구성과 일치하도록 로깅 리소스를 적극적으로 관리합니다.
Unmanaged 로 설정하면 Operator에서 작업을 수행하지 않으므로 로깅 구성 요소를 수동으로 관리할 수 있습니다.

3.2.5. 검증

3.2.6. 퀵 스타트

OpenShift Logging은 다음 두 가지 데이터 모델을 지원합니다.

viaq (일반 가용성)
OpenTelemetry (기술 프리뷰)

ClusterLogForwarder 에서 lokiStack.dataModel 필드를 구성하여 요구 사항에 따라 이러한 데이터 모델 중 하나를 선택할 수 있습니다. viaq는 LokiStack으로 로그를 전달할 때 기본 데이터 모델입니다.

참고

향후 OpenShift Logging 릴리스에서는 기본 데이터 모델이 ViaQ에서 OpenTelemetry로 변경됩니다.

3.2.6.1. ViaQ로 퀵 스타트

기본 ViaQ 데이터 모델을 사용하려면 다음 단계를 따르십시오.

사전 요구 사항

클러스터 관리자 권한

프로세스

OperatorHub에서 Red Hat OpenShift Logging Operator, Loki Operator 및 Cluster Observability Operator(COO)를 설치합니다.

openshift-logging 네임스페이스에서 LokiStack CR(사용자 정의 리소스)을 생성합니다.

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  managementState: Managed
  size: 1x.extra-small
  storage:
    schemas:
    - effectiveDate: '2024-10-01'
      version: v13
    secret:
      name: logging-loki-s3
      type: s3
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging

참고

logging-loki-s3 시크릿이 사전에 생성되었는지 확인합니다. 이 보안의 내용은 사용 중인 오브젝트 스토리지에 따라 다릅니다. 자세한 내용은 시크릿 및 TLS 구성을 참조하십시오.

수집기의 서비스 계정을 생성합니다.
```
$ oc create sa collector -n openshift-logging
```
수집기의 서비스 계정에서 LokiStack CR에 데이터를 쓸 수 있도록 허용합니다.
```
$ oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z collector
```
참고
ClusterRole 리소스는 Cluster Logging Operator 설치 중에 자동으로 생성되며 수동으로 생성할 필요가 없습니다.
수집기의 서비스 계정에서 로그를 수집할 수 있도록 허용합니다.
```
$ oc project openshift-logging
```
```
$ oc adm policy add-cluster-role-to-user collect-application-logs -z collector
```
```
$ oc adm policy add-cluster-role-to-user collect-audit-logs -z collector
```
```
$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z collector
```
참고
이 예제에서는 수집기를 세 가지 역할(애플리케이션, 인프라 및 감사) 모두에 바인딩하지만 기본적으로 애플리케이션 및 인프라 로그만 수집됩니다. 감사 로그를 수집하려면 이를 포함하도록 ClusterLogForwarder 구성을 업데이트합니다. 환경에 필요한 특정 로그 유형에 따라 역할을 할당합니다.

UIPlugin CR을 생성하여 모니터링 탭의 Log 섹션을 활성화합니다.

apiVersion: observability.openshift.io/v1alpha1
kind: UIPlugin
metadata:
  name: logging
spec:
  type: Logging
  logging:
    lokiStack:
      name: logging-loki

ClusterLogForwarder CR을 생성하여 로그 전달을 구성합니다.

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  namespace: openshift-logging
spec:
  serviceAccount:
    name: collector
  outputs:
  - name: default-lokistack
    type: lokiStack
    lokiStack:
      authentication:
        token:
          from: serviceAccount
      target:
        name: logging-loki
        namespace: openshift-logging
    tls:
      ca:
        key: service-ca.crt
        configMapName: openshift-service-ca.crt
  pipelines:
  - name: default-logstore
    inputRefs:
    - application
    - infrastructure
    outputRefs:
    - default-lokistack

참고

dataModel 필드는 선택 사항이며 설정되지 않은(dataModel: "") 기본적으로 유지됩니다. 이를 통해 Cluster Logging Operator(CLO)가 데이터 모델을 자동으로 선택할 수 있습니다. 현재 CLO는 필드가 설정되지 않은 경우 기본적으로 ViaQ 모델로 설정되지만 향후 릴리스에서는 변경될 예정입니다. dataModel: ViaQ 를 지정하면 기본 변경 사항이 있는 경우 구성이 계속 호환됩니다.

검증

OpenShift 웹 콘솔의 Observe 탭의 Log 섹션에 로그가 표시되는지 확인합니다.

3.2.6.2. OpenTelemetry로 퀵 스타트

중요

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

OTLP ingestion을 구성하고 OpenTelemetry 데이터 모델을 활성화하려면 다음 단계를 따르십시오.

사전 요구 사항

클러스터 관리자 권한

프로세스

OperatorHub에서 Red Hat OpenShift Logging Operator, Loki Operator 및 Cluster Observability Operator(COO)를 설치합니다.

openshift-logging 네임스페이스에서 LokiStack CR(사용자 정의 리소스)을 생성합니다.

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  managementState: Managed
  size: 1x.extra-small
  storage:
    schemas:
    - effectiveDate: '2024-10-01'
      version: v13
    secret:
      name: logging-loki-s3
      type: s3
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging

참고

logging-loki-s3 시크릿이 사전에 생성되었는지 확인합니다. 이 보안의 내용은 사용 중인 오브젝트 스토리지에 따라 다릅니다. 자세한 내용은 "시크릿 및 TLS 구성"을 참조하십시오.

수집기의 서비스 계정을 생성합니다.
```
$ oc create sa collector -n openshift-logging
```
수집기의 서비스 계정에서 LokiStack CR에 데이터를 쓸 수 있도록 허용합니다.
```
$ oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z collector
```
참고
ClusterRole 리소스는 Cluster Logging Operator 설치 중에 자동으로 생성되며 수동으로 생성할 필요가 없습니다.
수집기의 서비스 계정에서 로그를 수집할 수 있도록 허용합니다.
```
$ oc project openshift-logging
```
```
$ oc adm policy add-cluster-role-to-user collect-application-logs -z collector
```
```
$ oc adm policy add-cluster-role-to-user collect-audit-logs -z collector
```
```
$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z collector
```
참고
이 예제에서는 수집기를 세 가지 역할(애플리케이션, 인프라 및 감사) 모두에 바인딩합니다. 기본적으로 애플리케이션 및 인프라 로그만 수집됩니다. 감사 로그를 수집하려면 이를 포함하도록 ClusterLogForwarder 구성을 업데이트합니다. 환경에 필요한 특정 로그 유형에 따라 역할을 할당합니다.

UIPlugin CR을 생성하여 모니터링 탭의 Log 섹션을 활성화합니다.

apiVersion: observability.openshift.io/v1alpha1
kind: UIPlugin
metadata:
  name: logging
spec:
  type: Logging
  logging:
    lokiStack:
      name: logging-loki

ClusterLogForwarder CR을 생성하여 로그 전달을 구성합니다.

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  namespace: openshift-logging
  annotations:
    observability.openshift.io/tech-preview-otlp-output: "enabled" 1
spec:
  serviceAccount:
    name: collector
  outputs:
  - name: loki-otlp
    type: lokiStack 2
    lokiStack:
      target:
        name: logging-loki
        namespace: openshift-logging
      dataModel: Otel 3
      authentication:
        token:
          from: serviceAccount
    tls:
      ca:
        key: service-ca.crt
        configMapName: openshift-service-ca.crt
  pipelines:
  - name: my-pipeline
    inputRefs:
    - application
    - infrastructure
    outputRefs:
    - loki-otlp

1: 주석을 사용하여 기술 프리뷰 기능인 Otel 데이터 모델을 활성화합니다.
2: 출력 유형을 lokiStack 으로 정의합니다.
3: OpenTelemetry 데이터 모델을 지정합니다.

참고

dataModel 이 Otel 인 경우 lokiStack.labelKeys 를 사용할 수 없습니다. dataModel 이 Otel 일 때 유사한 기능을 얻으려면 "OTLP 데이터 수집용 LokiStack 구성"을 참조하십시오.

검증

OpenShift 웹 콘솔에서 Observe → OpenShift Logging → LokiStack → Writes 로 이동하여 Cryostat - structured Metadata 가 올바르게 작동하는지 확인합니다.

3.3. 로그 전달 구성

ClusterLogForwarder의 주요 기능

입력을 사용하여 로그 메시지 선택
출력을 사용하여 외부 대상으로 로그를 전달
필터를 사용하여 로그 메시지를 필터링, 변환 및 삭제
입력, 필터 및 출력을 연결하는 로그 전달 파이프라인을 정의합니다.

3.3.1. 로그 컬렉션 설정

필요한 클러스터 역할을 서비스 계정에 바인딩하여 로그 컬렉션을 설정합니다.

3.3.1.1. 레거시 서비스 계정

기존 서비스 계정 logcollector 를 사용하려면 다음 ClusterRoleBinding 을 생성합니다.

$ oc adm policy add-cluster-role-to-user collect-application-logs system:serviceaccount:openshift-logging:logcollector
$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs system:serviceaccount:openshift-logging:logcollector

또한 감사 로그를 수집하는 경우 다음 ClusterRoleBinding 을 생성합니다.

$ oc adm policy add-cluster-role-to-user collect-audit-logs system:serviceaccount:openshift-logging:logcollector

3.3.1.2. 서비스 계정 생성

사전 요구 사항

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>

3.3.1.2.1. 서비스 계정의 클러스터 역할 바인딩

role_binding.yaml 파일은 ClusterLogging Operator의 ClusterRole을 특정 ServiceAccount에 바인딩하여 클러스터 전체에서 Kubernetes 리소스를 관리할 수 있습니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: manager-rolebinding
roleRef:                                           1
  apiGroup: rbac.authorization.k8s.io              2
  kind: ClusterRole                                3
  name: cluster-logging-operator                   4
subjects:                                          5
  - kind: ServiceAccount                           6
    name: cluster-logging-operator                 7
    namespace: openshift-logging                   8

1: roleRef: 바인딩이 적용되는 ClusterRole을 참조합니다.
2: apiGroup: RBAC API 그룹을 나타내며 ClusterRole이 Kubernetes RBAC 시스템의 일부임을 지정합니다.
3: kind: 참조된 역할이 클러스터 전체에서 적용되는 ClusterRole임을 지정합니다.
4: name: ServiceAccount에 바인딩되는 ClusterRole의 이름입니다. 여기서 cluster-logging-operator.
5: 제목: ClusterRole에서 권한을 부여하는 엔터티(사용자 또는 서비스 계정)를 정의합니다.
6: kind: subject가 ServiceAccount임을 지정합니다.
7: name: 권한이 부여된 ServiceAccount의 이름입니다.
8: namespace: ServiceAccount가 있는 네임스페이스를 나타냅니다.

3.3.1.2.2. 애플리케이션 로그 작성

write-application-logs-clusterrole.yaml 파일은 Loki 로깅 애플리케이션에 애플리케이션 로그를 작성할 수 있는 권한을 부여하는 ClusterRole을 정의합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-application-logs
rules:                                              1
  - apiGroups:                                      2
      - loki.grafana.com                            3
    resources:                                      4
      - application                                 5
    resourceNames:                                  6
      - logs                                        7
    verbs:                                          8
      - create                                      9
Annotations
<1> rules: Specifies the permissions granted by this ClusterRole.
<2> apiGroups: Refers to the API group loki.grafana.com, which relates to the Loki logging system.
<3> loki.grafana.com: The API group for managing Loki-related resources.
<4> resources: The resource type that the ClusterRole grants permission to interact with.
<5> application: Refers to the application resources within the Loki logging system.
<6> resourceNames: Specifies the names of resources that this role can manage.
<7> logs: Refers to the log resources that can be created.
<8> verbs: The actions allowed on the resources.
<9> create: Grants permission to create new logs in the Loki system.

3.3.1.2.3. 감사 로그 작성

write-audit-logs-clusterrole.yaml 파일은 Loki 로깅 시스템에서 감사 로그를 생성할 수 있는 권한을 부여하는 ClusterRole을 정의합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-audit-logs
rules:                                              1
  - apiGroups:                                      2
      - loki.grafana.com                            3
    resources:                                      4
      - audit                                       5
    resourceNames:                                  6
      - logs                                        7
    verbs:                                          8
      - create                                      9

1 1: rules: 이 ClusterRole에서 부여하는 권한을 정의합니다.
2 2: apiGroups: loki.grafana.com API 그룹을 지정합니다.
3 3: Loki.grafana.com: Loki 로깅 리소스를 담당하는 API 그룹입니다.
4 4: resources: 이 역할이 관리하는 리소스 유형을 나타냅니다(이 경우 audit).
5 5: audit: 역할이 Loki 내에서 감사 로그를 관리하도록 지정합니다.
6 6: resourceNames: 역할이 액세스할 수 있는 특정 리소스를 정의합니다.
7 7: logs: 이 역할에서 관리할 수 있는 로그를 참조합니다.
8 8: 동사: 리소스에서 허용되는 작업입니다.
9 9: create: 새 감사 로그를 생성할 수 있는 권한을 부여합니다.

3.3.1.2.4. 인프라 로그 작성

write-infrastructure-logs-clusterrole.yaml 파일은 Loki 로깅 시스템에서 인프라 로그를 생성할 수 있는 권한을 부여하는 ClusterRole을 정의합니다.

샘플 YAML

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-infrastructure-logs
rules:                                              1
  - apiGroups:                                      2
      - loki.grafana.com                            3
    resources:                                      4
      - infrastructure                              5
    resourceNames:                                  6
      - logs                                        7
    verbs:                                          8
      - create                                      9

1: rules: 이 ClusterRole에서 부여하는 권한을 지정합니다.
2: apiGroups: Loki 관련 리소스의 API 그룹을 지정합니다.
3: Loki.grafana.com: Loki 로깅 시스템을 관리하는 API 그룹입니다.
4: resources: 이 역할이 상호 작용할 수 있는 리소스 유형을 정의합니다.
5: 인프라: 이 역할이 관리하는 인프라 관련 리소스를 나타냅니다.
6: resourceNames: 이 역할이 관리할 수 있는 리소스의 이름을 지정합니다.
7: 로그: 인프라와 관련된 로그 리소스를 참조합니다.
8: 동사: 이 역할에서 허용하는 작업입니다.
9: 생성: Loki 시스템에서 인프라 로그를 생성할 수 있는 권한을 부여합니다.

3.3.1.2.5. ClusterLogForwarder 편집기 역할

clusterlogforwarder-editor-role.yaml 파일은 사용자가 OpenShift에서 ClusterLogForwarder를 관리할 수 있는 ClusterRole을 정의합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: clusterlogforwarder-editor-role
rules:                                              1
  - apiGroups:                                      2
      - observability.openshift.io                  3
    resources:                                      4
      - clusterlogforwarders                        5
    verbs:                                          6
      - create                                      7
      - delete                                      8
      - get                                         9
      - list                                        10
      - patch                                       11
      - update                                      12
      - watch                                       13

1: rules: 이 ClusterRole에서 부여하는 권한을 지정합니다.
2: apiGroups: OpenShift 관련 API 그룹을 참조합니다.
3: obervability.openshift.io: 로깅과 같은 관찰 기능 리소스를 관리하는 API 그룹입니다.
4: resources: 이 역할이 관리할 수 있는 리소스를 지정합니다.
5: clusterlogforwarders: OpenShift의 로그 전달 리소스를 참조합니다.
6: verbs: ClusterLogForwarders에 허용되는 작업을 지정합니다.
7: 생성: 새 ClusterLogForwarder를 생성할 수 있는 권한을 부여합니다.
8: delete: 기존 ClusterLogForwarder를 삭제할 수 있는 권한을 부여합니다.
9: get: 특정 ClusterLogForwarder에 대한 정보를 검색할 수 있는 권한을 부여합니다.
10: list: 모든 ClusterLogForwarder를 나열할 수 있습니다.
11: patch: ClusterLogForwarder를 부분적으로 수정할 수 있는 권한을 부여합니다.
12: update: 기존 ClusterLogForwarder를 업데이트할 수 있는 권한을 부여합니다.
13: watch: ClusterLogForwarder의 변경 사항을 모니터링할 수 있는 권한을 부여합니다.

3.3.2. 수집기에서 로그 수준 수정

로그 수준 주석의 예

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  annotations:
    observability.openshift.io/log-level: debug
# ...

3.3.3. Operator 관리

ClusterLogForwarder 리소스에는 Operator가 리소스를 적극적으로 관리하는지 또는 Unmanaged 상태로 둘지 여부를 제어하는 managementState 필드가 있습니다.

관리됨: (기본값) Operator는 CLF 사양의 원하는 상태와 일치하도록 로깅 리소스를 구동합니다.
Unmanaged: Operator는 로깅 구성 요소와 관련된 작업을 수행하지 않습니다.

이를 통해 관리자는 managementState 를 Unmanaged 로 설정하여 로그 전달을 일시적으로 일시 중지할 수 있습니다.

3.3.4. ClusterLogForwarder의 구조

CLF에는 다음과 같은 주요 구성 요소가 포함된 spec 섹션이 있습니다.

입력: 전달할 로그 메시지를 선택합니다. 기본 입력 유형 애플리케이션,인프라 및 감사 는 클러스터의 다른 부분에서 로그를 전달합니다. 사용자 지정 입력을 정의할 수도 있습니다.
출력: 로그를 전달할 대상을 정의합니다. 각 출력에는 고유한 이름과 유형별 구성이 있습니다.
파이프라인: 입력에서 필터를 통해 출력으로 가져오는 경로 로그를 정의합니다. 파이프라인에는 고유한 이름이 있으며 입력, 출력 및 필터 이름 목록으로 구성됩니다.
필터: 파이프라인에서 로그 메시지를 변환하거나 삭제합니다. 사용자는 특정 로그 필드와 일치하는 필터를 정의하고 메시지를 삭제하거나 수정할 수 있습니다. 필터는 파이프라인에 지정된 순서로 적용됩니다.

3.3.4.1. 입력

입력은 spec.inputs 의 배열에 구성됩니다. 세 가지 기본 제공 입력 유형이 있습니다.

애플리케이션: 기본, openshift 또는 kube- 또는 openshift - 접두사가 있는 네임스페이스를 제외하고 모든 애플리케이션 컨테이너에서 로그를 선택합니다.
인프라: 기본 및 openshift 네임스페이스 및 노드 로그에서 실행되는 인프라 구성 요소에서 로그를 선택합니다.
audit: auditd에서 OpenShift API 서버 감사 로그, Kubernetes API 서버 감사 로그, ovn 감사 로그 및 노드 감사 로그에서 로그를 선택합니다.

사용자는 특정 네임스페이스에서 로그를 선택하거나 Pod 레이블을 사용하는 유형 애플리케이션 의 사용자 정의 입력을 정의할 수 있습니다.

3.3.4.2. 출력

출력은 spec.outputs 아래의 배열에 구성됩니다. 각 출력에는 고유한 이름과 유형이 있어야 합니다. 지원되는 유형은 다음과 같습니다.

azureMonitor: Azure Monitor로 로그를 전달합니다.
CloudMonitor: AWS CloudMonitor로 로그를 전달합니다.
elasticsearch: 로그를 외부 Elasticsearch 인스턴스로 전달합니다.
googleCloudLogging: Google Cloud Logging으로 로그를 전달합니다.
HTTP: 일반 HTTP 끝점으로 로그를 전달합니다.
kafka: Kafka 브로커로 로그를 전달합니다.
loki: 로그를 Loki 로깅 백엔드로 전달합니다.
lokistack: OpenShift Container Platform 인증 통합을 사용하여 Loki 및 웹 프록시의 로깅 지원 조합으로 로그를 전달합니다. LokiStack의 프록시는 OpenShift Container Platform 인증을 사용하여 멀티 테넌시 적용
otlp: OpenTelemetry 프로토콜을 사용하여 로그를 전달합니다.
splunk: Splunk로 로그를 전달합니다.
syslog: 로그를 외부 syslog 서버로 전달합니다.

각 출력 유형에는 고유한 구성 필드가 있습니다.

3.3.5. OTLP 출력 구성

클러스터 관리자는 OTLP(OpenTelemetry Protocol) 출력을 사용하여 로그를 수집하고 OTLP 수신자에 전달할 수 있습니다. OTLP 출력은 OpenTelemetry Observability 프레임워크에서 정의한 사양을 사용하여 JSON 인코딩으로 HTTP를 통해 데이터를 보냅니다.

중요

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

프로세스

다음 주석을 추가하여 OTLP를 사용하여 전달을 활성화하도록 ClusterLogForwarder CR(사용자 정의 리소스)을 생성하거나 편집합니다.

ClusterLogForwarder CR의 예

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  annotations:
    observability.openshift.io/tech-preview-otlp-output: "enabled" 1
  name: clf-otlp
spec:
  serviceAccount:
    name: <service_account_name>
  outputs:
  - name: otlp
    type: otlp
    otlp:
      tuning:
        compression: gzip
        deliveryMode: AtLeastOnce
        maxRetryDuration: 20
        maxWrite: 10M
        minRetryDuration: 5
      url: <otlp_url> 2
  pipelines:
  - inputRefs:
    - application
    - infrastructure
    - audit
    name: otlp-logs
    outputRefs:
    - otlp

1: 이 주석을 사용하여 기술 프리뷰 기능인OTLP(OpenTelemetry Protocol) 출력을 활성화합니다.
2: 이 URL은 절대적이어야 하며 로그가 전송되는 OTLP 끝점의 자리 표시자입니다.

참고

OTLP 출력에서는 다른 출력 유형에서 사용하는 ViaQ 데이터 모델과 다른 OpenTelemetry 데이터 모델을 사용합니다. OpenTelemetry Observability 프레임워크에서 정의한 OpenTelemetry Semantic ations를 사용하여 OTLP를 준수합니다.

3.3.5.1. 파이프라인

파이프라인은 spec.pipelines 의 배열에 구성됩니다. 각 파이프라인에는 고유한 이름이 있어야 하며 다음으로 구성됩니다.

inputRefs: 로그가 이 파이프라인으로 전달되어야 하는 입력의 이름입니다.
outputRefs: 로그를 전송할 출력의 이름입니다.
filterRefs: (선택 사항) 적용할 필터 이름입니다.

filterRefs 순서가 순차적으로 적용되므로 중요합니다. 이전 필터는 이후 필터에서 처리되지 않는 메시지를 삭제할 수 있습니다.

3.3.5.2. 필터

필터는 spec.filters 아래의 배열에 구성됩니다. 구조화된 필드의 값을 기반으로 들어오는 로그 메시지를 일치시키고 수정하거나 삭제할 수 있습니다.

관리자는 다음 유형의 필터를 구성할 수 있습니다.

3.3.5.3. 여러 줄 예외 탐지 활성화

컨테이너 로그의 여러 줄 오류 감지를 활성화합니다.

주의

이 기능을 활성화하면 성능에 영향을 미칠 수 있으며 추가 컴퓨팅 리소스 또는 대체 로깅 솔루션이 필요할 수 있습니다.

Java 예외 예

java.lang.NullPointerException: Cannot invoke "String.toString()" because "<param1>" is null
    at testjava.Main.handle(Main.java:47)
    at testjava.Main.printMe(Main.java:19)
    at testjava.Main.main(Main.java:10)

로깅을 사용하여 여러 줄 예외를 감지하고 이를 단일 로그 항목으로 재조정하려면 ClusterLogForwarder 사용자 정의 리소스(CR)에 .spec.filters 아래의 detectMultilineErrors 필드가 포함되어 있는지 확인합니다.

Example ClusterLogForwarder CR

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
  namespace: <log_forwarder_namespace>
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <name>
    type: detectMultilineException
  pipelines:
    - inputRefs:
        - <input-name>
      name: <pipeline-name>
      filterRefs:
        - <filter-name>
      outputRefs:
        - <output-name>

3.3.5.3.1. 세부 정보

수집기는 다음 언어를 지원합니다.

Java
JS
Ruby
Python
Golang
PHP
Dart

3.3.5.4. 원하지 않는 로그 레코드를 삭제하도록 콘텐츠 필터 구성

프로세스

ClusterLogForwarder CR의 필터 사양에 필터 구성을 추가합니다.
다음 예제에서는 정규식을 기반으로 로그 레코드를 삭제하도록 ClusterLogForwarder CR을 구성하는 방법을 보여줍니다.
ClusterLogForwarder CR의 예
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <filter_name>
    type: drop 1
    drop: 2
    - test: 3
      - field: .kubernetes.labels."foo-bar/baz" 4
        matches: .+ 5
      - field: .kubernetes.pod_name
        notMatches: "my-pod" 6
  pipelines:
  - name: <pipeline_name> 7
    filterRefs: ["<filter_name>"]
# ...
```
1
필터 유형을 지정합니다. drop 필터는 필터 구성과 일치하는 로그 레코드를 삭제합니다.
2
드롭 필터를 적용하기 위한 구성 옵션을 지정합니다.
3
로그 레코드 삭제 여부를 평가하는 데 사용되는 테스트에 대한 구성을 지정합니다.
테스트에 지정된 모든 조건이 true이면 테스트가 통과되고 로그 레코드가 삭제됩니다.
drop 필터 구성에 대해 여러 테스트가 지정되면 테스트가 통과하면 레코드가 삭제됩니다.
예를 들어 평가 중인 로그 레코드에서 필드가 누락되면 해당 조건이 false로 평가됩니다.
4
로그 레코드의 필드 경로인 점으로 구분된 필드 경로를 지정합니다. 경로에는 alpha-numeric 문자 및 밑줄(a-zA-Z0-9_)을 포함할 수 있습니다(예: .kubernetes.namespace_name ). 세그먼트에 이 범위를 벗어나는 문자가 포함된 경우 세그먼트는 따옴표로 묶어야 합니다(예: .kubernetes.labels."foo.bar-bar/baz". 단일 테스트 구성에 여러 필드 경로를 포함할 수 있지만 테스트가 통과하고 drop 필터를 적용하려면 모두 true로 평가되어야 합니다.
5
정규식을 지정합니다. 로그 레코드가 이 정규식과 일치하는 경우 해당 레코드가 삭제됩니다. 단일 필드 경로에 대해 matches 또는 notMatches 조건을 설정할 수 있지만 둘 다 설정할 수는 없습니다.
6
정규식을 지정합니다. 로그 레코드가 이 정규식과 일치하지 않으면 삭제됩니다. 단일 필드 경로에 대해 matches 또는 notMatches 조건을 설정할 수 있지만 둘 다 설정할 수는 없습니다.
7
drop 필터가 적용되는 파이프라인을 지정합니다.
다음 명령을 실행하여 ClusterLogForwarder CR을 적용합니다.
```
$ oc apply -f <filename>.yaml
```

추가 예

다음 추가 예제에서는 우선 순위가 높은 로그 레코드만 유지하도록 drop 필터를 구성하는 방법을 보여줍니다.

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: important
    type: drop
    drop:
    - test:
      - field: .message
        notMatches: "(?i)critical|error"
      - field: .level
        matches: "info|warning"
# ...

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: important
    type: drop
    drop:
    - test:
      - field: .kubernetes.namespace_name
        matches: "^open"
    - test:
      - field: .log_type
        matches: "application"
      - field: .kubernetes.pod_name
        notMatches: "my-pod"
# ...

3.3.5.5. API 감사 필터 개요

없음: 이벤트가 삭제되었습니다.
metadata: 감사 메타데이터가 포함되어 요청 및 응답 본문이 제거됩니다.
요청: 감사 메타데이터와 요청 본문이 포함되어 응답 본문이 제거됩니다.
RequestResponse: 메타데이터, 요청 본문, 응답 본문 등 모든 데이터가 포함됩니다. 응답 본문은 매우 커질 수 있습니다. 예를 들어 oc get pods -A 는 클러스터의 모든 포드에 대한 YAML 설명이 포함된 응답 본문을 생성합니다.

ClusterLogForwarder CR(사용자 정의 리소스)은 다음과 같은 추가 기능을 제공하는 동안 표준 Kubernetes 감사 정책과 동일한 형식을 사용합니다.

와일드카드

기본 규칙

정책의 규칙과 일치하지 않는 이벤트는 다음과 같이 필터링됩니다.

get,list 및 watch 와 같은 읽기 전용 시스템 이벤트가 삭제됩니다.
서비스 계정은 서비스 계정과 동일한 네임스페이스 내에서 발생하는 이벤트를 기록합니다.
기타 모든 이벤트는 구성된 속도 제한에 따라 전달됩니다.

이러한 기본값을 비활성화하려면 수준 필드만 있는 규칙으로 규칙 목록을 종료하거나 빈 규칙을 추가합니다.

응답 코드 생략: 생략할 정수 상태 코드 목록입니다. 이벤트가 생성되지 않은 HTTP 상태 코드를 나열하는 OmitResponseCodes 필드를 사용하여 응답에서 HTTP 상태 코드를 기반으로 이벤트를 삭제할 수 있습니다. 기본값은 [404, 409, 422, 429] 입니다. 값이 빈 목록 [] 인 경우 상태 코드는 생략되지 않습니다.

참고

감사 정책의 예

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
  namespace: <log_forwarder_namespace>
spec:
  serviceAccount:
    name: <service_account_name>
  pipelines:
    - name: my-pipeline
      inputRefs: audit 1
      filterRefs: my-policy 2
  filters:
    - name: my-policy
      type: kubeAPIAudit
      kubeAPIAudit:
        # Don't generate audit events for all requests in RequestReceived stage.
        omitStages:
          - "RequestReceived"

        rules:
          # Log pod changes at RequestResponse level
          - level: RequestResponse
            resources:
            - group: ""
              resources: ["pods"]

          # Log "pods/log", "pods/status" at Metadata level
          - level: Metadata
            resources:
            - group: ""
              resources: ["pods/log", "pods/status"]

          # Don't log requests to a configmap called "controller-leader"
          - level: None
            resources:
            - group: ""
              resources: ["configmaps"]
              resourceNames: ["controller-leader"]

          # Don't log watch requests by the "system:kube-proxy" on endpoints or services
          - level: None
            users: ["system:kube-proxy"]
            verbs: ["watch"]
            resources:
            - group: "" # core API group
              resources: ["endpoints", "services"]

          # Don't log authenticated requests to certain non-resource URL paths.
          - level: None
            userGroups: ["system:authenticated"]
            nonResourceURLs:
            - "/api*" # Wildcard matching.
            - "/version"

          # Log the request body of configmap changes in kube-system.
          - level: Request
            resources:
            - group: "" # core API group
              resources: ["configmaps"]
            # This rule only applies to resources in the "kube-system" namespace.
            # The empty string "" can be used to select non-namespaced resources.
            namespaces: ["kube-system"]

          # Log configmap and secret changes in all other namespaces at the Metadata level.
          - level: Metadata
            resources:
            - group: "" # core API group
              resources: ["secrets", "configmaps"]

          # Log all other resources in core and extensions at the Request level.
          - level: Request
            resources:
            - group: "" # core API group
            - group: "extensions" # Version of group should NOT be included.

          # A catch-all rule to log all other requests at the Metadata level.
          - level: Metadata

1: 수집되는 로그 유형입니다. 이 필드의 값은 감사 로그, 애플리케이션 로그의 애플리케이션, 인프라 로그용 인프라 또는 애플리케이션에 대해 정의된 이름이 지정된 입력에 대한 감사일 수 있습니다.
2: 감사 정책의 이름입니다.

3.3.5.6. 레이블 표현식 또는 일치하는 라벨 키와 값을 포함하여 입력 시 애플리케이션 로그 필터링

입력 선택기를 사용하여 라벨 표현식 또는 일치하는 라벨 키와 해당 값을 기반으로 애플리케이션 로그를 포함할 수 있습니다.

프로세스

ClusterLogForwarder CR의 입력 사양에 필터 구성을 추가합니다.
다음 예제에서는 라벨 표현식 또는 일치하는 라벨 키/값에 따라 로그를 포함하도록 ClusterLogForwarder CR을 구성하는 방법을 보여줍니다.
ClusterLogForwarder CR의 예
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs
      application:
        selector:
          matchExpressions:
          - key: env 1
            operator: In 2
            values: ["prod", "qa"] 3
          - key: zone
            operator: NotIn
            values: ["east", "west"]
          matchLabels: 4
            app: one
            name: app1
      type: application
# ...
```
1
일치시킬 레이블 키를 지정합니다.
2
Operator를 지정합니다. 유효한 값에는 in,NotIn,Exists 및 DoesNotExist 가 있습니다.
3
문자열 값의 배열을 지정합니다. operator 값이 Exists 또는 DoesNotExist 이면 값 배열이 비어 있어야 합니다.
4
정확한 키 또는 값 매핑을 지정합니다.
다음 명령을 실행하여 ClusterLogForwarder CR을 적용합니다.
```
$ oc apply -f <filename>.yaml
```

3.3.5.7. 로그 레코드를 정리하도록 콘텐츠 필터 구성

프로세스

ClusterLogForwarder CR의 prune 사양에 필터 구성을 추가합니다.
다음 예제에서는 필드 경로를 기반으로 로그 레코드를 정리하도록 ClusterLogForwarder CR을 구성하는 방법을 보여줍니다.
중요
둘 다 지정된 경우 먼저 notIn 배열에 따라 레코드가 정리되며, 이 경우 in 배열보다 우선합니다. notIn 배열을 사용하여 레코드를 정리하면 in 배열을 사용하여 정리됩니다.
ClusterLogForwarder CR의 예
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <filter_name>
    type: prune 1
    prune: 2
      in: [.kubernetes.annotations, .kubernetes.namespace_id] 3
      notIn: [.kubernetes,.log_type,.message,."@timestamp"] 4
  pipelines:
  - name: <pipeline_name> 5
    filterRefs: ["<filter_name>"]
# ...
```
1
필터 유형을 지정합니다. prune 필터는 구성된 필드를 통해 로그 레코드를 정리합니다.
2
prune 필터를 적용하기 위한 구성 옵션을 지정합니다. in 및 notIn 필드는 로그 레코드의 필드 경로의 경로인 점으로 구분된 필드 경로의 배열로 지정됩니다. 이러한 경로에는 alpha-numeric 문자 및 밑줄(a-zA-Z0-9_)을 포함할 수 있습니다(예: .kubernetes.namespace_name ). 세그먼트에 이 범위를 벗어나는 문자가 포함된 경우 세그먼트는 따옴표로 묶어야 합니다(예: .kubernetes.labels."foo.bar-bar/baz".
3
선택 사항: 이 배열에 지정된 모든 필드는 로그 레코드에서 제거됩니다.
4
선택 사항: 이 배열에 지정되지 않은 모든 필드는 로그 레코드에서 제거됩니다.
5
prune 필터가 적용되는 파이프라인을 지정합니다.
참고
필터는 log_type,.log_source, .message 필드를 제외합니다.
다음 명령을 실행하여 ClusterLogForwarder CR을 적용합니다.
```
$ oc apply -f <filename>.yaml
```

3.3.6. 소스로 감사 및 인프라 로그 입력 필터링

입력 선택기를 사용하여 로그를 수집할 감사 및 인프라 소스 목록을 정의할 수 있습니다.

프로세스

ClusterLogForwarder CR에서 감사 및 인프라 소스를 정의하는 구성을 추가합니다.
다음 예제에서는 감사 및 인프라 소스를 정의하도록 ClusterLogForwarder CR을 구성하는 방법을 보여줍니다.
ClusterLogForwarder CR의 예
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs1
      type: infrastructure
      infrastructure:
        sources: 1
          - node
    - name: mylogs2
      type: audit
      audit:
        sources: 2
          - kubeAPI
          - openshiftAPI
          - ovn
# ...
```
1
수집할 인프라 소스 목록을 지정합니다. 유효한 소스는 다음과 같습니다.
Node: 노드에서 저널 로그
컨테이너: 네임스페이스에 배포된 워크로드의 로그
2
수집할 감사 소스 목록을 지정합니다. 유효한 소스는 다음과 같습니다.
kubeAPI: Kubernetes API 서버의 로그
openshiftAPI: OpenShift API 서버의 로그
auditd: 노드 auditd 서비스의 로그
OVN: 오픈 가상 네트워크 서비스의 로그
다음 명령을 실행하여 ClusterLogForwarder CR을 적용합니다.
```
$ oc apply -f <filename>.yaml
```

3.3.7. 네임스페이스 또는 컨테이너 이름을 포함하거나 제외하여 입력 시 애플리케이션 로그 필터링

입력 선택기를 사용하여 네임스페이스 및 컨테이너 이름을 기반으로 애플리케이션 로그를 포함하거나 제외할 수 있습니다.

프로세스

ClusterLogForwarder CR에 네임스페이스 및 컨테이너 이름을 포함하거나 제외하는 구성을 추가합니다.
다음 예제에서는 네임스페이스 및 컨테이너 이름을 포함하거나 제외하도록 ClusterLogForwarder CR을 구성하는 방법을 보여줍니다.
ClusterLogForwarder CR의 예
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs
      application:
        includes:
          - namespace: "my-project" 1
            container: "my-container" 2
        excludes:
          - container: "other-container*" 3
            namespace: "other-namespace" 4
      type: application
# ...
```
1
이러한 네임스페이스에서만 로그를 수집하도록 지정합니다.
2
이러한 컨테이너에서만 로그를 수집하도록 지정합니다.
3
로그를 수집할 때 무시할 네임스페이스 패턴을 지정합니다.
4
로그를 수집할 때 무시할 컨테이너 세트를 지정합니다.
참고
excludes 필드는 includes 필드보다 우선합니다.
다음 명령을 실행하여 ClusterLogForwarder CR을 적용합니다.
```
$ oc apply -f <filename>.yaml
```

3.4. LokiStack을 사용하여 로그 저장

애플리케이션, 감사 및 인프라 관련 로그를 저장하도록 LokiStack CR을 구성할 수 있습니다.

중요

3.4.1. Loki 배포 크기 조정

Loki의 크기 조정은 1x.<size> 형식을 따릅니다. 여기서 1x 값은 인스턴스 수이고 < size >는 성능 기능을 지정합니다.

디스크 요청은 크기 구성에서 유사합니다. 고객이 다양한 크기를 테스트하여 배포 요구 사항에 가장 적합한지 확인할 수 있습니다.

중요

배포 크기에 대해 숫자 1x 를 변경할 수 없습니다.

표 3.1. Loki 크기 조정
	1x.demo	1x.pico [6.1+ only]	1x.extra-windows	1x.small	1x.medium
데이터 전송	데모만 사용	50GB/일	100GB/일	500GB/일	2TB/일
초당 쿼리(QPS)	데모만 사용	200ms에서 1-25 QPS	200ms에서 1-25 QPS	25-50 QPS (200ms)	25-75 QPS (200ms)
복제 요인	없음	2	2	2	2
총 CPU 요청	없음	7개의 vCPU	14개의 vCPU	34 vCPU	54 vCPU
ruler을 사용하는 경우 총 CPU 요청	없음	8개의 vCPU	16개의 vCPU	42 vCPU	70개의 vCPU
총 메모리 요청	없음	17GI	31Gi	67Gi	139Gi
룰러를 사용하는 경우 총 메모리 요청	없음	18GI	35Gi	83Gi	171Gi
총 디스크 요청	40Gi	590Gi	430Gi	430Gi	590Gi
ruler을 사용하는 경우 총 디스크 요청	80Gi	910Gi	750Gi	750Gi	910Gi

3.4.2. 사전 요구 사항

CLI 또는 웹 콘솔을 사용하여 Loki Operator를 설치했습니다.
ClusterLogForwarder 를 생성하는 동일한 네임스페이스에 serviceAccount 가 있습니다.
serviceAccount 에는 collect-audit-logs,collect-application-logs, collect-infrastructure-logs 클러스터 역할이 할당됩니다.

3.4.3. 코어 설정 및 구성

Loki를 배포하기 위한 역할 기반 액세스 제어, 기본 모니터링 및 Pod 배치입니다.

3.4.4. LokiStack 규칙 RBAC 권한 승인

경고 및 레코딩 규칙에 대한 다음 클러스터 역할은 LokiStack에 사용할 수 있습니다.

규칙 이름	설명
`alertingrules.loki.grafana.com-v1-admin`	이 역할의 사용자에게는 경고 규칙을 관리할 수 있는 관리 수준 액세스 권한이 있습니다. 이 클러스터 역할은 `loki.grafana.com/v1` API 그룹 내에서 `AlertingRule` 리소스를 생성, 읽기, 업데이트, 삭제, 나열 및 조사할 수 있는 권한을 부여합니다.
`alertingrules.loki.grafana.com-v1-crdview`	이 역할의 사용자는 `loki.grafana.com/v1` API 그룹 내의 `AlertingRule` 리소스와 관련된 CRD(Custom Resource Definitions)의 정의를 볼 수 있지만 이러한 리소스를 수정하거나 관리할 수 있는 권한은 없습니다.
`alertingrules.loki.grafana.com-v1-edit`	이 역할의 사용자는 `AlertingRule` 리소스를 생성, 업데이트 및 삭제할 수 있는 권한이 있습니다.
`alertingrules.loki.grafana.com-v1-view`	이 역할의 사용자는 `loki.grafana.com/v1` API 그룹 내에서 `AlertingRule` 리소스를 읽을 수 있습니다. 기존 경고 규칙에 대한 구성, 라벨 및 주석을 검사할 수 있지만 수정할 수는 없습니다.
`recordingrules.loki.grafana.com-v1-admin`	이 역할의 사용자는 레코딩 규칙을 관리할 수 있는 관리 수준의 액세스 권한이 있습니다. 이 클러스터 역할은 `loki.grafana.com/v1` API 그룹 내의 `RecordingRule` 리소스를 생성, 읽기, 업데이트, 삭제, 나열 및 감시할 수 있는 권한을 부여합니다.
`recordingrules.loki.grafana.com-v1-crdview`	이 역할의 사용자는 `loki.grafana.com/v1` API 그룹 내의 `RecordingRule` 리소스와 관련된 CRD(Custom Resource Definitions)의 정의를 볼 수 있지만 이러한 리소스를 수정하거나 관리할 수 있는 권한은 없습니다.
`recordingrules.loki.grafana.com-v1-edit`	이 역할의 사용자는 `RecordingRule` 리소스를 생성, 업데이트 및 삭제할 수 있는 권한이 있습니다.
`recordingrules.loki.grafana.com-v1-view`	이 역할의 사용자는 `loki.grafana.com/v1` API 그룹 내에서 `RecordingRule` 리소스를 읽을 수 있습니다. 기존 경고 규칙에 대한 구성, 라벨 및 주석을 검사할 수 있지만 수정할 수는 없습니다.

3.4.4.1. 예

사용자의 클러스터 역할을 적용하려면 기존 클러스터 역할을 특정 사용자 이름에 바인딩해야 합니다.

다음 예제 명령은 클러스터의 특정 네임스페이스의 경고 규칙에 대해 지정된 사용자 생성, 읽기, 업데이트 및 삭제(CRUD) 권한을 제공합니다.

특정 네임스페이스에서 경고 규칙 CRUD 권한에 대한 클러스터 역할 바인딩 명령의 예

$ oc adm policy add-role-to-user alertingrules.loki.grafana.com-v1-admin -n <namespace> <username>

다음 명령은 모든 네임스페이스의 경고 규칙에 대해 지정된 사용자 관리자 권한을 부여합니다.

관리자 권한에 대한 클러스터 역할 바인딩 명령의 예

$ oc adm policy add-cluster-role-to-user alertingrules.loki.grafana.com-v1-admin <username>

3.4.5. Loki를 사용하여 로그 기반 경고 규칙 생성

AlertingRule CR에 잘못된 간격 기간이 포함된 경우 잘못된 경고 규칙입니다.
AlertingRule CR 에 기간 동안 유효하지 않은 항목이 포함된 경우 잘못된 경고 규칙입니다.
AlertingRule CR에 잘못된 LogQL expr 가 포함된 경우 잘못된 경고 규칙입니다.
AlertingRule CR에 동일한 이름의 두 개의 그룹이 포함된 경우 잘못된 경고 규칙입니다.
위의 어느 것도 적용되지 않으면 경고 규칙이 유효한 것으로 간주됩니다.

표 3.2. AlertingRule 정의
테넌트 유형	`AlertingRule` CR을 위한 유효한 네임스페이스
애플리케이션	`<your_application_namespace>`
audit	`openshift-logging`
인프라	`openshift-/`, `kube-/\`, `default`

프로세스

AlertingRule 사용자 정의 리소스(CR)를 생성합니다.

인프라 AlertingRule CR의 예

  apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: loki-operator-alerts
    namespace: openshift-operators-redhat 1
    labels: 2
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "infrastructure" 3
    groups:
      - name: LokiOperatorHighReconciliationError
        rules:
          - alert: HighPercentageError
            expr: | 4
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"} |= "error" [1m])) by (job)
                /
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"}[1m])) by (job)
                > 0.01
            for: 10s
            labels:
              severity: critical 5
            annotations:
              summary: High Loki Operator Reconciliation Errors 6
              description: High Loki Operator Reconciliation Errors 7

1: 이 AlertingRule CR이 생성되는 네임스페이스에는 LokiStack spec.rules.namespaceSelector 정의와 일치하는 레이블이 있어야 합니다.
2: labels 블록은 LokiStack spec.rules.selector 정의와 일치해야 합니다.
3: 인프라 테넌트에 대한 AlertingRule CR은 openshift-*, kube-\* 또는 default 네임스페이스에서만 지원됩니다.
4: kubernetes_namespace_name: 의 값은 metadata.namespace 값과 일치해야 합니다.
5: 이 필수 필드의 값은 중요,경고 또는 정보 여야 합니다.
6: 이 필드는 필수입니다.
7: 이 필드는 필수입니다.

애플리케이션 AlertingRule CR의 예

  apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: app-user-workload
    namespace: app-ns 1
    labels: 2
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "application"
    groups:
      - name: AppUserWorkloadHighError
        rules:
          - alert:
            expr: | 3
              sum(rate({kubernetes_namespace_name="app-ns", kubernetes_pod_name=~"podName.*"} |= "error" [1m])) by (job)
            for: 10s
            labels:
              severity: critical 4
            annotations:
              summary:  5
              description:  6

1: 이 AlertingRule CR이 생성되는 네임스페이스에는 LokiStack spec.rules.namespaceSelector 정의와 일치하는 레이블이 있어야 합니다.
2: labels 블록은 LokiStack spec.rules.selector 정의와 일치해야 합니다.
3: kubernetes_namespace_name: 의 값은 metadata.namespace 값과 일치해야 합니다.
4: 이 필수 필드의 값은 중요,경고 또는 정보 여야 합니다.
5: 이 필수 필드의 값은 규칙에 대한 요약입니다.
6: 이 필수 필드의 값은 규칙에 대한 자세한 설명입니다.

AlertingRule CR을 적용합니다.
```
$ oc apply -f <filename>.yaml
```

3.4.6. 멤버 목록 생성 실패를 허용하도록 Loki 구성

$ oc patch LokiStack logging-loki -n openshift-logging  --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP"},"type":"memberlist"}}}'

podIP를 포함하는 LokiStack의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  hashRing:
    type: memberlist
    memberlist:
      instanceAddrType: podIP
# ...

3.4.7. Loki를 사용하여 스트림 기반 보존 활성화

중요

s3 버킷 또는 LokiStack 사용자 정의 리소스(CR)에 정의된 보존 기간이 없으면 로그가 정리되지 않고 s3 스토리지를 채울 수 있습니다.

참고

스키마 v13이 권장됩니다.

프로세스

LokiStack CR을 생성합니다.

다음 예와 같이 스트림 기반 보존을 전역적으로 활성화합니다.

AWS에 대한 글로벌 스트림 기반 보존의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
   global: 1
      retention: 2
        days: 20
        streams:
        - days: 4
          priority: 1
          selector: '{kubernetes_namespace_name=~"test.+"}' 3
        - days: 1
          priority: 1
          selector: '{log_type="infrastructure"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v13
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging

1: 모든 로그 스트림에 대한 보존 정책을 설정합니다. 참고: 이 필드는 오브젝트 스토리지에 저장된 로그의 보존 기간에는 영향을 미치지 않습니다.
2: 이 블록이 CR에 추가되면 클러스터에서 보존이 활성화됩니다.
3: 로그 스트림.spec: 제한을 정의하는 데 사용되는 LogQL 쿼리 를 포함합니다.

다음 예와 같이 테넌트별로 스트림 기반 보존을 활성화합니다.

AWS에 대한 테넌트별 스트림 기반 보존 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      retention:
        days: 20
    tenants: 1
      application:
        retention:
          days: 1
          streams:
            - days: 4
              selector: '{kubernetes_namespace_name=~"test.+"}' 2
      infrastructure:
        retention:
          days: 5
          streams:
            - days: 1
              selector: '{kubernetes_namespace_name=~"openshift-cluster.+"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v13
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging

1: 테넌트별 보존 정책을 설정합니다. 유효한 테넌트 유형은 애플리케이션,감사 및 인프라 입니다.
2: 로그 스트림을 정의하는 데 사용되는 LogQL 쿼리 를 포함합니다.

LokiStack CR을 적용합니다.
```
$ oc apply -f <filename>.yaml
```

3.4.8. Loki Pod 배치

Pod의 허용 오차 또는 노드 선택기를 사용하여 Loki Pod가 실행되는 노드를 제어하고 다른 워크로드가 해당 노드를 사용하지 못하도록 할 수 있습니다.

노드 선택기가 있는 LokiStack의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor: 1
      nodeSelector:
        node-role.kubernetes.io/infra: "" 2
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
# ...

1: 노드 선택기에 적용되는 구성 요소 Pod 유형을 지정합니다.
2: 정의된 라벨이 포함된 노드로 이동되는 Pod를 지정합니다.

노드 선택기 및 허용 오차가 있는 LokiStack CR의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
# ...

LokiStack(CR)의 nodeSelector 및 허용 오차 필드를 구성하려면 oc explain 명령을 사용하여 특정 리소스에 대한 설명 및 필드를 볼 수 있습니다.

$ oc explain lokistack.spec.template

출력 예

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: template <Object>

DESCRIPTION:
     Template defines the resource/limits/tolerations/nodeselectors per
     component

FIELDS:
   compactor	<Object>
     Compactor defines the compaction component spec.

   distributor	<Object>
     Distributor defines the distributor component spec.
...

자세한 내용은 특정 필드를 추가할 수 있습니다.

$ oc explain lokistack.spec.template.compactor

출력 예

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: compactor <Object>

DESCRIPTION:
     Compactor defines the compaction component spec.

FIELDS:
   nodeSelector	<map[string]string>
     NodeSelector defines the labels required by a node to schedule the
     component onto it.
...

3.4.8.1. 향상된 신뢰성 및 성능

프로덕션 환경에서 Loki의 안정성 및 효율성을 보장하는 구성입니다.

3.4.8.2. 수명이 짧은 토큰을 사용하여 클라우드 기반 로그 저장소에 대한 인증 활성화

워크로드 ID 페더레이션을 통해 단기 토큰을 사용하여 클라우드 기반 로그 저장소에 인증할 수 있습니다.

프로세스

다음 옵션 중 하나를 사용하여 인증을 활성화합니다.

OpenShift Container Platform 웹 콘솔을 사용하여 Loki Operator를 설치하면 수명이 짧은 토큰을 사용하는 클러스터가 자동으로 감지됩니다. 역할을 생성하고 Loki Operator에서 보안을 채우는 CredentialsRequest 오브젝트를 생성하는 데 필요한 데이터를 제공하라는 메시지가 표시됩니다.

Azure 샘플 서브스크립션의 예

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-6.0"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
      - name: CLIENTID
        value: <your_client_id>
      - name: TENANTID
        value: <your_tenant_id>
      - name: SUBSCRIPTIONID
        value: <your_subscription_id>
      - name: REGION
        value: <your_region>

AWS 샘플 서브스크립션 예

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-6.0"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: ROLEARN
      value: <role_ARN>

3.4.8.3. 노드 장애를 허용하도록 Loki 구성

Loki Operator는 Pod 유사성 방지 규칙을 설정하여 동일한 구성 요소의 Pod가 클러스터의 다른 사용 가능한 노드에 예약되도록 요청할 수 있습니다.

유사성은 예약할 노드를 제어하는 Pod의 속성입니다. 유사성 방지는 Pod가 노드에서 예약되지 않도록 하는 Pod의 속성입니다.

OpenShift Container Platform에서 Pod 유사성 및 Pod 유사성 방지를 사용하면 다른 Pod의 키 값 라벨에 따라 Pod를 예약할 수 있는 노드를 제한할 수 있습니다.

requiredDuringSchedulingIgnoredDuringExecution 필드에서 필요한 설정을 구성하여 Loki 구성 요소의 기본 podAntiAffinity 설정을 덮어쓸 수 있습니다.

ingester 구성 요소에 대한 사용자 설정 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    ingester:
      podAntiAffinity:
      # ...
        requiredDuringSchedulingIgnoredDuringExecution: 1
        - labelSelector:
            matchLabels: 2
              app.kubernetes.io/component: ingester
          topologyKey: kubernetes.io/hostname
# ...

1: 필수 규칙을 정의하는 스탠자입니다.
2: 규칙을 적용하려면 일치해야 하는 키-값 쌍(레이블)입니다.

3.4.8.4. 클러스터를 다시 시작하는 동안 LokiStack 동작

3.4.8.5. 고급 배포 및 확장성

고가용성, 확장성 및 오류 처리를 위한 특수 구성입니다.

3.4.8.6. 영역 인식 데이터 복제

영역 복제가 활성화된 LokiStack CR의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
 name: logging-loki
 namespace: openshift-logging
spec:
 replicationFactor: 2 1
 replication:
   factor: 2 2
   zones:
   -  maxSkew: 1 3
      topologyKey: topology.kubernetes.io/zone 4

1: 더 이상 사용되지 않는 필드로 입력된 값은 replication.factor 로 덮어씁니다.
2: 이 값은 배포 크기가 설정 시 선택되면 자동으로 설정됩니다.
3: 두 토폴로지 도메인 간 최대 Pod 수 차이입니다. 기본값은 1이며 값 0을 지정할 수 없습니다.
4: 노드 레이블에 해당하는 토폴로지 키 형태로 영역을 정의합니다.

3.4.8.7. 실패한 영역에서 Loki Pod 복구

주의

사전 요구 사항

LokiStack CR에 1보다 큰 복제 인수가 있는지 확인합니다.
컨트롤 플레인에서 감지한 영역 장애와 실패한 영역의 노드는 클라우드 공급자 통합으로 표시됩니다.

프로세스

다음 명령을 실행하여 Pending 상태의 Pod를 나열합니다.

$ oc get pods --field-selector status.phase==Pending -n openshift-logging

oc get pods 출력 예

NAME                           READY   STATUS    RESTARTS   AGE 1
logging-loki-index-gateway-1   0/1     Pending   0          17m
logging-loki-ingester-1        0/1     Pending   0          16m
logging-loki-ruler-1           0/1     Pending   0          16m

1: 해당 PVC가 실패한 영역에 있기 때문에 이러한 Pod는 Pending 상태입니다.

다음 명령을 실행하여 Pending 상태의 PVC를 나열합니다.

$ oc get pvc -o=json -n openshift-logging | jq '.items[] | select(.status.phase == "Pending") | .metadata.name' -r

oc get pvc 출력 예

storage-logging-loki-index-gateway-1
storage-logging-loki-ingester-1
wal-logging-loki-ingester-1
storage-logging-loki-ruler-1
wal-logging-loki-ruler-1

다음 명령을 실행하여 Pod의 PVC를 삭제합니다.
```
$ oc delete pvc <pvc_name>  -n openshift-logging
```
다음 명령을 실행하여 Pod를 삭제합니다.
```
$ oc delete pod <pod_name>  -n openshift-logging
```
이러한 오브젝트가 성공적으로 삭제되면 사용 가능한 영역에서 자동으로 다시 예약해야 합니다.

3.4.8.7.1. 종료 상태의 PVC 문제 해결

아래 명령을 실행하여 각 PVC의 종료자를 제거한 다음 삭제를 다시 시도합니다.
```
$ oc patch pvc <pvc_name> -p '{"metadata":{"finalizers":null}}' -n openshift-logging
```

3.4.8.8. 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에서 ingestionBurstSize 및 ingestionRate 필드를 업데이트합니다.
```
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.5. Loki의 OTLP 데이터 수집

로깅 6.1은 OTLP(OpenTelemetry Protocol)를 사용하여 API 엔드포인트를 활성화합니다. OTLP는 Loki를 위해 특별히 설계되지 않은 표준화된 형식이므로 OpenTelemetry의 데이터 형식을 Loki의 데이터 모델에 매핑하려면 Loki의 측에 대한 추가 구성이 필요합니다. OTLP에는 스트림 레이블 또는 구조화된 메타데이터 와 같은 개념이 없습니다. 대신 OTLP는 세 가지 범주로 그룹화된 속성으로 로그 항목에 대한 메타데이터를 제공합니다.

리소스
범위
log

이렇게 하면 필요에 따라 여러 항목에 대해 동시에 또는 개별적으로 메타데이터를 설정할 수 있습니다.

3.5.1. OTLP 데이터 수집용 LokiStack 구성

중요

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

OTLP 수집에 대한 LokiStack CR(사용자 정의 리소스)을 구성하려면 다음 단계를 따르십시오.

사전 요구 사항

Loki 설정이 스키마 버전 13에 도입된 구조화된 메타데이터를 지원하는지 확인하여 OTLP 로그 수집을 활성화합니다.

프로세스

스키마 버전을 설정합니다.
- 새 LokiStack CR을 생성할 때 스토리지 스키마 구성에서 version: v13 을 설정합니다.
  참고
  기존 구성의 경우 version: v13 과 effectiveDate 를 사용하여 새 스키마 항목을 추가합니다. 스키마 버전 업데이트에 대한 자세한 내용은 업그레이드 스키마 (Grafana 문서)를 참조하십시오.
다음과 같이 스토리지 스키마를 구성합니다.
스토리지 스키마 구성 예
```
# ...
spec:
  storage:
    schemas:
    - version: v13
      effectiveDate: 2024-10-25
```
effectiveDate 가 전달되면 v13 스키마가 적용되어 LokiStack 에서 구조화된 메타데이터를 저장할 수 있습니다.

3.5.2. 속성 매핑

Loki Operator가 openshift-logging 모드로 설정되면 기본 속성 매핑 세트가 자동으로 적용됩니다. 이러한 매핑은 특정 OTLP 속성을 Loki의 스트림 레이블 및 구조화된 메타데이터와 조정합니다.

일반적인 설정의 경우 이러한 기본 매핑만으로도 충분합니다. 그러나 다음과 같은 경우 속성 매핑을 사용자 지정해야 할 수 있습니다.

사용자 지정 수집기 사용: 설정에 추가 속성을 생성하는 사용자 지정 수집기가 포함된 경우 이러한 특성이 Loki에 유지되도록 매핑을 사용자 정의하는 것이 좋습니다.
특성 세부 정보 수준 조정: 기본 특성 세트가 필요 이상으로 자세히 설명하는 경우 필수 속성으로만 줄일 수 있습니다. 이로 인해 과도한 데이터 스토리지를 방지하고 로깅 프로세스를 간소화할 수 있습니다.

중요

스트림 레이블 또는 구조화된 메타데이터에 매핑되지 않은 속성은 Loki에 저장되지 않습니다.

3.5.2.1. OpenShift의 사용자 정의 속성 매핑

openshift-logging 모드에서 Loki Operator를 사용하는 경우 속성 매핑은 OpenShift 기본값을 따르지만 사용자 정의 매핑을 구성하여 조정할 수 있습니다. 사용자 지정 매핑을 사용하면 추가 구성이 특정 요구 사항을 충족할 수 있습니다.

openshift-logging 모드에서 사용자 정의 속성 매핑은 모든 테넌트 또는 필요에 따라 개별 테넌트에 대해 전역적으로 구성할 수 있습니다. 사용자 정의 매핑이 정의되면 OpenShift 기본값에 추가됩니다. 기본 권장 라벨이 필요하지 않은 경우 테넌트 구성에서 비활성화할 수 있습니다.

참고

Loki Operator와 Loki 자체의 주요 차이점은 상속 처리입니다. Loki는 default_resource_attributes_as_index_labels 만 기본적으로 테넌트에 복사하는 반면 Loki Operator는 openshift-logging 모드의 각 테넌트에 전체 글로벌 구성을 적용합니다.

LokiStack 내에서 속성 매핑 구성은 limits 설정을 통해 관리됩니다.

# ...
spec:
  limits:
    global:
      otlp: {} 1
    tenants:
      application:
        otlp: {} 2

1: 글로벌 OTLP 특성 구성.
2: openshift-logging 모드 내에서 애플리케이션 테넌트에 대한 OTLP 속성 구성입니다.

참고

글로벌 및 테넌트별 OTLP 구성 모두 속성을 스트림 레이블 또는 구조화된 메타데이터에 매핑할 수 있습니다. 로그 항목을 Loki 스토리지에 저장하려면 하나 이상의 스트림 레이블이 필요하므로 이 구성이 해당 요구 사항을 충족하는지 확인합니다.

스트림 레이블은 LokiStack 리소스 구조가 반영하는 리소스 수준 속성에서만 파생됩니다.

spec:
  limits:
    global:
      otlp:
        streamLabels:
          resourceAttributes:
          - name: "k8s.namespace.name"
          - name: "k8s.pod.name"
          - name: "k8s.container.name"

반대로 구조화된 메타데이터는 리소스, 범위 또는 로그 수준 특성에서 생성할 수 있습니다.

# ...
spec:
  limits:
    global:
      otlp:
        streamLabels:
          # ...
        structuredMetadata:
          resourceAttributes:
          - name: "process.command_line"
          - name: "k8s\\.pod\\.labels\\..+"
            regex: true
          scopeAttributes:
          - name: "service.name"
          logAttributes:
          - name: "http.route"

작은 정보

Loki에서 유사한 속성을 매핑할 때 속성 이름에 regex: true 를 설정하여 정규식을 사용합니다.

중요

데이터 볼륨이 증가할 수 있으므로 스트림 레이블에는 정규식을 사용하지 마십시오.

3.5.2.2. OpenShift 기본값 사용자 정의

openshift-logging 모드에서는 특정 속성이 필요하며 OpenShift 함수에서 역할로 인해 구성에서 제거할 수 없습니다. 성능에 영향을 주는 경우 레이블이 지정된 기타 속성이 비활성화될 수 있습니다.

사용자 정의 속성 없이 openshift-logging 모드를 사용하는 경우 OpenShift 툴과 즉시 호환성을 얻을 수 있습니다. 스트림 레이블 또는 구조화된 메타데이터로 추가 속성이 필요한 경우 사용자 지정 구성을 사용합니다. 사용자 지정 구성은 기본 구성과 병합할 수 있습니다.

3.5.2.3. 권장 속성 제거

openshift-logging 모드에서 기본 속성을 줄이려면 권장 속성을 비활성화합니다.

# ...
spec:
  tenants:
    mode: openshift-logging
    openshift:
      otlp:
        disableRecommendedAttributes: true 1

1: 기본 속성을 필수 속성으로 제한하는 권장 속성을 제거하려면 disableRecommendedAttributes: true 를 설정합니다.

참고

이 옵션은 기본 속성으로 인해 성능 또는 스토리지 문제가 발생하는 경우 유용합니다. 이 설정은 기본 스트림 레이블을 제거하므로 쿼리 성능에 부정적인 영향을 미칠 수 있습니다. 쿼리에 필수 속성을 유지하려면 이 옵션을 사용자 지정 특성 구성과 페어링해야 합니다.

3.5.3. 추가 리소스

3.6. OpenTelemetry 데이터 모델

이 문서에서는 로깅 6.1을 사용한 Red Hat OpenShift Logging의 OpenTelemetry 지원에 대한 프로토콜 및 의미 규칙에 대해 간단히 설명합니다.

중요

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

3.6.1. 전달 및 수집 프로토콜

Red Hat OpenShift Logging은 OTLP 사양 을 사용하여 OpenTelemetry 끝점으로 로그를 수집하고 전달합니다. OTLP 인코딩, 전송 및 Telemetry 데이터를 제공합니다. 로그 스트림을 수집하는 OTLP endpont을 제공하는 Loki 스토리지를 배포할 수도 있습니다. 이 문서에서는 다양한 OpenShift 클러스터 소스에서 수집된 로그에 대한 의미 규칙을 정의합니다.

3.6.2. 의미 체계 규칙

이 솔루션의 로그 수집기는 다음 로그 스트림을 수집합니다.

컨테이너 로그
클러스터 노드 저널 로그
클러스터 노드 auditd 로그
Kubernetes 및 OpenShift API 서버 로그
OpenShift Virtual Network(OVN) 로그

OpenTelemetry 의미 체계 특성에 의해 정의된 의미 규칙에 따라 이러한 스트림을 전달할 수 있습니다. OpenTelemetry의 의미 체계 규칙은 속성을 통해 식별되는 원격 분석을 생성하는 엔티티의 불변 표현으로 리소스를 정의합니다. 예를 들어 컨테이너에서 실행되는 프로세스에는 container_name,cluster_id,pod_name,namespace, deployment 또는 app_name 과 같은 특성이 포함됩니다. 이러한 속성은 리소스 오브젝트 아래에 그룹화되므로 반복을 줄이고 로그 전송을 원격 분석 데이터로 최적화할 수 있습니다.

리소스 속성 외에도 로그에는 각 로그 항목과 관련된 조정 라이브러리 및 로그 속성과 관련된 범위 속성이 포함될 수 있습니다. 이러한 속성은 각 로그 항목에 대해 자세히 설명하고 스토리지의 로그를 쿼리할 때 필터링 기능을 향상시킵니다.

다음 섹션에서는 일반적으로 전달되는 속성을 정의합니다.

3.6.2.1. 로그 항목 구조

모든 로그 스트림에는 다음 로그 데이터 필드가 포함됩니다.

적용 가능한 소스 열은 각 필드가 적용되는 로그 소스를 나타냅니다.

all: 이 필드는 모든 로그에 있습니다.
컨테이너: 이 필드는 애플리케이션 및 인프라 둘 다에 Kubernetes 컨테이너 로그에 있습니다.
audit: 이 필드는 Kubernetes, OpenShift API 및 OVN 로그에 있습니다.
auditd: 이 필드는 노드 auditd 로그에 있습니다.
저널: 이 필드는 노드 저널 로그에 있습니다.

이름	적용 가능한 소스	댓글
`body`	all
`observedTimeUnixNano`	all
`timeUnixNano`	all
`severityText`	컨테이너, 저널
`속성`	all	(선택 사항) 스트림 특정 특성을 전달할 때 우선순위

3.6.2.2. 속성

로그 항목에는 다음 표에 설명된 대로 소스 기반의 리소스, 범위 및 로그 속성 세트가 포함됩니다.

Location 열은 특성 유형을 지정합니다.

resource: resource 특성을 나타냅니다.
scope: scope 특성을 나타냅니다.
log: 로그 특성을 나타냅니다.

스토리지 열은 기본 openshift-logging 모드를 사용하여 특성이 LokiStack에 저장되는지 여부를 나타내며 특성이 저장된 위치를 지정합니다.

스트림 레이블:
- 특정 레이블을 기반으로 효율적으로 필터링 및 쿼리를 수행할 수 있습니다.
- Loki Operator가 구성에 이 속성을 적용하는 경우 필요에 따라 레이블을 지정할 수 있습니다.
구조화된 메타데이터:
- 키-값 쌍의 자세한 필터링 및 스토리지를 허용합니다.
- 사용자가 JSON 구문 분석 없이도 직접 라벨을 사용하여 간소화된 쿼리에 사용할 수 있습니다.

OTLP를 사용하면 사용자가 JSON 구문 분석을 사용하는 대신 레이블로 직접 쿼리를 필터링하여 쿼리의 속도와 효율성을 개선할 수 있습니다.

이름	위치	적용 가능한 소스	스토리지(LokiStack)	댓글
`log_source`	resource	all	필수 스트림 레이블	(DEPRECATED) 호환성 속성에 `openshift.log.source`와 동일한 정보가 포함되어 있습니다.
`log_type`	resource	all	필수 스트림 레이블	(DEPRECATED) 호환성 속성에 `openshift.log.type`과 동일한 정보가 포함되어 있습니다.
`kubernetes.container_name`	resource	container	스트림 레이블	(DEPRECATED) 호환성 속성에 `k8s.container.name`과 동일한 정보가 포함되어 있습니다.
`kubernetes.host`	resource	all	스트림 레이블	(DEPRECATED) 호환성 속성에 `k8s.node.name`과 동일한 정보가 포함되어 있습니다.
`kubernetes.namespace_name`	resource	container	필수 스트림 레이블	(DEPRECATED) 호환성 속성에 `k8s.namespace.name`과 동일한 정보가 포함되어 있습니다.
`kubernetes.pod_name`	resource	container	스트림 레이블	(DEPRECATED) 호환성 속성에 `k8s.pod.name`과 동일한 정보가 포함되어 있습니다.
`openshift.cluster_id`	resource	all		(DEPRECATED) 호환성 속성에 `openshift.cluster.uid`와 동일한 정보가 포함되어 있습니다.
`level`	log	컨테이너, 저널		(DEPRECATED) 호환성 속성에는 `심각도 Cryostat와 동일한 정보가 포함되어 있습니다.`
`openshift.cluster.uid`	resource	all	필수 스트림 레이블
`openshift.log.source`	resource	all	필수 스트림 레이블
`openshift.log.type`	resource	all	필수 스트림 레이블
`openshift.labels.*`	resource	all	구조화된 메타데이터
`k8s.node.name`	resource	all	스트림 레이블
`k8s.namespace.name`	resource	container	필수 스트림 레이블
`k8s.container.name`	resource	container	스트림 레이블
`k8s.pod.labels.*`	resource	container	구조화된 메타데이터
`k8s.pod.name`	resource	container	스트림 레이블
`k8s.pod.uid`	resource	container	구조화된 메타데이터
`k8s.cronjob.name`	resource	container	스트림 레이블	Pod 작성자를 기반으로 조건부 전달
`k8s.daemonset.name`	resource	container	스트림 레이블	Pod 작성자를 기반으로 조건부 전달
`k8s.deployment.name`	resource	container	스트림 레이블	Pod 작성자를 기반으로 조건부 전달
`k8s.job.name`	resource	container	스트림 레이블	Pod 작성자를 기반으로 조건부 전달
`k8s.replicaset.name`	resource	container	구조화된 메타데이터	Pod 작성자를 기반으로 조건부 전달
`k8s.statefulset.name`	resource	container	스트림 레이블	Pod 작성자를 기반으로 조건부 전달
`log.iostream`	log	container	구조화된 메타데이터
`k8s.audit.event.level`	log	audit	구조화된 메타데이터
`k8s.audit.event.stage`	log	audit	구조화된 메타데이터
`k8s.audit.event.user_agent`	log	audit	구조화된 메타데이터
`k8s.audit.event.request.uri`	log	audit	구조화된 메타데이터
`k8s.audit.event.response.code`	log	audit	구조화된 메타데이터
`k8s.audit.event.annotation.*`	log	audit	구조화된 메타데이터
`k8s.audit.event.object_ref.resource`	log	audit	구조화된 메타데이터
`k8s.audit.event.object_ref.name`	log	audit	구조화된 메타데이터
`k8s.audit.event.object_ref.namespace`	log	audit	구조화된 메타데이터
`k8s.audit.event.object_ref.api_group`	log	audit	구조화된 메타데이터
`k8s.audit.event.object_ref.api_version`	log	audit	구조화된 메타데이터
`k8s.user.username`	log	audit	구조화된 메타데이터
`k8s.user.groups`	log	audit	구조화된 메타데이터
`process.executable.name`	resource	journal	구조화된 메타데이터
`process.executable.path`	resource	journal	구조화된 메타데이터
`process.command_line`	resource	journal	구조화된 메타데이터
`process.pid`	resource	journal	구조화된 메타데이터
`service.name`	resource	journal	스트림 레이블
`systemd.t.*`	log	journal	구조화된 메타데이터
`systemd.u.*`	log	journal	구조화된 메타데이터

참고

호환성 특성으로 표시된 속성은 ViaQ 데이터 모델과의 이전 버전과 최소 호환성을 지원합니다. 이러한 속성은 더 이상 사용되지 않으며 지속적인 UI 기능을 보장하기 위해 호환성 계층으로 작동합니다. 이러한 속성은 Logging UI가 향후 릴리스에서 OpenTelemetry 카운터를 완전히 지원할 때까지 계속 지원됩니다.

Loki는 스토리지로 유지할 때 속성 이름을 변경합니다. 이름은 소문자로 표시되고 집합의 모든 문자(,/,-)는 밑줄(_)으로 대체됩니다. 예를 들어 k8s.namespace.name 은 k8s_namespace_name 이 됩니다.

3.6.3. 추가 리소스

3.7. 로깅 시각화

로깅을 위한 시각화는 Operator 설치가 필요한 Cluster Observability Operator 의 로깅 UI 플러그인 을 배포하여 제공됩니다.

중요

4장. 지원

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

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

참고

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

참고

중요

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

로깅은 다음과 같습니다.

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

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

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

표 4.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에서 지원

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

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

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

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

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

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

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

4.4. 로깅 UI 플러그인에 대한 지원 예외

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

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

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

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

참고

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

4.5.1. must-gather 툴 정보

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

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

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

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

4.5.2. 로깅 데이터 수집

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

프로세스

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

must-gather 정보를 저장하려는 디렉터리로 이동합니다.
로깅 이미지에 대해 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.
방금 생성한 must-gather 디렉터리에서 압축 파일을 만듭니다. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다.
```
$ tar -cvaf must-gather.tar.gz must-gather.local.4157245944708210408
```
Red Hat Customer Portal에서 해당 지원 사례에 압축 파일을 첨부합니다.

5장. 로깅 문제 해결

5.1. 로깅 상태 보기

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

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

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

사전 요구 사항

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

프로세스

다음 명령을 실행하여 openshift-logging 프로젝트로 변경합니다.
```
$ oc project openshift-logging
```

다음 명령을 실행하여 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에 대한 정보.

5.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:

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

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

사전 요구 사항

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

프로세스

openshift-logging 프로젝트로 변경합니다.
```
$ oc project openshift-logging
```

로깅 환경의 상태 보기:

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

로깅 복제본 세트의 상태를 확인합니다.

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

출력 예

$ 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

복제본 세트의 상태를 가져옵니다.

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

5.2. 로그 전달 문제 해결

5.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
```

5.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에서 ingestionBurstSize 및 ingestionRate 필드를 업데이트합니다.
```
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)에 대한 소프트 제한입니다. 로그 비율이 제한을 초과하는 경우 속도 제한 오류가 발생하지만 수집기는 로그를 다시 시도합니다. 총 평균이 제한보다 작으면 사용자 개입 없이 시스템을 복구하고 오류가 해결됩니다.

5.3. 로깅 경고 문제 해결

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

5.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 변수를 사용할 수 있습니다.

프로세스

Elasticsearch 클러스터 상태를 확인하고 다음 명령을 실행하여 클러스터 상태가 빨간색인지 확인합니다.
```
$ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- health
```

다음 명령을 실행하여 클러스터에 참여한 노드를 나열합니다.

$ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_cat/nodes?v

다음 명령을 실행하여 Elasticsearch Pod를 나열하고 이전 단계의 명령 출력의 노드와 비교합니다.
```
$ oc -n openshift-logging get pods -l component=elasticsearch
```
일부 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
```
모든 노드가 클러스터에 참여한 경우 다음 명령을 실행하고 출력을 관찰하여 클러스터가 복구 프로세스 중인지 확인합니다.
```
$ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_cat/recovery?active_only=true
```
명령 출력이 없는 경우 복구 프로세스가 보류 중인 작업에서 지연되거나 중단될 수 있습니다.

다음 명령을 실행하고 출력을 관찰하여 보류 중인 작업이 있는지 확인합니다.

$ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- health | grep number_of_pending_tasks

보류 중인 작업이 있는 경우 상태를 모니터링합니다. 상태가 변경되고 클러스터가 복구 중임을 나타내는 경우 계속 대기합니다. 복구 시간은 클러스터의 크기와 기타 요인에 따라 다릅니다. 그렇지 않으면 보류 중인 작업의 상태가 변경되지 않는 경우 복구가 중지되었음을 나타냅니다.
복구가 중단된 것처럼 보이면 다음 명령을 실행하고 출력을 관찰하여 cluster.routing.allocation.enable 값이 none 으로 설정되어 있는지 확인합니다.
```
$ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_cluster/settings?pretty
```

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

다음 명령을 실행하고 출력을 관찰하여 인덱스가 빨간색인지 확인합니다.

$ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_cat/indices?v

인덱스가 빨간색이면 다음 단계를 수행하여 지웁니다.

다음 명령을 실행하여 캐시를 지웁니다.

$ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=<elasticsearch_index_name>/_cache/clear?pretty

다음 명령을 실행하여 최대 할당 재시도 횟수를 늘립니다.

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

다음 명령을 실행하여 스크롤 항목을 모두 삭제합니다.

$ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_search/scroll/_all -X DELETE

다음 명령을 실행하여 시간 초과를 늘립니다.

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

이전 단계에서 빨간색 인덱스를 지우지 않으면 인덱스를 개별적으로 삭제합니다.
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
```
빨간색 인덱스가 없고 클러스터 상태가 빨간색이면 데이터 노드에서 지속적으로 처리 로드가 높은지 확인합니다.
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 "모듈 대시보드 검토" 설명서를 참조하십시오.

추가 리소스

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

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

추가 리소스

빨간색 또는 노란색 클러스터 상태 수정

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

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

작은 정보

다음 명령을 실행하여 사용 가능한 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 변수를 사용할 수 있습니다.

프로세스

다음 명령을 실행하여 Elasticsearch가 배포된 노드를 식별합니다.
```
$ oc -n openshift-logging get po -o wide
```

다음 명령을 실행하여 할당되지 않은 shard가 있는지 확인합니다.

$ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_cluster/health?pretty | grep unassigned_shards

할당되지 않은 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

명령 출력에서 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를 할당할 수 없습니다.

현재 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 값으로 설정하고 이 변경 사항을 저장합니다.
이전 단계에서 문제가 해결되지 않으면 이전 인덱스를 삭제합니다.
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
```

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

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

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

작은 정보

다음 명령을 실행하여 사용 가능한 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 변수를 사용할 수 있습니다.

프로세스

다음 명령을 실행하여 Elasticsearch가 배포된 노드를 식별합니다.
```
$ oc -n openshift-logging get po -o wide
```

각 노드의 디스크 공간을 확인합니다.

$ 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

클러스터가 재조정 중인지 확인합니다.
```
$ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_cluster/health?pretty | grep relocating_shards
```
명령 출력에 shard 재배치가 표시되면 높은 워터마크가 초과되었습니다. 높은 워터마크의 기본값은 90%입니다.
모든 노드의 디스크 공간을 늘립니다. 디스크 공간을 늘릴 수 없는 경우 클러스터에 새 데이터 노드를 추가하거나 총 클러스터 중복 정책을 줄입니다.
현재 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 값으로 설정하고 이 변경 사항을 저장합니다.
이전 단계에서 문제가 해결되지 않으면 이전 인덱스를 삭제합니다.
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
```

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

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

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

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

작은 정보

다음 명령을 실행하여 사용 가능한 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 변수를 사용할 수 있습니다.

프로세스

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

명령 출력에서 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

모든 노드의 디스크 공간을 늘립니다. 디스크 공간을 늘릴 수 없는 경우 클러스터에 새 데이터 노드를 추가하거나 총 클러스터 중복 정책을 줄입니다.
현재 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 값으로 설정하고 이 변경 사항을 저장합니다.
이전 단계에서 문제가 해결되지 않으면 이전 인덱스를 삭제합니다.
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
```
디스크 공간을 계속 확보하고 모니터링합니다. 사용된 디스크 공간이 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}'
```

5.3.6. Elasticsearch JVM 힙 사용량이 높음

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

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

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

5.3.8. Elasticsearch 프로세스 CPU가 높음

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

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

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

프로세스

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

명령 출력에서 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

모든 노드의 디스크 공간을 늘립니다. 디스크 공간을 늘릴 수 없는 경우 클러스터에 새 데이터 노드를 추가하거나 총 클러스터 중복 정책을 줄입니다.
현재 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 값으로 설정하고 이 변경 사항을 저장합니다.
이전 단계에서 문제가 해결되지 않으면 이전 인덱스를 삭제합니다.
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
```

추가 리소스

빨간색 또는 노란색 클러스터 상태 수정

5.3.10. Elasticsearch FileDescriptor 사용량이 높음

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

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

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

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

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

사전 요구 사항

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

프로세스

다음 명령을 실행하여 openshift-logging 프로젝트로 변경합니다.
```
$ oc project openshift-logging
```
상태를 보려면 다음을 수행합니다.
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

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

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

StorageClassNameChangeIgnored: 스토리지 클래스 이름에 대한 지원되지 않는 변경 사항입니다.
StorageSizeChangeIgnored: 스토리지 크기에 대한 지원되지 않는 변경 사항입니다.
StorageStructureChangeIgnored: 임시 스토리지 구조와 영구저장장치 구조 간에는 지원되지 않는 변경 사항입니다.
중요
임시 스토리지에서 영구 스토리지로 전환하도록 ClusterLogging CR을 구성하려고 하면 OpenShift Elasticsearch Operator는 PVC(영구 볼륨 클레임)를 생성하지만 PV(영구 볼륨)를 생성하지 않습니다. StorageStructureChangeIgnored 상태를 지우려면 ClusterLogging CR로 변경 사항을 취소하고 PVC를 삭제해야 합니다.

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

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

Elasticsearch 인덱스

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

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

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

$ 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의 상태를 볼 수 있습니다.

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

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 배포 구성

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

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

$ 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

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

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

로그 저장소 복제본 세트

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

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

$ 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

복제본 세트의 상태를 가져옵니다.

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

5.4.3. Elasticsearch 클러스터 상태

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

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

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

6장. 로깅 정보

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

참고

OpenShift Container Platform 4.16에서는 Elasticsearch Operator가 ServiceMesh, 추적 및 Kiali에만 지원됩니다. 이 Operator는 2025년 11월 OpenShift Operator 카탈로그에서 제거될 예정입니다. 제거 이유는 Elasticsearch Operator가 더 이상 로그 스토리지에 지원되지 않으며 Kibana는 OpenShift Container Platform 4.16 이상 버전에서 더 이상 지원되지 않기 때문입니다. 라이프사이클 날짜에 대한 자세한 내용은 Platform Agnostic Operators 를 참조하십시오.

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

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

참고

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

6.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 프로젝트의 로그입니다.

추가 리소스

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

6.2. 로깅 배포 정보

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

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

6.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) - 사용자 구성당 로그를 전달하도록 수집기 구성을 생성합니다.

Loki Operator:

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

OpenShift Elasticsearch Operator:

참고

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

Elasticsearch - Elasticsearch 인스턴스를 기본 로그 저장소로 구성하고 배포합니다.
Kibana - 로그를 검색, 쿼리 및 보기 위해 Kibana 인스턴스를 구성하고 배포합니다.

6.2.2. JSON OpenShift Container Platform Logging 정보

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

JSON 로그 구문 분석
Elasticsearch에 대한 JSON 로그 데이터 구성
Elasticsearch 로그 저장소로 JSON 로그를 전달

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

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

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

6.2.4. OpenShift Container Platform Logging 문제 해결 정보

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

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

6.2.5. 필드 내보내기 정보

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

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

6.2.6. 이벤트 라우팅 정보

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

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

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

7장. 로깅 설치

OpenShift Container Platform Operator는 CR(사용자 정의 리소스)을 사용하여 애플리케이션 및 해당 구성 요소를 관리합니다. 높은 수준의 구성 및 설정은 CR 내에서 사용자가 제공합니다. Operator는 고급 지시문을 Operator 논리에 포함된 모범 사례를 기반으로 하위 수준 작업으로 변환합니다. CRD(사용자 정의 리소스 정의)는 CR을 정의하고 Operator 사용자가 사용할 수 있는 모든 구성을 나열합니다. Operator를 설치하면 CRD가 생성되는 CR을 생성하는 데 사용됩니다.

중요

로그 저장소 Operator 후에는 Red Hat OpenShift Logging Operator를 설치해야 합니다.

Loki Operator 또는 OpenShift Elasticsearch Operator를 설치하여 로그 저장소를 관리하고 Red Hat OpenShift Logging Operator가 로깅 구성 요소를 관리하여 로깅을 배포합니다. OpenShift Container Platform 웹 콘솔 또는 OpenShift Container Platform CLI를 사용하여 로깅을 설치하거나 구성할 수 있습니다.

참고

작은 정보

또는 모든 예제 오브젝트를 적용할 수 있습니다.

7.1. 웹 콘솔을 사용하여 Elasticsearch로 로깅 설치

OpenShift Container Platform 웹 콘솔을 사용하여 OpenShift Elasticsearch Operator 및 Red Hat OpenShift Logging Operator를 설치할 수 있습니다. Elasticsearch는 메모리를 많이 사용하는 애플리케이션입니다. 기본적으로 OpenShift Container Platform은 메모리 요청 및 제한이 16GB인 3 개의 Elasticsearch 노드를 설치합니다. 이 초기 3개의 OpenShift Container Platform 노드 세트에는 클러스터 내에서 Elasticsearch를 실행하기에 충분한 메모리가 없을 수 있습니다. Elasticsearch와 관련된 메모리 문제가 발생하는 경우 기존 노드의 메모리를 늘리는 대신 클러스터에 Elasticsearch 노드를 더 추가합니다.

참고

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

사전 요구 사항

Elasticsearch에 필요한 영구 스토리지가 있는지 확인합니다. 각 Elasticsearch 노드에는 자체 스토리지 볼륨이 필요합니다.
참고
영구 스토리지에 로컬 볼륨을 사용하는 경우 LocalVolume 오브젝트에서 volumeMode: block에 설명된 원시 블록 볼륨을 사용하지 마십시오. Elasticsearch는 원시 블록 볼륨을 사용할 수 없습니다.

프로세스

OpenShift Container Platform 웹 콘솔을 사용하여 OpenShift Elasticsearch Operator 및 Red Hat OpenShift Logging Operator를 설치하려면 다음을 수행합니다.

OpenShift Elasticsearch Operator를 설치합니다.
1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
2. 사용 가능한 Operator 목록에서 OpenShift Elasticsearch Operator를 선택한 다음 설치를 클릭합니다.
3. 설치 모드에서 클러스터의 모든 네임스페이스가 선택되어 있는지 확인합니다.
4. 설치된 네임스페이스에서 openshift-operators-redhat이 선택되어 있는지 확인합니다.
  openshift-operators-redhat 네임스페이스를 지정해야 합니다. openshift-operators 네임스페이스에 신뢰할 수 없는 Community Operator가 포함될 수 있고, 여기에서 OpenShift Container Platform 지표와 동일한 이름의 지표를 게시하면 충돌이 발생합니다.
6. 참고
3. 설치 모드에서 클러스터의 특정 네임스페이스가 선택되어 있는지 확인합니다.
4. 설치된 네임스페이스에서 Operator 권장 네임스페이스가 openshift-logging인지 확인하십시오.
5. 이 네임스페이스에서 Operator 권장 클러스터 모니터링 사용을 선택합니다.
  이 옵션은 네임스페이스 오브젝트에서 openshift.io/cluster-monitoring: "true" 레이블을 설정합니다. 클러스터 모니터링이 openshift-logging 네임스페이스를 스크랩하도록 하려면 이 옵션을 선택해야 합니다.
6. stable-5.y 를 업데이트 채널로 선택합니다.
7. 승인 전략을 선택합니다.
  - 자동 전략을 사용하면 Operator 새 버전이 준비될 때 OLM(Operator Lifecycle Manager)이 자동으로 Operator를 업데이트할 수 있습니다.
  - 수동 전략을 사용하려면 적절한 자격 증명을 가진 사용자가 Operator 업데이트를 승인해야 합니다.
8. 설치를 클릭합니다.
9. Operator → 설치된 Operator 페이지로 전환하여 Red Hat OpenShift Logging Operator가 설치되었는지 확인합니다.
10. Red Hat OpenShift Logging이 openshift-logging 프로젝트에 성공 상태로 나열되어 있는지 확인합니다.
  Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.
  - Operator → 설치된 Operator 페이지로 전환하여 상태 열에 오류 또는 실패가 있는지 점검합니다.
  - 워크로드 → Pod 페이지로 전환하고 openshift-logging 프로젝트에서 문제를 보고하는 Pod의 로그를 확인합니다.
OpenShift Logging 인스턴스를 생성합니다.
1. 관리 → 사용자 정의 리소스 정의 페이지로 전환합니다.
2. 사용자 정의 리소스 정의 페이지에서 ClusterLogging을 클릭합니다.
3. 사용자 정의 리소스 정의 상세 정보 페이지의 작업 메뉴에서 인스턴스 보기를 선택합니다.
4. ClusterLoggings 페이지에서 ClusterLogging 생성을 클릭합니다.
  데이터를 로드하기 위해 페이지를 새로 고쳐야 할 수도 있습니다.
5. YAML 필드에서 코드를 다음으로 교체합니다.
  참고
  이 기본 OpenShift Logging 구성은 다양한 환경을 지원해야 합니다. OpenShift Logging 클러스터에 수행할 수 있는 수정 사항에 대한 정보는 로깅 구성 요소 튜닝 및 구성 주제를 검토하십시오.
```
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 구성"을 참조하십시오.
  참고
  마스터 노드의 최대 수는 3입니다. 3보다 큰 nodeCount를 지정하면 OpenShift Container Platform은 마스터, 클라이언트 및 데이터 역할을 가진 마스터 적격 노드인 Elasticsearch 노드 3개를 생성합니다. 추가 Elasticsearch 노드는 클라이언트 및 데이터 역할을 사용하여 데이터 전용 노드로 생성됩니다. 마스터 노드는 인덱스 작성 또는 삭제, shard 할당 및 추적 노드와 같은 클러스터 전체 작업을 수행합니다. 데이터 노드는 shard를 보유하고 CRUD, 검색 및 집계와 같은 데이터 관련 작업을 수행합니다. 데이터 관련 작업은 I/O, 메모리 및 CPU 집약적입니다. 현재 노드에 과부하가 걸리면 이러한 리소스를 모니터링하고 더 많은 데이터 노드를 추가하는 것이 중요합니다.
  예를 들어 nodeCount = 4인 경우 다음 노드가 생성됩니다.
  $ oc get deployment
  출력 예
  
  cluster-logging-operator-66f77ffccb-ppzbg 1/1 Running 0 7m elasticsearch-cd-tuhduuw-1-f5c885dbf-dlqws 1/1 Running 0 2m4s 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
6. 생성을 클릭합니다. 이렇게 하면 로깅 구성 요소, Elasticsearch 사용자 정의 리소스 및 구성 요소, Kibana 인터페이스가 생성됩니다.

설치를 확인합니다.

워크로드 → Pod 페이지로 전환합니다.

openshift-logging 프로젝트를 선택합니다.

다음 목록과 유사한 OpenShift Logging, Elasticsearch, 수집기 및 Kibana에 대한 여러 Pod가 표시됩니다.

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

7.2.

참고

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

1
2

```
$ oc apply -f <filename>.yaml
```

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

1

```
$ oc apply -f <filename>.yaml
```

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-operators-redhat
  namespace: openshift-operators-redhat 1
spec: {}

1

```
$ oc apply -f <filename>.yaml
```

참고

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: elasticsearch-operator
  namespace: openshift-operators-redhat 1
spec:
  channel: <channel> 2
  installPlanApproval: Automatic 3
  source: redhat-operators 4
  sourceNamespace: openshift-marketplace
  name: elasticsearch-operator

1
2
3
4

```
$ oc apply -f <filename>.yaml
```

$ oc get csv --all-namespaces

NAMESPACE                                          NAME                            DISPLAY                            VERSION          REPLACES                        PHASE
default                                            elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
kube-node-lease                                    elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
kube-public                                        elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
kube-system                                        elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
openshift-apiserver-operator                       elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
openshift-apiserver                                elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
openshift-authentication-operator                  elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
openshift-authentication                           elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
openshift-cloud-controller-manager-operator        elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
openshift-cloud-controller-manager                 elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
openshift-cloud-credential-operator                elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded

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

1
2

```
$ oc apply -f <filename>.yaml
```

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

```
$ oc apply -f <filename>.yaml
```

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
2
3
4
5
6
7
8
9
10

참고

$ oc get deployment

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

```
$ oc apply -f <filename>.yaml
```

$ oc get pods -n openshift-logging

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

중요

7.3.

참고

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

1
2

```
$ oc apply -f <filename>.yaml
```

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

1
2
3

```
$ oc apply -f <filename>.yaml
```

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

1
2

```
$ oc apply -f <filename>.yaml
```

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

1

```
$ oc apply -f <filename>.yaml
```

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

```
$ oc apply -f <filename>.yaml
```

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki 1
  namespace: openshift-logging 2
spec:
  size: 1x.small 3
  storage:
    schemas:
    - version: v13
      effectiveDate: "<yyyy>-<mm>-<dd>"
    secret:
      name: logging-loki-s3 4
      type: s3 5
      credentialMode: 6
  storageClassName: <storage_class_name> 7
  tenants:
    mode: openshift-logging 8

1
2
3
4
5
6
7
8

```
$ oc apply -f <filename>.yaml
```

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance 1
  namespace: openshift-logging 2
spec:
  collection:
    type: vector
  logStore:
    lokistack:
      name: logging-loki
    type: lokistack
  visualization:
    type: ocp-console
    ocpConsole:
      logsLimit: 15
  managementState: Managed

1
2

```
$ oc apply -f <filename>.yaml
```

$ oc get pods -n openshift-logging

$ oc get pods -n openshift-logging
NAME                                               READY   STATUS    RESTARTS   AGE
cluster-logging-operator-fb7f7cf69-8jsbq           1/1     Running   0          98m
collector-222js                                    2/2     Running   0          18m
collector-g9ddv                                    2/2     Running   0          18m
collector-hfqq8                                    2/2     Running   0          18m
collector-sphwg                                    2/2     Running   0          18m
collector-vv7zn                                    2/2     Running   0          18m
collector-wk5zz                                    2/2     Running   0          18m
logging-view-plugin-6f76fbb78f-n2n4n               1/1     Running   0          18m
lokistack-sample-compactor-0                       1/1     Running   0          42m
lokistack-sample-distributor-7d7688bcb9-dvcj8      1/1     Running   0          42m
lokistack-sample-gateway-5f6c75f879-bl7k9          2/2     Running   0          42m
lokistack-sample-gateway-5f6c75f879-xhq98          2/2     Running   0          42m
lokistack-sample-index-gateway-0                   1/1     Running   0          42m
lokistack-sample-ingester-0                        1/1     Running   0          42m
lokistack-sample-querier-6b7b56bccc-2v9q4          1/1     Running   0          42m
lokistack-sample-query-frontend-84fb57c578-gq2f7   1/1     Running   0          42m

7.4.

중요
참고

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki 1
  namespace: openshift-logging 2
spec:
  size: 1x.small 3
  storage:
    schemas:
    - version: v13
      effectiveDate: "<yyyy>-<mm>-<dd>"
    secret:
      name: logging-loki-s3 4
      type: s3 5
      credentialMode: 6
  storageClassName: <storage_class_name> 7
  tenants:
    mode: openshift-logging 8

1
2
3
4
5
6
7
8

중요

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance 1
  namespace: openshift-logging 2
spec:
  collection:
    type: vector
  logStore:
    lokistack:
      name: logging-loki
    type: lokistack
  visualization:
    type: ocp-console
    ocpConsole:
      logsLimit: 15
  managementState: Managed

1
2

참고

8장.

8.1.

8.2.

8.3.

$ oc -n openshift-logging delete subscription <subscription>

$ oc -n openshift-logging delete operatorgroup <operator_group_name>

$ oc delete clusterserviceversion cluster-logging.<version>

$ 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:
  - ""
# ...

8.4.

8.5.

8.6.

apiVersion: loki.grafana.com/v1
kind: LokiStack
# ...
spec:
# ...
  storage:
    schemas:
    # ...
      version: v12 1
    - effectiveDate: "<yyyy>-<mm>-<future_dd>" 2
      version: v13
# ...

1
2

작은 정보

$ oc edit lokistack <name> -n openshift-logging

8.7.

참고

중요

$ 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

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

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

$ 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

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

예 8.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

$ oc get kibana kibana -o json

예 8.2.

[
{
"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
}
]

9장.

9.1.

참고

9.1.1.

중요

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

```
$ oc apply -f <filename>.yaml
```

9.1.2.

작은 정보

9.1.2.1.

참고

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

$ 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

9.2.

9.2.1.

9.2.2.

$ 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"]}}'

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

9.3.

9.3.1.

9.3.2.

표 9.1.

9.3.3.

표 9.2.

표 9.3.

표 9.4.

표 9.5.

표 9.6.

표 9.7.

표 9.8.

9.4.

참고

9.4.1.

$ oc auth can-i get pods --subresource log -n <project>

yes

참고

9.4.2.

$ oc auth can-i get pods --subresource log -n <project>

yes

참고

예 9.1.

{
  "_index": "infra-000001",
  "_type": "_doc",
  "_id": "YmJmYTBlNDkZTRmLTliMGQtMjE3NmFiOGUyOWM3",
  "_version": 1,
  "_score": null,
  "_source": {
    "docker": {
      "container_id": "f85fa55bbef7bb783f041066be1e7c267a6b88c4603dfce213e32c1"
    },
    "kubernetes": {
      "container_name": "registry-server",
      "namespace_name": "openshift-marketplace",
      "pod_name": "redhat-marketplace-n64gc",
      "container_image": "registry.redhat.io/redhat/redhat-marketplace-index:v4.7",
      "container_image_id": "registry.redhat.io/redhat/redhat-marketplace-index@sha256:65fc0c45aabb95809e376feb065771ecda9e5e59cc8b3024c4545c168f",
      "pod_id": "8f594ea2-c866-4b5c-a1c8-a50756704b2a",
      "host": "ip-10-0-182-28.us-east-2.compute.internal",
      "master_url": "https://kubernetes.default.svc",
      "namespace_id": "3abab127-7669-4eb3-b9ef-44c04ad68d38",
      "namespace_labels": {
        "openshift_io/cluster-monitoring": "true"
      },
      "flat_labels": [
        "catalogsource_operators_coreos_com/update=redhat-marketplace"
      ]
    },
    "message": "time=\"2020-09-23T20:47:03Z\" level=info msg=\"serving registry\" database=/database/index.db port=50051",
    "level": "unknown",
    "hostname": "ip-10-0-182-28.internal",
    "pipeline_metadata": {
      "collector": {
        "ipaddr4": "10.0.182.28",
        "inputname": "fluent-plugin-systemd",
        "name": "fluentd",
        "received_at": "2020-09-23T20:47:15.007583+00:00",
        "version": "1.7.4 1.6.0"
      }
    },
    "@timestamp": "2020-09-23T20:47:03.422465+00:00",
    "viaq_msg_id": "YmJmYTBlNDktMDMGQtMjE3NmFiOGUyOWM3",
    "openshift": {
      "labels": {
        "logging": "infra"
      }
    }
  },
  "fields": {
    "@timestamp": [
      "2020-09-23T20:47:03.422Z"
    ],
    "pipeline_metadata.collector.received_at": [
      "2020-09-23T20:47:15.007Z"
    ]
  },
  "sort": [
    1600894023422
  ]
}

9.4.3.

9.4.3.1.

$ oc -n openshift-logging edit ClusterLogging instance

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: openshift-logging

...

spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 3
      resources: 1
        limits:
          memory: 16Gi
        requests:
          cpu: 200m
          memory: 16Gi
      storage:
        storageClassName: "gp2"
        size: "200G"
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources: 2
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      proxy:
        resources: 3
          limits:
            memory: 100Mi
          requests:
            cpu: 100m
            memory: 100Mi
      replicas: 2
  collection:
    resources: 4
      limits:
        memory: 736Mi
      requests:
        cpu: 200m
        memory: 736Mi
    type: fluentd

1
2 3
4

9.4.3.2.

$ oc edit ClusterLogging instance

$ oc edit ClusterLogging instance

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"

....

spec:
    visualization:
      type: "kibana"
      kibana:
        replicas: 1 1

1

10장.

10.1.

10.1.1.

$ oc -n openshift-logging edit ClusterLogging instance

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: openshift-logging

...

spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 3
      resources: 1
        limits:
          memory: 16Gi
        requests:
          cpu: 200m
          memory: 16Gi
      storage:
        storageClassName: "gp2"
        size: "200G"
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources: 2
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      proxy:
        resources: 3
          limits:
            memory: 100Mi
          requests:
            cpu: 100m
            memory: 100Mi
      replicas: 2
  collection:
    resources: 4
      limits:
        memory: 736Mi
      requests:
        cpu: 200m
        memory: 736Mi
    type: fluentd

1
2 3
4

10.2.

10.2.1.

참고

variant: openshift
version: 4.16.0
metadata:
  name: 40-worker-custom-journald
  labels:
    machineconfiguration.openshift.io/role: "worker"
storage:
  files:
  - path: /etc/systemd/journald.conf
    mode: 0644 1
    overwrite: true
    contents:
      inline: |
        Compress=yes 2
        ForwardToConsole=no 3
        ForwardToSyslog=no
        MaxRetentionSec=1month 4
        RateLimitBurst=10000 5
        RateLimitIntervalSec=30s
        Storage=persistent 6
        SyncIntervalSec=1s 7
        SystemMaxUse=8G 8
        SystemKeepFree=20% 9
        SystemMaxFileSize=10M 10

참고

$ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml

$ oc apply -f 40-worker-custom-journald.yaml

$ oc describe machineconfigpool/worker

Name:         worker
Namespace:
Labels:       machineconfiguration.openshift.io/mco-built-in=
Annotations:  <none>
API Version:  machineconfiguration.openshift.io/v1
Kind:         MachineConfigPool

...

Conditions:
  Message:
  Reason:                All nodes are updating to rendered-worker-913514517bcea7c93bd446f4830bc64e

11장.

11.1.

참고

11.1.1.

11.1.1.1.

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  collection:
    logs:
      type: vector
      vector: {}
# ...

11.1.1.2.

중요

11.1.1.3.

표 11.1.

표 11.2.

표 11.3.

표 11.4.

표 11.5.

표 11.6.

11.1.1.4.

표 11.7.

11.1.2.

11.1.2.1.

중요

11.1.2.1.1.

11.1.2.1.2.

11.1.2.2.

중요

11.1.2.2.1.

$ oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>

11.2.

11.2.1.

표 11.8.

11.2.2.

: 참고



: 중요

11.3.

11.3.1.

{"level":"info","name":"fred","home":"bedrock"}

pipelines:
- inputRefs: [ application ]
  outputRefs: myFluentd
  parse: json

{"structured": { "level": "info", "name": "fred", "home": "bedrock" },
 "more fields..."}

중요

11.3.2.

중요

참고

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
# ...
  outputDefaults:
    elasticsearch:
      structuredTypeKey: kubernetes.labels.logFormat 1
      structuredTypeName: nologformat
  pipelines:
  - inputRefs:
    - application
    outputRefs:
    - default
    parse: json 2

1
2

{
  "structured":{"name":"fred","home":"bedrock"},
  "kubernetes":{"labels":{"logFormat": "apache", ...}}
}

{
  "structured":{"name":"wilma","home":"bedrock"},
  "kubernetes":{"labels":{"logFormat": "google", ...}}
}

outputDefaults:
 elasticsearch:
    structuredTypeKey: openshift.labels.myLabel 1
    structuredTypeName: nologformat
pipelines:
 - name: application-logs
   inputRefs:
   - application
   - audit
   outputRefs:
   - elasticsearch-secure
   - default
   parse: json
   labels:
     myLabel: myValue 2

1
2

{
  "structured":{"name":"fred","home":"bedrock"},
  "openshift":{"labels":{"myLabel": "myValue", ...}}
}

11.3.3.

중요

outputDefaults:
 elasticsearch:
    structuredTypeKey: <log record field>
    structuredTypeName: <name>
pipelines:
- inputRefs:
  - application
  outputRefs: default
  parse: json

중요

$ oc create -f <filename>.yaml

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

11.3.4.

중요

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputDefaults:
    elasticsearch:
      structuredTypeKey: kubernetes.labels.logFormat 1
      structuredTypeName: nologformat
      enableStructuredContainerLogs: true 2
  pipelines:
  - inputRefs:
    - application
    name: application-logs
    outputRefs:
    - default
    parse: json

1
2

apiVersion: v1
kind: Pod
metadata:
  annotations:
    containerType.logging.openshift.io/heavy: heavy 1
    containerType.logging.openshift.io/low: low
spec:
  containers:
  - name: heavy 2
    image: heavyimage
  - name: low
    image: lowimage

1
2

주의

11.4.

11.4.1.

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> 1
  namespace: <log_forwarder_namespace> 2
spec:
  serviceAccountName: <service_account_name> 3
  outputs:
   - name: elasticsearch-secure 4
     type: "elasticsearch"
     url: https://elasticsearch.secure.com:9200
     secret:
        name: elasticsearch
   - name: elasticsearch-insecure 5
     type: "elasticsearch"
     url: http://elasticsearch.insecure.com:9200
   - name: kafka-app 6
     type: "kafka"
     url: tls://kafka.secure.com:9093/app-topic
  inputs: 7
   - name: my-app-logs
     application:
        namespaces:
        - my-project
  pipelines:
   - name: audit-logs 8
     inputRefs:
      - audit
     outputRefs:
      - elasticsearch-secure
      - default
     labels:
       secure: "true" 9
       datacenter: "east"
   - name: infrastructure-logs 10
     inputRefs:
      - infrastructure
     outputRefs:
      - elasticsearch-insecure
     labels:
       datacenter: "west"
   - name: my-app 11
     inputRefs:
      - my-app-logs
     outputRefs:
      - default
   - inputRefs: 12
      - application
     outputRefs:
      - kafka-app
     labels:
       datacenter: "south"

11.4.1.1.

$ oc create secret generic -n <namespace> <secret_name> \
  --from-file=ca-bundle.crt=<your_bundle_file> \
  --from-literal=username=<your_username> \
  --from-literal=password=<your_password>

참고

11.4.2.

중요

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> 1
  namespace: <log_forwarder_namespace> 2
spec:
  serviceAccountName: <service_account_name> 3
  pipelines:
   - inputRefs:
     - <log_type> 4
     outputRefs:
     - <output_name> 5
  outputs:
  - name: <output_name> 6
    type: <output_type> 7
    url: <log_output_url> 8
# ...

1
2
3
4
5 7: 참고
6
8

11.4.3.

중요

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  tuning:
    delivery: AtLeastOnce 1
    compression: none 2
    maxWrite: <integer> 3
    minRetryDuration: 1s 4
    maxRetryDuration: 1s 5
# ...

표 11.9.

11.4.4.

주의

java.lang.NullPointerException: Cannot invoke "String.toString()" because "<param1>" is null
    at testjava.Main.handle(Main.java:47)
    at testjava.Main.printMe(Main.java:19)
    at testjava.Main.main(Main.java:10)

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  pipelines:
    - name: my-app-logs
      inputRefs:
        - application
      outputRefs:
        - default
      detectMultilineErrors: true

11.4.4.1.

표 11.10.

11.4.4.2.

[transforms.detect_exceptions_app-logs]
 type = "detect_exceptions"
 inputs = ["application"]
 languages = ["All"]
 group_by = ["kubernetes.namespace_name","kubernetes.pod_name","kubernetes.container_name"]
 expire_after_ms = 2000
 multiline_flush_interval_ms = 1000

<label @MULTILINE_APP_LOGS>
  <match kubernetes.**>
    @type detect_exceptions
    remove_tag_prefix 'kubernetes'
    message message
    force_line_breaks true
    multiline_flush_interval .2
  </match>
</label>

11.4.5.

참고

$ oc -n openshift-logging create secret generic gcp-secret --from-file google-application-credentials.json=<your_service_account_key_file.json>

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> 1
  namespace: <log_forwarder_namespace> 2
spec:
  serviceAccountName: <service_account_name> 3
  outputs:
    - name: gcp-1
      type: googleCloudLogging
      secret:
        name: gcp-secret
      googleCloudLogging:
        projectId : "openshift-gce-devel" 4
        logId : "app-gcp" 5
  pipelines:
    - name: test-app
      inputRefs: 6
        - application
      outputRefs:
        - gcp-1

1
2
3
4
5
6

11.4.6.

참고

$ oc -n openshift-logging create secret generic vector-splunk-secret --from-literal hecToken=<HEC_Token>

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> 1
  namespace: <log_forwarder_namespace> 2
spec:
  serviceAccountName: <service_account_name> 3
  outputs:
    - name: splunk-receiver 4
      secret:
        name: vector-splunk-secret 5
      type: splunk 6
      url: <http://your.splunk.hec.url:8088> 7
  pipelines: 8
    - inputRefs:
        - application
        - infrastructure
      name: 9
      outputRefs:
        - splunk-receiver 10

1
2
3
4
5
6
7
8
9
10

11.4.7.

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> 1
  namespace: <log_forwarder_namespace> 2
spec:
  serviceAccountName: <service_account_name> 3
  outputs:
    - name: httpout-app
      type: http
      url: 4
      http:
        headers: 5
          h1: v1
          h2: v2
        method: POST
      secret:
        name: 6
      tls:
        insecureSkipVerify: 7
  pipelines:
    - name:
      inputRefs:
        - application
      outputRefs:
        - 8

1
2
3
4
5
6
7
8

11.4.8.

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: openshift-logging
type: Opaque
data:
  shared_key: <your_shared_key> 1

1

Get-AzOperationalInsightsWorkspaceSharedKey -ResourceGroupName "<resource_name>" -Name "<workspace_name>”

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: azure-monitor
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id 1
      logType: my_log_type 2
    secret:
       name: my-secret
  pipelines:
  - name: app-pipeline
    inputRefs:
    - application
    outputRefs:
    - azure-monitor

1
2

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: azure-monitor-app
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
      logType: application_log 1
    secret:
      name: my-secret
  - name: azure-monitor-infra
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
      logType: infra_log #
    secret:
      name: my-secret
  pipelines:
    - name: app-pipeline
      inputRefs:
      - application
      outputRefs:
      - azure-monitor-app
    - name: infra-pipeline
      inputRefs:
      - infrastructure
      outputRefs:
      - azure-monitor-infra

1

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: azure-monitor
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
      logType: my_log_type
      azureResourceId: "/subscriptions/111111111" 1
      host: "ods.opinsights.azure.com" 2
    secret:
       name: my-secret
  pipelines:
   - name: app-pipeline
    inputRefs:
    - application
    outputRefs:
    - azure-monitor

1
2

11.4.9.

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance 1
  namespace: openshift-logging 2
spec:
  outputs:
   - name: fluentd-server-secure 3
     type: fluentdForward 4
     url: 'tls://fluentdserver.security.example.com:24224' 5
     secret: 6
        name: fluentd-secret
   - name: fluentd-server-insecure
     type: fluentdForward
     url: 'tcp://fluentdserver.home.example.com:24224'
  inputs: 7
   - name: my-app-logs
     application:
        namespaces:
        - my-project 8
  pipelines:
   - name: forward-to-fluentd-insecure 9
     inputRefs: 10
     - my-app-logs
     outputRefs: 11
     - fluentd-server-insecure
     labels:
       project: "my-project" 12
   - name: forward-to-fluentd-secure 13
     inputRefs:
     - application 14
     - audit
     - infrastructure
     outputRefs:
     - fluentd-server-secure
     - default
     labels:
       clusterId: "C1234"

```
$ oc apply -f <filename>.yaml
```

11.4.10.

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> 1
  namespace: <log_forwarder_namespace> 2
spec:
  pipelines:
    - inputRefs: [ myAppLogData ] 3
      outputRefs: [ default ] 4
  inputs: 5
    - name: myAppLogData
      application:
        selector:
          matchLabels: 6
            environment: production
            app: nginx
        namespaces: 7
        - app1
        - app2
  outputs: 8
    - <output_name>
    ...

1
2
3
4
5
6
7
8

- inputRefs: [ myAppLogData, myOtherAppLogData ]

```
$ oc create -f <file-name>.yaml
```

11.4.11.

참고

참고

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  pipelines:
    - name: my-pipeline
      inputRefs: audit 1
      filterRefs: my-policy 2
      outputRefs: default
  filters:
    - name: my-policy
      type: kubeAPIAudit
      kubeAPIAudit:
        # Don't generate audit events for all requests in RequestReceived stage.
        omitStages:
          - "RequestReceived"

        rules:
          # Log pod changes at RequestResponse level
          - level: RequestResponse
            resources:
            - group: ""
              resources: ["pods"]

          # Log "pods/log", "pods/status" at Metadata level
          - level: Metadata
            resources:
            - group: ""
              resources: ["pods/log", "pods/status"]

          # Don't log requests to a configmap called "controller-leader"
          - level: None
            resources:
            - group: ""
              resources: ["configmaps"]
              resourceNames: ["controller-leader"]

          # Don't log watch requests by the "system:kube-proxy" on endpoints or services
          - level: None
            users: ["system:kube-proxy"]
            verbs: ["watch"]
            resources:
            - group: "" # core API group
              resources: ["endpoints", "services"]

          # Don't log authenticated requests to certain non-resource URL paths.
          - level: None
            userGroups: ["system:authenticated"]
            nonResourceURLs:
            - "/api*" # Wildcard matching.
            - "/version"

          # Log the request body of configmap changes in kube-system.
          - level: Request
            resources:
            - group: "" # core API group
              resources: ["configmaps"]
            # This rule only applies to resources in the "kube-system" namespace.
            # The empty string "" can be used to select non-namespaced resources.
            namespaces: ["kube-system"]

          # Log configmap and secret changes in all other namespaces at the Metadata level.
          - level: Metadata
            resources:
            - group: "" # core API group
              resources: ["secrets", "configmaps"]

          # Log all other resources in core and extensions at the Request level.
          - level: Request
            resources:
            - group: "" # core API group
            - group: "extensions" # Version of group should NOT be included.

          # A catch-all rule to log all other requests at the Metadata level.
          - level: Metadata

1
2

11.4.12.

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> 1
  namespace: <log_forwarder_namespace> 2
spec:
  serviceAccountName: <service_account_name> 3
  outputs:
  - name: loki-insecure 4
    type: "loki" 5
    url: http://loki.insecure.com:3100 6
    loki:
      tenantKey: kubernetes.namespace_name
      labelKeys:
      - kubernetes.labels.foo
  - name: loki-secure 7
    type: "loki"
    url: https://loki.secure.com:3100
    secret:
      name: loki-secret 8
    loki:
      tenantKey: kubernetes.namespace_name 9
      labelKeys:
      - kubernetes.labels.foo 10
  pipelines:
  - name: application-logs 11
    inputRefs:  12
    - application
    - audit
    outputRefs: 13
    - loki-secure

1
2
3
4
5
6
7
8
9
10
11
12
13

참고

```
$ oc apply -f <filename>.yaml
```

11.4.13.

참고

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> 1
  namespace: <log_forwarder_namespace> 2
spec:
  serviceAccountName: <service_account_name> 3
  outputs:
   - name: elasticsearch-example 4
     type: elasticsearch 5
     elasticsearch:
       version: 8 6
     url: http://elasticsearch.example.com:9200 7
     secret:
       name: es-secret 8
  pipelines:
   - name: application-logs 9
     inputRefs: 10
     - application
     - audit
     outputRefs:
     - elasticsearch-example 11
     - default 12
     labels:
       myLabel: "myValue" 13
# ...

1
2
3
4
5
6
7
8
9
10
11
12
13

```
$ oc apply -f <filename>.yaml
```

apiVersion: v1
kind: Secret
metadata:
  name: openshift-test-secret
data:
  username: <username>
  password: <password>
# ...

$ oc create secret -n openshift-logging openshift-test-secret.yaml

kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
   - name: elasticsearch
     type: "elasticsearch"
     url: https://elasticsearch.secure.com:9200
     secret:
        name: openshift-test-secret
# ...

참고

```
$ oc apply -f <filename>.yaml
```

11.4.14.

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance 1
  namespace: openshift-logging 2
spec:
  outputs:
   - name: fluentd-server-secure 3
     type: fluentdForward 4
     url: 'tls://fluentdserver.security.example.com:24224' 5
     secret: 6
        name: fluentd-secret
   - name: fluentd-server-insecure
     type: fluentdForward
     url: 'tcp://fluentdserver.home.example.com:24224'
  pipelines:
   - name: forward-to-fluentd-secure 7
     inputRefs:  8
     - application
     - audit
     outputRefs:
     - fluentd-server-secure 9
     - default 10
     labels:
       clusterId: "C1234" 11
   - name: forward-to-fluentd-insecure 12
     inputRefs:
     - infrastructure
     outputRefs:
     - fluentd-server-insecure
     labels:
       clusterId: "C1234"

```
$ oc create -f <file-name>.yaml
```

11.4.14.1.

input { tcp { codec => fluent { nanosecond_precision => true } port => 24114 } }
filter { }
output { stdout { codec => rubydebug } }

11.4.15.

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> 1
  namespace: <log_forwarder_namespace> 2
spec:
  serviceAccountName: <service_account_name> 3
  outputs:
   - name: rsyslog-east 4
     type: syslog 5
     syslog: 6
       facility: local0
       rfc: RFC3164
       payloadKey: message
       severity: informational
     url: 'tls://rsyslogserver.east.example.com:514' 7
     secret: 8
        name: syslog-secret
   - name: rsyslog-west
     type: syslog
     syslog:
      appName: myapp
      facility: user
      msgID: mymsg
      procID: myproc
      rfc: RFC5424
      severity: debug
     url: 'tcp://rsyslogserver.west.example.com:514'
  pipelines:
   - name: syslog-east 9
     inputRefs: 10
     - audit
     - application
     outputRefs: 11
     - rsyslog-east
     - default 12
     labels:
       secure: "true" 13
       syslog: "east"
   - name: syslog-west 14
     inputRefs:
     - infrastructure
     outputRefs:
     - rsyslog-west
     - default
     labels:
       syslog: "west"

```
$ oc create -f <filename>.yaml
```

11.4.15.1.

  spec:
    outputs:
    - name: syslogout
      syslog:
        addLogSource: true
        facility: user
        payloadKey: message
        rfc: RFC3164
        severity: debug
        tag: mytag
      type: syslog
      url: tls://syslog-receiver.openshift-logging.svc:24224
    pipelines:
    - inputRefs:
      - application
      name: test-app
      outputRefs:
      - syslogout

참고

<15>1 2020-11-15T17:06:14+00:00 fluentd-9hkb4 mytag - - -  {"msgcontent"=>"Message Contents", "timestamp"=>"2020-11-15 17:06:09", "tag_key"=>"rec_tag", "index"=>56}

<15>1 2020-11-16T10:49:37+00:00 crc-j55b9-master-0 mytag - - -  namespace_name=clo-test-6327,pod_name=log-generator-ff9746c49-qxm7l,container_name=log-generator,message={"msgcontent":"My life is my message", "timestamp":"2020-11-16 10:49:36", "tag_key":"rec_tag", "index":76}

11.4.15.2.

참고

11.4.15.3.

11.4.16.

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> 1
  namespace: <log_forwarder_namespace> 2
spec:
  serviceAccountName: <service_account_name> 3
  outputs:
   - name: app-logs 4
     type: kafka 5
     url: tls://kafka.example.devlab.com:9093/app-topic 6
     secret:
       name: kafka-secret 7
   - name: infra-logs
     type: kafka
     url: tcp://kafka.devlab2.example.com:9093/infra-topic 8
   - name: audit-logs
     type: kafka
     url: tls://kafka.qelab.example.com:9093/audit-topic
     secret:
        name: kafka-secret-qe
  pipelines:
   - name: app-topic 9
     inputRefs: 10
     - application
     outputRefs: 11
     - app-logs
     labels:
       logType: "application" 12
   - name: infra-topic 13
     inputRefs:
     - infrastructure
     outputRefs:
     - infra-logs
     labels:
       logType: "infra"
   - name: audit-topic
     inputRefs:
     - audit
     outputRefs:
     - audit-logs
     labels:
       logType: "audit"

# ...
spec:
  outputs:
  - name: app-logs
    type: kafka
    secret:
      name: kafka-secret-dev
    kafka:  1
      brokers: 2
        - tls://kafka-broker1.example.com:9093/
        - tls://kafka-broker2.example.com:9093/
      topic: app-topic 3
# ...

1
2
3

```
$ oc apply -f <filename>.yaml
```

11.4.17.

apiVersion: v1
kind: Secret
metadata:
  name: cw-secret
  namespace: openshift-logging
data:
  aws_access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK
  aws_secret_access_key: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=

```
$ oc apply -f cw-secret.yaml
```

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> 1
  namespace: <log_forwarder_namespace> 2
spec:
  serviceAccountName: <service_account_name> 3
  outputs:
   - name: cw 4
     type: cloudwatch 5
     cloudwatch:
       groupBy: logType 6
       groupPrefix: <group prefix> 7
       region: us-east-2 8
     secret:
        name: cw-secret 9
  pipelines:
    - name: infra-logs 10
      inputRefs: 11
        - infrastructure
        - audit
        - application
      outputRefs:
        - cw 12

```
$ oc create -f <file-name>.yaml
```

$ oc get Infrastructure/cluster -ojson | jq .status.infrastructureName
"mycluster-7977k"

$ oc run busybox --image=busybox -- sh -c 'while true; do echo "My life is my message"; sleep 3; done'
$ oc logs -f busybox
My life is my message
My life is my message
My life is my message
...

$ oc get ns/app -ojson | jq .metadata.uid
"794e1e1a-b9f5-4958-a190-e76a9b53d7bf"

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
   - name: cw
     type: cloudwatch
     cloudwatch:
       groupBy: logType
       region: us-east-2
     secret:
        name: cw-secret
  pipelines:
    - name: all-logs
      inputRefs:
        - infrastructure
        - audit
        - application
      outputRefs:
        - cw

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"mycluster-7977k.application"
"mycluster-7977k.audit"
"mycluster-7977k.infrastructure"

$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.application | jq .logStreams[].logStreamName
"kubernetes.var.log.containers.busybox_app_busybox-da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76.log"

$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.audit | jq .logStreams[].logStreamName
"ip-10-0-131-228.us-east-2.compute.internal.k8s-audit.log"
"ip-10-0-131-228.us-east-2.compute.internal.linux-audit.log"
"ip-10-0-131-228.us-east-2.compute.internal.openshift-audit.log"
...

$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.infrastructure | jq .logStreams[].logStreamName
"ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-69f9fd9b58-zqzw5_openshift-oauth-apiserver_oauth-apiserver-453c5c4ee026fe20a6139ba6b1cdd1bed25989c905bf5ac5ca211b7cbb5c3d7b.log"
"ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-797774f7c5-lftrx_openshift-apiserver_openshift-apiserver-ce51532df7d4e4d5f21c4f4be05f6575b93196336be0027067fd7d93d70f66a4.log"
"ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-797774f7c5-lftrx_openshift-apiserver_openshift-apiserver-check-endpoints-82a9096b5931b5c3b1d6dc4b66113252da4a6472c9fff48623baee761911a9ef.log"
...

$ aws logs get-log-events --log-group-name mycluster-7977k.application --log-stream-name kubernetes.var.log.containers.busybox_app_busybox-da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76.log
{
    "events": [
        {
            "timestamp": 1629422704178,
            "message": "{\"docker\":{\"container_id\":\"da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76\"},\"kubernetes\":{\"container_name\":\"busybox\",\"namespace_name\":\"app\",\"pod_name\":\"busybox\",\"container_image\":\"docker.io/library/busybox:latest\",\"container_image_id\":\"docker.io/library/busybox@sha256:0f354ec1728d9ff32edcd7d1b8bbdfc798277ad36120dc3dc683be44524c8b60\",\"pod_id\":\"870be234-90a3-4258-b73f-4f4d6e2777c7\",\"host\":\"ip-10-0-216-3.us-east-2.compute.internal\",\"labels\":{\"run\":\"busybox\"},\"master_url\":\"https://kubernetes.default.svc\",\"namespace_id\":\"794e1e1a-b9f5-4958-a190-e76a9b53d7bf\",\"namespace_labels\":{\"kubernetes_io/metadata_name\":\"app\"}},\"message\":\"My life is my message\",\"level\":\"unknown\",\"hostname\":\"ip-10-0-216-3.us-east-2.compute.internal\",\"pipeline_metadata\":{\"collector\":{\"ipaddr4\":\"10.0.216.3\",\"inputname\":\"fluent-plugin-systemd\",\"name\":\"fluentd\",\"received_at\":\"2021-08-20T01:25:08.085760+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-20T01:25:04.178986+00:00\",\"viaq_index_name\":\"app-write\",\"viaq_msg_id\":\"NWRjZmUyMWQtZjgzNC00MjI4LTk3MjMtNTk3NmY3ZjU4NDk1\",\"log_type\":\"application\",\"time\":\"2021-08-20T01:25:04+00:00\"}",
            "ingestionTime": 1629422744016
        },
...

cloudwatch:
    groupBy: logType
    groupPrefix: demo-group-prefix
    region: us-east-2

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"demo-group-prefix.application"
"demo-group-prefix.audit"
"demo-group-prefix.infrastructure"

cloudwatch:
    groupBy: namespaceName
    region: us-east-2

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"mycluster-7977k.app"
"mycluster-7977k.audit"
"mycluster-7977k.infrastructure"

cloudwatch:
    groupBy: namespaceUUID
    region: us-east-2

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"mycluster-7977k.794e1e1a-b9f5-4958-a190-e76a9b53d7bf" // uid of the "app" namespace
"mycluster-7977k.audit"
"mycluster-7977k.infrastructure"

11.4.18.

$ oc create secret generic cw-sts-secret -n openshift-logging --from-literal=role_arn=arn:aws:iam::123456789012:role/my-role_with-permissions

apiVersion: v1
kind: Secret
metadata:
  namespace: openshift-logging
  name: my-secret-name
stringData:
  role_arn: arn:aws:iam::123456789012:role/my-role_with-permissions

11.4.19.

apiVersion: cloudcredential.openshift.io/v1
kind: CredentialsRequest
metadata:
  name: <your_role_name>-credrequest
  namespace: openshift-cloud-credential-operator
spec:
  providerSpec:
    apiVersion: cloudcredential.openshift.io/v1
    kind: AWSProviderSpec
    statementEntries:
      - action:
          - logs:PutLogEvents
          - logs:CreateLogGroup
          - logs:PutRetentionPolicy
          - logs:CreateLogStream
          - logs:DescribeLogGroups
          - logs:DescribeLogStreams
        effect: Allow
        resource: arn:aws:logs:*:*:*
  secretRef:
    name: <your_role_name>
    namespace: openshift-logging
  serviceAccountNames:
    - logcollector

$ ccoctl aws create-iam-roles \
--name=<name> \
--region=<aws_region> \
--credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests \
--identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<name>-oidc.s3.<aws_region>.amazonaws.com 1

1

$ oc apply -f output/manifests/openshift-logging-<your_role_name>-credentials.yaml

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> 1
  namespace: <log_forwarder_namespace> 2
spec:
  serviceAccountName: clf-collector 3
  outputs:
   - name: cw 4
     type: cloudwatch 5
     cloudwatch:
       groupBy: logType 6
       groupPrefix: <group prefix> 7
       region: us-east-2 8
     secret:
        name: <your_secret_name> 9
  pipelines:
    - name: to-cloudwatch 10
      inputRefs: 11
        - infrastructure
        - audit
        - application
      outputRefs:
        - cw 12

11.5.

11.5.1.

참고

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
# ...
spec:
# ...
  collection:
    type: <log_collector_type> 1
    resources: {}
    tolerations: {}
# ...

1

```
$ oc apply -f <filename>.yaml
```

11.5.2.

apiVersion: logging.openshift.io/v1alpha1
kind: LogFileMetricExporter
metadata:
  name: instance
  namespace: openshift-logging
spec:
  nodeSelector: {} 1
  resources: 2
    limits:
      cpu: 500m
      memory: 256Mi
    requests:
      cpu: 200m
      memory: 128Mi
  tolerations: [] 3
# ...

1
2
3

```
$ oc apply -f <filename>.yaml
```

$ oc get pods -l app.kubernetes.io/component=logfilesmetricexporter -n openshift-logging

NAME                           READY   STATUS    RESTARTS   AGE
logfilesmetricexporter-9qbjj   1/1     Running   0          2m46s
logfilesmetricexporter-cbc4v   1/1     Running   0          2m46s

11.5.3.

$ oc -n openshift-logging edit ClusterLogging instance

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  collection:
    type: fluentd
    resources:
      limits: 1
        memory: 736Mi
      requests:
        cpu: 100m
        memory: 736Mi
# ...

1

11.5.4.

11.5.4.1.

apiVersion: logging.openshift.io/v1beta1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccountName: <service_account_name>
  inputs:
    - name: http-receiver 1
      receiver:
        type: http 2
        http:
          format: kubeAPIAudit 3
          port: 8443 4
  pipelines: 5
    - name: http-pipeline
      inputRefs:
        - http-receiver
# ...

1
2
3
4
5

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  inputs:
    - name: http-receiver 1
      receiver:
        type: http 2
        http:
          format: kubeAPIAudit 3
          port: 8443 4
  pipelines: 5
  - inputRefs:
    - http-receiver
    name: http-pipeline
# ...

1
2
3
4
5

```
$ oc apply -f <filename>.yaml
```

11.5.5.

참고

표 11.11.

```
$ oc edit ClusterLogging instance
```

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  collection:
    fluentd:
      buffer:
        chunkLimitSize: 8m 1
        flushInterval: 5s 2
        flushMode: interval 3
        flushThreadCount: 3 4
        overflowAction: throw_exception 5
        retryMaxInterval: "300s" 6
        retryType: periodic 7
        retryWait: 1s 8
        totalLimitSize: 32m 9
# ...

1
2
3
4
5
6
7
8
9

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

$ oc extract configmap/collector-config --confirm

<buffer>
  @type file
  path '/var/lib/fluentd/default'
  flush_mode interval
  flush_interval 5s
  flush_thread_count 3
  retry_type periodic
  retry_wait 1s
  retry_max_interval 300s
  retry_timeout 60m
  queued_chunks_limit_size "#{ENV['BUFFER_QUEUE_LIMIT'] || '32'}"
  total_limit_size "#{ENV['TOTAL_LIMIT_SIZE_PER_BUFFER'] || '8589934592'}"
  chunk_limit_size 8m
  overflow_action throw_exception
  disable_chunk_backup true
</buffer>

11.6.

중요

11.6.1.

참고

apiVersion: template.openshift.io/v1
kind: Template
metadata:
  name: eventrouter-template
  annotations:
    description: "A pod forwarding kubernetes events to OpenShift Logging stack."
    tags: "events,EFK,logging,cluster-logging"
objects:
  - kind: ServiceAccount 1
    apiVersion: v1
    metadata:
      name: eventrouter
      namespace: ${NAMESPACE}
  - kind: ClusterRole 2
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: event-reader
    rules:
    - apiGroups: [""]
      resources: ["events"]
      verbs: ["get", "watch", "list"]
  - kind: ClusterRoleBinding 3
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: event-reader-binding
    subjects:
    - kind: ServiceAccount
      name: eventrouter
      namespace: ${NAMESPACE}
    roleRef:
      kind: ClusterRole
      name: event-reader
  - kind: ConfigMap 4
    apiVersion: v1
    metadata:
      name: eventrouter
      namespace: ${NAMESPACE}
    data:
      config.json: |-
        {
          "sink": "stdout"
        }
  - kind: Deployment 5
    apiVersion: apps/v1
    metadata:
      name: eventrouter
      namespace: ${NAMESPACE}
      labels:
        component: "eventrouter"
        logging-infra: "eventrouter"
        provider: "openshift"
    spec:
      selector:
        matchLabels:
          component: "eventrouter"
          logging-infra: "eventrouter"
          provider: "openshift"
      replicas: 1
      template:
        metadata:
          labels:
            component: "eventrouter"
            logging-infra: "eventrouter"
            provider: "openshift"
          name: eventrouter
        spec:
          serviceAccount: eventrouter
          containers:
            - name: kube-eventrouter
              image: ${IMAGE}
              imagePullPolicy: IfNotPresent
              resources:
                requests:
                  cpu: ${CPU}
                  memory: ${MEMORY}
              volumeMounts:
              - name: config-volume
                mountPath: /etc/eventrouter
              securityContext:
                allowPrivilegeEscalation: false
                capabilities:
                  drop: ["ALL"]
          securityContext:
            runAsNonRoot: true
            seccompProfile:
              type: RuntimeDefault
          volumes:
          - name: config-volume
            configMap:
              name: eventrouter
parameters:
  - name: IMAGE 6
    displayName: Image
    value: "registry.redhat.io/openshift-logging/eventrouter-rhel9:v0.4"
  - name: CPU 7
    displayName: CPU
    value: "100m"
  - name: MEMORY 8
    displayName: Memory
    value: "128Mi"
  - name: NAMESPACE
    displayName: Namespace
    value: "openshift-logging" 9

1
2
3
4
5
6
7
8
9

$ oc process -f <templatefile> | oc apply -n openshift-logging -f -

$ oc process -f eventrouter.yaml | oc apply -n openshift-logging -f -

serviceaccount/eventrouter created
clusterrole.rbac.authorization.k8s.io/event-reader created
clusterrolebinding.rbac.authorization.k8s.io/event-reader-binding created
configmap/eventrouter created
deployment.apps/eventrouter created

$ oc get pods --selector  component=eventrouter -o name -n openshift-logging

pod/cluster-logging-eventrouter-d649f97c8-qvv8r

$ oc logs <cluster_logging_eventrouter_pod> -n openshift-logging

$ oc logs cluster-logging-eventrouter-d649f97c8-qvv8r -n openshift-logging

{"verb":"ADDED","event":{"metadata":{"name":"openshift-service-catalog-controller-manager-remover.1632d931e88fcd8f","namespace":"openshift-service-catalog-removed","selfLink":"/api/v1/namespaces/openshift-service-catalog-removed/events/openshift-service-catalog-controller-manager-remover.1632d931e88fcd8f","uid":"787d7b26-3d2f-4017-b0b0-420db4ae62c0","resourceVersion":"21399","creationTimestamp":"2020-09-08T15:40:26Z"},"involvedObject":{"kind":"Job","namespace":"openshift-service-catalog-removed","name":"openshift-service-catalog-controller-manager-remover","uid":"fac9f479-4ad5-4a57-8adc-cb25d3d9cf8f","apiVersion":"batch/v1","resourceVersion":"21280"},"reason":"Completed","message":"Job completed","source":{"component":"job-controller"},"firstTimestamp":"2020-09-08T15:40:26Z","lastTimestamp":"2020-09-08T15:40:26Z","count":1,"type":"Normal"}}

12장.

12.1.

12.1.1.

12.1.1.1.

참고

12.1.2.

12.1.3.

12.2.

참고

12.2.1.

12.2.1.1.

중요

표 12.1.

12.2.1.2.

중요
참고

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki 1
  namespace: openshift-logging 2
spec:
  size: 1x.small 3
  storage:
    schemas:
    - version: v13
      effectiveDate: "<yyyy>-<mm>-<dd>"
    secret:
      name: logging-loki-s3 4
      type: s3 5
      credentialMode: 6
  storageClassName: <storage_class_name> 7
  tenants:
    mode: openshift-logging 8

1
2
3
4
5
6
7
8

중요

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance 1
  namespace: openshift-logging 2
spec:
  collection:
    type: vector
  logStore:
    lokistack:
      name: logging-loki
    type: lokistack
  visualization:
    type: ocp-console
    ocpConsole:
      logsLimit: 15
  managementState: Managed

1
2

참고

12.2.1.3.

apiVersion: v1
kind: Secret
metadata:
  name: logging-loki-s3
  namespace: openshift-logging
stringData:
  access_key_id: AKIAIOSFODNN7EXAMPLE
  access_key_secret: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
  bucketnames: s3-bucket-name
  endpoint: https://s3.eu-central-1.amazonaws.com
  region: eu-central-1

12.2.2.

참고

12.2.2.1.

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-5.9"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
      - name: CLIENTID
        value: <your_client_id>
      - name: TENANTID
        value: <your_tenant_id>
      - name: SUBSCRIPTIONID
        value: <your_subscription_id>
      - name: REGION
        value: <your_region>

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-5.9"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: ROLEARN
      value: <role_ARN>

12.2.2.2.

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki 1
  namespace: openshift-logging
spec:
  size: 1x.small 2
  storage:
    schemas:
      - effectiveDate: '2023-10-15'
        version: v13
    secret:
      name: logging-loki-s3 3
      type: s3 4
      credentialMode: 5
  storageClassName: <storage_class_name> 6
  tenants:
    mode: openshift-logging

1
2
3
4
5
6

12.2.2.3.

참고

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

1
2

```
$ oc apply -f <filename>.yaml
```

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

1
2
3

```
$ oc apply -f <filename>.yaml
```

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

1
2

```
$ oc apply -f <filename>.yaml
```

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

1

```
$ oc apply -f <filename>.yaml
```

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

```
$ oc apply -f <filename>.yaml
```

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki 1
  namespace: openshift-logging 2
spec:
  size: 1x.small 3
  storage:
    schemas:
    - version: v13
      effectiveDate: "<yyyy>-<mm>-<dd>"
    secret:
      name: logging-loki-s3 4
      type: s3 5
      credentialMode: 6
  storageClassName: <storage_class_name> 7
  tenants:
    mode: openshift-logging 8

1
2
3
4
5
6
7
8

```
$ oc apply -f <filename>.yaml
```

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance 1
  namespace: openshift-logging 2
spec:
  collection:
    type: vector
  logStore:
    lokistack:
      name: logging-loki
    type: lokistack
  visualization:
    type: ocp-console
    ocpConsole:
      logsLimit: 15
  managementState: Managed

1
2

```
$ oc apply -f <filename>.yaml
```

$ oc get pods -n openshift-logging

$ oc get pods -n openshift-logging
NAME                                               READY   STATUS    RESTARTS   AGE
cluster-logging-operator-fb7f7cf69-8jsbq           1/1     Running   0          98m
collector-222js                                    2/2     Running   0          18m
collector-g9ddv                                    2/2     Running   0          18m
collector-hfqq8                                    2/2     Running   0          18m
collector-sphwg                                    2/2     Running   0          18m
collector-vv7zn                                    2/2     Running   0          18m
collector-wk5zz                                    2/2     Running   0          18m
logging-view-plugin-6f76fbb78f-n2n4n               1/1     Running   0          18m
lokistack-sample-compactor-0                       1/1     Running   0          42m
lokistack-sample-distributor-7d7688bcb9-dvcj8      1/1     Running   0          42m
lokistack-sample-gateway-5f6c75f879-bl7k9          2/2     Running   0          42m
lokistack-sample-gateway-5f6c75f879-xhq98          2/2     Running   0          42m
lokistack-sample-index-gateway-0                   1/1     Running   0          42m
lokistack-sample-ingester-0                        1/1     Running   0          42m
lokistack-sample-querier-6b7b56bccc-2v9q4          1/1     Running   0          42m
lokistack-sample-query-frontend-84fb57c578-gq2f7   1/1     Running   0          42m

12.2.2.4.

$ oc create secret generic -n openshift-logging <your_secret_name> \
 --from-file=tls.key=<your_key_file>
 --from-file=tls.crt=<your_crt_file>
 --from-file=ca-bundle.crt=<your_bundle_file>
 --from-literal=username=<your_username>
 --from-literal=password=<your_password>

참고

```
$ oc get secrets
```

12.2.2.5.

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki 1
  namespace: openshift-logging
spec:
  size: 1x.small 2
  storage:
    schemas:
      - effectiveDate: '2023-10-15'
        version: v13
    secret:
      name: logging-loki-s3 3
      type: s3 4
      credentialMode: 5
  storageClassName: <storage_class_name> 6
  tenants:
    mode: openshift-logging

$ oc get pods -n openshift-logging

NAME                                           READY   STATUS    RESTARTS   AGE
cluster-logging-operator-78fddc697-mnl82       1/1     Running   0          14m
collector-6cglq                                2/2     Running   0          45s
collector-8r664                                2/2     Running   0          45s
collector-8z7px                                2/2     Running   0          45s
collector-pdxl9                                2/2     Running   0          45s
collector-tc9dx                                2/2     Running   0          45s
collector-xkd76                                2/2     Running   0          45s
logging-loki-compactor-0                       1/1     Running   0          8m2s
logging-loki-distributor-b85b7d9fd-25j9g       1/1     Running   0          8m2s
logging-loki-distributor-b85b7d9fd-xwjs6       1/1     Running   0          8m2s
logging-loki-gateway-7bb86fd855-hjhl4          2/2     Running   0          8m2s
logging-loki-gateway-7bb86fd855-qjtlb          2/2     Running   0          8m2s
logging-loki-index-gateway-0                   1/1     Running   0          8m2s
logging-loki-index-gateway-1                   1/1     Running   0          7m29s
logging-loki-ingester-0                        1/1     Running   0          8m2s
logging-loki-ingester-1                        1/1     Running   0          6m46s
logging-loki-querier-f5cf9cb87-9fdjd           1/1     Running   0          8m2s
logging-loki-querier-f5cf9cb87-fp9v5           1/1     Running   0          8m2s
logging-loki-query-frontend-58c579fcb7-lfvbc   1/1     Running   0          8m2s
logging-loki-query-frontend-58c579fcb7-tjf9k   1/1     Running   0          8m2s
logging-view-plugin-79448d8df6-ckgmx           1/1     Running   0          46s

12.2.3.

표 12.2.

12.2.3.1.

$ oc create secret generic logging-loki-aws \
  --from-literal=bucketnames="<bucket_name>" \
  --from-literal=endpoint="<aws_bucket_endpoint>" \
  --from-literal=access_key_id="<aws_access_key_id>" \
  --from-literal=access_key_secret="<aws_access_key_secret>" \
  --from-literal=region="<aws_region_of_your_bucket>"

12.2.3.1.1.

$ oc -n openshift-logging create secret generic "logging-loki-aws" \
--from-literal=bucketnames="<s3_bucket_name>" \
--from-literal=region="<bucket_region>" \
--from-literal=audience="<oidc_audience>" 1

1

12.2.3.2.

$ oc create secret generic logging-loki-azure \
  --from-literal=container="<azure_container_name>" \
  --from-literal=environment="<azure_environment>" \ 1
  --from-literal=account_name="<azure_account_name>" \
  --from-literal=account_key="<azure_account_key>"

1

12.2.3.2.1.

$ oc -n openshift-logging create secret generic logging-loki-azure \
--from-literal=environment="<azure_environment>" \
--from-literal=account_name="<storage_account_name>" \
--from-literal=container="<container_name>"

12.2.3.3.

$ oc create secret generic logging-loki-gcs \
  --from-literal=bucketname="<bucket_name>" \
  --from-file=key.json="<path/to/key.json>"

12.2.3.4.

$ oc create secret generic logging-loki-minio \
  --from-literal=bucketnames="<bucket_name>" \
  --from-literal=endpoint="<minio_bucket_endpoint>" \
  --from-literal=access_key_id="<minio_access_key_id>" \
  --from-literal=access_key_secret="<minio_access_key_secret>"

12.2.3.5.

apiVersion: objectbucket.io/v1alpha1
kind: ObjectBucketClaim
metadata:
  name: loki-bucket-odf
  namespace: openshift-logging
spec:
  generateBucketName: loki-bucket-odf
  storageClassName: openshift-storage.noobaa.io

BUCKET_HOST=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_HOST}')
BUCKET_NAME=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_NAME}')
BUCKET_PORT=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_PORT}')

ACCESS_KEY_ID=$(oc get -n openshift-logging secret loki-bucket-odf -o jsonpath='{.data.AWS_ACCESS_KEY_ID}' | base64 -d)
SECRET_ACCESS_KEY=$(oc get -n openshift-logging secret loki-bucket-odf -o jsonpath='{.data.AWS_SECRET_ACCESS_KEY}' | base64 -d)

$ oc create -n openshift-logging secret generic logging-loki-odf \
--from-literal=access_key_id="<access_key_id>" \
--from-literal=access_key_secret="<secret_access_key>" \
--from-literal=bucketnames="<bucket_name>" \
--from-literal=endpoint="https://<bucket_host>:<bucket_port>"

12.2.3.6.

$ oc create secret generic logging-loki-swift \
  --from-literal=auth_url="<swift_auth_url>" \
  --from-literal=username="<swift_usernameclaim>" \
  --from-literal=user_domain_name="<swift_user_domain_name>" \
  --from-literal=user_domain_id="<swift_user_domain_id>" \
  --from-literal=user_id="<swift_user_id>" \
  --from-literal=password="<swift_password>" \
  --from-literal=domain_id="<swift_domain_id>" \
  --from-literal=domain_name="<swift_domain_name>" \
  --from-literal=container_name="<swift_container_name>"

$ oc create secret generic logging-loki-swift \
  --from-literal=auth_url="<swift_auth_url>" \
  --from-literal=username="<swift_usernameclaim>" \
  --from-literal=user_domain_name="<swift_user_domain_name>" \
  --from-literal=user_domain_id="<swift_user_domain_id>" \
  --from-literal=user_id="<swift_user_id>" \
  --from-literal=password="<swift_password>" \
  --from-literal=domain_id="<swift_domain_id>" \
  --from-literal=domain_name="<swift_domain_name>" \
  --from-literal=container_name="<swift_container_name>" \
  --from-literal=project_id="<swift_project_id>" \
  --from-literal=project_name="<swift_project_name>" \
  --from-literal=project_domain_id="<swift_project_domain_id>" \
  --from-literal=project_domain_name="<swift_project_domain_name>" \
  --from-literal=region="<swift_region>"

12.2.4.

참고

12.2.4.1.

참고

12.2.4.2.

참고

12.2.4.3.

참고

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

1
2

```
$ oc apply -f <filename>.yaml
```

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-operators-redhat
  namespace: openshift-operators-redhat 1
spec: {}

1

```
$ oc apply -f <filename>.yaml
```

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: elasticsearch-operator
  namespace: openshift-operators-redhat 1
spec:
  channel: stable-x.y 2
  installPlanApproval: Automatic 3
  source: redhat-operators 4
  sourceNamespace: openshift-marketplace
  name: elasticsearch-operator

1
2
3
4

참고

```
$ oc apply -f <filename>.yaml
```

```
$ oc get csv -n --all-namespaces
```

NAMESPACE                                          NAME                            DISPLAY                            VERSION          REPLACES                        PHASE
default                                            elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
kube-node-lease                                    elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
kube-public                                        elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
kube-system                                        elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
non-destructive-test                               elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
openshift-apiserver-operator                       elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
openshift-apiserver                                elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
...

12.2.5.

참고

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
2
3
4

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  managementState: Managed
  logStore:
    type: lokistack
    lokistack:
      name: logging-loki
# ...

```
$ oc apply -f <filename>.yaml
```

12.3.

12.3.1.

중요

```
$ oc adm groups new cluster-admin
```

$ oc adm groups add-users cluster-admin <username>

$ oc adm policy add-cluster-role-to-group cluster-admin cluster-admin

12.3.2.

12.3.3.

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    ingester:
      podAntiAffinity:
      # ...
        requiredDuringSchedulingIgnoredDuringExecution: 1
        - labelSelector:
            matchLabels: 2
              app.kubernetes.io/component: ingester
          topologyKey: kubernetes.io/hostname
# ...

1
2

12.3.4.

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
 name: logging-loki
 namespace: openshift-logging
spec:
 replicationFactor: 2 1
 replication:
   factor: 2 2
   zones:
   -  maxSkew: 1 3
      topologyKey: topology.kubernetes.io/zone 4

1
2
3
4

12.3.4.1.

주의

oc get pods --field-selector status.phase==Pending -n openshift-logging

NAME                           READY   STATUS    RESTARTS   AGE 1
logging-loki-index-gateway-1   0/1     Pending   0          17m
logging-loki-ingester-1        0/1     Pending   0          16m
logging-loki-ruler-1           0/1     Pending   0          16m

1

oc get pvc -o=json -n openshift-logging | jq '.items[] | select(.status.phase == "Pending") | .metadata.name' -r

storage-logging-loki-index-gateway-1
storage-logging-loki-ingester-1
wal-logging-loki-ingester-1
storage-logging-loki-ruler-1
wal-logging-loki-ruler-1

oc delete pvc __<pvc_name>__  -n openshift-logging

oc delete pod __<pod_name>__  -n openshift-logging

12.3.4.1.1.

oc patch pvc __<pvc_name>__ -p '{"metadata":{"finalizers":null}}' -n openshift-logging

12.3.5.

참고

12.3.5.1.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: logging-all-application-logs-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-logging-application-view 1
subjects: 2
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

1
2

12.3.5.2.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: allow-read-logs
  namespace: log-test-0 1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-logging-application-view
subjects:
- kind: User
  apiGroup: rbac.authorization.k8s.io
  name: testuser-0

1

12.3.5.3.

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  tenants:
    mode: openshift-logging 1
    openshift:
      adminGroups: 2
      - cluster-admin
      - custom-admin-group 3

1
2
3

12.3.6.

중요

참고

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
   global: 1
      retention: 2
        days: 20
        streams:
        - days: 4
          priority: 1
          selector: '{kubernetes_namespace_name=~"test.+"}' 3
        - days: 1
          priority: 1
          selector: '{log_type="infrastructure"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v11
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging

1
2
3

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      retention:
        days: 20
    tenants: 1
      application:
        retention:
          days: 1
          streams:
            - days: 4
              selector: '{kubernetes_namespace_name=~"test.+"}' 2
      infrastructure:
        retention:
          days: 5
          streams:
            - days: 1
              selector: '{kubernetes_namespace_name=~"openshift-cluster.+"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v11
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging

1
2

$ oc apply -f <filename>.yaml

12.3.7.

중요

"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\"}"]]}]}

429 Too Many Requests Ingestion rate limit exceeded

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

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"

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

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
2

12.3.8.

$ oc patch LokiStack logging-loki -n openshift-logging  --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP","type": "memberlist"}}}}'

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  hashRing:
    type: memberlist
    memberlist:
      instanceAddrType: podIP
# ...

12.3.9.

12.4.

12.4.1.

참고

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
2
3
4

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  managementState: Managed
  logStore:
    type: lokistack
    lokistack:
      name: logging-loki
# ...

```
$ oc apply -f <filename>.yaml
```

12.4.2.

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  pipelines: 1
  - name: all-to-default
    inputRefs:
    - infrastructure
    - application
    - audit
    outputRefs:
    - default

1

참고

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
   - name: elasticsearch-insecure
     type: "elasticsearch"
     url: http://elasticsearch-insecure.messaging.svc.cluster.local
     insecure: true
   - name: elasticsearch-secure
     type: "elasticsearch"
     url: https://elasticsearch-secure.messaging.svc.cluster.local
     secret:
       name: es-audit
   - name: secureforward-offcluster
     type: "fluentdForward"
     url: https://secureforward.offcluster.com:24224
     secret:
       name: secureforward
  pipelines:
   - name: container-logs
     inputRefs:
     - application
     outputRefs:
     - secureforward-offcluster
   - name: infra-logs
     inputRefs:
     - infrastructure
     outputRefs:
     - elasticsearch-insecure
   - name: audit-logs
     inputRefs:
     - audit
     outputRefs:
     - elasticsearch-secure
     - default 1

1

12.4.3.

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
...
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    retentionPolicy: 1
      application:
        maxAge: 1d
      infra:
        maxAge: 7d
      audit:
        maxAge: 7d
    elasticsearch:
      nodeCount: 3
...

1

apiVersion: "logging.openshift.io/v1"
kind: "Elasticsearch"
metadata:
  name: "elasticsearch"
spec:
...
  indexManagement:
    policies: 1
      - name: infra-policy
        phases:
          delete:
            minAge: 7d 2
          hot:
            actions:
              rollover:
                maxAge: 8h 3
        pollInterval: 15m 4
...

1
2
3
4

참고

$ oc get cronjob

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

12.4.4.

참고

$ oc edit ClusterLogging instance

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
....
spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:1
        resources:
          limits: 2
            memory: "32Gi"
          requests: 3
            cpu: "1"
            memory: "16Gi"
        proxy: 4
          resources:
            limits:
              memory: 100Mi
            requests:
              memory: 100Mi

1
2
3
4

      resources:
        limits: 1
          memory: "32Gi"
        requests: 2
          cpu: "8"
          memory: "32Gi"

1
2

12.4.5.

$ oc edit clusterlogging instance

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"

....

spec:
  logStore:
    type: "elasticsearch"
    elasticsearch:
      redundancyPolicy: "SingleRedundancy" 1

1

참고

12.4.6.

참고

12.4.7.

주의

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
# ...
spec:
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 3
      storage:
        storageClassName: "gp2"
        size: "200G"

참고

12.4.8.

참고

 spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage: {}

12.4.9.

```
$ oc project openshift-logging
```

$ oc get pods -l component=elasticsearch

$ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "false"}}}}}'

$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_flush/synced" -XPOST

$ oc exec -c elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6  -c elasticsearch -- es_util --query="_flush/synced" -XPOST

{"_shards":{"total":4,"successful":4,"failed":0},".security":{"total":2,"successful":2,"failed":0},".kibana_1":{"total":2,"successful":2,"failed":0}}

$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'

$ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'

{"acknowledged":true,"persistent":{"cluster":{"routing":{"allocation":{"enable":"primaries"}}}},"transient":

$ oc rollout resume deployment/<deployment-name>

$ oc rollout resume deployment/elasticsearch-cdm-0-1

deployment.extensions/elasticsearch-cdm-0-1 resumed

$ oc get pods -l component=elasticsearch-

NAME                                            READY   STATUS    RESTARTS   AGE
elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6k    2/2     Running   0          22h
elasticsearch-cdm-5ceex6ts-2-f799564cb-l9mj7    2/2     Running   0          22h
elasticsearch-cdm-5ceex6ts-3-585968dc68-k7kjr   2/2     Running   0          22h

$ oc rollout pause deployment/<deployment-name>

$ oc rollout pause deployment/elasticsearch-cdm-0-1

deployment.extensions/elasticsearch-cdm-0-1 paused

$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/health?pretty=true

참고

$ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/health?pretty=true

{
  "cluster_name" : "elasticsearch",
  "status" : "yellow", 1
  "timed_out" : false,
  "number_of_nodes" : 3,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 8,
  "active_shards" : 16,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 1,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}

1

$ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'

$ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'

{
  "acknowledged" : true,
  "persistent" : { },
  "transient" : {
    "cluster" : {
      "routing" : {
        "allocation" : {
          "enable" : "all"
        }
      }
    }
  }
}

$ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "true"}}}}}'

12.4.10.

$ oc get service elasticsearch -o jsonpath={.spec.clusterIP} -n openshift-logging

172.30.183.229

$ oc get service elasticsearch -n openshift-logging

NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
elasticsearch   ClusterIP   172.30.183.229   <none>        9200/TCP   22h

$ oc exec elasticsearch-cdm-oplnhinv-1-5746475887-fj2f8 -n openshift-logging -- curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://172.30.183.229:9200/_cat/health"

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    29  100    29    0     0    108      0 --:--:-- --:--:-- --:--:--   108

```
$ oc project openshift-logging
```

$ oc extract secret/elasticsearch --to=. --keys=admin-ca

admin-ca

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: elasticsearch
  namespace: openshift-logging
spec:
  host:
  to:
    kind: Service
    name: elasticsearch
  tls:
    termination: reencrypt
    destinationCACertificate: | 1

1

$ cat ./admin-ca | sed -e "s/^/      /" >> <file-name>.yaml

$ oc create -f <file-name>.yaml

route.route.openshift.io/elasticsearch created

```
$ token=$(oc whoami -t)
```

$ routeES=`oc get route elasticsearch -o jsonpath={.spec.host}`

curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://${routeES}"

{
  "name" : "elasticsearch-cdm-i40ktba0-1",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "0eY-tJzcR3KOdpgeMJo-MQ",
  "version" : {
  "number" : "6.8.1",
  "build_flavor" : "oss",
  "build_type" : "zip",
  "build_hash" : "Unknown",
  "build_date" : "Unknown",
  "build_snapshot" : true,
  "lucene_version" : "7.7.0",
  "minimum_wire_compatibility_version" : "5.6.0",
  "minimum_index_compatibility_version" : "5.0.0"
},
  "<tagline>" : "<for search>"
}

12.4.11.

```
outputRefs:
- default
```

주의

```
$ oc edit ClusterLogging instance
```

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  collection:
    type: "fluentd"
    fluentd: {}

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

13장.

13.1.

13.1.1.

참고

13.1.2.

13.1.3.

표 13.1.

13.1.4.

표 13.2.

13.1.5.

표 13.3.

13.1.6.

13.2.

13.2.1.

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: <name>
  namespace: <namespace>
spec:
# ...
  rules:
    enabled: true 1
    selector:
      matchLabels:
        openshift.io/<label_name>: "true" 2
    namespaceSelector:
      matchLabels:
        openshift.io/<label_name>: "true" 3

1
2
3

13.2.2.

13.2.2.1.

$ oc adm policy add-role-to-user alertingrules.loki.grafana.com-v1-admin -n <namespace> <username>

$ oc adm policy add-cluster-role-to-user alertingrules.loki.grafana.com-v1-admin <username>

13.2.3.

  apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: loki-operator-alerts
    namespace: openshift-operators-redhat 1
    labels: 2
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "infrastructure" 3
    groups:
      - name: LokiOperatorHighReconciliationError
        rules:
          - alert: HighPercentageError
            expr: | 4
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"} |= "error" [1m])) by (job)
                /
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"}[1m])) by (job)
                > 0.01
            for: 10s
            labels:
              severity: critical 5
            annotations:
              summary: High Loki Operator Reconciliation Errors 6
              description: High Loki Operator Reconciliation Errors 7

1
2
3
4
5
6
7

  apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: app-user-workload
    namespace: app-ns 1
    labels: 2
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "application"
    groups:
      - name: AppUserWorkloadHighError
        rules:
          - alert:
            expr: | 3
            sum(rate({kubernetes_namespace_name="app-ns", kubernetes_pod_name=~"podName.*"} |= "error" [1m])) by (job)
            for: 10s
            labels:
              severity: critical 4
            annotations:
              summary:  5
              description:  6

1
2
3
4
5
6

```
$ oc apply -f <filename>.yaml
```

13.2.4.

14장.

14.1.

14.1.1.

14.1.2.

14.1.3.

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
# ...
  outputs:
    - name: kafka-example 1
      type: kafka 2
      limit:
        maxRecordsPerSecond: 1000000 3
# ...

1
2
3

```
$ oc apply -f <filename>.yaml
```

14.1.4.

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
# ...
  inputs:
    - name: <input_name> 1
      application:
        selector:
          matchLabels: { example: label } 2
        containerLimit:
          maxRecordsPerSecond: 0 3
# ...

1
2
3

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
# ...
  inputs:
    - name: <input_name> 1
      application:
        namespaces: [ example-ns-1, example-ns-2 ] 2
        containerLimit:
          maxRecordsPerSecond: 10 3
    - name: <input_name>
      application:
        namespaces: [ test ]
        containerLimit:
          maxRecordsPerSecond: 1000
# ...

1
2
3

```
$ oc apply -f <filename>.yaml
```

14.2.

참고

14.2.1.

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  filters:
  - name: <filter_name>
    type: drop 1
    drop: 2
    - test: 3
      - field: .kubernetes.labels."foo-bar/baz" 4
        matches: .+ 5
      - field: .kubernetes.pod_name
        notMatches: "my-pod" 6
  pipelines:
  - name: <pipeline_name> 7
    filterRefs: ["<filter_name>"]
# ...

```
$ oc apply -f <filename>.yaml
```

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  filters:
  - name: important
    type: drop
    drop:
      test:
      - field: .message
        notMatches: "(?i)critical|error"
      - field: .level
        matches: "info|warning"
# ...

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  filters:
  - name: important
    type: drop
    drop:
      test:
      - field: .kubernetes.namespace_name
        matches: "^open"
      test:
      - field: .log_type
        matches: "application"
      - field: .kubernetes.pod_name
        notMatches: "my-pod"
# ...

14.2.2.

중요

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  filters:
  - name: <filter_name>
    type: prune 1
    prune: 2
      in: [.kubernetes.annotations, .kubernetes.namespace_id] 3
      notIn: [.kubernetes,.log_type,.message,."@timestamp"] 4
  pipelines:
  - name: <pipeline_name> 5
    filterRefs: ["<filter_name>"]
# ...

1
2
3
4
5

```
$ oc apply -f <filename>.yaml
```

14.2.3.

14.3.

중요

참고

14.3.1.

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
# ...
spec:
  inputs:
    - name: mylogs
      application:
        includes:
          - namespace: "my-project" 1
            container: "my-container" 2
        excludes:
          - container: "other-container*" 3
            namespace: "other-namespace" 4
# ...

1
2
3
4

```
$ oc apply -f <filename>.yaml
```

14.3.2.

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
# ...
spec:
  inputs:
    - name: mylogs
      application:
        selector:
          matchExpressions:
          - key: env 1
            operator: In 2
            values: [“prod”, “qa”] 3
          - key: zone
            operator: NotIn
            values: [“east”, “west”]
          matchLabels: 4
            app: one
            name: app1
# ...

1
2
3
4

```
$ oc apply -f <filename>.yaml
```

14.3.3.

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
# ...
spec:
  inputs:
    - name: mylogs1
      infrastructure:
        sources: 1
          - node
    - name: mylogs2
      audit:
        sources: 2
          - kubeAPI
          - openshiftAPI
          - ovn
# ...

1

2

```
$ oc apply -f <filename>.yaml
```

15장.

15.1.

15.1.1.

중요

참고

kind: Node
apiVersion: v1
metadata:
  name: ip-10-0-131-14.ec2.internal
  selfLink: /api/v1/nodes/ip-10-0-131-14.ec2.internal
  uid: 7bc2580a-8b8e-11e9-8e01-021ab4174c74
  resourceVersion: '478704'
  creationTimestamp: '2019-06-10T14:46:08Z'
  labels:
    kubernetes.io/os: linux
    topology.kubernetes.io/zone: us-east-1a
    node.openshift.io/os_version: '4.5'
    node-role.kubernetes.io/worker: ''
    topology.kubernetes.io/region: us-east-1
    node.openshift.io/os_id: rhcos
    node.kubernetes.io/instance-type: m4.large
    kubernetes.io/hostname: ip-10-0-131-14
    kubernetes.io/arch: amd64
    region: east 1
    type: user-node
#...

1

apiVersion: v1
kind: Pod
metadata:
  name: s1
#...
spec:
  nodeSelector: 1
    region: east
    type: user-node
#...

1

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
#...
spec:
  defaultNodeSelector: type=user-node,region=east
#...

apiVersion: v1
kind: Node
metadata:
  name: ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4
#...
  labels:
    region: east
    type: user-node
#...

apiVersion: v1
kind: Pod
metadata:
  name: s1
#...
spec:
  nodeSelector:
    region: east
#...

NAME     READY   STATUS    RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
pod-s1   1/1     Running   0          20s   10.131.2.6   ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4   <none>           <none>

참고

apiVersion: v1
kind: Namespace
metadata:
  name: east-region
  annotations:
    openshift.io/node-selector: "region=east"
#...

apiVersion: v1
kind: Node
metadata:
  name: ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4
#...
  labels:
    region: east
    type: user-node
#...

apiVersion: v1
kind: Pod
metadata:
  namespace: east-region
#...
spec:
  nodeSelector:
    region: east
    type: user-node
#...

NAME     READY   STATUS    RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
pod-s1   1/1     Running   0          20s   10.131.2.6   ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4   <none>           <none>

apiVersion: v1
kind: Pod
metadata:
  name: west-region
#...
spec:
  nodeSelector:
    region: west
#...

15.1.2.

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor: 1
      nodeSelector:
        node-role.kubernetes.io/infra: "" 2
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
# ...

1
2

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
# ...

$ oc explain lokistack.spec.template

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: template <Object>

DESCRIPTION:
     Template defines the resource/limits/tolerations/nodeselectors per
     component

FIELDS:
   compactor	<Object>
     Compactor defines the compaction component spec.

   distributor	<Object>
     Distributor defines the distributor component spec.
...

$ oc explain lokistack.spec.template.compactor

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: compactor <Object>

DESCRIPTION:
     Compactor defines the compaction component spec.

FIELDS:
   nodeSelector	<map[string]string>
     NodeSelector defines the labels required by a node to schedule the
     component onto it.
...

15.1.3.

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name:  <name> 1
  namespace: <namespace> 2
spec:
  managementState: "Managed"
  collection:
    type: "vector"
    tolerations:
    - key: "logging"
      operator: "Exists"
      effect: "NoExecute"
      tolerationSeconds: 6000
    resources:
      limits:
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 1Gi
    nodeSelector:
      collector: needed
# ...

1
2

```
$ oc apply -f <filename>.yaml
```

15.1.4.

$ oc get pods --selector component=collector -o wide -n <project_name>

NAME           READY  STATUS    RESTARTS   AGE     IP            NODE                  NOMINATED NODE   READINESS GATES
collector-8d69v  1/1    Running   0          134m    10.130.2.30   master1.example.com   <none>           <none>
collector-bd225  1/1    Running   0          134m    10.131.1.11   master2.example.com   <none>           <none>
collector-cvrzs  1/1    Running   0          134m    10.130.0.21   master3.example.com   <none>           <none>
collector-gpqg2  1/1    Running   0          134m    10.128.2.27   worker1.example.com   <none>           <none>
collector-l9j7j  1/1    Running   0          134m    10.129.2.31   worker2.example.com   <none>           <none>

15.1.5.

15.2.

15.2.1.

apiVersion: v1
kind: Node
metadata:
  name: my-node
#...
spec:
  taints:
  - effect: NoExecute
    key: key1
    value: value1
#...

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
#...
spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoExecute"
    tolerationSeconds: 3600
#...

표 15.1.

apiVersion: v1
kind: Node
metadata:
  annotations:
    machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
    machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
  name: my-node
#...
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
#...

중요

15.2.2.

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor: 1
      nodeSelector:
        node-role.kubernetes.io/infra: "" 2
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
# ...

1
2

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
# ...

$ oc explain lokistack.spec.template

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: template <Object>

DESCRIPTION:
     Template defines the resource/limits/tolerations/nodeselectors per
     component

FIELDS:
   compactor	<Object>
     Compactor defines the compaction component spec.

   distributor	<Object>
     Distributor defines the distributor component spec.
...

$ oc explain lokistack.spec.template.compactor

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: compactor <Object>

DESCRIPTION:
     Compactor defines the compaction component spec.

FIELDS:
   nodeSelector	<map[string]string>
     NodeSelector defines the labels required by a node to schedule the
     component onto it.
...

15.2.3.

apiVersion: v1
kind: Pod
metadata:
  name: collector-example
  namespace: openshift-logging
spec:
# ...
  collection:
    type: vector
    tolerations:
    - effect: NoSchedule
      key: node-role.kubernetes.io/master
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/disk-pressure
      operator: Exists
    - effect: NoExecute
      key: node.kubernetes.io/not-ready
      operator: Exists
    - effect: NoExecute
      key: node.kubernetes.io/unreachable
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/memory-pressure
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/pid-pressure
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/unschedulable
      operator: Exists
# ...

$ oc adm taint nodes <node_name> <key>=<value>:<effect>

$ oc adm taint nodes node1 collector=node:NoExecute

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
# ...
spec:
# ...
  collection:
    type: vector
    tolerations:
    - key: collector 1
      operator: Exists 2
      effect: NoExecute 3
      tolerationSeconds: 6000 4
    resources:
      limits:
        memory: 2Gi
      requests:
        cpu: 100m
        memory: 1Gi
# ...

1
2
3
4

15.2.4.

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name:  <name> 1
  namespace: <namespace> 2
spec:
  managementState: "Managed"
  collection:
    type: "vector"
    tolerations:
    - key: "logging"
      operator: "Exists"
      effect: "NoExecute"
      tolerationSeconds: 6000
    resources:
      limits:
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 1Gi
    nodeSelector:
      collector: needed
# ...

1
2

```
$ oc apply -f <filename>.yaml
```

15.2.5.

$ oc get pods --selector component=collector -o wide -n <project_name>

NAME           READY  STATUS    RESTARTS   AGE     IP            NODE                  NOMINATED NODE   READINESS GATES
collector-8d69v  1/1    Running   0          134m    10.130.2.30   master1.example.com   <none>           <none>
collector-bd225  1/1    Running   0          134m    10.131.1.11   master2.example.com   <none>           <none>
collector-cvrzs  1/1    Running   0          134m    10.130.0.21   master3.example.com   <none>           <none>
collector-gpqg2  1/1    Running   0          134m    10.128.2.27   worker1.example.com   <none>           <none>
collector-l9j7j  1/1    Running   0          134m    10.129.2.31   worker2.example.com   <none>           <none>

15.2.6.

16장.

16.1.

주의
주의

16.2.

16.3.

중요

16.4.

중요

16.5.

$ oc get subscription.operators.coreos.com serverless-operator -n openshift-serverless -o yaml | grep currentCSV

  currentCSV: serverless-operator.v1.28.0

$ oc delete subscription.operators.coreos.com serverless-operator -n openshift-serverless

subscription.operators.coreos.com "serverless-operator" deleted

$ oc delete clusterserviceversion serverless-operator.v1.28.0 -n openshift-serverless

clusterserviceversion.operators.coreos.com "serverless-operator.v1.28.0" deleted

17장.

18장.

19장.

19.1.

19.2.

19.3.

19.4.

19.5.

19.6.

19.7.

19.8.

19.9.

19.9.1.

19.9.2.

19.9.2.1.

19.9.2.2.

19.9.2.3.

19.9.2.4.

19.9.2.5.

19.9.3.

19.9.3.1.

19.9.3.2.

19.9.3.3.

19.9.3.4.

19.9.3.5.

19.9.3.6.

19.9.4.

19.9.5.

19.9.6.

19.9.7.

19.9.8.

20장.

20.1.

21장.

21.1.

21.1.1.

21.1.1.1.

21.1.1.1.1.

21.1.1.1.1.1.

21.1.1.1.1.1.1.

21.1.1.1.2.

21.1.1.1.2.1.

21.1.1.1.2.1.1.

21.1.1.1.3.

21.1.1.1.3.1.

21.1.1.1.3.1.1.

21.1.1.1.4.

21.1.1.1.4.1.

21.1.1.1.4.1.1.

21.1.1.1.5.

21.1.1.1.5.1.

21.1.1.1.5.1.1.

21.1.1.1.6.

21.1.1.1.6.1.

21.1.1.1.6.1.1.

21.1.1.1.7.

21.1.1.1.7.1.

21.1.1.1.7.1.1.

21.1.1.1.8.

21.1.1.1.8.1.

21.1.1.1.8.1.1.

21.1.1.1.9.

21.1.1.1.9.1.

21.1.1.1.9.1.1.

21.1.1.1.10.

21.1.1.1.10.1.

21.1.1.1.10.1.1.

21.1.1.1.11.

21.1.1.1.11.1.

21.1.1.1.11.1.1.

21.1.1.1.12.

21.1.1.1.12.1.

21.1.1.1.12.1.1.

21.1.1.1.13.

21.1.1.1.13.1.

21.1.1.1.13.1.1.

21.1.1.1.14.

21.1.1.1.14.1.

21.1.1.1.14.1.1.

21.1.1.1.15.

21.1.1.1.15.1.

21.1.1.1.15.1.1.

21.1.1.1.16.

21.1.1.1.16.1.

21.1.1.1.16.1.1.

21.1.1.1.17.

21.1.1.1.17.1.

21.1.1.1.17.1.1.

21.1.1.1.18.

21.1.1.1.18.1.

21.1.1.1.18.1.1.

21.1.1.1.19.

21.1.1.1.19.1.

21.1.1.1.19.1.1.

21.1.1.1.20.

21.1.1.1.20.1.

21.1.1.1.20.1.1.

21.1.1.1.21.

21.1.1.1.21.1.

21.1.1.1.21.1.1.

21.1.1.1.22.

21.1.1.1.22.1.

21.1.1.1.22.1.1.

21.1.1.1.23.

21.1.1.1.23.1.

21.1.1.1.23.1.1.

21.1.1.1.24.

21.1.1.1.24.1.

21.1.1.1.24.1.1.

21.1.1.1.25.

21.1.1.1.25.1.

21.1.1.1.25.1.1.

21.1.1.1.26.

21.1.1.1.26.1.

21.1.1.1.26.1.1.

21.1.1.1.27.

21.1.1.1.27.1.

21.1.1.1.27.1.1.

21.1.1.1.28.

21.1.1.1.28.1.

21.1.1.1.28.1.1.

21.1.1.1.29.

21.1.1.1.29.1.

21.1.1.1.29.1.1.

21.1.1.1.30.

21.1.1.1.30.1.

21.1.1.1.30.1.1.

21.1.1.1.31.

21.1.1.1.31.1.

21.1.1.1.31.1.1.

21.1.1.1.32.

21.1.1.1.32.1.

21.1.1.1.32.1.1.

21.1.1.1.33.

21.1.1.1.33.1.

21.1.1.1.33.1.1.

21.1.1.1.34.

21.1.1.1.34.1.

21.1.1.1.34.1.1.

21.1.1.1.35.

21.1.1.1.35.1.

21.1.1.1.35.1.1.

21.1.1.1.36.

21.1.1.1.36.1.

21.1.1.1.36.1.1.

21.1.1.1.37.

21.1.1.1.37.1.

21.1.1.1.37.1.1.

21.1.1.1.38.

21.1.1.1.38.1.

21.1.1.1.38.1.1.

21.1.1.1.39.

21.1.1.1.39.1.

21.1.1.1.39.1.1.

21.1.1.1.40.

21.1.1.1.40.1.

21.1.1.1.40.1.1.

21.1.1.1.41.

21.1.1.1.41.1.

21.1.1.1.41.1.1.

21.1.1.1.42.

21.1.1.1.42.1.

21.1.1.1.42.1.1.

21.1.1.1.43.

21.1.1.1.43.1.

21.1.1.1.43.1.1.

21.1.1.1.44.

21.1.1.1.44.1.

21.1.1.1.44.1.1.

21.1.1.1.45.

21.1.1.1.45.1.

21.1.1.1.45.1.1.

21.1.1.1.46.

21.1.1.1.46.1.

21.1.1.1.46.1.1.

21.1.1.1.47.

21.1.1.1.47.1.

21.1.1.1.47.1.1.

21.1.1.1.48.

21.1.1.1.48.1.

21.1.1.1.48.1.1.

21.1.1.1.49.

21.1.1.1.49.1.

21.1.1.1.49.1.1.

21.1.1.1.50.

21.1.1.1.50.1.

21.1.1.1.50.1.1.

21.1.1.1.51.

21.1.1.1.51.1.

21.1.1.1.51.1.1.

21.1.1.1.52.

21.1.1.1.52.1.

21.1.1.1.52.1.1.

21.1.1.1.53.

21.1.1.1.53.1.

21.1.1.1.53.1.1.

21.1.1.1.54.

21.1.1.1.54.1.

21.1.1.1.54.1.1.

21.1.1.1.55.

21.1.1.1.55.1.

21.1.1.1.55.1.1.

21.1.1.1.56.

21.1.1.1.56.1.

21.1.1.1.56.1.1.

21.1.1.1.57.

21.1.1.1.57.1.

21.1.1.1.57.1.1.

21.1.1.1.58.

21.1.1.1.58.1.

21.1.1.1.58.1.1.

21.1.1.1.59.

21.1.1.1.59.1.

21.1.1.1.59.1.1.

21.1.1.1.60.

21.1.1.1.60.1.

21.1.1.1.60.1.1.

21.1.1.1.61.

21.1.1.1.61.1.

21.1.1.1.61.1.1.

21.1.1.1.62.

21.1.1.1.62.1.

21.1.1.1.62.1.1.

21.1.1.1.63.

21.1.1.1.63.1.

21.1.1.1.63.1.1.

21.1.1.1.64.

21.1.1.1.64.1.

21.1.1.1.64.1.1.

21.1.1.1.65.

21.1.1.1.65.1.

21.1.1.1.65.1.1.

21.1.1.1.66.

21.1.1.1.66.1.

21.1.1.1.66.1.1.

21.1.1.1.67.

21.1.1.1.67.1.

21.1.1.1.67.1.1.

21.1.1.1.68.

21.1.1.1.68.1.

21.1.1.1.68.1.1.

21.1.1.1.69.

21.1.1.1.69.1.

21.1.1.1.69.1.1.

21.1.1.1.70.

21.1.1.1.70.1.

21.1.1.1.70.1.1.

21.1.1.1.71.

21.1.1.1.71.1.

21.1.1.1.71.1.1.

21.1.1.1.72.

21.1.1.1.72.1.

21.1.1.1.72.1.1.

21.1.1.1.73.

21.1.1.1.73.1.

21.1.1.1.73.1.1.

21.1.1.1.74.

21.1.1.1.74.1.

21.1.1.1.74.1.1.

21.1.1.1.75.

21.1.1.1.75.1.

21.1.1.1.75.1.1.

21.1.1.1.76.

21.1.1.1.76.1.

21.1.1.1.76.1.1.

21.1.1.1.77.

21.1.1.1.77.1.

21.1.1.1.77.1.1.

21.1.1.1.78.

21.1.1.1.78.1.

21.1.1.1.78.1.1.

21.1.1.1.79.

21.1.1.1.79.1.

21.1.1.1.79.1.1.

21.1.1.1.80.

21.1.1.1.80.1.

21.1.1.1.80.1.1.

21.1.1.1.81.

21.1.1.1.81.1.

21.1.1.1.81.1.1.

21.1.1.1.82.

21.1.1.1.82.1.

21.1.1.1.82.1.1.

21.1.1.1.83.

21.1.1.1.83.1.

21.1.1.1.83.1.1.

21.1.1.1.84.

21.1.1.1.84.1.

21.1.1.1.84.1.1.

21.1.1.1.85.

21.1.1.1.85.1.

21.1.1.1.85.1.1.

21.1.1.1.86.

21.1.1.1.86.1.

21.1.1.1.86.1.1.

21.1.1.1.87.

21.1.1.1.87.1.

21.1.1.1.87.1.1.

21.1.1.1.88.

21.1.1.1.88.1.

21.1.1.1.88.1.1.

21.1.1.1.89.

21.1.1.1.89.1.

21.1.1.1.89.1.1.

21.1.1.1.90.

21.1.1.1.90.1.

21.1.1.1.90.1.1.

21.1.1.1.91.

21.1.1.1.91.1.

21.1.1.1.91.1.1.

21.1.1.1.92.

21.1.1.1.92.1.

21.1.1.1.92.1.1.

21.1.1.1.93.

21.1.1.1.93.1.

21.1.1.1.93.1.1.

21.1.1.1.94.

21.1.1.1.94.1.

21.1.1.1.94.1.1.

21.1.1.1.95.

21.1.1.1.95.1.

21.1.1.1.95.1.1.

21.1.1.1.96.

21.1.1.1.96.1.

21.1.1.1.96.1.1.

21.1.1.1.97.

21.1.1.1.97.1.

21.1.1.1.97.1.1.

21.1.1.1.98.

21.1.1.1.98.1.

21.1.1.1.98.1.1.

21.1.1.1.99.

21.1.1.1.99.1.

21.1.1.1.99.1.1.

21.1.1.1.100.

21.1.1.1.100.1.

21.1.1.1.100.1.1.

21.1.1.1.101.

21.1.1.1.101.1.

21.1.1.1.101.1.1.

21.1.1.1.102.

21.1.1.1.102.1.

21.1.1.1.102.1.1.

21.1.1.1.103.

21.1.1.1.103.1.

21.1.1.1.103.1.1.

21.1.1.1.104.

21.1.1.1.104.1.

21.1.1.1.104.1.1.

21.1.1.1.105.

21.1.1.1.105.1.

21.1.1.1.105.1.1.

21.1.1.1.106.

21.1.1.1.106.1.

21.1.1.1.106.1.1.

21.1.1.1.107.

21.1.1.1.107.1.

21.1.1.1.107.1.1.

21.1.1.1.108.

21.1.1.1.108.1.

21.1.1.1.108.1.1.

22장.

Legal Notice

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

로깅

OpenShift Container Platform에서 로깅 구성 및 사용

1장. 릴리스 노트

1.1. Logging 5.9

1.1.1. 로깅 5.9.9

1.1.1.1. 버그 수정

1.1.1.2. CVE

1.1.2. 로깅 5.9.8

1.1.2.1. 버그 수정

1.1.2.2. CVE

1.1.3. 로깅 5.9.7

1.1.3.1. 버그 수정

1.1.3.2. CVE

1.1.4. 로깅 5.9.6

1.1.4.1. 버그 수정

1.1.4.2. CVE

1.1.5. 로깅 5.9.5

1.1.5.1. 버그 수정

1.1.5.2. CVE

1.1.6. Logging 5.9.4

1.1.6.1. 버그 수정

1.1.6.2. CVE

1.1.7. Logging 5.9.3

1.1.7.1. 버그 수정

1.1.7.2. CVE

1.1.8. Logging 5.9.2

1.1.8.1. 버그 수정

1.1.8.2. CVE

1.1.9. Logging 5.9.1

1.1.9.1. 기능 개선

1.1.9.2. 버그 수정

1.1.9.3. CVE

1.1.10. Logging 5.9.0

1.1.10.1. 제거 알림

1.1.10.2. 사용 중단 알림

1.1.10.3. 기능 개선

1.1.10.3.1. 로그 컬렉션

1.1.10.3.2. 로그 스토리지

1.1.10.4. 버그 수정

1.1.10.5. 확인된 문제

1.1.10.6. CVE

2장. 로깅 6.0

2.1. 릴리스 노트

2.1.1. 로깅 6.0.2

2.1.1.1. 버그 수정

2.1.1.2. CVE

2.1.2. 로깅 6.0.1

2.1.2.1. 버그 수정

2.1.2.2. CVE

2.1.3. 로깅 6.0.0

2.1.4. 제거 알림

2.1.5. 새로운 기능 및 개선 사항

2.1.6. 기술 프리뷰 기능

2.1.7. 버그 수정

2.1.8. CVE

2.2. 로깅 6.0

2.2.1. 입력 및 출력

2.2.2. 수신자 입력 유형

2.2.3. 파이프라인 및 필터

2.2.4. Operator 동작

2.2.5. 검증

2.2.5.1. 빠른 시작

2.3. Logging 6.0으로 업그레이드

2.3.1. oc explain 명령 사용

2.3.1.1. 리소스 설명

2.3.1.2. 계층 구조 구조

2.3.1.3. 유형 정보

2.3.1.4. 기본값

2.3.2. 로그 스토리지

2.3.3. 로그 시각화

2.3.4. 로그 수집 및 전달

2.3.5. 관리, 리소스 할당 및 워크로드 스케줄링

2.3.6. 입력 사양

2.3.6.1. 애플리케이션 입력

2.3.6.2. 입력 수신자

2.3.7. 출력 사양

2.3.8. 보안 및 TLS 구성

2.3.9. Red Hat Managed Elasticsearch

2.3.10. Red Hat Managed LokiStack

2.3.11. 필터 및 파이프라인 구성

2.3.1. `oc explain` 명령 사용