Adan의 손으로 그린 순서도: 그림이 약간 작을 수 있습니다. 확대하여 확인하세요!
프로메테우스 코어 컴포넌트
프로메테우스 서버
Prometheus 서버는 모니터링 데이터의 수집, 저장 및 쿼리를 담당하는 Prometheus 구성 요소의 핵심 부분입니다. Prometheus 서버는 정적 구성을 통해 모니터링 대상을 관리할 수 있으며 Service Discoverv를 사용하여 모니터링 대상을 동적으로 관리하고 이러한 모니터링 대상에서 데이터를 가져올 수도 있습니다. 둘째, Prometheus 서버는 수집된 모니터링 데이터를 저장해야 하는데, Prometheus 서버 자체가 시계열 데이터베이스로서 수집된 모니터링 데이터를 시계열 방식으로 로컬 디스크에 저장합니다. 마지막으로 Prometheus 서버는 데이터 쿼리 및 분석을 실현하기 위해 사용자 지정 PromQL 언어를 제공합니다.
1. 가져가다
Prometheus 서버는 서비스 검색 구성요소를 통해 위에서 언급한 ]ob, Exporter 및 Pushgateway에서 모니터링 지표 데이터를 HTTP 폴링 형식으로 주기적으로 가져옵니다.
2. 보관
캡처된 모니터링 데이터는 특정 규칙(캡처 전에 서비스 검색에서 제공하는 relabel configs 메서드 사용, 캡처 후 작업에서 메트릭 relabel configs 메서드 사용)에 따라 지워지고 구성되며, 획득한 결과는 새로운 시간에 저장됩니다. 순서대로 지속성. 스토리지 모듈은 수년에 걸쳐 여러 번 재설계되었으며 Prometheus 버전 20의 스토리지 시스템은 세 번째 반복입니다. 스토리지 시스템은 초당 수백만 개의 샘플 수집을 처리할 수 있으므로 하나의 Prometheus 서버로 수천 대의 시스템을 모니터링할 수 있습니다. 사용된 압축 알고리즘은 실제 데이터에서 샘플당 1.3B를 달성할 수 있습니다.
SSD 사용을 권장하지만 Prometheus의 스토리지를 로컬 스토리지와 원격 스토리지로 구분할 필요는 없습니다
. NFS는 모든 버전의 Prometheus에서 지원되지 않습니다. 일부 실제 프로덕션 사례에 따르면 Prometheus가 NFS를 사용하여 파일을 저장하면 기록 데이터가 손실될 가능성이 있음
원격 저장소: 대량의 모니터링 데이터를 저장하는 데 적합합니다. Prometheus가 지원하는 원격 저장소에는 OpenTSDB, InfluxDB.Elasticsearch, Graphite, CrateDB, Kakfa, PostgresQL, TimescaleDB, TiKV 등이 있습니다. 원격 스토리지는 주로 Prometheus의 remote_write 및 remote_read 인터페이스와 관련된 중간 계층의 어댑터로 변환해야 합니다. 실제 프로덕션에서는 원격 스토리지에서 다양한 문제가 발생하므로 지속적인 최적화, 스트레스 테스트, 아키텍처 변환, 심지어 데이터 로직 업로드를 위한 모듈 재작성이 필요합니다.
3. 쿼리
Prometheus가 데이터를 유지한 후 클라이언트는 PromQL 문을 통해 데이터를 쿼리하고
Prometheus 서버에 내장된 Express Browser Ul을 사용할 수 있으며, 이 U를 통해 PromQL을 통해 데이터 쿼리 및 시각화를 직접 실현할 수 있습니다.
Prometheus 서버의 연합 클러스터 기능을 통해 다른 Prometheus 서버 인스턴스에서 데이터를 가져올 수 있으므로 대규모 모니터링의 경우 연합 클러스터 및 기능 파티션을 통해 Prometheus 서버를 확장할 수 있습니다.
수출업체
도구를 사용하여 데이터를 수집합니다. 스카이워킹의 매설 지점 및 프로브 개념과 유사합니다.
Exporter는 모니터링 데이터 수집의 엔드포인트를 HTTP 서비스를 통해 Prometheus Server에 노출하고 Prometheus Server는 Exporter에서 제공하는 Endpoint 엔드포인트에 액세스하여 수집해야 하는 모니터링 데이터를 얻을 수 있습니다. 일반적 으로 Exporter는 두 가지 범주로 나눌 수 있습니다.
collection : 이 유형의 내보내기에는 cAdvisor, Kubernetes, EtcdGokit 등과 같은 Prometheus 모니터링에 대한 지원이 내장되어 있으며, 모두 Prometheus에 모니터링 데이터를 노출하기 위한 내장 엔드포인트가 직접 있습니다.
간접 획득: 간접 획득, 원래 모니터링 대상은 Prometheus를 직접 지원하지 않으므로 Prometheus에서 제공하는 ClientLibrary를 통해 모니터링 대상의 모니터링 획득 프로그램을 작성해야 합니다. 예: MysalExporter, ]MX Exporter, ConsulExporter 등
평신도의 관점에서 우물은 물을 사용하기 전에 뚫어야 합니다.
AlxrtManager
Prometheus 서버는 PromQL을 기반으로 경고 규칙 생성을 지원합니다. PromQL에서 정의한 규칙이 충족되면 경고가 생성되고 후속 경고 처리는 AlertManager에서 관리합니다. AlertManager에서는 이메일, Slack 등의 내장된 알림 방식과 통합하거나 Webhook을 통해 알람 처리 방식을 사용자 정의할 수 있습니다. AlertManager는 Prometheus 시스템의 경보 처리 센터입니다.
요약: 사실 알람 관리자입니다.
푸시게이트웨이
Prometheus 데이터 수집은 Pull 모델을 기반으로 설계되었으므로 Prometheus Server가 네트워크 환경 구성에서 Exporter와 직접 통신할 수 있도록 해야 합니다. 이 네트워크 요구 사항을 직접 충족할 수 없는 경우 PushGateway를 전송에 사용할 수 있습니다. PushGatewav를 통해 내부 네트워크의 모니터링 데이터를 Gateway에 능동적으로 푸시할 수 있습니다. 그리고 Prometheus Server는 동일한 Pull 메서드를 사용하여 PushGateway에서 모니터링 데이터를 가져올 수 있습니다.
서비스 디스커버리
Prometheus는 서비스 검색 메커니즘을 통해 클라우드 및 컨테이너 환경에서 모니터링 시나리오에 대한 포괄적인 지원을 제공합니다 서비스 검색에는 두 가지 방법이 있습니다: 구성 파일 및 서비스 동적 인식 1. 구성 파일 Prometheus는 주기적으로 파일 대상 정보에서 최신 정보를 읽
습니다
.
파일을 지원하는 서비스 검색을 위해 자동화된 구성 관리 도구(Ansible, CronJob, Puppet. SaltStack 등)와 조합하여 실제 시나리오에서
사용할 수 있도록 도출 할 수 있습니다.
2. 서비스 동적 인식을 통해
Prometheus는 Kubernetes, DNS, Zookeeper, Azure, EC2 및 GCE와 같은 다양한 공통 서비스 검색 구성 요소도 지원합니다. 예를 들어 Prometheus는 Kubernetes API를 사용하여 컨테이너 정보 변경(예: 컨테이너 생성 및 삭제)을 가져와 모니터링 개체를 동적으로 업데이트할 수 있으며,
서비스 검색을 통해 관리자는 Prometheus 서비스를 다시 시작하지 않고도 모니터링해야 하는 대상 인스턴스를 동적으로 검색할 수 있습니다. .