고성능 및 기본 파티셔닝: TimescaleDB를 지원하는 Zabbix

Zabbix는 모니터링 시스템입니다. 다른 시스템과 마찬가지로 모든 모니터링 시스템의 세 가지 주요 문제, 즉 데이터 수집 및 처리, 기록 저장 및 정리에 직면합니다.

데이터 수신, 처리, 기록 단계에는 시간이 걸립니다. 많지는 않지만 대규모 시스템의 경우 이로 인해 큰 지연이 발생할 수 있습니다. 저장 문제는 데이터 액세스 문제입니다. 이는 보고서, 확인 및 트리거에 사용됩니다. 데이터 액세스 지연도 성능에 영향을 미칩니다. 데이터베이스가 커지면 관련 없는 데이터를 삭제해야 합니다. 제거는 일부 리소스를 소모하는 어려운 작업입니다.

Zabbix에서 수집 및 저장 중 지연 문제는 캐싱(여러 유형의 캐시, 데이터베이스 캐싱)을 통해 해결됩니다. 세 번째 문제를 해결하기 위해 캐싱이 적합하지 않아 Zabbix는 TimescaleDB를 사용했습니다. 그 사람이 당신에게 그것에 대해 말해 줄 거예요 안드레이 구쉬친 - 기술 지원 엔지니어 자빅스 SIA. Andrey는 6년 이상 Zabbix를 지원해 왔으며 성능에 대한 직접적인 경험을 갖고 있습니다.

TimescaleDB는 어떻게 작동하며 일반 PostgreSQL과 비교하여 어떤 성능을 제공할 수 있습니까? TimescaleDB 데이터베이스에서 Zabbix는 어떤 역할을 합니까? 처음부터 시작하는 방법과 PostgreSQL에서 마이그레이션하는 방법, 그리고 어떤 구성의 성능이 더 좋습니까? 이 모든 것에 대해 컷 아래에 있습니다.

생산성 문제

모든 모니터링 시스템은 특정 성능 문제에 직면해 있습니다. 그 중 데이터 수집 및 처리, 저장, 이력 삭제 세 가지에 대해 말씀드리겠습니다.

빠른 데이터 수집 및 처리. 좋은 모니터링 시스템은 모든 데이터를 신속하게 수신하고 해당 기준에 따라 트리거 표현에 따라 처리해야 합니다. 처리 후 시스템은 나중에 사용할 수 있도록 이 데이터를 데이터베이스에 신속하게 저장해야 합니다.

역사 저장. 좋은 모니터링 시스템은 기록을 데이터베이스에 저장하고 측정항목에 쉽게 액세스할 수 있도록 해야 합니다. 보고서, 그래프, 트리거, 임계값 및 계산된 경고 데이터 항목에 사용하려면 기록이 필요합니다.

기록을 삭제합니다. 때로는 측정항목을 저장할 필요가 없는 날이 옵니다. 5년, 한두 달 전에 수집된 데이터가 필요한 이유는 무엇입니까? 일부 노드는 삭제되었으며, 일부 호스트 또는 메트릭은 오래되어 더 이상 수집되지 않기 때문에 더 이상 필요하지 않습니다. 좋은 모니터링 시스템은 데이터베이스가 커지지 않도록 기록 데이터를 저장하고 수시로 삭제해야 합니다.

오래된 데이터를 정리하는 것은 데이터베이스 성능에 큰 영향을 미치는 중요한 문제입니다.

Zabbix의 캐싱

Zabbix에서는 첫 번째와 두 번째 호출이 캐싱을 사용하여 해결됩니다. RAM은 데이터를 수집하고 처리하는 데 사용됩니다. 저장용 - 트리거, 그래프 및 계산된 데이터 요소의 기록입니다. 데이터베이스 측에는 그래프와 같은 기본 선택 항목에 대한 일부 캐싱이 있습니다.

Zabbix 서버 자체 측의 캐싱은 다음과 같습니다.

• 구성캐시;
• 가치캐시;
• 히스토리 캐시;
• 트렌드캐시.

