O monitoramento tornou-se um componente muito importante do crescimento das soluções em nuvem à medida que aumenta a complexidade dos sistemas distribuídos. É necessário entender seu comportamento. Precisamos de ferramentas escaláveis que possam coletar dados de todos os serviços – e fornecer aos especialistas uma interface única com análise de desempenho, demonstração de erros, disponibilidade e logs.
Essas mesmas ferramentas devem ser eficientes e produtivas. Neste artigo, veremos duas pilhas de tecnologia populares: EFK (Elasticsearch) e PLG (Loki) e examinaremos suas arquiteturas e diferenças.
Pilha EFK
Você já deve ter ouvido falar do popular ELK ou EFK. A pilha consiste em várias partes distintas: Elasticsearch (armazenamento de objetos), Logstash ou FluentD (coleta e agregação de logs) e Kibana para visualização.
Um fluxo de trabalho típico é assim:
ElasticSearch — armazenamento distribuído de objetos com pesquisa e análise em tempo real. Excelente solução para dados semiestruturados como logs. As informações são salvas como documentos JSON, indexadas em tempo real e distribuídas entre nós do cluster. É usado um índice invertido, contendo todas as palavras exclusivas e documentos associados para pesquisa de texto completo, que por sua vez é baseado no mecanismo de pesquisa Apache Lucene.
FluenteD é um coletor de dados que unifica os dados ao coletá-los e consumi-los. Ele tenta organizar os dados em JSON tanto quanto possível. Sua arquitetura é extensível, existem mais , apoiado pela comunidade, para todas as ocasiões.
Kibana - uma ferramenta de visualização de dados para Elasticsearch com vários recursos adicionais, por exemplo, análise de séries temporais, análise de gráficos, aprendizado de máquina e muito mais.
Arquitetura Elasticsearch
Os dados do cluster Elasticsearch são armazenados espalhados por todos os seus nós. Um cluster consiste em vários nós para melhorar a disponibilidade e a resiliência. Qualquer nó pode executar todas as funções do cluster, mas em implantações de grande expansão, os nós normalmente recebem tarefas individuais.
Tipos de nós de cluster:
- nó mestre - gerencia o cluster, são necessários pelo menos três, um está sempre ativo;
- nó de dados - armazena dados indexados e executa diversas tarefas com eles;
- nó de ingestão - organiza pipelines para transformar dados antes da indexação;
- nó coordenador - roteamento de solicitações, redução da fase de processamento da pesquisa, coordenação da indexação em massa;
- nó de alerta — iniciando tarefas de alerta;
- nó de aprendizado de máquina - processamento de tarefas de aprendizado de máquina.
O diagrama abaixo mostra como os dados são armazenados e replicados entre nós para obter maior disponibilidade de dados.
Os dados de cada réplica são armazenados em um índice invertido, o diagrama abaixo mostra como isso acontece:
Instalação
Detalhes podem ser visualizados , usarei o gráfico do Helm:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsPilha PLG
Não se surpreenda se não encontrar essa sigla, pois ela é mais conhecida como Grafana Loki. Em qualquer caso, esta pilha está ganhando popularidade porque utiliza soluções técnicas comprovadas. Você já deve ter ouvido falar do Grafana, uma ferramenta de visualização popular. Seus criadores, inspirados no Prometheus, desenvolveram o Loki, um sistema de agregação de logs de alto desempenho, escalável horizontalmente. Loki indexa apenas os metadados, não os periódicos em si, uma solução técnica que permite que seja fácil de usar e econômica.
Promtail - um agente para enviar logs do sistema operacional para o cluster Loki. grafana é uma ferramenta de visualização baseada em dados do Loki.
Loki é construído com base nos mesmos princípios do Prometheus, tornando-o adequado para armazenar e analisar logs do Kubernetes.
Arquitetura Loki
Loki pode ser executado como um único processo ou como vários processos, permitindo escalonamento horizontal.
Também pode funcionar como um aplicativo monolítico ou como um microsserviço. A execução como um processo único pode ser útil para o desenvolvimento local ou para uma monitorização menor. Para implementação industrial e carga de trabalho escalável, recomenda-se usar a opção de microsserviço. Os caminhos para gravação e leitura de dados são separados, para que possam ser ajustados e dimensionados conforme necessário.
Vejamos a arquitetura do sistema de coleta de logs sem entrar em detalhes:
E aqui está a descrição (arquitetura de microsserviços):
Componentes:
Promtail — um agente instalado nos nós (como um conjunto de serviços), remove logs de tarefas e acessa a API Kubernetes para obter metadados que marcarão os logs. Em seguida, ele envia o log para o serviço principal do Loki. O mapeamento de metadados oferece suporte às mesmas regras de marcação do Prometheus.
Distribuidor — um distribuidor de serviços que funciona como buffer. Para processar milhões de registros, ele empacota os dados recebidos, compactando-os em blocos à medida que chegam. Vários coletores de dados estão sendo executados simultaneamente, mas os logs pertencentes a um fluxo de dados de entrada só devem aparecer em um deles para todos os seus blocos. Isso é organizado em um anel de coletores e hashing sequencial. Para tolerância a falhas e redundância, isso é feito n vezes (3 se não estiver configurado).
Ingerir - receptor de serviço. Os blocos de dados chegam compactados com logs adicionados. Quando o bloco tiver tamanho suficiente, ele será descarregado no banco de dados. Os metadados vão para o índice e os dados do bloco de log vão para os Chunks (geralmente armazenamento de objetos). Após o reset, o receptor cria um novo bloco onde novas entradas serão adicionadas.
Índice - banco de dados, DynamoDB, Cassandra, Google BigTable, etc.
Chunks — blocos de log em formato compactado, geralmente armazenados em armazenamento de objetos, por exemplo, S3.
Consultor - o caminho de leitura que faz todo o trabalho sujo. Ele analisa o intervalo de tempo e o carimbo de data/hora e, em seguida, analisa o índice para encontrar correspondências. Em seguida, ele lê blocos de dados e os filtra para obter o resultado.
Agora vamos ver tudo em ação.
Instalação
A maneira mais fácil de instalar no Kubernetes é usar o helm. Presumimos que você já o instalou e configurou ( Aproximadamente. tradutor)
Adicione um repositório e instale uma pilha.
$ helm repo add loki https://grafana.github.io/loki/charts
$ helm repo update
$ helm upgrade --install loki loki/loki-stack --set grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=falseAbaixo está um exemplo de painel que mostra dados de métricas do Prometheus para Etcd e logs de pod do Loki para Etcd.
Agora vamos discutir a arquitetura de ambos os sistemas e também comparar suas capacidades entre si.
Comparação
Linguagem de consulta
Elasticsearch usa Query DSL e linguagem de consulta Lucene para fornecer recursos de pesquisa de texto completo. É um mecanismo de pesquisa poderoso e estabelecido, com amplo suporte de operadora. Com ele, você pode pesquisar por contexto e classificar por relevância.
Do outro lado do anel está o LogQL, usado no Loki, o sucessor do PromQL (linguagem de consulta Prometheus). Ele usa tags de log para filtrar e selecionar dados de log. É possível usar alguns operadores e aritmética conforme descrito , mas em termos de recursos fica atrás da linguagem Elastic.
Como as consultas no Loki estão associadas a tags, elas são fáceis de correlacionar com métricas e, como resultado, são mais fáceis de organizar o monitoramento operacional.
Escalabilidade
Ambas as pilhas são escalonáveis horizontalmente, mas o Loki torna isso mais fácil porque possui caminhos separados de leitura e gravação e uma arquitetura de microsserviço. O Loki pode ser personalizado para atender às suas necessidades e pode ser usado para volumes muito grandes de dados de registro.
Múltiplos inquilinos
Multitenancy de cluster é um tema comum na abreviatura OPEX, ambas as pilhas fornecem multitenancy. Existem vários para Elasticsearch separação de clientes: índice separado para cada cliente, roteamento baseado em cliente, campos de cliente exclusivos, filtros de pesquisa. Loki tem na forma de um cabeçalho HTTP X-Scope-OrgID.
de custo
Loki é bastante econômico devido ao fato de não indexar os dados, apenas os metadados. Isto alcança e memória (cache), já que o armazenamento de objetos é mais barato que o armazenamento em blocos, que é usado em clusters do Elasticsearch.
Conclusão
A pilha EFK pode ser usada para diversas finalidades, fornecendo flexibilidade máxima e uma interface Kibana rica em recursos para análises, visualização e consultas. Ele pode ser aprimorado ainda mais por recursos de aprendizado de máquina.
A pilha Loki é útil no ecossistema Kubernetes devido ao seu mecanismo de descoberta de metadados. Você pode correlacionar facilmente dados para monitoramento com base em séries temporais no Grafana e em logs.
Quando se trata de custo e armazenamento de logs de longo prazo, o Loki é um excelente ponto de entrada para soluções em nuvem.
Existem mais alternativas no mercado – algumas podem ser melhores para você. Por exemplo, o GKE possui uma integração Stackdriver que fornece uma excelente solução de monitoramento. Não os incluímos em nossa análise neste artigo.
Links:
O artigo foi traduzido e preparado para Habr por funcionários — cursos intensivos, cursos em vídeo e treinamento corporativo com especialistas em atividade (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Fonte: habr.com