서비스형 모니터링: 마이크로서비스 아키텍처를 위한 모듈형 시스템

현재 우리 프로젝트에는 모놀리식 코드 외에도 수십 개의 마이크로서비스가 포함되어 있습니다. 각각을 모니터링해야 합니다. DevOps 엔지니어를 사용하여 이러한 규모로 이를 수행하는 것은 문제가 있습니다. 우리는 개발자를 위한 서비스로 작동하는 모니터링 시스템을 개발했습니다. 모니터링 시스템에 측정항목을 독립적으로 작성하고, 이를 사용하고, 이를 기반으로 대시보드를 구축하고, 임계값에 도달하면 트리거되는 경고를 연결할 수 있습니다. DevOps 엔지니어의 경우 인프라와 문서만 제공됩니다.

이 포스팅은 제가 저희와 나눈 대화를 녹취한 것입니다. 섹션들 RIT++에서. 많은 사람들이 거기에서 보고서의 텍스트 버전을 만들어달라고 요청했습니다. 컨퍼런스에 참석하셨거나 영상을 시청하셨다면 새로운 점은 발견하지 못하실 것입니다. 그리고 다른 모든 사람들 - 고양이에 오신 것을 환영합니다. 우리가 어떻게 그러한 시스템을 갖게 되었는지, 어떻게 작동하는지, 그리고 어떻게 업데이트할 계획인지 말씀드리겠습니다.

과거 : 계획과 계획

현재의 모니터링 시스템은 어떻게 탄생하게 되었나요? 이 질문에 답하려면 2015년으로 돌아가야 한다. 당시의 모습은 다음과 같습니다.

모니터링을 담당하는 노드는 약 24개였습니다. 어떻게든 무언가를 모니터링하고, 메시지를 보내고, 기능을 수행하는 다양한 크라운, 스크립트, 데몬의 전체 팩이 있습니다. 우리는 더 나아갈수록 그러한 시스템의 실행 가능성이 낮아질 것이라고 생각했습니다. 개발할 필요가 없습니다. 너무 번거롭기 때문입니다.
우리는 유지하고 개발할 모니터링 요소와 폐기할 모니터링 요소를 선택하기로 결정했습니다. 19개가 있었는데, 흑연과 애그리게이터, 대시보드 역할을 하는 그라파나만 남았습니다. 하지만 새로운 시스템은 어떤 모습일까요? 이와 같이:

우리는 메트릭 저장소를 가지고 있습니다. 이것은 빠른 SSD 드라이브를 기반으로 하는 흑연이며 메트릭에 대한 특정 집계자입니다. 다음 - 대시보드를 표시하는 Grafana와 경고를 위한 Moira입니다. 우리는 또한 이상 징후를 검색하는 시스템을 개발하고 싶었습니다.

표준: 모니터링 2.0

2015년 계획은 이렇습니다. 하지만 인프라와 서비스 자체뿐 아니라 이를 위한 문서도 준비해야 했습니다. 우리는 모니터링 2.0이라고 부르는 기업 표준을 스스로 개발했습니다. 시스템 요구사항은 무엇이었나요?

• 지속적인 가용성;
• 메트릭 저장 간격 = 10초;
• 측정항목 및 대시보드의 구조화된 저장
• SLA > 99,99%
• UDP(!)를 통한 이벤트 측정항목 수집.

메트릭을 생성하는 트래픽과 이벤트의 흐름이 많기 때문에 UDP가 필요했습니다. 한번에 다 흑연에 쓰면 저장공간이 무너지거든요. 또한 모든 지표에 대해 첫 번째 수준 접두사를 선택했습니다.

각 접두사에는 몇 가지 속성이 있습니다. 서버, 네트워크, 컨테이너, 리소스, 애플리케이션 등에 대한 측정항목이 있습니다. 명확하고 엄격한 유형의 필터링이 구현되어 첫 번째 수준 측정항목을 허용하고 나머지는 삭제합니다. 이것이 우리가 2015년에 이 시스템을 계획한 방법입니다. 현재에는 무엇이 있나요?