그들을 더 자세히 고려하십시오.

구성캐시

이는 메트릭, 호스트, 데이터 항목, 트리거(전처리 및 데이터 수집에 필요한 모든 것)를 저장하는 기본 캐시입니다.

이 모든 것은 데이터베이스에 불필요한 쿼리를 생성하지 않도록 ConfigurationCache에 저장됩니다. 서버가 시작된 후 이 캐시를 업데이트하고 구성을 생성하고 주기적으로 업데이트합니다.

데이터 수집

다이어그램은 꽤 크지만 그 안에 있는 주요 내용은 다음과 같습니다. 수집가. 이는 다양한 "폴러"(조립 프로세스)입니다. 이들은 다양한 유형의 어셈블리를 담당합니다. SNMP, IPMI를 통해 데이터를 수집하고 이를 모두 PreProcessing으로 전송합니다.

수집가는 주황색으로 윤곽선이 표시되어 있습니다.

Zabbix는 수표 집계에 필요한 집계 항목을 계산했습니다. 해당 데이터가 있으면 ValueCache에서 직접 데이터를 가져옵니다.

전처리 기록캐시

모든 수집기는 ConfigurationCache를 사용하여 작업을 수신합니다. 그런 다음 이를 PreProcessing으로 옮깁니다.

전처리는 ConfigurationCache를 사용하여 전처리 단계를 수신합니다. 이 데이터는 다양한 방식으로 처리됩니다.

PreProcessing을 사용하여 데이터를 처리한 후 처리를 위해 HistoryCache에 저장합니다. 이것으로 데이터 수집이 종료되고 Zabbix의 주요 프로세스로 이동합니다. 기록 동기화 장치, 모놀리식 아키텍처이기 때문입니다.

참고: 전처리는 상당히 어려운 작업입니다. v 4.2에서는 프록시로 이동되었습니다. 데이터 요소 수가 많고 수집 빈도가 높은 Zabbix가 매우 큰 경우 작업이 훨씬 쉬워집니다.

ValueCache, 기록 및 동향 캐시

히스토리 싱크는 각 데이터 요소, 즉 각 값을 원자적으로 처리하는 주요 프로세스입니다.

기록 동기화 장치는 HistoryCache에서 값을 가져와 구성에서 계산을 위한 트리거가 있는지 확인합니다. 존재하는 경우 계산합니다.

기록 동기화 장치는 이벤트를 생성하고 구성에 필요한 경우 경고를 생성하기 위한 에스컬레이션 및 기록을 생성합니다. 후속 처리를 위한 트리거가 있는 경우 이 값을 ValueCache에 저장하여 기록 테이블에 액세스하지 않습니다. 이는 ValueCache가 트리거 및 계산된 요소를 계산하는 데 필요한 데이터로 채워지는 방식입니다.

기록 동기화 장치는 모든 데이터를 데이터베이스에 기록하고 디스크에 기록합니다. 처리 과정은 여기서 끝납니다.

데이터베이스 캐싱

데이터베이스 측에는 이벤트에 대한 그래프나 보고서를 보려는 경우 다양한 캐시가 있습니다.

• Innodb_buffer_pool MySQL 측에서;
• shared_buffers PostgreSQL 측에서;
• effective_cache_size 오라클 측에서;
• shared_pool DB2 측에서.

다른 많은 캐시가 있지만 이것이 모든 데이터베이스의 주요 캐시입니다. 쿼리에 자주 필요한 데이터를 RAM에 저장할 수 있습니다. 그들은 이에 대한 자체 기술을 가지고 있습니다.

데이터베이스 성능이 중요합니다

Zabbix 서버는 지속적으로 데이터를 수집하고 기록합니다. 다시 시작하면 기록에서 읽어 ValueCache를 채웁니다. 스크립트 및 보고서 사용 자빅스 API, 웹 인터페이스를 기반으로 구축되었습니다. Zabbix API는 데이터베이스에 액세스하여 그래프, 보고서, 이벤트 목록 및 최신 문제에 필요한 데이터를 검색합니다.

