A tradução do artigo foi elaborada especificamente para os alunos do curso .
é desenvolvedor de software, fanático por Go e solucionador de problemas. Ele também é mantenedor do Prometheus e cofundador da instrumentação Kubernetes SIG. No passado, ele foi engenheiro de produção no SoundCloud e liderou a equipe de monitoramento do CoreOS. Atualmente trabalha no Google.
- Engenheiro de Infraestrutura na Improvável. Ele está interessado em novas tecnologias e problemas de sistemas distribuídos. Ele tem experiência de programação de baixo nível na Intel, experiência de contribuidor na Mesos e experiência de produção de SRE de classe mundial na Improbable. Dedicado a melhorar o mundo dos microsserviços. Seus três amores: Golang, código aberto e vôlei.
Olhando para nosso principal produto SpatialOS, você pode adivinhar que o Improbable requer uma infraestrutura em nuvem altamente dinâmica e em escala global com dezenas de clusters Kubernetes. Fomos um dos primeiros a utilizar um sistema de monitoramento . O Prometheus é capaz de rastrear milhões de métricas em tempo real e vem com uma linguagem de consulta poderosa que permite extrair as informações necessárias.
A simplicidade e confiabilidade do Prometheus é uma de suas principais vantagens. No entanto, depois de ultrapassarmos uma certa escala, encontramos várias desvantagens. Para resolver estes problemas desenvolvemos é um projeto de código aberto criado pela Improbable para transformar perfeitamente clusters Prometheus existentes em um único sistema de monitoramento com armazenamento ilimitado de dados históricos. Thanos está disponível no Github .
Nossos objetivos com Thanos
Em uma certa escala, surgem problemas que estão além das capacidades do vanilla Prometheus. Como armazenar petabytes de dados históricos de maneira confiável e econômica? Isso pode ser feito sem comprometer o tempo de resposta? É possível acessar todas as métricas localizadas em diferentes servidores Prometheus com uma única solicitação de API? Existe alguma maneira de combinar dados replicados coletados usando o Prometheus HA?
Para resolver esses problemas, criamos Thanos. As seções a seguir descrevem como abordamos essas questões e explicam nossos objetivos.
Consultando dados de várias instâncias do Prometheus (consulta global)
O Prometheus oferece uma abordagem funcional para fragmentação. Até mesmo um único servidor Prometheus oferece escalabilidade suficiente para libertar os usuários das complexidades da fragmentação horizontal em quase todos os casos de uso.
Embora este seja um ótimo modelo de implantação, muitas vezes é necessário acessar dados em diferentes servidores Prometheus por meio de uma única API ou UI – uma visão global. Claro, é possível exibir múltiplas consultas em um painel Grafana, mas cada consulta só pode ser executada em um servidor Prometheus. Por outro lado, com Thanos você pode consultar e agregar dados de vários servidores Prometheus, uma vez que todos eles são acessíveis a partir de um único endpoint.
Anteriormente, para obter uma visão global no Improbable, organizamos nossas instâncias do Prometheus em uma instância multinível. . Isso significou a criação de um meta-servidor Prometheus que coleta algumas das métricas de cada servidor folha.
Esta abordagem revelou-se problemática. Isto resultou em configurações mais complexas, na adição de um ponto potencial de falha adicional e na aplicação de regras complexas para garantir que o terminal federado receba apenas os dados de que necessita. Além disso, esse tipo de federação não permite obter uma visão global verdadeira, pois nem todos os dados estão disponíveis a partir de uma única solicitação de API.
Intimamente relacionado a isso está uma visão unificada dos dados coletados em servidores Prometheus de alta disponibilidade (HA). O modelo HA do Prometheus coleta dados duas vezes de forma independente, o que é tão simples que não poderia ser mais simples. No entanto, usar uma visualização combinada e desduplicada de ambos os fluxos seria muito mais conveniente.
Obviamente, há necessidade de servidores Prometheus altamente disponíveis. Na Improbable, levamos muito a sério o monitoramento de dados minuto a 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 levar à perda de dados importantes. Mesmo uma implantação simples pode causar pequenas interrupções na coleta de métricas porque as reinicializações podem ser significativamente mais longas do que o intervalo de coleta.
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). No Improvável, fomos forçados a configurar o período de retenção das métricas para nove dias (para Prometheus 1.8). Isto acrescenta limites óbvios ao quão longe podemos olhar para trás.
O Prometheus 2.0 melhorou nesse aspecto, pois o número de séries temporais não afeta mais o desempenho geral do servidor (consulte. ). No entanto, o Prometheus armazena dados no disco local. Embora a compactação de dados de alta eficiência possa reduzir significativamente o uso de SSD local, ainda há um limite para a quantidade de dados históricos que podem ser armazenados.
Além disso, na Improbable nos preocupamos com confiabilidade, simplicidade e custo. Discos locais grandes são mais difíceis de operar e fazer backup. Eles custam mais e exigem mais ferramentas de backup, resultando em complexidade desnecessária.
Redução da resolução
Assim que começamos a trabalhar com dados históricos, percebemos que existem dificuldades fundamentais com o big-O que tornam as consultas cada vez mais lentas à medida que trabalhamos com semanas, meses e anos de dados.
A solução padrão para esse problema seria (downsampling) - reduzindo a frequência de amostragem do sinal. Com a redução da resolução, podemos “reduzir” para um intervalo de tempo maior e manter o mesmo número de amostras, mantendo as consultas responsivas.
A redução da resolução de dados antigos é um requisito inevitável de qualquer solução de armazenamento de longo prazo e está além do escopo do vanilla Prometheus.
Metas adicionais
Um dos objetivos originais do projeto Thanos era integrar-se perfeitamente a quaisquer instalações existentes do Prometheus. O segundo objetivo era a facilidade de operação com barreiras mínimas de entrada. Quaisquer dependências devem ser facilmente satisfeitas para usuários pequenos e grandes, o que também significa um baixo custo base.
Arquitetura de Thanos
Depois de listar nossos objetivos na seção anterior, vamos trabalhar neles e ver como Thanos resolve esses problemas.
Visão global
Para obter uma visão global das instâncias existentes do Prometheus, precisamos vincular um único ponto de entrada de solicitação a todos os servidores. Isto é exatamente o que o componente Thanos faz. . Ele é implantado próximo a cada servidor Prometheus e atua como um proxy, servindo dados locais do Prometheus por meio da API gRPC Store, permitindo que dados de série temporal sejam recuperados por tag e intervalo de tempo.
Do outro lado está o componente Querier escalonável e sem estado, que faz pouco mais do que apenas responder a consultas PromQL por meio da API HTTP padrão do Prometheus. Querier, Sidecar e outros componentes do Thanos se comunicam via .
- O Querier, ao receber uma solicitação, se conecta ao servidor Store API correspondente, ou seja, aos nossos Sidecars e recebe dados de série temporal dos servidores Prometheus correspondentes.
- Depois disso, ele combina as respostas e executa uma consulta PromQL sobre elas. O Querier pode mesclar dados separados e dados duplicados de servidores Prometheus HA.
Isso resolve uma peça importante do nosso quebra-cabeça: combinar dados de servidores Prometheus isolados em uma única visualização. Na verdade, Thanos só pode ser usado para esse recurso. Nenhuma alteração precisa ser feita nos servidores Prometheus existentes!
Prazo de validade ilimitado!
No entanto, mais cedo ou mais tarde, desejaremos armazenar dados além do tempo normal de retenção do Prometheus. Escolhemos o armazenamento de objetos para armazenar dados históricos. Ele está amplamente disponível em qualquer nuvem, bem como em data centers locais, e é muito econômico. Além disso, quase todo armazenamento de objetos está disponível por meio da conhecida API S3.
O Prometheus grava dados da RAM no disco aproximadamente a cada duas horas. O bloco de dados armazenado contém todos os dados por um período fixo de tempo e é imutável. Isso é muito conveniente porque o Thanos Sidecar pode simplesmente consultar o diretório de dados do Prometheus e, à medida que novos blocos ficam disponíveis, carregá-los em depósitos de armazenamento de objetos.
Carregar no armazenamento de objetos imediatamente após gravar no disco também permite manter a simplicidade do raspador (Prometheus e Thanos Sidecar). O que simplifica o suporte, o custo e o design do sistema.
Como você pode ver, o backup de dados é muito simples. Mas e quanto à consulta de dados no armazenamento de objetos?
O componente Thanos Store atua como um proxy para recuperar dados do armazenamento de objetos. Assim como Thanos Sidecar, ele participa do cluster de fofocas e implementa a API Store. Dessa forma, o Querier existente pode tratá-lo como um Sidecar, como outra fonte de dados de série temporal - sem necessidade de configuração especial.
Os blocos de dados de série temporal consistem em vários arquivos grandes. Carregá-los sob demanda seria bastante ineficiente e armazená-los em cache local exigiria uma enorme quantidade de memória e espaço em disco.
Em vez disso, o Store Gateway sabe como lidar com o formato de armazenamento Prometheus. Graças a um agendador de consultas inteligente e ao armazenamento em cache apenas das partes de índice necessárias dos blocos, é possível reduzir consultas complexas a um número mínimo de solicitações HTTP para arquivos de armazenamento de objetos. Dessa forma, você pode reduzir o número de solicitações em quatro a seis ordens de magnitude e obter tempos de resposta que geralmente são difíceis de distinguir das solicitações de dados em um SSD local.
Conforme mostrado no diagrama acima, Thanos Querier reduz significativamente o custo por consulta de dados de armazenamento de objetos, aproveitando o formato de armazenamento Prometheus e colocando os dados relacionados lado a lado. Usando esta abordagem, podemos combinar muitas solicitações únicas em um número mínimo de operações em massa.
Compactação e redução da resolução
Depois que um novo bloco de dados de série temporal é carregado com sucesso no armazenamento de objetos, nós o tratamos como dados “históricos”, que ficam imediatamente disponíveis por meio do Store Gateway.
Porém, depois de algum tempo, os blocos de uma fonte (Prometheus com Sidecar) se acumulam e não utilizam mais todo o potencial de indexação. Para resolver este problema, introduzimos outro componente chamado Compactor. Ele simplesmente aplica o mecanismo de compactação local do Prometheus aos dados históricos no armazenamento de objetos e pode ser executado como um simples trabalho em lote periódico.
Graças à compactação eficiente, consultar o armazenamento durante um longo período de tempo não representa um problema em termos de tamanho dos dados. No entanto, o custo potencial de descompactar um bilhão de valores e executá-los por meio de um processador de consultas resultará inevitavelmente em um aumento dramático no tempo de execução da consulta. Por outro lado, como existem centenas de pontos de dados por pixel na tela, torna-se impossível até mesmo visualizar os dados em resolução total. Assim, a redução da resolução não só é possível, mas também não levará a uma perda perceptível de precisão.
Para reduzir a resolução dos dados, o Compactor agrega dados continuamente com uma resolução de cinco minutos e uma hora. Para cada pedaço bruto codificado usando a compactação TSDB XOR, diferentes tipos de dados agregados são armazenados, como mínimo, máximo ou soma para um bloco. Isso permite que o Querier selecione automaticamente um agregado apropriado para uma determinada consulta PromQL.
Nenhuma configuração especial é necessária para que o usuário utilize dados de precisão reduzida. O Querier alterna automaticamente entre diferentes resoluções e dados brutos conforme o usuário aumenta e diminui o zoom. Se desejar, o usuário pode controlar isso diretamente através do parâmetro “step” na solicitação.
Como o custo de armazenamento de um GB é baixo, por padrão o Thanos armazena dados brutos, dados com resolução de cinco minutos e uma hora. Não há necessidade de excluir os dados originais.
Regras de gravação
Mesmo com Thanos, as regras de gravação são uma parte essencial da pilha de monitoramento. Eles reduzem a complexidade, a latência e o custo das consultas. Eles também são convenientes para os usuários obterem dados agregados por métricas. Thanos é baseado em instâncias vanilla do Prometheus, portanto, é perfeitamente aceitável armazenar regras de gravação e regras de alerta em um servidor Prometheus existente. No entanto, em alguns casos isso pode não ser suficiente:
- Alerta e regra globais (por exemplo, um alerta quando um serviço não funciona em mais de dois dos três clusters).
- Regra para dados fora do armazenamento local.
- O desejo de armazenar todas as regras e alertas em um só lugar.
Para todos esses casos, Thanos inclui um componente separado chamado Ruler, que calcula regras e alertas por meio de consultas Thanos. Ao fornecer uma StoreAPI bem conhecida, o nó Query pode acessar métricas recentemente calculadas. Posteriormente também são armazenados em object storage e disponibilizados através do Store Gateway.
O poder de Thanos
Thanos é flexível o suficiente para ser personalizado para atender às suas necessidades. Isso é especialmente útil ao migrar do Prometheus simples. Vamos recapitular rapidamente o que aprendemos sobre os componentes do Thanos com um exemplo rápido. Veja como levar seu Prometheus vanilla para o mundo do “armazenamento ilimitado de métricas”:
- Adicione Thanos Sidecar aos seus servidores Prometheus – por exemplo, um contêiner sidecar em um pod Kubernetes.
- Implante várias réplicas do Thanos Querier para poder visualizar dados. Nesta fase é fácil estabelecer fofoca entre Scraper e Querier. Para verificar a interação dos componentes, use a métrica 'thanos_cluster_members'.
Apenas essas duas etapas são suficientes para fornecer visão global e desduplicação contínua de dados de possíveis réplicas de alta disponibilidade do Prometheus! Basta conectar seus painéis ao endpoint HTTP do Querier ou usar a UI do Thanos diretamente.
No entanto, se precisar de backup de métricas e armazenamento de longo prazo, você precisará concluir mais três etapas:
- Crie um bucket AWS S3 ou GCS. Configure o Sidecar para copiar dados para esses buckets. O armazenamento local de dados agora pode ser minimizado.
- Implante o Store Gateway e conecte-o ao seu cluster de fofocas existente. Agora você pode consultar os dados de backup!
- Implante o Compactor para melhorar a eficiência da consulta durante longos períodos usando compactação e redução da resolução.
Se você quiser saber mais, não hesite em dar uma olhada em nosso и !
Em apenas cinco etapas, transformamos o Prometheus em um sistema de monitoramento confiável com visão global, tempo de armazenamento ilimitado e alta disponibilidade potencial de métricas.
Solicitação pull: precisamos de você!
tem sido um projeto de código aberto desde o início. A integração perfeita com o Prometheus e a capacidade de usar apenas uma parte do Thanos o tornam uma excelente escolha para dimensionar seu sistema de monitoramento sem esforço.
Sempre recebemos solicitações e problemas pull do GitHub. Enquanto isso, sinta-se à vontade para nos contatar via Github Issues ou Slackse você tiver dúvidas ou comentários, ou quiser compartilhar sua experiência com ele! Se gosta do que fazemos na Improbable, não hesite em contactar-nos - !
Fonte: habr.com