11.4. 로그 전달 구성

절차

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

   이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.

절차

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

절차

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

절차

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 키가 포함되어야 합니다. 그러지 않으면 http 및 https 접두사의 경우 사용자 이름과 암호가 포함된 시크릿을 지정할 수 있습니다. 레거시 구현에서는 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

절차

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 키가 포함되어야 합니다. 그러지 않으면 http 및 https 접두사의 경우 사용자 이름과 암호가 포함된 시크릿을 지정할 수 있습니다. 레거시 구현에서는 openshift-logging 프로젝트에 시크릿이 있어야 합니다. 자세한 내용은 다음 "사용자 이름 및 암호가 포함된 시크릿 설정 예"를 참조하십시오.

   9

   선택사항: 파이프라인의 이름을 지정합니다.

   10

   파이프라인을 사용하여 전달할 로그 유형 (application, infrastructure, 또는 audit)을 지정합니다.

   11

   이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.

   12

   선택사항: default 출력을 지정하여 내부 Elasticsearch 인스턴스로 로그를 보냅니다.

   13

   선택 사항: 문자열. 로그에 추가할 하나 이상의 레이블입니다.

2. ClusterLogForwarder CR을 적용합니다.

   $ oc apply -f <filename>.yaml

1. 다음 예와 유사한 Secret YAML 파일을 생성합니다. username 및 password 필드에 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

절차

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

절차

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

절차

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

   brokers 및 topic 키가 있는 kafka 키를 지정합니다.

   2

   brokers 키를 사용하여 하나 이상의 브로커 배열을 지정합니다.

   3

   topic 키를 사용하여 로그를 수신하는 대상 주제를 지정합니다.

3. 다음 명령을 실행하여 ClusterLogForwarder CR을 적용합니다.

   $ oc apply -f <filename>.yaml

절차

1. aws_access_key_id 및 aws_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

절차

1. AWS 계정을 준비합니다.

   1. 다음 콘텐츠를 사용하여 IAM 정책 JSON 파일을 생성합니다.

      {
      "Version": "2012-10-17",
      "Statement": [
          {
          "Effect": "Allow",
          "Action": [
            "logs:CreateLogGroup",
            "logs:CreateLogStream",
            "logs:DescribeLogGroups",
            "logs:DescribeLogStreams",
            "logs:PutLogEvents",
            "logs:PutRetentionPolicy"
          ],
          "Resource": "arn:aws:logs:*:*:*"
          }
        ]
      }

   2. 다음 콘텐츠를 사용하여 IAM 신뢰 JSON 파일을 생성합니다.

      {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "Federated": "arn:aws:iam::<your_aws_account_id>:oidc-provider/<openshift_oidc_provider>" 1
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
              "StringEquals": {
                "<openshift_oidc_provider>:sub": "system:serviceaccount:openshift-logging:logcollector" 2
              }
            }
          }
        ]
      }

      1

      AWS 계정 ID와 OpenShift OIDC 공급자 끝점을 지정합니다. 다음 명령을 실행하여 끝점을 가져옵니다.

      $ rosa describe cluster \
        -c $(oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}') \
        -o yaml | awk '/oidc_endpoint_url/ {print $2}' | cut -d '/' -f 3,4

      2

      OpenShift OIDC 엔드포인트를 다시 지정합니다.

   3. IAM 역할을 생성합니다.

      $ aws iam create-role
        --role-name “<your_rosa_cluster_name>-RosaCloudWatch” \
        --assume-role-policy-document file://<your_trust_file_name>.json \
        --query Role.Arn \
        --output text

      출력을 저장합니다. 다음 단계에서 사용할 것입니다.

   4. IAM 정책을 생성합니다.

      $ aws iam create-policy \
      --policy-name "RosaCloudWatch" \
      --policy-document file:///<your_policy_file_name>.json \
      --query Policy.Arn \
      --output text

      출력을 저장합니다. 다음 단계에서 사용할 것입니다.

   5. IAM 정책을 IAM 역할에 연결합니다.

      $ aws iam attach-role-policy \
       --role-name “<your_rosa_cluster_name>-RosaCloudWatch” \
       --policy-arn <policy_ARN> 1

      1

      policy_ARN 을 정책을 생성하는 동안 저장한 출력으로 바꿉니다.

2. Red Hat OpenShift Logging Operator의 Secret YAML 파일을 생성합니다.

   apiVersion: v1
   kind: Secret
   metadata:
     name: cloudwatch-credentials
     namespace: openshift-logging
   stringData:
     credentials: |-
       [default]
       sts_regional_endpoints = regional
       role_arn: <role_ARN>  1
       web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token

   1

   role_ARN 을 역할을 생성하는 동안 저장한 출력으로 바꿉니다.

3. 시크릿을 생성합니다.

   $ oc apply -f cloudwatch-credentials.yaml

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

   서비스 계정의 이름입니다. 서비스 계정은 로그 전달자가 openshift-logging 네임스페이스에 배포되지 않은 경우에만 다중 로그 전달자 구현에 필요합니다.

   4

   출력 이름을 지정합니다.

   5

   cloudwatch 유형을 지정합니다.

   6

   선택 사항: 로그를 그룹화하는 방법을 지정합니다.

   • logType은 각 로그 유형에 대한 로그 그룹을 생성합니다.
   • namespaceName은 각 애플리케이션 네임 스페이스에 대한 로그 그룹을 생성합니다. 인프라 및 감사 로그는 영향을 받지 않으며 logType 에 의해 그룹화된 상태로 유지됩니다.
   • namespaceUUID는 각 애플리케이션 네임스페이스 UUID에 대한 새 로그 그룹을 생성합니다. 인프라 및 감사 로그를 위해 별도의 로그 그룹도 생성합니다.

   7

   선택 사항: 로그 그룹 이름으로 기본 infrastructureName 접두사를 바꾸려면 문자열을 지정합니다.

   8

   AWS 리전을 지정합니다.

   9

   이전에 생성한 시크릿의 이름을 지정합니다.

   10

   선택사항: 파이프라인의 이름을 지정합니다.

   11

   파이프라인을 사용하여 전달할 로그 유형 (application, infrastructure, 또는 audit)을 지정합니다.

   12

   이 파이프라인으로 로그를 전달할 때 사용할 출력 이름을 지정합니다.