타노스 - 확장 가능한 프로메테우스

이 기사의 번역은 코스의 학생들을 위해 특별히 준비되었습니다. "DevOps 사례 및 도구".

파비안 레이나츠 소프트웨어 개발자이자 Go 광팬이자 문제 해결사입니다. 그는 또한 Prometheus 관리자이자 Kubernetes SIG 계측의 공동 창립자이기도 합니다. 과거에는 SoundCloud의 프로덕션 엔지니어였으며 CoreOS의 모니터링 팀을 이끌었습니다. 현재 Google에서 일하고 있습니다.

바르텍 플롯카 - Improbable의 인프라 엔지니어. 그는 새로운 기술과 분산 시스템의 문제에 관심이 있습니다. 그는 Intel에서 낮은 수준의 프로그래밍 경험, Mesos에서 기여자 경험, Improbable에서 세계적 수준의 SRE 제작 경험을 보유하고 있습니다. 마이크로서비스의 세계를 개선하는 데 전념합니다. 그의 세 가지 사랑은 Golang, 오픈 소스, 배구입니다.

당사의 주력 제품인 SpatialOS를 살펴보면 Improbable에는 수십 개의 Kubernetes 클러스터가 포함된 매우 동적인 글로벌 규모의 클라우드 인프라가 필요하다는 것을 짐작할 수 있습니다. 우리는 모니터링 시스템을 사용한 최초의 기업 중 하나였습니다. 프로 메테우스. Prometheus는 수백만 개의 지표를 실시간으로 추적할 수 있으며 필요한 정보를 추출할 수 있는 강력한 쿼리 언어와 함께 제공됩니다.

Prometheus의 단순성과 신뢰성은 주요 장점 중 하나입니다. 그러나 일정 규모를 넘어서자 몇 가지 문제점이 발생했습니다. 이러한 문제를 해결하기 위해 우리는 개발했습니다. Thanos 기존 Prometheus 클러스터를 무제한의 기록 데이터 저장 기능을 갖춘 단일 모니터링 시스템으로 원활하게 변환하기 위해 Improbable이 만든 오픈 소스 프로젝트입니다. 타노스는 Github에서 이용 가능합니다 여기에.

Improbable의 최신 소식을 받아보세요.

타노스와 함께하는 우리의 목표

특정 규모에서는 바닐라 프로메테우스의 능력을 넘어서는 문제가 발생합니다. 페타바이트 규모의 기록 데이터를 안정적이고 경제적으로 저장하는 방법은 무엇입니까? 응답 시간을 저하시키지 않고 이를 수행할 수 있습니까? 단일 API 요청으로 다양한 Prometheus 서버에 있는 모든 지표에 액세스할 수 있습니까? Prometheus HA를 사용하여 수집된 복제 데이터를 결합할 수 있는 방법이 있습니까?

이러한 문제를 해결하기 위해 우리는 Thanos를 만들었습니다. 다음 섹션에서는 이러한 문제에 접근하는 방법과 목표를 설명합니다.

여러 Prometheus 인스턴스에서 데이터 쿼리(전역 쿼리)

Prometheus는 샤딩에 대한 기능적 접근 방식을 제공합니다. 단일 Prometheus 서버라도 거의 모든 사용 사례에서 수평 샤딩의 복잡성으로부터 사용자를 해방시킬 만큼 충분한 확장성을 제공합니다.

이는 훌륭한 배포 모델이지만 단일 API 또는 UI(전역 보기)를 통해 다양한 Prometheus 서버의 데이터에 액세스해야 하는 경우가 많습니다. 물론 하나의 Grafana 패널에 여러 쿼리를 표시하는 것이 가능하지만 각 쿼리는 하나의 Prometheus 서버에서만 실행할 수 있습니다. 반면, Thanos를 사용하면 단일 엔드포인트에서 모두 액세스할 수 있으므로 여러 Prometheus 서버의 데이터를 쿼리하고 집계할 수 있습니다.

