Solucionar problemas de implantações mongot autogerenciadas

Antes de começar

Antes de trabalhar em um cenário, confirme o status da sua implantação:

• Se você tiver uma anomalia de métricas, mas ainda não souber o que está errado, comece com as definições de métricas em Referência de métricas para mongot e os limites em Alertas recomendados para mongot.

• Se você concluiu recentemente uma implantação ou alteração de configuração, comece com Verifique sua conexão mongot.

Se seu sintoma não corresponder a nenhum cenário, capture artefatos conforme descrito em Capturar diagnósticos para suporte e abra um caso de suporte.

mongot Não inicia

O processo mongot não é iniciado após a inicialização.

Problemas

• O processo é encerrado segundos após a inicialização.

• Em um contêiner, o processo é reiniciado em um loop.

• Nenhuma mensagem de log "pronto" aparece.

Causas comuns

Em ordem de prioridade:

1. O arquivo de configuração está malformado ou não possui os campos necessários.

2. A autenticação para mongod falha na inicialização.

3. mongot não é possível acessar mongod no endereço configurado.

4. Ocorre um erro de configuração de TLS.

5. A porta configurada já está em uso.

6. O caminho de dados não é gravável.

Diagnosticar

Revise as linhas de log de inicialização mais recentes. A mensagem de erro identifica o subsistema com falha.

Container

Linux

Arquivo de log

docker logs --tail 100 <container-id>

journalctl -u mongot --no-pager | tail -n 200

tail -n 200 /var/log/mongot/mongot.log

Procure os seguintes padrões:

• Failed to parse config file indica YAML inválido.

• Authentication failed ou Unauthorized indica um problema de credenciais ou x.509 confiança.

• Connection refused ou unable to connect to host indica um host ou porta errados, ou que mongod não está em execução.

• SSL handshake failed indica uma incompatibilidade de CA trust ou certificado SAN.

• Address already in use indica que outro processo está vinculado à mesma porta.

• Cannot write to <dataPath> indica um problema de permissão ou caminho.

Resolver

• Configuração: Corrija o YAML. Para saber mais sobre as configurações válidas, consulte Configurar mongot.

• Autenticação: Verifique se o usuário existe em mongod com a função necessária. Consulte Configurar autenticação e autorização para mongot.

• Acessibilidade: Execute nc -zv <mongod-host> <mongod-port> do host mongot. Verifique firewalls, DNS e a configuração mongod bindIp.

• TLS: Verifique se mongot e mongod confiam na mesma autoridade de certificação (CA) para que o certificado de cada lado seja encadeado a uma CA confiável. Além disso, verifique se o SAN do certificado corresponde ao nome do host que mongot usa. Consulte Configurar criptografia TLS para mongot.

• Porta em uso: identifique o processo conflitante com ss -lntp ou lsof -i :<port>. Altere a porta mongot ou interrompa o outro processo.

• Caminho de dados: verifique se o diretório existe e se o usuário do processo mongot pode gravar nele. Atualize a propriedade e as permissões conforme necessário.

A query falha com um erro de conexão

Uma query falha porque mongod não consegue alcançar mongot.

Problemas

• Uma $search, $searchMeta ou $vectorSearch query retorna um erro de conexão como Error connecting to <host>:<port> :: Connection refused.

• Ou a query retorna Error connecting to Search Index Management service.

Causas comuns

1. mongot não está sendo executado no host que mongod tenta alcançar.

2. A configuração de host ou porta mongod para mongot está errada e não corresponde ao ouvinte mongot.

3. mongot está sendo executado, mas travou ou está reiniciando.

4. O TLS não corresponde. O mongod está configurado para TLS, mas o mongot não está, ou o inverso.

Diagnosticar

No host mongod, teste a conectividade com mongot:

nc -zv <mongot-host> <mongot-port>

No host mongot, confirme se o processo está em execução e escutando:

ps aux | grep '[m]ongot'
ss -lntp | grep <mongot-port>

Inspecione o log mongod para o erro correspondente e o host mongot configurado:

