검색

9.4. 로그 전달 구성

download PDF

로깅 배포에서 컨테이너 및 인프라 로그는 기본적으로 ClusterLogging 사용자 정의 리소스(CR)에 정의된 내부 로그 저장소로 전달됩니다.

감사 로그는 보안 스토리지를 제공하지 않기 때문에 기본적으로 내부 로그 저장소로 전달되지 않습니다. 감사 로그를 전달하는 시스템이 조직 및 정부 규정을 준수하고 올바르게 보호되도록 할 책임이 있습니다.

이 기본 구성이 요구 사항을 충족하는 경우 ClusterLogForwarder CR을 구성할 필요가 없습니다. ClusterLogForwarder CR이 있는 경우 기본 출력이 포함된 파이프라인을 정의하지 않는 한 로그는 내부 로그 저장소로 전달되지 않습니다.

9.4.1. 타사 시스템으로 로그 전달 정보

OpenShift Container Platform 클러스터 내부 및 외부의 특정 끝점에 로그를 보내려면 ClusterLogForwarder CR(사용자 정의 리소스)에서 출력파이프라인 조합을 지정합니다. 입력을 사용하여 특정 프로젝트와 관련된 애플리케이션 로그를 끝점으로 전달할 수도 있습니다. 인증은 Kubernetes Secret 오브젝트에서 제공합니다.

pipeline

한 로그 유형에서 하나 이상의 출력 또는 전송할 로그로의 간단한 라우팅을 정의합니다. 로그 유형은 다음 중 하나입니다.

  • application. 인프라 컨테이너 애플리케이션을 제외하고 클러스터에서 실행 중인 사용자 애플리케이션에 의해 생성된 컨테이너 로그입니다.
  • infrastructure. openshift*, kube* 또는 default 프로젝트에서 실행되는 Pod의 컨테이너 로그 및 노드 파일 시스템에서 가져온 저널 로그입니다.
  • audit. 노드 감사 시스템, auditd, Kubernetes API 서버, OpenShift API 서버 및 OVN 네트워크에서 생성된 감사 로그입니다.

파이프라인에서 key:value 쌍을 사용하여 아웃바운드 로그 메시지에 레이블을 추가할 수 있습니다. 예를 들어 다른 데이터 센터로 전달되는 메시지에 레이블을 추가하거나 유형별로 로그에 레이블을 지정할 수 있습니다. 오브젝트에 추가된 레이블도 로그 메시지와 함께 전달됩니다.

input

특정 프로젝트와 관련된 애플리케이션 로그를 파이프라인으로 전달합니다.

파이프 라인에서 outputRef 매개변수를 사용하여 로그를 전달하는 위치와 inputRef 매개변수를 사용하여 전달하는 로그 유형을 정의합니다.

Secret
사용자 자격 증명과 같은 기밀 데이터를 포함하는 key:value 맵 입니다.

다음을 확인합니다.

  • 로그 유형에 대한 파이프라인을 정의하지 않으면 정의되지 않은 유형의 로그가 삭제됩니다. 예를 들어 applicationaudit 유형에 대한 파이프라인을 지정하고 infrastructure 유형에 대한 파이프라인을 지정하지 않으면 infrastructure 로그가 삭제됩니다.
  • ClusterLogForwarder 사용자 정의 리소스(CR)에서 여러 유형의 출력을 사용하여 다른 프로토콜을 지원하는 서버에 로그를 보낼 수 있습니다.

다음 예제는 감사 로그를 안전한 외부 Elasticsearch 인스턴스로, 인프라 로그를 안전하지 않은 외부 Elasticsearch 인스턴스로, 애플리케이션 로그를 Kafka 브로커로, 애플리케이션 로그를 my-apps-logs 프로젝트에서 내부 Elasticsearch 인스턴스로 전달합니다.

샘플 로그 전달 출력 및 파이프라인

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"

1
레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.
2
레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.
3
서비스 계정의 이름입니다. 서비스 계정은 로그 전달자가 openshift-logging 네임스페이스에 배포되지 않은 경우에만 다중 로그 전달자 구현에 필요합니다.
4
보안 시크릿과 보안 URL을 사용하여 보안 Elasticsearch 출력을 구성합니다.
  • 출력을 설명하는 이름입니다.
  • 출력 유형: elasticsearch.
  • 접두사를 포함하여 유효한 절대 URL인 Elasticsearch 인스턴스의 보안 URL 및 포트입니다.
  • TLS 통신을 위해 끝점에서 요구하는 시크릿입니다. openshift-logging 프로젝트에 이 시크릿이 있어야 합니다.
5
안전하지 않은 Elasticsearch 출력에 대한 구성:
  • 출력을 설명하는 이름입니다.
  • 출력 유형: elasticsearch.
  • 접두사를 포함하여 유효한 절대 URL인 Elasticsearch 인스턴스의 안전하지 않은 URL 및 포트입니다.
6
보안 URL을 통한 클라이언트 인증 TLS 통신을 사용한 Kafka 출력 구성:
  • 출력을 설명하는 이름입니다.
  • 출력 유형: kafka.
  • 접두사를 포함하여 Kafka 브로커의 URL 및 포트를 유효한 절대 URL로 지정합니다.
7
my-project 네임스페이스에서 애플리케이션 로그를 필터링하기 위한 입력 구성입니다.
8
감사 로그를 안전한 외부 Elasticsearch 인스턴스로 전송하기 위한 파이프 라인 구성:
  • 파이프라인을 설명하는 이름입니다.
  • inputRefs는 로그 유형이며 이 예에서는 audit입니다.
  • outputRefs는 사용할 출력의 이름입니다.이 예에서 elasticsearch-secure는 보안 Elasticsearch 인스턴스로 전달하고 default은 내부 Elasticsearch 인스턴스로 전달합니다.
  • 선택사항: 로그에 추가할 레이블입니다.
9
선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다. "true"와 같은 인용 값은 부울 값이 아닌 문자열 값으로 인식됩니다.
10
인프라 로그를 안전하지 않은 외부 Elasticsearch 인스턴스로 전송하는 파이프라인 구성:
11
my-project 프로젝트에서 내부 Elasticsearch 인스턴스로 로그를 전송하기 위한 파이프라인 구성입니다.
  • 파이프라인을 설명하는 이름입니다.
  • inputRefs는 특정 입력인 my-app-logs입니다.
  • outputRefsdefault입니다.
  • 선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.
12
파이프라인 이름 없이 Kafka 브로커에 로그를 전송하는 파이프라인 구성:
  • inputRefs는 이 예제 application에서 로그 유형입니다.
  • outputRefs는 사용할 출력의 이름입니다.
  • 선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.
외부 로그 집계기를 사용할 수 없는 경우 Fluentd 로그 처리

외부 로깅 집계기를 사용할 수 없으며 로그를 수신할 수 없는 경우 Fluentd는 계속 로그를 수집하여 버퍼에 저장합니다. 로그 집계기를 사용할 수 있게 되면 버퍼링된 로그를 포함하여 로그 전달이 재개됩니다. 버퍼가 완전히 채워지면 Fluentd는 로그 수집을 중지합니다. OpenShift Container Platform은 로그를 회전시켜 삭제합니다. Fluentd 데몬 세트 또는 pod에 버퍼 크기를 조정하거나 PVC(영구 볼륨 클레임)를 추가할 수 없습니다.

