👨🏾‍🏫 😣 👨🏿‍🏭 Thanos - Prometheus escalável 💞 ☝️ 🧜

A tradução do artigo foi preparada especificamente para os alunos do curso "DevOps Practices and Tools" .

(Fabian Reinartz) — , Go . Prometheus Kubernetes SIG instrumentation. production- SoundCloud CoreOS. Google.

(Bartek Plotka) — Improbable. . Intel, Mesos production- SRE Improbable. . : Golang, open source .

Olhando para o nosso principal produto SpatialOS, você pode imaginar que o Improvável precisa de uma infraestrutura de nuvem global altamente dinâmica com dezenas de clusters Kubernetes. Fomos os primeiros a usar o sistema de monitoramento Prometheus . O Prometheus é capaz de rastrear milhões de métricas em tempo real e vem com uma poderosa linguagem de consulta para recuperar as informações necessárias.

Simplicidade e confiabilidade O Prometheus é uma de suas principais vantagens. No entanto, tendo ultrapassado uma certa escala, encontramos várias desvantagens. Para resolver esses problemas, desenvolvemos o Thanos- Um projeto de código aberto criado pelo Improbable para transformar perfeitamente os clusters existentes do Prometheus em um único sistema de monitoramento com um repositório ilimitado de dados históricos. Thanos está disponível no github aqui .

Mantenha-se atualizado com as últimas notícias do Improvável.

Nossos objetivos com Thanos

Em uma certa escala, surgem problemas que vão além das capacidades do Prometheus de baunilha. Como armazenar de forma confiável e econômica petabytes de dados históricos? Isso pode ser feito sem prejuízo do tempo de resposta à solicitação? É possível acessar todas as métricas localizadas em diferentes servidores Prometheus com uma única solicitação de API? É possível combinar de alguma forma os dados replicados coletados usando o Prometheus HA?

Para resolver esses problemas, criamos o Thanos. As seções a seguir descrevem como abordamos esses problemas e explicamos os objetivos que buscamos.

Consultando dados de várias instâncias do Prometheus (consulta global)

Prometeu oferece uma abordagem funcional para sharding. Mesmo um servidor Prometheus fornece escalabilidade suficiente para liberar os usuários das dificuldades do sharding horizontal em quase todos os casos de uso.

Embora esse seja um excelente modelo de implantação, geralmente é necessário acessar dados em diferentes servidores Prometheus por meio de uma única API ou interface de usuário - visão global. Obviamente, é possível exibir várias solicitações em um painel Grafana, mas cada solicitação pode ser executada apenas em um servidor Prometheus. Por outro lado, com o Thanos, você pode consultar e agregar dados de vários servidores Prometheus, pois todos são acessíveis a partir de um ponto de extremidade.

Anteriormente, para obter uma visão global do Improvável, organizamos nossas instâncias do Prometheus em vários níveisFederação Hierárquica . Isso significou a criação de um meta servidor Prometheus que coleta parte das métricas de cada servidor folha, o

que provou ser problemático, complicando a configuração, adicionando um ponto de falha potencial adicional e aplicando regras complexas para fornecer ao terminal federado apenas os dados corretos. Além disso, a federação desse tipo não permite obter uma visão global real, pois nem todos os dados são acessíveis a partir de uma solicitação de API.

Intimamente relacionada a isso, há uma visão única dos dados coletados nos servidores de alta disponibilidade (HA) do Prometheus. O modelo Prometheus HA coleta dados de forma independente duas vezes, o que é tão simples que não poderia ser mais simples. No entanto, o uso de uma representação combinada e deduplicada de ambos os threads seria muito mais conveniente.

Obviamente, há uma necessidade de servidores Prometheus altamente disponíveis. Na Improbable, levamos muito a sério o monitoramento de dados a cada minuto, mas ter uma instância do Prometheus por cluster é um ponto único de falha. Qualquer erro de configuração ou falha de hardware pode resultar potencialmente na perda de dados importantes. Mesmo implementações simples podem levar a pequenas falhas na coleção de métricas, pois a reinicialização pode ser significativamente maior que o intervalo de raspagem.

