2.4. 로깅 배포 구성

각 Operator가 구현한 CR(사용자 정의 리소스) YAML 파일을 사용하여 로깅 하위 시스템 배포를 구성할 수 있습니다.

Red Hat Openshift Logging Operator:

  • ClusterLogging (CL) - 현재 각 노드에서 실행되는 데몬 세트에서 모두 구현된 수집기 및 전달자를 배포합니다.
  • ClusterLogForwarder (CLF) - 사용자 구성별로 로그를 전달하도록 수집기 구성을 생성합니다.

ScanSetting Operator:

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

OpenShift Elasticsearch Operator:

참고

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

  • Elasticsearch - Elasticsearch 인스턴스를 기본 로그 저장소로 구성하고 배포합니다.
  • Kibana - 로그를 검색, 쿼리 및 볼 수 있도록 Kibana 인스턴스를 구성하고 배포합니다.

Red Hat OpenShift에서 로깅 하위 시스템을 구성하는 데 지원되는 방법은 이 설명서에 설명된 옵션을 사용하여 구성하는 것입니다. 다른 구성은 지원되지 않으므로 사용하지 마십시오. 구성 패러다임은 OpenShift Container Platform 릴리스마다 변경될 수 있으며 이러한 경우는 모든 구성 가능성이 제어되는 경우에만 정상적으로 처리될 수 있습니다. 이 문서에 설명된 것과 다른 구성을 사용하는 경우 Operator가 차이를 조정하므로 변경 사항이 사라집니다. Operator는 원래 기본적으로 모든 항목을 정의된 상태로 되돌립니다.

참고

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

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

로깅 버전 5.6 이상을 사용하면 로그 스트림에 따라 보존 정책을 구성할 수 있습니다. 이러한 규칙은 테넌트별로 또는 둘 다 전역적으로 설정할 수 있습니다. 둘 다 구성하면 글로벌 규칙 이전에 테넌트 규칙이 적용됩니다.

  1. 스트림 기반 보존을 활성화하려면 ScanSetting Stack CR(사용자 정의 리소스)을 생성하거나 편집합니다. 
oc create -f <file-name>.yaml
  1. 아래 예제를 참조하여stack CR을 구성할 수 있습니다.

전역 스트림 기반 보존의 예

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

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

테넌트당 스트림 기반 보존 예

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

1
테넌트별 보존 정책을 설정합니다. 유효한 테넌트 유형은 애플리케이션,감사 및 인프라 입니다.
2
로그 스트림을 정의하는 데 사용되는 LogQL 쿼리를 포함합니다.
  1. 그런 다음 설정을 적용합니다. 
oc apply -f <file-name>.yaml
참고

이는 저장된 로그의 보존을 관리하기 위한 것이 아닙니다. 지원되는 최대 30일 동안의 저장된 로그의 글로벌 보존 기간은 오브젝트 스토리지로 구성됩니다.

2.4.2. 다중 라인 예외 탐지 활성화

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

주의

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

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

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

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

2.4.2.1. 세부 정보

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

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

언어fluentdvector

Java

✓

✓

JS

✓

✓

Ruby

✓

✓

Python

✓

✓

Golang

✓

✓

PHP

✓

 

Dart

✓

✓

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

2.4.3. CloudEvent를 사용하여 로그 기반 경고 활성화

CloudEvent 경고 규칙은 LogQL 을 사용하고 Prometheus 형식을 따릅니다. AlertingRule CR(사용자 정의 리소스)을 생성하여 로그 기반 경고를 설정할 수 있습니다. 애플리케이션,감사 또는 인프라 테넌트에 대해 AlertingRule CR을 생성할 수 있습니다.

테넌트 유형유효한 네임스페이스

애플리케이션

 

audit

openshift-logging

인프라

openshift-/*, kube-/\*, default

로컬 Alertmanager 인스턴스를 비활성화하지 않는 한 openshift-monitoring 네임스페이스의 CMO(Cluster Monitoring Operator) Alertmanager로 애플리케이션, 감사 및 인프라 경고가 전송됩니다.

별도의 Alertmanager 인스턴스를 활성화하지 않는 한 기본적으로 애플리케이션 경고는 openshift-user-workload-monitoring 네임스페이스에서 CMO Alertmanager 로 전송되지 않습니다.

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

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

사전 요구 사항

  • Red Hat OpenShift Operator 5.7 이상의 하위 시스템 로깅
  • OpenShift Container Platform 4.13 이상

절차

  1. AlertingRule CR을 생성합니다. 

    oc create -f <file-name>.yaml

  2. 다음 예제를 사용하여 AlertingRule CR을 채웁니다.

    인프라 경고Rule CR 예

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

    1
    이 AlertingRule이 생성된 네임스페이스에 는 CloudEventStack spec.rules.namespaceSelector 정의와 일치하는 레이블이 있어야 합니다.
    2
    레이블 블록은>-<Stack spec.rules.selector 정의와 일치해야 합니다.
    3
    인프라 테넌트에 대한 AlertingRules는 openshift-*, kube-\* 또는 default 네임스페이스에서만 지원됩니다.
    4
    kubernetes_namespace_name: metadata.namespace 의 값과 일치해야 합니다.
    5
    필수 필드입니다. critical,warning, info 여야 합니다.
    6
    필수 필드입니다.
    7
    필수 필드입니다.

    애플리케이션 AlertingRule CR의 예

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

    1
    이 AlertingRule이 생성된 네임스페이스에 는 CloudEventStack spec.rules.namespaceSelector 정의와 일치하는 레이블이 있어야 합니다.
    2
    레이블 블록은>-<Stack spec.rules.selector 정의와 일치해야 합니다.
    3
    kubernetes_namespace_name: metadata.namespace 의 값과 일치해야 합니다.
    4
    필수 필드입니다. critical,warning, info 여야 합니다.
    5
    필수 필드입니다. 규칙 요약입니다.
    6
    필수 필드입니다. 규칙에 대한 자세한 설명입니다.

  3. CR을 적용합니다. 

    oc apply -f <file-name>.yaml