지원되는 권한 부여 키

공통 키 유형이 여기에 제공됩니다. 일부 출력 유형은 출력별 구성 필드에 설명된 추가 특수 키를 지원합니다. 모든 보안 키는 선택 사항입니다. 관련 키를 설정하여 원하는 보안 기능을 활성화합니다. 키 및 시크릿, 서비스 계정, 포트 열기 또는 전역 프록시 구성과 같이 외부 대상에 필요할 수 있는 추가 구성을 생성하고 유지보수할 책임이 있습니다. Open Shift Logging은 권한 부여 조합이 일치하지 않는지 확인하지 않습니다.

TLS(Transport Layer Security)

시크릿 없이 TLS URL(http://... 또는 ssl://...)을 사용하면 기본 TLS 서버 측 인증이 활성화됩니다. 시크릿을 포함하고 다음 선택적 필드를 설정하여 추가 TLS 기능을 활성화합니다.

  • passphrase: (문자열)로 인코딩된 TLS 개인 키를 디코딩합니다. tls.key 가 필요합니다.
  • ca-bundle.crt: (문자열) 서버 인증을 위한 고객 CA의 파일 이름입니다.
사용자 이름 및 암호
  • 사용자 이름:(문자열) 인증 사용자 이름입니다. 암호 가 필요합니다.
  • password: (문자열) 인증 암호입니다. 사용자 이름이 필요합니다.
Simple Authentication Security Layer (SASL)
  • SASL.enable (boolean)은 SASL을 활성화 또는 비활성화합니다. 누락된 경우 다른 sasl. 키가 설정되면 SASL이 자동으로 활성화됩니다.
  • SASL.mechanisms: 허용 된 SASL 메커니즘 이름의 목록. 누락되거나 비어 있는 경우 시스템 기본값이 사용됩니다.
  • SASL.allow-insecure: (boolean) 일반 텍스트 암호를 보내는 메커니즘을 허용합니다. 기본값은 false입니다.

9.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>
참고

최상의 결과를 위해 일반 또는 불투명 보안이 권장됩니다.

9.4.2. 로그 전달자 생성

로그 전달자를 생성하려면 서비스 계정에서 수집할 수 있는 로그 입력 유형을 지정하는 ClusterLogForwarder CR을 생성해야 합니다. 로그를 전달할 수 있는 출력을 지정할 수도 있습니다. 다중 로그 전달자 기능을 사용하는 경우 ClusterLogForwarder CR의 서비스 계정도 참조해야 합니다.

클러스터에서 다중 로그 전달자 기능을 사용하는 경우 이름을 사용하여 모든 네임스페이스에서 ClusterLogForwarder 사용자 정의 리소스(CR)를 생성할 수 있습니다. 레거시 구현을 사용하는 경우 ClusterLogForwarder CR의 이름은 instance 여야 하며 openshift-logging 네임스페이스에서 생성해야 합니다.

중요

ClusterLogForwarder CR을 생성하는 네임스페이스에 대한 관리자 권한이 필요합니다.

ClusterLogForwarder 리소스 예

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
레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.
2
레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.
3
서비스 계정의 이름입니다. 서비스 계정은 로그 전달자가 openshift-logging 네임스페이스에 배포되지 않은 경우에만 다중 로그 전달자 구현에 필요합니다.
4
수집되는 로그 유형입니다. 이 필드의 값은 감사 로그, 애플리케이션 로그의 애플리케이션, 인프라 로그용 인프라 또는 애플리케이션에 대해 정의된 이름이 지정된 입력에 대한 감사일 수 있습니다.
5 7
로그를 전달할 출력 유형입니다. 이 필드의 값은 기본값,loki,kafka,elasticsearch,fluentdForward,syslog 또는 cloudwatch 일 수 있습니다.
참고

기본 출력 유형은 mutli 로그 전달자 구현에서 지원되지 않습니다.

6
로그를 전달할 출력의 이름입니다.
8
로그를 전달할 출력의 URL입니다.

9.4.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)에 값이 truedetectMultilineErrors 필드가 포함되어 있는지 확인합니다.

ClusterLogForwarder CR의 예

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

9.4.3.1. 세부 정보

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

표 9.9. 수집기당 지원되는 언어:
언어fluentdvector

Java

JS

Ruby

Python

Golang

PHP

Dart

9.4.3.2. 문제 해결

활성화되면 수집기 구성에 type: detect_exceptions가 있는 새 섹션이 포함됩니다.

벡터 구성 섹션의 예

