2.4. LokiStack을 사용하여 로그 저장


애플리케이션, 감사 및 인프라 관련 로그를 저장하도록 LokiStack CR을 구성할 수 있습니다.

Loki는 수평으로 확장 가능한 고가용성 다중 테넌트 로그 집계 시스템으로 OpenShift Observability UI로 시각화할 수 있는 Red Hat OpenShift의 로깅을 위한 GA 로그 저장소로 제공됩니다. OpenShift Logging에서 제공하는 Loki 구성은 사용자가 수집된 로그를 사용하여 빠른 문제 해결을 수행할 수 있도록 설계된 단기 로그 저장소입니다. 이를 위해 Loki의 Red Hat OpenShift 구성에 대한 로깅은 단기 스토리지가 있으며 최근 쿼리에 최적화되어 있습니다.

중요

장기간의 기간 동안의 스토리지 또는 쿼리의 경우 사용자는 클러스터 외부에 있는 저장소를 로그하려고 합니다. Loki 크기 조정은 최대 30일 동안 단기 스토리지에서만 테스트 및 지원됩니다.

2.4.1. Loki 배포 크기 조정

Loki의 크기 조정은 1x.<size> 형식을 따릅니다. 여기서 1x 값은 인스턴스 수이고 < size >는 성능 기능을 지정합니다.

1x.pico 구성은 최소한의 리소스 및 제한 요구 사항으로 단일 Loki 배포를 정의하여 모든 Loki 구성 요소에 대한 HA(고가용성) 지원을 제공합니다. 이 구성은 단일 복제 요소 또는 자동 컴파일이 필요하지 않은 배포에 적합합니다.

디스크 요청은 크기 구성에서 유사합니다. 고객이 다양한 크기를 테스트하여 배포 요구 사항에 가장 적합한지 확인할 수 있습니다.

중요

배포 크기에 대해 숫자 1x 를 변경할 수 없습니다.

표 2.1. Loki 크기 조정
 1x.demo1x.pico [6.1+ only]1x.extra-small1x.small1x.medium

데이터 전송

데모만 사용

50GB/일

100GB/일

500GB/일

2TB/일

초당 쿼리(QPS)

데모만 사용

200ms에서 1-25 QPS

200ms에서 1-25 QPS

25-50 QPS (200ms)

25-75 QPS (200ms)

복제 요인

없음

2

2

2

2

총 CPU 요청

없음

7개의 vCPU

14개의 vCPU

34 vCPU

54 vCPU

ruler을 사용하는 경우 총 CPU 요청

없음

8개의 vCPU

16개의 vCPU

42 vCPU

70개의 vCPU

총 메모리 요청

없음

17GI

31GI

67GI

139Gi

룰러를 사용하는 경우 총 메모리 요청

없음

18GI

35GI

83Gi

171Gi

총 디스크 요청

40Gi

590Gi

430Gi

430Gi

590Gi

ruler을 사용하는 경우 총 디스크 요청

80GI

910Gi

750Gi

750Gi

910Gi

2.4.2. 사전 요구 사항

  • CLI 또는 웹 콘솔을 사용하여 Loki Operator를 설치했습니다.
  • ClusterLogForwarder 를 생성하는 동일한 네임스페이스에 serviceAccount 가 있습니다.
  • serviceAccount 에는 collect-audit-logs,collect-application-logs, collect-infrastructure-logs 클러스터 역할이 할당됩니다.

2.4.3. 코어 설정 및 구성

Loki를 배포하기 위한 역할 기반 액세스 제어, 기본 모니터링 및 Pod 배치입니다.

2.4.4. LokiStack 규칙 RBAC 권한 승인

관리자는 클러스터 역할을 사용자 이름에 바인딩하여 사용자가 자체 경고 및 레코딩 규칙을 생성하고 관리할 수 있습니다. 클러스터 역할은 사용자에게 필요한 RBAC(역할 기반 액세스 제어) 권한이 포함된 ClusterRole 오브젝트로 정의됩니다.

경고 및 레코딩 규칙에 대한 다음 클러스터 역할은 LokiStack에 사용할 수 있습니다.

규칙 이름설명

alertingrules.loki.grafana.com-v1-admin

