È disponibile la release della piattaforma VictoriaMetrics 1.94.0, che fornisce un database per l'archiviazione e l'elaborazione di dati in forma di serie temporali (una registrazione forma il tempo e un insieme di valori corrispondenti a quel tempo, ad esempio, ottenuti tramite il sondaggio periodico dello stato dei sensori o la raccolta di metriche), ottimizzato per risolvere problemi di monitoraggio. Il progetto compete con soluzioni come InfluxDB, TimescaleDB, Thanos, Cortex e Uber M3, e si distingue per prestazioni superiori. Il database può essere utilizzato come archivio dati a lungo termine, connesso a Prometheus e Grafana, nonché come sostituzione trasparente di InfluxDB. Il codice è scritto in Go e distribuito sotto licenza Apache 2.0.
Nei test di prestazioni, VictoriaMetrics supera InfluxDB e TimescaleDB nelle operazioni di inserimento e selezione dei dati fino a 20 volte, consumando 10 volte meno RAM rispetto a InfluxDB e 7 volte meno rispetto a Prometheus, Thanos e Cortex nella gestione di milioni di serie temporali uniche. La memorizzazione dei dati in forma compressa consente di contenere 7 volte più record nello stesso spazio di archiviazione rispetto a Prometheus, Thanos e Cortex, e 70 volte rispetto a TimescaleDB. Sono disponibili ottimizzazioni specifiche per gli archivi con elevate latenze e bassa intensità di operazioni di input/output (ad esempio, dischi rigidi e servizi di archiviazione cloud AWS, Google Cloud e Microsoft Azure).
Il database è fornito come un singolo file eseguibile con impostazioni minime, trasmesse tramite la riga di comando all'avvio. Tutti i dati sono memorizzati in una directory unica, definita all'avvio tramite il flag '-storageDataPath'. Il linguaggio di query utilizzato è MetricsQL, una versione estesa del linguaggio PromQL, utilizzato nel sistema di monitoraggio Prometheus. Oltre alla continua elaborazione dei dati in arrivo, VictoriaMetrics offre anche la possibilità di caricare dati storici precedentemente raccolti.
Sono forniti strumenti per proteggere l'integrità dell'archivio da danni ai dati, ad esempio in caso di interruzione di corrente (l'archivio è strutturato come un albero a registro con fusione), insieme a un semplice sistema di backup basato su snapshot. È possibile unire i nodi di VictoriaMetrics in un cluster scalabile orizzontalmente, supportando meccanismi per garantire alta disponibilità.
Tra le novità aggiunte nella nuova release ci sono:
- In MetricsQL, per maggiore chiarezza, è consentito separare i numeri con un sottolineato (ad esempio, è possibile specificare 1_234_567_890 e 1.234_567_890 invece di 1234567890 e 1.234567890).
- In vmbackup è stata aggiunta la supporto per mantenere server copia dei backup creati.
- Nell'interfaccia vmui è stata aggiunta un'opzione per visualizzare le ultime 25 query. Nella pagina 'Explore cardinality' è stato aggiunto il supporto per l'esportazione dei dati in Prometheus. È stato aggiunto un pulsante per la formattazione automatica delle query PromQL/MetricsQL. È stata migliorata la chiarezza dei grafici. È stato aggiunto uno spazio di archiviazione della cronologia delle query in localStorage.
- In vmagent sono state ampliate le funzionalità di gestione dei nodi del cluster, migliorata la gestione degli errori e ridotto il carico sulla dashboard di Kubernetes durante la scoperta iniziale del servizio.
- Nel cluster, il tempo massimo di ripristino durante le operazioni vmselect e vminsert è stato ridotto da 60 a 3 secondi, nel caso in cui alcuni nodi vmstorage non siano disponibili.
Merita una particolare menzione la conferenza virtuale che si terrà oggi alle 19:00 ora di Mosca, in cui gli sviluppatori di VictoriaMetrics presenteranno le nuove funzionalità del progetto e i piani di sviluppo, parleranno della gestione della piattaforma e dell'individuazione di anomalie, e condivideranno informazioni sullo sviluppo del database open source per il logging VictoriaLogs. La conferenza si concluderà con una sessione di domande e risposte.
Fonte: opennet.ru
