Theory
인프라
Loki 공식 문서 번역
setup
마이그레이션
`loki-distributed`에서 마이그레이션

loki-distributed Helm 차트에서 마이그레이션

원본: https://grafana.com/docs/loki/latest/setup/migrate/migrate-from-distributed/ (opens in a new tab)

이 가이드는 loki-distributed Helm 차트(작성 시점 v0.63.2)에서 loki Helm 차트 v3.0 이상으로 마이그레이션하는 과정을 안내합니다. 이 프로세스는 기존 loki-distributed 설치와 함께 새 loki Helm 차트를 배포하는 것으로 구성됩니다. 새 클러스터를 기존 클러스터의 링에 연결하여 하나의 큰 클러스터를 만듭니다. 이렇게 하면 데이터 손실 없이 안전하게 loki-distributed 구성 요소를 수동으로 중단할 수 있습니다.

시작하기 전에:

마이그레이션 프로세스 중 데이터 손실이 없는지 확인하기 위해 기존 클러스터와 새 클러스터를 모두 모니터링할 수 있는 Grafana 인스턴스를 사용하는 것이 좋습니다. loki 차트에는 대시보드를 포함한 자체 모니터링 기능이 함께 제공됩니다. 이는 새 클러스터가 가동될 때 상태를 모니터링하는 데 유용합니다.

먼저 기존 Grafana Agent 또는 Promtail 구성(환경에서 로그를 스크래핑하는 모든 것)을 업데이트하여 새 배포를 제외하도록 시작합니다. 새 loki 차트는 자체 모니터링 메커니즘과 함께 제공되므로 두 번 스크래핑되어 중복 로그가 생성되지 않도록 해야 합니다. 가장 좋은 방법은 다음과 같이 새 배포에서 로그를 삭제하는 재레이블 구성을 사용하는 것입니다.

- source_labels:
  - "__meta_kubernetes_pod_label_app_kubernetes_io_component"
  regex: "(canary|read|write)"
  action: "drop"

이는 새 배포가 read (읽기 파드), write (쓰기 파드), canary (Loki Canary 파드)의 app.kubernetes.io/component 레이블을 추가한다는 사실을 활용합니다. 이러한 주석은 loki-distributed 배포에는 없으므로 새 배포의 로그만 일치해야 합니다.