이 역할의 사용자에게는 경고 규칙을 관리할 수 있는 관리 수준 액세스 권한이 있습니다. 이 클러스터 역할은 loki.grafana.com/v1 API 그룹 내에서 AlertingRule 리소스를 생성, 읽기, 업데이트, 삭제, 나열 및 조사할 수 있는 권한을 부여합니다.

alertingrules.loki.grafana.com-v1-crdview

이 역할의 사용자는 loki.grafana.com/v1 API 그룹 내의 AlertingRule 리소스와 관련된 CRD(Custom Resource Definitions)의 정의를 볼 수 있지만 이러한 리소스를 수정하거나 관리할 수 있는 권한은 없습니다.

alertingrules.loki.grafana.com-v1-edit

이 역할의 사용자는 AlertingRule 리소스를 생성, 업데이트 및 삭제할 수 있는 권한이 있습니다.

alertingrules.loki.grafana.com-v1-view

이 역할의 사용자는 loki.grafana.com/v1 API 그룹 내에서 AlertingRule 리소스를 읽을 수 있습니다. 기존 경고 규칙에 대한 구성, 라벨 및 주석을 검사할 수 있지만 수정할 수는 없습니다.

recordingrules.loki.grafana.com-v1-admin

이 역할의 사용자는 레코딩 규칙을 관리할 수 있는 관리 수준의 액세스 권한이 있습니다. 이 클러스터 역할은 loki.grafana.com/v1 API 그룹 내의 RecordingRule 리소스를 생성, 읽기, 업데이트, 삭제, 나열 및 감시할 수 있는 권한을 부여합니다.

recordingrules.loki.grafana.com-v1-crdview

이 역할의 사용자는 loki.grafana.com/v1 API 그룹 내의 RecordingRule 리소스와 관련된 CRD(Custom Resource Definitions)의 정의를 볼 수 있지만 이러한 리소스를 수정하거나 관리할 수 있는 권한은 없습니다.

recordingrules.loki.grafana.com-v1-edit

이 역할의 사용자는 RecordingRule 리소스를 생성, 업데이트 및 삭제할 수 있는 권한이 있습니다.

recordingrules.loki.grafana.com-v1-view

이 역할의 사용자는 loki.grafana.com/v1 API 그룹 내에서 RecordingRule 리소스를 읽을 수 있습니다. 기존 경고 규칙에 대한 구성, 라벨 및 주석을 검사할 수 있지만 수정할 수는 없습니다.

2.4.4.1. 예

사용자의 클러스터 역할을 적용하려면 기존 클러스터 역할을 특정 사용자 이름에 바인딩해야 합니다.

클러스터 역할은 사용하는 역할 바인딩 유형에 따라 클러스터 또는 네임스페이스 범위일 수 있습니다. RoleBinding 오브젝트가 사용되는 경우 oc adm policy add-role-to-user 명령을 사용하는 경우 클러스터 역할은 지정된 네임스페이스에만 적용됩니다. oc adm policy add-cluster-role-to-user 명령을 사용할 때 ClusterRoleBinding 오브젝트가 사용되는 경우 클러스터 역할은 클러스터의 모든 네임스페이스에 적용됩니다.

다음 예제 명령은 클러스터의 특정 네임스페이스의 경고 규칙에 대해 지정된 사용자 생성, 읽기, 업데이트 및 삭제(CRUD) 권한을 제공합니다.

특정 네임스페이스에서 경고 규칙 CRUD 권한에 대한 클러스터 역할 바인딩 명령의 예

$ oc adm policy add-role-to-user alertingrules.loki.grafana.com-v1-admin -n <namespace> <username>

다음 명령은 모든 네임스페이스의 경고 규칙에 대해 지정된 사용자 관리자 권한을 부여합니다.

관리자 권한에 대한 클러스터 역할 바인딩 명령의 예

$ oc adm policy add-cluster-role-to-user alertingrules.loki.grafana.com-v1-admin <username>

2.4.5. Loki를 사용하여 로그 기반 경고 규칙 생성

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

  • AlertingRule CR에 잘못된 간격 기간이 포함된 경우 잘못된 경고 규칙입니다.
  • AlertingRule CR 에 기간 동안 유효하지 않은 항목이 포함된 경우 잘못된 경고 규칙입니다.
  • AlertingRule CR에 잘못된 LogQL expr 가 포함된 경우 잘못된 경고 규칙입니다.
  • AlertingRule CR에 동일한 이름의 두 개의 그룹이 포함된 경우 잘못된 경고 규칙입니다.
  • 위의 어느 것도 적용되지 않으면 경고 규칙이 유효한 것으로 간주됩니다.
