Guia de solução de problemas: resolvendo 6 problemas comuns no carregamento do Kibana Discover

Discover é a UI núcleo do Kibana®da Elastic® para buscar, filtrar e inspecionar dados (de série temporal). Visualizações são usadas para agregações/resumos de dados. A UI do Discover é resiliente a grandes respostas de dados do Elasticsearch®, mas às vezes pode apresentar problemas devido ao tamanho da resposta (não compactada), explosão de mapeamento e limites do navegador.
Abaixo, resumiremos os problemas históricos mais comuns, incluindo carregamentos lentos, tempos limite (time outs) e erros, e forneceremos um passo a passo sequencial de solução de problemas para resolvê-los. Nota: As APIs deste artigo foram escritas para a v8.6, mas o fluxo geral de solução de problemas se aplica a versões anteriores e posteriores.

Após estabelecer e carregar uma sessão de usuário, o Kibana carregará o Discover via URI base /app/discover (ou sua URI específica relacionada ao Kibana Space). Para carregar esta página, a página do navegador solicitará sequencialmente três APIs do servidor Kibana (e, conforme necessário, através do Kibana para o servidor Elasticsearch abaixo).
Problema comum 1: erros de página no carregamento
Se a página do Kibana apresentar erro ao carregar, você deve abrir a guia de rede do seu navegador para confirmar qual solicitação sequencial está falhando. Você pode compartilhar suas descobertas exportando um log HAR.
1. Carregar Data view
A página do navegador solicitará o endpoint de Objetos salvos do Kibana para a Data View selecionada atualmente (o código ainda aponta para `type:index-pattern`, pois esse objeto era chamado de “padrão de indexação” em versões anteriores, mas foi renomeado na v8.0 para maior clareza).
POST /api/saved_objects/_bulk_get
[{"id":"${INDEX_PATTERN_ID}","type":"index-pattern"}]Esta API do Kibana encaminha a busca para a API do Elasticsearch sob o Alias .kibana de suporte do objeto salvo. Não tenho certeza sobre a tradução da consulta, mas seria algo como:
GET .kibana*/_search
{"query": {"bool": {"filter": [{"bool": {"should": [{
"match_phrase": {"_id": "index-pattern:INDEX_PATTERN_ID"}
}]}}]}}}Nota: os Saved Objects são pesquisados pelo id do Data view e não pelo título ou nome. Se você exportar/importar ou copiar Saved Objects entre Kibana Spaces ou clusters do Elasticsearch, você pode ter um erro de visualização/dashboard/Discover sobre o seu id subjacente ter mudado durante a importação (consulte o módulo de importação de Saved Object para evitar). Para demonstrar a diferença desses campos:

Problema comum 2: Data view ausente
Se isso afetar você, durante o carregamento da página, você verá um módulo de aviso/erro no canto inferior direito semelhante a: "DATA_VIEW_ID" não é um ID de Data view configurado
Este erro é relatado no contexto do Kibana Space atual e não se qualifica se o Data View existir ou não em um Space diferente.
2. Carregar campos
Em seguida, a UI do Kibana carregará uma compilação de campos relacionados aos índices de suporte.
API. Primeiro, ele fará uma solicitação de API:
GET /api/index_patterns/_fields_for_wildcard?pattern=INDEX_PATTERN&meta_fields=_source&meta_fields=_id&meta_fields=_index&meta_fields=_scoreEsta API será acionada novamente toda vez que o usuário selecionar um Data view no canto superior esquerdo. No back-end, o Kibana retorna índices da campo Caps API do Elasticsearch.
Problema comum 3: explosão de mapeamento
O tempo de resposta desta API é drasticamente impactado por explosão de mapeamento, que pode ser parcialmente diagnosticada pelo tamanho da resposta descompactada/compactada desta API. Geralmente, isso se relaciona a quantos mapeamentos de índice variáveis são carregados, mas também pode resultar da substituição de limites de mapeamento. Isso geralmente retorna (bem) abaixo de 3s, mas você deve definitivamente considerar ≥10s como lento.
Problema comum 4: conflitos de campo
Erros ocorreram historicamente devido a conflitos de nomes de campo entre índices. Você desejaria corrigir os mapeamentos de índice subjacentes, mas também pode aplicar um campo de tempo de execução como uma substituição temporária para corrigir o tipo de mapeamento dos índices divergentes.
JS. Assim que os resultados da API retornarem, se a gaveta esquerda (mostrando “Campos selecionados” e “Campos disponíveis”) estiver aberta, o JavaScript do navegador fará uma analítica de resumo desses campos. Se estiver lento, isso aparecerá na guia Rede do navegador como se a solicitação da API tivesse terminado, mas a solicitação (3) seguinte não tivesse começado a tentar por vários segundos. Os usuários normalmente só percebem a partir de ≥10s.

