개요
탄력적으로 확장 가능하고 가용성이 높은 시스템의 경우 일반적으로 많은 양의 지표 데이터를 수집하고 저장해야 하는데 이러한 시스템에 대한 모니터링 솔루션을 만드는 방법은 무엇입니까? Thanos+Prometheus+Grafana를 사용하여 모니터링 시스템을 구축하는 방법에 대해 설명합니다.
클러스터 용량 개요
사용자 스토리
올해 1월까지는 APM에도 사용되는 엔터프라이즈급 모니터링 솔루션으로 쿠버네티스 클러스터를 모니터링하고 있었습니다. 사용이 자연스럽고 약간의 조정으로 Kubernetes와 매우 쉽게 통합되며 APM 및 인프라 메트릭을 통합할 수 있습니다.
이 모니터링 솔루션은 데이터를 쉽게 수집하고 저장할 수 있지만 메트릭을 사용하여 경고를 생성하면 상당한 쿼리 제한이 있습니다 . 우리가 받는 경고는 대시보드에 표시되는 것과 다른 경우가 많습니다. 6개의 클러스터가 있고 수집 및 저장되는 메트릭의 수가 매우 많아 경제적 비용이 크게 증가한다는 것은 말할 것도 없습니다.
약간의 고려 끝에 우리는 이 모니터링 솔루션을 계속 사용하는 것이 득보다 실이 많다는 것을 깨달았습니다. 감시 솔루션을 교체할 시간입니다! 하지만 어떤 제품이나 도구를 사용해야 할까요? 시각화 도구로는 Grafana가 가장 좋은 선택 이지만 우리의 "백엔드"는 탄력적인 확장성과 고가용성이 필요합니다. 어떤 도구를 사용해야 할까요?
OpenTSDB를 순수하게 사용한다면 설치에 너무 많은 수고와 노력이 필요하고, 독립형 Prometheus는 복제 기능을 제공하지 않으며, 여러 데이터베이스를 갖추어야 합니다.
위의 솔루션 중 일부를 실험한 후 CNCF 웹 사이트를 확인하고 마침내 Thanos를 찾았습니다 ! 장기 데이터 보존, 복제 가능, 고가용성, 마이크로서비스에 적합, 동일한 데이터베이스를 사용하는 모든 클러스터에 대한 글로벌 보기가 있습니다.
건축학
클러스터에서 사용할 수 있는 영구 스토리지가 없으므로(모든 서비스는 상태 비저장으로 유지됨) 기본 Prometheus + Thanos 사이드카 접근 방식을 사용할 수 없으며 메트릭 스토리지는 클러스터 외부에 배치해야 합니다. 또한 클러스터는 서로 격리되어 있으며 Thanos 구성 요소를 특정 클러스터 집합에 바인딩할 수 없으며 클러스터를 "외부"에서 모니터링해야 합니다.
요약하자면 고가용성과 가상 머신에서 실행되는 Thanos의 가능성을 고려하여 최종 아키텍처는 다음과 같습니다.
그림과 같이 다중 데이터 센터 아키텍처가 있습니다. 이러한 각 센터에는 Grafana + 쿼리 서버 세트 , 스토리지 서버 세트 및 3개의 수신 서버(클러스터 수의 절반)가 있습니다.
Grafana에서 사용하는 데이터베이스에는 AWS RDS도 있습니다. 이 데이터베이스는 거대할 필요가 없으며(비용 절감을 위해) 우리 팀은 MySQL을 관리할 필요가 없습니다.
Thanos가 제공하는 모든 구성 요소 중 4가지를 구현했습니다.
-
수신 : TSDB를 담당하며 TSBD 블록을 수신하고 S3에 업로드하는 모든 서버 간의 복제를 관리합니다.
-
쿼리 : 수신 데이터베이스 쿼리를 담당합니다.
-
Store : 더 이상 수신에 저장되지 않는 장기 지표에 대해 S3를 읽습니다.
-
Compactor : S3에 저장된 TSDB 블록의 데이터 다운샘플링 및 압축을 관리합니다.
데이터 통합
모든 클러스터의 데이터 수집은 클러스터 내에서 실행되는 전용 Prometheus Pod 에서 관리합니다 . 인프라 및 Kubernetes 자체(Kube-proxy, Kubelet, Node Exporter, State Metrics, Metrics Server, 스크래핑 주석이 있는 기타 포드).
그런 다음 Prometheus 포드는 원격 스토리지 구성으로 TSDB를 관리하는 수신 서버 중 하나로 정보를 보냅니다.
데이터 수집
모든 데이터는 단일 서버로 전송된 다음 다른 서버로 복제됩니다. Prometheus에서 사용하는 DNS 주소는 각 수신 서버를 조사하고 정상적인 서버 간에 DNS 확인의 균형을 유지하는 DNS GSLB입니다. DNS 확인은 각 DNS 쿼리에 대해 하나의 IP만 제공하기 때문에 모든 서버 간에 로드를 공유합니다.
데이터를 단일 수신 인스턴스로 전송하고 복제를 관리하도록 해야 한다는 점을 강조해야 합니다. 동일한 메트릭을 전송하면 복제가 실패하고 오작동하게 됩니다 .
이 수준에서 지표는 장기 보존을 위해 S3 버킷에도 업로드됩니다. 수신은 2시간마다(각 TSDB 블록이 닫힐 때) 블록을 업로드하며 이러한 메트릭은 Store 구성 요소를 사용하는 쿼리에 사용할 수 있습니다.
로컬 데이터의 보존 시간을 설정할 수도 있습니다. 이 경우 일상적인 사용 및 문제 해결을 위해 모든 로컬 데이터가 30일 동안 보존되므로 쿼리 속도가 빨라집니다 .
30일보다 오래된 데이터는 S3에서만 사용할 수 있으며 장기 평가 및 비교를 위해 최대 1년 동안 유지됩니다.
데이터 쿼리
쿼리를 위해 데이터가 수집되어 수신기에 저장됩니다. 이 부분도 여러 데이터 센터에서 사용할 수 있도록 설정되어 있습니다.
Grafana 및 Query를 실행하는 각 서버에서 하나(또는 둘 다)가 다운되면 로드 밸런서에서 더 쉽게 식별하고 제거할 수 있습니다. Grafana에서는 데이터 원본이 localhost로 구성되어 있으므로 항상 로컬 쿼리를 사용하여 데이터를 가져옵니다.
쿼리 구성의 경우 메트릭을 저장하는 모든 서버(수신자 및 저장소)를 알아야 합니다. 쿼리 구성 요소는 어떤 서버가 온라인 상태인지 알고 있으며 해당 서버에서 메트릭을 수집할 수 있습니다.
데이터 쿼리
또한 중복 제거를 관리합니다. 모든 서버를 쿼리하고 복제를 구성하므로 모든 메트릭에는 여러 복사본이 있습니다. 이는 메트릭에 할당된 레이블 및 쿼리 매개 변수()를 사용하여 --query.replica-label=QUERY.REPLICA-LABEL수행 할 수 있습니다. 이러한 구성을 통해 쿼리 구성 요소는 Receiver 및 Store에서 수집된 메트릭이 중복되었는지 여부를 알고 하나의 데이터 포인트만 사용합니다.
장기 데이터
앞서 언급했듯이 데이터는 최대 30일 동안 로컬에 보관되며 나머지는 모두 S3에 저장됩니다. 이렇게 하면 수신기에 필요한 공간이 줄어들고 블록 스토리지가 개체 스토리지보다 비싸기 때문에 비용이 절감됩니다. 30일 이상의 데이터를 쿼리하는 것은 말할 것도 없이 일반적이지 않으며 주로 리소스 사용 내역 및 예측에 사용됩니다.
원격 데이터 쿼리
Store는 또한 S3 버킷에 저장된 각 TSDB 청크에 대한 인덱스의 로컬 복사본을 유지하므로 30일 이상의 데이터를 쿼리해야 하는 경우 데이터를 제공하기 위해 다운로드하고 사용할 청크를 알고 있습니다.
데이터 상황
모든 클러스터를 고려한 모니터링 체계:
-
6개의 Kubernetes 클러스터를 모니터링했습니다.
-
670개 서비스의 수집된 지표
-
Node Exporter를 사용하여 246개의 서버를 모니터링했습니다.
-
분당 약 27w 표시기를 수집합니다.
-
하루에 약 7.3GB의 데이터 또는 매월 약 226.3GB의 데이터를 수집합니다.
-
Kubernetes 구성요소 전용 대시보드 40개 생성
-
Grafana에 116개의 알람이 생성됩니다.
대부분의 구성 요소가 온프레미스에서 실행되는 월 사용료는 AWS 서비스 비용을 포함하여 월 $38,421.25에서 $3,608.99로 90.61% 감소했습니다 .
요약하다
다른 솔루션 테스트, 아키텍처 유효성 검사, 구현, 클러스터에서 수집 켜기 및 모든 대시보드 생성을 포함하여 위의 아키텍처를 구성하고 설정하는 데 약 한 달 정도 걸렸습니다.
첫 주에 이점이 분명했습니다. 클러스터 모니터링이 더 쉬워지고, 대시보드를 빠르게 구축하고 사용자 정의할 수 있으며, 메트릭 수집은 거의 플러그 앤 플레이 방식이며, 대부분의 애플리케이션은 메트릭을 Prometheus 형식으로 내보내고, 주석을 기반으로 자동으로 수집합니다.
또한 Grafana의 LDAP를 통합하여 더 세밀한 팀 권한 제어를 달성할 수 있습니다. 개발자와 SRE는 네임스페이스, 인그레스 등에 대한 관련 메트릭이 포함된 많은 대시보드에 액세스할 수 있습니다.