Kubernetes 클러스터 모니터링: Prometheus 개요 및 소개

Kubernetes 모니터링의 개념을 고려하고, Prometheus 도구에 대해 알아보고, 알림에 대해 이야기해 보세요.

모니터링 주제는 방대해서 한 기사로 분해할 수 없습니다. 이 텍스트의 목적은 도구, 개념 및 접근 방식에 대한 개요를 제공하는 것입니다.

기사의 소재는 짜낸 것입니다. 학교 "Slurm"의 공개 강의. 전체 과정을 수강하려면 다음 과정에 등록하세요. Kubernetes의 모니터링 및 로깅 인프라.

Kubernetes 클러스터에서 모니터링되는 항목

물리적 서버. Kubernetes 클러스터가 서버에 배포된 경우 해당 상태를 모니터링해야 합니다. Zabbix가 이 작업을 처리합니다. 그와 함께 일하면 거절할 필요가 없으며 갈등도 없을 것입니다. 서버 상태를 모니터링하는 것은 Zabbix입니다.

클러스터 수준의 모니터링으로 넘어가겠습니다.

제어 영역 구성요소: API, 스케줄러 및 기타. 최소한 서버 또는 etcd의 API가 0보다 큰지 확인해야 합니다. Etcd는 회전 중인 디스크, etcd 클러스터 상태 등을 기준으로 많은 측정항목을 반환할 수 있습니다.

도커 오래 전에 등장했으며 모두가 그 문제를 잘 알고 있습니다. 많은 컨테이너가 정지 및 기타 문제를 발생시킵니다. 따라서 Docker 자체도 시스템으로서 최소한 가용성 측면에서는 제어되어야 합니다.

dns.dns. 클러스터에서 DNS가 중단되면 전체 Discovery 서비스도 중단되고 포드에서 포드로의 호출이 작동하지 않게 됩니다. 실제로는 그러한 문제가 없었지만 이것이 DNS 상태를 모니터링할 필요가 없다는 의미는 아닙니다. 요청 대기 시간 및 기타 일부 측정항목은 CoreDNS에서 추적할 수 있습니다.

입구. 프로젝트의 진입점으로 수신(수신 컨트롤러 포함)의 가용성을 제어해야 합니다.

클러스터의 주요 구성 요소가 해체되었습니다. 이제 추상화 수준으로 내려가겠습니다.

애플리케이션이 포드에서 실행되는 것처럼 보입니다. 즉, 애플리케이션을 제어해야 하지만 실제로는 그렇지 않습니다. 포드는 임시적입니다. 오늘은 한 서버에서 실행되고 내일은 다른 서버에서 실행됩니다. 오늘은 10개, 내일은 2개입니다. 따라서 아무도 포드를 모니터링하지 않습니다. 마이크로서비스 아키텍처 내에서는 애플리케이션의 가용성을 전체적으로 제어하는 ​​것이 더 중요합니다. 특히 서비스 엔드포인트의 가용성을 확인하세요. 작동하는 것이 있나요? 애플리케이션을 사용할 수 있는 경우 그 뒤에 무슨 일이 일어나고 현재 복제본이 몇 개 있는지 등은 두 번째 질문입니다. 개별 인스턴스를 모니터링할 필요가 없습니다.

마지막 수준에서는 애플리케이션 자체의 작동을 제어하고 주문 수, 사용자 행동 등과 같은 비즈니스 지표를 가져와야 합니다.

프로 메테우스

클러스터를 모니터링하는 가장 좋은 시스템은 다음과 같습니다. 프로 메테우스. 품질이나 사용 편의성 측면에서 Prometheus에 필적할 수 있는 도구는 없습니다. 유연한 인프라에 적합하므로 "Kubernetes 모니터링"이라고 하면 일반적으로 Prometheus를 의미합니다.

Prometheus를 시작하는 데는 몇 가지 옵션이 있습니다. Helm을 사용하면 일반 Prometheus 또는 Prometheus Operator를 설치할 수 있습니다.

