Integrações de ferramentas de monitoramento

Superfícies de monitoramento disponíveis

A tabela a seguir resume as superfícies que o mongot expõe para monitoramento:

Prometheus e Grafana

Prometheus com Grafana é a pilha de monitoramento recomendada para a maioria das implantações autogerenciadas. A pilha é gratuita, amplamente suportada e funciona diretamente com o ponto de extremidade de métricas mongot. O Prometheus funciona nas edições Community e Enterprise e não requer configuração do 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

Se sua organização padronizar no OpenTelemetry, o OpenTelemetry Collector poderá ingerir métricas mongot do ponto de extremidade do Prometheus e encaminhá-las para qualquer backend compatível com 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 padrão é neutro em relação ao provedor. A mesma configuração de coletor funciona para Honeycomb, Grafana Cloud, New Relic e outros backends.

Para encaminhar logs, configure mongot para gravar JSON no stdout. O coletor pode então analisar os campos estruturados e rotear os logs para o seu backend.

Encaminhamento de registros

mongot grava logs JSON estruturados para stdout e stderr por padrão. Encaminhe stdout para sua plataforma de log centralizada e ingira os logs como JSON.

verificação de integridade

mongot expõe dois pontos de extremidade HTTP na porta 8080 por padrão:

Ambos os pontos de extremidade retornam JSON com HTTP 200. Trate {"status":"SERVING"} como saudável e {"status":"NOT_SERVING"} como não saudável. Um parâmetro de query inválido retorna HTTP 400 com {"error":"BAD_REQUEST"}.

Assim como o ponto de extremidade de métricas, os pontos de extremidade /health e /ready não são autenticados por padrão. Proteja-os na camada de rede.

No Kubernetes, mapeie a sonda de atividade para /health e a sonda de prontidão para /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

Se você usar /health para ambas as sondas, um pod poderá receber tráfego antes que seus índices sejam inicializados, porque /health retorna SERVING assim que os serviços são vinculados. A divisão de dois pontos de extremidade existe para separar esses sinais.

Quando o MongoDB Controllers for Kubernetes Operator gerencia mais de um pod mongot, ele provisiona um balanceador de carga padrão e roteia o tráfego com base no ponto de extremidade /ready para você. Para implantações autogerenciadas que executam seu próprio balanceador de carga na frente de várias instâncias mongot, configure o balanceador de carga para rotear o tráfego apenas para instâncias que retornam SERVING em /ready.

Para manter um pod pronto mesmo quando alguns índices não são inicializados, defina o caminho da sonda de prontidão como /ready?allowFailedIndexes=true. Essa configuração é uma compensação deliberada, porque os índices com falha retornam resultados vazios para queries que os alcançam.

Considerações sobre várias instâncias

Se sua implantação executar mais de uma instância mongot, cada instância exporá seu próprio ponto de extremidade de métricas. Raspe cada instância individualmente e, em seguida, use agregações do Prometheus, como sum, max e avg, para ver uma visualização combinada das métricas.

Acompanhe o atraso de replicação, a profundidade da fila do executor e a latência da query para cada instância e em agregação. Uma única instância saturada pode degradar a latência das query que ela atende, e as médias de toda a frota podem ocultar essa degradação.

Para clusters sharded, rotule cada raspagem com o nome do shard para que você possa acumular as métricas por shard.

FTDC e casos de suporte

Ao abrir um caso de suporte do MongoDB, anexe a captura FTDC da instância mongot afetada. Para saber o procedimento de captura, consulte mongot Logs e FTDC.