Prometheus, Clickhouse 및 ELK에 모니터링을 구축한 방법

내 이름은 안톤 베이더린입니다. 저는 첨단기술센터에서 시스템 관리 업무를 담당하고 있습니다. 한 달 전, 우리 도시의 IT 커뮤니티와 축적된 경험을 공유하는 기업 컨퍼런스가 끝났습니다. 웹 애플리케이션 모니터링에 대해 이야기했습니다. 이 자료는 이 프로세스를 처음부터 구축하지 않은 중급 또는 중급 수준을 대상으로 작성되었습니다.

모든 모니터링 시스템의 기본은 비즈니스 문제를 해결하는 것입니다. 모니터링을 위한 모니터링은 누구에게도 관심이 없습니다. 기업은 무엇을 원하는가? 모든 것이 오류 없이 신속하게 작동하도록 합니다. 기업은 서비스의 문제를 스스로 식별하고 가능한 한 빨리 해결할 수 있도록 적극적으로 노력하기를 원합니다. 사실 이것은 제가 작년에 우리 고객 중 한 명을 위한 프로젝트에서 해결한 문제입니다.

프로젝트에 대한

이 프로젝트는 미국 최대 규모의 로열티 프로그램 중 하나입니다. 우리는 보너스 카드와 같은 다양한 마케팅 도구를 통해 소매 체인이 판매 빈도를 높일 수 있도록 돕습니다. 전체적으로 이 프로젝트에는 14개의 서버에서 실행되는 XNUMX개의 애플리케이션이 포함됩니다.

인터뷰 과정에서 저는 관리자가 항상 웹 애플리케이션 모니터링에 올바르게 접근하지 않는다는 사실을 반복해서 발견했습니다. 많은 관리자가 여전히 운영 체제 측정 항목에 초점을 맞추고 가끔 서비스를 모니터링합니다.

제 경우에는 이전에 고객의 모니터링 시스템이 Icinga를 기반으로 했습니다. 위의 문제는 어떤 식으로든 해결되지 않았습니다. 고객이 직접 문제에 대해 알려주는 경우가 많았으며, 원인을 파악하기에 충분한 데이터가 없는 경우가 많았습니다.

또한 추가 개발의 무익함에 대한 명확한 이해가있었습니다. 이싱가에 대해 잘 아시는 분들은 저를 이해하실 거라 생각합니다. 그래서 우리는 프로젝트의 웹 애플리케이션 모니터링 시스템을 완전히 재설계하기로 결정했습니다.

프로 메테우스

우리는 세 가지 주요 지표를 바탕으로 Prometheus를 선택했습니다.

1. 사용 가능한 측정항목이 엄청나게 많습니다. 우리의 경우에는 60만 개가 있습니다. 물론 우리는 그 중 대다수(약 95% 정도)를 사용하지 않는다는 점에 주목할 필요가 있습니다. 반면에, 그것들은 모두 상대적으로 저렴합니다. 우리에게 이것은 이전에 사용된 Icinga와 비교할 때 다른 극단입니다. 그 안에서 측정항목을 추가하는 것은 특별한 고통이었습니다. 기존 측정항목은 비용이 많이 들었습니다(플러그인의 소스 코드를 살펴보세요). 모든 플러그인은 Bash 또는 Python의 스크립트였으며 실행 시 리소스 소비 측면에서 비용이 많이 듭니다.
2. 이 시스템은 상대적으로 적은 양의 리소스를 소비합니다. 600MB RAM, 15개 코어의 XNUMX%, 수십 개의 IOPS이면 모든 측정 항목에 충분합니다. 물론 메트릭 내보내기를 실행해야 하지만 모두 Go로 작성되었으며 전력 소모도 크지 않습니다. 나는 현대 현실에서 이것이 문제라고 생각하지 않습니다.
3. Kubernetes로 마이그레이션하는 기능을 제공합니다. 고객의 계획을 고려하면 선택은 분명합니다.

고라니

이전에는 로그를 수집하거나 처리하지 않았습니다. 단점은 누구에게나 분명합니다. 우리는 이미 이 시스템에 대한 경험이 있었기 때문에 ELK를 선택했습니다. 여기에는 애플리케이션 로그만 저장됩니다. 주요 선택 기준은 전체 텍스트 검색과 속도였습니다.

클릭하우스

처음에는 InfluxDB를 선택했습니다. 우리는 Nginx 로그, pg_stat_statements의 통계를 수집하고 Prometheus 기록 데이터를 저장해야 할 필요성을 깨달았습니다. 우리는 Influx가 주기적으로 많은 양의 메모리를 소비하기 시작하고 충돌하기 때문에 마음에 들지 않았습니다. 게다가, Remote_addr별로 쿼리를 그룹화하고 싶었는데, 이 DBMS에서는 태그별로 그룹화만 되네요. 태그는 비용이 많이 들고(메모리) 개수가 조건부로 제한됩니다.