1. 일반 프로메테우스. 그에게는 모든 것이 괜찮지만 ConfigMap을 구성해야 합니다. 실제로 마이크로서비스 아키텍처 이전에 했던 것처럼 텍스트 기반 구성 파일을 작성해야 합니다.
2. Prometheus Operator는 좀 더 분산되어 있고 내부 로직 측면에서 조금 더 복잡하지만 작업하기가 더 쉽습니다. 별도의 개체가 있고 추상화가 클러스터에 추가되므로 제어 및 구성이 훨씬 더 편리합니다.

제품을 이해하기 위해서는 먼저 일반 Prometheus를 설치하는 것을 권장합니다. 구성을 통해 모든 것을 구성해야 하지만 이는 유익할 것입니다. 무엇이 무엇에 속하는지, 어떻게 구성되는지 알아낼 수 있습니다. Prometheus Operator에서는 즉시 더 높은 추상화로 올라갈 수 있지만 원하는 경우 깊이를 탐구할 수도 있습니다.

Prometheus는 Kubernetes와 잘 통합되어 있습니다. 즉, API 서버에 액세스하고 상호 작용할 수 있습니다.

Prometheus는 인기가 높기 때문에 수많은 애플리케이션과 프로그래밍 언어가 이를 지원합니다. Prometheus에는 자체 메트릭 형식이 있으므로 지원이 필요하며 이를 전송하려면 애플리케이션 내부의 라이브러리나 기성 내보내기 도구가 필요합니다. 그리고 그러한 수출업자가 꽤 많이 있습니다. 예를 들어 PostgreSQL 내보내기가 있습니다. PostgreSQL에서 데이터를 가져와 Prometheus가 작업할 수 있도록 Prometheus 형식으로 변환합니다.

프로메테우스 아키텍처

프로메테우스 서버 프로메테우스의 두뇌인 백엔드입니다. 측정항목은 여기에서 저장되고 처리됩니다.

측정항목은 시계열 데이터베이스(TSDB)에 저장됩니다. TSDB는 별도의 데이터베이스가 아니라 Prometheus에 내장된 Go 언어 패키지입니다. 대략적으로 말하면 모든 것이 하나의 바이너리에 있습니다.

오랫동안 TSDB에 데이터를 저장하지 마십시오

Prometheus 인프라는 메트릭을 장기간 저장하는 데 적합하지 않습니다. 기본 보존 기간은 15일입니다. 이 한도를 초과할 수 있지만 TSDB에 더 많은 데이터를 저장하고 저장 기간이 길어질수록 더 많은 리소스가 소비된다는 점을 명심하세요. Prometheus에 기록 데이터를 저장하는 것은 나쁜 습관으로 간주됩니다.

트래픽이 많고 메트릭 수가 초당 수십만 개에 달하는 경우 디스크 공간이나 기간별로 저장 공간을 제한하는 것이 좋습니다. 일반적으로 "핫 데이터"는 단 몇 시간 만에 TSDB에 저장됩니다. 더 긴 스토리지의 경우 InfluxDB, ClickHouse 등과 같이 이에 적합한 데이터베이스에 외부 스토리지가 사용됩니다. 클릭하우스에 대한 좋은 리뷰를 더 많이 봤습니다.

Prometheus 서버는 모델에서 작동합니다. 당겨: 그는 우리가 그에게 제공한 엔드포인트에 대한 측정항목을 찾습니다. 그들은 "API 서버로 가세요"라고 말했고 그는 n번째 초마다 거기로 가서 메트릭을 가져옵니다.

스크래핑 기간 사이에 나타날 수 있는 수명이 짧은 객체(작업 또는 크론 작업)의 경우 Pushgateway 구성 요소가 있습니다. 단기 개체의 지표가 여기에 푸시됩니다. 작업이 시작되고, 작업이 수행되고, 지표가 Pushgateway로 전송되고 완료되었습니다. 잠시 후 Prometheus는 자체 속도로 내려와 Pushgateway에서 이러한 측정항목을 수집합니다.

