{"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\/it\/blog\/administrirovanie\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","title":{"rendered":"Bioyino \u2014 un aggregatore di metriche distribuito e scalabile","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Quindi, state raccogliendo metriche. Proprio come noi. Anche noi raccogliamo metriche. Certamente quelle utili per il business. Oggi parleremo del primo anello del nostro sistema di monitoraggio: un server di aggregazione compatibile con statsd. bioyino<\/a><\/noindex>, il motivo per cui l'abbiamo scritto e perch\u00e9 abbiamo abbandonato brubeck. <\/p>\n

<\/p>\n

\"Bioyino<\/p>\n

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

Dai nostri articoli precedenti (1<\/a><\/noindex>, 2<\/a><\/noindex>) puoi scoprire che fino a un certo punto abbiamo raccolto i nostri dati tramite brubeck<\/a><\/noindex>. \u00c8 scritto in C. Dal punto di vista del codice - semplice come un tappo (questo \u00e8 importante quando vuoi contribuire) e, cosa pi\u00f9 importante, gestisce senza particolari problemi i nostri volumi di 2 milioni di metriche al secondo (MPS) al picco. La documentazione afferma di supportare 4 milioni di MPS con asterisco. Ci\u00f2 significa che otterrai il numero dichiarato se configuri correttamente la rete su Linux. (Non sappiamo quante MPS si possono ottenere lasciando la rete com'\u00e8). Nonostante questi vantaggi, avevamo alcune serie lamentele su brubeck.<\/p>\n

<\/p>\n

Lamentela 1.<\/em> Github \u2014 lo sviluppatore del progetto \u2014 ha smesso di supportarlo: pubblicare patch e fix, accettare le nostre e (non solo le nostre) PR. Negli ultimi mesi (circa da febbraio-marzo 2018) l'attivit\u00e0 \u00e8 ripresa, ma prima di ci\u00f2 c'\u00e8 stata quasi 2 anni di completo silenzio. Inoltre, il progetto \u00e8 sviluppato per esigenze interne di Gihub<\/a><\/noindex>, il che pu\u00f2 rappresentare un serio ostacolo all'implementazione di nuove funzionalit\u00e0.<\/p>\n

<\/p>\n

Reclamo 2.<\/em> Precisione dei calcoli. Brubeck raccoglie solo 65536 valori per l'aggregazione. Nel nostro caso, per alcune metriche durante il periodo di aggregazione (30 secondi) possono arrivare molte pi\u00f9 valore (1.527.392 al picco). Di conseguenza, i valori massimi e minimi sembrano inutili. Ad esempio, ecco come dovrebbe apparire: <\/p>\n

<\/p>\n

\"Bioyino
\nCome era<\/em><\/p>\n

<\/p>\n

\"Bioyino
\nCome dovrebbe essere<\/em><\/p>\n

<\/p>\n

Per lo stesso motivo, le somme sono considerate del tutto scorrette. Aggiungi a ci\u00f2 il bug del overflow del float a 32 bit, che manda in segfault il server all'arrivo di una metrica apparentemente innocua, e diventa davvero eccellente. Il bug, per inciso, non \u00e8 stato ancora corretto.<\/p>\n

<\/p>\n

E, infine, Reclamo X<\/em>. Al momento della stesura di questo articolo, siamo pronti a presentarlo a tutte e 14 le implementazioni di statsd che siamo riusciti a trovare. Immaginiamo che un'infrastruttura specifica sia cresciuta a tal punto da rendere insufficienti 4 milioni di MPS. Oppure, magari non \u00e8 ancora cresciuta, ma le metriche sono gi\u00e0 cos\u00ec importanti per voi che anche brevi cali, di 2-3 minuti, nei grafici possono risultare critici e provocare episodi di depressione negli manager. Poich\u00e9 curare la depressione \u00e8 un compito ingrato, sono necessarie soluzioni tecniche.<\/p>\n

<\/p>\n

In primo luogo, la tolleranza ai guasti, affinch\u00e9 un problema imprevisto su un server non scateni un'apocalisse zombie psichiatrica in ufficio. In secondo luogo, la scalabilit\u00e0, per poter gestire pi\u00f9 di 4 milioni di MPS, senza dover scavare a fondo nello stack di rete di Linux e crescere tranquillamente \"in larghezza\" fino alle dimensioni necessarie.<\/p>\n

<\/p>\n

Poich\u00e9 avevamo margine per la scalabilit\u00e0, abbiamo deciso di iniziare con la resilienza. \"Oh! Resilienza! \u00c8 semplice, lo sappiamo fare\", abbiamo pensato e abbiamo avviato 2 server, sollevando su ciascuno una copia di brubeck. Per questo, abbiamo dovuto copiare il traffico con le metriche su entrambi i server e persino scrivere per questo una piccola utilit\u00e0<\/a><\/noindex>. Abbiamo risolto il problema della tolleranza ai guasti, ma... non molto bene. All'inizio sembrava andare tutto alla grande: ogni brubeck raccoglie la propria variante di aggregazione, scrivendo dati in Graphite ogni 30 secondi, sovrascrivendo l'intervallo precedente (questo avviene sul lato di Graphite). Se un server dovesse guastarsi, abbiamo sempre un secondo con una copia dei dati aggregati. Ma ecco il problema: se un server si guasta, sui grafici compare una \u00absega\u00bb. Questo \u00e8 dovuto al fatto che gli intervalli di 30 secondi dei brubeck non sono sincronizzati e, nel momento in cui uno di essi si guasta, non viene sovrascritto. Quando il secondo server viene attivato, succede la stessa cosa. \u00c8 tollerabile, ma si pu\u00f2 fare di meglio! Anche il problema della scalabilit\u00e0 non \u00e8 scomparso. Tutte le metriche continuano a \u00abvolare\u00bb su un singolo server e perci\u00f2 siamo limitati agli stessi 2-4 milioni MPS a seconda delle prestazioni della rete.<\/p>\n

<\/p>\n

Se ci si ferma un attimo a riflettere sul problema e si scava un po' nella neve, pu\u00f2 venirci in mente un'idea piuttosto ovvia: abbiamo bisogno di un statsd in grado di operare in modalit\u00e0 distribuita. In altre parole, uno che implementi la sincronizzazione tra le nodi in base al tempo e alle metriche. \"Certo, una soluzione del genere deve gi\u00e0 esistere\", abbiamo detto e ci siamo messi a cercare su Google... ma non abbiamo trovato nulla. Esaminando la documentazione di vari statsd (https:\/\/github.com\/etsy\/statsd\/wiki#server-implementations<\/a><\/noindex> a partire dal 11.12.2017), non abbiamo trovato davvero niente. Evidentemente, n\u00e9 gli sviluppatori n\u00e9 gli utenti di queste soluzioni si sono ancora imbattuti in UNA COS\u00cc GRANDE quantit\u00e0 di metriche, altrimenti avrebbero sicuramente trovato qualche soluzione.<\/p>\n

<\/p>\n

Ed \u00e8 qui che ci siamo ricordati del statsd \"giocattolo\" - bioyino, che abbiamo creato durante un hackathon solo per divertirci (il nome del progetto \u00e8 stato generato da uno script prima dell'inizio dell'hackathon) e abbiamo capito che avevamo urgentemente bisogno di un nostro statsd. Perch\u00e9?<\/p>\n

<\/p>\n