UI de logs e de infraestrutura: novas maneiras de os operadores interagirem com o Elasticsearch
Com a versão 6.5 do Elastic Stack, lançamos duas novas maneiras de interagir com seus dados: as UIs de logs e de infraestrutura. Ambas estão na versão beta no 6.5, mas falarei sobre isso mais tarde, quando pedirei sua opinião. Para cada uma delas, gostaria de falar um pouco sobre a motivação, a experiência do usuário e a configuração da UI. Vamos começar com a UI de logs.
UI de logs
Motivação
Já ouvi isto tantas vezes: "Só me dê os logs, não preciso de nada sofisticado, tudo o que preciso saber está escrito nos logs, eu só quero lê-los." Nós ouvimos você. A escolha é sua:
Um tail -f turbinado onde os registros mais recentes ficam na parte inferior; uma experiência visual com tabelas, gráficos, nuvens de tags etc.; ou uma visualização tabular. Você deve poder trabalhar da maneira mais adequada para você, e o Elastic Stack tem total abertura para dar suporte a isso.
 |  |  |
Experiência do usuário
O uso da UI de logs é semelhante a fazer tailing de um arquivo de log, mas com todos os seus logs de todos os seus sistemas disponíveis em um único console. Os logs são transmitidos e a parte inferior da visualização é o registro mais recente, assim como um tail -f. Por padrão, a UI de logs mostra todos os registros de todos os logs que atendem aos critérios de configuração (veremos mais sobre isso na próxima seção). Quando você está trabalhando em um problema e decide que não quer todos os seus logs, de todos os seus serviços, todos juntos (sendo transmitidos mais rápido do que qualquer um poderia ler), basta alterar a interação digitando na barra de busca na parte superior. Por exemplo, se eu quiser ver apenas erros 404 dos pods h do Apache com o rótulo do Kubernetes tier = "frontend", basta começar a digitar na barra de busca e deixar o preenchimento automático me ajudar a encontrar os logs certos:
Compare isso com abrir um terminal, autenticar-se com o provedor do k8s, descobrir quais pods você quer e executar kubectl logs -f … | grep 404 (ou no mundo sem container, encontrar os nomes dos hosts, entrar no SSH, fazer tailing dos logs etc.). Queremos facilitar sua vida e fornecer seus dados da maneira que você quer vê-los.
Configuração
Os documentos da UI de logs estão no local de sempre, mas destacarei algumas das opções de configuração aqui. Esta é a configuração padrão que você pode colar no config/kibana.yml e depois modificar a partir dos padrões:
xpack.infra.sources.default.logAlias: "filebeat-*"
xpack.infra.sources.default.fields.timestamp: "@timestamp"
xpack.infra.sources.default.fields.message: ['message', '@message']
A configuração é bem simples; logo de cara, as linhas que aparecem na UI de logs são o campo message de cada índice que corresponde ao alias filebeat-*. Então, e se você quiser adicionar todos os seus índices do Logstash? Basta modificar o xpack.infra.sources.default.logAlias na entrada do config/kibana.yml desta forma e reiniciar o Kibana:
#xpack.infra.sources.default.logAlias: "filebeat-*"
xpack.infra.sources.default.logAlias: "filebeat-*,logstash-*"
Não se esqueça de reiniciar o Kibana. Abra a UI de logs novamente e clique em Stream Live. Você verá todos os seus logs do Logstash e do Filebeat sendo transmitidos para a UI de logs.
Observação: se preferir usar aliases do Elasticsearch, defina xpack.infra.sources.default.logAlias como o nome do alias e atualize o alias conforme necessário. Aqui está o equivalente ao uso de um alias de logs
Crie o alias:
curl -X POST "localhost:9200/_aliases" -H 'Content-Type: application/json' -d'
{
"actions" : [
{ "add" : { "indices" : ["logstash-*", "filebeat-*"], "alias" : "logs" } }
]
}
'
Atualize o config/kibana.yml:
#xpack.infra.sources.default.logAlias: "filebeat-*"
xpack.infra.sources.default.logAlias: "logs"
UI de infraestrutura
Motivação
Vejo três níveis básicos de maturidade no gerenciamento da infraestrutura:
- Descobrir que algo está com problema e abrir um sistema de monitoramento para explorar.
- Traçar gráficos dos principais indicadores de todos os sistemas em um grande dashboard e observar isso, depois analisar até encontrar os problemas.
- Automatizar os operadores com machine learning descobrindo o comportamento normal, detectando problemas emergentes e alertando os operadores.
A UI de infraestrutura foi desenvolvida para levar os operadores ao estágio de "traçar gráficos dos principais indicadores em um grande dashboard". É seguro dizer que todos nós precisamos chegar ao "estágio automatizado com machine learning"; você pode ler mais sobre o machine learning da Elastic e, se assistir ao vídeo no final deste post, verá um fluxo de trabalho que começa com um alerta de um trabalho de machine learning e progride a partir daí pelo APM e o rastreamento distribuído, a UI de infraestrutura e a UI de logs. Ter todos os logs, metrics, APM e rastreamento distribuído juntos no Elasticsearch permite usar todas as ferramentas de análise e visualização com todos os seus dados.
Vamos dar uma olhada na UI de infraestrutura e depois explorar. Nesta visualização, estamos olhando para os pods do Kubernetes, e eu os agrupo por espaço de nome. Eu estou olhando para o tráfego de rede de entrada. Ao clicar com o botão direito do mouse em um dos pods, posso ir para os logs desse pod ou para um dashboard de metrics selecionadas desse pod.
Experiência do usuário
Atualmente, três tipos de dispositivos são compatíveis: hosts, pods do Kubernetes (k8s) e containers do Docker. A vantagem da UI de infraestrutura é que você pode ver o estado dos principais indicadores de um número muito grande de dispositivos. Em grande volume, você tem quadrados coloridos sem texto até pesquisar um subconjunto interessante usando a barra de busca ou clicando em um grupo. Você também pode executar os logs de um dispositivo ou exibir um dashboard de metrics.
Eu mencionei "principais indicadores"; no momento, esta é a lista, e todos eles vêm do Metricbeat:
Hosts: CPU, memória, carga, tráfego de entrada, tráfego de saída e taxa de log
Kubernetes: CPU, memória, tráfego de entrada e tráfego de saída
Docker: CPU, memória, tráfego de entrada e tráfego de saída
O agrupamento permite detalhar a lista de dispositivos. Se você dá suporte a um aplicativo específico implantado com o Kubernetes, o grupo "espaço de nome" é para você. Se você acha que um problema está relacionado a um nó específico que está sendo sobrecarregado, convém subdividir ainda mais agrupando por espaço de nome e nó. Aqui está a lista de agrupamentos no momento (e você pode usar até dois por tipo de dispositivo):
Hosts: zona de disponibilidade, tipo de máquina, ID do projeto, provedor de serviços em nuvem
Kubernetes: espaço de nome, nó
Docker: host, zona de disponibilidade, tipo de máquina, ID do projeto, provedor
Se nenhum dos agrupamentos acima for compatível com a maneira como você quer interagir com seus dados, use a barra de busca. Basta começar a digitar e o recurso de preenchimento automático do Kibana Query Language (KQL) guiará você. Eu forneci um exemplo no GIF da UI de logs na parte superior; quando comecei a digitar kubernetes, o Kibana ofereceu labels e depois tier e, então, forneceu as opções possíveis com base no que foi indexado no Elasticsearch.
Depois de agrupar os recursos, você pode pesquisar em um grupo clicando nele, o que lhe permite ver mais detalhes sobre esse grupo. Se um host, pod ou container específico lhe interessar, pesquise nos respectivos logs ou metrics. Aqui está uma parte da visualização da metric de um host:
Configuração
Há muito pouca configuração a ser feita para a UI da infraestrutura. Basta implantar o Metricbeat e habilitar o módulo System. Se estiver executando containers, habilite também os módulos Kubernetes e Docker.
A menos que você tenha modificado o padrão de indexação padrão (metricbeat-*), a configuração estará pronta. Se precisar personalizar as coisas, os documentos da UI da infraestrutura terão os detalhes. Incluo as principais opções aqui:
xpack.infra.sources.default.metricAlias: "metricbeat-*"
xpack.infra.sources.default.fields.host: "beat.hostname"
xpack.infra.sources.default.fields.container: "docker.container.name"
xpack.infra.sources.default.fields.pod: "kubernetes.pod.name"
Dê sua opinião
Ambas as UIs estão na versão beta e gostaríamos muito de receber o seu feedback (e continuar recebendo-o mesmo depois da disponibilidade geral das UIs). Diga-nos como você prefere interagir com seus dados. Os agrupamentos nesta versão beta da UI de infraestrutura são suficientes para dar suporte à maneira como sua equipe está organizada? O que seria melhor? Temos as metrics corretas orientando as cores? Você precisa de uma maneira diferente de filtrar os logs na UI de logs? Quando você executa a visualização de metrics na UI de infraestrutura, vê as metrics mais relevantes para você?
Vá para o fórum de discussão do Kibana e diga-nos o que você gosta, não gosta, precisa etc. Os desenvolvedores leem e respondem a essas discussões, e vão adorar saber a sua opinião. Você também pode abrir um registro de problema, enviar um PR ou ficar de olho no GitHub.
Entre e experimente
Nosso sistema de demonstração ao vivo tem logs e metrics que você pode buscar, visualizar e com os quais pode interagir. Acesse e clique no bloco Infrastructure para executar a UI de infraestrutura:
Você pode alternar para as visualizações do Kubernetes ou Docker, agrupar os objetos usando a UI ou restringir a visualização com a barra de busca. Clique com o botão esquerdo do mouse em um host, pod ou container e execute a UI de logs desse objeto. Enquanto estiver no demo.elastic.co, dê uma olhada em alguns dos dashboards e visualizações. Você pode navegar para diferentes áreas da página de destino.
Assista a uma demonstração
Aqui está um vídeo que mostra o fluxo de trabalho dessas UIs (e também machine learning e APM com rastreamento distribuído). Mais uma vez obrigado pela leitura e pelo seu feedback!
