Olá a todos. Abaixo está a transcrição .
– um sistema de monitorização de diversos sistemas e serviços, com o qual os administradores de sistemas podem recolher informações sobre os parâmetros atuais dos sistemas e configurar alertas para receber notificações sobre desvios no funcionamento dos sistemas.
O relatório incluirá uma comparação и — projetos para armazenamento de longo prazo de métricas do Prometheus.
Primeiro, vou falar sobre Prometeu. Este é um sistema de monitoramento que coleta métricas de alvos especificados e as salva no armazenamento local. O Prometheus pode registrar métricas em armazenamento remoto e gerar alertas e regras de gravação.
Limitações do Prometeu:
- Não possui uma visualização de consulta global. É quando você tem várias instâncias independentes do prometheus. Eles coletam métricas. E você deseja consultar todas essas métricas coletadas de diferentes instâncias do Prometheus. Prometeu não permite isso.
- Com o prometheus, o desempenho é limitado a apenas um servidor. O Prometheus não é dimensionado automaticamente em vários servidores. Você só pode dividir manualmente seus alvos entre vários Prometheus.
- O escopo das métricas no Prometheus é limitado a apenas um servidor pelo mesmo motivo que não pode ser dimensionado automaticamente em vários servidores.
- Não é tão fácil organizar a segurança dos dados no Prometheus.
Soluções para esses problemas/desafios?
As soluções são:
Todas essas soluções são para armazenamento remoto dos dados coletados pelo Prometheus. Eles resolvem o problema de armazenamento remoto do slide anterior de diferentes maneiras. Nesta apresentação falarei apenas sobre as duas primeiras soluções: и .
Pela primeira vez informações sobre apareceu por . A arquitetura é descrita lá e como funciona.
Thanos pega os dados que o Prometheus salvou no disco local e os copia para o S3, para ou para outro armazenamento de objetos.
Assim, Thanos fornece uma visão de consulta global. Você pode consultar dados armazenados no armazenamento de objetos de várias instâncias do Prometheus.
Thanos suporta PromQL e .
Thanos usa código Prometheus para armazenar dados.
Thanos é desenvolvido pelos mesmos desenvolvedores do Prometheus.
Про . Aqui , onde falamos pela primeira vez sobre .
VictoriaMetrics recebe dados de vários prometheus protocolo suportado pelo Prometheus.
VictoriaMetrics fornece uma visualização de consulta global, uma vez que várias instâncias do Prometheus podem gravar dados em um VictoriaMetrics. Dessa forma, você pode fazer consultas sobre todos esses dados.
VictoriaMetrics também oferece suporte, como Thanos, PromQL e Prometheus, API de consulta.
Ao contrário do Thanos, o código-fonte do VictoriaMetrics é escrito do zero e otimizado para velocidade e consumo de recursos.
VictoriaMetrics, ao contrário de Thanos, é dimensionado vertical e horizontalmente. Comer , que é dimensionado verticalmente. Você pode começar com um processador e 1 GB de memória e crescer gradualmente até centenas de processadores e 1 TB de memória. VictoriaMetrics pode usar todos esses recursos. Seu desempenho aumentará cerca de 100 vezes em comparação com um sistema de 1 núcleo.
A história de Thanos começou em novembro de 2017, quando apareceu o primeiro commit público. Antes disso, Thanos foi desenvolvido internamente .
Em junho de 2019, houve um lançamento histórico 0.5.0, no qual protocolo. Ele foi removido de Thanos porque não teve um bom desempenho. Freqüentemente, o cluster Thanos não funcionava corretamente, os nós se conectavam incorretamente a ele devido ao protocolo de fofoca. Portanto, decidimos retirá-lo de lá. Acho que esta é a decisão certa.
No mesmo mês de junho de 2019, enviaram o número do pedido в .
E depois de alguns meses Thanos foi aceito , que inclui Prometheus, Kubernetes e outros projetos populares.
Em janeiro de 2018, teve início o desenvolvimento do VictoriaMetrics.
Em setembro de 2018, mencionei publicamente a VictoriaMetrics pela primeira vez.
Em dezembro de 2018, foi publicada uma versão de nó único.
Em maio 2019 fontes de versões de nó único e de cluster.
Em junho de 2019, tal como Thanos, submetemos uma candidatura à fundação CNCF sob o número . Nós nos inscrevemos um dia antes de Thanos se inscrever.
Mas, infelizmente, ainda não fomos aceitos lá. É necessária ajuda comunitária.
Vejamos os slides mais importantes que mostram a arquitetura de Thanos e VictoriaMetrics.
Vamos começar com Thanos. Os componentes amarelos são componentes do Prometheus. Todo o resto são componentes do Thanos. Vamos começar com o componente mais importante. Thanos Sidecar é um componente instalado próximo a cada Prometheus. Ele carrega dados do Prometheus do armazenamento local no S3 ou em outro Object Storage.
Há também um componente chamado Thanos Store Gateway, que pode ler esses dados do Object Storage mediante solicitações recebidas do Thanos Query. Thanos Query implementa API PromQL e Prometheus. Ou seja, visto de fora parece Prometeu. Recebe consultas PromQL, envia-as para o Thanos Store Gateway, o Thanos Store Gateway recupera os dados necessários do Object Storage e os envia de volta.
Mas armazenamos dados no Object Storage sem as últimas duas horas devido a um recurso da implementação do Thanos Sidecar, que não pode fazer upload das últimas duas horas para o Object Storage S3, pois o Prometheus ainda não criou arquivos para essas duas horas no armazenamento local.
Como você decidiu contornar isso? O Thanos Query, além das solicitações ao Thanos Store Gateway, envia solicitações paralelas para cada Thanos Sidecar, que está localizado próximo ao Prometheus.
E Thanos Sidecar, por sua vez, faz proxy de solicitações adicionais para o Prometheus e recupera dados das últimas duas horas.
Além desses componentes, há também um componente opcional sem o qual Thanos não terá um bom desempenho. Este é o Thanos Compact, responsável por mesclar arquivos pequenos no Object Storage em arquivos maiores que foram carregados aqui pelo Thanos Sidecars. Thanos Sidecar carrega arquivos de dados lá em duas horas. Esses arquivos, se não forem mesclados em arquivos maiores, seu número poderá crescer significativamente. Quanto mais arquivos desse tipo, mais memória será necessária para o Thanos Store Gateway e mais recursos serão necessários para transferir dados pela rede e metadados. Thanos Store Gateway torna-se ineficaz. Portanto, é necessário executar o Thanos Compact, que mescla arquivos pequenos em arquivos maiores, para que haja menos arquivos desse tipo e para reduzir a sobrecarga no Thanos Store Gateway.
Existe também um componente como Thanos Ruler. Ele executa regras de alerta do Prometheus e pode avaliar as regras de gravação do Prometheus para gravar dados de volta no Object Storage. Mas este componente não é recomendado para uso, porque... Ele .
Este é o esquema simples de Thanos.
Agora vamos compará-lo com o esquema VictoriaMetrics.
VictoriaMetrics tem 2 versões: versão de nó único e versão de cluster. O nó único é executado em um computador. O nó único não possui esses componentes, apenas um binário. Este binário no slide se parece com este quadrado. Tudo o que está dentro do quadrado é o conteúdo do arquivo binário da versão de nó único. Você não precisa saber sobre ele. Basta executar o binário e tudo funciona para nós.
A versão cluster é mais complicada. Dentro dele existem três componentes diferentes: vmselect, vminsert e vmstorage. Pelo nome deles deve ficar claro o que cada um deles faz. O componente Insert aceita dados em diferentes formatos: da API de gravação remota do Prometheus, do protocolo de linha Influx, do protocolo Graphite e do protocolo OpenTSDB. O componente Insert os aceita, analisa e distribui entre os componentes de armazenamento existentes, onde os dados já estão armazenados. O componente Select, por sua vez, aceita consultas PromQL. Ele implementa , bem como a API de consulta do Prometheus, e pode ser usado como um substituto do Prometheus no Grafana ou em outros clientes da API do Prometheus. Select aceita uma solicitação promql, analisa-a, lê os dados necessários para executar esta solicitação dos nós de armazenamento, processa esses dados e retorna uma resposta.
Vamos comparar a complexidade da instalação do Thanos e do VictoriaMetrics.
Vamos começar com Thanos. Antes de começar a trabalhar com Thanos, você precisa criar um bucket no Object Storage, como S3 ou GCS, para que Thanos Sidecar possa gravar dados nele.
Então, para cada Prometheus, você precisa instalar o Thanos Sidecar. Antes disso, você precisa se lembrar de desabilitar a compactação de dados no Prometheus. A compactação de dados compacta periodicamente os dados no armazenamento local do Prometheus para reduzir o consumo de recursos.
Ao instalar o Thanos Sidecar em seu Prometheus, você deve desabilitar essa compactação de dados, pois o Thanos Sidecar não funciona corretamente com a compactação de dados habilitada. Isso significa que o Prometheus começa a salvar dados em blocos de duas horas e para de mesclar esses blocos em blocos maiores. Da mesma forma, se você fizer consultas que excedam a duração das últimas duas horas, elas não funcionarão com a mesma eficiência que funcionariam se a compactação de dados estivesse habilitada.
Portanto, Thanos recomenda reduzir o tempo de retenção de dados no armazenamento local para 6 a 8 horas, a fim de reduzir a sobrecarga de um grande número de pequenos blocos.
Depois de instalar o Thanos Sidecar, você deve instalar dois componentes para cada Object Storage Bucket. Estes são o Thanos Compactor e o Thanos Store Gateway.
Depois disso, você precisa instalar o Thanos Query e configurá-lo para que ele possa se conectar a todos os Thanos Store Gateways que você possui e também a todos os Thanos Sidecars.
Pode haver um pequeno problema aqui.
Você precisa configurar uma conexão confiável e segura do Thanos Query para esses componentes. E se o seu Prometheus estiver localizado em data centers diferentes ou em VPCs diferentes, as conexões externas com eles serão proibidas. Mas para que o Thanos Query funcione, você precisa configurar de alguma forma a conexão lá e descobrir uma maneira.
Se você tiver muitos desses data centers, a confiabilidade de todo o sistema diminuirá. Já o Thanos Query deve manter constantemente conexões com todos os Thanos Sidecars localizados em diferentes data centers. Para cada solicitação recebida, ele encaminhará as solicitações para todos os Thanos Sidecars. Se a conexão for interrompida, você receberá um conjunto incompleto de dados ou uma resposta “cluster inativo”.
No VictoriaMetrics tudo é um pouco mais simples. Para a versão de nó único, você só precisa executar um binário e tudo funciona.
Na versão cluster, basta executar todos os três tipos de componentes acima na quantidade que você precisar, ou usar para automatizar o lançamento de componentes no Kubernetes. Também estamos planejando criar um operador Kubernetes. O gráfico do Helm não cobre alguns casos e permite que você dê um tiro no próprio pé. Por exemplo, permite reduzir o número de nós de armazenamento, o que levará à perda de dados.
Depois de lançar uma versão binária ou em cluster, você só precisa adicionar o Prometheus à configuração para que comece a gravar dados em paralelo ao armazenamento local e ao armazenamento remoto. Como você pode ver, esta configuração deve funcionar de forma muito mais confiável em comparação com a configuração do Thanos. Não precisamos manter uma conexão do VictoriaMetrics com todos os Prometheus, porque os próprios Prometheus se conectam ao VictoriaMetrics e transmitem dados.
Consideremos o apoio de Thanos e VictoriaMetrics.
Thanos precisa monitorar o Sidecar para garantir que eles não parem de carregar dados no Object Storage. Eles podem interromper o download de dados devido a erros de download, por exemplo, sua conexão de rede com o Object Storage foi temporariamente interrompida ou o Object Storage está temporariamente indisponível. Thanos Sidecar perceberá isso neste momento, reportará um erro, poderá travar e parar de funcionar. Se você não monitorá-lo, interromperá a transferência de dados para o Object Storage. Se o tempo de retenção passar (6 a 8 horas recomendado), você perderá dados que não foram parar no Object Storage.
Os compactadores Thanos podem parar de funcionar devido a . Os compactadores pegam dados do Object Storage e os mesclam em pedaços maiores de dados. Como os compactadores não estão sincronizados com os Sidecars, pode acontecer o seguinte: o Sidecar ainda não teve tempo de completar o bloco, o Compactor decide que este bloco foi totalmente escrito. O Compactor começa a lê-lo. Ele não lê o bloco por completo e para de funcionar. Veja detalhes .
O Store Gateway pode retornar dados inconsistentes devido a corridas entre Compactor e Sidecars. A mesma coisa acontece aqui, pois o Store Gateway não está sincronizado de forma alguma com Compactadores e Sidecars. Conseqüentemente, condições de corrida podem ocorrer quando o Store Gateway não vê parte dos dados ou vê dados desnecessários.
O componente Query no Thanos por padrão retorna um resultado parcial se alguns Sidecars ou Store Gateways não estiverem disponíveis no momento. Você receberá parte dos dados e nem saberá que não recebeu todos os dados. É assim que funciona por padrão. Numa situação semelhante, VictoriaMetrics retorna dados marcados como parciais.
Ao contrário de Thanos, VictoriaMetrics raramente perde dados. Mesmo que a conexão do Prometheus com o VictoriaMetrics seja interrompida, isso não é um problema, pois o Prometheus continua registrando novos dados recebidos no Write Ahead Log, cujo tamanho é de 2 horas. Se você restaurar sua conexão com VictoriaMetrics dentro de duas horas, seus dados não serão perdidos. Prometeu .
Ao contrário do Thanos, que grava dados no armazenamento de objetos somente após duas horas, o Prometheus replica automaticamente os dados usando o protocolo de gravação remota para armazenamento remoto, como o VictoriaMetrics. Você não tem medo de perder o armazenamento local no Prometheus. Se ele perder repentinamente o armazenamento local, na pior das hipóteses você perderá os últimos segundos de dados que não tiveram tempo de serem gravados no armazenamento remoto.
O Kubernetes gerencia automaticamente o cluster, ao contrário do Thanos. É difícil colocar todos os componentes do Thanos em um cluster Kubernetes, ao contrário dos componentes do cluster VictoriaMetrics.
VictoriaMetrics tem uma atualização muito simples para a nova versão. Basta parar o VictoriaMetrics, atualizar os binários e iniciá-lo. Quando parados por meio de um sinal SIGINT, todos os binários VictoriaMetrics executam um desligamento normal. Eles salvam corretamente os dados necessários, fecham corretamente as conexões de entrada para não perder nada. Assim você não perderá nada ao atualizar.
VictoriaMetrics torna muito fácil expandir um cluster. Basta adicionar os componentes necessários e continuar trabalhando.
Sobre armadilhas em Thanos e VictoriaMetrics.
Thanos tem as seguintes armadilhas. O Prometheus deve armazenar dados das últimas duas horas. Se eles se perderem, você os perderá completamente porque eles ainda não foram gravados no Object Storage como o S3.
O componente Store Gateway e o componente compactador podem exigir muita memória para funcionar com um Object Storage grande se houver muitos arquivos pequenos armazenados nele. Quanto maior o número e o tamanho dos arquivos, mais gateway de armazenamento e RAM compactadora serão necessários para armazenar metainformações. Thanos tem muitos problemas em relação ao fato de que .
Thanos é anunciado para escalar indefinidamente com a quantidade de Prometheus que você possui. Na verdade, isso não é verdade. Como todas as solicitações passam pelo componente Query, que deve pesquisar simultaneamente todos os componentes do Store Gateway e todos os componentes Sidecar, extrair dados de lá e pré-processá-los. Obviamente, a velocidade da solicitação é limitada pelo elo mais fraco, pelo Store Gateway mais lento ou pelo Sidecar mais lento.
Esses componentes podem estar carregados de forma desigual. Por exemplo, você tem o Prometheus, que coleta milhões de métricas por segundo. E há o Prometheus, que coleta milhares de métricas por segundo. O Prometheus, que coleta milhões de métricas por segundo, coloca uma carga muito maior no servidor em que é executado. Conseqüentemente, o Sidecar funciona mais devagar lá. E em geral tudo funciona devagar aí. E o componente Query extrairá dados de lá muito lentamente. Conseqüentemente, o desempenho de todo o seu cluster será limitado por este Sidecar lento.
Por padrão, Thanos fornece dados parciais se alguns Sidecars e o Store Gateway não estiverem disponíveis. Por exemplo, se seus Sidecars estiverem espalhados pelo mundo em diferentes data centers, a probabilidade de falha de conexão e indisponibilidade de componentes aumenta muito. Conseqüentemente, na maioria dos casos você receberá dados parciais, mesmo sem saber.
VictoriaMetrics também tem armadilhas. A primeira armadilha é a opção que limita a quantidade de RAM usada para o cache VictoriaMetrics. Por padrão, é igual a 60% da RAM na máquina onde o VictoriaMetrics está sendo executado ou 60% da RAM do pod VictoriaMetrics no Kubernetes.
Se você alterar esse valor incorretamente, poderá prejudicar o desempenho do VictoriaMetrics. Por exemplo, se você definir um valor muito baixo, os dados poderão não caber mais no cache VictoriaMetrics. Por causa disso, ela terá que fazer um trabalho extra e carregar o processador e o disco. Se você tornar esta opção muito grande, aumentará, em primeiro lugar, a probabilidade de o VictoriaMetrics travar com um erro de falta de memória e, em segundo lugar, levará ao fato de que restará muito pouca RAM na memória do sistema operacional para cache de arquivo. E VictoriaMetrics depende de um cache de arquivos para desempenho. Se não for suficiente, a carga no disco pode aumentar bastante. Portanto, conselho: não altere o parâmetro a menos que seja absolutamente necessário.
Segunda opçao. Este é otentionPeriod - um período definido como 1 mês por padrão. Este é o período de tempo que VictoriaMetrics armazena dados. Após este período, VictoriaMetrics elimina os dados.
Muitas pessoas executam o VictoriaMetrics sem esse parâmetro e registram dados por um mês. E aí perguntam: por que os dados do mês anterior desapareceram? Porque o período de retenção padrão é de 1 mês. Portanto, você precisa conhecer e definir o período de retenção correto.
Vamos dar uma olhada nos recursos exclusivos.
Thanos tem um recurso chamado downsampling: intervalos de 5 minutos e de hora em hora, que muitas vezes . Se você pesquisar no Google e analisar o problema no github, verá que há muitos problemas relacionados a essa redução da resolução, que às vezes não funciona corretamente ou não funciona como os usuários esperam.
Thanos possui desduplicação de dados para pares Prometheus HA. Quando dois Prometheus coletam as mesmas métricas dos mesmos alvos e Thanos as armazena no Object Storage. Thanos pode desduplicar adequadamente esses dados, ao contrário do VictoriaMetrics.
Thanos tem um componente de alerta que estava no esquema do Thanos. Mas ele .
Thanos tem a vantagem de Thanos e Prometheus compartilharem o mesmo código. Thanos e Prometheus são desenvolvidos pelos mesmos desenvolvedores. Com melhorias em Thanos ou Prometheus, o outro lado vence.
O principal recurso do VictoriaMetrics é o MetricsQL. Estas são extensões VictoriaMetrics para PromQL, sobre as quais falei no grande encontro de monitoramento anterior.
VictoriaMetrics oferece suporte ao carregamento de dados usando muitos protocolos diferentes. VictoriaMetrics pode aceitar dados não apenas do Prometheus, mas também através dos protocolos Influx, OpenTSDB e Graphite.
Os dados do VictoriaMetrics ocupam muito menos espaço em comparação com Thanos e Prometheus.
Se você registrar dados reais, os usuários falam sobre uma redução de 2 a 5 vezes no tamanho dos dados no disco em comparação com Prometheus e Thanos.
Outra vantagem do VictoriaMetrics é que ele é otimizado para velocidade.
Vejamos o custo da infraestrutura.
Uma das vantagens do Thanos é que ele armazena dados em armazenamento de objetos, o que é relativamente barato.
Ao armazenar dados no armazenamento de objetos, você deve pagar pelas operações de gravação e leitura de dados (US$ 10 por milhão de operações). Ao gravar dados no armazenamento de objetos, você paga seus custos de hospedagem para fazer upload de dados para a Internet; se o seu cluster não estiver na AWS, ele será gratuito lá. Ao ler dados, você paga entre US$ 10 e US$ 230 por 1 TB. Isso pode ser significativo se você consultar frequentemente dados históricos do cluster Thanos.
Para um cluster Thanos, você precisa pagar por servidores para componentes Compact, Store Gateway, Query que exigem muita memória e CPU para grandes quantidades de dados.
VictoriaMetrics tem as seguintes despesas. Se você armazenar dados em unidades HDD GCE, o valor será de US$ 40 por 1 TB. Para VictoriaMetrics, unidades HDD comuns são suficientes; não são necessários SSDs, que custam cinco vezes mais. VictoriaMetrics é otimizado para HDD.
VictoriaMetrics requer servidores para componentes: componentes de nó único ou clusterizados, que, ao contrário dos componentes Thanos, requerem muito menos CPU e RAM - e serão, portanto, mais baratos.
Exemplos de implementação.
Thanos tem um exemplo de implementação no Gitlab. Gitlab roda inteiramente em Thanos. Mas nem tudo é tão tranquilo aí. Se você olhar para eles , então você pode ver que eles constantemente têm algum : não há memória suficiente para os componentes Store Gateway ou Query. Eles precisam aumentar constantemente a quantidade de memória.
Por conta disso, os custos para resolver esses problemas aumentam.
A segunda implementação, que pode ter mais sucesso, é a empresa Improvável, que começou a desenvolver Thanos. Eles publicaram o código-fonte do Thanos. Improvável é uma empresa que desenvolve motores de jogos.
VictoriaMetrics tem exemplos de implementação pública:
- construtor de sites wix.com
- Adidas está implementando VictoriaMetrics e até fez apresentação na última PromCon 2019
- TrafficStars - rede de anúncios
- Seznam.cz é um popular mecanismo de pesquisa tcheco.
E então havia empresas sem nome que não posso nomear agora. Eles não consentiram.
- Um grande desenvolvedor de jogos. Maior que Im Improvável.
- Grande desenvolvedor de software gráfico.
- Grande banco russo.
- Fabricante europeu de turbinas eólicas que testou com sucesso o VictoriaMetrics. Este fabricante está implementando o VictoriaMetrics para monitorar dados coletados de turbinas eólicas a uma taxa de 50 amostras por segundo por sensor. Cada turbina eólica possui várias centenas de sensores. Eles têm várias centenas de turbinas eólicas.
- Companhias aéreas russas que querem implementar o VictoriaMetrics, mas ainda não conseguem. Estamos em fase de contrato com eles.
Conclusões.
VictoriaMetrics e Thanos resolvem problemas semelhantes, mas de maneiras diferentes:
- Visualização de consulta global
- escala horizontal
- retenção arbitrária
Obrigado.
Esperamos por você em nosso .
Apenas usuários registrados podem participar da pesquisa. por favor
O que você usa como armazenamento de longo prazo para o Prometheus?
-
35,3%Thanos6
-
0,0%Córtex0
-
0,0%M3DB0
-
41,2%VictoriaMetrics7
-
23,5%outros4
17 usuários votaram. 16 usuários se abstiveram.
Fonte: habr.com