VictoriaMetrics 및 프라이빗 클라우드 모니터링. 파벨 콜로바예프

VictoriaMetrics는 시계열 형태로 데이터를 저장하고 처리하기 위한 빠르고 확장 가능한 DBMS입니다(레코드는 시간과 이 시간에 해당하는 일련의 값으로 구성됩니다. 예를 들어 센서 상태를 주기적으로 폴링하거나 지표 수집).

제 이름은 콜로바예프 파벨입니다. DevOps, SRE, LeroyMerlin 등 모든 것이 코드와 같습니다. 이는 모두 우리에 관한 것입니다. 저와 다른 LeroyMerlin 직원에 관한 것입니다.

https://bit.ly/3jf1fIK

OpenStack을 기반으로 한 클라우드가 있습니다. 기술 레이더에 대한 작은 링크가 있습니다.

이는 Kubernetes 하드웨어는 물론 OpenStack 및 로깅을 위한 모든 관련 서비스를 기반으로 구축되었습니다.

이것이 우리가 개발할 때 가졌던 계획입니다. 이 모든 것을 개발할 때 K8s 클러스터 자체 내에 데이터를 저장하는 Prometheus 연산자가 있었습니다. 그는 문질러야 할 부분을 자동으로 찾아서 대략적으로 말하면 발 아래에 놓습니다.

어떤 일이 발생하면 무엇이 어디서 발생하는지 이해해야 하기 때문에 모든 데이터를 Kubernetes 클러스터 외부로 이동해야 합니다.

첫 번째 해결책은 타사 Prometheus가 있을 때, 페더레이션 메커니즘을 통해 Kubernetes 클러스터로 이동할 때 페더레이션을 사용하는 것입니다.

그러나 여기에는 몇 가지 작은 문제가 있습니다. 우리의 경우 메트릭이 250개일 때 문제가 시작되었고, 메트릭이 000개가 되었을 때 우리는 그렇게 일할 수 없다는 것을 깨달았습니다. scrape_timeout을 400초로 늘렸습니다.

우리는 왜 이런 일을 해야 했나요? Prometheus는 펜스 시작부터 시간 초과를 계산하기 시작합니다. 데이터가 계속 흐르고 있다는 것은 중요하지 않습니다. 지정된 기간 동안 데이터가 병합되지 않고 http를 통해 세션이 닫히지 않으면 세션이 실패한 것으로 간주되어 데이터가 Prometheus 자체에 들어 가지 않습니다.

데이터 중 일부가 누락되었을 때 나타나는 그래프는 누구나 잘 알고 있습니다. 일정이 찢어졌고 우리는 이에 만족하지 않습니다.

다음 옵션은 동일한 페더레이션 메커니즘을 통해 서로 다른 두 Prometheus를 기반으로 샤딩하는 것입니다.

예를 들어, 이름을 기준으로 샤딩하면 됩니다. 이것도 사용할 수 있지만 계속 진행하기로 결정했습니다.

이제 어떻게든 이 샤드를 처리해야 합니다. 샤드 영역으로 이동하여 데이터를 증폭시키는 promxy를 사용할 수 있습니다. 두 개의 샤드를 단일 진입점으로 사용합니다. 이는 promxy를 통해 구현할 수 있지만 여전히 너무 어렵습니다.

첫 번째 옵션은 매우 느리기 때문에 연합 메커니즘을 포기하는 것입니다.

Prometheus 개발자는 "여러분, 우리는 메트릭의 장기 저장을 지원하지 않기 때문에 다른 TimescaleDB를 사용하십시오."라고 분명히 말합니다. 이것은 그들의 임무가 아닙니다.

우리는 모든 것을 한 곳에 보관하지 않기 위해 여전히 외부에서 내려야 할 종이에 적어 둡니다.

두 번째 단점은 메모리 소비입니다. 예, 많은 사람들이 2020년에는 몇 기가바이트의 메모리 비용이 XNUMX페니라고 말할 것이라는 점을 이해합니다.

이제 개발 및 프로덕션 환경이 생겼습니다. 개발에서는 9개의 지표에 대해 약 350GB입니다. 프로덕션 환경에서는 000GB이고 측정항목이 14개가 조금 넘습니다. 동시에 우리의 보유 시간은 단 780분입니다. 이것은 나쁘다. 이제 그 이유를 설명하겠습니다.

