Monitore seu sistema

Monitorar o Pod mongot e o status do recurso

O sinal mais direto da disponibilidade de mongot é o estado de seu Pod e o status do recurso MongoDBSearch.

Verifique o estado do pod e a contagem de reinícios:

kubectl get pods -n <namespace> --context <context> | grep search

Um pod mongot saudável relata um estado Running com todos os contêineres prontos e uma contagem de reinícios que não aumenta. Uma contagem crescente de reinícios pode indicar pressão de memória ou um erro de configuração. Para saber mais, consulte Solucionar problemas de implantação do mongot.

Inspecione o status e as condições do recurso MongoDBSearch:

kubectl describe mongodbsearch <MongoDBSearch.metadata.name> \
  -n <namespace> --context <context>

Habilitar métricas do Prometheus

Por padrão, o ponto de extremidade de métricas mongot Prometheus está desabilitado. Adicione o bloco spec.observability.prometheus ao seu recurso MongoDBSearch para habilitá-lo. Um bloco vazio habilita o ponto de extremidade na porta padrão 9946.

spec:
  observability:
    prometheus: {}

Para usar uma porta não padrão, defina spec.observability.prometheus.port:

spec:
  observability:
    prometheus:
      port: 9090

O ponto de extremidade é exposto dentro do pod e é acessível através do IP do pod do contêiner mongot na porta configurada. O Operador Kubernetes não autentica o ponto de extremidade de métricas.

Encaminhar métricas para o Ops Manager

O encaminhador de métricas envia métricas mongot para o MongoDB Ops Manager para que você possa visualizá-las junto com suas outras métricas de implantação. O operador Kubernetes implanta o encaminhador como um Deployment Kubernetes separado que raspa o ponto de extremidade de métricas mongot e envia as métricas para o MongoDB Ops Manager.

O encaminhador de métricas requer o MongoDB Ops Manager 8.0.25 ou posterior e não oferece suporte ao Cloud Manager.

Para configurar o encaminhador, defina os seguintes campos em spec.observability.metricsForwarder no recurso MongoDBSearch:

• mode controla se o operador do Kubernetes implanta o encaminhador. Defina-o como um dos seguintes valores:

  • auto (padrão) implanta automaticamente o encaminhador para uma fonte interna do MongoDB e para uma fonte externa quando você define opsManager.

  • enabled sempre implanta o encaminhador.

  • disabled nunca implanta o encaminhador.

• opsManager.projectConfigMapRef nomeia o ConfigMap que contém a configuração do projeto do MongoDB Ops Manager. Preencha o ConfigMap com as seguintes chaves:

  • baseUrl: o URL da sua instância do MongoDB Ops Manager.

  • projectNameo nome do projeto do MongoDB Ops Manager.

  • orgId: o ID da organização do MongoDB Ops Manager.

• opsManager.agentCredentials nomeia o segredo que contém a chave da API do MongoDB Ops Manager. Preencha o segredo com as seguintes chaves:

  • publicKey: a chave pública da chave de API do Ops Manager.

  • privateKeya chave privada da chave de API do MongoDB Ops Manager.

• resourceRequirements define a CPU e a memória para o contêiner do encaminhador.

Se não definir opsManager, o operador do Kubernetes derivará os detalhes de conexão do MongoDB Ops Manager do recurso MongoDB de origem. Você deve definir opsManager para uma fonte MongoDB externa.

spec:
  observability:
    metricsForwarder:
      mode: enabled
      opsManager:
        projectConfigMapRef:
          name: my-om-project-config
        agentCredentials:
          name: my-om-agent-api-key

O operador Kubernetes relata o status do encaminhador em status.metricsForwarder no recurso MongoDBSearch.

Configurar verbosidade de registro

mongot grava log JSON estruturado nos fluxos stdout e stderr do contêiner, para que você possa lê-los com as ferramentas de log padrão do Kubernetes:

kubectl logs statefulset/<MongoDBSearch.metadata.name>-search-0

Para transmitir log em tempo real, adicione o sinalizador --follow. Para visualizar log de uma instância de contêiner anterior após uma reinicialização, adicione o sinalizador --previous.

Para alterar o detalhamento do log, defina spec.logLevel no recurso MongoDBSearch. Os valores válidos são TRACE, DEBUG, INFO, WARN e ERROR. Se omitido, mongot registra em INFO.

spec:
  logLevel: DEBUG

mongot não gira seus próprios logs. Em uma implantação do Kubernetes, o tempo de execução do contêiner (containerd ou CRI-O na maioria das distribuições) lida com a rotação de log no nó. Se você encaminhar logs para um agregador externo, configure a retenção nesse sistema em vez de no processo mongot.

Ponto de extremidade de verificação de integridade

mongot expõe um servidor de integridade HTTP na porta 8080 dentro do pod com dois pontos de extremidade:

Os pontos de extremidade refletem a inicialização mongot, a vivacidade e a inicialização da replicação do índice. Os pontos de extremidade não podem ser desativados.

O operador Kubernetes conecta /health e /ready às sondas de vivacidade e prontidão do contêiner mongot automaticamente. Normalmente, você não precisa substituir essas sondas; kubectl describe pod <mongot-pod> mostra a configuração da sonda aplicada pelo operador.

Diagnóstico FTDC

mongot grava arquivos FTDC (Full-Time Diagnostic Data Capture) no volume persistente montado no caminho de dados do pod, em um subdiretório diagnostic.data/. O FTDC é habilitado por padrão e destina-se ao suporte do MongoDB para classificar problemas de desempenho e estabilidade.

Os arquivos FTDC incluem dados de cardinalidade mais alta do que a superfície do Prometheus, incluindo dimensionamento por índice, detalhamento de latência para indexação e consulta, estatísticas do catálogo de solicitações, latência de serialização e contadores de desempenho do Lucene.

Para coletar arquivos FTDC para um caso de suporte, copie o diretório diagnostic.data/ do pod mongot com kubectl cp:

kubectl cp <mongot-pod>:/mongot/data/diagnostic.data ./mongot-ftdc

O caminho de montagem no pod é fixado em /mongot/data, independentemente da configuração spec.clusters[].persistence. As configurações de persistência controlam o tamanho do PVC e a classe de armazenamento, não a localização de montagem.

Observabilidade do Envoy gerenciado

Quando você define spec.clusters[].loadBalancer.managed, o operador do Kubernetes provisiona um proxy Envoy L7 que fica na frente dos pods mongot. O contêiner Envoy expõe duas superfícies de observabilidade:

• Ponto de extremidade de administrador na porta 9901 para estatísticas e controle de tempo de execução (nível de log, drenagem do listener). O operador restringe a interface de administrador a uma lista de permissões de caminhos: /ready, /stats*, /drain_listeners e /logging*. Use este ponto de extremidade para solução de problemas ad-hoc com kubectl port-forward; ele não se destina à exposição externa.

• Métricas do Prometheus na porta de administração do Envoy no caminho padrão /stats/prometheus. Raspe este ponto de extremidade junto com as métricas mongot para obter visibilidade de ponta a ponta do fluxo de solicitações, integridade upstream e estado de conexão para o plano de tráfego de pesquisa.

O operador relata o status de alto nível do Envoy em status.loadBalancer.phase no recurso MongoDBSearch:

kubectl get mongodbsearch <name> -o jsonpath='{.status.loadBalancer.phase}'

A fase reflete o ciclo de vida do Envoy Deployment gerenciado pelo operador (por exemplo, Pending, Running, Failed).

Saiba mais

• Solução de problemas de implantação mongot
• mongot Limitações de implantação
• spec.observability.prometheus
• spec.logLevel