Prometheus 2의 TSDB 분석

Prometheus 2의 시계열 데이터베이스(TSDB)는 데이터 축적 속도, 쿼리 실행 및 리소스 효율성 측면에서 Prometheus 2의 v1 ​​스토리지에 비해 크게 향상된 엔지니어링 솔루션의 훌륭한 예입니다. 우리는 PMM(Percona Monitoring and Management)에서 Prometheus 2를 구현하고 있었고 Prometheus 2 TSDB의 성능을 이해할 기회를 가졌습니다. 이 기사에서는 이러한 관찰 결과에 대해 이야기하겠습니다.

평균 Prometheus 워크로드

범용 데이터베이스를 다루는 데 익숙한 사람들에게는 일반적인 Prometheus 워크로드가 매우 흥미로울 것입니다. 데이터 축적 속도는 안정적인 경향이 있습니다. 일반적으로 모니터링하는 서비스는 거의 동일한 수의 측정항목을 보내고 인프라는 상대적으로 느리게 변경됩니다.
정보 요청은 다양한 출처에서 이루어질 수 있습니다. 경고와 같은 일부 기능도 안정적이고 예측 가능한 값을 위해 노력합니다. 사용자 요청과 같은 다른 요청으로 인해 버스트가 발생할 수 있지만 대부분의 워크로드에는 해당되지 않습니다.

부하 테스트

테스트하면서 데이터 축적 능력에 중점을 두었습니다. 다음 스크립트를 사용하여 Go 2.3.2(PMM 1.10.1의 일부)로 컴파일된 Prometheus 1.14를 Linode 서비스에 배포했습니다. 스택스크립트. 가장 현실적인 부하 생성을 위해 다음을 사용합니다. 스택스크립트 저는 실제 로드(Sysbench TPC-C 테스트)를 사용하여 여러 개의 MySQL 노드를 시작했습니다. 각 노드는 10개의 Linux/MySQL 노드를 에뮬레이트했습니다.
다음 테스트는 모두 32개의 가상 코어와 20GB 메모리를 갖춘 Linode 서버에서 수행되었으며, 800개의 MySQL 인스턴스를 모니터링하는 440개의 로드 시뮬레이션을 실행했습니다. 또는 Prometheus 용어로 말하면 380개의 대상, 초당 1,7개의 스크레이핑, 초당 XNUMX만 개의 레코드, XNUMX만 개의 활성 시계열입니다.

디자인

Prometheus 1.x에서 사용되는 데이터베이스를 포함하여 기존 데이터베이스의 일반적인 접근 방식은 다음과 같습니다. 메모리 제한. 로드를 처리하기에 충분하지 않으면 대기 시간이 길어지고 일부 요청이 실패하게 됩니다. Prometheus 2의 메모리 사용량은 키를 통해 구성 가능 storage.tsdb.min-block-duration, 디스크에 플러시하기 전에 녹음 내용을 메모리에 보관할 기간을 결정합니다(기본값은 2시간). 필요한 메모리 양은 순 수신 스트림에 추가된 시계열, 레이블 및 스크랩 수에 따라 달라집니다. 디스크 공간 측면에서 Prometheus는 레코드(샘플)당 3바이트를 사용하는 것을 목표로 합니다. 반면에 메모리 요구 사항은 훨씬 높습니다.

블록 크기를 구성하는 것은 가능하지만 수동으로 구성하는 것은 권장되지 않으므로 작업 부하에 필요한 만큼의 메모리를 Prometheus에 제공해야 합니다.
들어오는 메트릭 스트림을 지원할 만큼 메모리가 충분하지 않으면 Prometheus의 메모리가 부족해지거나 OOM 킬러가 메모리에 접근하게 됩니다.
Prometheus의 메모리가 부족할 때 충돌을 지연시키기 위해 스왑을 추가하는 것은 실제로 도움이 되지 않습니다. 이 기능을 사용하면 폭발적인 메모리 소비가 발생하기 때문입니다. 내 생각에는 Go의 가비지 수집기 및 Go가 스왑을 처리하는 방식과 관련이 있는 것 같습니다.
또 다른 흥미로운 접근 방식은 프로세스 시작부터 계산하는 대신 헤드 블록이 특정 시간에 디스크에 플러시되도록 구성하는 것입니다.