표 2.2. AlertingRule 정의
테넌트 유형AlertingRule CR을 위한 유효한 네임스페이스

애플리케이션

<your_application_namespace>

audit

openshift-logging

인프라

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

프로세스

  1. AlertingRule 사용자 정의 리소스(CR)를 생성합니다.

    인프라 AlertingRule CR의 예

      apiVersion: loki.grafana.com/v1
      kind: AlertingRule
      metadata:
        name: loki-operator-alerts
        namespace: openshift-operators-redhat 1
        labels: 2
          openshift.io/<label_name>: "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 CR이 생성되는 네임스페이스에는 LokiStack spec.rules.namespaceSelector 정의와 일치하는 레이블이 있어야 합니다.
    2
    labels 블록은 LokiStack spec.rules.selector 정의와 일치해야 합니다.
    3
    인프라 테넌트에 대한 AlertingRule CR은 openshift-*, kube-\* 또는 default 네임스페이스에서만 지원됩니다.
    4
    kubernetes_namespace_name: 의 값은 metadata.namespace 값과 일치해야 합니다.
    5
    이 필수 필드의 값은 중요,경고 또는 정보 여야 합니다.
    6
    이 필드는 필수입니다.
    7
    이 필드는 필수입니다.

    애플리케이션 AlertingRule CR의 예

      apiVersion: loki.grafana.com/v1
      kind: AlertingRule
      metadata:
        name: app-user-workload
        namespace: app-ns 1
        labels: 2
          openshift.io/<label_name>: "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 CR이 생성되는 네임스페이스에는 LokiStack spec.rules.namespaceSelector 정의와 일치하는 레이블이 있어야 합니다.
    2
    labels 블록은 LokiStack spec.rules.selector 정의와 일치해야 합니다.
    3
    kubernetes_namespace_name: 의 값은 metadata.namespace 값과 일치해야 합니다.
    4
    이 필수 필드의 값은 중요,경고 또는 정보 여야 합니다.
    5
    이 필수 필드의 값은 규칙에 대한 요약입니다.
    6
    이 필수 필드의 값은 규칙에 대한 자세한 설명입니다.
  2. AlertingRule CR을 적용합니다.

    $ oc apply -f <filename>.yaml

2.4.6. 멤버 목록 생성 실패를 허용하도록 Loki 구성

OpenShift Container Platform 클러스터에서 관리자는 일반적으로 개인 IP 네트워크 범위를 사용합니다. 결과적으로 LokiStack 멤버 목록 구성은 기본적으로 개인 IP 네트워크만 사용하므로 실패합니다.

관리자는 memberlist 구성에 대한 Pod 네트워크를 선택할 수 있습니다. hashRing 사양에서 podIP 주소를 사용하도록 LokiStack CR(사용자 정의 리소스)을 수정할 수 있습니다. LokiStack CR을 구성하려면 다음 명령을 사용합니다.

$ oc patch LokiStack logging-loki -n openshift-logging  --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP"},"type":"memberlist"}}}'

podIP를 포함하는 LokiStack의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  hashRing:
    type: memberlist
    memberlist:
      instanceAddrType: podIP
# ...

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

로그 스트림을 기반으로 보존 정책을 구성할 수 있습니다. 이러한 규칙에 대한 규칙은 전역적으로, 테넌트별로 또는 둘 다 설정할 수 있습니다. 둘 다 구성하는 경우 테넌트 규칙이 글로벌 규칙 앞에 적용됩니다.

중요

s3 버킷 또는 LokiStack 사용자 정의 리소스(CR)에 정의된 보존 기간이 없으면 로그가 정리되지 않고 s3 스토리지를 채울 수 있습니다.

참고

스키마 v13이 권장됩니다.