[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

fluentd config 섹션의 예

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

9.4.4. GCP(Google Cloud Platform)에 로그 전달

내부 기본 OpenShift Container Platform 로그 저장소에 추가하거나 대신 Google Cloud Logging 에 로그를 전달할 수 있습니다.

참고

Fluentd에서 이 기능을 사용하는 것은 지원되지 않습니다.

사전 요구 사항

  • Red Hat OpenShift Logging Operator 5.5.1 이상

절차

  1. Google 서비스 계정 키를 사용하여 시크릿을 생성합니다.

    $ oc -n openshift-logging create secret generic gcp-secret --from-file google-application-credentials.json=<your_service_account_key_file.json>
  2. 아래 템플릿을 사용하여 ClusterLogForwarder 사용자 정의 리소스 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: 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
    레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.
    2
    레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.
    3
    서비스 계정의 이름입니다. 서비스 계정은 로그 전달자가 openshift-logging 네임스페이스에 배포되지 않은 경우에만 다중 로그 전달자 구현에 필요합니다.
    4
    GCP 리소스 계층에 로그를 저장하려는 위치에 따라 projectId,folderId,organizationId 또는 billingAccountId 필드 및 해당 값을 설정합니다.
    5
    Log EntrylogName 필드에 추가할 값을 설정합니다.
    6
    파이프라인 ,인프라 또는 감사 파이프라인을 사용하여 전달할 로그 유형을 지정합니다.

9.4.5. Splunk에 로그 전달

내부 기본 OpenShift Container Platform 로그 저장소에 추가하거나 대신 Splunk HTTP 이벤트 수집기(HEC) 에 로그를 전달할 수 있습니다.

참고

Fluentd에서 이 기능을 사용하는 것은 지원되지 않습니다.

사전 요구 사항

  • Red Hat OpenShift Logging Operator 5.6 이상
  • 벡터 가 수집기로 지정된 ClusterLogging 인스턴스
  • base64로 인코딩된 Splunk HEC 토큰

절차

  1. Base64로 인코딩된 Splunk HEC 토큰을 사용하여 시크릿을 생성합니다.

    $ oc -n openshift-logging create secret generic vector-splunk-secret --from-literal hecToken=<HEC_Token>
  2. 아래 템플릿을 사용하여 ClusterLogForwarder 사용자 정의 리소스(CR)를 생성하거나 편집합니다.

    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
    레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.
    2
    레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.
    3
    서비스 계정의 이름입니다. 서비스 계정은 로그 전달자가 openshift-logging 네임스페이스에 배포되지 않은 경우에만 다중 로그 전달자 구현에 필요합니다.
    4
    출력 이름을 지정합니다.
    5
    HEC 토큰이 포함된 시크릿의 이름을 지정합니다.
    6
    출력 유형을 splunk 로 지정합니다.
    7
    Splunk HEC의 URL(포트 포함)을 지정합니다.
    8
    파이프라인 ,인프라 또는 감사 파이프라인을 사용하여 전달할 로그 유형을 지정합니다.
    9
    선택사항: 파이프라인의 이름을 지정합니다.
    10
    이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.

9.4.6. HTTP를 통해 로그 전달

HTTP를 통한 로그 전달은 Fluentd 및 Vector 로그 수집기 모두에서 지원됩니다. 활성화하려면 ClusterLogForwarder CR(사용자 정의 리소스)에서 http 를 출력 유형으로 지정합니다.

절차

  • 아래 템플릿을 사용하여 ClusterLogForwarder CR을 생성하거나 편집합니다.

    ClusterLogForwarder CR의 예

    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
    레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.
    2
    레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.
    3
    서비스 계정의 이름입니다. 서비스 계정은 로그 전달자가 openshift-logging 네임스페이스에 배포되지 않은 경우에만 다중 로그 전달자 구현에 필요합니다.
    4
    로그의 대상 주소입니다.
    5
    로그 레코드와 함께 전송할 추가 헤더입니다.
    6
    대상 자격 증명의 시크릿 이름입니다.
    7
    값은 true 또는 false 입니다.
    8
    이 값은 출력 이름과 동일해야 합니다.

9.4.7. 특정 프로젝트의 애플리케이션 로그 전달

내부 로그 저장소를 사용하거나 대신 특정 프로젝트의 애플리케이션 로그 사본을 외부 로그 수집기로 전달할 수 있습니다. OpenShift Container Platform에서 로그 데이터를 수신하도록 외부 로그 수집기를 구성해야 합니다.

프로젝트의 애플리케이션 로그 전달을 구성하려면 프로젝트에서 하나 이상의 입력, 다른 로그 집계기에 대한 선택적 출력, 이러한 입력 및 출력을 사용하는 파이프라인을 사용하여 ClusterLogForwarder 사용자 정의 리소스(CR)를 생성해야 합니다.

사전 요구 사항

  • 지정된 프로토콜 또는 형식을 사용하여 로깅 데이터를 수신하도록 구성된 로깅 서버가 있어야 합니다.

절차

  1. ClusterLogForwarder CR을 정의하는 YAML 파일을 생성하거나 편집합니다.

    ClusterLogForwarder CR의 예

    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"

    1
    ClusterLogForwarder CR의 이름은 instance여야 합니다.
    2
    ClusterLogForwarder CR의 네임스페이스는 openshift-logging이어야 합니다.
    3
    출력의 이름입니다.
    4
    출력 유형: elasticsearch,fluentdForward,syslog 또는 kafka.
    5
    유효한 절대 URL인 외부 로그 수집기의 URL 및 포트입니다. CIDR 주석을 사용하는 클러스터 전체 프록시가 활성화된 경우 출력은 IP 주소가 아닌 서버 이름 또는 FQDN이어야 합니다.
    6
    tls 접두사를 사용하는 경우 TLS 통신을 위해 끝점에서 요구하는 시크릿 이름을 지정해야 합니다. 시크릿은 openshift-logging 프로젝트에 있어야 하며 각각의 인증서를 가리키는 tls.crt, tls.key, 및 ca-bundle.crt 키가 있어야 합니다.
    7
    지정된 프로젝트의 애플리케이션 로그를 필터링하기 위한 입력 구성입니다.
    8
    네임스페이스를 지정하지 않으면 모든 네임스페이스에서 로그가 수집됩니다.
    9
    파이프라인 구성은 이름이 지정된 입력의 로그를 이름이 지정된 출력으로 보냅니다. 이 예에서 forward-to-fluentd-insecure 라는 파이프라인은 my-app-logs 라는 입력에서 fluentd-server-insecure 라는 출력으로 로그를 전달합니다.
    10
    입력 목록입니다.
    11
    사용할 출력의 이름입니다.
    12
    선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.
    13
    로그를 다른 로그 집계기로 보내는 파이프라인 구성입니다.
    • 선택사항: 파이프라인의 이름을 지정합니다.
    • 파이프라인을 사용하여 전달할 로그 유형 (application, infrastructure, 또는 audit)을 지정합니다.
    • 이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.
    • 선택 사항: default 출력을 지정하여 로그를 기본 로그 저장소로 전달합니다.
    • 선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.
    14
    이 구성을 사용할 때 모든 네임스페이스의 애플리케이션 로그가 수집됩니다.
  2. 다음 명령을 실행하여 ClusterLogForwarder CR을 적용합니다.

    $ oc apply -f <filename>.yaml

9.4.8. 특정 pod에서 애플리케이션 로그 전달

클러스터 관리자는 Kubernetes Pod 레이블을 사용하여 특정 Pod에서 로그 데이터를 수집하여 로그 수집기로 전달할 수 있습니다.

다양한 네임스페이스의 다른 pod와 함께 실행되는 pod로 구성된 애플리케이션이 있다고 가정합니다. 이러한 pod에 애플리케이션을 식별하는 레이블이 있는 경우 로그 데이터를 특정 로그 수집기로 수집하고 출력할 수 있습니다.

Pod 라벨을 지정하려면 하나 이상의 matchLabels 키-값 쌍을 사용합니다. 여러 키-값 쌍을 지정하는 경우 Pod를 모두 선택할 수 있어야 합니다.

절차

  1. ClusterLogForwarder CR 오브젝트를 정의하는 YAML 파일을 생성하거나 편집합니다. 파일에서 다음 예와 같이 inputs[].name.application.selector.matchLabels에서 간단한 동일성 기반 선택기를 사용하여 Pod 레이블을 지정합니다.

    ClusterLogForwarder CR YAML 파일의 예

    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
    레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.
    2
    레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.
    3
    inputs[].name에서 하나 이상의 쉼표로 구분된 값을 지정합니다.
    4
    outputs[]에서 하나 이상의 쉼표로 구분된 값을 지정합니다.
    5
    고유한 pod 레이블 집합이 있는 각 애플리케이션에 대해 고유한 inputs[].name을 정의합니다.
    6
    수집하려는 로그 데이터가 있는 Pod 라벨의 키-값 쌍을 지정합니다. 키뿐만 아니라 키와 값 모두를 지정해야 합니다. 선택하려면 Pod가 모든 키-값 쌍과 일치해야 합니다.
    7
    선택 사항: 하나 이상의 네임스페이스를 지정합니다.
    8
    로그 데이터를 전달할 출력을 하나 이상 지정합니다.
  2. 선택 사항: 로그 데이터 수집을 특정 네임스페이스로 제한하려면 위 예제에 표시된 대로 inputs[].name.application.namespaces를 사용합니다.
  3. 선택 사항: Pod 레이블이 다른 추가 애플리케이션에서 동일한 파이프라인으로 로그 데이터를 보낼 수 있습니다.

    1. Pod 레이블의 고유한 조합마다 표시된 항목과 유사한 추가 inputs[].name 섹션을 생성합니다.
    2. 이 애플리케이션의 Pod 레이블과 일치하도록 selectors를 업데이트합니다.
    3. inputs[].name 값을 inputRefs에 추가합니다. 예를 들면 다음과 같습니다.

      - inputRefs: [ myAppLogData, myOtherAppLogData ]
  4. CR 오브젝트를 생성합니다.

    $ oc create -f <file-name>.yaml

추가 리소스

9.4.9. API 감사 필터 개요

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

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

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

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

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

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

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

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

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

참고

제공된 예제에서는 감사 정책에서 가능한 규칙 범위를 설명하기 위한 것이며 권장되는 구성이 아닙니다.

감사 정책의 예

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
감사 정책의 이름입니다.

9.4.10. 외부 Loki 로깅 시스템으로 로그 전달

기본 로그 저장소에 추가하거나 대신 외부 Loki 로깅 시스템으로 로그를 전달할 수 있습니다.

Loki에 대한 로그 전달을 구성하려면 Loki에 대한 출력과 출력을 사용하는 파이프라인이 있는 ClusterLogForwarder 사용자 정의 리소스(CR)를 생성해야 합니다. Loki의 출력은 HTTP(비보안) 또는 HTTPS(보안 HTTP) 연결을 사용할 수 있습니다.

사전 요구 사항

  • CR의 url 필드로 지정하는 URL에서 Loki 로깅 시스템을 실행해야 합니다.

절차

  1. ClusterLogForwarder CR 오브젝트를 정의하는 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: 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
    레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.
    2
    레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.
    3
    서비스 계정의 이름입니다. 서비스 계정은 로그 전달자가 openshift-logging 네임스페이스에 배포되지 않은 경우에만 다중 로그 전달자 구현에 필요합니다.
    4
    출력 이름을 지정합니다.
    5
    유형을 "loki"로 지정합니다.
    6
    Loki 시스템의 URL 및 포트를 유효한 절대 URL로 지정합니다. http(비보안) 또는 https(보안 HTTP) 프로토콜을 사용할 수 있습니다. CIDR 주석을 사용하는 클러스터 전체 프록시가 활성화된 경우 출력은 IP 주소가 아닌 서버 이름 또는 FQDN이어야 합니다. 로키의 HTTP(S) 통신용 기본 포트는 3100입니다.
    7
    보안 연결의 경우 secret을 지정하여 인증하는 https 또는 http URL을 지정할 수 있습니다.
    8
    https 접두사의 경우 TLS 통신의 엔드포인트에 필요한 보안 이름을 지정합니다. 시크릿에는 나타내는 인증서를 가리키는 ca-bundle.crt 키가 포함되어야 합니다. 그러지 않으면 httphttps 접두사의 경우 사용자 이름과 암호가 포함된 시크릿을 지정할 수 있습니다. 레거시 구현에서는 openshift-logging 프로젝트에 시크릿이 있어야 합니다. 자세한 내용은 다음 "사용자 이름 및 암호가 포함된 시크릿 설정 예"를 참조하십시오.
    9
    선택 사항: metadata 키 필드를 지정하여 Loki의 TenantID 필드 값을 생성합니다. 예를 들어 tenantKey: kubernetes.namespace_name을 설정하면 Kubernetes 네임스페이스의 이름이 Loki의 테넌트 ID 값으로 사용됩니다. 지정할 수 있는 다른 로그 레코드 필드를 보려면 다음 "추가 리소스" 섹션의 "로그 레코드 필드" 링크를 참조하십시오.
    10
    선택 사항: 메타데이터 필드 키 목록을 지정하여 기본 Loki 레이블을 교체합니다. Loki 레이블 이름은 정규식 [a-zA-Z_:][a-zA-Z0-9_:]*와 일치해야 합니다. 메타데이터 키의 잘못된 문자는 레이블 이름을 형성하기 위해 _ 로 교체됩니다. 예를 들어 kubernetes.labels.foo 메타데이터 키는 Loki 레이블 kubernetes_labels_foo 가 됩니다. labelKeys를 설정하지 않으면 기본값은 [log_type, kubernetes.namespace_name, kubernetes.pod_name, kubernetes_host] 입니다. Loki는 허용되는 레이블의 크기와 수를 제한하므로 레이블 세트를 작게 유지합니다. Configuring Loki, limits_config를 참조하십시오. 쿼리 필터를 사용하여 로그 레코드 필드를 기반으로 쿼리할 수 있습니다.
    11
    선택사항: 파이프라인의 이름을 지정합니다.
    12
    파이프라인을 사용하여 전달할 로그 유형 (application, infrastructure, 또는 audit)을 지정합니다.
    13
    이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.
    참고

    Loki는 타임스탬프에 의해 로그 스트림을 올바르게 정렬해야 하므로 labelKeys에는 항상 kubernetes_host 레이블 세트가 포함됩니다. 이렇게 하면 각 스트림이 단일 호스트에서 시작되도록 하여 서로 다른 호스트의 클록 차이로 인해 타임스탬프가 무질서해지는 것을 방지할 수 있습니다.

  2. 다음 명령을 실행하여 ClusterLogForwarder CR 오브젝트를 적용합니다.

    $ oc apply -f <filename>.yaml

추가 리소스

9.4.11. 외부 Elasticsearch 인스턴스로 로그 전달

내부 로그 저장소에 추가하거나 대신 외부 Elasticsearch 인스턴스로 로그를 전달할 수 있습니다. OpenShift Container Platform에서 로그 데이터를 수신하도록 외부 로그 집계기를 구성해야 합니다.

외부 Elasticsearch 인스턴스에 대한 로그 전달을 구성하려면 해당 인스턴스에 대한 출력과 출력을 사용하는 파이프라인이 있는 ClusterLogForwarder 사용자 정의 리소스(CR)를 생성해야 합니다. 외부 Elasticsearch 출력은 HTTP(비보안) 또는 HTTPS(보안 HTTP) 연결을 사용할 수 있습니다.

외부 및 내부 Elasticsearch 인스턴스 모두에 로그를 전달하려면 외부 인스턴스에 대한 출력 및 파이프라인과 default 출력을 사용하여 내부 인스턴스로 로그를 전달하는 파이프라인을 생성합니다.

참고

내부 Elasticsearch 인스턴스에만 로그를 전달하려면 ClusterLogForwarder CR을 생성할 필요가 없습니다.

사전 요구 사항

  • 지정된 프로토콜 또는 형식을 사용하여 로깅 데이터를 수신하도록 구성된 로깅 서버가 있어야 합니다.

절차

  1. ClusterLogForwarder CR을 정의하는 YAML 파일을 생성하거나 편집합니다.

    ClusterLogForwarder CR의 예

    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
    레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.
    2
    레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.
    3
    서비스 계정의 이름입니다. 서비스 계정은 로그 전달자가 openshift-logging 네임스페이스에 배포되지 않은 경우에만 다중 로그 전달자 구현에 필요합니다.
    4
    출력 이름을 지정합니다.
    5
    elasticsearch 유형을 지정합니다.
    6
    Elasticsearch 버전을 지정합니다. 6,7 또는 8 일 수 있습니다.
    7
    외부 Elasticsearch 인스턴스의 URL과 포트를 유효한 절대 URL로 지정합니다. http(비보안) 또는 https(보안 HTTP) 프로토콜을 사용할 수 있습니다. CIDR 주석을 사용하는 클러스터 전체 프록시가 활성화된 경우 출력은 IP 주소가 아닌 서버 이름 또는 FQDN이어야 합니다.
    8
    https 접두사의 경우 TLS 통신의 엔드포인트에 필요한 보안 이름을 지정합니다. 시크릿에는 나타내는 인증서를 가리키는 ca-bundle.crt 키가 포함되어야 합니다. 그러지 않으면 httphttps 접두사의 경우 사용자 이름과 암호가 포함된 시크릿을 지정할 수 있습니다. 레거시 구현에서는 openshift-logging 프로젝트에 시크릿이 있어야 합니다. 자세한 내용은 다음 "사용자 이름 및 암호가 포함된 시크릿 설정 예"를 참조하십시오.
    9
    선택사항: 파이프라인의 이름을 지정합니다.
    10
    파이프라인을 사용하여 전달할 로그 유형 (application, infrastructure, 또는 audit)을 지정합니다.
    11
    이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.
    12
    선택사항: default 출력을 지정하여 내부 Elasticsearch 인스턴스로 로그를 보냅니다.
    13
    선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.
  2. ClusterLogForwarder CR을 적용합니다.

    $ oc apply -f <filename>.yaml

예: 사용자 이름과 암호가 포함된 시크릿 설정

사용자 이름과 암호가 포함된 시크릿을 사용하여 외부 Elasticsearch 인스턴스에 대한 보안 연결을 인증할 수 있습니다.

예를 들어 타사가 Elasticsearch 인스턴스를 작동하기 때문에 상호 TLS(mTLS) 키를 사용할 수 없는 경우 HTTP 또는 HTTPS를 사용하고 사용자 이름과 암호가 포함된 시크릿을 설정할 수 있습니다.

  1. 다음 예와 유사한 Secret YAML 파일을 생성합니다. usernamepassword 필드에 base64로 인코딩된 값을 사용합니다. 기본적으로 secret 유형은 opaque입니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: openshift-test-secret
    data:
      username: <username>
      password: <password>
    # ...
  2. 시크릿을 생성합니다.

    $ oc create secret -n openshift-logging openshift-test-secret.yaml
  3. ClusterLogForwarder CR에서 시크릿 이름을 지정합니다.

    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
    # ...
    참고

    url 필드의 값에서 접두사는 http 또는 https가 될 수 있습니다.

  4. CR 오브젝트를 적용합니다.

    $ oc apply -f <filename>.yaml

9.4.12. Fluentd 정방향 프로토콜을 사용하여 로그 전달

Fluentd 전달 프로토콜을 사용하여 기본 Elasticsearch 로그 저장소 대신 또는 기본 Elasticsearch 로그 저장소 외에 프로토콜을 수락하도록 구성된 외부 로그 집계기로 로그 사본을 보낼 수 있습니다. OpenShift Container Platform에서 로그를 수신하도록 외부 로그 집계기를 구성해야 합니다.

전달 프로토콜을 사용하여 로그 전달을 구성하려면 해당 출력을 사용하는 Fluentd 서버 및 파이프라인에 대한 출력이 하나 이상 있는 ClusterLogForwarder 사용자 정의 리소스(CR)를 생성해야 합니다. Fluentd 출력은 TCP(비보안) 또는 TLS(보안 TCP) 연결을 사용할 수 있습니다.

사전 요구 사항

  • 지정된 프로토콜 또는 형식을 사용하여 로깅 데이터를 수신하도록 구성된 로깅 서버가 있어야 합니다.

절차

  1. ClusterLogForwarder CR 오브젝트를 정의하는 YAML 파일을 생성하거나 편집합니다.

    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"
    1
    ClusterLogForwarder CR의 이름은 instance여야 합니다.
    2
    ClusterLogForwarder CR의 네임스페이스는 openshift-logging이어야 합니다.
    3
    출력 이름을 지정합니다.
    4
    fluentdForward 유형을 지정합니다.
    5
    유효한 절대 URL로 외부 Fluentd 인스턴스의 URL 및 포트를 지정합니다. tcp(비보안) 또는 tls(보안 TCP) 프로토콜을 사용할 수 있습니다. CIDR 주석을 사용하는 클러스터 전체 프록시가 활성화된 경우 출력은 IP 주소가 아닌 서버 이름 또는 FQDN이어야 합니다.
    6
    tls 접두사를 사용하는 경우 TLS 통신을 위해 끝점에 필요한 시크릿 이름을 지정해야 합니다. 시크릿은 openshift-logging 프로젝트에 있어야 하며 나타내는 인증서를 가리키는 ca-bundle.crt 키가 포함되어야 합니다.
    7
    선택사항: 파이프라인의 이름을 지정합니다.
    8
    파이프라인을 사용하여 전달할 로그 유형 (application, infrastructure, 또는 audit)을 지정합니다.
    9
    이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.
    10
    선택사항: default 출력을 지정하여 내부 Elasticsearch 인스턴스로 로그를 전달합니다.
    11
    선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.
    12
    선택사항: 지원되는 유형의 다른 외부 로그 집계에 로그를 전달하도록 여러 출력을 구성합니다.
    • 파이프라인을 설명하는 이름입니다.
    • inputRefs는 pipeline: application, infrastructure 또는 audit를 사용하여 전달할 로그 유형입니다.
    • outputRefs는 사용할 출력의 이름입니다.
    • 선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.
  2. CR 오브젝트를 생성합니다.

    $ oc create -f <file-name>.yaml

9.4.12.1. Logstash가 fluentd에서 데이터를 수집할 수 있도록 nanosecond precision 사용

fluentd에서 로그 데이터를 수집하려면 Logstash 구성 파일에서 nanosecond precision을 활성화해야 합니다.

절차

  • Logstash 설정 파일에서 nanosecond_ precisiontrue 로 설정합니다.

Logstash 구성 파일 예

input { tcp { codec => fluent { nanosecond_precision => true } port => 24114 } }
filter { }
output { stdout { codec => rubydebug } }

9.4.13. syslog 프로토콜을 사용하여 로그 전달

syslog RFC3164 또는 RFC5424 프로토콜을 사용하여 기본 Elasticsearch 로그 저장소 대신 또는 기본 Elasticsearch 로그 저장소에 더하여 해당 프로토콜을 수락하도록 구성된 외부 로그 집계기에 로그 사본을 보낼 수 있습니다. OpenShift Container Platform에서 로그를 수신하도록 syslog 서버와 같은 외부 로그 수집기를 구성해야 합니다.

syslog 프로토콜을 사용하여 로그 전달을 구성하려면 해당 출력을 사용하는 syslog 서버 및 파이프라인에 대한 출력이 하나 이상 있는 ClusterLogForwarder 사용자 정의 리소스(CR)를 생성해야 합니다. syslog 출력은 UDP, TCP 또는 TLS 연결을 사용할 수 있습니다.

사전 요구 사항

  • 지정된 프로토콜 또는 형식을 사용하여 로깅 데이터를 수신하도록 구성된 로깅 서버가 있어야 합니다.

절차

  1. ClusterLogForwarder CR 오브젝트를 정의하는 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: 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"
    1
    레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.
    2
    레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.
    3
    서비스 계정의 이름입니다. 서비스 계정은 로그 전달자가 openshift-logging 네임스페이스에 배포되지 않은 경우에만 다중 로그 전달자 구현에 필요합니다.
    4
    출력 이름을 지정합니다.
    5
    syslog 유형을 지정합니다.
    6
    선택 사항: 아래에 나열된 syslog 매개변수를 지정합니다.
    7
    외부 syslog 인스턴스의 URL 및 포트를 지정합니다. udp(비보안), tcp(비보안) 또는 tls(보안 TCP) 프로토콜을 사용할 수 있습니다. CIDR 주석을 사용하는 클러스터 전체 프록시가 활성화된 경우 출력은 IP 주소가 아닌 서버 이름 또는 FQDN이어야 합니다.
    8
    tls 접두사를 사용하는 경우 TLS 통신을 위해 끝점에서 요구하는 시크릿 이름을 지정해야 합니다. 시크릿에는 나타내는 인증서를 가리키는 ca-bundle.crt 키가 포함되어야 합니다. 레거시 구현에서는 openshift-logging 프로젝트에 시크릿이 있어야 합니다.
    9
    선택사항: 파이프라인의 이름을 지정합니다.
    10
    파이프라인을 사용하여 전달할 로그 유형 (application, infrastructure, 또는 audit)을 지정합니다.
    11
    이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.
    12
    선택사항: default 출력을 지정하여 내부 Elasticsearch 인스턴스로 로그를 전달합니다.
    13
    선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다. "true"와 같은 인용 값은 부울 값이 아닌 문자열 값으로 인식됩니다.
    14
    선택사항: 지원되는 유형의 다른 외부 로그 집계에 로그를 전달하도록 여러 출력을 구성합니다.
    • 파이프라인을 설명하는 이름입니다.
    • inputRefs는 pipeline: application, infrastructure 또는 audit를 사용하여 전달할 로그 유형입니다.
    • outputRefs는 사용할 출력의 이름입니다.
    • 선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.
  2. CR 오브젝트를 생성합니다.

    $ oc create -f <filename>.yaml

9.4.13.1. 메시지 출력에 로그 소스 정보 추가

ClusterLogForwarder 사용자 정의 리소스(CR)에 AddLogSource 필드를 추가하여 namespace _name,pod_name 요소를 레코드의 message 필드에 추가할 수 있습니다.

  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
참고

이 구성은 RFC3164 및 RFC5424와 모두 호환됩니다.

AddLogSource가 없는 syslog 메시지 출력 예

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

AddLogSource의 syslog 메시지 출력 예

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

9.4.13.2. Syslog 매개변수

syslog 출력에 대해 다음을 구성할 수 있습니다. 자세한 내용은 syslog RFC3164 또는 RFC5424 RFC를 참조하십시오.

  • 시설: syslog facility. 값은 10진수 정수 또는 대소문자를 구분하지 않는 키워드일 수 있습니다.

    • 커널 메시지의 경우 0 또는 kern
    • 사용자 수준 메시지의 경우 1 또는 user, 기본값입니다.
    • 2 또는 mail 시스템용 메일
    • 시스템 데몬의 경우 3 또는 daemon
    • 보안/인증 메시지의 경우 4 또는 auth
    • syslogd에 의해 내부적으로 생성된 메시지의 경우 5 또는 syslog
    • 라인 프린터 하위 시스템의 경우 6 또는 lpr
    • 네트워크 뉴스 서브 시스템의 경우 7 또는 news
    • UUCP 하위 시스템의 경우 8 또는 uucp
    • 시계 데몬의 경우 9 또는 cron
    • 보안 인증 메시지의 경우 10 또는 authpriv
    • FTP 데몬의 경우 11 또는 ftp
    • NTP 하위 시스템의 경우 12 또는 ntp
    • syslog 감사 로그의 경우 13 또는 security
    • syslog 경고 로그의 경우 14 또는 console
    • 스케줄링 데몬의 경우 15 또는 solaris-cron
    • 로컬에서 사용되는 시설의 경우 1623 또는 local0local7
  • 선택 사항: payloadKey: syslog 메시지의 페이로드로 사용할 레코드 필드입니다.

    참고

    payloadKey 매개변수를 구성하면 다른 매개 변수가 syslog로 전달되지 않습니다.

  • rfc: syslog를 사용하여 로그를 보내는 데 사용할 RFC입니다. 기본값은 RFC5424입니다.
  • 심각도: 발신되는 syslog 레코드에 설정할 syslog 심각도입니다. 값은 10진수 정수 또는 대소문자를 구분하지 않는 키워드일 수 있습니다.

    • 시스템을 사용할 수 없음을 나타내는 메시지의 경우 0 또는 Emergency
    • 조치를 즉시 취해야 함을 나타내는 메시지의 경우 1 또는 Alert
    • 위험 상태를 나타내는 메시지의 경우 2 또는 Critical
    • 오류 상태를 나타내는 메시지의 경우 3 또는 Error
    • 경고 조건을 나타내는 메시지의 경우 4 또는 Warning
    • 정상이지만 중요한 조건을 나타내는 메시지의 경우 5 또는 Notice
    • 정보성 메시지를 나타내는 메시지의 경우 6 또는 Informational
    • 디버그 수준 메시지를 나타내는 메시지의 경우 7 또는 Debug, 기본값
  • 태그: 태그는 syslog 메시지에서 태그로 사용할 레코드 필드를 지정합니다.
  • trimPrefix: 태그에서 지정된 접두사를 제거합니다.

9.4.13.3. 추가 RFC5424 syslog 매개변수

RFC5424에는 다음 매개변수가 적용됩니다.

  • appName: APP-NAME은 로그를 보낸 애플리케이션을 식별하는 자유 텍스트 문자열입니다. RFC5424에 대해 지정해야 합니다.
  • msgID: MSGID는 메시지 유형을 식별하는 자유 텍스트 문자열입니다. RFC5424에 대해 지정해야 합니다.
  • procID: PROCID는 자유 텍스트 문자열입니다. 값이 변경되면 syslog 보고가 중단되었음을 나타냅니다. RFC5424에 대해 지정해야 합니다.

9.4.14. Kafka 브로커로 로그 전달

기본 로그 저장소에 추가하거나 대신 외부 Kafka 브로커로 로그를 전달할 수 있습니다.

외부 Kafka 인스턴스에 대한 로그 전달을 구성하려면 해당 인스턴스에 대한 출력과 출력을 사용하는 파이프라인이 있는 ClusterLogForwarder 사용자 정의 리소스(CR)를 생성해야 합니다. 출력에 특정 Kafka 주제를 포함하거나 기본값을 사용할 수 있습니다. Kafka 출력은 TCP(비보안) 또는 TLS(보안 TCP) 연결을 사용할 수 있습니다.

절차

  1. ClusterLogForwarder CR 오브젝트를 정의하는 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: 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"
    1
    레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.
    2
    레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.
    3
    서비스 계정의 이름입니다. 서비스 계정은 로그 전달자가 openshift-logging 네임스페이스에 배포되지 않은 경우에만 다중 로그 전달자 구현에 필요합니다.
    4
    출력 이름을 지정합니다.
    5
    kafka 유형을 지정합니다.
    6
    Kafka 브로커의 URL과 포트를 유효한 절대 URL로 지정하고 선택적으로 특정 주제를 사용합니다. tcp(비보안) 또는 tls(보안 TCP) 프로토콜을 사용할 수 있습니다. CIDR 주석을 사용하는 클러스터 전체 프록시가 활성화된 경우 출력은 IP 주소가 아닌 서버 이름 또는 FQDN이어야 합니다.
    7
    tls 접두사를 사용하는 경우 TLS 통신을 위해 끝점에 필요한 시크릿 이름을 지정해야 합니다. 시크릿에는 나타내는 인증서를 가리키는 ca-bundle.crt 키가 포함되어야 합니다. 레거시 구현에서는 openshift-logging 프로젝트에 시크릿이 있어야 합니다.
    8
    선택 사항: 비보안 출력을 보내려면 URL 앞에 있는 tcp 접두사를 사용합니다. 이 출력에서 secret 키와 해당 name을 생략합니다.
    9
    선택사항: 파이프라인의 이름을 지정합니다.
    10
    파이프라인을 사용하여 전달할 로그 유형 (application, infrastructure, 또는 audit)을 지정합니다.
    11
    이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.
    12
    선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.
    13
    선택사항: 지원되는 유형의 다른 외부 로그 집계에 로그를 전달하도록 여러 출력을 구성합니다.
    • 파이프라인을 설명하는 이름입니다.
    • inputRefs는 pipeline: application, infrastructure 또는 audit를 사용하여 전달할 로그 유형입니다.
    • outputRefs는 사용할 출력의 이름입니다.
    • 선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.
  2. 선택 사항: 단일 출력을 여러 Kafka 브로커로 전달하려면 다음 예와 같이 Kafka 브로커 배열을 지정합니다.

    # ...
    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
    brokerstopic 키가 있는 kafka 키를 지정합니다.
    2
    brokers 키를 사용하여 하나 이상의 브로커 배열을 지정합니다.
    3
    topic 키를 사용하여 로그를 수신하는 대상 주제를 지정합니다.
  3. 다음 명령을 실행하여 ClusterLogForwarder CR을 적용합니다.

    $ oc apply -f <filename>.yaml

9.4.15. Amazon CloudView로 로그 전달

AWS(Amazon Web Services)에서 호스팅하는 모니터링 및 로그 스토리지 서비스인 Amazon CloudMonitor에 로그를 전달할 수 있습니다. 기본 로그 저장소에 추가하거나 대신 logs를 NetNamespace로 전달할 수 있습니다.

CloudMonitor에 대한 로그 전달을 구성하려면 CloudMonitor의 출력이 있는 ClusterLogForwarder 사용자 정의 리소스(CR)와 출력을 사용하는 파이프라인을 생성해야 합니다.

절차

  1. aws_access_key_idaws_secret_access_key 필드를 사용하여 base64로 인코딩된 AWS 인증 정보를 지정하는 Secret YAML 파일을 만듭니다. 예를 들면 다음과 같습니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: cw-secret
      namespace: openshift-logging
    data:
      aws_access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK
      aws_secret_access_key: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=
  2. 시크릿을 생성합니다. 예를 들면 다음과 같습니다.

    $ oc apply -f cw-secret.yaml
  3. ClusterLogForwarder CR 오브젝트를 정의하는 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
    1
    레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.
    2
    레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.
    3
    서비스 계정의 이름입니다. 서비스 계정은 로그 전달자가 openshift-logging 네임스페이스에 배포되지 않은 경우에만 다중 로그 전달자 구현에 필요합니다.
    4
    출력 이름을 지정합니다.
    5
    cloudwatch 유형을 지정합니다.
    6
    선택 사항: 로그를 그룹화하는 방법을 지정합니다.
    • logType 은 각 로그 유형에 대한 로그 그룹을 생성합니다.
    • namespaceName은 각 애플리케이션 네임 스페이스에 대한 로그 그룹을 생성합니다. 인프라 및 감사 로그를 위해 별도의 로그 그룹도 생성합니다.
    • namespaceUUID는 각 애플리케이션 네임스페이스 UUID에 대한 새 로그 그룹을 생성합니다. 인프라 및 감사 로그를 위해 별도의 로그 그룹도 생성합니다.
    7
    선택 사항: 로그 그룹 이름으로 기본 infrastructureName 접두사를 바꾸려면 문자열을 지정합니다.
    8
    AWS 리전을 지정합니다.
    9
    AWS 인증 정보가 포함된 시크릿의 이름을 지정합니다.
    10
    선택사항: 파이프라인의 이름을 지정합니다.
    11
    파이프라인을 사용하여 전달할 로그 유형 (application, infrastructure, 또는 audit)을 지정합니다.
    12
    이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.
  4. CR 오브젝트를 생성합니다.

    $ oc create -f <file-name>.yaml

예: Amazon Cloud Watch에서 ClusterLogForwarder 사용

여기에 ClusterLogForwarder 사용자 정의 리소스(CR)의 예와 Amazon CloudMonitor로 출력되는 로그 데이터가 표시됩니다.

mycluster라는 OpenShift Container Platform 클러스터를 실행하고 있다고 가정합니다. 다음 명령은 나중에 aws 명령을 구성하는 데 사용할 클러스터의 infrastructureName을 반환합니다.

$ oc get Infrastructure/cluster -ojson | jq .status.infrastructureName
"mycluster-7977k"

이 예제에 대한 로그 데이터를 생성하려면 app 이라는 네임스페이스에서 busybox Pod를 실행합니다. busybox Pod는 3초마다 stdout에 메시지를 씁니다.

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

busybox Pod가 실행되는 네임스페이스의 UUID를 조회할 수 있습니다.

$ oc get ns/app -ojson | jq .metadata.uid
"794e1e1a-b9f5-4958-a190-e76a9b53d7bf"

ClusterLogForwarder 사용자 정의 리소스(CR)에서 infrastructure, audit, application 로그 유형을 all-logs 파이프라인에 대한 입력으로 구성합니다. 또한 이 파이프라인을 cw 출력에 연결하여 us-east-2 리전의 CloudMonitor 인스턴스로 로그를 전달합니다.

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

CloudMonitor의 각 리전에는 세 가지 수준의 오브젝트가 포함되어 있습니다.

  • 로그 그룹

    • 로그 스트림

      • 로그 이벤트

ClusterLogForwarding CR의 groupBy: logType 을 사용하는 경우 inputRefs 의 세 가지 로그 유형은 Amazon Cloudwatch에 3개의 로그 그룹을 생성합니다.

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

각 로그 스트림에는 로그 이벤트가 포함되어 있습니다. busybox Pod에서 로그 이벤트를 보려면 application 로그 그룹에서 로그 스트림을 지정합니다.

$ 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
        },