우리는 다시 검색을 시작했습니다. 필요한 것은 리소스 소비를 최소화하고 가급적이면 디스크에 데이터를 압축하는 분석 데이터베이스였습니다.

Clickhouse는 이러한 모든 기준을 충족하며, 우리는 우리의 선택을 결코 후회한 적이 없습니다. 우리는 여기에 엄청난 양의 데이터를 쓰지 않습니다(삽입 횟수는 분당 약 XNUMX회에 불과합니다).

NewRelic

NewRelic은 고객의 선택이었기 때문에 역사적으로 우리와 함께해 왔습니다. 우리는 그것을 APM으로 사용합니다.

자 비츠

우리는 다양한 API의 블랙박스를 모니터링하기 위해 Zabbix를 독점적으로 사용합니다.

모니터링 접근 방식 정의

우리는 작업을 분해하여 모니터링 접근 방식을 체계화하고 싶었습니다.

이를 위해 저는 시스템을 다음과 같은 수준으로 나누었습니다.

• 하드웨어 및 VMS;
• 운영 체제
• 시스템 서비스, 소프트웨어 스택;
• 애플리케이션;
• 비즈니스 논리.

이 접근 방식이 편리한 이유:

• 우리는 각 수준의 작업을 담당하는 사람이 누구인지 알고 있으며 이를 기반으로 경고를 보낼 수 있습니다.
• 경고를 억제할 때 구조를 사용할 수 있습니다. 가상 머신 전체를 사용할 수 없을 때 데이터베이스 가용성에 대한 경고를 보내는 것은 이상할 것입니다.

우리의 임무는 시스템 운영의 위반 사항을 식별하는 것이므로 각 수준에서 경고 규칙을 작성할 때 주의할 가치가 있는 특정 측정항목 집합을 강조해야 합니다. 다음으로 "VMS", "운영 체제" 및 "시스템 서비스, 소프트웨어 스택" 수준을 살펴보겠습니다.

가상 머신

호스팅은 우리에게 프로세서, 디스크, 메모리 및 네트워크를 할당합니다. 그리고 우리는 처음 두 개에 문제가 있었습니다. 측정항목은 다음과 같습니다.

CPU 도난 시간 - Amazon에서 가상 머신(예: t2.micro)을 구매할 때 전체 프로세서 코어가 할당되지 않고 시간 할당량만 할당된다는 점을 이해해야 합니다. 그리고 그것을 소진하면 프로세서가 당신에게서 멀어 질 것입니다.

이 지표를 사용하면 그러한 순간을 추적하고 결정을 내릴 수 있습니다. 예를 들어, 더 높은 요금을 부과하거나 백그라운드 작업 및 API 요청 처리를 다른 서버에 분산해야 합니까?

IOPS + CPU iowait 시간 - 어떤 이유로 많은 클라우드 호스팅이 충분한 IOPS를 제공하지 않음으로써 죄를 짓습니다. 게다가 IOPS가 낮은 일정은 그들에게 논쟁거리가 되지 않습니다. 따라서 CPU iowait를 수집할 가치가 있습니다. IOPS가 낮고 I/O 대기가 높은 이 그래프 쌍을 사용하면 이미 호스팅과 대화하고 문제를 해결할 수 있습니다.

운영 체제

운영 체제 측정항목:

• 사용 가능한 메모리 양(%);
• 스왑 사용 활동: vmstat swapin, swapout;
• 사용 가능한 inode 수 및 파일 시스템의 여유 공간(%)
• 평균 부하;
• tw 상태의 연결 수;
• conntrack 테이블 충만도;
• 네트워크 품질은 ss 유틸리티인 iproute2 패키지를 사용하여 모니터링할 수 있습니다. 출력에서 ​​RTT 연결 표시기를 가져와 대상 포트별로 그룹화합니다.

또한 운영 체제 수준에는 프로세스와 같은 엔터티가 있습니다. 시스템 운영에 중요한 역할을 하는 일련의 프로세스를 시스템에서 식별하는 것이 중요합니다. 예를 들어, 여러 pgpool이 있는 경우 각각에 대한 정보를 수집해야 합니다.

측정항목 집합은 다음과 같습니다.

• CPU;
• 기억은 주로 상주합니다.
• IO - 바람직하게는 IOPS입니다.
• FileFd - 열기 및 제한;
• 심각한 페이지 오류 - 이를 통해 어떤 프로세스가 교체되고 있는지 이해할 수 있습니다.

우리는 Docker에 모든 모니터링을 배포하고 Advisor를 사용하여 메트릭 데이터를 수집합니다. 다른 컴퓨터에서는 프로세스 내보내기를 사용합니다.

시스템 서비스, 소프트웨어 스택

각 애플리케이션에는 고유한 특성이 있으므로 특정 측정항목 집합을 골라내는 것은 어렵습니다.

