{"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 aggregatore di metriche distribuito e scalabile","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Quindi, stai raccogliendo metriche. Proprio come noi. Anche noi raccogliamo metriche. Certamente quelle necessarie per il business. Oggi parleremo del primo anello del nostro sistema di monitoraggio: un server di aggregazione compatibile con statsd bioyino<\/a><\/noindex>, perch\u00e9 lo abbiamo scritto e perch\u00e9 abbiamo rinunciato a 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 tag tramite brubeck<\/a><\/noindex>. \u00c8 scritto in C. Dal punto di vista del codice, \u00e8 semplice come un tappo (questo \u00e8 importante quando vuoi contribuire) e, soprattutto, gestisce senza particolari problemi i nostri volumi di 2 milioni di metriche al secondo (MPS) al picco. La documentazione afferma il supporto per 4 milioni di MPS con asterisco. Ci\u00f2 significa che il numero dichiarato lo otterrai se configuri correttamente la rete su Linux. (Quante MPS \u00e8 possibile ottenere lasciando la rete cos\u00ec com'\u00e8, non lo sappiamo). Nonostante questi vantaggi, avevamo diverse serie lamentele su brubeck.<\/p>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

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

<\/p>\n

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

<\/p>\n

Per lo stesso motivo, i totali vengono calcolati in modo errato. Aggiungi qui il bug del sovraccarico del float a 32 bit, che manda il server in segfault quando riceve una metrica apparentemente innocua, e diventa davvero ottimo. Il bug, tra l'altro, non \u00e8 stato ancora risolto.<\/p>\n

<\/p>\n

E, infine, Lamentela X<\/em>. Al momento della stesura dell'articolo siamo pronti a presentare a tutti le 14 implementazioni di statsd funzionanti che siamo riusciti a trovare. Immaginiamo che una certa infrastruttura sia cresciuta cos\u00ec tanto che accettare 4 milioni di MPS non \u00e8 pi\u00f9 sufficiente. Oppure che non sia ancora cresciuta, ma che le metriche siano gi\u00e0 cos\u00ec importanti che anche brevi interruzioni di 2-3 minuti nei grafici possano diventare critiche e causare attacchi di profonda depressione nei 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, per evitare che un problema improvviso sul server scateni un'apocalisse zombie psichiatrica in ufficio. In secondo luogo, la scalabilit\u00e0, per avere la possibilit\u00e0 di accettare pi\u00f9 di 4 milioni di MPS, senza dover scavare a fondo nel stack di rete di Linux e poter crescere 'in larghezza' fino alle dimensioni necessarie.<\/p>\n

<\/p>\n

Poich\u00e9 avevamo margine in termini di scalabilit\u00e0, abbiamo deciso di partire dalla tolleranza ai guasti. 'Oh! Tolleranza ai guasti! \u00c8 semplice, lo sappiamo fare', abbiamo pensato e abbiamo avviato 2 server, installando su ciascuno una copia di brubeck. Per fare questo, ci \u00e8 stato necessario copiare il traffico con le metriche su entrambi i server e persino scrivere per questo un piccolo utilitario<\/a><\/noindex>. Abbiamo risolto il problema della tolleranza ai guasti, ma... non molto bene. All'inizio sembrava che andasse tutto bene: ogni brubeck raccoglie la propria versione dell'aggregazione, scrive i dati in Graphite ogni 30 secondi, sovrascrivendo l'intervallo precedente (questo avviene lato Graphite). Se un server fallisce, abbiamo sempre il secondo con la propria copia dei dati aggregati. Ma c'\u00e8 un problema: se il server fallisce, nei grafici appare una 'sega'. Questo \u00e8 dovuto al fatto che gli intervalli di 30 secondi di brubeck non sono sincronizzati, e nel momento in cui uno di essi va gi\u00f9, non viene sovrascritto. Quando si avvia il secondo server, succede la stessa cosa. \u00c8 abbastanza tollerabile, ma si desidera qualcosa di meglio! Anche il problema della scalabilit\u00e0 non \u00e8 scomparso. Tutte le metriche continuano a 'volare' su un singolo server, e quindi siamo limitati agli stessi 2-4 milioni di MPS a seconda della potenza della rete.<\/p>\n

<\/p>\n

Se si riflette un po' sul problema e si inizia a scavare nella neve, pu\u00f2 venire in mente un'idea piuttosto ovvia: \u00e8 necessario uno statsd in grado di funzionare in modalit\u00e0 distribuita. Ovvero, 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 pensato, e abbiamo iniziato a cercare su Google... ma non abbiamo trovato nulla. Analizzando la documentazione di vari statsd (https:\/\/github.com\/etsy\/statsd\/wiki#server-implementations<\/a><\/noindex> al 11.12.2017), non abbiamo trovato assolutamente nulla. Evidentemente, n\u00e9 gli sviluppatori n\u00e9 gli utenti di queste soluzioni si sono ancora trovati con un numero COS\u00cc elevato di metriche, altrimenti avrebbero sicuramente inventato qualche cosa.<\/p>\n

<\/p>\n

E qui ci siamo ricordati dello statsd \"giocattolo\" - bioyino, che avevamo scritto durante un hackathon solo per divertimento (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