...

예: 로그 그룹 이름에 접두사 사용자 지정

로그 그룹 이름에서는 기본 infrastructureName 접두사인 mycluster-7977kdemo-group-prefix와 같은 임의의 문자열로 바꿀 수 있습니다. 이 변경을 수행하려면 ClusterLogForwarding CR에서 groupPrefix 필드를 업데이트합니다.

cloudwatch:
    groupBy: logType
    groupPrefix: demo-group-prefix
    region: us-east-2

groupPrefix 값은 기본 infrastructureName 접두사를 대체합니다.

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"demo-group-prefix.application"
"demo-group-prefix.audit"
"demo-group-prefix.infrastructure"

예: 애플리케이션 네임스페이스 이름 뒤에 로그 그룹 이름 지정

클러스터의 각 애플리케이션 네임스페이스에 대해 애플리케이션 네임스페이스 이름을 기반으로 하는 로그 그룹을 CloudWatch에서 생성할 수 있습니다.

애플리케이션 네임스페이스 오브젝트를 삭제하고 이름이 같은 새 항목을 생성하면 CloudMonitor는 이전과 동일한 로그 그룹을 계속 사용합니다.

서로 동일한 이름이 있는 연속적인 애플리케이션 네임스페이스 오브젝트를 고려하는 경우 이 예제에 설명된 접근 방식을 사용합니다. 또는 결과 로그 그룹을 서로 구분해야 하는 경우 대신 다음 "애플리케이션 네임스페이스 UUID에 대한 로그 그룹 설정" 섹션을 참조하십시오.

