안녕하세요 여러분! 그의 마지막 기사 마이크로서비스 아키텍처를 위한 모듈형 모니터링 시스템 구성에 대해 글을 썼습니다. 아무것도 정지되지 않습니다. 우리 프로젝트는 지속적으로 성장하고 있으며 저장된 측정 항목의 수도 마찬가지입니다. 고부하 조건에서 Graphite+Whisper에서 Graphite+ClickHouse로의 전환을 어떻게 구성했는지, 이에 대한 기대 사항과 컷 아래의 마이그레이션 결과를 읽어보세요.

Graphite+Whisper의 메트릭 저장에서 Graphite+ClickHouse로의 전환을 어떻게 구성했는지 설명하기 전에, 그러한 결정을 내린 이유와 오랫동안 우리가 함께 살아온 Whisper의 단점에 대한 정보를 제공하고 싶습니다.

흑연+속삭임 문제

1. 디스크 하위 시스템의 부하가 높습니다.

전환 당시에는 분당 약 1.5만 개의 지표가 우리에게 도착했습니다. 이러한 흐름으로 인해 서버의 디스크 활용도는 ~30%였습니다. 일반적으로 이것은 상당히 수용 가능한 수준이었습니다. 모든 것이 안정적으로 작동하고, 빠르게 작성되고, 빠르게 읽혔습니다. 개발 팀 중 하나가 새로운 기능을 출시하고 분당 천만 개의 측정 항목을 보내기 시작할 때까지는 말이죠. 이때 디스크 하위 시스템이 강화되어 10% 활용도를 확인했습니다. 문제는 빨리 해결됐지만, 잔여물이 남았습니다.

2. 복제 및 일관성 부족

아마도 Graphite+Whisper를 사용/사용하는 모든 사람들과 마찬가지로 우리는 내결함성을 만들기 위해 동일한 메트릭 스트림을 여러 Graphite 서버에 동시에 쏟아 부었습니다. 그리고 어떤 이유로 서버 중 하나가 충돌하는 순간까지 특별한 문제는 없었습니다. 때때로 우리는 손상된 서버를 신속하게 복구할 수 있었고 carbon-c-relay는 캐시에서 메트릭을 해당 서버로 로드했지만 때로는 그렇지 않은 경우도 있었습니다. 그리고 측정항목에 구멍이 있었는데 우리는 이를 rsync로 채웠습니다. 절차가 꽤 길었습니다. 유일한 구원의 은혜는 이런 일이 아주 드물게 일어났다는 것입니다. 또한 주기적으로 임의의 메트릭 세트를 가져와 클러스터의 이웃 노드에 있는 동일한 유형의 다른 메트릭과 비교했습니다. 약 5%의 경우에는 여러 값이 달라서 그다지 만족스럽지 않았습니다.

3. 큰 설치 공간

우리는 인프라뿐만 아니라 비즈니스 메트릭(그리고 이제 Kubernetes의 메트릭)도 Graphite로 작성하기 때문에 메트릭에 몇 가지 값만 포함되고 모든 보존을 고려하여 .wsp 파일이 생성되는 상황이 자주 발생합니다. 기간이며 사전 할당된 공간을 차지하며 이는 ~2MB에 해당합니다. 시간이 지남에 따라 유사한 파일이 많이 나타나고 이에 대한 보고서를 작성할 때 빈 지점을 읽는 데 많은 시간과 리소스가 소요된다는 사실로 인해 문제는 더욱 악화됩니다.

위에서 설명한 문제는 다양한 방법과 다양한 효율성으로 처리될 수 있지만 더 많은 데이터를 받기 시작할수록 문제가 더 악화된다는 점을 즉시 지적하고 싶습니다.

위의 사항을 모두 갖춘 경우(이전 항목을 고려하여) 조항) 수신된 지표 수가 지속적으로 증가할 뿐만 아니라 모든 지표를 30초의 저장 간격으로 전송하려는 요구도 있습니다. (필요한 경우 최대 10초) Whisper의 유망한 대안으로 Graphite+ClickHouse를 사용해 보기로 결정했습니다.

그래파이트+클릭하우스. 기대