시각화를 위해 - 그라 파나. 이는 사용자들 사이에서 인기 있는 솔루션입니다. Zabbix API와 데이터베이스를 통해 직접 요청을 보낼 수 있으며 데이터 수신을 위해 특정 경쟁을 만듭니다. 따라서 결과 및 테스트의 빠른 전달을 위해서는 데이터베이스를 보다 세밀하고 효과적으로 조정하는 것이 필요합니다.

가사도우미

Zabbix의 세 번째 성능 과제는 Housekeeper를 사용한 기록 삭제입니다. 모든 설정을 따릅니다. 데이터 요소는 변화의 역학(추세)을 며칠 단위로 저장하는 기간을 나타냅니다.

TrendsCache를 즉시 계산합니다. 데이터가 도착하면 이를 한 시간 동안 집계하여 추세 변화의 역학을 테이블에 기록합니다.

Housekeeper는 일반적인 "선택"을 사용하여 데이터베이스에서 정보를 시작하고 삭제합니다. 내부 프로세스의 성능 그래프에서 볼 수 있듯이 이는 항상 효과적인 것은 아닙니다.

빨간색 그래프는 기록 동기화 장치가 지속적으로 사용 중임을 나타냅니다. 상단의 주황색 그래프는 지속적으로 실행되는 Housekeeper입니다. 그는 데이터베이스가 자신이 지정한 모든 행을 삭제할 때까지 기다립니다.

언제 Housekeeper를 비활성화해야 합니까? 예를 들어, "항목 ID"가 있고 특정 시간 내에 마지막 5개의 행을 삭제해야 합니다. 물론 이는 인덱스별로 발생합니다. 그러나 일반적으로 데이터 세트는 매우 크고 데이터베이스는 여전히 디스크에서 읽어 캐시에 저장합니다. 이는 항상 데이터베이스에 매우 비용이 많이 드는 작업이며 데이터베이스 크기에 따라 성능 문제가 발생할 수 있습니다.

가정부는 비활성화하기 쉽습니다. 웹 인터페이스에는 Housekeeper에 대한 "관리 일반" 설정이 있습니다. 내부 추세 기록에 대한 내부 관리를 비활성화하고 더 이상 관리하지 않습니다.

Housekeeper가 꺼지고 그래프가 균등해졌습니다. 이 경우 어떤 문제가 있을 수 있으며 세 번째 성능 문제를 해결하는 데 무엇이 도움이 될 수 있습니까?

파티셔닝 - 파티셔닝 또는 파티셔닝

일반적으로 파티셔닝은 내가 나열한 각 관계형 데이터베이스에서 다른 방식으로 구성됩니다. 각각 고유한 기술이 있지만 일반적으로 유사합니다. 새 파티션을 생성하면 특정 문제가 발생하는 경우가 많습니다.

일반적으로 파티션은 하루에 생성되는 데이터 양인 "설정"에 따라 구성됩니다. 원칙적으로 파티셔닝은 하루 안에 실행되며 이것이 최소입니다. 새로운 배치의 추세 - 1개월.

"설정"이 매우 큰 경우 값이 변경될 수 있습니다. 작은 "설정"이 최대 5nvps(초당 새 값)인 경우 중간 설정은 000~5이고 큰 설정은 000nvps 이상입니다. 이는 데이터베이스를 신중하게 구성해야 하는 대규모 설치입니다.

대규모 설치에서는 하루라는 기간이 최적이 아닐 수 있습니다. 하루에 40GB 이상의 MySQL 파티션을 본 적이 있습니다. 이는 문제를 일으킬 수 있는 매우 큰 양의 데이터이므로 줄여야 합니다.

파티셔닝은 무엇을 제공합니까?

파티션 나누기 테이블. 종종 이들은 디스크에 별도의 파일로 존재합니다. 쿼리 계획은 하나의 파티션을 더 최적으로 선택합니다. 일반적으로 파티셔닝은 범위별로 사용됩니다. 이는 Zabbix에서도 마찬가지입니다. 여기서는 시대가 시작된 이후의 시간인 "타임스탬프"를 사용합니다. 이것은 우리에게 평범한 숫자입니다. 하루의 시작과 끝을 설정합니다. 이것은 파티션입니다.