이전에는 Improbable에서 전역 보기를 얻기 위해 Prometheus 인스턴스를 다단계로 구성했습니다. 계층적 연합. 이는 각 리프 서버에서 일부 메트릭을 수집하는 하나의 Prometheus 메타 서버를 생성하는 것을 의미했습니다.

이 접근 방식은 문제가 있는 것으로 판명되었습니다. 이로 인해 구성이 더 복잡해지고, 잠재적인 실패 지점이 추가되었으며, 연합 엔드포인트가 필요한 데이터만 수신하도록 보장하는 복잡한 규칙이 적용되었습니다. 또한 단일 API 요청에서 모든 데이터를 사용할 수 없기 때문에 이러한 종류의 연합에서는 진정한 글로벌 보기를 얻을 수 없습니다.

이와 밀접하게 관련된 것은 고가용성(HA) Prometheus 서버에서 수집된 데이터에 대한 통합 보기입니다. Prometheus의 HA 모델은 독립적으로 데이터를 두 번 수집하므로 이보다 더 간단할 수 없을 만큼 간단합니다. 그러나 두 스트림의 결합 및 중복 제거 보기를 사용하는 것이 훨씬 더 편리합니다.

물론 가용성이 높은 Prometheus 서버가 필요합니다. Improbable에서는 분 단위의 데이터 모니터링을 매우 중요하게 생각하지만 클러스터당 하나의 Prometheus 인스턴스를 보유하는 것은 단일 실패 지점입니다. 구성 오류나 하드웨어 오류로 인해 잠재적으로 중요한 데이터가 손실될 수 있습니다. 재시작이 스크래핑 간격보다 상당히 길어질 수 있으므로 간단한 배포라도 메트릭 수집에 약간의 중단이 발생할 수 있습니다.

과거 데이터의 안정적인 저장

저렴하고 빠르며 장기적인 메트릭 스토리지는 우리의 꿈입니다(대부분의 Prometheus 사용자가 공유함). Improbable에서는 메트릭 보존 기간을 1.8일로 구성해야 했습니다(Prometheus XNUMX의 경우). 이는 우리가 얼마나 멀리 과거를 볼 수 있는지에 명백한 한계를 추가합니다.

Prometheus 2.0에서는 시계열 수가 더 이상 서버의 전체 성능에 영향을 미치지 않으므로 이와 관련하여 개선되었습니다(참조: Prometheus 2에 대한 KubeCon 기조연설). 그러나 Prometheus는 로컬 디스크에 데이터를 저장합니다. 고효율 데이터 압축으로 로컬 SSD 사용량을 크게 줄일 수 있지만 궁극적으로 저장할 수 있는 기록 데이터의 양에는 여전히 제한이 있습니다.

또한 Improbable에서는 신뢰성, 단순성 및 비용에 중점을 둡니다. 대용량 로컬 디스크는 작동 및 백업이 더 어렵습니다. 비용이 더 많이 들고 더 많은 백업 도구가 필요하므로 불필요한 복잡성이 발생합니다.

다운샘플링

과거 데이터 작업을 시작한 후에 우리는 몇 주, 몇 달, 몇 년의 데이터로 작업할 때 쿼리를 점점 더 느리게 만드는 big-O에 근본적인 어려움이 있다는 것을 깨달았습니다.

이 문제에 대한 표준적인 해결책은 다음과 같습니다. 다운샘플링 (다운샘플링) - 신호 샘플링 주파수를 줄입니다. 다운샘플링을 사용하면 더 큰 시간 범위로 '축소'하고 동일한 수의 샘플을 유지하면서 쿼리 응답성을 유지할 수 있습니다.

오래된 데이터를 다운샘플링하는 것은 장기 스토리지 솔루션의 불가피한 요구 사항이며 바닐라 프로메테우스의 범위를 벗어납니다.

추가 목표