grep -E 'mongotHost|searchIndexManagementHostAndPort' \
  /var/log/mongodb/mongod.log

Resolver

• Se o mongot não estiver em execução, reinicie-o. Se ele não iniciar, siga mongot não inicia.

• Se a configuração do host mongot estiver incorreta, corrija o parâmetro mongod e reinicie o mongod.

• Se o TLS não corresponder, reconcilie a configuração do TLS em ambos os lados. Consulte Configurar criptografia TLS para mongot.

mongot Continua ressincronizando

Um índice sai repetidamente do estado estável e inicia uma sincronização inicial.

Problemas

• Os logs repetem Initial sync starting seguido por exceções.

• No estado estacionário, os logs mostram Exception requiring resync occurred during steady state replication.

• O estado do gerenciador de índices faz a transição de volta para INITIAL_SYNC.

• A pesquisa retorna resultados desatualizados durante a janela de ressincronização.

Causas comuns

1. O oplog mongod foi transferido antes que o mongot pudesse alcançar, geralmente porque o mongot estava muito lento ou inativo, ou porque o oplog é muito pequeno.

2. Um problema transitório, como uma interrupção de rede ou uma breve reinicialização do mongod, causou uma exceção de estado estacionário. Uma única ocorrência é recuperável, mas ocorrências repetidas não são.

3. Uma explosão de mapeamento de documentos preenche repetidamente o heap mongot, acionando um erro de falta de memória e uma ressincronização.

4. Os dados do índice estão corrompidos.

5. Um número muito grande de índices, mapeamentos dinâmicos ou escolhas de campo caras impulsionam o atraso de replicação sustentado.

Diagnosticar

Revise as seguintes métricas:

• mongot_replication_mongodb_indexManagerState ciclos entre INITIAL_SYNC e STEADY_STATE.

• mongot_index_stats_numLuceneMaxDocs é cíclico ou está travado.

• mongot_index_stats_indexing_replicationLagMs continua a subir.

• mongot_jvm_memory_used_bytes e mongot_jvm_gc_pause_seconds_sum aumentam sob pressão de memória.

Procure no log mongot o erro que precede a ressincronização e, em seguida, verifique a janela oplog e o heap:

grep -E 'SteadyStateException|CappedPositionLost|OutOfMemoryError' \
  mongot.log

Em mongosh, verifique o tamanho do oplog mongod com db.getReplicationInfo().

Resolver

• Se o oplog for muito pequeno para a taxa de aplicação mongot, aumente o tamanho do oplog mongod ou feche a lacuna com mais capacidade mongot ou menos índices simultâneos.

• Se as exceções de estado estacionário se repetirem, capture o FTDC e abra um caso de suporte.

• Para uma explosão de mapeamento de documentos, encontre o índice ofensivo, geralmente um com um mapeamento dynamic: true que ingere documentos com chaves arbitrárias. Alterne para um mapeamento estático ou restrinja o conjunto de campos e, em seguida, reinicie mongot para limpar o estado do heap.

• Para corrupção de índice, que é rara, capture o FTDC, depois descarte e recrie o índice afetado. Não exclua arquivos no caminho de dados manualmente.

Erro OutOfMemory ou mongot Morto pelo sistema operacional

mongot sai porque fica sem memória.

Problemas

• mongot sai inesperadamente e a contagem de reinícios do contêiner aumenta.

• Os logs terminam com OutOfMemoryError: Java heap space, um erro de falta de memória do lado da JVM.

• Os logs do sistema de dmesg ou journalctl mostram que o OOM killer encerrou o processo, um erro de falta de memória do lado do host.

Causas comuns

1. O heap é muito pequeno para a carga de trabalho, especialmente durante uma grande sincronização inicial ou mesclagem.

2. Uma explosão de mapeamento de documentos consome o heap. Consulte mongot continua ressincronizando.

3. O limite de memória do contêiner é muito baixo. Mesmo com um heap dimensionado corretamente, a sobrecarga não-heap da JVM pode ultrapassar o limite.