빠른 제거 - DELETE. 삭제할 행을 선택하는 대신 하나의 파일/하위 테이블이 선택됩니다.

데이터 검색 속도가 대폭 향상됩니다. SELECT - 전체 테이블이 아닌 하나 이상의 파티션을 사용합니다. 이틀이 지난 데이터에 액세스하는 경우 큰 테이블이 아닌 하나의 파일만 캐시에 로드하고 반환하면 되므로 데이터베이스에서 더 빨리 검색됩니다.

종종 많은 데이터베이스도 가속화됩니다. INSERT — 하위 테이블에 삽입합니다.

타임스케일DB

v 4.2에서는 TimescaleDB에 관심을 돌렸습니다. 이는 기본 인터페이스를 갖춘 PostgreSQL용 확장입니다. 확장은 관계형 데이터베이스의 이점을 잃지 않으면서 시계열 데이터와 효과적으로 작동합니다. TimescaleDB도 자동으로 파티션을 나눕니다.

TimescaleDB에는 개념이 있습니다 하이퍼테이블 (하이퍼테이블)을 생성합니다. 그것은 포함 덩어리 - 파티션. 청크는 다른 조각에 영향을 주지 않는 자동으로 관리되는 하이퍼테이블 조각입니다. 각 청크에는 고유한 시간 범위가 있습니다.

TimescaleDB와 PostgreSQL

TimescaleDB는 정말 효율적으로 작동합니다. 확장 프로그램 제조업체는 보다 정확한 쿼리 처리 알고리즘, 특히 inserts 사용한다고 주장합니다. 데이터 세트 삽입 크기가 증가함에 따라 알고리즘은 일정한 성능을 유지합니다.

200억 행 이후 PostgreSQL은 일반적으로 크게 저하되기 시작하고 성능이 0으로 떨어집니다. TimescaleDB를 사용하면 모든 양의 데이터에 대해 "삽입"을 효율적으로 삽입할 수 있습니다.

설치

TimescaleDB 설치는 모든 패키지에서 매우 쉽습니다. 안에 선적 서류 비치 모든 것이 자세히 설명되어 있습니다. 공식 PostgreSQL 패키지에 따라 다릅니다. TimescaleDB는 수동으로 구축하고 컴파일할 수도 있습니다.

Zabbix 데이터베이스의 경우 확장 기능을 활성화하기만 하면 됩니다.

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

당신은 활성화 extension Zabbix 데이터베이스용으로 생성합니다. 마지막 단계는 하이퍼테이블을 만드는 것입니다.

기록 테이블을 TimescaleDB로 마이그레이션

여기에는 특별한 기능이 있습니다 create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

이 함수에는 세 가지 매개변수가 있습니다. 첫 번째 - 데이터베이스의 테이블, 하이퍼테이블을 생성해야 합니다. 두번째 - 들판, 이에 따라 생성해야 할 chunk_time_interval — 사용할 파티션 청크의 간격입니다. 내 경우 간격은 하루 - 86입니다.

세 번째 매개변수 - migrate_data. 설정하면 true, 그러면 현재의 모든 데이터가 미리 생성된 청크로 전송됩니다. 제가 직접 사용했어요 migrate_data. 1TB 정도 있었는데 XNUMX시간 넘게 걸렸습니다. 어떤 경우에는 테스트 중에 저장에 필요하지 않은 문자 유형의 기록 데이터를 삭제하여 전송하지 않도록 했습니다.

마지막 단계 - UPDATE:에서 db_extension 놓다 timescaledb데이터베이스는 이 확장이 존재한다는 것을 이해합니다. Zabbix는 이를 활성화하고 TimescaleDB에 필요한 기능인 데이터베이스에 대한 구문과 쿼리를 올바르게 사용합니다.

하드웨어 구성