그래프에서 볼 수 있듯이 디스크 플러시는 XNUMX시간마다 발생합니다. min-block-duration 매개변수를 XNUMX시간으로 변경하면 이러한 재설정은 XNUMX분 이후부터 시작하여 매시간 발생합니다.
Prometheus 설치에서 이 그래프와 다른 그래프를 사용하려면 다음을 사용할 수 있습니다. 계기반. PMM용으로 설계되었지만 약간만 수정하면 모든 Prometheus 설치에 적합합니다.
메모리에 저장되는 헤드 블록이라는 활성 블록이 있습니다. 이전 데이터가 포함된 블록은 다음을 통해 사용할 수 있습니다. mmap(). 이렇게 하면 캐시를 별도로 구성할 필요가 없지만 헤드 블록이 수용할 수 있는 것보다 오래된 데이터를 쿼리하려는 경우 운영 체제 캐시를 위한 충분한 공간을 확보해야 함을 의미합니다.
이는 또한 Prometheus 가상 메모리 소비가 상당히 높아 보일 것이라는 의미이므로 걱정할 필요가 없습니다.

또 다른 흥미로운 디자인 포인트는 WAL(미리 쓰기 로그)을 사용하는 것입니다. 스토리지 문서에서 볼 수 있듯이 Prometheus는 WAL을 사용하여 충돌을 방지합니다. 안타깝게도 데이터 생존성을 보장하기 위한 구체적인 메커니즘은 잘 문서화되어 있지 않습니다. Prometheus 버전 2.3.2는 10초마다 WAL을 디스크에 플러시하며 이 옵션은 사용자가 구성할 수 없습니다.

다짐

Prometheus TSDB는 LSM(Log Structured Merge) 저장소처럼 설계되었습니다. 헤드 블록은 주기적으로 디스크에 플러시되는 반면, 압축 메커니즘은 쿼리 중에 너무 많은 블록을 스캔하지 않도록 여러 블록을 결합합니다. 여기에서 하루 동안 로드한 후 테스트 시스템에서 관찰한 블록 수를 확인할 수 있습니다.

스토어에 대해 자세히 알아보려면 사용 가능한 블록과 해당 블록이 어떻게 생성되었는지에 대한 정보가 포함된 Meta.json 파일을 검사할 수 있습니다.

{
       "ulid": "01CPZDPD1D9R019JS87TPV5MPE",
       "minTime": 1536472800000,
       "maxTime": 1536494400000,
       "stats": {
               "numSamples": 8292128378,
               "numSeries": 1673622,
               "numChunks": 69528220
       },
       "compaction": {
               "level": 2,
               "sources": [
                       "01CPYRY9MS465Y5ETM3SXFBV7X",
                       "01CPYZT0WRJ1JB1P0DP80VY5KJ",
                       "01CPZ6NR4Q3PDP3E57HEH760XS"
               ],
               "parents": [
                       {
                               "ulid": "01CPYRY9MS465Y5ETM3SXFBV7X",
                               "minTime": 1536472800000,
                               "maxTime": 1536480000000
                       },
                       {
                               "ulid": "01CPYZT0WRJ1JB1P0DP80VY5KJ",
                               "minTime": 1536480000000,
                               "maxTime": 1536487200000
                       },
                       {
                               "ulid": "01CPZ6NR4Q3PDP3E57HEH760XS",
                               "minTime": 1536487200000,
                               "maxTime": 1536494400000
                       }
               ]
       },
       "version": 1
}

Prometheus의 압축은 헤드 블록이 디스크에 플러시되는 시간과 연결됩니다. 이 시점에서 이러한 여러 작업이 수행될 수 있습니다.

압축은 어떤 식으로든 제한되지 않으며 실행 중에 큰 디스크 I/O 스파이크를 일으킬 수 있는 것으로 보입니다.

CPU 로드 스파이크

물론 이는 시스템 속도에 다소 부정적인 영향을 미치며 LSM 저장소에 심각한 과제를 안겨줍니다. 너무 많은 오버헤드를 발생시키지 않고 높은 요청 속도를 지원하기 위해 압축을 수행하는 방법은 무엇입니까?
압축 과정에서 메모리를 사용하는 것도 꽤 흥미로워 보입니다.

압축 후 대부분의 메모리 상태가 Cached에서 Free로 변경되는 방식을 볼 수 있습니다. 이는 잠재적으로 가치 있는 정보가 거기에서 제거되었음을 의미합니다. 여기에 사용되는지 궁금합니다 fadvice() 아니면 다른 최소화 기술인가요? 아니면 압축 중에 파괴된 블록에서 캐시가 해제되었기 때문인가요?

장애 후 복구

장애 복구에는 시간이 걸리며 그럴 만한 이유가 있습니다. 초당 백만 개의 레코드가 들어오는 스트림의 경우 SSD 드라이브를 고려하여 복구가 수행되는 동안 약 25분을 기다려야 했습니다.