4. Definições de índice ruins, como muitos índice ou definições caras, aumentam a pressão da memória.

5. Ocorre um vazamento de memória, o que é raro, mas possível em compilações de visualização.

Diagnosticar

Revise as seguintes métricas:

• mongot_jvm_memory_used_bytes aumenta com querys com uso intensivo de memória e definições de índice.

• mongot_jvm_gc_pause_seconds_sum mostra o tempo cumulativo gasto em pausas de coleta de lixo.

• machine_swap_bytes permanece próximo de zero em uma implantação saudável. O uso de swap indica pressão severa na memória.

Verifique o log mongot para o rastreamento de pilha de falta de memória e o tamanho de heap configurado:

grep -E 'OutOfMemoryError|Java heap space' mongot.log
ps -ef | grep '[m]ongot' | grep -oE '\-Xmx[0-9a-zA-Z]+'

Para um contêiner, verifique o limite de memória configurado:

docker inspect <container> | grep -i memory

Resolver

• Aumente -Xmx se o host tiver margem de memória.

• Em um contêiner, defina o limite de memória visivelmente maior que -Xmx para acomodar a sobrecarga não heap. Como ponto de partida, defina o limite do contêiner para pelo menos o valor -Xmx mais 30%.

• Se o heap for grande o suficiente, mas você ainda ficar sem memória, procure padrões de indexação que causem a explosão. O log mongot identifica o índice.

• Reduza o número de índice ou simplifique as definições de índice caras se elas forem a fonte de pressão de memória.

• Se você suspeitar de um vazamento de memória, capture o FTDC e um dump de heap para suporte.

A sincronização inicial é lenta ou está travada

Um novo índice leva muito tempo para concluir sua sincronização inicial.

Problemas

• O estado do índice permanece em INITIAL_SYNC por um longo tempo.

• Em alguns casos, o gerente de replicação entra em INITIAL_SYNC_BACKOFF antes de tentar novamente a sincronização inicial.

• mongot_index_stats_numLuceneMaxDocs cresce apenas lentamente.

• O índice não pode ser consultado enquanto a sincronização inicial é executada.

Causas comuns

1. O host de origem mongod está subprovisionado e não consegue alimentar a sincronização inicial com rapidez suficiente.

2. A pressão do disco, CPU ou memória em outro lugar retarda o criar.

3. Um grande preenchimento inicial excede o envelope de hardware atual.

Diagnosticar

Observe mongot_replication_mongodb_indexManagerState e mongot_index_stats_numLuceneMaxDocs para o crescimento de documentos.

Não trate mongot_index_stats_indexing_replicationLagMs como autoritativo durante a sincronização inicial. Essa métrica não é preenchida de forma significativa durante a sincronização inicial. Em vez disso, revise as métricas de integridade do sistema para confirmar se o sistema tem recursos suficientes.

Resolver

• Dimensionar o hospedar de origem mongod se for o gargalo.

• Adicione CPU ou memória onde o sistema é restrito a recursos.

• Verifique novamente o espaço livre em disco antes de tentar uma criação inicial grande.

Índices presos no status PENDING ou BUILDING

Um índice não avança além do estado PENDING ou BUILDING.

Problemas

• Um índice permanece em PENDING ou BUILDING por mais de alguns minutos em uma coleção que não é grande.

• O log mongot não mostra falhas, apenas falta de progresso.

Causas comuns

1. mongot não está progredindo na sincronização. Consulte Grande atraso de replicação.

2. O ponto de extremidade de embedding está falhando para índices de embedding automatizados.

3. O pool do executor de indexação está saturado por outros índices que estão sendo criados simultaneamente.

4. mongot foi reiniciado recentemente e os índices estão sendo atualizados.

5. A pressão do disco pausou uma nova criar ou recriar, embora a definição tenha sido aceita.

Diagnosticar

Revise mongot_replication_mongodb_indexManagerState e mongot_index_stats_numLuceneMaxDocs para ver o progresso.

Em mongosh, verifique o status do índice e qualquer campo de erro:

db.<collection>.getSearchIndexes()