저는 두 대의 서버를 사용했습니다. 첫 번째 - VMware 머신. 20개의 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz 프로세서, 16GB RAM 및 200GB SSD로 매우 작습니다.

Debian 10.8-10.8.pgdg1+90 OS 및 xfs 파일 시스템과 함께 PostgreSQL 1을 설치했습니다. Zabbix 자체에서 사용하는 것을 제외하고 이 특정 데이터베이스를 사용하기 위해 모든 것을 최소한으로 구성했습니다.

동일한 시스템에는 Zabbix 서버, PostgreSQL 및 로드 에이전트. 사용 중인 활성 에이전트가 50개 있었습니다. LoadableModule숫자, 문자열 등 다양한 결과를 매우 빠르게 생성합니다. 나는 데이터베이스를 많은 데이터로 채웠다.

처음에 포함된 구성 5개 요소 호스트당 데이터. 거의 모든 요소에는 실제 설치와 유사하게 만드는 트리거가 포함되어 있습니다. 어떤 경우에는 하나 이상의 트리거가 발생했습니다. 하나의 네트워크 노드에는 3~000개의 트리거.

데이터 항목 업데이트 간격 - 4-7 초. 에이전트를 50개만 사용하는 것이 아니라 더 추가하여 부하 자체를 조절했습니다. 또한 데이터 요소를 사용하여 로드를 동적으로 조정하고 업데이트 간격을 4초로 줄였습니다.

PostgreSQL. 35NVPS

이 하드웨어에서의 첫 번째 실행은 순수 PostgreSQL에서 이루어졌습니다. 초당 35개의 값이었습니다. 보시다시피 데이터를 삽입하는 데는 몇 분의 200초밖에 걸리지 않습니다. 모든 것이 훌륭하고 빠릅니다. 유일한 것은 XNUMXGB SSD 디스크가 빨리 채워진다는 것입니다.

이것은 표준 Zabbix 서버 성능 대시보드입니다.

첫 번째 파란색 그래프는 초당 값의 개수입니다. 오른쪽의 두 번째 그래프는 빌드 프로세스의 로딩입니다. 세 번째는 내부 빌드 프로세스를 로드하는 것입니다. 히스토리 동기화 장치와 Housekeeper는 여기에서 꽤 오랫동안 실행되어 왔습니다.

네 번째 그래프는 HistoryCache 사용량을 보여줍니다. 데이터베이스에 삽입하기 전의 일종의 버퍼이다. 녹색 다섯 번째 그래프는 ValueCache 사용량, 즉 트리거에 대한 ValueCache 적중 횟수를 보여줍니다. 이는 초당 수천 개의 값입니다.

PostgreSQL. 50NVPS

그런 다음 동일한 하드웨어에서 로드를 초당 50만 값으로 늘렸습니다.

Housekeeper에서 로드할 때 10개의 값을 삽입하는 데 2~3초가 걸렸습니다.

가정부는 이미 일을 방해하기 시작했습니다.

세 번째 그래프는 일반적으로 트랩퍼 및 기록 동기화 장치의 로드가 여전히 60%임을 보여줍니다. 네 번째 그래프에서는 Housekeeper 작업 중에 HistoryCache가 이미 활발하게 채워지기 시작했습니다. 20% 정도 차서 약 0,5GB 정도 됩니다.

PostgreSQL. 80NVPS

그런 다음 초당 80만 값으로 부하를 늘렸습니다. 이는 약 400만 개의 데이터 요소와 280만 개의 트리거입니다.

히스토리 싱크로니셔 XNUMX개의 로딩 비용은 이미 상당히 높습니다.

또한 기록 동기화 장치, 캐시 등 다양한 매개변수도 늘렸습니다.

내 하드웨어에서는 기록 동기화 장치의 로딩이 최대치로 증가했습니다. HistoryCache는 빠르게 데이터로 채워졌습니다. 처리할 데이터가 버퍼에 축적되었습니다.

이번에는 프로세서, RAM 및 기타 시스템 매개변수가 어떻게 사용되는지 관찰했고 디스크 활용도가 최대치에 도달했다는 사실을 발견했습니다.