level=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Starting Prometheus" version="(version=2.3.2, branch=v2.3.2, revision=71af5e29e815795e9dd14742ee7725682fa14b7b)"
level=info ts=2018-09-13T13:38:14.096599879Z caller=main.go:223 build_context="(go=go1.10.1, user=Jenkins, date=20180725-08:58:13OURCE)"
level=info ts=2018-09-13T13:38:14.096624109Z caller=main.go:224 host_details="(Linux 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC 2018 x86_64 1bee9e9b78cf (none))"
level=info ts=2018-09-13T13:38:14.096641396Z caller=main.go:225 fd_limits="(soft=1048576, hard=1048576)"
level=info ts=2018-09-13T13:38:14.097715256Z caller=web.go:415 component=web msg="Start listening for connections" address=:9090
level=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="Starting TSDB ..."
level=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
level=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="router prefix" prefix=/prometheus
level=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
level=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
level=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
level=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
level=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="WAL corruption detected; truncating" err="unexpected CRC32 checksum d0465484, want 0" file=/opt/prometheus/data/.prom2-data/wal/007357 pos=15504363
level=info ts=2018-09-13T14:05:19.471459777Z caller=main.go:543 msg="TSDB started"
level=info ts=2018-09-13T14:05:19.471604598Z caller=main.go:603 msg="Loading configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Completed loading of configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499228186Z caller=main.go:502 msg="Server is ready to receive web requests."

복구 프로세스의 주요 문제는 높은 메모리 소비입니다. 정상적인 상황에서는 서버가 동일한 양의 메모리로 안정적으로 작동할 수 있음에도 불구하고 충돌이 발생하면 OOM으로 인해 복구되지 않을 수 있습니다. 내가 찾은 유일한 해결책은 데이터 수집을 비활성화하고, 서버를 가동하고, 수집이 활성화된 상태에서 복구하고 재부팅하는 것이었습니다.

워밍업

워밍업 중에 염두에 두어야 할 또 다른 동작은 시작 직후 낮은 성능과 높은 리소스 소비 사이의 관계입니다. 전부는 아니지만 일부 시작 중에 CPU와 메모리에 심각한 부하가 발생하는 것을 관찰했습니다.

메모리 사용량의 차이는 Prometheus가 처음부터 모든 컬렉션을 구성할 수 없으며 일부 정보가 손실되었음을 나타냅니다.
CPU와 메모리 부하가 높은 정확한 이유를 파악하지 못했습니다. 나는 이것이 높은 빈도로 헤드 블록에 새로운 시계열이 생성되었기 때문이라고 생각합니다.

CPU 부하 급증

상당히 높은 I/O 로드를 생성하는 압축 외에도 XNUMX분마다 CPU 로드가 심각하게 급증하는 것을 발견했습니다. 입력 흐름이 높을 때 버스트는 더 길어지고 Go의 가비지 수집기로 인해 발생하는 것으로 보이며 적어도 일부 코어가 완전히 로드됩니다.

이러한 점프는 그다지 중요하지 않습니다. 이러한 일이 발생하면 Prometheus의 내부 진입점과 측정항목을 사용할 수 없게 되어 동일한 기간 동안 데이터 격차가 발생하는 것으로 보입니다.

또한 Prometheus 내보내기가 XNUMX초 동안 종료되는 것을 확인할 수 있습니다.

가비지 컬렉션(GC)과의 상관관계를 확인할 수 있습니다.

결론

Prometheus 2의 TSDB는 속도가 빠르고 상당히 적당한 하드웨어를 사용하여 수백만 개의 시계열과 동시에 초당 수천 개의 레코드를 처리할 수 있습니다. CPU 및 디스크 I/O 활용도도 인상적입니다. 내 예에서는 사용된 코어당 초당 최대 200개의 메트릭을 보여주었습니다.

확장을 계획하려면 충분한 양의 메모리를 기억해야 하며 이는 실제 메모리여야 합니다. 내가 관찰한 사용된 메모리 양은 들어오는 스트림의 초당 5개 레코드당 약 100GB였으며 운영 체제 캐시와 함께 약 000GB의 점유 메모리를 제공했습니다.

물론 CPU 및 디스크 I/O 급증을 억제하기 위해 수행해야 할 작업이 여전히 많습니다. 이는 젊은 TSDB Prometheus 2가 InnoDB, TokuDB, RocksDB, WiredTiger와 비교되는 방식을 고려하면 놀라운 일이 아니지만 모두 유사했습니다. 수명주기 초기에 문제가 발생합니다.

출처 : habr.com