Prometheus에서 알림을 구성하려면 별도의 구성요소가 있습니다. 경보 관리자. 그리고 경고 규칙. 예를 들어 서버 API가 0인 경우 경고를 생성해야 합니다. 이벤트가 발생하면 추가 전달을 위해 경고가 경고 관리자에게 전달됩니다. 경고 관리자에는 매우 유연한 라우팅 설정이 있습니다. 경고 그룹 하나는 관리자의 텔레그램 채팅으로, 다른 그룹은 개발자 채팅으로, 세 번째 그룹은 인프라 작업자 채팅으로 보낼 수 있습니다. Slack, Telegram, 이메일 및 기타 채널로 알림을 보낼 수 있습니다.

마지막으로 프로메테우스 킬러 기능에 대해 말씀드리겠습니다~ 발견. Prometheus로 작업할 때 모니터링할 개체의 특정 주소를 지정할 필요가 없으며 해당 개체 유형을 설정하는 것으로 충분합니다. 즉, "여기에 IP 주소가 있습니다. 여기에 포트가 있습니다. 모니터입니다"라고 쓸 필요가 없으며 대신 이러한 개체를 찾는 원칙에 따라 결정해야 합니다(목표 - 목표). Prometheus 자체는 현재 활성화된 개체에 따라 필요한 개체를 가져와 모니터링에 추가합니다.

이 접근 방식은 모든 것이 부동하는 Kubernetes 구조에 잘 맞습니다. 오늘은 10개의 서버가 있고 내일은 3입니다. 서버의 IP 주소를 매번 지정하지 않기 위해 서버를 찾는 방법을 한 번 작성했으며 Discovering이 이를 수행합니다. .

프로메테우스 언어라고 불린다. PromQL. 이 언어를 사용하면 특정 측정항목의 값을 얻은 다음 이를 변환하고 이를 기반으로 분석 계산을 작성할 수 있습니다.

https://prometheus.io/docs/prometheus/latest/querying/basics/

Простой запрос

    container_memory_usage_bytes

Математические операции

    container_memory_usage_bytes / 1024 / 1024

Встроенные функции

    sum(container_memory_usage_bytes) / 1024 / 1024

Уточнение запроса

    100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

프로메테우스 웹 인터페이스

Prometheus에는 매우 최소한의 자체 웹 인터페이스가 있습니다. 디버그 또는 데모에만 적합합니다.

표현식 줄에서는 PromQL 언어로 쿼리를 작성할 수 있습니다.

경고 탭에는 경고 규칙이 포함되어 있으며 다음과 같은 세 가지 상태가 있습니다.

1. 비활성 - 현재 경고가 활성화되지 않은 경우, 즉 모든 것이 정상이고 작동하지 않은 것입니다.
2. 보류 중 - 경고가 작동했지만 전송이 아직 통과되지 않은 경우입니다. 네트워크 깜박임을 보상하기 위해 지연이 설정됩니다. 지정된 서비스가 XNUMX분 이내에 활성화된 경우 알람이 아직 울리지 않아야 합니다.
3. 발사는 경고가 켜지고 메시지를 보내는 세 번째 상태입니다.

상태 메뉴에서는 프로메테우스가 무엇인지에 대한 정보에 액세스할 수 있습니다. 위에서 이야기한 목표(목표)로의 전환도 있습니다.

Prometheus 인터페이스에 대한 자세한 개요는 다음을 참조하세요. Kubernetes 클러스터 모니터링에 대한 Slurm의 강의에서.

Grafana와의 통합

Prometheus 웹 인터페이스에서는 클러스터 상태에 대한 결론을 도출할 수 있는 아름답고 이해하기 쉬운 그래프를 찾을 수 없습니다. 이를 구축하기 위해 Prometheus는 Grafana와 통합되었습니다. 우리는 그러한 대시보드를 얻습니다.

Prometheus와 Grafana 통합을 설정하는 것은 전혀 어렵지 않습니다. 문서에서 지침을 찾을 수 있습니다. 프로메테우스에 대한 GRAFANA 지원자, 이것으로 마치겠습니다.

다음 기사에서는 모니터링 주제를 계속해서 다룰 것입니다. Grafana Loki 및 대체 도구를 사용하여 로그를 수집하고 분석하는 방법에 대해 이야기하겠습니다.

작성자: Marcel Ibraev, 인증된 Kubernetes 관리자, 회사에서 실습 엔지니어 사우스 브리지, 연사 및 강좌 개발자인 Slurm.

출처 : habr.com