{"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 dei cloud privati. Pavel Kolobaev","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VictoriaMetrics<\/p>\n

<\/p>\n

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

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

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

\"VictoriaMetrics<\/p>\n

<\/p>\n

Mi chiamo Kolobaev Pavel. DevOps, SRE, LeroyMerlin, tutto come codice \u2013 questo \u00e8 ci\u00f2 di cui parliamo: di me e degli 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. Ecco un link a un tech radar. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

\u00c8 costruito su hardware Kubernetes, oltre a tutti i servizi associati a OpenStack e al logging. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Lo schema era questo durante lo sviluppo. Quando abbiamo sviluppato tutto ci\u00f2, avevamo un operatore Prometheus che memorizzava i dati all'interno del cluster K8s. Trova automaticamente ci\u00f2 che deve essere estratto e lo mette a disposizione, per cos\u00ec dire. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Dobbiamo estrarre tutti i dati al di fuori del 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 l'uso della federazione, quando abbiamo un Prometheus esterno e accediamo al cluster Kubernetes tramite il meccanismo di federazione.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Qui ci sono alcuni problemi. Nel nostro caso, i problemi sono iniziati quando avevamo 250.000 metriche, e quando sono aumentate a 400.000 metriche, abbiamo capito che non potevamo continuare a lavorare in questo modo. Abbiamo aumentato il timeout di estrazione a 25 secondi.<\/p>\n

<\/p>\n

Perch\u00e9 abbiamo dovuto farlo? Prometheus inizia a contare il tempo del timeout dall'inizio del recupero. Non importa se i dati continuano a fluire. Se, entro il suddetto intervallo temporale, i dati non sono stati trasferiti e la sessione non viene chiusa tramite http, la sessione \u00e8 considerata fallita e i dati non vengono inviati a Prometheus.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Tutti conosciamo i grafici che otteniamo quando mancano parte dei dati. I grafici risultano frastagliati e questo non ci soddisfa. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

La soluzione successiva \u00e8 lo sharding basato su due diversi Prometheus tramite lo stesso meccanismo di federazione.<\/p>\n

<\/p>\n

Ad esempio, possiamo semplicemente effettuare lo sharding in base ai nomi. Questo pu\u00f2 essere utilizzato, ma abbiamo deciso di andare oltre. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ora dovremo gestire questi shard in qualche modo. Possiamo utilizzare promxy, che accede all'area di uno shard e moltiplica i dati. Funziona con due shard come se fosse un'unica punto di accesso. Questo pu\u00f2 essere implementato tramite promxy, ma \u00e8 ancora troppo difficile. <\/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 affermano chiaramente: \"Ragazzi, usate altre TimescaleDB, perch\u00e9 non supporteremo a lungo la conservazione delle metriche\". Non \u00e8 compito loro. \"VictoriaMetrics<\/p>\n

<\/p>\n

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

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

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

<\/p>\n

Attualmente abbiamo ambienti dev e prod. In dev ci sono circa 9 gigabyte per 350.000 metriche. In prod, ci sono oltre 14 gigabyte per 780.000 metriche. Inoltre, il retention time \u00e8 solo di 30 minuti. Questo \u00e8 un problema. E ora spiegher\u00f2 perch\u00e9.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Facciamo un calcolo: con un milione e mezzo di metriche, e ci stiamo avvicinando, in fase di progettazione otteniamo 35-37 gigabyte di memoria. Ma gi\u00e0 con 4 milioni di metriche servirebbero circa 90 gigabyte di memoria. Questo \u00e8 stato calcolato con la formula fornita dagli sviluppatori di Prometheus. Abbiamo analizzato 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 di macchine, ma monitoriamo anche le macchine virtuali stesse. Quindi, pi\u00f9 macchine virtuali ci sono, pi\u00f9 metriche di vario tipo avremo. Ci sar\u00e0 una crescita specifica del nostro cluster in termini di metriche.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

La situazione con lo spazio su disco non \u00e8 cos\u00ec drammatica, ma ci sarebbe la possibilit\u00e0 di migliorare. In 15 giorni abbiamo accumulato per un totale di 120 gigabyte, di cui 100 sono dati compressi e 20 non compressi, ma si desidera sempre avere meno. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

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

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

C'\u00e8 un altro svantaggio di Prometheus che abbiamo identificato: esiste un qualche tipo di limitazione della memoria. Con Prometheus la situazione \u00e8 molto peggiore, perch\u00e9 non ha proprio impostazioni di questo tipo. Usare limiti in Docker non \u00e8 un'opzione. Se per caso il vostro RAF va gi\u00f9 e ci sono 20-30 gigabyte, il ripristino sar\u00e0 molto lungo. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Questa \u00e8 un'altra ragione per cui Prometheus non fa per noi, cio\u00e8 non \u00e8 possibile limitare il consumo di memoria. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Potremmo implementare un sistema di questo tipo. Questo schema \u00e8 necessario per organizzare un cluster HA. Vogliamo che le nostre metriche siano sempre e ovunque accessibili, anche in caso di guasto del server che le memorizza. Pertanto, dovremo costruire uno schema di questo tipo. <\/p>\n

<\/p>\n

Questo schema indica che avremo ridondanza dei shard e, di conseguenza, anche ridondanza dei costi delle risorse consumate. Pu\u00f2 essere quasi scalato orizzontalmente, ma il consumo delle risorse sar\u00e0 comunque elevato. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Gli svantaggi, in ordine, come li abbiamo elencati:<\/p>\n

<\/p>\n