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
권한이 있는 사용자를 위한 새 그룹을 생성합니다.
절차
다음 명령을 입력하여 새 그룹을 생성합니다.
$ oc adm groups new cluster-admin
다음 명령을 입력하여 원하는 사용자를
cluster-admin
그룹에 추가합니다.$ oc adm groups add-users cluster-admin <username>
다음 명령을 입력하여
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
,queryFrontend
및 ruler
구성 요소를 포함하는 모든 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 # ...
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
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를 수동으로 삭제해야 합니다.
절차
다음 명령을 실행하여
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
상태입니다.
다음 명령을 실행하여
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
다음 명령을 실행하여 Pod의 PVC를 삭제합니다.
oc delete pvc __<pvc_name>__ -n openshift-logging
그런 다음 다음 명령을 실행하여 Pod를 삭제합니다.
oc delete pod __<pod_name>__ -n openshift-logging
이러한 오브젝트가 성공적으로 삭제되면 사용 가능한 영역에서 자동으로 다시 예약해야 합니다.
12.3.4.1.1. 종료 상태의 PVC 문제 해결
PVC 메타데이터 종료자가 kubernetes.io/pv-protection
으로 설정된 경우 PVC는 삭제 없이 종료 상태로 중단될 수 있습니다. 종료자를 제거하면 PVC가 성공적으로 삭제될 수 있습니다.
아래 명령을 실행하여 각 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
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
12.3.6. CloudEvent를 사용하여 스트림 기반 보존 활성화
추가 리소스
로깅 버전 5.6 이상을 사용하면 로그 스트림에 따라 보존 정책을 구성할 수 있습니다. 이러한 규칙은 테넌트별로 또는 둘 다 전역적으로 설정할 수 있습니다. 둘 다 구성하면 글로벌 규칙 이전에 테넌트 규칙이 적용됩니다.
스트림 기반 보존을 활성화하려면
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
테넌트당 스트림 기반 보존 예
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
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에서ingestionBurstSize
및ingestionRate
필드를 업데이트합니다.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 # ...