12.3. LokiStack 로그 저장소 구성


로깅 설명서에서 LokiStack 은 AWS 인증 통합에서 Red Hat OpenShift Service와 Loki 및 web proxy의 로깅 지원 조합을 나타냅니다. CloudEventStack의 프록시는 AWS 인증에서 Red Hat OpenShift Service를 사용하여 멀티 테넌시를 적용합니다. Loki 는 개별 구성 요소 또는 외부 저장소로 로그 저장소를 나타냅니다.

12.3.1. cluster-admin 사용자 역할의 새 그룹 생성

중요

cluster-admin 사용자로 여러 네임스페이스에 대한 애플리케이션 로그를 쿼리합니다. 여기서 클러스터의 모든 네임스페이스 합계는 5120보다 큰 오류입니다: 입력 크기가 너무 긴 (XXXX > 5120) 오류가 발생했습니다. LokiStack의 로그에 대한 액세스를 보다 효과적으로 제어하려면 cluster-admin 사용자를 cluster-admin 그룹의 멤버로 설정합니다. cluster-admin 그룹이 없는 경우 해당 그룹을 생성하고 원하는 사용자를 추가합니다.

다음 절차에 따라 cluster-admin 권한이 있는 사용자를 위한 새 그룹을 생성합니다.

절차

  1. 다음 명령을 입력하여 새 그룹을 생성합니다.

    $ oc adm groups new cluster-admin
  2. 다음 명령을 입력하여 원하는 사용자를 cluster-admin 그룹에 추가합니다.

    $ oc adm groups add-users cluster-admin <username>
  3. 다음 명령을 입력하여 cluster-admin 사용자 역할을 그룹에 추가합니다.

    $ oc adm policy add-cluster-role-to-group cluster-admin cluster-admin

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

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

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

로깅 5.8 이상 버전에서 Loki Operator는 Pod 유사성 방지 규칙 설정을 지원하여 동일한 구성 요소의 Pod가 클러스터의 다른 사용 가능한 노드에 예약되도록 요청합니다.

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

AWS의 Red Hat OpenShift Service에서 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
규칙을 적용하려면 일치해야 하는 키-값 쌍(레이블)입니다.

12.3.4. 영역 인식 데이터 복제

로깅 5.8 이상 버전에서 Loki Operator는 Pod 토폴로지 분배 제약 조건을 통해 영역 인식 데이터 복제를 지원합니다. 이 기능을 사용하면 단일 영역 장애가 발생할 경우 로그 손실에 대한 안정성과 보호 장치가 향상됩니다. 배포 크기를 1x.extra. tekton ,1x. tekton 또는 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
노드 레이블에 해당하는 토폴로지 키 형태로 영역을 정의합니다.

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

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

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

주의

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

사전 요구 사항

  • 로깅 버전 5.8 이상
  • 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

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

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

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

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

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

12.3.5. Loki 로그에 대한 세분화된 액세스

로깅 5.8 이상에서 Red Hat OpenShift Logging Operator는 기본적으로 모든 사용자에게 로그에 대한 액세스 권한을 부여하지 않습니다. 관리자는 Operator가 업그레이드되고 이전 구성이 적용되지 않는 한 사용자 액세스를 구성해야 합니다. 구성 및 필요에 따라 다음을 사용하여 로그에 대한 미세 액세스를 구성할 수 있습니다.

  • 클러스터 전체 정책
  • 네임스페이스 범위 정책
  • 사용자 정의 관리자 그룹 생성

관리자는 배포에 적합한 역할 바인딩 및 클러스터 역할 바인딩을 생성해야 합니다. Red Hat OpenShift Logging Operator는 다음과 같은 클러스터 역할을 제공합니다.

  • cluster-logging-application-view 는 애플리케이션 로그를 읽을 수 있는 권한을 부여합니다.
  • cluster-logging-infrastructure-view 는 인프라 로그를 읽을 수 있는 권한을 부여합니다.
  • cluster-logging-audit-view 는 감사 로그를 읽을 수 있는 권한을 부여합니다.

이전 버전에서 업그레이드한 경우 추가 클러스터 역할 logging-application-logs-reader 및 관련 클러스터 역할 바인딩 logging-all-authenticated-application-logs-reader 는 이전 버전과의 호환성을 제공하여 네임스페이스에서 인증된 모든 사용자 읽기 액세스를 허용합니다.

참고

네임스페이스별 액세스 권한이 있는 사용자는 애플리케이션 로그를 쿼리할 때 네임스페이스를 제공해야 합니다.

12.3.5.1. 클러스터 전체 액세스

클러스터 역할 바인딩 리소스는 클러스터 역할을 참조하고 클러스터 전체 권한을 설정합니다.

클러스터 역할 바인딩 예

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: logging-all-application-logs-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-logging-application-view 1
subjects: 2
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

1
추가 ClusterRolescluster-logging-infrastructure-viewcluster-logging-audit-view 입니다.
2
이 개체가 적용되는 사용자 또는 그룹을 지정합니다.

12.3.5.2. 네임스페이스가 지정된 액세스

RoleBinding 리소스는 ClusterRole 오브젝트와 함께 사용하여 사용자 또는 그룹이 로그에 액세스할 수 있는 네임스페이스를 정의할 수 있습니다.

RoleBinding의 예

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: allow-read-logs
  namespace: log-test-0 1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-logging-application-view
subjects:
- kind: User
  apiGroup: rbac.authorization.k8s.io
  name: testuser-0

1
RoleBinding 이 적용되는 네임스페이스를 지정합니다.

12.3.5.3. 사용자 정의 관리자 그룹 액세스

광범위한 권한이 필요한 사용자가 많은 대규모 배포가 있는 경우 adminGroup 필드를 사용하여 사용자 지정 그룹을 생성할 수 있습니다. LokiStack CR의 adminGroups 필드에 지정된 그룹의 멤버인 사용자는 관리자로 간주됩니다. admin 사용자는 cluster-logging-application-view 역할도 할당한 경우 모든 네임스페이스의 모든 애플리케이션 로그에 액세스할 수 있습니다.

LokiStack CR의 예

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  tenants:
    mode: openshift-logging 1
    openshift:
      adminGroups: 2
      - cluster-admin
      - custom-admin-group 3

1
사용자 지정 관리 그룹은 이 모드에서만 사용할 수 있습니다.
2
이 필드에 빈 목록 [] 값을 입력하면 관리자 그룹이 비활성화됩니다.
3
기본 그룹 덮어쓰기(system:cluster-admins,cluster-admin,dedicated-admin)

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

추가 리소스

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

  1. 스트림 기반 보존을 활성화하려면 LokiStack 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 쿼리를 포함합니다.
  2. LokiStack CR을 적용합니다.

    $ oc apply -f <filename>.yaml
참고

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

12.3.7. 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)에 대한 소프트 제한입니다. 로그 비율이 제한을 초과하는 경우 속도 제한 오류가 발생하지만 수집기는 로그를 다시 시도합니다. 총 평균이 제한보다 작으면 사용자 개입 없이 시스템을 복구하고 오류가 해결됩니다.

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

OpenShift 클러스터에서 관리자는 일반적으로 개인 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
# ...

12.3.9. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.