현재: 모니터링 구성 요소의 상호 작용 다이어그램

우선, 우리는 애플리케이션, 즉 PHP 코드, 애플리케이션 및 마이크로서비스, 즉 개발자가 작성하는 모든 것을 모니터링합니다. 모든 애플리케이션은 UDP를 통해 Brubeck 집계자(statsd, C로 재작성됨)에 메트릭을 보냅니다. 합성 테스트에서 가장 빠른 것으로 나타났습니다. 그리고 이미 집계된 측정항목을 TCP를 통해 Graphite로 보냅니다.

타이머라는 측정항목 유형이 있습니다. 이것은 매우 편리한 일입니다. 예를 들어, 서비스에 대한 각 사용자 연결에 대해 응답 시간이 포함된 지표를 Brubeck에 보냅니다. 백만 개의 응답이 들어왔지만 집계자는 10개의 측정항목만 반환했습니다. 온 사람 수, 최대, 최소 및 평균 응답 시간, 중앙값 및 4 백분위수가 있습니다. 그런 다음 데이터가 Graphite로 전송되고 우리는 모든 것을 실시간으로 볼 수 있습니다.

또한 하드웨어, 소프트웨어, 시스템 측정항목 및 기존 Munin 모니터링 시스템에 대한 측정항목 집계 기능도 있습니다(2015년까지 작동했습니다). 우리는 C 데몬 CollectD를 통해 이 모든 것을 수집합니다(이것은 다양한 플러그인이 내장되어 있으며 설치된 호스트 시스템의 모든 리소스를 폴링할 수 있으며 구성에서 데이터를 쓸 위치를 지정하기만 하면 됩니다). 그것을 통해 Graphite에 데이터를 씁니다. 또한 Python 플러그인과 쉘 스크립트를 지원하므로 사용자 정의 솔루션을 작성할 수 있습니다. CollectD는 로컬 또는 원격 호스트(Curl 가정)에서 이 데이터를 수집하여 Graphite로 보냅니다.

그런 다음 수집한 모든 측정 항목을 Carbon-c-relay로 보냅니다. 이것은 C로 수정된 Graphite의 Carbon Relay 솔루션입니다. 이는 집계자로부터 보내는 모든 측정항목을 수집하여 노드로 라우팅하는 라우터입니다. 또한 라우팅 단계에서는 메트릭의 유효성을 확인합니다. 첫째, 앞서 보여드린 접두사 체계와 일치해야 하며, 둘째, 흑연에 유효해야 합니다. 그렇지 않으면 떨어질 것입니다.

그런 다음 Carbon-c-relay는 측정항목을 Graphite 클러스터로 보냅니다. 우리는 Go로 다시 작성된 Carbon-cache를 메트릭의 주요 저장소로 사용합니다. Go-carbon은 멀티스레딩으로 인해 Carbon-cache보다 성능이 훨씬 뛰어납니다. 속삭임 패키지(표준, Python으로 작성)를 사용하여 데이터를 수신하고 디스크에 씁니다. 저장소에서 데이터를 읽기 위해 Graphite API를 사용합니다. 표준 Graphite WEB보다 훨씬 빠릅니다. 다음 데이터는 어떻게 되나요?

그들은 그라파나로 갑니다. 우리는 흑연 클러스터를 데이터의 주요 소스로 사용하고 있으며 Grafana를 지표 표시 및 대시보드 구축을 위한 웹 인터페이스로 사용하고 있습니다. 각 서비스에 대해 개발자는 자신만의 대시보드를 만듭니다. 그런 다음 이를 기반으로 그래프를 작성하고 애플리케이션에서 작성한 측정항목을 표시합니다. Grafana 외에도 SLAM도 있습니다. 이것은 흑연의 데이터를 기반으로 SLA를 계산하는 Python 악마입니다. 이미 말했듯이 우리에게는 수십 개의 마이크로서비스가 있으며 각 마이크로서비스에는 고유한 요구 사항이 있습니다. SLAM을 사용하여 문서로 이동하여 Graphite의 내용과 비교하고 요구 사항이 서비스 가용성과 얼마나 잘 일치하는지 비교합니다.

