{"id":94153,"date":"2020-09-13T19:42:30","date_gmt":"2020-09-13T17:42:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev"},"modified":"2020-09-13T19:42:30","modified_gmt":"2020-09-13T17:42:30","slug":"victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev","title":{"rendered":"VictoriaMetrics e monitoramento de nuvens privadas. Pavel Kolobaev","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VictoriaMetrics<\/p>\n

<\/p>\n

VictoriaMetrics \u2014 um banco de dados r\u00e1pido e escal\u00e1vel para armazenamento e processamento de dados em formato de s\u00e9ries temporais (os registros formam o tempo e um conjunto de valores correspondentes a esse tempo, como os obtidos por meio de sondagens peri\u00f3dicas do estado de sensores ou coleta de m\u00e9tricas).<\/p>\n

<\/a><\/noindex>
\n

\r\n \"Por\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Meu nome \u00e9 Kolobaev Pavel. DevOps, SRE, LeroyMerlin, tudo como c\u00f3digo \u2013 isso \u00e9 sobre n\u00f3s: sobre mim e sobre outros colaboradores da LeroyMerlin.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

https:\/\/bit.ly\/3jf1fIK<\/a><\/noindex><\/p>\n

<\/p>\n

Existe uma nuvem baseada em OpenStack. H\u00e1 um pequeno link para o radar t\u00e9cnico. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Constru\u00eddo com hardware Kubernetes, al\u00e9m de todos os servi\u00e7os complementares ao OpenStack e de logging. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

O esquema era este que t\u00ednhamos em desenvolvimento. Quando est\u00e1vamos desenvolvendo tudo isso, t\u00ednhamos um operador Prometheus que armazenava dados dentro do pr\u00f3prio cluster K8s. Ele encontra automaticamente o que precisa ser raspado e re\u00fane, grosso modo, no seu caminho. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Todos os dados precisar\u00e3o ser extra\u00eddos do cluster Kubernetes, porque se algo acontecer, precisamos entender o que e onde. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

A primeira solu\u00e7\u00e3o \u2013 usamos federation, quando h\u00e1 um Prometheus externo, quando acessamos o cluster Kubernetes atrav\u00e9s do mecanismo federation.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Mas surgem pequenos problemas. No nosso caso, os problemas come\u00e7aram quando t\u00ednhamos 250.000 m\u00e9tricas, e quando chegamos a 400.000 m\u00e9tricas, percebemos que n\u00e3o pod\u00edamos trabalhar assim. Aumentamos o scrape_timeout para 25 segundos.<\/p>\n

<\/p>\n

Por que tivemos que fazer isso? O Prometheus come\u00e7a a contar o tempo de timeout a partir do in\u00edcio da coleta. E n\u00e3o importa que os dados ainda estejam fluindo. Se durante esse per\u00edodo especificado os dados n\u00e3o forem coletados e a sess\u00e3o n\u00e3o for encerrada por http, a sess\u00e3o \u00e9 considerada fracassada e os dados n\u00e3o chegam ao pr\u00f3prio Prometheus.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Todos conhecem os gr\u00e1ficos que recebemos quando parte dos dados est\u00e1 ausente. Os gr\u00e1ficos ficam fragmentados, e isso n\u00e3o nos satisfaz. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

A pr\u00f3xima op\u00e7\u00e3o \u00e9 o sharding baseado em dois Prometheus diferentes atrav\u00e9s do mesmo mecanismo federation.<\/p>\n

<\/p>\n

Por exemplo, simplesmente pegar e shardear por nome. Isso tamb\u00e9m pode ser utilizado, mas decidimos seguir em frente. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Agora teremos que processar esses shards de alguma forma. Podemos usar o promxy, que acessa a \u00e1rea do shard e multiplica os dados. Ele trabalha com dois shards como se fosse um \u00fanico ponto de entrada. Isso pode ser realizado atrav\u00e9s do promxy, mas \u00e9 complicado por enquanto. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

A primeira op\u00e7\u00e3o \u2013 queremos desistir do mecanismo federation, porque \u00e9 muito lento. <\/p>\n

<\/p>\n

Os desenvolvedores do Prometheus claramente dizem: \"Pessoal, usem outros TimescaleDB, porque n\u00e3o vamos suportar o armazenamento de m\u00e9tricas a longo prazo\". Essa n\u00e3o \u00e9 a tarefa deles. \"VictoriaMetrics<\/p>\n

<\/p>\n

Anotamos que precisamos de uma exporta\u00e7\u00e3o externa, para n\u00e3o armazenar tudo em um s\u00f3 lugar. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

O segundo problema \u00e9 o consumo de mem\u00f3ria. Sim, eu entendo que muitos dir\u00e3o que em 2020 alguns gigabytes de mem\u00f3ria custam pouco, mas ainda assim. <\/p>\n

<\/p>\n

Atualmente temos ambientes dev e prod. No dev, temos cerca de 9 gigabytes para 350.000 m\u00e9tricas. No prod, s\u00e3o 14 gigabytes e um pouco mais para 780.000 m\u00e9tricas. E o nosso tempo de reten\u00e7\u00e3o \u00e9 de apenas 30 minutos. Isso \u00e9 ruim, e agora explicarei por qu\u00ea.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Fazemos um c\u00e1lculo, ou seja, com um milh\u00e3o e meio de m\u00e9tricas, e j\u00e1 estamos pr\u00f3ximos disso, na fase de planejamento obtemos 35-37 gigabytes de mem\u00f3ria. Mas com quatro milh\u00f5es de m\u00e9tricas j\u00e1 s\u00e3o cerca de 90 gigabytes de mem\u00f3ria. Isso foi calculado com a f\u00f3rmula fornecida pelos desenvolvedores do Prometheus. Observamos a correla\u00e7\u00e3o e entendemos que n\u00e3o queremos pagar alguns milh\u00f5es por um servidor apenas para monitoramento. <\/p>\n

<\/p>\n

N\u00e3o apenas o n\u00famero de m\u00e1quinas vai aumentar, mas tamb\u00e9m estamos monitorando as pr\u00f3prias m\u00e1quinas virtuais. Portanto, quanto mais m\u00e1quinas virtuais, mais m\u00e9tricas de v\u00e1rios tipos, etc. Teremos um crescimento especial do nosso cluster em termos de m\u00e9tricas.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Com o espa\u00e7o em disco, a situa\u00e7\u00e3o n\u00e3o \u00e9 t\u00e3o ruim, mas gostar\u00edamos de melhorar. Em 15 dias, obtivemos um total de 120 gigabytes, dos quais 100 s\u00e3o dados comprimidos e 20 s\u00e3o dados n\u00e3o comprimidos, mas sempre queremos menos. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Portanto, estamos anotando mais um ponto - o alto consumo de recursos, que queremos economizar, pois n\u00e3o queremos que nosso cluster de monitoramento consuma mais recursos do que nosso cluster que cuida da gest\u00e3o do OpenStack.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

H\u00e1 mais uma desvantagem no Prometheus que identificamos: uma limita\u00e7\u00e3o de mem\u00f3ria, mesmo que m\u00ednima. Com o Prometheus, isso \u00e9 muito pior, pois ele n\u00e3o tem tais controles. Usar limites no Docker tamb\u00e9m n\u00e3o \u00e9 uma op\u00e7\u00e3o. Se o seu RAF falhar e houver 20-30 gigabytes, ele levar\u00e1 muito tempo para reiniciar. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Esta \u00e9 mais uma raz\u00e3o pela qual o Prometheus n\u00e3o nos serve; ou seja, n\u00e3o \u00e9 poss\u00edvel limitar o consumo de mem\u00f3ria. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Poder\u00edamos seguir esse esquema. Esse esquema \u00e9 necess\u00e1rio para organizarmos um cluster de alta disponibilidade (HA). Queremos que nossas m\u00e9tricas estejam sempre e em qualquer lugar acess\u00edveis, mesmo em caso de falha do servidor que armazena essas m\u00e9tricas. Assim, teremos que construir um esquema como este. <\/p>\n

<\/p>\n

Este esquema indica que teremos duplica\u00e7\u00e3o de shards, assim como a duplica\u00e7\u00e3o dos recursos consumidos. \u00c9 quase escal\u00e1vel horizontalmente, mas, mesmo assim, o consumo de recursos ser\u00e1 intenso. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

As desvantagens, na ordem em que as anotamos:<\/p>\n

<\/p>\n