이 페이지에서는 mongot 지표와 로그를 일반적인 모니터링 플랫폼과 통합하는 방법을 설명합니다. 이 지침은 이 도구 중 하나를 이미 실행하고 있으며 mongot-의 특정 구성이 필요하다고 가정합니다. 이 페이지에서는 Prometheus, Grafana 또는 다른 플랫폼을 처음부터 가르지 않습니다.
이 지침은 mongot 를 기존 관찰 스택에 통합하는 사이트 신뢰성 엔지니어와 플랫폼 팀을 대상으로 합니다.
사용 가능한 모니터링 표면
다음 표에는 mongot 가 모니터링을 위해 노출하는 표면이 요약되어 있습니다.
표면 | protocol | 기본 엔드포인트 | 다음 하에 구성됨 | 참고 사항 |
|---|---|---|---|---|
지표 | HTTP, Prometheus text format |
|
| 포함된 |
활성 | HTTP |
|
|
|
준비도 | HTTP |
|
|
|
로그 | stdout 및 stderr 또는 파일 | 로깅 구성 단위 |
| 구성에 따라 JSON 또는 텍스트입니다. |
FTDC | 온디스크 바이너리 스트림 |
|
| 기본적으로 활성화되어 있습니다. |
Prometheus 및 Grafana
Grafana와 함께 사용하는 Prometheus는 대부분의 자체 관리형 배포에 권장되는 모니터링 스택입니다. 스택은 무료이고 널리 지원되며 mongot 지표 엔드포인트와 직접 작동합니다. Prometheus는 Community 및 Enterprise 모두 에디션에서 작동하며 MongoDB Ops Manager 구성이 필요하지 않습니다.
스크래핑 구성
Prometheus 구성에 스크랩 작업 추가:
scrape_configs: - job_name: mongot scrape_interval: 15s scrape_timeout: 10s static_configs: - targets: - mongot-host-1.internal:9946 - mongot-host-2.internal:9946 labels: deployment: prod edition: ce
Kubernetes Operator용 MongoDB Controllers가 관리하는 Kubernetes 배포의 경우 Prometheus Operator와 함께 PodMonitor 또는 ServiceMonitor 리소스를 사용합니다. app=<resource-name>-search로 레이블된 팝을 대상으로 지정합니다.
apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: mongot namespace: <mongot-namespace> spec: selector: matchLabels: app: <resource-name>-search podMetricsEndpoints: - port: metrics interval: 15s
기록 규칙
기록 규칙은 PromQL 반복을 줄이고 Grafana 쿼리를 더 빠르게 만들어 줍니다. 다음 규칙은 자체 관리형 mongot 가 노출하는 지표 이름을 사용합니다.
groups: - name: mongot_recording interval: 30s rules: - record: mongot:search_latency_p99 expr: max(mongot_command_searchCommandTotalLatency_seconds{quantile="0.99"}) - record: mongot:vector_search_latency_p99 expr: max(mongot_command_vectorSearchCommandTotalLatency_seconds{quantile="0.99"}) - record: mongot:search_rate:rate5m expr: sum(rate(mongot_command_searchCommandTotalLatency_seconds_count[5m])) - record: mongot:search_failure_rate:rate5m expr: sum(rate(mongot_command_searchCommandFailure_total[5m])) - record: mongot:replication_lag_ms:max expr: max(mongot_index_stats_indexing_replicationLagMs) - record: mongot:heap_utilization_post_gc expr: mongot_jvm_gc_live_data_size_bytes / mongot_jvm_gc_max_data_size_bytes - record: mongot:gc_pause_worst expr: max(mongot_jvm_gc_pause_seconds_max)
경고 규칙
권장 경고를 Prometheus 경고 규칙으로 번역합니다. 예시:
groups: - name: mongot_alerts rules: - alert: MongotDown expr: up{job="mongot"} == 0 for: 1m labels: severity: page annotations: summary: "mongot is down ({{ $labels.instance }})" - alert: MongotReplicationLagGrowing expr: deriv(max(mongot_index_stats_indexing_replicationLagMs)[15m:1m]) > 500 for: 10m labels: severity: page - alert: MongotHeapPressure expr: mongot:heap_utilization_post_gc > 0.85 for: 5m labels: severity: page
전체 경고 세트를 PromQL로 번역하려면 mongot에 권장되는 경고를 참조하십시오.
Grafana 대시보드 스켈레톤
mongot 의 스타터 Grafana 대시보드에는 다음 패널 그룹이 포함되어야 합니다.
프로세스: 가동 시간, 재시작 횟수, CPU 및 상주 메모리.
JVM: 최대치에 대한 힙 사용량, GC 검사 후 힙, GC 일시 중지 시간 및 스레드입니다.
복제: 현재 상태, 지연 시간(밀리초), 속도 및 초당 적용되는 이벤트입니다.
인덱싱: 활성 빌드, 인덱스 별 상태, 인덱싱 실패 및 병합 백로그입니다.
쿼리: 연산자별 속도, 연산자별 지연 시간 p50, p95, p99, 및 오류 율.
실행자: 푸를 및 거부된 작업의 큐 깊이입니다.
저장: 자유 바이트, IOPS 및 페이지 부족 린도.
임베딩 (활성화된 경우): 요청 속도, 지연 시간, 오류, 및 토큰 처리량.
OpenTelemetry
조직이 OpenTelemetry를 표준화하는 경우 OpenTelemetry Collector는 Prometheus 엔드포인트에서 mongot 지표를 수집하여 OTLP 호환 백엔드로 전송할 수 있습니다.
receivers: prometheus: config: scrape_configs: - job_name: mongot scrape_interval: 15s static_configs: - targets: - localhost:9946 exporters: otlphttp: endpoint: https://<your-otel-backend> service: pipelines: metrics: receivers: - prometheus exporters: - otlphttp
이 패턴은 제공자 중립적입니다. 동일한 컬렉터 구성은 Honeycomb, Grafana 클라우드, New Relic 및 기타 백엔드에서 작동합니다.
로그를 전송하려면 mongot 을 구성하여 JSON을 stdout에 쓰도록 합니다. 수집기는 구조화된 필드를 파싱하고 로그를 백엔드로 보낼 수 있습니다.
로그 전달
mongot 기본적으로 stdout 및 stderr에 구조화된 JSON 로그를 쓰기 (write)합니다. stdout을 중앙집중화된 로그 플랫폼으로 전송하고 로그를 JSON으로 수집합니다.
Fluent Bit 및 Vector
Fluent Bit과 Vector 모두 mongot 로그 컬렉션에 사용할 수 있습니다. 로그를 태그가 지정된 스트림으로 처리합니다. 가장 중요한 로그 패턴을 학습하려면 mongot 로그 및 FTDC를 참조하십시오.
CloudWatch 로그
AWS에서 호스팅하는 배포서버의 경우, CloudWatch 에이전트가 로그 파일을 직접 테일(tail)할 수 있습니다. Exception requiring resync과(와) 같은 주요 로그 패턴에 CloudWatch 지표 필터를 생성하여 로그 이벤트를 지표로 변환합니다.
상태 확인
mongot 기본적으로 포트 8080 에 두 개의 HTTP 엔드포인트를 노출합니다.
엔드포인트 | 사용 이유 | 의미 |
|---|---|---|
| 활성 |
|
| 준비도 |
|
두 엔드포인트 모두 HTTP 200으로 JSON을 반환합니다. {"status":"SERVING"} 은 정상으로, {"status":"NOT_SERVING"} 는 비정상으로 간주합니다. 유효하지 않은 쿼리 매개 변수는 HTTP 400 으로 {"error":"BAD_REQUEST"}를 반환합니다.
지표 엔드포인트와 마찬가지로 /health 및 /ready 엔드포인트는 기본적으로 인증되지 않습니다. 네트워크 계층에서 보호하세요.
Kubernetes에서 라이브니스 프로브를 /health 에, 준비 프로브를 /ready에 매핑합니다.
livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 periodSeconds: 10 failureThreshold: 3 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5 failureThreshold: 3
두 프로브에 /health 를 사용하면 /health 이 서비스가 바인딩되는 대로 SERVING 를 반환하므로 인덱스가 초기화되기 전에 팝이 트래픽을 수신할 수 있습니다. 두 엔드포인트 분할은 이러한 신호를 분리하기 위해 존재합니다.
Kubernetes 연산자용 MongoDB 컨트롤러가 하나 이상의 mongot 팝을 managed하는 경우, 기본 부하 밸런서를 프로비저닝하고 /ready 엔드포인트를 기반으로 트래픽을 라우팅합니다. 여러 mongot 인스턴스 앞에 자체 관리형 부하 밸런서를 실행하는 자체 관리형 배포서버의 경우, /ready에서 SERVING 을 반환하는 인스턴스로만 트래픽을 라우팅하도록 부하 밸런서를 구성합니다.
인덱스 일부가 초기화되지 않아도 팟을 준비 상태로 유지하려면 준비 프로브 경로를 /ready?allowFailedIndexes=true으로 설정합니다. 이 설정은 실패한 인덱스가 여기에 도달하는 쿼리에 대해 빈 결과를 반환하므로 의도적인 트레이드오프입니다.
다중 인스턴스 고려 사항
배포서버에서 하나 이상의 mongot 인스턴스를 실행하는 경우 각 인스턴스는 고유의 지표 엔드포인트를 노출합니다. 각 인스턴스를 개별적으로 스크래이한 후 sum, max, avg 등과 같은 Prometheus 집계를 사용하여 지표의 결합된 보기를 확인합니다.
각 인스턴스에 대한 복제 지연, 실행기 큐 깊이 및 쿼리 지연 시간을 추적하고 집계합니다. 단일 포화된 인스턴스는 제공하는 쿼리의 지연 시간을 저하시킬 수 있으며, 플리트 전체 평균은 이러한 저하를 숨길 수 있습니다.
샤딩된 클러스터의 경우 각 스크랩에 샤드 이름을 라벨하여 샤드별 지표를 롤업할 수 있도록 합니다.
FTDC 및 지원 사례
MongoDB 지원 사례를 열 때 영향을 받은 mongot 인스턴스에서 FTDC 캡처를 첨부하세요. 캡처 절차를 학습하려면 mongot 로그 및 FTDC를 참조하세요.