Confirme se a taxa de transferência de indexação está aumentando:

rate(mongot_index_stats_indexing_insert_total[5m])

Para índices de embedding automatizados, verifique se os contadores de repetição de embedding são maiores que zero:

rate(mongot_indexing_steadyStateChangeStream_rescheduledEmbeddingGetMores_total[5m])
rate(mongot_initialsync_queue_requeuedEmbeddingInitialSyncs_total[5m])

Resolver

• Se a taxa de transferência de indexação for constante, revise o log mongot para o nome do índice e quaisquer exceções.

• Se as tentativas de embedding forem maiores que zero, corrija o caminho de embedding. Consulte Configurar mongot para embedding automatizado de pesquisa vetorial do MongoDB.

• Se o pool de executores estiver saturado, reduza as construções de índice simultâneas ou dimensione mongot.

• Se o disco for o bloqueador, adicione espaço ou mova o criar para um nó maior.

Queries retornam resultados vazios

Uma query não retorna resultados, embora existam documentos correspondentes.

Problemas

• Você pode executar findOne() em um documento que espera encontrar no índice de pesquisa.

• Uma query $search no mesmo campo não retorna nada ou menos resultados do que o esperado.

Causas comuns

1. O índice não terminou de ser criado para os documentos que você espera corresponder.

2. Atraso de replicação significa que mongot ainda não recebeu os documentos.

3. A definição do índice não cobre o campo que você pesquisa.

4. A expressão de query está errada, como uma expressão numérica contra um campo com índice como uma string.

5. A indexação falhou nos documentos específicos.

Diagnosticar

Em mongosh, verifique o status do índice e confirme se o índice viu o documento:

db.<collection>.getSearchIndexes()

Em seguida, revise mongot_index_stats_indexing_replicationLagMs para verificar o atraso de replicação.

Resolver

• Aguarde até que o índice atinja o estado pronto.

• Aguarde até que o atraso de replicação seja eliminado.

• Ajuste a definição do índice ou a query.

• Se a indexação falhar em documentos específicos, o log mongot identificará o motivo da falha. Corrija ou filtre esses documentos.

Saturação ou limitação da CPU

A pressão sustentada da CPU degrada o desempenho da query e da replicação.

Problemas

• A latência da query aumenta sob pressão sustentada da CPU.

• O atraso de replicação aumenta porque o trabalho de query e o trabalho de indexação competem pela CPU.

• Em casos graves, as verificações de integridade falham e o processo é reiniciado.

Causas comuns

1. O host mongot está subprovisionado para a combinação atual de query e trabalho de indexação.

2. Muito trabalho de indexação simultâneo compete com a execução de query.

3. A carga de trabalho precisa de descarte de carga ou dimensionamento de capacidade.

Diagnosticar

Revise as seguintes métricas:

• mongot_command_searchCommandTotalLatency_seconds_max

• mongot_index_stats_indexing_replicationLagMs

• Métricas de CPU e carga do host, que aumentam sob saturação.

Nenhuma mensagem de log explícita indica que o host está com a CPU limitada.

Resolver

• Dimensionar CPU no host mongot.

• Reduza a carga por meio de práticas de descarga de carga, se disponível.

• Simplifique o trabalho de indexação se a atividade de replicação competir com as query.

Pressão do disco ou caminho de dados quase cheio

O caminho de dados mongot está com pouco espaço livre.

Problemas

• O espaço livre no caminho de dados mongot cai para zero.

• Os índices existentes acumulam atraso de replicação quando o uso do disco é alto.

• Um índice novo ou reconstruído pode permanecer em INITIAL_SYNC quando a pressão do disco for severa.

• As querys continuam a ter sucesso mesmo enquanto a replicação está pausada para proteção de disco.

Causas comuns

1. O host não tem espaço livre suficiente para o crescimento normal da indexação.

2. Um índice novo ou reconstruído precisa de mais espaço temporário do que o disco atual pode fornecer.

Diagnosticar

Revise as seguintes métricas:

