2.3. 로그 전달 구성
ClusterLogForwarder (CLF)를 사용하면 사용자가 다양한 대상으로 로그 전달을 구성할 수 있습니다. 다른 소스의 로그 메시지를 선택하고, 변환하거나 필터링할 수 있는 파이프라인을 통해 보내고, 하나 이상의 출력으로 전달할 수 있는 유연한 방법을 제공합니다.
ClusterLogForwarder의 주요 기능
- 입력을 사용하여 로그 메시지 선택
- 출력을 사용하여 외부 대상으로 로그를 전달
- 필터를 사용하여 로그 메시지를 필터링, 변환 및 삭제
- 입력, 필터 및 출력을 연결하는 로그 전달 파이프라인을 정의합니다.
2.3.1. 로그 컬렉션 설정
이 클러스터 로깅 릴리스에서는 관리자가 ClusterLogForwarder 와 연결된 서비스 계정에 로그 수집 권한을 명시적으로 부여해야 합니다. ClusterLogging 및 ClusterLogForwarder.logging.openshift.io 리소스로 구성된 레거시 로깅 시나리오의 이전 릴리스에서는 이 작업이 필요하지 않았습니다.
Red Hat OpenShift Logging Operator는 collect-audit-logs,collect-application-logs, collect-infrastructure-logs 클러스터 역할을 제공하여 수집기가 감사 로그, 애플리케이션 로그 및 인프라 로그를 각각 수집할 수 있습니다.
필요한 클러스터 역할을 서비스 계정에 바인딩하여 로그 컬렉션을 설정합니다.
2.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
2.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>
2.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가 있는 네임스페이스를 나타냅니다.
2.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.
2.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: 새 감사 로그를 생성할 수 있는 권한을 부여합니다.
2.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 시스템에서 인프라 로그를 생성할 수 있는 권한을 부여합니다.
2.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의 변경 사항을 모니터링할 수 있는 권한을 부여합니다.
2.3.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.3.3. Operator 관리
ClusterLogForwarder 리소스에는 Operator가 리소스를 적극적으로 관리하는지 또는 Unmanaged 상태로 둘지 여부를 제어하는 managementState 필드가 있습니다.
- 관리됨
- (기본값) Operator는 CLF 사양의 원하는 상태와 일치하도록 로깅 리소스를 구동합니다.
- Unmanaged
- Operator는 로깅 구성 요소와 관련된 작업을 수행하지 않습니다.
이를 통해 관리자는 managementState 를 Unmanaged 로 설정하여 로그 전달을 일시적으로 일시 중지할 수 있습니다.
2.3.4. ClusterLogForwarder의 구조
CLF에는 다음과 같은 주요 구성 요소가 포함된 spec 섹션이 있습니다.
- 입력
-
전달할 로그 메시지를 선택합니다. 기본 입력 유형
애플리케이션,인프라및감사는 클러스터의 다른 부분에서 로그를 전달합니다. 사용자 지정 입력을 정의할 수도 있습니다. - 출력
- 로그를 전달할 대상을 정의합니다. 각 출력에는 고유한 이름과 유형별 구성이 있습니다.
- 파이프라인
- 입력에서 필터를 통해 출력으로 가져오는 경로 로그를 정의합니다. 파이프라인에는 고유한 이름이 있으며 입력, 출력 및 필터 이름 목록으로 구성됩니다.
- 필터
- 파이프라인에서 로그 메시지를 변환하거나 삭제합니다. 사용자는 특정 로그 필드와 일치하는 필터를 정의하고 메시지를 삭제하거나 수정할 수 있습니다. 필터는 파이프라인에 지정된 순서로 적용됩니다.
2.3.4.1. 입력
입력은 spec.inputs 의 배열에 구성됩니다. 세 가지 기본 제공 입력 유형이 있습니다.
- 애플리케이션
-
기본, openshift 또는kube-또는openshift- - 인프라
-
기본및openshift네임스페이스 및 노드 로그에서 실행되는 인프라 구성 요소에서 로그를 선택합니다. - audit
- auditd에서 OpenShift API 서버 감사 로그, Kubernetes API 서버 감사 로그, ovn 감사 로그 및 노드 감사 로그에서 로그를 선택합니다.
사용자는 특정 네임스페이스에서 로그를 선택하거나 Pod 레이블을 사용하는 유형 애플리케이션 의 사용자 정의 입력을 정의할 수 있습니다.
2.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 서버로 전달합니다.
각 출력 유형에는 고유한 구성 필드가 있습니다.
2.3.5. OTLP 출력 구성
클러스터 관리자는 OTLP(OpenTelemetry Protocol) 출력을 사용하여 로그를 수집하고 OTLP 수신자에 전달할 수 있습니다. OTLP 출력은 OpenTelemetry Observability 프레임워크에서 정의한 사양을 사용하여 JSON 인코딩으로 HTTP를 통해 데이터를 보냅니다.
OTLP(OpenTelemetry Protocol) 출력 로그 전달자는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
프로세스
다음 주석을 추가하여 OTLP를 사용하여 전달을 활성화하도록
ClusterLogForwarderCR(사용자 정의 리소스)을 생성하거나 편집합니다.ClusterLogForwarderCR의 예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
OTLP 출력에서는 다른 출력 유형에서 사용하는 ViaQ 데이터 모델과 다른 OpenTelemetry 데이터 모델을 사용합니다. OpenTelemetry Observability 프레임워크에서 정의한 OpenTelemetry Semantic ations를 사용하여 OTLP를 준수합니다.
2.3.5.1. 파이프라인
파이프라인은 spec.pipelines 의 배열에 구성됩니다. 각 파이프라인에는 고유한 이름이 있어야 하며 다음으로 구성됩니다.
- inputRefs
- 로그가 이 파이프라인으로 전달되어야 하는 입력의 이름입니다.
- outputRefs
- 로그를 전송할 출력의 이름입니다.
- filterRefs
- (선택 사항) 적용할 필터 이름입니다.
filterRefs 순서가 순차적으로 적용되므로 중요합니다. 이전 필터는 이후 필터에서 처리되지 않는 메시지를 삭제할 수 있습니다.
2.3.5.2. 필터
필터는 spec.filters 아래의 배열에 구성됩니다. 구조화된 필드의 값을 기반으로 들어오는 로그 메시지를 일치시키고 수정하거나 삭제할 수 있습니다.
관리자는 다음 유형의 필터를 구성할 수 있습니다.
2.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>
2.3.5.3.1. 세부 정보
로그 메시지가 예외 스택 추적을 형성하는 연속 시퀀스로 표시되면 단일 통합 로그 레코드로 결합됩니다. 첫 번째 로그 메시지의 콘텐츠는 시퀀스의 모든 메시지 필드의 연결된 콘텐츠로 교체됩니다.
수집기는 다음 언어를 지원합니다.
- Java
- JS
- Ruby
- Python
- Golang
- PHP
- Dart
2.3.5.4. 원하지 않는 로그 레코드를 삭제하도록 콘텐츠 필터 구성
드롭 필터가 구성되면 로그 수집기는 전달 전에 필터에 따라 로그 스트림을 평가합니다. 수집기는 지정된 구성과 일치하는 원하지 않는 로그 레코드를 삭제합니다.
프로세스
ClusterLogForwarderCR의필터 사양에 필터구성을 추가합니다.다음 예제에서는 정규식을 기반으로 로그 레코드를 삭제하도록
ClusterLogForwarderCR을 구성하는 방법을 보여줍니다.ClusterLogForwarderCR의 예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필터가 적용되는 파이프라인을 지정합니다.
다음 명령을 실행하여
ClusterLogForwarderCR을 적용합니다.$ 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.3.5.5. 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
2.3.5.6. 레이블 표현식 또는 일치하는 라벨 키와 값을 포함하여 입력 시 애플리케이션 로그 필터링
입력 선택기를 사용하여 라벨 표현식 또는 일치하는 라벨 키와 해당 값을 기반으로 애플리케이션 로그를 포함할 수 있습니다.
프로세스
ClusterLogForwarderCR의입력 사양에필터 구성을 추가합니다.다음 예제에서는 라벨 표현식 또는 일치하는 라벨 키/값에 따라 로그를 포함하도록
ClusterLogForwarderCR을 구성하는 방법을 보여줍니다.ClusterLogForwarderCR의 예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 # ...다음 명령을 실행하여
ClusterLogForwarderCR을 적용합니다.$ oc apply -f <filename>.yaml
2.3.5.7. 로그 레코드를 정리하도록 콘텐츠 필터 구성
정리 필터가 구성되면 로그 수집기는 전달 전에 필터에 따라 로그 스트림을 평가합니다. 수집기는 Pod 주석과 같은 낮은 값 필드를 제거하여 로그 레코드를 정리합니다.
프로세스
ClusterLogForwarderCR의prune사양에 필터 구성을 추가합니다.다음 예제에서는 필드 경로를 기반으로 로그 레코드를 정리하도록
ClusterLogForwarderCR을 구성하는 방법을 보여줍니다.중요둘 다 지정된 경우 먼저
notIn배열에 따라 레코드가 정리되며, 이 경우in배열보다 우선합니다.notIn배열을 사용하여 레코드를 정리하면in배열을 사용하여 정리됩니다.ClusterLogForwarderCR의 예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필드를 제외합니다.다음 명령을 실행하여
ClusterLogForwarderCR을 적용합니다.$ oc apply -f <filename>.yaml
2.3.6. 소스로 감사 및 인프라 로그 입력 필터링
입력 선택기를 사용하여 로그를 수집할 감사 및 인프라 소스 목록을 정의할 수 있습니다.
프로세스
ClusterLogForwarderCR에서감사및인프라소스를 정의하는 구성을 추가합니다.다음 예제에서는
감사및인프라소스를 정의하도록ClusterLogForwarderCR을 구성하는 방법을 보여줍니다.ClusterLogForwarderCR의 예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 # ...다음 명령을 실행하여
ClusterLogForwarderCR을 적용합니다.$ oc apply -f <filename>.yaml
2.3.7. 네임스페이스 또는 컨테이너 이름을 포함하거나 제외하여 입력 시 애플리케이션 로그 필터링
입력 선택기를 사용하여 네임스페이스 및 컨테이너 이름을 기반으로 애플리케이션 로그를 포함하거나 제외할 수 있습니다.
프로세스
ClusterLogForwarderCR에 네임스페이스 및 컨테이너 이름을 포함하거나 제외하는 구성을 추가합니다.다음 예제에서는 네임스페이스 및 컨테이너 이름을 포함하거나 제외하도록
ClusterLogForwarderCR을 구성하는 방법을 보여줍니다.ClusterLogForwarderCR의 예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 # ...참고excludes필드는includes필드보다 우선합니다.다음 명령을 실행하여
ClusterLogForwarderCR을 적용합니다.$ oc apply -f <filename>.yaml