프로세스

  1. LokiStack CR을 생성합니다.

    • 다음 예와 같이 스트림 기반 보존을 전역적으로 활성화합니다.

      AWS에 대한 글로벌 스트림 기반 보존의 예

      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: v13
          secret:
            name: logging-loki-s3
            type: aws
        storageClassName: gp3-csi
        tenants:
          mode: openshift-logging

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

      AWS에 대한 테넌트별 스트림 기반 보존 예

      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: v13
          secret:
            name: logging-loki-s3
            type: aws
        storageClassName: gp3-csi
        tenants:
          mode: openshift-logging

      1
      테넌트별 보존 정책을 설정합니다. 유효한 테넌트 유형은 애플리케이션,감사인프라 입니다.
      2
      로그 스트림을 정의하는 데 사용되는 LogQL 쿼리 를 포함합니다.
  2. LokiStack CR을 적용합니다.

    $ oc apply -f <filename>.yaml

2.4.8. Loki Pod 배치

Pod의 허용 오차 또는 노드 선택기를 사용하여 Loki Pod가 실행되는 노드를 제어하고 다른 워크로드가 해당 노드를 사용하지 못하도록 할 수 있습니다.

LokiStack CR(사용자 정의 리소스)을 사용하여 로그 저장소 Pod에 허용 오차를 적용하고 노드 사양이 있는 노드에 taint를 적용할 수 있습니다. 노드의 테인트는 테인트를 허용하지 않는 모든 Pod를 거절하도록 노드에 지시하는 키:값 쌍입니다. 다른 Pod에 없는 특정 키:값 쌍을 사용하면 해당 노드에서 로그 저장소 Pod만 실행할 수 있습니다.

노드 선택기가 있는 LokiStack의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor: 1
      nodeSelector:
        node-role.kubernetes.io/infra: "" 2
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
# ...

1
노드 선택기에 적용되는 구성 요소 Pod 유형을 지정합니다.
2
정의된 라벨이 포함된 노드로 이동되는 Pod를 지정합니다.

노드 선택기 및 허용 오차가 있는 LokiStack CR의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
# ...

LokiStack(CR)의 nodeSelector허용 오차 필드를 구성하려면 oc explain 명령을 사용하여 특정 리소스에 대한 설명 및 필드를 볼 수 있습니다.

$ oc explain lokistack.spec.template

출력 예

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: template <Object>

DESCRIPTION:
     Template defines the resource/limits/tolerations/nodeselectors per
     component

FIELDS:
   compactor	<Object>
     Compactor defines the compaction component spec.

   distributor	<Object>
     Distributor defines the distributor component spec.
...

자세한 내용은 특정 필드를 추가할 수 있습니다.

$ oc explain lokistack.spec.template.compactor

출력 예

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: compactor <Object>

DESCRIPTION:
     Compactor defines the compaction component spec.

FIELDS:
   nodeSelector	<map[string]string>
     NodeSelector defines the labels required by a node to schedule the
     component onto it.
...

2.4.8.1. 향상된 신뢰성 및 성능

프로덕션 환경에서 Loki의 안정성 및 효율성을 보장하는 구성입니다.

2.4.8.2. 수명이 짧은 토큰을 사용하여 클라우드 기반 로그 저장소에 대한 인증 활성화

워크로드 ID 페더레이션을 통해 단기 토큰을 사용하여 클라우드 기반 로그 저장소에 인증할 수 있습니다.

프로세스

  • 다음 옵션 중 하나를 사용하여 인증을 활성화합니다.

    • OpenShift Container Platform 웹 콘솔을 사용하여 Loki Operator를 설치하면 수명이 짧은 토큰을 사용하는 클러스터가 자동으로 감지됩니다. 역할을 생성하고 Loki Operator에서 보안을 채우는 CredentialsRequest 오브젝트를 생성하는 데 필요한 데이터를 제공하라는 메시지가 표시됩니다.
    • OpenShift CLI(oc)를 사용하여 Loki Operator를 설치하는 경우 다음 예와 같이 스토리지 공급자에 적절한 템플릿을 사용하여 Subscription 오브젝트를 수동으로 생성해야 합니다. 이 인증 전략은 표시된 스토리지 공급자에 대해서만 지원됩니다.

      Azure 샘플 서브스크립션의 예

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: loki-operator
        namespace: openshift-operators-redhat
      spec:
        channel: "stable-6.0"
        installPlanApproval: Manual
        name: loki-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        config:
          env:
            - name: CLIENTID
              value: <your_client_id>
            - name: TENANTID
              value: <your_tenant_id>
            - name: SUBSCRIPTIONID
              value: <your_subscription_id>
            - name: REGION
              value: <your_region>

      AWS 샘플 서브스크립션 예

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: loki-operator
        namespace: openshift-operators-redhat
      spec:
        channel: "stable-6.0"
        installPlanApproval: Manual
        name: loki-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        config:
          env:
          - name: ROLEARN
            value: <role_ARN>