애플리케이션 네임스페이스의 이름을 기반으로 이름이 인 애플리케이션 로그 그룹을 생성하려면 ClusterLogForwarder CR에서 groupBy 필드의 값을 namespaceName으로 설정합니다.

cloudwatch:
    groupBy: namespaceName
    region: us-east-2

groupBynamespaceName으로 설정하면 애플리케이션 로그 그룹에만 영향을 미칩니다. auditinfrastructure 로그 그룹에는 영향을 미치지 않습니다.

Amazon Cloudwatch에서 각 로그 그룹 이름 끝에 네임스페이스 이름이 표시됩니다. 단일 애플리케이션 네임스페이스인 "app"이 있으므로 다음 출력에서는mycluster-7977k.application 대신 새 mycluster-7977k.app 로그 그룹이 표시됩니다.

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"mycluster-7977k.app"
"mycluster-7977k.audit"
"mycluster-7977k.infrastructure"

이 예제의 클러스터에 여러 애플리케이션 네임스페이스가 포함된 경우 출력에 각 네임스페이스에 하나씩 여러 개의 로그 그룹이 표시됩니다.

groupBy 필드는 애플리케이션 로그 그룹에만 영향을 미칩니다. auditinfrastructure 로그 그룹에는 영향을 미치지 않습니다.

