Thanos Tips

Thanos 는 Prometheus 사용할 때 HA 와 Long-term storage 를 보완하기 위한 솔루션으로서 기본적인 컨셉과 설명은 조대협님 블로그에 잘 설명되어 있다.

 

https://bcho.tistory.com/1375

Prometheus 를 스케일링 하기 위한 Thanos (타노스)

 

여기서는 추가적으로 실 운영단계에서 알아둬야할 몇가지 팁을 요약해보고자 한다.

 

- Thanos의 쿼리 속도는 Vanila Prometheus 보다 최소 2~10배 까지 느릴 수 있다. 

Thanos는 기본적으로 여러 데이터 소스로부터 중복제거를 통해 데이터를 리턴하기 때문에 느릴수 밖에 없다. Thanos Query가 쿼리를 입력받게 되면 이를 Sidecar 와 Store gateway에 데이터를 요청하게 되고, 각각의 Store(Sidecar도 결국 Query 관점에서는 Store)에서 리턴한 데이터를 네트워크를 통해서 받고 이에 대한 중복도 제거(Deduplication)해 줘야한다.

 

또한 query, store 가 필요로 하는 리소스가 적진 않기 때문에 리소스 capa 계획을 잘 세워야한다. 각각의 component는 최대 1 cpu만 사용하고(최신에서 더 개선이 됐는지는 모르겠다), memory는 GB단위로 줘야 안정성 있게 운영할 수 있다(규모에 따라 달라지므로 명시적으로 말할수는 없을것 같다)

 

- Sidecar는 Chunk 파일만 업로드하고(WAL은 하지 않는다), 업로드 할 때 기존 metadata에 몇가지를 더 추가한다.

Sidecar는 Prometheus에서 생성한 TSDB(chunk)만을 업로드한다. WAL(Write-Ahead-Log, DB에서 일반적으로 쓰이는 DB로그에 해당)의 경우는 업로드 하지 않기 때문에, 최근 2시간(정확히 얘기하면 정각 2시간 단위이다)의 데이터는 오로지 Sidecar로 부터만 받을 수 있다.

Sidecar는 Prometheus chunk 파일을 올릴때 meta.json에 몇가지 정보를 추가한다. thanos 키값내에 중복처리에 필요한 labels, 쿼리 step 사이즈에 따라 선택하기 위한 downsample, 어디서부터 업로드되었는지는 나타내는 source 키가 있다. 이는 버전이 바뀐에 따라 추가되거나 바뀔 가능성이 있다.

 

- S3 Bucket을 여러개를 사용함으로써 쿼리 속도를 개선할 수 있다.

위에 언급한 쿼리 속도를 개선하기 위해서는 S3를 하나만 사용할 것이 아니라 Data sharding을 통해 Sidecar와 Store gateway가 각각 다른 S3 Bucket을 바라보게 하면 된다. Query에서 Store gateway에 데이터를 요청할 때 서로 다른 Bucket을 바라보는 Store gateway를 여러개 띄워놓는 다면 병렬도 진행하기 때문에 속도가 향상될 수 있다.

 

보통 두가지로 생각할 수가 있는데, 첫번째로는 여러 prometheus를 합쳐서 보는 것이고, 두번째는 federation된 prometheus만 보는 것이다.

 

 

- Store Gateway는 Cache로 인해 많은 메모리가 필요할 수 있다.

Store gateway는 성능향상을 위해 자체적인 index cache를 가지고 있다. 이 cache크기를 설정할 수 있는데, 필자 경험상 2GB정도는 되어야 성능을 보장할 수 있었다. 다만 이렇게 되면 Store Gateway가 차지하는 메모리 크기가 커질 수 있다.

 

- Downsampling은 쿼리 속도를 향상하기 위함이지 공간을 절약하는 옵션이 아니다.

Thanos Compactor에 의해 진행되는 Downsampling 기본원리는 40시간이 지나면 5분, 10일이 지나면 1시간으로 자동 Downsampling 된다는 것이다. 이는 기존 raw 데이터를 지운다는게 아니고, 추가로 데이터를 생성한다는 것이다. 쿼리를 할때 Step 사이즈에 기반하여 Thanos는 1시간 데이터에서 꺼낼 것인지, 5분 데이터에서 꺼낼 것인지 판단한다. 상황에 따라 검색하는 chunk 대상이 달라지기 때문에 속도가 향상된다. 이러한 downsampling 된 데이터까지 포함하여 조회하도록 하려면 query에 auto-downsampling 옵션을 켜둬야 한다.

 

- 제한된 저장공간으로 인해 데이터 보관기관을 지정하려면 raw, 5분, 1시간 데이터에 대한 retention값을 각각 지정해야 한다. 

서로 다르게 지정해놓는다면 Grafana등에서 Zoom in을 했을때 데이터가 안나올 수도 있다. 예를들면, raw는 30일로 하고, 5분은 60일로 했을 경우, 지난 30일~60일 데이터의 경우 5분 이하의 step 사이즈를 가진 쿼리에 대해 데이터가 나오지 않는다는 것이다.

 

하지만 보통 오래된 날짜의 데이터는 상세하게 보지 않기 때문에 raw < 5분 < 1시간 순으로 보관기간을 설정하면 된다.

 

- Compactor는 상시 띄워두지 않아도 된다.

compactor의 주요 기능은 기존에 올라간 오래된 chunk 파일을 압축 또는 삭제하고, downsampling을 하는 것이다. 이를 계속 띄워두면 Compactor가 상시 동작하게 되나 필자의 경우는 하루에 1번 새벽에 Cronjob을 이용해서 돌리고 있다. 이렇게 해두면 k8s 리소스 상시할당을 절약할 수 있다.

 

- Staleness 값(default: 5m)은 조정하지 않는 것이 좋다.

Prometheus는 기본적으로 5분이 넘어간 데이터는 stale처리하여 결과로 리턴하지 않는다. 이는 query.lookback-delta 옵션으로 좀더 길게 조정할 수 있는데, 5분 이상의 수집이나 Federation을 적용하려고 하면 반드시 수정을 해줘야 한다. 하지만 Thanos sidecar의 경우 prometheus에서 데이터를 빼올때 prometheus의 일반적인 API가 아닌 Remote API 를 사용한다. 문제는 이 Remote API는 Stale옵션이 적용되지 않는다. 그렇기 때문에 Stale 값을 조정하게 되면 원하는 데이터가 안나올 수가 있다.

 

- HA된 Prometheus를 Federation 할 때 각 prometheus를 나타내는 Exteneral label이 존재할 경우 이를 Drop해주는 것이 필요하다.

이건 Thanos 가 아니더라도 Federation할때 반드시 고려해야 할 부분인데, Target prometheus가 HA로 되어있고 앞단에 LB가 있다면, Federation시에 각각의 Target prometheus를 뜻하는 External Label을 Drop해줘야한다. 예를들어 prometheus: prometheus_0, prometheus_1로 되어있는 2개의 HA prometheus가 있고 이를 LB를 통해 federation하면, 저장하는 prometheus쪽에는 각각 다른 prometheus label 값을 가진 데이터가 랜덤하게 쌓기게 된다. 그러면 쿼리 사용시 다른 Series로 처리되기 때문에 잘못된 결과가 나올 수 있다.