2.4.8.3. 노드 장애를 허용하도록 Loki 구성

Loki Operator는 Pod 유사성 방지 규칙을 설정하여 동일한 구성 요소의 Pod가 클러스터의 다른 사용 가능한 노드에 예약되도록 요청할 수 있습니다.

유사성은 예약할 노드를 제어하는 Pod의 속성입니다. 유사성 방지는 Pod가 노드에서 예약되지 않도록 하는 Pod의 속성입니다.

OpenShift Container Platform에서 Pod 유사성Pod 유사성 방지를 사용하면 다른 Pod의 키 값 라벨에 따라 Pod를 예약할 수 있는 노드를 제한할 수 있습니다.

Operator는 compactor,distributor,gateway,indexGateway,ingester,querier,queryFrontendruler 구성 요소를 포함하는 모든 Loki 구성 요소에 대해 기본 기본 podAntiAffinity 규칙을 설정합니다.

requiredDuringSchedulingIgnoredDuringExecution 필드에서 필요한 설정을 구성하여 Loki 구성 요소의 기본 podAntiAffinity 설정을 덮어쓸 수 있습니다.

ingester 구성 요소에 대한 사용자 설정 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    ingester:
      podAntiAffinity:
      # ...
        requiredDuringSchedulingIgnoredDuringExecution: 1
        - labelSelector:
            matchLabels: 2
              app.kubernetes.io/component: ingester
          topologyKey: kubernetes.io/hostname
# ...

1
필수 규칙을 정의하는 스탠자입니다.
2
규칙을 적용하려면 일치해야 하는 키-값 쌍(레이블)입니다.

2.4.8.4. 클러스터를 다시 시작하는 동안 LokiStack 동작

OpenShift Container Platform 클러스터가 다시 시작되면 LokiStack 수집 및 쿼리 경로가 노드에 사용 가능한 사용 가능한 CPU 및 메모리 리소스 내에서 계속 작동합니다. 즉, OpenShift Container Platform 클러스터 업데이트 중에 LokiStack에 대한 다운 타임이 없습니다. 이 동작은 PodDisruptionBudget 리소스를 사용하여 수행됩니다. Loki Operator는 특정 조건에서 정상적인 작업을 보장하기 위해 구성 요소별로 사용 가능한 최소 Pod 수를 결정하는 Loki의 PodDisruptionBudget 리소스를 프로비저닝합니다.

2.4.8.5. 고급 배포 및 확장성

고가용성, 확장성 및 오류 처리를 위한 특수 구성입니다.

2.4.8.6. 영역 인식 데이터 복제

Loki Operator는 Pod 토폴로지 분배 제약 조건을 통해 영역 인식 데이터 복제를 지원합니다. 이 기능을 사용하면 단일 영역 장애가 발생할 경우 로그 손실에 대한 안정성과 보호 장치가 향상됩니다. 배포 크기를 1x.extra- windows ,1x. ngressController 또는 1x.medium 으로 구성하는 경우 replication.factor 필드가 자동으로 2로 설정됩니다.

적절한 복제를 위해서는 복제 요인에서 지정한 만큼 이상의 가용성 영역이 있어야 합니다. 복제 요인보다 가용성 영역을 더 많이 보유할 수는 있지만 영역이 줄어들면 오류를 작성할 수 있습니다. 각 영역은 최적의 작업을 위해 동일한 수의 인스턴스를 호스팅해야 합니다.

영역 복제가 활성화된 LokiStack CR의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
 name: logging-loki
 namespace: openshift-logging
spec:
 replicationFactor: 2 1
 replication:
   factor: 2 2
   zones:
   -  maxSkew: 1 3
      topologyKey: topology.kubernetes.io/zone 4

1
더 이상 사용되지 않는 필드로 입력된 값은 replication.factor 로 덮어씁니다.
2
이 값은 배포 크기가 설정 시 선택되면 자동으로 설정됩니다.
3
두 토폴로지 도메인 간 최대 Pod 수 차이입니다. 기본값은 1이며 값 0을 지정할 수 없습니다.
4
노드 레이블에 해당하는 토폴로지 키 형태로 영역을 정의합니다.