• mongot_system_disk_space_data_path_free_bytes relata bytes livres no diretório de dados.

• mongot_system_disk_space_data_path_total_bytes relata o total de bytes no diretório de dados.

Observe o comportamento de pausa da replicação vinculado aos limites do disco. A replicação para quando o uso do disco excede aproximadamente 90% e é retomada depois que o uso cai abaixo de aproximadamente 85%. Para um novo índice ou recriação, espere que a definição seja aceita, mas a criação permaneça travada se a pressão do disco já estiver acima do limite de proteção.

Resolver

• Adicione capacidade de disco se o host ou volume puder ser expandido com segurança.

• Exclua os índices desnecessários para liberar espaço, se isso for operacionalmente aceitável.

• Mantenha um espaço extra antes de criar ou recriar índices grandes. Planeje aproximadamente 125% da pegada de estado estacionário esperada durante uma reconstrução.

• Em NVMe de armazenamento de instância local, não presuma que você pode redimensionar no local. Geralmente, você precisa de uma classe de máquina maior e de uma reindexação quando excede a capacidade de armazenamento de instância local.

• Se você usar armazenamento com suporte a EBS, um redimensionamento ao vivo será mais viável, mas o NVMe continua sendo a orientação preferencial para o desempenho mongot. Consulte Recomendações de classe de armazenamento para mongot.

Atraso de replicação do limite de BSON de 16 MB

Um evento de fluxo de alterações excede o limite de BSON de 16 MB e interrompe a replicação.

Problemas

• Um índice se torna obsoleto ou começa a ser reconstruído após um erro de replicação de estado estável.

• O log mongot mostra change stream payload exceeding 16MB BSON limit, BSONObjectTooLarge ou código de erro 10334 durante getMore.

• Seus documentos armazenados podem parecer menores que 16 MB, mas a falha ainda ocorre.

Causas comuns

1. O evento de fluxo de alterações excede 16 MB porque inclui o documento e metadados adicionais de fluxo de alterações.

2. Grandes atualizações em documentos já grandes tornam o payload do fluxo de alterações maior do que o tamanho do documento armazenado sozinho sugere.

Diagnosticar

Revise as seguintes métricas:

• mongot_changestream_numSplitEvents_total contagens de eventos que excederam o tamanho de payload de 16 MB.

• mongot_index_stats_indexing_replicationLagMs relata o atraso de replicação para um índice específico.

Pesquise no log mongot as seguintes strings:

• change stream payload exceeding 16MB BSON limit

• BSONObjectTooLarge

• Executor error during getMore

• code 10334

Se uma verificação do tamanho do documento mostrar que os maiores documentos estão abaixo de 16 MB, não descarte esse cenário. O evento de alteração inclui metadados além do próprio documento.

Resolver

• Reduza o tamanho do documento e evite grandes atualizações em documentos já grandes, sempre que possível.

• Sempre que possível, substitua o documento em vez de aplicar uma grande atualização a um documento grande existente.

• Se a maioria das gravações forem atualizações, revise a query de atualização para reduzir o tamanho dos metadados do evento de fluxo de alterações.

• Depois de corrigir a carga de trabalho, permita que a reconstrução seja concluída. Se o padrão de carga de trabalho não mudar, o índice poderá atingir a mesma falha novamente.

• Se o problema reaparecer depois de ajustar a carga de trabalho, capture os logs e escale com os detalhes do incidente.

Atraso de replicação grande

O atraso de replicação aumenta constantemente ao longo do tempo.

Problemas

• O atraso de replicação aumenta constantemente e pode chegar a muitas horas ou vários dias.

• mongot fica com restrições de memória ou fica sem memória repetidamente ao tentar acompanhar.

• O host ainda pode servir query, mas o desempenho da query pode diminuir devido ao trabalho de replicação e grandes pegadas de índice.

Causas comuns

1. Um número muito grande de índice aumenta a replicação e a sobrecarga de indexação.

2. O uso amplo de dynamic: true aumenta a contagem de campos e o tamanho do índice, o que aumenta a pressão da memória.

