{"id":52113,"date":"2019-11-01T00:00:00","date_gmt":"2019-10-31T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik"},"modified":"2020-02-18T13:59:47","modified_gmt":"2020-02-18T10:59:47","slug":"bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","title":{"rendered":"Bioyino \u2014 um agregador de m\u00e9tricas distribu\u00eddo e escal\u00e1vel","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ent\u00e3o, voc\u00ea est\u00e1 coletando m\u00e9tricas. Assim como n\u00f3s. Tamb\u00e9m coletamos m\u00e9tricas. Claro, as necess\u00e1rias para o neg\u00f3cio. Hoje, falaremos sobre o primeiro elo do nosso sistema de monitoramento \u2014 um servidor de agrega\u00e7\u00e3o compat\u00edvel com statsd. bioyino<\/a><\/noindex>, por que o escrevemos e por que abandonamos o brubeck. <\/p>\n

<\/p>\n

\"Bioyino<\/p>\n

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

A partir de nossos artigos anteriores (1<\/a><\/noindex>, 2<\/a><\/noindex>) voc\u00ea pode descobrir que, at\u00e9 certo tempo, colet\u00e1vamos as etiquetas por meio de brubeck<\/a><\/noindex>. Ele foi escrito em C. Do ponto de vista do c\u00f3digo \u2014 simples como um palito (isso \u00e9 importante quando voc\u00ea deseja contribuir) e, o mais importante, lida com nossos volumes de 2 milh\u00f5es de m\u00e9tricas por segundo (MPS) no pico, sem grandes problemas. A documenta\u00e7\u00e3o afirma o suporte a 4 milh\u00f5es de MPS com um asterisco. Isso significa que voc\u00ea atingir\u00e1 o n\u00famero declarado se configurar corretamente a rede no Linux. (N\u00e3o sabemos quantos MPS podem ser obtidos se a rede for deixada como est\u00e1). Apesar dessas vantagens, tivemos algumas s\u00e9rias reclama\u00e7\u00f5es sobre o brubeck.<\/p>\n

<\/p>\n

Reclama\u00e7\u00e3o 1.<\/em> Github \u2014 o desenvolvedor do projeto \u2014 parou de suport\u00e1-lo: publicar patches e corre\u00e7\u00f5es, aceitar nossos e (n\u00e3o apenas nossos) PRs. Nos \u00faltimos meses (desde fevereiro-mar\u00e7o de 2018) a atividade foi retomada, mas antes disso houve quase 2 anos de completo sil\u00eancio. Al\u00e9m disso, o projeto \u00e9 desenvolvido para necessidades internas do GitHub<\/a><\/noindex>, o que pode se tornar um s\u00e9rio obst\u00e1culo para a implementa\u00e7\u00e3o de novas funcionalidades.<\/p>\n

<\/p>\n

Reclama\u00e7\u00e3o 2.<\/em> Precis\u00e3o dos c\u00e1lculos. O Brubeck coleta apenas 65536 valores para a agrega\u00e7\u00e3o. No nosso caso, para algumas m\u00e9tricas, durante o per\u00edodo de agrega\u00e7\u00e3o (30 seg), pode chegar muito mais valores (1.527.392 no pico). Como resultado dessa amostragem, os valores m\u00e1ximos e m\u00ednimos parecem in\u00fateis. Por exemplo, assim: <\/p>\n

<\/p>\n

\"Bioyino
\nComo foi<\/em><\/p>\n

<\/p>\n

\"Bioyino
\nComo deveria ser<\/em><\/p>\n

<\/p>\n

Pelo mesmo motivo, as somas s\u00e3o consideradas incorretas. Adicione a isso o bug de estouro do float de 32 bits, que envia o servidor para um segfault ao receber uma m\u00e9trica que, \u00e0 primeira vista, parece inofensiva, e a situa\u00e7\u00e3o se torna ainda pior. O bug, a prop\u00f3sito, n\u00e3o foi corrigido.<\/p>\n

<\/p>\n

E, finalmente, Reclama\u00e7\u00e3o X<\/em>. No momento da reda\u00e7\u00e3o deste artigo, estamos prontos para apresent\u00e1-lo a todas as 14 implementa\u00e7\u00f5es funcionais do statsd que conseguimos encontrar. Vamos imaginar que uma infraestrutura espec\u00edfica cresceu tanto que aceitar 4 milh\u00f5es de MPS j\u00e1 n\u00e3o \u00e9 suficiente. Ou pode ser que ainda n\u00e3o tenha crescido, mas as m\u00e9tricas para voc\u00ea j\u00e1 s\u00e3o t\u00e3o importantes que at\u00e9 mesmo breves falhas de 2 a 3 minutos nos gr\u00e1ficos podem se tornar cr\u00edticas e provocar crises de depress\u00e3o insuper\u00e1veis nos gerentes. Como tratar a depress\u00e3o \u00e9 uma tarefa ingrata, s\u00e3o necess\u00e1rias solu\u00e7\u00f5es t\u00e9cnicas.<\/p>\n

<\/p>\n

Em primeiro lugar, toler\u00e2ncia a falhas, para que um problema repentino no servidor n\u00e3o cause um apocalipse zumbi psiqui\u00e1trico no escrit\u00f3rio. Em segundo lugar, escalabilidade, para que possamos aceitar mais de 4 milh\u00f5es de MPS sem ter que aprofundar no stack de rede do Linux e possamos crescer \"horizontalmente\" para os tamanhos necess\u00e1rios.<\/p>\n

<\/p>\n

Como t\u00ednhamos uma margem para escalabilidade, decidimos come\u00e7ar pela toler\u00e2ncia a falhas. \"Oh! Toler\u00e2ncia a falhas! Isso \u00e9 f\u00e1cil, n\u00f3s sabemos fazer isso\", pensamos, e lan\u00e7amos 2 servidores, levantando em cada um uma c\u00f3pia do brubeck. Para isso, tivemos que copiar o tr\u00e1fego com m\u00e9tricas para ambos os servidores e at\u00e9 mesmo escrever para isso uma pequena utilidade<\/a><\/noindex>. Este problema de toler\u00e2ncia a falhas foi resolvido, mas... n\u00e3o muito bem. No in\u00edcio, tudo parecia \u00f3timo: cada brubeck coleta sua pr\u00f3pria vers\u00e3o da agrega\u00e7\u00e3o, escreve dados no Graphite a cada 30 segundos, sobrescrevendo o intervalo anterior (isso acontece do lado do Graphite). Se um servidor falhar, sempre temos o segundo com sua pr\u00f3pria c\u00f3pia dos dados agregados. Mas eis o problema: se um servidor falha, aparece uma \"serra\" nos gr\u00e1ficos. Isso ocorre porque os intervalos de 30 segundos do brubeck n\u00e3o est\u00e3o sincronizados, e no momento da falha, um deles n\u00e3o \u00e9 sobrescrito. No momento em que o segundo servidor \u00e9 iniciado, o mesmo acontece. \u00c9 bastante aceit\u00e1vel, mas gostar\u00edamos de algo melhor! O problema da escalabilidade tamb\u00e9m n\u00e3o desapareceu. Todas as m\u00e9tricas ainda est\u00e3o \"voando\" para um servidor \u00fanico, e, portanto, estamos limitados aos mesmos 2 a 4 milh\u00f5es de MPS, dependendo da capacidade da rede.<\/p>\n

<\/p>\n

Se pensarmos um pouco sobre o problema e ao mesmo tempo cavarmos a neve com uma p\u00e1, pode nos ocorrer uma ideia \u00f3bvia: precisamos de um statsd que funcione em modo distribu\u00eddo. Ou seja, um que implemente a sincroniza\u00e7\u00e3o entre n\u00f3s em termos de tempo e m\u00e9tricas. \"Claro, uma solu\u00e7\u00e3o assim deve existir\", dissemos n\u00f3s e fomos pesquisar.... E nada encontramos. Ap\u00f3s revisar a documenta\u00e7\u00e3o de diferentes statsd (https:\/\/github.com\/etsy\/statsd\/wiki#server-implementations<\/a><\/noindex> at\u00e9 11.12.2017), n\u00e3o encontramos nada. Aparentemente, nem os desenvolvedores nem os usu\u00e1rios dessas solu\u00e7\u00f5es ainda se depararam com UM N\u00daMERO T\u00c3O GRANDE de m\u00e9tricas, caso contr\u00e1rio, eles teriam inventado algo.<\/p>\n

<\/p>\n

E ent\u00e3o nos lembramos do statsd \"brinquedo\" \u2014 bioyino, que escrevemos no hackathon apenas por divers\u00e3o (o nome do projeto foi gerado por um script antes do in\u00edcio do hackathon) e percebemos que precisar\u00edamos urgentemente do nosso pr\u00f3prio statsd. Por qu\u00ea?<\/p>\n

<\/p>\n