Integraciones de herramientas de supervisión

Superficies de supervisión disponibles

En la siguiente tabla se resumen las superficies que mongot expone para la supervisión:

Prometheus y Grafana

Prometheus con Grafana es la pila de supervisión recomendada para la mayoría de las implementaciones autogestionadas. La pila es gratuita, ampliamente compatible y funciona directamente con el punto de conexión de métricas mongot. Prometheus funciona en las ediciones Community y Enterprise, y no requiere configuración de 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

Si su organización estandariza en OpenTelemetry, OpenTelemetry Collector puede ingerir métricas mongot desde el punto final de Prometheus y reenviarlas a cualquier backend compatible con 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

Este patrón es independiente del proveedor. La misma configuración del recopilador funciona para Honeycomb, Grafana nube, New Relic y otros backend.

Para reenviar registros, configure mongot para que escriba JSON en stdout. El recopilador puede analizar los campos estructurados y enrutar los registros a su backend.

Log Forwarding

mongot guarda registros JSON estructurados en stdout y stderr por defecto. Reenvíe stdout a su plataforma de registro centralizada e ingiera los registros como JSON.

verificación de estado

mongot expone dos puntos finales HTTP en el puerto 8080 por defecto:

Ambos puntos finales devuelven JSON con HTTP 200. Trate {"status":"SERVING"} como saludable y {"status":"NOT_SERVING"} como no saludable. Un parámetro de consulta no válido devuelve HTTP 400 con {"error":"BAD_REQUEST"}.

Al igual que el punto de conexión de métricas, los puntos de conexión /health y /ready no están autenticados por defecto. Protéjalos en la capa de red.

En Kubernetes, asigne la sonda de actividad a /health y la sonda de preparación a /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

Si utiliza /health para ambas sondas, un pod puede recibir tráfico antes de que se inicialicen sus índices, porque /health devuelve SERVING tan pronto como se vinculan los servicios. La división de dos puntos finales existe para separar estas señales.

Cuando el MongoDB Controllers for Kubernetes Operator gestiona más de un pod mongot, aprovisiona un balanceador de carga por defecto y enruta el tráfico en función del punto final /ready. Para implementaciones autogestionadas que ejecutan su propio balanceador de carga delante de varias instancias mongot, configure el balanceador de carga para enrutar el tráfico solo a las instancias que devuelvan SERVING en /ready.

Para mantener un pod listo incluso cuando algunos índices no se inicializan, establezca la ruta de la sonda de preparación en /ready?allowFailedIndexes=true. Esta configuración es una compensación deliberada, ya que los índices fallidos devuelven resultados vacíos para las consultas que los alcanzan.

Consideraciones de varias instancias

Si su implementación ejecuta más de una instancia de mongot, cada instancia expone su propio punto de conexión de métricas. Extraiga cada instancia individualmente y, a continuación, utilice agregaciones de Prometheus, como sum, max y avg, para ver una vista combinada de las métricas.

Rastree el atraso de la replicación, la profundidad de la cola del ejecutor y la latencia de la query para cada instancia y en conjunto. Una sola instancia saturada puede degradar la latencia de las query que sirve, y los promedios de toda la flota pueden ocultar esta degradación.

Para clústeres particionados, etiquete cada raspado con el nombre de la partición para que pueda acumular las métricas por partición.

FTDC y casos de soporte

Cuando abra un caso de soporte de MongoDB, adjunte la captura FTDC de la instancia mongot afectada. Para conocer el procedimiento de captura, consulte Registros de mongot y FTDC.