3. Eventos repetidos de falta de memória pioram o atraso e fazem com que as métricas pareçam irregulares ou incompletas.

4. O gargalo está no banco de dados de origem. Secundários mongod subprovisionados com alta CPU e pressão de cache podem impedir que os eventos de fluxo de alterações sejam emitidos rapidamente.

Diagnosticar

Revise as seguintes métricas:

• mongot_index_stats_indexing_replicationLagMs relata o atraso de replicação para um índice específico.

• mongot_indexing_steadyStateChangeStream_getMoresScheduled relata operações getMore agendadas.

• mongot_replication_mongodb_indexManagerState identifica quais índices não estão progredindo.

• mongot_jvm_memory_used_bytes e as métricas de CPU e carga do host mostram pressão de recursos.

Conte o número total de índices e revise se muitos dependem de dynamic: true ou indexam campos desnecessários de alta cardinalidade.

Resolver

• Dimensionar mongot CPU e memória primeiro se os nós ficarem sem memória ou tiverem restrições de memória.

• Reduza o número total de índice. Em contagens de índice muito altas, adicionar mais nó de pesquisa pode piorar o padrão de carga, a menos que você primeiro controle a carga do fluxo de alterações.

• Desative o mapeamento de esquema dinâmico onde não for necessário. Prefira dynamic: false e mapeie explicitamente apenas os subcampos necessários para queries.

• Reduza o número de campo indexados, especialmente campo de alta cardinalidade, como carimbos de data/hora ou ID do usuário, e remova mapeamentos de faceta profunda que não são usados para faceta.

• Se mongod secundários forem o gargalo, dimensione o banco de dados principal para melhorar a taxa de transferência do fluxo de alterações.

Falhas no handshake TLS

O handshake TLS entre mongot e mongod falha.

Problemas

• O log mongot mostra SSL handshake failed, Certificate verification failed ou bad certificate.

• O log mongod mostra erros semelhantes quando tenta alcançar mongot.

Causas comuns

1. Incompatibilidade de CA: ambas as extremidades não confiam na mesma CA.

2. O SAN do certificado não inclui o nome do host em uso.

3. O certificado expirou.

4. Incompatibilidade do modo TLS: um lado exige TLS e o outro o desativou.

5. Incompatibilidade de conjunto de cifras ou versão TLS, o que é raro.

Diagnosticar

Inspecione os certificados que cada lado serve e verifique a cadeia em relação à sua CA:

openssl s_client -connect <mongot-host>:<mongot-port> -showcerts
openssl s_client -connect <mongod-host>:<mongod-port> -showcerts
openssl verify -CAfile <ca-bundle> <cert-file>
openssl x509 -in <cert-file> -text -noout

Resolver

• Distribua o CA correto para ambos os pontos de extremidade.

• Reemita certificados com a lista SAN correta.

• Renovar certificados expirados.

• Reconcilie os modos TLS em ambos os lados. Consulte Configurar criptografia TLS para mongot.

Índice atinge o limite de documentos do Lucene

Um único índice excede a contagem máxima de documentos do Lucene.

Problemas

• Um índice muito grande para de fazer progresso perto do limite de contagem de documentos do Lucene.

• Os logs mostram java.lang.IllegalArgumentException: number of documents in the index cannot exceed 2147483519.

• mongot_index_stats_numLuceneMaxDocs aproxima-se do limite rígido e pode parar de publicar depois que o limite for atingido.

• O estado do index-manager muda para um estado com falha.

Causas comuns

1. Um único índice não particionado excedeu a contagem máxima de documentos do Lucene de 2147483519.

2. Um novo índice foi aceito e começou a ser criado, mas falhou assim que atingiu o mesmo limite rígido.

Diagnosticar

Assista ao mongot_index_stats_numLuceneMaxDocs como o sinal preventivo primário para esse modo de falha e verifique o log para a string de exceção exata:

java.lang.IllegalArgumentException: number of documents in the index cannot exceed 2147483519

Resolver

