{"id":81888,"date":"2020-05-17T13:42:23","date_gmt":"2020-05-17T11:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus"},"modified":"2020-05-17T13:42:23","modified_gmt":"2020-05-17T11:42:23","slug":"thanos-masshtabiruemyj-prometheus","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus","title":{"rendered":"Thanos \u2014 um Prometheus escal\u00e1vel.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A tradu\u00e7\u00e3o do artigo foi preparada especialmente para os alunos do curso \u00abPr\u00e1ticas e Ferramentas DevOps\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\nFabian Reinartz<\/a><\/noindex> \u2014 desenvolvedor de software, entusiasta de Go e amante de resolver problemas complexos. Tamb\u00e9m \u00e9 mantenedor do Prometheus e cofundador do Kubernetes SIG instrumentation. No passado, foi engenheiro de produ\u00e7\u00e3o no SoundCloud e liderou o grupo de monitoramento na CoreOS. Atualmente, trabalha no Google.<\/p>\n

Bartek Plotka<\/a><\/noindex> \u2014 engenheiro de infraestrutura na Improbable. \u00c9 apaixonado por novas tecnologias e desafios em sistemas distribu\u00eddos. Tem experi\u00eancia em programa\u00e7\u00e3o de baixo n\u00edvel na Intel, experi\u00eancia como contribuinte no Mesos e experi\u00eancia em SRE em escala mundial na Improbable. Est\u00e1 focado em melhorar o mundo dos microsservi\u00e7os. Suas tr\u00eas paix\u00f5es: Golang, c\u00f3digo aberto e v\u00f4lei.<\/i><\/p>\n

Olhando para nosso produto flagship SpatialOS, voc\u00ea pode imaginar que a Improbable precisa de uma infraestrutura de nuvem de alta din\u00e2mica em escala global com dezenas de clusters Kubernetes. Fomos um dos primeiros a come\u00e7ar a usar o sistema de monitoramento Prometheus<\/a><\/noindex>. O Prometheus \u00e9 capaz de monitorar milh\u00f5es de m\u00e9tricas em tempo real e vem com uma poderosa linguagem de consulta que permite extrair as informa\u00e7\u00f5es necess\u00e1rias.<\/p>\n

A simplicidade e confiabilidade do Prometheus \u00e9 uma de suas principais vantagens. No entanto, ao passar por uma certa escala, encontramos algumas desvantagens. Para resolver esses problemas, desenvolvemos Thanos<\/a><\/noindex> \u2014 um projeto de c\u00f3digo aberto criado pela Improbable, para a transforma\u00e7\u00e3o sem costura de clusters existentes do Prometheus em um \u00fanico sistema de monitoramento com armazenamento ilimitado de dados hist\u00f3ricos. O Thanos est\u00e1 dispon\u00edvel no Github aqui<\/a><\/noindex>.<\/a><\/noindex><\/p>\n

Fique por dentro das \u00faltimas not\u00edcias da Improbable.<\/a><\/noindex><\/p>\n

Nossos objetivos com o Thanos<\/h2>\n

\nEm uma certa escala, surgem problemas que v\u00e3o al\u00e9m das capacidades do Prometheus vanilla. Como armazenar de forma confi\u00e1vel e econ\u00f4mica petabytes de dados hist\u00f3ricos? \u00c9 poss\u00edvel fazer isso sem comprometer o tempo de resposta das consultas? \u00c9 poss\u00edvel acessar todas as m\u00e9tricas localizadas em diferentes servidores Prometheus atrav\u00e9s de uma \u00fanica solicita\u00e7\u00e3o API? \u00c9 poss\u00edvel, de alguma forma, combinar dados replicados coletados com o Prometheus HA?<\/p>\n

Para responder a essas perguntas, criamos o Thanos. Nas se\u00e7\u00f5es a seguir, abordamos como enfrentamos essas quest\u00f5es e explicamos os objetivos que buscamos.<\/p>\n

Consulta de dados de v\u00e1rias inst\u00e2ncias do Prometheus (consulta global)<\/h4>\n

\nPrometheus oferece uma abordagem funcional para sharding. Mesmo um \u00fanico servidor Prometheus fornece escalabilidade suficiente para liberar os usu\u00e1rios das complexidades do sharding horizontal na maioria dos casos de uso.<\/p>\n

Embora este seja um excelente modelo de implanta\u00e7\u00e3o, frequentemente \u00e9 necess\u00e1rio acessar dados de diferentes servidores Prometheus por meio de uma \u00fanica API ou UI \u2014 vis\u00e3o global. Claro, \u00e9 poss\u00edvel exibir v\u00e1rias consultas em um \u00fanico painel Grafana, mas cada consulta s\u00f3 pode ser realizada em um servidor Prometheus. Por outro lado, com o Thanos, voc\u00ea pode consultar e agregar dados de v\u00e1rios servidores Prometheus, uma vez que todos est\u00e3o acess\u00edveis a partir de um \u00fanico endpoint.<\/p>\n

Anteriormente, para obter uma vis\u00e3o global na Improbable, organizamos nossas inst\u00e2ncias Prometheus em uma hierarquia de Federa\u00e7\u00e3o Hier\u00e1rquica<\/a><\/noindex>Isso significou a cria\u00e7\u00e3o de um meta-servidor Prometheus, que coleta parte das m\u00e9tricas de cada servidor \"leaf\".<\/p>\n

\"Thanos
\n
\nEssa abordagem se mostrou problem\u00e1tica. Ela resultou em uma configura\u00e7\u00e3o mais complicada, adicionando um ponto de falha potencial adicional e aplicando regras complexas para fornecer ao endpoint federado apenas os dados necess\u00e1rios. Al\u00e9m disso, federa\u00e7\u00f5es desse tipo n\u00e3o permitem obter uma verdadeira vis\u00e3o global, uma vez que nem todos os dados est\u00e3o dispon\u00edveis em uma \u00fanica solicita\u00e7\u00e3o de API.<\/p>\n

Isso est\u00e1 intimamente relacionado \u00e0 vis\u00e3o unificada dos dados coletados em servidores Prometheus de alta disponibilidade (high-availability, HA). O modelo HA do Prometheus coleta dados de forma independente duas vezes, sendo t\u00e3o simples que n\u00e3o poderia ser mais f\u00e1cil. No entanto, usar uma vis\u00e3o combinada e deduplicada de ambos os fluxos seria muito mais conveniente.<\/p>\n

Claro, existe a necessidade de servidores Prometheus de alta disponibilidade. Na Improbable, levamos a monitoriza\u00e7\u00e3o em tempo real de dados muito a s\u00e9rio, mas ter uma \u00fanica inst\u00e2ncia do Prometheus em um cluster \u00e9 um ponto \u00fanico de falha. Qualquer erro de configura\u00e7\u00e3o ou falha de hardware pode potencialmente resultar na perda de dados importantes. At\u00e9 mesmo uma implanta\u00e7\u00e3o simples pode levar a breves falhas na coleta de m\u00e9tricas, uma vez que um rein\u00edcio pode levar consideravelmente mais tempo do que o intervalo de raspagem.<\/p>\n

Armazenamento confi\u00e1vel de dados hist\u00f3ricos<\/h4>\n

\nUm armazenamento de m\u00e9tricas econ\u00f4mico, r\u00e1pido e de longo prazo \u00e9 o nosso sonho (compartilhado pela maioria dos usu\u00e1rios do Prometheus). Na Improbable, tivemos que configurar o per\u00edodo de reten\u00e7\u00e3o de m\u00e9tricas para nove dias (para o Prometheus 1.8). Isso imp\u00f5e limita\u00e7\u00f5es \u00f3bvias sobre o qu\u00e3o longe podemos olhar para tr\u00e1s.<\/p>\n

O Prometheus 2.0 melhorou nesse aspecto, pois a quantidade de s\u00e9ries temporais n\u00e3o afeta mais o desempenho geral do servidor (veja a apresenta\u00e7\u00e3o principal do KubeCon sobre o Prometheus 2<\/a><\/noindex>). No entanto, o Prometheus armazena dados no disco local. Embora uma Compress\u00e3o de Dados altamente eficiente possa reduzir significativamente o uso do SSD local, ainda assim existe um limite para a quantidade de dados hist\u00f3ricos armazenados.<\/p>\n

Al\u00e9m disso, na Improbable, nos preocupamos com confiabilidade, simplicidade e custo. Discos locais grandes s\u00e3o mais dif\u00edceis de operar e fazer backup. Eles s\u00e3o mais caros e requerem mais ferramentas para backup, resultando em complexidade excessiva.<\/p>\n

Downsampling<\/h4>\n

\nAssim que come\u00e7amos a trabalhar com dados hist\u00f3ricos, percebemos que existem complexidades fundamentais com O-grande, que tornam as consultas cada vez mais lentas se trabalharmos com dados de semanas, meses e anos.<\/p>\n

A solu\u00e7\u00e3o padr\u00e3o para esse problema \u00e9 downsampling<\/a><\/noindex> \u2014 reduzir a frequ\u00eancia de amostragem do sinal. Ao diminuir a amostragem, podemos 'ampliar' para um intervalo de tempo maior e manter o mesmo n\u00famero de amostras, o que ajuda a manter a responsividade das consultas.<\/p>\n

O downsampling de dados antigos \u00e9 um requisito inevit\u00e1vel de qualquer solu\u00e7\u00e3o de armazenamento de longo prazo e vai al\u00e9m do Prometheus vanilla.<\/p>\n

Objetivos adicionais<\/h4>\n

\nUm dos objetivos iniciais do projeto Thanos era a integra\u00e7\u00e3o perfeita com quaisquer instala\u00e7\u00f5es existentes do Prometheus. O segundo objetivo era uma opera\u00e7\u00e3o simples com uma barreira de entrada m\u00ednima. Quaisquer depend\u00eancias devem ser facilmente atendidas tanto para usu\u00e1rios pequenos quanto para grandes, implicando tamb\u00e9m um custo b\u00e1sico insignificante.<\/p>\n

Arquitetura do Thanos<\/h2>\n

\nDepois de listar nossos objetivos na se\u00e7\u00e3o anterior, vamos trabalhar neles e ver como o Thanos aborda esses desafios.<\/p>\n

Vis\u00e3o global<\/h4>\n

\nPara obter uma vis\u00e3o global sobre as inst\u00e2ncias existentes do Prometheus, precisamos conectar um \u00fanico ponto de entrada de solicita\u00e7\u00f5es a todos os servidores. \u00c9 exatamente isso que o componente Thanos faz. Sidecar<\/a><\/noindex>. Ele \u00e9 implantado ao lado de cada servidor Prometheus e atua como um proxy, atendendo aos dados locais do Prometheus atrav\u00e9s da interface gRPC Store API, que permite selecionar dados de s\u00e9ries temporais por r\u00f3tulos e intervalo de tempo.<\/p>\n

Do outro lado, temos o componente Querier, que \u00e9 escal\u00e1vel horizontalmente e sem estado, e que faz um pouco mais do que apenas responder a solicita\u00e7\u00f5es PromQL atrav\u00e9s da API HTTP padr\u00e3o do Prometheus. Os componentes Querier, Sidecar e outros do Thanos interagem por meio do protocolo gossip.<\/a><\/noindex>.<\/p>\n

\"Thanos
\n<\/p>\n

    \n
  1. Quando o Querier recebe uma solicita\u00e7\u00e3o, ele se conecta ao servidor correspondente da Store API, ou seja, aos nossos Sidecars, e obt\u00e9m os dados de s\u00e9ries temporais dos servidores Prometheus correspondentes.<\/li>\n
  2. Depois disso, ele combina as respostas e executa a consulta PromQL sobre elas. O Querier pode combinar dados que n\u00e3o se sobrep\u00f5em, bem como dados duplicados de servidores HA do Prometheus.<\/li>\n<\/ol>\n

    \nIsso resolve a maior parte do nosso quebra-cabe\u00e7a \u2014 combinar dados de servidores do Prometheus isolados em uma \u00fanica vis\u00e3o. De fato, o Thanos pode ser utilizado apenas por causa dessa capacidade. N\u00e3o s\u00e3o necess\u00e1rias altera\u00e7\u00f5es nos servidores Prometheus existentes!<\/p>\n

    Armazenamento ilimitado!<\/h4>\n

    \nNo entanto, mais cedo ou mais tarde, desejaremos armazenar dados que ultrapassam o per\u00edodo de reten\u00e7\u00e3o comum do Prometheus. Para o armazenamento de dados hist\u00f3ricos, escolhemos o armazenamento de objetos. Ele est\u00e1 amplamente dispon\u00edvel em qualquer nuvem, bem como em data centers locais e \u00e9 muito econ\u00f4mico. Al\u00e9m disso, praticamente qualquer armazenamento de objetos \u00e9 acess\u00edvel atrav\u00e9s da famosa API S3.<\/p>\n

    O Prometheus grava dados da mem\u00f3ria para o disco a cada duas horas. Um bloco de dados armazenados cont\u00e9m todos os dados para um intervalo de tempo fixo e \u00e9 imut\u00e1vel. Isso \u00e9 muito conveniente, pois o Thanos Sidecar pode simplesmente observar o diret\u00f3rio de dados do Prometheus e, \u00e0 medida que novos blocos aparecem, carreg\u00e1-los nos buckets do armazenamento de objetos.<\/p>\n

    \"Thanos
    \n
    \nFazer o upload para o armazenamento de objetos imediatamente ap\u00f3s a grava\u00e7\u00e3o no disco tamb\u00e9m permite manter a simplicidade do 'scraper' (Prometheus e Thanos Sidecar), o que simplifica a manuten\u00e7\u00e3o, o custo e o design do sistema.<\/p>\n

    Como voc\u00ea pode ver, o backup de dados \u00e9 implementado de forma muito simples. Mas e quanto \u00e0 consulta de dados em um armazenamento de objetos?<\/p>\n

    O componente Thanos Store atua como um proxy para a obten\u00e7\u00e3o de dados do armazenamento de objetos. Assim como o Thanos Sidecar, ele participa do cluster gossip e implementa a API Store. Assim, os Querier existentes podem v\u00ea-lo como um Sidecar, como outra fonte de dados de s\u00e9ries temporais \u2014 nenhuma configura\u00e7\u00e3o especial \u00e9 necess\u00e1ria.<\/p>\n

    \"Thanos
    \n
    \nOs blocos de dados de s\u00e9ries temporais consistem em v\u00e1rios arquivos grandes. Carreg\u00e1-los sob demanda seria bastante ineficiente, e o cache local exigiria uma enorme quantidade de mem\u00f3ria e espa\u00e7o de armazenamento.<\/p>\n

    Em vez disso, o Store Gateway sabe como lidar com o formato de armazenamento do Prometheus. Gra\u00e7as a um planejador de consultas inteligente e ao cache apenas das partes de \u00edndice necess\u00e1rias dos blocos, foi poss\u00edvel reduzir consultas complexas ao m\u00ednimo de solicita\u00e7\u00f5es HTTP para os arquivos do armazenamento de objetos. Assim, o n\u00famero de solicita\u00e7\u00f5es pode ser reduzido em quatro a seis ordens de magnitude e alcan\u00e7ar um tempo de resposta que \u00e9, em geral, dif\u00edcil de distinguir das consultas de dados em um SSD local.<\/p>\n

    \"Thanos
    \n
    \nComo mostrado no diagrama acima, o Thanos Querier reduz significativamente o custo por consulta de dados no armazenamento de objetos, utilizando o formato de armazenamento do Prometheus e colocando dados relacionados pr\u00f3ximos uns dos outros. Usando essa abordagem, podemos combinar v\u00e1rias solicita\u00e7\u00f5es individuais em um n\u00famero m\u00ednimo de opera\u00e7\u00f5es em lote.<\/p>\n

    Compacta\u00e7\u00e3o e downsampling<\/h4>\n

    \nDepois que um novo bloco de dados de s\u00e9ries temporais \u00e9 carregado com sucesso no armazenamento de objetos, o consideramos como dados \"hist\u00f3ricos\", que imediatamente se tornam dispon\u00edveis atrav\u00e9s do Store Gateway.<\/p>\n

    No entanto, ap\u00f3s algum tempo, os blocos de uma fonte (Prometheus com Sidecar) se acumulam e j\u00e1 n\u00e3o utilizam todo o potencial de indexa\u00e7\u00e3o. Para resolver esse problema, introduzimos mais um componente chamado Compactor. Ele simplesmente aplica o mecanismo de compacta\u00e7\u00e3o local do Prometheus aos dados hist\u00f3ricos no armazenamento de objetos e pode ser executado como uma simples tarefa em lote peri\u00f3dica.<\/p>\n

    \"Thanos
    \n
    \nGra\u00e7as \u00e0 compacta\u00e7\u00e3o eficiente, uma solicita\u00e7\u00e3o ao armazenamento por um longo per\u00edodo de tempo n\u00e3o apresenta problemas em termos de tamanho de dados. No entanto, o custo potencial de descompactar bilh\u00f5es de valores e process\u00e1-los atrav\u00e9s do manipulador de consultas inevitavelmente levar\u00e1 a um aumento acentuado no tempo de execu\u00e7\u00e3o da consulta. Por outro lado, como cada pixel da tela corresponde a centenas de pontos de dados, torna-se imposs\u00edvel at\u00e9 mesmo visualizar os dados em plena resolu\u00e7\u00e3o. Assim, o downsampling n\u00e3o s\u00f3 \u00e9 vi\u00e1vel, mas tamb\u00e9m n\u00e3o resultar\u00e1 em uma perda significativa de precis\u00e3o. <\/p>\n

    \"Thanos
    \n
    \nPara o downsampling de dados, o Compactor agrega continuamente dados com resolu\u00e7\u00e3o de cinco minutos e uma hora. Para cada fragmento bruto codificado com compacta\u00e7\u00e3o TSDB XOR, diferentes tipos de dados agregados s\u00e3o armazenados, como min, max ou sum para um bloco. Isso permite que o Querier selecione automaticamente a agrega\u00e7\u00e3o que se adapta \u00e0 consulta PromQL dada. <\/p>\n

    Para usar dados com menor precis\u00e3o, o usu\u00e1rio n\u00e3o precisa de nenhuma configura\u00e7\u00e3o especial. O Querier alterna automaticamente entre diferentes resolu\u00e7\u00f5es e dados brutos \u00e0 medida que o usu\u00e1rio aumenta ou diminui o zoom. Se desejado, o usu\u00e1rio pode gerenciar isso diretamente atrav\u00e9s do par\u00e2metro \u201cstep\u201d na consulta. <\/p>\n

    Como o custo de armazenamento de um GB \u00e9 pequeno, por padr\u00e3o o Thanos armazena dados brutos, dados com resolu\u00e7\u00e3o de cinco minutos e uma hora. N\u00e3o h\u00e1 necessidade de excluir dados brutos.<\/p>\n

    Regras de grava\u00e7\u00e3o<\/h2>\n

    \nMesmo com o Thanos, as regras de grava\u00e7\u00e3o s\u00e3o uma parte essencial da pilha de monitoramento. Elas reduzem a complexidade, a lat\u00eancia e o custo das consultas. Tamb\u00e9m s\u00e3o convenientes para os usu\u00e1rios que desejam obter dados agregados por m\u00e9tricas. O Thanos baseia-se em inst\u00e2ncias vanilla do Prometheus, portanto, \u00e9 perfeitamente aceit\u00e1vel armazenar regras de grava\u00e7\u00e3o e regras de alerta no servidor Prometheus existente. No entanto, em alguns casos, isso pode n\u00e3o ser suficiente:<\/p>\n