즉, 35만 개의 메트릭을 사용하여 계산을 수행하고 이미 그 값에 가까워졌으며 설계 단계에서 37-4GB의 메모리를 얻습니다. 그러나 이미 90만 개의 메트릭에는 약 XNUMXGB의 메모리가 필요합니다. 즉, Prometheus 개발자가 제공하는 공식을 사용하여 계산되었습니다. 우리는 상관 관계를 살펴보고 단지 모니터링만을 위해 서버에 몇 백만 달러를 지불하고 싶지 않다는 것을 깨달았습니다.

우리는 머신 수를 늘릴 뿐만 아니라 가상 머신 자체도 모니터링할 예정입니다. 따라서 가상 머신이 많을수록 다양한 종류의 메트릭이 많아집니다. 메트릭 측면에서 클러스터가 특별히 성장할 것입니다.

디스크 공간이 있으면 여기서 모든 것이 그렇게 나쁘지는 않지만 개선하고 싶습니다. 우리는 15일 동안 총 120GB를 받았습니다. 그 중 100개는 압축된 데이터이고 20개는 압축되지 않은 데이터이지만 우리는 항상 더 적은 양을 원합니다.

따라서 우리는 한 가지 점을 더 기록합니다. 이는 모니터링 클러스터가 OpenStack을 관리하는 클러스터보다 더 많은 리소스를 소비하는 것을 원하지 않기 때문에 여전히 절약하고 싶은 리소스 소비가 크다는 것입니다.

우리가 스스로 확인한 Prometheus의 단점이 하나 더 있습니다. 이는 적어도 일종의 메모리 제한입니다. Prometheus를 사용하면 그런 왜곡이 전혀 없기 때문에 모든 것이 훨씬 더 나쁩니다. Docker에서 제한을 사용하는 것도 옵션이 아닙니다. 갑자기 RAF가 떨어지고 용량이 20-30GB인 경우 상승하는 데 매우 오랜 시간이 걸립니다.

이것이 Prometheus가 우리에게 적합하지 않은 또 다른 이유입니다. 즉, 메모리 소비를 제한할 수 없습니다.

그러한 계획을 세우는 것이 가능할 것입니다. HA 클러스터를 구성하려면 이 체계가 필요합니다. 우리는 이러한 측정항목을 저장하는 서버가 충돌하더라도 측정항목을 언제 어디서나 사용할 수 있기를 원합니다. 따라서 우리는 그러한 계획을 세워야 할 것입니다.

이 계획은 샤드가 중복되어 소비되는 리소스 비용이 중복된다는 것을 의미합니다. 거의 수평으로 확장할 수 있지만 그럼에도 불구하고 리소스 소비는 지옥 수준입니다.

단점을 우리가 직접 적어 놓은 형식으로 나열하면 다음과 같습니다.

• 측정항목을 외부로 업로드해야 합니다.
• 높은 자원 소비.
• 메모리 소비를 제한할 수 있는 방법은 없습니다.
• 복잡하고 리소스 집약적인 HA 구현.

우리는 저장 시설인 프로메테우스에서 벗어나기로 결정했습니다.

우리는 우리에게 필요한 추가 요구 사항을 확인했습니다. 이것:

• 이는 Prometheus에 대해 쿼리, 경고 등 많은 항목이 이미 작성되었기 때문에 promql 지원입니다.
• 그리고 Prometheus의 백엔드와 정확히 동일한 방식으로 이미 작성된 Grafana가 있습니다. 대시보드를 다시 작성하고 싶지 않습니다.
• 우리는 일반적인 HA 아키텍처를 구축하고 싶습니다.
• 우리는 모든 자원의 소비를 줄이고 싶습니다.
• 또 다른 작은 뉘앙스가 있습니다. 다양한 유형의 클라우드 메트릭 수집 시스템을 사용할 수 없습니다. 우리는 아직 이러한 측정항목에 무엇이 포함될지 모릅니다. 그리고 무엇이든 그곳으로 날아갈 수 있기 때문에 우리는 로컬 배치로 제한해야 합니다.

