{"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\/it\/blog\/administrirovanie\/victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev","title":{"rendered":"VictoriaMetrics e monitoraggio di cloud privati. Pavel Kolobaev","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VictoriaMetrics<\/p>\n

<\/p>\n

VictoriaMetrics \u2014 un database veloce e scalabile per la memorizzazione e l'elaborazione dei dati in forma di serie temporale (una registrazione forma il tempo e un insieme di valori corrispondenti a quel tempo, ad esempio, ottenuti tramite sondaggio periodico dello stato dei sensori o raccolta di metriche).<\/p>\n

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

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

\"VictoriaMetrics<\/p>\n

<\/p>\n

Mi chiamo Kolobayev Pavel. DevOps, SRE, LeroyMerlin, tutto come codice \u2013 \u00e8 tutto su di noi: su di me e sugli altri dipendenti di LeroyMerlin.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

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

<\/p>\n

C'\u00e8 un cloud basato su OpenStack. Qui c'\u00e8 un piccolo collegamento al tech radar. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

\u00c8 costruito su hardware Kubernetes, oltre a tutti i servizi ausiliari per OpenStack e registrazione. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Lo schema era questo durante lo sviluppo. Quando stavamo sviluppando tutto questo, avevamo un operatore Prometheus che memorizzava i dati all'interno del cluster K8s. Trova automaticamente ci\u00f2 che deve essere estratto e lo mette ai suoi piedi, in parole povere. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Tutti i dati devono essere estratti dal cluster Kubernetes, perch\u00e9 se succede qualcosa, dobbiamo capire cosa e dove. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

La prima soluzione \u00e8 utilizzare la federation, quando abbiamo un Prometheus esterno e accediamo al cluster Kubernetes attraverso il meccanismo di federation.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ma qui sorgono piccoli problemi. Nel nostro caso, i problemi sono iniziati quando avevamo 250.000 metriche, e quando sono diventate 400.000 metriche, ci siamo resi conto che non potevamo lavorare in questo modo. Abbiamo aumentato il scrape_timeout a 25 secondi.<\/p>\n

<\/p>\n

Perch\u00e9 abbiamo dovuto farlo? Prometheus inizia a contare il tempo di timeout dall'inizio dell'estrazione. E non importa che i dati stiano ancora fluendo. Se entro quel periodo specificato i dati non vengono scaricati e la sessione non viene chiusa tramite http, si considera che la sessione sia fallita e i dati non entrano in Prometheus.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Tutti conosciamo i grafici che otteniamo quando parte dei dati \u00e8 assente. I grafici sono frastagliati e ci\u00f2 non ci soddisfa. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

La prossima opzione \u00e8 lo sharding basato su due Prometheus diversi tramite lo stesso meccanismo di federation.<\/p>\n

<\/p>\n

Ad esempio, semplicemente prendere e shardarli per nome. Questo pu\u00f2 essere utilizzato anch'esso, ma abbiamo deciso di andare oltre. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ora dovremo in qualche modo gestire questi shard. Possiamo prendere promxy, che si collega all'area dello shard e moltiplica i dati. Funziona con due shard come un'unica porta di accesso. Questo pu\u00f2 essere realizzato tramite promxy, ma \u00e8 ancora troppo complicato. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

La prima opzione \u00e8 che vogliamo rinunciare al meccanismo di federation, perch\u00e9 \u00e8 molto lento. <\/p>\n

<\/p>\n

Gli sviluppatori di Prometheus dicono chiaramente: \u00abRagazzi, utilizzate altri TimescaleDB, perch\u00e9 non supporteremo a lungo la conservazione delle metriche\u00bb. Non \u00e8 compito loro. \"VictoriaMetrics<\/p>\n

<\/p>\n

Prendiamo nota su un pezzo di carta che abbiamo comunque bisogno di un'esportazione, per non conservare tutto in un unico posto. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Il secondo svantaggio \u00e8 il consumo di memoria. S\u00ec, capisco che molti diranno che nel 2020 un paio di gigabyte di memoria costano pochi, ma comunque. <\/p>\n

<\/p>\n

Attualmente abbiamo un ambiente dev e uno prod. Nel dev, sono circa 9 gigabyte per 350.000 metriche. Nel prod, sono 14 gigabyte e poco pi\u00f9 per 780.000 metriche. Inoltre, il tempo di retention \u00e8 di soli 30 minuti. Questo \u00e8 un problema. E ora spiegher\u00f2 perch\u00e9.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Stiamo facendo un calcolo, ossia con un milione e mezzo di metriche, e siamo gi\u00e0 vicini a quel numero, in fase di progettazione riceviamo 35-37 gigabyte di memoria. Gi\u00e0 a 4 milioni di metriche, abbiamo bisogno di circa 90 gigabyte di memoria. Questo \u00e8 stato calcolato secondo la formula fornita dagli sviluppatori di Prometheus. Abbiamo esaminato la correlazione e capito che non vogliamo pagare un paio di milioni per un server solo per il monitoraggio. <\/p>\n

<\/p>\n

Non solo aumenter\u00e0 il numero delle macchine, ma monitoriamo anche le stesse macchine virtuali. Quindi, pi\u00f9 macchine virtuali ci sono, pi\u00f9 metriche di vario tipo avremo e cos\u00ec via. Ci sar\u00e0 una crescita specifica del nostro cluster in termini di metriche.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Con lo spazio su disco non \u00e8 tutto cos\u00ec tragico, ma ci piacerebbe migliorare. Abbiamo ottenuto in 15 giorni un totale di 120 gigabyte, di cui 100 sono dati compressi e 20 non compressi, ma si vorrebbe sempre avere meno. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Di conseguenza, aggiungiamo un altro punto: \u00e8 un grande consumo di risorse che vorremmo comunque risparmiare, perch\u00e9 non vogliamo che il nostro cluster di monitoraggio consumi pi\u00f9 risorse del nostro cluster che gestisce OpenStack.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

C'\u00e8 anche un altro svantaggio di Prometheus che abbiamo identificato, ed \u00e8 una qualche forma di limitazione della memoria. Con Prometheus la situazione \u00e8 molto peggiore, perch\u00e9 non ha affatto queste regolazioni. Utilizzare un limite in Docker non \u00e8 neanche un'opzione. Se il vostro RAF si arresta e ci sono 20-30 gigabyte, ci vorr\u00e0 un bel po' per rialzarsi. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Questa \u00e8 un'altra ragione per cui Prometheus non \u00e8 adatto a noi, cio\u00e8 non si pu\u00f2 limitare il consumo di memoria. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Si potrebbe arrivare a una tale configurazione. Questa configurazione ci serve per organizzare un cluster HA. Vogliamo che le nostre metriche siano sempre e ovunque disponibili, anche in caso di fallimento del server che le memorizza. Pertanto, dovremo costruire una configurazione del genere. <\/p>\n

<\/p>\n

Questa configurazione prevede che ci sar\u00e0 duplicazione delle shard e, di conseguenza, anche duplicazione dei costi delle risorse consumate. Pu\u00f2 essere scalata quasi orizzontalmente, ma il consumo di risorse sar\u00e0 comunque enorme. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Gli svantaggi in ordine, cos\u00ec come li abbiamo annotati:<\/p>\n

<\/p>\n