loki-distributed에서 loki로 마이그레이션하려면:

  1. 새 Loki 클러스터 배포

    다음으로 기존 loki-distributed 설치와 동일한 네임스페이스에 새 loki 차트를 배포합니다. 기존 설치와 동일한 버킷 및 스토리지 구성을 사용해야 합니다. 몇 가지 특별한 migrate 값도 설정해야 합니다.

    migrate:
  fromDistributed:
    enabled: true
    memberlistService: loki-loki-distributed-memberlist

    memberlistService 값은 loki-distributed 배포에서 Memberlist DNS 목적으로 생성된 쿠버네티스 서비스여야 합니다. loki-distributed 배포 구성의 memberlist.join_members 값과 일치해야 합니다. 이렇게 하면 새 클러스터가 기존 클러스터 링에 가입하게 됩니다. 모든 기존 링에 가입하는 것이 중요합니다. 다른 링에 다른 멤버리스트 DNS를 사용하는 경우 각 링에 대해 해당하는 각 join_members 구성 값을 수동으로 설정해야 합니다. loki-distributed 차트의 기본값처럼 모든 링에 동일한 멤버리스트 DNS를 사용하는 경우 migrate.memberlistService를 설정하는 것으로 충분합니다.

    새 클러스터가 가동되면 Grafana에서 새 클러스터에 대한 적절한 데이터 소스를 추가합니다. 다음 쿼리가 결과를 반환하는지 확인하십시오.

    • 새 배포에 새 로그와 이전 로그가 있는지 확인합니다. Grafana에서 새 배포의 Loki 데이터 소스를 사용하여 다음을 찾습니다.
      • 위에서 조정한 기존 Promtail 또는 Grafana Agent에 고유한 작업을 가진 로그. 아직 새 배포에 로그를 푸시하지 않습니다. 새 배포를 통해 쿼리할 수 있다면 기록 로그가 손실되지 않았음을 보여줍니다.
      • job="loki/loki-read" 레이블이 있는 로그. read 구성 요소는 loki-distributed에 존재하지 않으므로 새 Loki 클러스터의 자체 모니터링이 올바르게 작동하고 있음을 보여줍니다.
    • 이전 배포에 새 로그가 있는지 확인합니다. 이전 배포의 Loki 데이터 소스를 사용하여 다음을 찾습니다.
      • job="loki/loki-read" 레이블이 있는 로그. 새 배포의 로그를 loki-distributed 배포로 보내지 않도록 제외했으므로 loki-distributed Loki 데이터 소스를 통해 쿼리할 수 있다면 인제스터가 동일한 링에 가입했으며 loki-distributed 쿼리어에서 쿼리할 수 있음을 보여줍니다.

  2. 모든 클라이언트를 새 loki 배포로 로그를 푸시하도록 변환

    모든 것이 예상대로 작동한다고 가정하면 이제 Grafana Agent 또는 Promtail 구성의 clients 섹션을 수정하여 새 배포에 로그를 푸시할 수 있습니다. 이 변경이 이루어지면 loki-distributed 클러스터는 더 이상 새 로그를 수신하지 않으며 신중하게 축소할 수 있습니다.

    이것이 배포되면 새 loki 클러스터의 Loki 데이터 소스에서 새 로그를 쿼리하여 여전히 수집되고 있는지 확인합니다.

  3. 이전 Loki Canary 해체

    이전에 loki-canary Helm 차트를 통해 카나리아를 배포했다면 이제 해체할 수 있습니다. 새 차트는 기본적으로 카나리아와 함께 제공되며 자동으로 스크랩하도록 구성됩니다.

  4. loki-distributed 배포에서 플러시 구성 업데이트

    이제 이전 loki-distributed 클러스터 축소를 시작할 준비가 거의 되었습니다. 그러나 시작하기 전에 loki-distributed 인제스터가 종료 시 플러시하도록 구성되어 있는지 확인하는 것이 중요합니다. 이러한 인제스터는 다시 돌아오지 않으므로 WAL을 재생할 기회가 없으므로 데이터 손실을 방지하기 위해 종료하기 전에 모든 메모리 내 로그를 플러시해야 합니다.

    이를 수행하는 가장 쉬운 방법은 loki-distributed 차트의 ingester 섹션에 있는 extraArgs 인수를 사용하는 것입니다. 플러싱 프로세스에 대한 메시지를 보려면 인제스터의 로그 수준을 debug로 설정할 수도 있습니다.

    ingester:
  replicas: 3
  extraArgs:
  - '-ingester.flush-on-shutdown=true'
  - '-log.level=debug'

    이 변경 사항을 배포하고 모든 인제스터가 다시 시작되고 최신 구성을 실행하고 있는지 확인하십시오.

  5. 인제스터를 한 번에 하나씩 축소

    이제 loki-distributed를 축소할 시간입니다. 인제스터 StatefulSet 또는 Deployment(loki-distributed 차트가 배포된 방식에 따라 다름)를 한 번에 1개의 복제본씩 축소합니다. debug 로그가 활성화된 경우 각 인제스터가 종료될 때 로그를 모니터링하여 플러싱 프로세스가 성공했는지 확인할 수 있습니다. 인제스터 파드가 완전히 종료되면 다른 1개의 복제본으로 계속 줄입니다. 실행 중인 인제스터 인스턴스가 0이 될 때까지 계속합니다.

    다음 명령을 사용하여 인제스터 StatefulSet를 편집하여 복제본 수를 변경할 수 있습니다(<NAMESPACE>를 올바른 네임스페이스로 바꿔야 함).

    kubectl -n <NAMESPACE> edit statefulsets.apps loki-distributed-ingester

  6. loki-distributed 클러스터 제거

    로그가 여전히 새 클러스터로 들어오고 있는지 다시 확인하십시오. 문제가 있는 경우 전체 클러스터를 해체하기 전에 loki-distributed 인제스터를 신속하게 다시 확장하여 조사하는 것이 훨씬 쉽습니다. 모든 것이 좋아 보이면 helm uninstall을 사용하여 loki-distributed를 해체할 수 있습니다. 예:

    helm uninstall -n loki loki-distributed

    이제 새 loki 클러스터를 편집하여 처음 설치할 때 추가한 migrate 옵션을 제거합니다. values.yaml에서 다음을 모두 제거하십시오.

    migrate:
  fromDistributed:
    enabled: true
    memberlistService: loki-loki-distributed-memberlist

    새 구성을 적용하려면 (새 차트를 loki 네임스페이스에 loki로 설치했다고 가정):

    helm upgrade -n loki loki grafana/loki --values values.yaml

    migrate.fromDistributed.memberlistService는 추가 멤버리스트 조인 멤버로 추가되었으므로 이 새 구성이 푸시되면 구성 요소가 중단 없이 롤아웃되어야 합니다.

  7. 대시보드 확인

    이제 마이그레이션이 완료되었으므로 새 loki 차트에 포함된 대시보드를 확인하여 모든 것이 예상대로 작동하는지 확인할 수 있습니다. 또한 로키 카나리아 메트릭을 확인하여 마이그레이션 중에 손실된 것이 없는지 확인할 수 있습니다. 모든 것이 loki 네임스페이스에 있었다고 가정하면 마이그레이션 시작 전부터 마이그레이션 완료 후까지의 기간 동안 실행된 다음 쿼리는 새 카나리아에서 메트릭이 언제부터 들어오기 시작했는지, 프로세스 중에 둘 중 하나에 의해 데이터가 감지되었는지 여부를 명확하게 보여줍니다.

    ( sum(increase(loki_canary_missing_entries_total{namespace="loki"}[$__range])) by (job) / sum(increase(loki_canary_entries_total{namespace="loki"}[$__range])) by (job) )*100
TSDB로 마이그레이션세 개의 대상으로 마이그레이션