Thanos 프로젝트의 원래 목표 중 하나는 기존 Prometheus 설치와 원활하게 통합하는 것이었습니다. 두 번째 목표는 진입 장벽을 최소화하면서 운영을 용이하게 하는 것이었습니다. 모든 종속성은 소규모 사용자와 대규모 사용자 모두에게 쉽게 충족되어야 하며 이는 기본 비용도 낮다는 것을 의미합니다.

타노스 아키텍처

이전 섹션에서 우리의 목표를 나열한 후 이를 통해 작업하고 Thanos가 이러한 문제를 어떻게 해결하는지 살펴보겠습니다.

글로벌 뷰

기존 Prometheus 인스턴스에 대한 전역 보기를 얻으려면 단일 요청 진입점을 모든 서버에 연결해야 합니다. 이것이 바로 Thanos 구성 요소가 수행하는 작업입니다. 사이드카. 이는 각 Prometheus 서버 옆에 배포되고 프록시 역할을 하여 gRPC Store API를 통해 로컬 Prometheus 데이터를 제공하므로 시계열 데이터를 태그 및 시간 범위별로 검색할 수 있습니다.

다른 측면에는 표준 Prometheus HTTP API를 통해 PromQL 쿼리에 응답하는 것 이상의 기능을 수행하는 확장형 상태 비저장 Querier 구성 요소가 있습니다. 쿼리어(Querier), 사이드카(Sidecar) 및 기타 Thanos 구성 요소는 다음을 통해 통신합니다. 가십 프로토콜.

1. Querier는 요청을 받으면 해당 Store API 서버, 즉 사이드카에 연결하고 해당 Prometheus 서버로부터 시계열 데이터를 수신합니다.
2. 그런 다음 응답을 결합하고 이에 대해 PromQL 쿼리를 실행합니다. 쿼리어는 Prometheus HA 서버의 분리된 데이터와 중복 데이터를 모두 병합할 수 있습니다.

이는 격리된 Prometheus 서버의 데이터를 단일 보기로 결합하는 퍼즐의 주요 조각을 해결합니다. 실제로 Thanos는 이 기능에만 사용할 수 있습니다. 기존 Prometheus 서버를 변경할 필요가 없습니다!

유통기한은 무제한!

그러나 조만간 우리는 일반적인 Prometheus 보존 시간을 초과하여 데이터를 저장하려고 할 것입니다. 우리는 기록 데이터를 저장하기 위해 객체 스토리지를 선택했습니다. 온프레미스 데이터 센터는 물론 모든 클라우드에서 광범위하게 사용할 수 있으며 매우 비용 효율적입니다. 또한 잘 알려진 S3 API를 통해 거의 모든 객체 스토리지를 사용할 수 있습니다.

Prometheus는 대략 XNUMX시간마다 RAM에서 디스크로 데이터를 씁니다. 저장된 데이터 블록은 고정된 기간 동안의 모든 데이터를 포함하며 변경할 수 없습니다. 이는 Thanos Sidecar가 Prometheus 데이터 디렉터리를 간단히 살펴보고 새 블록을 사용할 수 있게 되면 이를 객체 스토리지 버킷에 로드할 수 있기 때문에 매우 편리합니다.

디스크에 쓴 후 즉시 개체 스토리지에 로드하면 스크레이퍼(Prometheus 및 Thanos Sidecar)의 단순성을 유지할 수도 있습니다. 지원, 비용 및 시스템 설계를 단순화합니다.

보시다시피 데이터 백업은 매우 간단합니다. 하지만 객체 스토리지의 데이터를 쿼리하는 것은 어떻습니까?

Thanos Store 구성 요소는 객체 스토리지에서 데이터를 검색하는 프록시 역할을 합니다. Thanos Sidecar와 마찬가지로 가십 클러스터에 참여하고 Store API를 구현합니다. 이런 방식으로 기존 쿼리기는 이를 사이드카처럼 시계열 데이터의 또 다른 소스로 처리할 수 있으며 특별한 구성이 필요하지 않습니다.

시계열 데이터 블록은 여러 개의 큰 파일로 구성됩니다. 요청 시 로드하는 것은 매우 비효율적이며 로컬로 캐싱하려면 엄청난 양의 메모리와 디스크 공간이 필요합니다.