더 나아가 보겠습니다. 경고. 강력한 시스템인 Moira를 사용하여 구성됩니다. 후드 아래에 자체 그래파이트가 있기 때문에 독립적입니다. Python과 Go로 작성된 SKB "Kontur" 직원이 개발한 완전 오픈 소스입니다. Moira는 흑연으로 들어가는 것과 동일한 흐름을 받습니다. 어떤 이유로 스토리지가 중단되더라도 알림은 계속 작동합니다.

우리는 Kubernetes에 Moira를 배포했는데, Redis 서버 클러스터를 기본 데이터베이스로 사용합니다. 그 결과는 내결함성 시스템이었습니다. 메트릭 스트림을 트리거 목록과 비교합니다. 언급된 내용이 없으면 메트릭을 삭제합니다. 따라서 분당 기가바이트의 측정항목을 소화할 수 있습니다.

또한 기업 시스템의 각 사용자가 기존(또는 새로 생성된) 트리거를 기반으로 스스로 알림을 생성할 수 있도록 기업 LDAP를 연결했습니다. Moira에는 Graphite가 포함되어 있으므로 모든 기능을 지원합니다. 따라서 먼저 해당 줄을 가져와 Grafana에 복사합니다. 데이터가 그래프에 어떻게 표시되는지 확인하세요. 그런 다음 동일한 줄을 선택하여 Moira에 복사합니다. 한계를 두고 매달고 출력 시 경고를 받습니다. 이 모든 작업을 수행하려면 특정 지식이 필요하지 않습니다. Moira는 SMS, 이메일, Jira, Slack 등을 통해 경고할 수 있습니다. 또한 사용자 정의 스크립트 실행도 지원합니다. 그녀에게 트리거가 발생하고 사용자 정의 스크립트 또는 바이너리를 구독하면 이를 실행하고 이 바이너리에 대한 JSON을 stdin으로 보냅니다. 따라서 프로그램에서는 이를 구문 분석해야 합니다. 이 JSON으로 수행할 작업은 귀하에게 달려 있습니다. 원한다면 Telegram으로 보내고, 원한다면 Jira에서 작업을 열고 무엇이든 하세요.

우리는 또한 경고를 위해 자체 개발한 Imagotag를 사용합니다. 우리는 일반적으로 매장의 전자 가격표에 사용되는 패널을 우리의 필요에 맞게 조정했습니다. Moira에서 트리거를 가져왔습니다. 이는 현재 상태와 발생 시기를 나타냅니다. 일부 개발 담당자는 이 패널을 선호하여 Slack 및 이메일 알림을 포기했습니다.

글쎄, 우리는 진보적인 회사이기 때문에 이 시스템에서 Kubernetes도 모니터링했습니다. 클러스터에 설치한 Heapster를 사용하여 시스템에 포함시켰고, 데이터를 수집하여 Graphite로 보냅니다. 결과적으로 다이어그램은 다음과 같습니다.

모니터링 구성 요소

다음은 이 작업에 사용한 구성 요소에 대한 링크 목록입니다. 그들 모두는 오픈 소스입니다.

석묵:

• 고카본: github.com/lomik/go-carbon
• 속삭임: github.com/graphite-project/whisper
• 흑연 API: github.com/brutasse/graphite-api

카본-C-릴레이:

github.com/grobian/carbon-c-relay

브루벡:

github.com/github/brubeck

수집된 항목:

Collectd.org

모이라 :

github.com/moira-alert

그라파나:

grafana.com

힙스터:

github.com/kubernetes/heapster

통계

다음은 시스템이 우리에게 어떻게 작동하는지에 대한 몇 가지 수치입니다.

애그리게이터(브뤼벡)