2.4.8.7. 실패한 영역에서 Loki Pod 복구

OpenShift Container Platform에서 특정 가용성 영역 리소스에 액세스할 수 없게 되면 영역 오류가 발생합니다. 가용성 영역은 클라우드 공급자의 데이터 센터 내의 격리된 영역이며 중복성과 내결함성을 강화하기 위한 것입니다. OpenShift Container Platform 클러스터가 이를 처리하도록 구성되지 않은 경우 영역 실패로 인해 서비스 또는 데이터가 손실될 수 있습니다.

Loki 포드는 StatefulSet 의 일부이며 StorageClass 오브젝트에서 프로비저닝한 PVC(영구 볼륨 클레임)와 함께 제공됩니다. 각 Loki Pod 및 해당 PVC는 동일한 영역에 있습니다. 클러스터에서 영역 오류가 발생하면 StatefulSet 컨트롤러에서 실패한 영역에서 영향을 받는 Pod를 자동으로 복구하려고 합니다.

주의

다음 절차에서는 실패한 영역의 PVC와 그 안에 포함된 모든 데이터를 삭제합니다. 완전한 데이터 손실을 방지하려면 LokiStack CR의 복제 요소 필드를 항상 1보다 큰 값으로 설정하여 Loki가 복제되도록 해야 합니다.

사전 요구 사항

  • LokiStack CR에 1보다 큰 복제 인수가 있는지 확인합니다.
  • 컨트롤 플레인에서 감지한 영역 장애와 실패한 영역의 노드는 클라우드 공급자 통합으로 표시됩니다.

StatefulSet 컨트롤러는 실패한 영역에서 Pod 일정 변경을 자동으로 시도합니다. 연결된 PVC도 실패한 영역에 있기 때문에 다른 영역으로 자동 일정 조정이 작동하지 않습니다. 새 영역에서 상태 저장 Loki Pod와 프로비저닝된 PVC를 다시 생성할 수 있도록 실패한 영역에서 PVC를 수동으로 삭제해야 합니다.

프로세스

  1. 다음 명령을 실행하여 Pending 상태의 Pod를 나열합니다.

    $ oc get pods --field-selector status.phase==Pending -n openshift-logging

    oc get pods 출력 예

    NAME                           READY   STATUS    RESTARTS   AGE 1
    logging-loki-index-gateway-1   0/1     Pending   0          17m
    logging-loki-ingester-1        0/1     Pending   0          16m
    logging-loki-ruler-1           0/1     Pending   0          16m

    1
    해당 PVC가 실패한 영역에 있기 때문에 이러한 Pod는 Pending 상태입니다.
  2. 다음 명령을 실행하여 Pending 상태의 PVC를 나열합니다.

    $ oc get pvc -o=json -n openshift-logging | jq '.items[] | select(.status.phase == "Pending") | .metadata.name' -r

    oc get pvc 출력 예

    storage-logging-loki-index-gateway-1
    storage-logging-loki-ingester-1
    wal-logging-loki-ingester-1
    storage-logging-loki-ruler-1
    wal-logging-loki-ruler-1

  3. 다음 명령을 실행하여 Pod의 PVC를 삭제합니다.

    $ oc delete pvc <pvc_name>  -n openshift-logging
  4. 다음 명령을 실행하여 Pod를 삭제합니다.

    $ oc delete pod <pod_name>  -n openshift-logging

    이러한 오브젝트가 성공적으로 삭제되면 사용 가능한 영역에서 자동으로 다시 예약해야 합니다.

2.4.8.7.1. 종료 상태의 PVC 문제 해결

PVC 메타데이터 종료자가 kubernetes.io/pv-protection 으로 설정된 경우 PVC는 삭제 없이 종료 상태로 중단될 수 있습니다. 종료자를 제거하면 PVC가 성공적으로 삭제될 수 있습니다.

  • 아래 명령을 실행하여 각 PVC의 종료자를 제거한 다음 삭제를 다시 시도합니다.

    $ oc patch pvc <pvc_name> -p '{"metadata":{"finalizers":null}}' -n openshift-logging

2.4.8.8. Loki 속도 제한 오류 문제 해결

로그 전달자 API에서 속도 제한을 초과하는 대규모 메시지 블록을 Loki로 전달하면 Loki는 속도 제한(429) 오류를 생성합니다.

