페더레이션

페더레이션 (Federation)

페더레이션(Federation)은 하나의 Prometheus 서버가 다른 Prometheus 서버에서 선택한 타임시리즈를 스크랩할 수 있게 해 주는 기능이에요. 여러 규모의 Prometheus를 계층으로 쌓고 싶을 때 아주 유용해요. 예를 들어 서비스 수준 Prometheus의 집계 시리즈를 글로벌 Prometheus로 끌어올 수 있죠. 이 문서는 페더레이션의 사용 사례와 구성 방법, 그리고 다른 데이터 수집 방식과의 장단점 비교를 설명해 드려요.

결론을 먼저 말하면, 장기 저장소에는 remote write를, 낮은 수준의 트리형 계층에는 페더레이션을, 그리고 직접적인 Prometheus-to-Prometheus 스크래핑에는 풀 기반 수집을 고려하세요. 각각의 쓰임새가 달라요.

출처: 문서

본문

페더레이션은 Prometheus 서버가 다른 Prometheus 서버에서 선택한 타임시리즈를 스크랩할 수 있게 해 줘요.

사용 사례 (Use cases)

계층적 페더레이션 (Hierarchical federation)

계층적 페더레이션은 Prometheus가 다른 Prometheus 서버에서 선택한 타임시리즈를 스크랩할 수 있게 해 줘요. 전형적인 사용 사례는 서비스 자체에 대한 메트릭 위에서, 서비스 수준 Prometheus의 집계 시리즈(예: 많은 인스턴스에 대한 요약, 카운트)를 글로벌 Prometheus로 스크랩하는 것이에요.

계층적 페더레이션의 예: 글로벌 Prometheus가 지역 Prometheus에서 avg by instance (job:instance:cpu_usage_ratio:rate5m)를 스크랩하고, 지역 Prometheus(또는 지역 클러스터 페더레이트)가 job:instance:cpu_usage_ratio:rate5m에서 클러스터 수준 집계를 구축해요.

크로스-서비스 페더레이션 (Cross-service federation)

한 서비스의 Prometheus 서버가 다른 서비스의 Prometheus 서버 메트릭을 스크랩하는 크로스-서비스 페더레이션은, 크로스-서비스 시나리오에 참여하는 서비스의 SLO를 달성하는 데 전형적으로 사용돼요. 예를 들어 다른 서비스, 즉 DB에 의존하는 애플리케이션(app)이 있고 그것이 하위 계층 서비스에서 실행된다면, 가장 관련 있는 서비스들 — 예를 들어 애플리케이션의 클라이언트와 서버 양쪽, 그리고 DB — 의 메트릭을 스크랩하는 단일 글로벌 Prometheus를 두는 것이 합리적이에요.

서비스 간 데이터 의존성은 아무리 피하려 해도 자주 나타나요. 이 데이터 의존성을 무시한다고 사라지지 않아요. 크로스-서비스 페더레이션을 사용하면 대시보드 쪽이나 SLO에서 의존성을 명시적으로 보이게 할 수 있어요. 전반적으로 글로벌 Prometheus는 특정 서비스를 신속하게 스크랩하고 실패가 발생하면 적절히 알림을 걸 수 있다면 이점을 얻어요.

페더레이션 구성 (Configuring federation)

주어진 Prometheus 서버에서 /federate 엔드포인트는 스크랩될 타임시리즈를 선택할 수 있게 해 줘요. 예를 들어 메트릭 up의 모든 타임시리즈를 가져오려면: curl 'http://localhost:9090/federate?match[]={__name__=~"up"}'

모든 메트릭을 스크랩하려면 임의의 정규식과 함께 match[] 파라미터를 사용하세요:

match[]={__name__=~".+"}

다음 요청은 로컬 Prometheus에서 job="prometheus" 라벨이 있는 모든 시리즈를 스크랩해요:

curl 'http://localhost:9090/federate?match[]={job="prometheus"}&match[]={__name__=~"job:.*"}'

job 라벨에 대해 (About the job label)

스크랩된 데이터의 job 라벨은 데이터가 수집된 Prometheus 서버의 이름과 일치해야 해요. 이렇게 되지 않으면 데이터가 스크랩될 때 오류 메시지가 로그로 기록돼요.

페더레이션이 다른 라벨 이름으로 설정되면(예: 한 Prometheus 서버에서는 job, 다른 서버에서는 service), 여러 페더레이션이 있는 더 큰 구성은 시간이 지나면서 job 라벨 값이 일치하지 않게 만들 거예요. 이를 고치는 두 가지 옵션이 있어요.

  • 모든 페더레이션에서 같은 라벨 이름(또는 단일 공통 네임스페이스)을 사용하세요. instance 라벨 이름은 소스 Prometheus 스크래핑 인스턴스에 유지되어야 해요.

  • Prometheus에서 그 라벨 이름들로 페더레이션 잡을 구성하세요.

이와 관련해, 페더레이션 잡에 relabel_configs가 있다면 그에 맞게 job 라벨 이름을 설정할 수 있어요.

다른 데이터 수집 방식과의 비교 (Compared to other means of data collection)

페더레이션은 remote write나 직접 데이터 스크래핑 같은 다른 수집 접근 방식과 비교해 여러 장단점이 있어요.

장점 (Advantages)

  • 타임시리즈 데이터를 다른 저장 서버로 옮기거나 복사할 필요가 없어요: 페더레이팅 서버는 페더레이트되는 서버의 저장소에 접근할 필요가 없어요.
  • 단일 엔드포인트가 모든 타임시리즈를 노출하고, 잠재적으로 더 많은 것(예: 기록 규칙을 통해)을 선택할 수 있어요.
  • 페더레이션은 더 이상 존재하지 않는 시리즈를 추적하는 스크래핑 재시작 메커니즘에 의존할 수 있어요.
  • 타깃에 대해 구성할 remote write 스택이 없어요.

단점 (Disadvantages)

  • 관련 애플리케이션의 타임시리즈만 페더레이팅 서버에 노출돼요.
  • 타임시리즈의 모든 평가와 검색은 페더레이팅 서버에서 수행돼요(Prometheus 서버의 스크랩 관점에서).
  • 페더레이션은 스트리밍을 지원하지 않거나, HTTP 위의 gRPC 스트리밍을 지원하지 않는 페더레이트된 서버에서는 작동할 수 없어요(하지만 그들은 여전히 push/pull 모드를 사용할 수 있어요).
  • remote write와 비교해 쓰기는 "그대로(as-is)" / 어떤 변환도 없이 일어나서, 시간이 지나면서 이질적인 라벨 이름(예: 라벨 이름 변경이나 타임시리즈 병합)이 있으면 문제가 될 수 있어요.
  • 페더레이션은 어떤 배칭(batching)도 하지 않으므로, 대용량 데이터나 높은 카디널리티 시리즈에는 효율적이지 않아요.
  • 요청이 HTTP GET 기반이므로 Prometheus HTTP 서버의 크기 제한(구체적으로 --web.max-connections)을 공유할 수 있어요.

결론 (Conclusion)

요약하면, 장기 저장소에는 remote write를, 낮은 수준의 트리형 계층에는 페더레이션을, 그리고 직접적인 prometheus-to-prometheus 스크래핑에는 풀 기반 수집을 사용하는 것을 고려하세요.

더 알아보기 (Learn more)