예: 애플리케이션 네임스페이스 UUID 후 로그 그룹 이름 지정

클러스터의 각 애플리케이션 네임스페이스에 대해 애플리케이션 네임스페이스 UUID를 기반으로 하는 로그 그룹을 CloudWatch에서 생성할 수 있습니다.

애플리케이션 네임스페이스 오브젝트를 삭제하고 새 오브젝트를 생성하면 CloudMonitor에서 새 로그 그룹을 생성합니다.

동일한 이름을 가진 연속적인 애플리케이션 네임스페이스 개체를 서로 다른 것으로 간주하는 경우 이 예에서 설명하는 접근 방식을 사용하십시오. 또는 이전의 "애플리케이션 네임스페이스 이름에 대한 로그 그룹 이름 지정" 섹션을 참조하십시오.

애플리케이션 네임스페이스 UUID 후에 로그 그룹의 이름을 지정하려면 ClusterLogForwarder CR에서 groupBy 필드의 값을 namespaceUUID로 설정합니다.

cloudwatch:
    groupBy: namespaceUUID
    region: us-east-2

Amazon Cloudwatch에서 각 로그 그룹 이름 끝에 네임스페이스 UUID가 표시됩니다. 단일 애플리케이션 네임스페이스인 "app"이 있으므로 다음 출력에서는 mycluster-7977k.application 대신 새로운 mycluster-7977k.794e1e1a-b9f5-4958-a190-e76a9b53d7bf 로그 그룹이 표시됩니다.

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

