{"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\/es\/blog\/administrirovanie\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","title":{"rendered":"Bioyino \u2014 un agregador de m\u00e9tricas distribuido y escalable","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Entonces, est\u00e1s recopilando m\u00e9tricas. Al igual que nosotros. Tambi\u00e9n recopilamos m\u00e9tricas. Por supuesto, las necesarias para el negocio. Hoy hablaremos sobre el primer eslab\u00f3n del sistema de monitoreo: un servidor de agregaci\u00f3n compatible con statsd. bioyino<\/a><\/noindex>, por qu\u00e9 lo escribimos y por qu\u00e9 abandonamos brubeck. <\/p>\n

<\/p>\n

\"Bioyino<\/p>\n

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

De nuestros art\u00edculos anteriores (1<\/a><\/noindex>, 2<\/a><\/noindex>) se puede saber que hasta hace alg\u00fan tiempo, recopil\u00e1bamos etiquetas utilizando brubeck<\/a><\/noindex>. Est\u00e1 escrito en C. Desde el punto de vista del c\u00f3digo, es tan simple como un tap\u00f3n (lo cual es importante cuando quieres contribuir) y, lo m\u00e1s importante, maneja nuestros vol\u00famenes de 2 millones de m\u00e9tricas por segundo (MPS) en pico sin problemas. La documentaci\u00f3n afirma soportar 4 millones de MPS con asterisco. Esto significa que la cifra anunciada se obtendr\u00e1 si configuras correctamente la red en Linux. (No sabemos cu\u00e1ntos MPS se pueden obtener si dejas la red como est\u00e1). A pesar de estas ventajas, tuvimos varias quejas serias sobre brubeck.<\/p>\n

<\/p>\n

Queja 1.<\/em> Github, el desarrollador del proyecto, ha dejado de mantenerlo: de publicar parches y arreglos, aceptar nuestros y (no solo nuestros) PR. En los \u00faltimos meses (desde febrero-marzo de 2018) la actividad ha vuelto, pero antes de eso hubo casi 2 a\u00f1os de completo silencio. Adem\u00e1s, el proyecto est\u00e1 desarrollado para las necesidades internas de Github<\/a><\/noindex>, lo que puede convertirse en un serio obst\u00e1culo para implementar nuevas funcionalidades.<\/p>\n

<\/p>\n

Queja 2.<\/em> Precisi\u00f3n de los c\u00e1lculos. Brubeck solo recopila 65536 valores para la agregaci\u00f3n. En nuestro caso, para algunas m\u00e9tricas en el per\u00edodo de agregaci\u00f3n (30 segundos) pueden llegar muchos m\u00e1s valores (1,527,392 en pico). Como resultado de esta muestreo, los valores de m\u00e1ximos y m\u00ednimos parecen in\u00fatiles. Por ejemplo, as\u00ed: <\/p>\n

<\/p>\n

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

<\/p>\n

\"Bioyino
\nComo deber\u00eda haber sido<\/em><\/p>\n

<\/p>\n

Por la misma raz\u00f3n, las sumas se calculan incorrectamente. A\u00f1ade a esto un error de desbordamiento de float de 32 bits, que realmente provoca un segfault en el servidor al recibir una m\u00e9trica que parece inocente, y se vuelve a\u00fan mejor. El error, por cierto, a\u00fan no se ha corregido.<\/p>\n

<\/p>\n

Y, por \u00faltimo, Queja X<\/em>. En el momento de redactar este art\u00edculo, estamos listos para presentarlo a las 14 implementaciones de statsd m\u00e1s o menos funcionales que hemos logrado encontrar. Imaginemos que cierta infraestructura ha crecido tanto que recibir 4 millones de MPS ya no es suficiente. O puede que a\u00fan no haya crecido, pero las m\u00e9tricas son tan importantes para usted que incluso breves ca\u00eddas de 2-3 minutos en los gr\u00e1ficos pueden volverse cr\u00edticas y causar ataques de depresi\u00f3n incontrolable a los gerentes. Dado que tratar la depresi\u00f3n es un asunto ingrato, son necesarias soluciones t\u00e9cnicas.<\/p>\n

<\/p>\n

En primer lugar, tolerancia a fallos, para que un problema repentino en el servidor no desencadene un apocalipsis zombi psiqui\u00e1trico en la oficina. En segundo lugar, escalabilidad, para poder recibir m\u00e1s de 4 millones de MPS sin tener que hurgar en la pila de red de Linux y crecer c\u00f3modamente 'horizontalmente' hasta los tama\u00f1os necesarios.<\/p>\n

<\/p>\n

Dado que ten\u00edamos margen para la escalabilidad, decidimos comenzar con la tolerancia a fallos. '\u00a1Oh! \u00a1Tolerancia a fallos! Esto es f\u00e1cil, lo sabemos hacer', pensamos y lanzamos 2 servidores, levantando una copia de brubeck en cada uno. Para ello, tuvimos que duplicar el tr\u00e1fico con las m\u00e9tricas en ambos servidores e incluso escribir para ello una peque\u00f1a utilidad<\/a><\/noindex>. Resolvimos el problema de la tolerancia a fallos, pero\u2026 no muy bien. Al principio, todo parec\u00eda ir bastante bien: cada brubeck recopila su propia variante de agregaci\u00f3n, escribe datos en Graphite cada 30 segundos, sobrescribiendo el intervalo anterior (esto lo hace Graphite). Si un servidor falla, siempre tenemos el segundo con su propia copia de los datos agregados. Pero hay un problema: si un servidor falla, en los gr\u00e1ficos aparece una 'sierra'. Esto se debe a que los intervalos de 30 segundos en brubeck no est\u00e1n sincronizados, y en el momento de la ca\u00edda uno de ellos no se sobrescribe. Al iniciar el segundo servidor ocurre lo mismo. Es bastante tolerable, pero se desea algo mejor. El problema de la escalabilidad tambi\u00e9n sigue sin resolverse. Todas las m\u00e9tricas siguen 'volando' hacia un \u00fanico servidor, por lo que estamos limitados a esos mismos 2-4 millones de MPS, dependiendo de la capacidad de la red.<\/p>\n

<\/p>\n

Si se piensa un poco en el problema y al mismo tiempo se excava en la nieve, puede venir a la mente una idea tan obvia: se necesita un statsd que funcione en modo distribuido. Es decir, uno que implemente sincronizaci\u00f3n entre nodos en funci\u00f3n del tiempo y las m\u00e9tricas. \"Por supuesto, ya debe existir una soluci\u00f3n as\u00ed\", dijimos y empezamos a buscar en Google... y no encontramos nada. Despu\u00e9s de revisar la documentaci\u00f3n de varios statsd (https:\/\/github.com\/etsy\/statsd\/wiki#server-implementations<\/a><\/noindex> a partir del 11.12.2017), no encontramos nada en absoluto. Al parecer, ni los desarrolladores ni los usuarios de estas soluciones se hab\u00edan enfrentado a esta CANTIDAD de m\u00e9tricas, de lo contrario, seguro ya habr\u00edan ideado algo.<\/p>\n

<\/p>\n

Y aqu\u00ed recordamos el statsd \"juguete\" \u2014 bioyino, que desarrollamos en un hackathon solo por diversi\u00f3n (el nombre del proyecto fue generado por un script al inicio del hackathon) y entendimos que urgentemente necesit\u00e1bamos nuestro propio statsd. \u00bfPor qu\u00e9?<\/p>\n

<\/p>\n