Este tempo de compilação de JavaScript é diagnosticado através da guia Performance do DevTool do navegador (por exemplo, Chrome, Firefox, Edge; também é possível exportar um equivalente tipo HAR para compartilhamento).
3. Carga de buscar
Por fim, a página do navegador fará uma solicitação para buscar na API. Essa solicitação de busca de API passa pelo servidor do Kibana, mas (deveria) levar quase o mesmo tempo que fazer a solicitação de API do Elasticsearch diretamente.
API. Este URI tem como padrão:
POST /internal/bsearch {REQUEST_BODY_HERE}Mas se a Configuração avançada courier:batchSearches estiver definida como false (<v8.0), então, isso solicitará a seguinte API:
POST /internal/_msearch {REQUEST_BODY_HERE}
Esperamos um diferencial entre o “tempo de consulta” (tempo que o Elasticsearch considera que leva para buscar) e o tempo reportado pelo Kibana, mas vamos querer verificar se este último está ordens de magnitude fora do primeiro, o que indicaria, por exemplo, carga no servidor do Kibana, compressão HTTP desabilitada ou problema geral de renderização.
Se quisermos investigar nossa busca mais a fundo para isolar a carga do servidor do Kibana de um problema geral de renderização, navegaremos até Inspect > Request > Open in Console (também conhecido como DevTools). Visualmente:

Em seguida, executaremos esta solicitação de busca da API tanto no DevTools quanto separadamente via cURL da API do Elasticsearch, observando as diferenças gerais de tempo de resposta entre o Discover, o DevTools e a API do Elasticsearch.
Problema comum 5: se a consulta estiver lenta na API do Elasticsearch
Se o Elasticsearch também estiver tão lento quanto os outros dois, podemos suspeitar de uma busca/filtro não otimizado em nossa visualização original do Discover. Se nenhum filtro/busca for aplicado (ou se o problema persistir sem nenhum aplicado), confirmaremos o desempenho geral do Elasticsearch via CAT Node, CAT Threadpools (esp. threads de busca) e CAT Tasks (para tarefas de longa duração). Se nenhum problema em todo o cluster for encontrado, compararemos as durações das respostas de busca entre as diferentes Data view selecionadas no Discover e, em seguida, compararemos o Query Profiling relacionado a essas buscas (após injetar profile: true no corpo da nossa solicitação de busca).
JS. Após o retorno dos resultados da API, o JavaScript do navegador entra em ação para carregar 1) o resumo da tabela de exibição (a tabela “Documents” no meio da parte inferior, onde você pode ativar/desativar a visualização de colunas) ou 2) “campo Statistics” (em beta, ative em Advanced Settings via Discover:showFieldStatistics).
Problema comum 6: tempo de renderização afetado por explosão de mapeamento
Explosões de mapeamento podem levar a um grande conjunto de resultados, o que no passado causou regressões de desempenho no navegador (por exemplo, kibana#144673). A explosão de mapeamento pode revelar erros específicos do navegador, como o erro do Chrome: maximum call stack size exceeded, que se reproduz no modo anônimo, não ocorre no Firefox/Safari e, às vezes, só é resolvido atualizando o Chrome. Se, no entanto, você encontrar um processo de renderização muito lento sem erros após o retorno do resultado, é hora de gravar um Perfil de Desempenho do navegador para investigar o que está causando a renderização lenta. Nossa equipe terá prazer em ajudar a revisar a saída via Kibana GitHub, Elastic Discuss ou abrindo um caso de suporte!
Impacto em cascata
(Para auxiliar na busca rápida de página: #devToolsAuto.) Ao solucionar possíveis explosões de mapeamento, DevTools pode responder mais lentamente do que o Discover e o ícone superior esquerdo carregar quando nenhuma solicitação for esperada devido ao URI.
GET /api/console/autocomplete_entities?fields=true&indices=true&templates=true&dataStreams=true
Essas solicitações podem sobrecarregar 1) o navegador local, causando travamentos de página ou banners de “aguardar página?”, e 2) o servidor do Kibana, dependendo da frequência e do custo de processamento. Esta alteração é específica para o usuário conectado.
Conclusão
O Discover é uma maneira fácil de inspecionar dados de múltiplos índices dentro de seus clusters. Existem algumas configurações e definições que podem fazer com que esta UI carregue mais lentamente do que o necessário. Este guia abordou o impacto desses vários problemas; no entanto, uma boa higiene de dados pode evitar todos eles. Para mais dicas de higiene de dados, consulte nossa documentação do Elasticsearch.
O lançamento e o tempo de amadurecimento de todos os recursos ou funcionalidades descritos neste artigo permanecem a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis no momento poderão não ser entregues ou não chegarem no prazo previsto.