지표 수: ~300/초
지표를 Graphite로 보내는 간격: 30초
서버 리소스 사용량: ~ 6% CPU(완전한 서버에 대해 이야기하고 있음) ~ 1GB RAM; ~3Mbps LAN

흑연(고카본)

지표 수: ~ 1/분
지표 업데이트 간격: 30초
측정항목 저장 방식: 30초 35일, 5분 90일, 10분 365일(장기간 동안 서비스에 어떤 일이 발생하는지 이해할 수 있음)
서버 리소스 사용량: ~10% CPU; ~ 20Gb RAM; ~30Mbps LAN

유연성

Avito는 모니터링 서비스의 유연성을 매우 중요하게 생각합니다. 그는 실제로 왜 이렇게 되었는가? 첫째, 해당 구성 요소는 구성 요소 자체와 해당 버전 모두 상호 교환이 가능합니다. 둘째, 지원 가능성입니다. 전체 프로젝트가 오픈 소스이므로 코드를 직접 편집하고, 변경하고, 기본적으로 사용할 수 없는 기능을 구현할 수 있습니다. 주로 Go 및 Python과 같은 매우 일반적인 스택이 사용되므로 매우 간단하게 수행됩니다.

다음은 실제 문제의 예입니다. Graphite의 메트릭은 파일입니다. 이름이 있습니다. 파일 이름 = 측정항목 이름. 그리고 거기로 가는 방법이 있습니다. Linux의 파일 이름은 255자로 제한됩니다. 그리고 (“내부 고객”으로서) 데이터베이스 부서 직원이 있습니다. 그들은 우리에게 이렇게 말합니다. “우리는 SQL 쿼리를 모니터링하고 싶습니다. 그리고 255자가 아니라 각각 8MB입니다. 우리는 이를 Grafana에 표시하고, 이 요청에 대한 매개변수를 확인하고, 더 나아가 그러한 요청의 상단을 보고 싶습니다. 실시간으로 보여주면 정말 좋을 것 같아요. 그들에게 경고를 보내는 것은 정말 멋질 것입니다.”

예제 SQL 쿼리는 사이트 postgrespro.ru

우리는 Redis 서버를 설정하고 Postgres로 이동하여 거기에서 모든 데이터를 가져와 Graphite로 메트릭을 보내는 Collectd 플러그인을 사용합니다. 하지만 측정항목 이름을 해시로 바꿉니다. 동일한 해시를 Redis에 키로 보내고 전체 SQL 쿼리를 값으로 동시에 보냅니다. 우리가 해야 할 일은 Grafana가 Redis로 이동하여 이 정보를 가져올 수 있는지 확인하는 것입니다. Graphite API를 공개하는 이유는... 이는 모든 모니터링 구성 요소와 흑연의 상호 작용을 위한 기본 인터페이스이며 여기에 aliasByHash()라는 새 함수를 입력합니다. Grafana에서 메트릭 이름을 가져와 Redis에 대한 요청에서 키로 사용합니다. 응답을 통해 우리는 "SQL 쿼리"인 키 값을 얻습니다. 따라서 우리는 이론적으로 표시할 수 없는 SQL 쿼리를 Grafana에 통계(호출, 행, total_time 등)와 함께 표시했습니다.

결과

가용성 당사의 모니터링 서비스는 모든 애플리케이션과 코드에서 연중무휴 24시간 이용 가능합니다. 스토리지 시설에 대한 액세스 권한이 있는 경우 서비스에 데이터를 쓸 수 있습니다. 언어는 중요하지 않으며 결정도 중요하지 않습니다. 소켓을 여는 방법, 거기에 메트릭을 넣고 소켓을 닫는 방법만 알면 됩니다.

신뢰성. 모든 구성 요소는 내결함성이 있으며 부하를 잘 처리합니다.

