10.5. 로깅 수집기 구성
Red Hat OpenShift의 로깅은 클러스터에서 작업 및 애플리케이션 로그를 수집하고 Kubernetes Pod 및 프로젝트 메타데이터로 데이터를 강화합니다. ClusterLogging
사용자 정의 리소스(CR)의 spec.collection
스탠자를 통해 로그 수집기에 대한 지원되는 모든 수정을 수행할 수 있습니다.
10.5.1. 로그 수집기 구성
ClusterLogging
사용자 정의 리소스(CR)를 수정하여 로깅에서 사용하는 로그 수집기 유형을 구성할 수 있습니다.
Fluentd는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않습니다. Fluentd 대신 Vector를 사용할 수 있습니다.
사전 요구 사항
- 관리자 권한이 있습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. - Red Hat OpenShift Logging Operator가 설치되어 있습니다.
-
ClusterLogging
CR을 생성했습니다.
절차
ClusterLogging
CR컬렉션
사양을 수정합니다.ClusterLogging
CR 예apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: # ... spec: # ... collection: type: <log_collector_type> 1 resources: {} tolerations: {} # ...
- 1
- 로깅에 사용할 로그 수집기 유형입니다.
벡터
또는fluentd
일 수 있습니다.
다음 명령을 실행하여
ClusterLogging
CR을 적용합니다.$ oc apply -f <filename>.yaml
10.5.2. LogFileMetricExporter 리소스 생성
로깅 버전 5.8 이상 버전에서는 LogFileMetricExporter는 기본적으로 수집기와 함께 더 이상 배포되지 않습니다. 컨테이너를 실행하여 생성된 로그에서 메트릭을 생성하려면 LogFileMetricExporter
CR(사용자 정의 리소스)을 수동으로 생성해야 합니다.
LogFileMetricExporter
CR을 생성하지 않으면 OpenShift Dedicated 웹 콘솔 대시보드에 Produced Logs 의 No datapoints found 메시지가 표시될 수 있습니다.
사전 요구 사항
- 관리자 권한이 있습니다.
- Red Hat OpenShift Logging Operator가 설치되어 있습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다.
절차
LogFileMetricExporter
CR을 YAML 파일로 생성합니다.LogFileMetricExporter
CR 예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 # ...
다음 명령을 실행하여
LogFileMetricExporter
CR을 적용합니다.$ oc apply -f <filename>.yaml
검증
logfilesmetricexporter
Pod는 각 노드에서 수집기
Pod를 사용하여 동시에 실행됩니다.
다음 명령을 실행하고 출력을 관찰하여
LogFileMetricExporter
CR을 생성한 네임스페이스에서logfilesmetricexporter
Pod가 실행되고 있는지 확인합니다.$ 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
10.5.3. 로그 수집기 CPU 및 메모리 제한 구성
로그 수집기는 CPU 및 메모리 제한을 모두 조정할 수 있습니다.
절차
openshift-logging
프로젝트에서ClusterLogging
사용자 정의 리소스(CR)를 편집합니다.$ 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
- 필요에 따라 CPU 및 메모리 제한 및 요청을 지정합니다. 표시된 값이 기본값입니다.
10.5.4. 입력 수신자 구성
Red Hat OpenShift Logging Operator는 구성된 각 입력 수신자에 대한 서비스를 배포하여 클라이언트가 컬렉터에 쓸 수 있도록 합니다. 이 서비스는 입력 수신자에 지정된 포트를 노출합니다. 서비스 이름은 다음을 기반으로 생성됩니다.
-
다중 로그 전달자
ClusterLogForwarder
CR 배포의 경우 서비스 이름은 <ClusterLogForwarder_CR_name>-<input_name
> 형식으로 되어 있습니다. 예:example-http-receiver
. -
레거시
ClusterLogForwarder
CR 배포의 경우 이름이instance
이고openshift-logging
네임스페이스에 있는 서비스 이름은collector-<input_name> 형식으로 되어 있습니다
. 예:collector-http-receiver
.
10.5.4.1. 감사 로그를 HTTP 서버로 수신하도록 수집기 구성
ClusterLogForwarder
사용자 정의 리소스(CR)에서 http
를 수신자 입력으로 지정하여 HTTP 연결을 수신하고 감사 로그를 HTTP 서버로 수신하도록 로그 수집기를 구성할 수 있습니다. 이를 통해 OpenShift Dedicated 클러스터 내부 및 외부에서 수집된 감사 로그에 공통 로그 저장소를 사용할 수 있습니다.
사전 요구 사항
- 관리자 권한이 있습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. - Red Hat OpenShift Logging Operator가 설치되어 있습니다.
-
ClusterLogForwarder
CR을 생성했습니다.
절차
http
수신자 입력 구성을 추가하도록ClusterLogForwarder
CR을 수정합니다.다중 로그 전달자 배포를 사용하는 경우
ClusterLogForwarder
CR의 예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 # ...
레거시 배포를 사용하는 경우
ClusterLogForwarder
CR의 예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 # ...
다음 명령을 실행하여
ClusterLogForwarder
CR에 변경 사항을 적용합니다.$ oc apply -f <filename>.yaml
추가 리소스
10.5.5. Fluentd 로그 전달자를 위한 고급 구성
Fluentd는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않습니다. Fluentd 대신 Vector를 사용할 수 있습니다.
로깅에는 Fluentd 로그 전달자의 성능을 조정하는 데 사용할 수 있는 여러 Fluentd 매개변수가 포함됩니다. 이러한 매개변수를 사용하여 다음 Fluentd 동작을 변경할 수 있습니다.
- 청크 및 청크 버퍼 크기
- 청크 플러시 동작
- 청크 전달 재시도 동작
Fluentd는 청크라는 단일 blob에서 로그 데이터를 수집합니다. Fluentd가 청크를 생성할 때 청크는 스테이지에 있는 것으로 간주되어 청크가 데이터로 채워집니다. 청크가 가득 차면 Fluentd는 청크를 큐로 이동합니다. 여기서 청크는 플러시되기 전에 보관되거나 대상에 기록됩니다. Fluentd는 네트워크 문제 또는 대상의 용량 문제와 같은 여러 가지 이유로 청크를 플러시하지 못할 수 있습니다. 청크를 플러시할 수 없는 경우 Fluentd는 구성된 대로 플러시를 다시 시도합니다.
기본적으로 OpenShift Dedicated에서 Fluentd는 지수 백오프 방법을 사용하여 플러시를 다시 시도합니다. 여기서 Fluentd는 플러시 재시도 간격 간 대기 시간을 두 배로 늘리므로 대상에 대한 연결 요청을 줄이는 데 도움이 됩니다. 지수 백오프를 비활성화하고 대신 주기적 재시도 방법을 사용하여 지정된 간격으로 청크 플러시를 재시도 할 수 있습니다.
이러한 매개변수는 대기 시간과 처리량 간의 균형을 결정하는 데 도움이 될 수 있습니다.
- 처리량에 대해 Fluentd를 최적화하려면 이러한 매개변수를 사용하여 더 큰 버퍼 및 큐를 구성하고, 플러시를 지연하고, 재시도 간격을 더 길게 설정하여 네트워크 패킷 수를 줄일 수 있습니다. 버퍼가 클수록 노드 파일 시스템에 더 많은 공간이 필요합니다.
- 짧은 대기 시간을 최적화하기 위해 매개변수를 사용하여 데이터를 최대한 빨리 전송하고, 배치 누적을 방지하고, 큐와 버퍼를 더 짧게 만들고, 플러시 및 재시도를 더 자주 사용할 수 있습니다.
ClusterLogging
사용자 정의 리소스(CR)에서 다음 매개변수를 사용하여 청크 및 플러시 동작을 구성할 수 있습니다. 그러면 Fluentd에서 사용할 수 있도록 매개변수가 Fluentd 구성 맵에 자동으로 추가됩니다.
이러한 매개변수는 다음과 같습니다.
- 대부분의 사용자와 관련이 없습니다. 기본 설정은 좋은 일반 성능을 제공해야 합니다.
- Fluentd 구성 및 성능에 대한 자세한 지식이 있는 고급 사용자에게만 해당됩니다.
- 성능 튜닝 전용입니다. 로깅의 기능적 측면에는 영향을 미치지 않습니다.
매개변수 | 설명 | 기본 |
---|---|---|
| 각 청크의 최대 크기입니다. Fluentd는 이 크기에 도달하면 청크에 데이터 쓰기를 중지합니다. 그런 다음 Fluentd는 청크를 큐로 보내고 새 청크를 엽니다. |
|
| 스테이지와 큐의 총 크기인 버퍼의 최대 크기입니다. 버퍼 크기가 이 값을 초과하면 Fluentd는 청크로의 데이터 추가를 중지하고 오류와 함께 실패합니다. 청크에 없는 모든 데이터는 손실됩니다. | 모든 출력에 분산된 노드 디스크의 약 15%입니다. |
|
청크 플러시 간격입니다. |
|
| 플러시를 수행하는 방법:
|
|
| 청크 플러시를 수행하는 스레드 수입니다. 스레드 수를 늘리면 플러시 처리량이 향상되어 네트워크 대기 시간이 숨겨집니다. |
|
| 큐가 가득 찼을 때 청크 동작:
|
|
|
|
|
| 플러시 실패 시 재시도 방법:
|
|
| 레코드가 삭제되기 전에 재시도를 시도하는 최대 시간 간격입니다. |
|
| 다음 청크 플러시 전의 시간(초)입니다. |
|
Fluentd 청크 수명 주기에 대한 자세한 내용은 Fluentd 문서의 버퍼 플러그인을 참조하십시오.
절차
openshift-logging
프로젝트에서ClusterLogging
사용자 정의 리소스(CR)를 편집합니다.$ 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
lazy
,interval
또는immediate
등 청크 플러시를 수행할 방법을 지정합니다.- 4
- 청크 플러시에 사용할 스레드 수를 지정합니다.
- 5
throw_exception
,block
또는drop_oldest_chunk
등 큐가 가득 찼을 때의 청크 동작을 지정합니다.- 6
exponential_backoff
청크 플러시 방법의 최대 간격(초)을 지정합니다.- 7
- 청크 플러시 실패 시 재시도 유형을
exponential_backoff
또는periodic
으로 지정합니다. - 8
- 다음 청크 플러시 전 시간(초)을 지정합니다.
- 9
- 청크 버퍼의 최대 크기를 지정합니다.
Fluentd Pod가 재배포되었는지 확인합니다.
$ oc get pods -l component=collector -n openshift-logging
새 값이
fluentd
구성 맵에 있는지 확인합니다.$ oc extract configmap/collector-config --confirm
예: fluentd.conf
<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>