범용 세트는 다음과 같습니다.

• 요청률;
• 실수의 수;
• 지연 시간;
• 포화.

이 수준에서 가장 눈에 띄는 모니터링 사례는 Nginx와 PostgreSQL입니다.

우리 시스템에서 가장 많이 로드되는 서비스는 데이터베이스입니다. 과거에는 데이터베이스가 무엇을 하고 있는지 파악하는 데 종종 어려움을 겪었습니다.

디스크의 로드가 높은 것을 확인했지만 느린 로그에는 실제로 아무 것도 표시되지 않았습니다. 쿼리 통계를 수집하는 뷰인 pg_stat_statements를 사용하여 이 문제를 해결했습니다.

이것이 관리자에게 필요한 전부입니다.

읽기 및 쓰기 요청 활동에 대한 그래프를 작성합니다.

모든 것이 간단하고 명확하며 각 요청에는 고유한 색상이 있습니다.

똑같이 눈에 띄는 예는 Nginx 로그입니다. 필수품 목록에서 이를 분석하거나 언급하는 사람이 거의 없다는 것은 놀라운 일이 아닙니다. 표준 형식은 그다지 유익하지 않으므로 확장이 필요합니다.

개인적으로 request_time, upstream_response_time, body_bytes_sent, request_length, request_id를 추가하고 응답 시간과 오류 수를 표시합니다.

우리는 응답 시간과 오류 수에 대한 그래프를 작성합니다. 기억하다? 내가 사업 목표에 대해 이야기했나요? 빠르고 오류 없이? 우리는 이미 두 개의 차트를 통해 이러한 문제를 다루었습니다. 그리고 이미 이를 사용하여 근무 중인 관리자에게 전화할 수 있습니다.

그러나 사건의 원인을 신속하게 제거하는 데 또 다른 문제가 남아 있습니다.

사고 해결

문제 식별부터 해결까지의 전체 프로세스는 여러 단계로 나눌 수 있습니다.

• 문제 식별;
• 직무 관리자에게 통지;
• 사건에 대한 대응;
• 원인 제거.

이 작업을 가능한 한 빨리 수행하는 것이 중요합니다. 그리고 문제를 식별하고 알림을 보내는 단계에서 많은 시간을 얻을 수 없다면 어떤 경우에도 XNUMX분이 소요되며 후속 문제는 개선을 위해 단순히 경작되지 않은 분야입니다.

당직 장교의 전화가 울렸다고 상상해 봅시다. 그는 무엇을 할 것인가? 질문에 대한 답을 찾아보세요. 무엇이 고장났고, 어디서 고장났으며, 어떻게 대응해야 할까요? 이러한 질문에 답하는 방법은 다음과 같습니다.

알림 텍스트에 이 모든 정보를 포함하고, 이 문제에 대응하는 방법, 문제를 해결하고 에스컬레이션하는 방법을 설명하는 위키 페이지 링크를 제공합니다.

저는 아직 애플리케이션 레이어와 비즈니스 로직에 대해 아무 말도 하지 않았습니다. 안타깝게도 우리 애플리케이션은 아직 측정항목 수집을 구현하지 않습니다. 이러한 수준의 정보에 대한 유일한 소스는 로그입니다.

몇 가지 요점.

먼저 구조화된 로그를 작성합니다. 메시지 텍스트에 컨텍스트를 포함할 필요는 없습니다. 이로 인해 그룹화하고 분석하기가 어렵습니다. Logstash는 이 모든 것을 정규화하는 데 오랜 시간이 걸립니다.

둘째, 심각도 수준을 올바르게 사용하십시오. 각 언어에는 고유한 표준이 있습니다. 개인적으로 저는 네 가지 수준을 구분합니다.

1. 오류 없음;
2. 클라이언트 측 오류;
3. 실수는 우리 편입니다. 우리는 돈을 잃지 않으며 위험을 감수하지도 않습니다.
4. 실수는 우리 편이고 우리는 돈을 잃습니다.

요약하겠습니다. 비즈니스 로직을 기반으로 모니터링을 구축해야 합니다. 애플리케이션 자체를 모니터링하고 판매량, 신규 사용자 등록 수, 현재 활성 사용자 수 등과 같은 지표를 사용하여 작동해 보세요.

전체 비즈니스가 브라우저의 버튼 하나라면 클릭이 제대로 작동하는지 모니터링해야 합니다. 나머지는 모두 중요하지 않습니다.

이것이 없다면 우리가 했던 것처럼 애플리케이션 로그, Nginx 로그 등에서 따라잡을 수 있습니다. 가능한 한 지원서에 가까이 있어야 합니다.

운영 체제 측정 항목은 물론 중요하지만 기업은 이에 관심이 없으며 이에 대한 대가를 받지도 않습니다.

출처 : habr.com