Yandex에서 온 사람들의 여러 모임을 방문하고, Habré에 관한 몇 가지 기사, 문서를 검토하고 Graphite에서 ClickHouse를 바인딩하기 위한 정상적인 구성 요소를 찾은 후 조치를 취하기로 결정했습니다!

나는 다음을 받고 싶습니다:

• 디스크 하위 시스템 활용도를 30%에서 5%로 줄입니다.
• 차지하는 공간을 1TB에서 100GB로 줄입니다.
• 분당 100억 개의 지표를 서버로 수신할 수 있습니다.
• 즉시 사용 가능한 데이터 복제 및 내결함성;
• 이 프로젝트를 XNUMX년 동안 진행하지 말고 합리적인 기간 내에 전환하십시오.
• 다운타임 없이 전환하세요.

꽤 야심찬 일이죠?

그래파이트+클릭하우스. 구성요소

Graphite 프로토콜을 통해 데이터를 수신하고 이후 ClickHouse에 기록하기 위해 저는 다음을 선택했습니다. 탄소클릭하우스 (골랑).

ClickHouse의 최신 릴리스인 안정 버전 1.1.54253이 시계열 저장을 위한 데이터베이스로 선택되었습니다. 작업할 때 문제가 있었습니다. 로그에 산더미 같은 오류가 쏟아졌고 이를 어떻게 해야 할지 완전히 명확하지 않았습니다. 와 논의 중 로만 로모노소프 (carbon-clickhouse, graphite-clickhouse 등의 저자) 오래된 것이 선택되었습니다. 릴리스 1.1.54236. 오류가 사라졌습니다. 모든 것이 쾅하고 작동하기 시작했습니다.

ClickHouse에서 데이터를 읽도록 선택됨 흑연-lickhouse (골랑). Graphite용 API - 카르보나피 (골랑). ClickHouse는 테이블 간 복제를 구성하는 데 사용되었습니다. 사육사. 라우팅 메트릭을 위해 우리는 사랑하는 사람을 떠났습니다. 카본-C-릴레이 (C) (이전 기사 참조).

그래파이트+클릭하우스. 테이블 구조

"graphite"는 모니터링 테이블을 위해 만든 데이터베이스입니다.

"graphite.metrics" - ReplicatedReplacingMergeTree 엔진이 있는 테이블(복제됨 병합트리 교체하기). 이 테이블에는 측정항목 이름과 측정항목 경로가 저장됩니다.

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

"graphite.data" - ReplicatedGraphiteMergeTree 엔진이 있는 테이블(복제됨 흑연병합트리). 이 테이블은 측정항목 값을 저장합니다.

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

"graphite.date_metrics"는 ReplicatedReplacingMergeTree 엔진을 사용하여 조건부로 채워진 테이블입니다. 이 테이블에는 하루 동안 발생한 모든 측정항목의 이름이 기록됩니다. 생성 이유는 섹션에 설명되어 있습니다. "문제" 이 기사의 끝에서.

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

"graphite.data_stat" - ReplicatedAggregatingMergeTree 엔진을 사용하여 조건에 따라 채워진 테이블(복제됨) 집계병합 트리). 이 테이블은 수신 측정항목 수를 4개의 중첩 수준으로 분류하여 기록합니다.

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

그래파이트+클릭하우스. 구성 요소 상호 작용 다이어그램

그래파이트+클릭하우스. 데이터 마이그레이션

이 프로젝트의 기대에서 기억나는 대로 ClickHouse로의 전환은 다운타임이 없어야 하기 때문에 우리는 사용자를 위해 가능한 한 투명하게 전체 모니터링 시스템을 새로운 스토리지로 전환해야 했습니다.
이것이 우리가 한 방법입니다.

• ClickHouse 테이블 복제에 참여하는 서버 중 하나의 carbon-clickhouse에 추가 메트릭 스트림을 보내는 규칙이 carbon-c-relay에 추가되었습니다.

• 우리는 속삭임 덤프 라이브러리를 사용하여 저장소에서 모든 .wsp 파일을 읽고 이 데이터를 위에서 설명한 탄소 클릭하우스에 24개 스레드로 보내는 작은 스크립트를 Python으로 작성했습니다. 카본클릭하우스에서 허용되는 측정값의 개수는 분당 125억 XNUMX만 개에 달했고, 클릭하우스는 땀 한 방울도 흘리지 않았습니다.