진입 문턱이 낮습니다. 이 시스템을 사용하기 위해 Grafana에서 프로그래밍 언어와 쿼리를 배울 필요는 없습니다. 애플리케이션을 열고 Graphite에 메트릭을 보내는 소켓을 입력하고 닫은 다음 Grafana를 열고 거기서 대시보드를 생성한 다음 메트릭의 동작을 살펴보고 Moira를 통해 알림을 받습니다.

독립. DevOps 엔지니어의 도움 없이 이 모든 작업을 직접 수행할 수 있습니다. 이는 바로 지금 프로젝트를 모니터링할 수 있기 때문에 누구에게도 작업을 시작하거나 변경하라고 요청할 필요가 없다는 장점이 있습니다.

우리는 무엇을 위해 노력하고 있습니까?

아래에 나열된 모든 것은 단지 추상적인 생각이 아니라 적어도 첫 번째 단계가 취해진 것입니다.

1. 이상 탐지기. 우리는 Graphite 스토리지로 이동하여 다양한 알고리즘을 사용하여 각 지표를 확인하는 서비스를 만들고 싶습니다. 우리가 보고 싶은 알고리즘과 데이터가 이미 있고, 우리는 이를 사용하는 방법을 알고 있습니다.
2. 메타데이터. 우리는 많은 서비스를 가지고 있으며, 그 서비스를 이용하는 사람들과 마찬가지로 시간이 지남에 따라 변경됩니다. 지속적으로 문서를 수동으로 유지하는 것은 선택 사항이 아닙니다. 이것이 바로 우리가 현재 마이크로서비스에 메타데이터를 내장하는 이유입니다. 이를 개발한 사람, 상호 작용하는 언어, SLA 요구 사항, 알림을 보내야 하는 위치 및 대상이 명시되어 있습니다. 서비스를 배포할 때 모든 엔터티 데이터는 독립적으로 생성됩니다. 결과적으로 두 개의 링크가 생성됩니다. 하나는 트리거에 대한 링크이고 다른 하나는 Grafana의 대시보드에 대한 링크입니다.
3. 모든 가정에서 모니터링합니다. 우리는 모든 개발자가 이러한 시스템을 사용해야 한다고 믿습니다. 이 경우 트래픽이 어디에 있는지, 무슨 일이 일어나고 있는지, 트래픽이 어디에 있는지, 약점이 어디에 있는지 항상 이해합니다. 예를 들어, 어떤 일이 발생하여 서비스가 중단되는 경우 관리자의 통화가 아닌 알림을 통해 이에 대해 알게 되며 즉시 최신 로그를 열어 무슨 일이 일어났는지 확인할 수 있습니다.
4. 고성능. 우리 프로젝트는 지속적으로 성장하고 있으며 현재 분당 약 2개의 측정값을 처리하고 있습니다. 000년 전 이 수치는 000이었고 성장이 계속되고 있으며 이는 일정 시간이 지나면 Graphite(속삭임)가 디스크 하위 시스템에 과도한 부하를 주기 시작할 것임을 의미합니다. 이미 말했듯이 이 모니터링 시스템은 구성 요소의 상호 교환 가능성으로 인해 매우 보편적입니다. 누군가 Graphite를 위한 인프라를 유지 관리하고 지속적으로 확장하고 있지만 우리는 다른 경로를 사용하기로 결정했습니다. 클릭 하우스 측정항목의 저장소로 사용됩니다. 이 전환은 거의 완료되었으며 곧 이 작업이 어떻게 수행되었는지 자세히 설명하겠습니다. 어떤 어려움이 있었고 어떻게 극복했는지, 마이그레이션 프로세스가 어떻게 진행되었는지, 바인딩으로 선택한 구성 요소와 해당 구성에 대해 설명하겠습니다.

관심을 가져주셔서 감사합니다! 주제에 대해 질문을 하시면 여기나 다음 게시물에서 답변해 드리겠습니다. 아마도 누군가 비슷한 모니터링 시스템을 구축한 경험이 있거나 비슷한 상황에서 Clickhouse로 전환한 경험이 있을 것입니다. 댓글로 공유해 주세요.

출처 : habr.com