선택의 여지가 거의 없었습니다. 우리는 우리가 경험한 모든 것을 수집했습니다. 우리는 통합 섹션의 Prometheus 페이지를 살펴보고 여러 기사를 읽고 거기에 무엇이 있는지 확인했습니다. 그리고 우리는 Prometheus의 대체 제품으로 VictoriaMetrics를 선택했습니다.

왜? 왜냐하면:

• promql을 알고 있습니다.
• 모듈식 아키텍처가 있습니다.
• Grafana를 변경할 필요가 없습니다.
• 그리고 가장 중요한 것은 아마도 회사 내 메트릭 스토리지를 서비스로 제공할 것이므로 사용자가 클러스터의 모든 리소스를 제한된 방식으로 사용할 수 있도록 다양한 종류의 제한을 미리 고려하고 있습니다. 멀티테넌시가 될 것입니다.

첫 번째 비교를 해보겠습니다. 우리는 클러스터 내부에 동일한 프로메테우스를 가져오고, 외부 프로메테우스는 클러스터로 이동합니다. RemoteWrite VictoriaMetrics를 통해 추가하세요.

여기서는 VictoriaMetrics의 CPU 소비가 약간 증가했음을 즉시 확인하겠습니다. VictoriaMetrics 위키는 어떤 매개변수가 가장 좋은지 알려줍니다. 우리는 그것을 확인했습니다. CPU 소비를 매우 잘 줄였습니다.

우리의 경우 Kubernetes 클러스터에 위치한 Prometheus의 메모리 소비는 크게 증가하지 않았습니다.

동일한 데이터의 두 데이터 소스를 비교합니다. Prometheus에서도 동일한 누락 데이터를 볼 수 있습니다. VictoriaMetrics에서는 모든 것이 괜찮습니다.

디스크 공간 테스트 결과. Prometheus에서는 총 120GB를 받았습니다. VictoriaMetrics에서는 이미 하루에 4GB를 받고 있습니다. 우리가 Prometheus에서 보던 것과는 약간 다른 메커니즘이 있습니다. 즉, 데이터는 이미 하루, XNUMX분 만에 꽤 잘 압축되었습니다. 데이터가 나중에 손실된다는 사실에도 불구하고 이미 하루, XNUMX분 만에 잘 수확되었습니다. 결과적으로 디스크 공간이 절약되었습니다.

또한 메모리 리소스 소비도 절약됩니다. 테스트 당시 우리는 8코어, 24GB의 가상 머신에 Prometheus를 배포했습니다. 프로메테우스는 거의 모든 것을 먹습니다. 그는 OOM Killer에 떨어졌습니다. 동시에 900개의 활성 지표만 쏟아졌습니다. 이는 초당 약 000~25개의 측정항목입니다.

우리는 8GB RAM을 갖춘 듀얼 코어 가상 머신에서 VictoriaMetrics를 실행했습니다. 우리는 8GB 시스템에서 몇 가지 사항을 조정하여 VictoriaMetrics가 잘 작동하도록 만들었습니다. 결국 7GB로 유지했습니다. 동시에 콘텐츠 전달 속도, 즉 지표도 프로메테우스보다 훨씬 빨랐다.

프로메테우스에 비해 CPU가 훨씬 좋아졌습니다. 여기서 Prometheus는 2,5개의 코어를 소비하고 VictoriaMetrics는 0,25개의 코어만 소비합니다. 시작 시 – 0,5 코어. 합쳐지면서 하나의 코어에 도달하지만 이는 극히 극히 드뭅니다.

우리의 경우에는 비용을 절감하고 싶었고 그렇게 했다는 분명한 이유로 VictoriaMetrics를 선택했습니다.

지표 업로드와 높은 리소스 소비라는 두 가지 사항을 바로 삭제해 보겠습니다. 그리고 아직 우리에게 남은 두 가지 점만 결정하면 됩니다.

여기서는 바로 예약하겠습니다. VictoriaMetrics를 측정항목 저장소로 간주합니다. 그러나 우리는 Leroy 전체에 대한 스토리지로 VictoriaMetrics를 제공할 가능성이 높으므로 이 클러스터를 사용하는 사람들이 우리에게 클러스터를 제공하지 않도록 제한해야 합니다.

시간, 데이터 양, 실행 시간을 기준으로 제한할 수 있는 훌륭한 매개변수가 있습니다.