Particione o índice para que cada partição permaneça abaixo do limite de contagem de documentos do Lucene e, em seguida, reconstrua o índice com numPartitions definido adequadamente. Espere trade-offs: o particionamento pode exigir query fan-out em várias partições e pode afetar o desempenho da pesquisa.

{
  "numPartitions": 4,
  "mappings": {
    "dynamic": true
  }
}

Falhas de embedding automatizado

Um índice de embedding automatizado não consegue alcançar o ponto de extremidade de embedding.

Problemas

• Um índice de embedding automatizado permanece em PENDING ou BUILDING.

• O log mongot mostra erros em relação ao ponto de extremidade de embedding.

• Os contadores de repetição de embedding mongot_indexing_steadyStateChangeStream_rescheduledEmbeddingGetMores_total ou mongot_initialsync_queue_requeuedEmbeddingInitialSyncs_total são maiores que zero. Use esses contadores como indicadores indiretos e verifique o log para o erro HTTP real do ponto de extremidade de embedding.

Causas comuns

1. A chave de API do modelo é inválida ou expirou.

2. A rede não consegue alcançar o ponto de extremidade de embedding.

3. O provedor de embedding está limitando as solicitações.

4. O provedor de embedding está com uma interrupção.

Diagnosticar

Teste a conectividade com o ponto de extremidade de embedding do host mongot e, em seguida, verifique o log:

grep -E 'voyage|embedding' mongot.log

Resolver

• Substitua a chave da API do modelo e reinicie mongot.

• Abra a saída de rede para o ponto de extremidade de embedding.

• Se o provedor limitar as solicitações, aumente o limite ou reduza a simultaneidade da indexação.

• Se o provedor tiver uma interrupção, monitore o status do Voyage AI e considere alternar os pontos de extremidade.

Para o modelo de configuração de embedding completo, consulte Configurar mongot para embedding automatizado de pesquisa vetorial do MongoDB.

Sinais de armazenamento, como IOPS sustentados ou falhas de página

IOPS de armazenamento sustentado ou falhas de página indicam um gargalo de armazenamento. Se você executar em NVMe local, procure primeiro o espaço livre de memória. Se você executar em qualquer outra classe de armazenamento, como SAN, SSD de nuvem de uso geral ou SSD SATA, a classe de armazenamento será a provável causa raiz e uma migração será garantida. Consulte Recomendações de classe de armazenamento para mongot.

O desempenho diminui sem uma causa óbvia

O desempenho regride sem uma alteração recente na implantação.

Problemas

• A latência da query aumentou sem uma alteração óbvia na implantação.

• O uso da CPU ou da memória aumentou.

Causas comuns

1. A carga de trabalho mudou, com mais ou maiores query.

2. Um novo índice agora consome recursos.

3. Uma explosão de mapeamento de documentos consome o heap.

4. Armazenamento degradado, como um vizinho barulhento, uma reconstrução RAID ou um problema do provedor de nuvem.

5. Uma regressão de ajuste de coleta de lixo ocorreu após uma atualização da JVM.

Diagnosticar

Pivote as métricas por sintoma, como latência de query, heap, fila do executor e IOPS de armazenamento. Para definições e limites de métricas, consulte Referência de métricas para mongot e Alertas recomendados para mongot.

Resolver

A resolução depende da causa raiz. As opções incluem dimensionamento, planejamento de capacidade ou revisão de índice, como descartar índices não utilizados e refinar mapeamentos.

Capturar diagnósticos para suporte

Quando você não conseguir resolver um problema localmente, capture o seguinte antes de abrir um caso de suporte:

1. mongot registros que cobrem o período do problema mais uma hora antes. Encaminhar logs mongod para a mesma janela.

2. FTDC para a instância mongot afetada. Consulte Logs do mongot e FTDC.

3. Snapshot do dashboard das métricas ao longo do período de tempo do problema.

4. Versões de mongot e mongod.

5. O que mudou, como implantações recentes, alterações de configuração ou padrão de tráfego.

6. Etapas para reproduzir o problema, se você puder reproduzi-lo sob demanda.