이러한 오류는 정상적인 작동 중에 발생할 수 있습니다. 예를 들어 이미 일부 로그가 있는 클러스터에 로깅을 추가할 때 로깅이 기존 로그 항목을 모두 수집하는 동안 속도 제한 오류가 발생할 수 있습니다. 이 경우 새 로그 추가 속도가 총 속도 제한보다 작으면 기록 데이터가 결국 수집되고 사용자 개입 없이도 속도 제한 오류가 해결됩니다.

속도 제한 오류가 계속 발생하는 경우 LokiStack CR(사용자 정의 리소스)을 수정하여 문제를 해결할 수 있습니다.

중요

LokiStack CR은 Grafana 호스팅 Loki에서 사용할 수 없습니다. 이는 Grafana 호스팅 Loki 서버에는 적용되지 않습니다.

조건

  • Log Forwarder API는 로그를 Loki로 전달하도록 구성되어 있습니다.
  • 시스템에서 2MB보다 큰 메시지 블록을 Loki로 보냅니다. 예를 들면 다음과 같습니다.

    "values":[["1630410392689800468","{\"kind\":\"Event\",\"apiVersion\":\
    .......
    ......
    ......
    ......
    \"received_at\":\"2021-08-31T11:46:32.800278+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-31T11:46:32.799692+00:00\",\"viaq_index_name\":\"audit-write\",\"viaq_msg_id\":\"MzFjYjJkZjItNjY0MC00YWU4LWIwMTEtNGNmM2E5ZmViMGU4\",\"log_type\":\"audit\"}"]]}]}
  • oc logs -n openshift-logging -l component=collector 를 입력하면 클러스터의 수집기 로그에 다음 오류 메시지 중 하나가 포함된 행이 표시됩니다.

    429 Too Many Requests Ingestion rate limit exceeded

    Vector 오류 메시지의 예

    2023-08-25T16:08:49.301780Z  WARN sink{component_kind="sink" component_id=default_loki_infra component_type=loki component_name=default_loki_infra}: vector::sinks::util::retries: Retrying after error. error=Server responded with an error: 429 Too Many Requests internal_log_rate_limit=true

    Fluentd 오류 메시지의 예

    2023-08-30 14:52:15 +0000 [warn]: [default_loki_infra] failed to flush the buffer. retry_times=2 next_retry_time=2023-08-30 14:52:19 +0000 chunk="604251225bf5378ed1567231a1c03b8b" error_class=Fluent::Plugin::LokiOutput::LogPostError error="429 Too Many Requests Ingestion rate limit exceeded for user infrastructure (limit: 4194304 bytes/sec) while attempting to ingest '4082' lines totaling '7820025' bytes, reduce log volume or contact your Loki administrator to see if the limit can be increased\n"

    이 오류는 수신 끝점에도 표시됩니다. 예를 들어 LokiStack ingester Pod에서 다음을 수행합니다.

    Loki ingester 오류 메시지의 예

    level=warn ts=2023-08-30T14:57:34.155592243Z caller=grpc_logging.go:43 duration=1.434942ms method=/logproto.Pusher/Push err="rpc error: code = Code(429) desc = entry with timestamp 2023-08-30 14:57:32.012778399 +0000 UTC ignored, reason: 'Per stream rate limit exceeded (limit: 3MB/sec) while attempting to ingest for stream

프로세스

  • LokiStack CR에서 ingestionBurstSizeingestionRate 필드를 업데이트합니다.

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki
      namespace: openshift-logging
    spec:
      limits:
        global:
          ingestion:
            ingestionBurstSize: 16 1
            ingestionRate: 8 2
    # ...
    1
    ingestionBurstSize 필드는 배포자 복제본당 최대 로컬 속도 제한 샘플 크기를 MB로 정의합니다. 이 값은 하드 제한입니다. 이 값을 단일 푸시 요청에 예상되는 최대 로그 크기로 설정합니다. ingestionBurstSize 값보다 큰 단일 요청은 허용되지 않습니다.
    2
    ingestionRate 필드는 초당 수집된 샘플의 최대 양(MB)에 대한 소프트 제한입니다. 로그 비율이 제한을 초과하는 경우 속도 제한 오류가 발생하지만 수집기는 로그를 다시 시도합니다. 총 평균이 제한보다 작으면 사용자 개입 없이 시스템을 복구하고 오류가 해결됩니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.