• 기존 대시보드에서 사용되는 기능을 디버그하기 위해 Grafana에 별도의 DataSource를 만들었습니다. 우리가 사용한 함수 목록을 확인했지만 carbonapi에서는 구현되지 않았습니다. 우리는 이러한 기능을 추가하고 carbonapi 작성자에게 PR을 보냈습니다(특별히 감사드립니다).

• 밸런서 설정에서 읽기 로드를 전환하기 위해 엔드포인트를 graphite-api(Graphite+Whisper용 API 인터페이스)에서 carbonapi로 변경했습니다.

그래파이트+클릭하우스. 결과

• 디스크 하위 시스템 활용도가 30%에서 1%로 감소되었습니다.

  

• 차지하는 공간을 1TB에서 300GB로 줄였습니다.
• 분당 125억 XNUMX만 개의 지표를 서버로 수신할 수 있는 능력이 있습니다(마이그레이션 당시 최고치).
• 모든 측정항목을 XNUMX초 저장 간격으로 전송했습니다.
• 수신된 데이터 복제 및 내결함성;
• 다운타임 없이 전환됨;
• 모든 것을 완료하는 데 약 7주가 걸렸습니다.

그래파이트+클릭하우스. 문제

우리의 경우 몇 가지 함정이 있었습니다. 이것이 전환 후에 우리가 직면한 것입니다.

1. ClickHouse는 항상 구성을 즉시 다시 읽는 것은 아니며 때로는 재부팅해야 합니다. 예를 들어 ClickHouse 구성의 사육사 클러스터에 대한 설명의 경우 clickhouse-server가 재부팅될 때까지 사용되지 않았습니다.
2. 대규모 ClickHouse 요청이 처리되지 않았으므로 graphite-clickhouse에서 ClickHouse 연결 문자열은 다음과 같습니다.

   url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"

3. ClickHouse는 안정적인 릴리스의 새 버전을 자주 출시하므로 예상치 못한 내용이 포함될 수 있으므로 주의하세요.
4. Kubernetes에서 동적으로 생성된 컨테이너는 수명이 짧고 무작위로 많은 수의 메트릭을 보냅니다. 이러한 측정 항목에는 포인트가 많지 않으며 공간에도 문제가 없습니다. 그러나 쿼리를 작성할 때 ClickHouse는 '메트릭' 테이블에서 이와 동일한 수많은 메트릭을 선택합니다. 90%의 경우에는 창(24시간) 이후에는 데이터가 없습니다. 하지만 '데이터' 테이블에서 이 데이터를 검색하는 데 시간이 걸리고 결국 시간 초과에 직면하게 됩니다. 이 문제를 해결하기 위해 우리는 하루 동안 접한 지표에 대한 정보를 별도의 보기로 유지하기 시작했습니다. 따라서 동적으로 생성된 컨테이너에 대한 보고서(그래프)를 작성할 때 전체 시간이 아닌 특정 창 내에서 발견된 측정항목만 쿼리하므로 이에 대한 보고서 구성 속도가 크게 향상되었습니다. 위에서 설명한 솔루션에 대해 수집한 내용은 다음과 같습니다. 그래파이트 클릭하우스(포크), 여기에는 date_metrics 테이블 작업 구현이 포함됩니다.

그래파이트+클릭하우스. 태그

버전 1.1.0에서 Graphite가 공식화되었습니다. 지원 태그. 그리고 우리는 그래파이트+클릭하우스 스택에서 이 이니셔티브를 지원하기 위해 무엇을 어떻게 해야 할지 적극적으로 고민하고 있습니다.

그래파이트+클릭하우스. 이상 탐지기

위에서 설명한 인프라를 기반으로 이상 탐지기의 프로토타입을 구현했으며 작동했습니다! 하지만 그에 대한 자세한 내용은 다음 기사에서 다루겠습니다.

구독하고 위쪽 화살표를 누르고 행복하세요!

출처 : habr.com