메모리 소비를 제한할 수 있는 탁월한 옵션도 있으므로 정상적인 작동 속도와 적절한 리소스 소비를 얻을 수 있는 균형을 찾을 수 있습니다.

한 가지 포인트를 더 뺍니다. 즉, 해당 포인트에 줄을 그어 지웁니다. 메모리 소비를 제한할 수 없습니다.

첫 번째 반복에서는 VictoriaMetrics Single Node를 테스트했습니다. 다음으로 VictoriaMetrics 클러스터 버전으로 이동합니다.

여기서 우리는 VictoriaMetrics에서 실행 대상과 소비할 리소스에 따라 다양한 서비스를 자유롭게 분리할 수 있습니다. 이는 매우 유연하고 편리한 솔루션입니다. 우리는 이것을 스스로 사용했습니다.

VictoriaMetrics 클러스터 버전의 주요 구성 요소는 vmstsorage입니다. N개의 숫자가 있을 수 있습니다. 우리의 경우에는 지금까지 2개가 있습니다.

그리고 vminsert가 있습니다. 이것은 우리가 말한 모든 저장소 사이에 샤딩을 정렬하고 복제본을 허용하는 프록시 서버입니다. 즉, 샤딩과 복제본을 모두 갖게 됩니다.

Vminsert는 Prometheus의 OpenTSDB, Graphite, InfluxDB 및 RemoteWrite 프로토콜을 지원합니다.

vmselect도 있습니다. 주요 작업은 vmstorage로 이동하여 데이터를 수신하고 이 데이터를 중복 제거하여 클라이언트에 제공하는 것입니다.

vmagent라는 놀라운 것이 있습니다. 우리는 그녀를 정말 좋아합니다. 이를 통해 Prometheus와 똑같이 구성하고 모든 작업을 Prometheus와 똑같이 수행할 수 있습니다. 즉, 다양한 엔터티와 서비스에서 메트릭을 수집하여 vminsert로 보냅니다. 그러면 모든 것이 당신에게 달려 있습니다.

또 다른 훌륭한 서비스는 vmalert입니다. 이를 통해 VictoriaMetrics를 백엔드로 사용하고, vminsert에서 처리된 데이터를 받아 vmselect로 보낼 수 있습니다. 규칙뿐만 아니라 경고 자체도 처리합니다. 알림의 경우, Alertmanager를 통해 알림을 받습니다.

wmauth 구성 요소가 있습니다. 우리는 이를 클러스터의 다중 테넌트 버전에 대한 인증 시스템으로 사용할 수도 있고 사용하지 않을 수도 있습니다(아직 결정하지 않았습니다). Prometheus에 대한 remoteWrite를 지원하며 URL 또는 쓰기 가능 여부의 두 번째 부분을 기반으로 권한을 부여할 수 있습니다.

vmbackup, vmrestore도 있습니다. 이는 본질적으로 모든 데이터의 복원 및 백업입니다. S3, GCS, 파일을 할 수 있습니다.

클러스터의 첫 번째 반복은 격리 중에 이루어졌습니다. 그 당시에는 복제본이 없었기 때문에 우리의 반복은 두 개의 서로 다른 독립적인 클러스터로 구성되었으며, 이를 통해 remoteWrite를 통해 데이터가 수신되었습니다.

여기서는 VictoriaMetrics Single Node에서 VictoriaMetrics Cluster 버전으로 전환했을 때 여전히 동일한 소비 리소스, 즉 주요 리소스가 메모리라는 점을 예약하겠습니다. 이것이 우리의 데이터, 즉 자원 소비가 대략적으로 분산된 방식입니다.

여기에 복제본이 이미 추가되었습니다. 우리는 이 모든 것을 상대적으로 큰 하나의 클러스터로 결합했습니다. 우리의 모든 데이터는 분할되고 복제됩니다.

전체 클러스터에는 N개의 진입점이 있습니다. 이는 Prometheus가 HAPROXY를 통해 데이터를 추가할 수 있음을 의미합니다. 여기에 진입점이 있습니다. 그리고 이 진입점을 통해 Grafana에서 로그인할 수 있습니다.