Armazenamento confiável de dados históricos

O armazenamento de métricas barato, rápido e de longo prazo é o nosso sonho (compartilhado pela maioria dos usuários do Prometheus). Em Improvável, fomos obrigados a definir o período de armazenamento para as métricas para nove dias (no Prometheus 1.8). Isso adiciona limitações óbvias a quão longe podemos olhar para trás.

O Prometheus 2.0 é melhor nesse aspecto, pois o número de séries temporais não afeta mais o desempenho geral do servidor (consulte a palestra do KubeCon sobre o Prometheus 2 ). No entanto, o Prometheus armazena dados em uma unidade local. Embora a compactação de dados altamente eficiente possa reduzir significativamente o uso de um SSD local, ainda há uma limitação na quantidade de dados históricos salvos.

Na Improbable, também nos preocupamos com confiabilidade, simplicidade e custo. As unidades locais grandes são mais difíceis de operar e fazer backup. Eles são mais caros e exigem mais ferramentas de backup, o que leva a uma complexidade desnecessária.

Downsampling

Assim que começamos a trabalhar com dados históricos, percebemos que existem dificuldades fundamentais com o O-big que tornam as consultas cada vez mais lentas se trabalharmos com dados por semanas, meses e anos.

Uma solução padrão para esse problema será a redução da amostragem - redução da amostragem do sinal. Ao reduzir a amostragem, podemos "reduzir" para um intervalo de tempo maior e manter o mesmo número de amostras, o que nos permite manter a capacidade de resposta das solicitações.

Reduzir a amostragem de dados antigos é um requisito inevitável de qualquer solução de armazenamento de longo prazo e vai além do baunilha Prometheus.

Objetivos adicionais

Um dos objetivos iniciais do projeto Thanos era integrar-se perfeitamente a qualquer instalação existente do Prometheus. O segundo objetivo era uma operação simples com uma barreira mínima de entrada. Quaisquer dependências devem ser facilmente satisfeitas para usuários pequenos e grandes, o que também implica em um baixo custo base.

Arquitetura Thanos

Depois que nossos objetivos foram listados na seção anterior, vamos trabalhar com eles e ver como Thanos resolve esses problemas.

Visão global

Para obter uma visão global sobre as instâncias existentes do Prometheus, precisamos associar um único ponto de entrada de solicitação a todos os servidores. É exatamente isso que o componente Thanos Sidecar faz . Ele é implantado ao lado de cada servidor Prometheus e atua como um proxy, fornecendo dados locais do Prometheus por meio da interface gRPC da loja, permitindo selecionar dados de séries temporais por rótulo e intervalo de tempo.

Por outro lado, existe um componente Querier escalável horizontalmente sem estado que faz um pouco mais do que apenas responder às solicitações do PromQL por meio da API HTTP padrão do Prometheus. Os componentes Querier, Sidecar e outros Thanos se comunicam através do protocolo de fofocas .

O solicitante, após o recebimento da solicitação, se conecta ao servidor da API da loja correspondente, ou seja, ao nosso Sidecar e recebe dados de séries temporais dos servidores correspondentes do Prometheus.
Depois disso, combina as respostas e executa uma consulta PromQL nelas. O querier pode combinar dados separados e duplicados dos servidores de alta disponibilidade do Prometheus.

Isso resolve a maior parte do nosso quebra-cabeça - combinando dados de servidores isolados do Prometheus em uma única exibição. De fato, Thanos só pode ser usado para esta oportunidade. Os servidores Prometheus existentes não precisam fazer alterações!

Prazo de validade ilimitado!