나는 사용을 달성했다 최대 디스크 용량 이 하드웨어와 이 가상 머신에서. 이러한 강도로 인해 PostgreSQL은 데이터를 매우 적극적으로 플러시하기 시작했으며 디스크에는 더 이상 쓰고 읽을 시간이 없었습니다.

두 번째 서버

저는 이미 48개의 프로세서와 128GB의 RAM을 갖춘 다른 서버를 가져갔습니다. 조정했습니다. 기록 동기화 장치를 60으로 설정하고 허용 가능한 성능을 얻었습니다.

실제로 이는 이미 무언가를 수행해야 하는 생산성의 한계입니다.

TimescaleDB. 80NVPS

나의 주요 임무는 Zabbix 로드에 대해 TimescaleDB의 기능을 테스트하는 것입니다. 초당 80개의 값은 많고 측정항목 수집 빈도(물론 Yandex 제외)와 상당히 큰 "설정"입니다.

모든 그래프에는 하락이 있습니다. 이것이 바로 데이터 마이그레이션입니다. Zabbix 서버에 장애가 발생한 후 기록 동기화 장치의 로딩 프로필이 많이 변경되어 세 번 떨어졌습니다.

TimescaleDB를 사용하면 데이터를 거의 3배 빠르게 삽입하고 HistoryCache를 덜 사용할 수 있습니다.

따라서 적시에 데이터를 받게 됩니다.

TimescaleDB. 120NVPS

그런 다음 데이터 요소 수를 500만 개로 늘렸습니다. 주요 작업은 TimescaleDB의 기능을 테스트하는 것이었고 초당 125개의 값으로 계산된 값을 받았습니다.

이것은 오랫동안 작동할 수 있는 작동 "설정"입니다. 그런데 내 디스크가 1,5TB에 불과해서 며칠 만에 다 찼어요.

가장 중요한 것은 동시에 새로운 TimescaleDB 파티션이 생성되었다는 것입니다.

이는 성능상 전혀 눈에 띄지 않습니다. 예를 들어 MySQL에서 파티션이 생성되면 모든 것이 달라집니다. 이는 일반 삽입을 차단하고 테이블 작업을 하며 서비스 저하를 일으킬 수 있기 때문에 일반적으로 밤에 발생합니다. TimescaleDB의 경우는 그렇지 않습니다.

예를 들어 커뮤니티의 많은 그래프 중 하나를 보여 드리겠습니다. 그림에서는 TimescaleDB가 활성화되어 프로세서에서 io.weight를 사용할 때의 부하가 감소했습니다. 내부 프로세스 요소의 사용도 감소했습니다. 게다가 이것은 SSD가 아닌 일반 팬케이크 디스크의 일반 가상 머신입니다.

조사 결과

TimescaleDB는 소규모 "설정"에 적합한 솔루션입니다., 이는 디스크 성능에 영향을 미칩니다. 이를 통해 데이터베이스가 가능한 한 빨리 하드웨어로 마이그레이션될 때까지 계속해서 원활하게 작업할 수 있습니다.

TimescaleDB는 구성이 쉽고 성능 향상을 제공하며 Zabbix 및 PostgreSQL에 비해 장점이 있음.

PostgreSQL을 사용하고 있으며 변경할 계획이 없다면 다음을 권장합니다. Zabbix와 함께 TimescaleDB 확장과 함께 PostgreSQL 사용. 이 솔루션은 중간 수준의 "설정"까지 효과적으로 작동합니다.

"고성능"이라고 하면 HighLoad ++. 수백만 명의 사용자에게 서비스를 제공할 수 있는 기술과 관행에 대해 배우기 위해 오래 기다리지 않을 것입니다. 목록 보고서 7월 8일과 XNUMX일에 대해서는 이미 편집했지만 여기서는 모임 더 많은 것을 제안할 수 있습니다.

우리의 구독 뉴스 레터 и 전보에서 다가오는 컨퍼런스의 특징을 공개하고 이를 최대한 활용하는 방법을 알아봅니다.

출처 : habr.com