우리의 경우 HAPROXY는 이 클러스터 내에서 선택, 삽입 및 기타 서비스를 프록시하는 유일한 포트입니다. 우리의 경우 하나의 주소를 만드는 것이 불가능했고, VictoriaMetrics 클러스터가 실행되는 가상 머신 자체가 동일한 클라우드 공급자의 다른 영역, 즉 클라우드 내부가 아닌 외부에 위치하기 때문에 여러 진입점을 만들어야 했습니다. .

경고가 있습니다. 우리는 그것을 사용합니다. 우리는 Prometheus의 Alertmanager를 사용합니다. 우리는 알림 전달 채널로 Opsgenie와 Telegram을 사용합니다. 텔레그램에서는 개발자로부터, 어쩌면 프로덕션에서 나온 것일 수도 있지만 대부분 엔지니어에게 필요한 통계적인 정보가 쏟아져 나옵니다. 그리고 Opsgenie는 매우 중요합니다. 통화, 사고 관리입니다.

영원한 질문: "누가 모니터링을 모니터링합니까?" 우리의 경우 각 노드에서 vmagent를 사용하기 때문에 모니터링은 모니터링 자체를 모니터링합니다. 그리고 우리 노드는 동일한 공급자의 여러 데이터 센터에 분산되어 있기 때문에 각 데이터 센터에는 자체 채널이 있고 독립적이며 분할 두뇌가 도착하더라도 여전히 경고를 받게 됩니다. 예, 더 많을 것입니다. 그러나 알림을 받지 않는 것보다는 더 많은 알림을 받는 것이 더 낫습니다.

HA 구현으로 목록을 마무리합니다.

또한 VictoriaMetrics 커뮤니티와의 소통 경험에 주목하고 싶습니다. 그것은 매우 긍정적인 것으로 나타났습니다. 사람들은 반응이 좋습니다. 그들은 제공되는 모든 사례를 조사하려고 노력합니다.

GitHub에서 문제를 시작했습니다. 문제는 매우 빠르게 해결되었습니다. 완전히 해결되지 않은 몇 가지 문제가 더 있지만 이 방향으로 작동하는 코드가 진행 중인 것을 이미 볼 수 있습니다.

반복하는 동안 저에게 가장 큰 고통은 노드를 종료하면 처음 30초 동안 vminsert가 백엔드가 없다는 것을 이해할 수 없다는 것이었습니다. 이제 이것이 결정되었습니다. 문자 그대로 XNUMX~XNUMX초 안에 나머지 모든 노드에서 데이터가 가져오고 요청은 누락된 노드를 기다리는 것을 중지합니다.

어느 시점에서 우리는 VictoriaMetrics가 VictoriaMetrics 운영자가 되기를 원했습니다. 우리는 그를 기다렸습니다. 우리는 현재 Prometheus 연산자와 함께 제공되는 규칙을 매우 적극적으로 사용하고 있기 때문에 모든 사전 계산 규칙 등을 가져오기 위해 VictoriaMetrics 연산자용 프레임워크를 적극적으로 구축하고 있습니다.

클러스터 구현을 개선하기 위한 제안이 있습니다. 위에 설명했습니다.

그리고 저는 정말로 다운샘플링을 하고 싶습니다. 우리의 경우 추세를 확인하기 위해서만 다운샘플링이 필요합니다. 대략적으로 말하면 하루 동안 하나의 측정 항목이면 충분합니다. 이러한 추세는 XNUMX년, XNUMX년, XNUMX년, XNUMX년 동안 필요합니다. 하나의 측정항목 값이면 충분합니다.

• 우리는 일부 동료들처럼 Prometheus를 사용할 때 고통을 겪었습니다.
• 우리는 VictoriaMetrics를 선택했습니다.
• 수직, 수평 모두 아주 잘 확장됩니다.
• 다양한 구성요소를 클러스터의 다양한 노드 수에 배포하고, 메모리별로 제한하고, 메모리를 추가하는 등의 작업을 수행할 수 있습니다.

우리는 그것이 정말 마음에 들었기 때문에 집에서 VictoriaMetrics를 사용할 것입니다. 이것이 과거의 일이고 현재의 일입니다.

https://t.me/VictoriaMetrics_ru1

VictoriaMetrics 채팅, 내 연락처, LeroyMerlin 기술 레이더용 QR 코드 두 개.

출처 : habr.com