No entanto, mais cedo ou mais tarde, queremos salvar dados que vão além do tempo normal de armazenamento do Prometheus. Para armazenar dados históricos, escolhemos o armazenamento de objetos. Está amplamente disponível em qualquer nuvem, bem como em data centers locais e é muito econômico. Além disso, quase qualquer armazenamento de objeto é acessível por meio da conhecida API S3.

Prometheus grava dados da RAM no disco aproximadamente a cada duas horas. O bloco de dados armazenados contém todos os dados por um período fixo de tempo e é imutável. Isso é muito conveniente, porque o Thanos Sidecar pode simplesmente olhar o catálogo de dados do Prometheus e, à medida que novos blocos aparecem, carregá-los nos baldes de armazenamento de objetos.

O download no armazenamento de objetos imediatamente após a gravação em um disco também permite manter a simplicidade de um "raspador" (Prometheus e Thanos Sidecar) simples. O que simplifica o suporte, o custo e o design do sistema.

Como você pode ver, o backup de dados é muito simples. Mas e a consulta de dados no armazenamento de objetos?

O componente Thanos Store atua como um proxy para recuperar dados do armazenamento de objetos. Como o Thanos Sidecar, ele participa do cluster de fofocas e implementa a API da loja. Portanto, o Querier existente pode considerá-lo como Sidecar, como outra fonte de dados de séries temporais - nenhuma configuração especial é necessária.

Os blocos de dados de séries temporais são compostos de vários arquivos grandes. Fazer o download sob demanda seria bastante ineficiente, e o armazenamento em cache local exigia muita memória e espaço em disco.

Em vez disso, o Store Gateway sabe como lidar com o formato de armazenamento do Prometheus. Graças ao planejador de consultas inteligente e ao cache de apenas as partes necessárias do índice dos blocos, tornou-se possível reduzir consultas complexas ao número mínimo de solicitações HTTP para objetos de arquivos de armazenamento. Portanto, é possível reduzir o número de solicitações de quatro a seis ordens de magnitude e obter tempos de resposta geralmente difíceis de distinguir das solicitações de dados em um SSD local.

Conforme mostrado no diagrama acima, o Thanos Querier reduz significativamente o custo de uma única solicitação de dados no armazenamento de objetos usando o formato de armazenamento do Prometheus e colocando dados relacionados lado a lado. Usando essa abordagem, podemos combinar muitas consultas únicas em um número mínimo de operações em massa.

Compactação e downsampling

Depois que o novo bloco de dados de séries temporais foi carregado com êxito no armazenamento de objetos, consideramos dados "históricos" que ficam imediatamente disponíveis no Store Gateway.

No entanto, após algum tempo, os blocos de uma fonte (Prometheus com Sidecar) se acumulam e não usam mais todo o potencial de indexação. Para resolver esse problema, introduzimos outro componente chamado Compactor. Simplesmente aplica o mecanismo de compactação local do Prometheus aos dados históricos no armazenamento de objetos e pode ser executado como uma tarefa em lote periódica simples.

Graças à compactação eficiente, uma consulta no repositório por um longo período de tempo não apresenta problemas em termos de tamanho dos dados. No entanto, o custo potencial de descompactar um bilhão de valores e executá-los através de um processador de consultas inevitavelmente levará a um aumento acentuado no tempo de execução da consulta. Por outro lado, como existem centenas de pontos de dados por pixel da tela, torna-se impossível visualizar os dados em resolução máxima. Portanto, a redução da amostragem não é apenas possível, mas não levará a uma perda perceptível de precisão.

Para dados de amostragem reduzida, o Compactor agrega dados continuamente com uma resolução de cinco minutos e uma hora. Para cada fragmento bruto codificado usando a compactação TSDB XOR, vários tipos de dados agregados são armazenados, como min, max ou soma para um bloco. Isso permite que o Querier selecione automaticamente o agregado adequado para esta consulta PromQL.

