モニタリング ツールの統合

利用可能なモニタリングサーフェース

次の表は、mongot がモニタリングのために公開するサーフェースを要約したものです。

Prometheus と Grafana

Grafana を使用した Prometheus は、ほとんどの自己管理型配置における推奨のモニタリングスタックです。スタックは無料で広範にサポートされており、mongot メトリクスエンドポイントで直接動作します。Prometheus は Community エディションと Enterprise エディションの両方で動作し、MongoDB Ops Manager の設定は必要ありません。

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

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

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)

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

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 デフォルトでは、構造化された JSON ログを stdout と stderr に書き込みます。stdout を一元化されたログ プラットフォームに転送し、ログを JSON として取り込みます。

ヘルスチェック

mongot デフォルトでポート 8080 で 2 つの 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 を返すため、インデックスが初期化される前にポッドがトラフィックを受け取ることがあります。これらの信号を分離するために、2 つの**エンドポイントとなる接続されたデバイス**の**分裂**が存在します。

Kubernetes オペレータの MongoDB コントローラーが複数の mongot ポッドを管理する場合、デフォルトのロード バランサーがプロビジョニングされ、/ready エンドポイントに基づいてトラフィックがルーティングされます。複数の mongot インスタンスの前で独自のロード バランサーを実行する自己管理型の配置の場合は、/ready で SERVING を返すインスタンスにのみトラフィックをルーティングするようにロード バランサーを構成します。

一部のインデックスの初期化に失敗した場合でもポッドを準備完了状態に保つには、準備状態プローブパスを /ready?allowFailedIndexes=true に設定します。この設定は、意図的なトレードオフです。失敗したインデックスは、それらに到達するクエリに対して空の結果を返すためです。

マルチインスタンスに関する考慮事項

配置で複数の mongot インスタンスが実行されている場合、各インスタンスでそれぞれのメトリクス エンドポイントが公開されます。各インスタンスを個別にスクレイプし、sum、max、avg などの Prometheus 集計を使用して、メトリクスの統合ビューを表示します。

レプリケーションラグ、エクゼキューター キューの深さ、および各インスタンスのクエリ レイテンシを個別におよび集計で追跡します。単一の頻繁なインスタンスは、提供するクエリのレイテンシを低下させる可能性があり、フリート全体の平均ではこの低下が隠される可能性があります。

シャーディングされたクラスターの場合は、各スクレイプにシャード名をラベル付けて、シャードごとにメトリクスをロールアップできるようにします。

FTDC とサポートケース

MongoDB サポート ケースを開くときは、影響を受ける mongot インスタンスの FTDC キャプチャを添付してください。キャプチャ手順については、mongot ログと FTDC を参照してください。