groupBy 필드는 애플리케이션 로그 그룹에만 영향을 미칩니다. auditinfrastructure 로그 그룹에는 영향을 미치지 않습니다.

9.4.15.1. 기존 AWS 역할을 사용하여 AWSIdentityProvider의 시크릿 생성

AWS에 대한 기존 역할이 있는 경우 oc create secret --from-literal 명령을 사용하여 STS로 AWS의 시크릿을 생성할 수 있습니다.

절차

  • CLI에서 다음을 입력하여 AWS의 시크릿을 생성합니다.

    $ 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

9.4.16. STS 활성화된 클러스터에서 Amazon STS로 로그 전달

AWS STS(Security Token Service)가 활성화된 클러스터의 경우 CCO(Cloud Credential Operator) 유틸리티 ccoctl 을 사용하여 AWS 서비스 계정을 수동으로 생성하거나 인증 정보 요청을 생성할 수 있습니다.

사전 요구 사항

  • Red Hat OpenShift에 대한 로깅: 5.5 이상

절차

  1. 아래 템플릿을 사용하여 CredentialsRequest 사용자 정의 리소스 YAML을 생성합니다.

    ECDHE 인증 정보 요청 템플릿

    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

  2. ccoctl 명령 사용하여 CredentialsRequest CR을 사용하여 AWS에 대한 역할을 생성합니다. CredentialsRequest 오브젝트를 사용하면 이 ccoctl 명령은 지정된 OIDC ID 공급자에 연결된 신뢰 정책과 NetNamespace 리소스에 대한 작업을 수행할 수 있는 권한을 부여하는 권한 정책을 사용하여 IAM 역할을 생성합니다. 이 명령은 /< path_to_ccoctl_output_dir>/manifests/openshift-logging-<your_role_name>-credentials.yaml 에 YAML 구성 파일도 생성합니다. 이 시크릿 파일에는 AWS IAM ID 공급자의 인증 중에 사용되는 role_arn 키/값이 포함되어 있습니다.

    $ 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
    <name>은 클라우드 리소스에 태그하는 데 사용되는 이름이며 STS 클러스터 설치 중에 사용되는 이름과 일치해야 합니다.
  3. 생성된 보안을 적용합니다.

    $ oc apply -f output/manifests/openshift-logging-<your_role_name>-credentials.yaml
  4. ClusterLogForwarder 사용자 정의 리소스를 생성하거나 편집합니다.

    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
    1
    레거시 구현에서 CR 이름은 인스턴스 여야 합니다. 다중 로그 전달자 구현에서는 모든 이름을 사용할 수 있습니다.
    2
    레거시 구현에서 CR 네임스페이스는 openshift-logging 이어야 합니다. 다중 로그 전달자 구현에서는 모든 네임스페이스를 사용할 수 있습니다.
    3
    clf-collector 서비스 계정을 지정합니다. 서비스 계정은 로그 전달자가 openshift-logging 네임스페이스에 배포되지 않은 경우에만 다중 로그 전달자 구현에 필요합니다.
    4
    출력 이름을 지정합니다.
    5
    cloudwatch 유형을 지정합니다.
    6
    선택 사항: 로그를 그룹화하는 방법을 지정합니다.
    • logType 은 각 로그 유형에 대한 로그 그룹을 생성합니다.
    • namespaceName은 각 애플리케이션 네임 스페이스에 대한 로그 그룹을 생성합니다. 인프라 및 감사 로그는 영향을 받지 않으며 logType 으로 그룹화됩니다.
    • namespaceUUID는 각 애플리케이션 네임스페이스 UUID에 대한 새 로그 그룹을 생성합니다. 인프라 및 감사 로그를 위해 별도의 로그 그룹도 생성합니다.
    7
    선택 사항: 로그 그룹 이름으로 기본 infrastructureName 접두사를 바꾸려면 문자열을 지정합니다.
    8
    AWS 리전을 지정합니다.
    9
    AWS 인증 정보가 포함된 시크릿의 이름을 지정합니다.
    10
    선택사항: 파이프라인의 이름을 지정합니다.
    11
    파이프라인을 사용하여 전달할 로그 유형 (application, infrastructure, 또는 audit)을 지정합니다.
    12
    이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.

추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.