대신 Store Gateway는 Prometheus 스토리지 형식을 처리하는 방법을 알고 있습니다. 스마트 쿼리 스케줄러와 블록의 필요한 인덱스 부분만 캐싱 덕분에 복잡한 쿼리를 개체 저장소 파일에 대한 HTTP 요청 수를 최소한으로 줄일 수 있습니다. 이러한 방식으로 요청 수를 XNUMX~XNUMX배로 줄이고 일반적으로 로컬 SSD의 데이터 요청과 구별하기 어려운 응답 시간을 달성할 수 있습니다.

위 다이어그램에서 볼 수 있듯이 Thanos Querier는 Prometheus 스토리지 형식을 활용하고 관련 데이터를 나란히 배치하여 개체 스토리지 데이터의 쿼리당 비용을 크게 줄입니다. 이 접근 방식을 사용하면 여러 단일 요청을 최소한의 대량 작업으로 결합할 수 있습니다.

압축 및 다운샘플링

새로운 시계열 데이터 블록이 객체 스토리지에 성공적으로 로드되면 이를 "과거" 데이터로 처리하여 스토어 게이트웨이를 통해 즉시 사용할 수 있습니다.

그러나 일정 시간이 지나면 한 소스(사이드카가 포함된 Prometheus)의 블록이 누적되어 더 이상 전체 인덱싱 잠재력을 사용하지 않습니다. 이 문제를 해결하기 위해 우리는 Compactor라는 또 다른 구성 요소를 도입했습니다. 단순히 Prometheus의 로컬 압축 엔진을 객체 스토리지의 기록 데이터에 적용하고 간단한 주기적인 배치 작업으로 실행할 수 있습니다.

효율적인 압축 덕분에 장기간에 걸쳐 스토리지를 쿼리해도 데이터 크기 측면에서 문제가 발생하지 않습니다. 그러나 수십억 개의 값을 풀고 이를 쿼리 프로세서를 통해 실행하는 데 드는 잠재적 비용으로 인해 필연적으로 쿼리 실행 시간이 급격히 증가하게 됩니다. 반면에 화면에는 픽셀당 수백 개의 데이터 포인트가 있기 때문에 전체 해상도로 데이터를 시각화하는 것조차 불가능해집니다. 따라서 다운샘플링은 가능할 뿐만 아니라 눈에 띄는 정확도 손실로 이어지지도 않습니다.

데이터를 다운샘플링하기 위해 Compactor는 XNUMX분과 XNUMX시간의 해상도로 데이터를 지속적으로 집계합니다. TSDB XOR 압축을 사용하여 인코딩된 각 원시 청크에 대해 한 블록의 최소, 최대 또는 합계와 같은 다양한 유형의 집계 데이터가 저장됩니다. 이를 통해 Querier는 특정 PromQL 쿼리에 적합한 집계를 자동으로 선택할 수 있습니다.

사용자가 축소된 정밀도 데이터를 사용하기 위해 특별한 구성이 필요하지 않습니다. Querier는 사용자가 확대 및 축소함에 따라 다양한 해상도와 원시 데이터 간에 자동으로 전환됩니다. 원하는 경우 사용자는 요청의 "step" 매개변수를 통해 이를 직접 제어할 수 있습니다.

XNUMXGB를 저장하는 비용이 낮기 때문에 Thanos는 기본적으로 원시 데이터, XNUMX분 및 XNUMX시간 해상도 데이터를 저장합니다. 원본 데이터를 삭제할 필요는 없습니다.

녹음 규칙

Thanos의 경우에도 녹화 규칙은 모니터링 스택의 필수 부분입니다. 복잡성, 대기 시간, 쿼리 비용이 줄어듭니다. 또한 사용자가 측정항목별로 집계된 데이터를 얻는 데 편리합니다. Thanos는 바닐라 Prometheus 인스턴스를 기반으로 하므로 기존 Prometheus 서버에 기록 규칙 및 경고 규칙을 저장하는 것이 완벽하게 허용됩니다. 그러나 어떤 경우에는 이것만으로는 충분하지 않을 수 있습니다.