Para usar dados com precisão reduzida, o usuário não precisa de nenhuma configuração especial. O consultor alterna automaticamente entre diferentes resoluções e dados brutos à medida que o usuário aumenta e diminui o zoom. Se desejado, o usuário pode controlar isso diretamente através do parâmetro "step" na solicitação.

Como o custo de armazenamento de um GB é pequeno, por padrão, o Thanos salva os dados originais, com uma resolução de cinco minutos e uma hora. Não há necessidade de excluir os dados originais.

Regras de gravação

Mesmo com as regras de gravação Thanos, é uma parte essencial da pilha de monitoramento. Eles reduzem a complexidade, latência e custo das solicitações. Eles também são convenientes para os usuários obterem dados métricos agregados. O Thanos é baseado em instâncias de baunilha do Prometheus, por isso é perfeitamente aceitável armazenar regras de gravação e de alerta em um servidor Prometheus existente. No entanto, em alguns casos, isso pode não ser suficiente:

Alertas e regras globais (por exemplo, alertas quando um serviço está inativo em mais de dois dos três clusters).
Regra para dados fora do armazenamento local.
O desejo de manter toda a regra e alerta em um só lugar.

Para todos esses casos, o Thanos inclui um componente separado chamado Régua, que calcula a regra e o alerta através das Consultas Thanos. Ao fornecer a StoreAPI conhecida, o nó Consulta pode acessar métricas recém-calculadas. Posteriormente, eles também são armazenados no armazenamento de objetos e disponibilizados através do Gateway de Loja.

O poder de Thanos

Thanos é flexível o suficiente para ser personalizado de acordo com suas necessidades. Isso é especialmente útil ao migrar do Prometheus simples. Vamos dar uma rápida olhada no que aprendemos sobre os componentes do Thanos. Veja como transferir seu Prometheus de baunilha para o mundo do "armazenamento ilimitado de métricas":

Adicione o Thanos Sidecar aos servidores do Prometheus - por exemplo, o contêiner adjacente no pod do Kubernetes.
Expanda várias réplicas do Thanos Querier para visualizar dados. Nesse momento, é fácil configurar fofocas entre o Scraper e o Querier. Use a métrica 'thanos_cluster_members' para testar interações de componentes.

Somente essas duas etapas são suficientes para fornecer uma visão global e desduplicação de dados contínua de possíveis réplicas de HA do Prometheus! Basta conectar seus painéis ao terminal HTTP do Querier ou usar a interface da interface do usuário Thanos diretamente.

No entanto, se você precisar fazer backup de métricas e armazenamento de longo prazo, precisará executar mais três etapas:

Crie um AWS S3 ou GCS Bucket. Configure o Sidecar para copiar dados para esses buckets. Agora você pode minimizar o armazenamento de dados local.
Expanda o Gateway de loja e conecte-o a um cluster de fofocas existente. Agora você pode enviar solicitações de dados em backups!
Implante o Compactor para melhorar o desempenho da consulta por longos períodos usando compactação e downsampling.

Se você quiser saber mais, fique à vontade para olhar nossos exemplos dos kubernetes manifestos e começar !

Em apenas cinco etapas, transformamos o Prometheus em um sistema de monitoramento confiável, com visão global, tempo ilimitado de armazenamento e potencial alta disponibilidade de métricas.

Puxar pedido: precisamos de você!

Thanos era um projeto de código aberto desde o início. A integração perfeita com o Prometheus e a capacidade de usar apenas parte do Thanos fazem dele uma excelente opção para dimensionar um sistema de monitoramento sem nenhum esforço extra.

Sempre recebemos solicitações e solicitações de recebimento do GitHub. Ao mesmo tempo, sinta-se à vontade para entrar em contato conosco através do Github Issues ou folga Improvable-eng #thanos se você tiver dúvidas ou comentários, ou quiser compartilhar sua experiência! Se você gosta do que fazemos na Improbable, não hesite em entrar em contato conosco - sempre temos vagas !

Saiba mais sobre o curso.

Thanos - Prometheus escalável