• 전역 경고 및 규칙(예: 서비스가 XNUMX개 클러스터 중 XNUMX개 이상에서 작동하지 않을 때의 경고)
• 로컬 저장소 외부의 데이터에 대한 규칙입니다.
• 모든 규칙과 경고를 한 곳에 저장하려는 욕구.

이러한 모든 경우에 대해 Thanos에는 Thanos 쿼리를 통해 규칙과 경고를 계산하는 Ruler라는 별도의 구성 요소가 포함되어 있습니다. 잘 알려진 StoreAPI를 제공함으로써 쿼리 노드는 새로 계산된 지표에 액세스할 수 있습니다. 나중에 객체 스토리지에도 저장되며 Store Gateway를 통해 사용할 수 있습니다.

타노스의 힘

Thanos는 귀하의 필요에 맞게 맞춤화할 수 있을 만큼 유연합니다. 이는 일반 Prometheus에서 마이그레이션할 때 특히 유용합니다. 간단한 예를 통해 Thanos 구성 요소에 대해 배운 내용을 빠르게 요약해 보겠습니다. 바닐라 프로메테우스를 "무제한 지표 저장"의 세계로 가져가는 방법은 다음과 같습니다.

1. Prometheus 서버에 Thanos 사이드카를 추가하세요(예: Kubernetes 포드의 사이드카 컨테이너).
2. 데이터를 볼 수 있도록 여러 Thanos Querier 복제본을 배포합니다. 이 단계에서는 Scraper와 Querier 사이에 가십을 설정하는 것이 쉽습니다. 구성 요소의 상호 작용을 확인하려면 'thanos_cluster_members' 측정항목을 사용하세요.

이 두 단계만으로도 잠재적인 Prometheus HA 복제본에서 글로벌 뷰와 원활한 데이터 중복 제거를 제공하기에 충분합니다! 대시보드를 Querier HTTP 엔드포인트에 연결하거나 Thanos UI를 직접 사용하면 됩니다.

그러나 지표 백업 및 장기 저장이 필요한 경우 다음 세 단계를 더 완료해야 합니다.

1. AWS S3 또는 GCS 버킷을 생성합니다. 이러한 버킷에 데이터를 복사하도록 사이드카를 구성합니다. 이제 로컬 데이터 저장 공간을 최소화할 수 있습니다.
2. Store Gateway를 배포하고 이를 기존 가십 클러스터에 연결합니다. 이제 백업된 데이터를 쿼리할 수 있습니다!
3. 압축 및 다운샘플링을 사용하여 장기간에 걸쳐 쿼리 효율성을 향상하려면 Compactor를 배포하세요.

더 알고 싶다면 주저하지 말고 우리의 쿠버네티스 매니페스트 예시 и 시작하기!

단 XNUMX단계만으로 우리는 Prometheus를 전역 보기, 무제한 저장 시간 및 잠재적인 고가용성 지표를 갖춘 안정적인 모니터링 시스템으로 전환했습니다.

풀 리퀘스트: 당신이 필요합니다!

Thanos 는 처음부터 오픈 소스 프로젝트였습니다. Prometheus와의 원활한 통합 및 Thanos의 일부만 사용하는 기능은 모니터링 시스템을 손쉽게 확장할 수 있는 탁월한 선택입니다.

우리는 GitHub Pull Request와 Issues를 언제나 환영합니다. 그동안 Github Issues나 Slack을 통해 언제든지 문의해 주세요. Improbable-eng #타노스질문이나 피드백이 있거나 사용 경험을 공유하고 싶다면! Improbable의 업무가 마음에 드신다면, 주저하지 마시고 연락주세요. 우리에겐 항상 빈자리가 있어요!

과정에 대해 자세히 알아보세요.

출처 : habr.com