VictoriaMetrics: взгляд вглубь

Вам интересно, где происходит волшебство?

«Магия» проекта VictoriaMetrics, обеспечивающая основную функциональность и производительность, в основном происходит в бэкенд-коде Go, а именно в каталоге хранилища.

Коллектор

vmagent — легковесный агент для сбора, агрегации и передачи метрик из различных источников в VictoriaMetrics или другие совместимые хранилища.

Вы собираете и запускаете vmagent как отдельный бинарный файл. Он настраивается с помощью флагов командной строки или файлов конфигурации для сбора данных с конечных точек, сбора метрик и их отправки в ваш экземпляр VictoriaMetrics.

В распределенной настройке VictoriaMetrics вы обычно устанавливаете vmagent как отдельный двоичный файл на каждом узле, где вы хотите собирать и пересылать метрики.

В кластере Kubernetes (K8s), например, с 10 узлами и 50 подами, следует развернуть vmagent в виде DaemonSet . Это гарантирует, что на каждом узле будет работать один экземпляр vmagent, автоматически собирающий метрики со всех подов на этом узле.

И,VictoriaMetrics предоставляет официальные Helm-чарты для vmagent. Helm упрощает настройку, обновление и управление.

Если вы не хотите управлять проектом самостоятельно, команда VictoriaMetrics предлагает VictoriaMetrics Cloud — управляемую SaaS-платформу для масштабируемого мониторинга временных рядов. Подробнее на сайте victoriametrics.com/cloud .

Исходный код и точку входа для компонента vmagent можно найти в 📁 vmagent.

/app/vmagent/
├── common/             # Shared utilities and helpers for vmagent modules
├── csvimport/          # Logic for importing metrics from CSV files
├── datadogsketches/    # Support for Datadog sketches data format
├── datasource/         # Abstractions for different metric data sources
├── datadogv1/          # Ingestion logic for Datadog v1 protocol
├── datadogv2/          # Ingestion logic for Datadog v2 protocol
├── deployment/         # Contains a Dockerfile for building a image of vmagent
├── graphite/           # Ingestion and helpers for Graphite protocol
├── influx/             # Ingestion and helpers for InfluxDB protocol
├── multiarch/          # Multi-architecture build support
├── native/             # Native integrations and optimizations
├── newrelic/           # Ingestion logic for NewRelic protocol
├── opentelemetry/      # Ingestion logic for OpenTelemetry protocol
├── opentsdb/           # Ingestion logic for OpenTSDB protocol
├── opentsdbhttp/       # HTTP ingestion for OpenTSDB protocol
├── prometheusimport/   # Import logic for Prometheus data
├── promremotewrite/    # Prometheus remote write protocol support
├── remotewrite/        # Logic for forwarding metrics to remote storage
├── static/             # Static assets and resources
├── vmiport/            # VictoriaMetrics import utilities
├── main.go             # Entry point for the vmagent binary
├── Makefile            # Build instructions for vmagent

Можно потратить немало времени на разбор каждого из этих файлов и каталогов, но не стоит. Взгляните на файл request_handler.go в папке opentelemetry, так как Otel — широко распространённый фреймворк. Из него можно сделать выводы о других особенностях поведения.

opentelemetry/request_handler.go

Этот код обрабатывает входящие метрики OpenTelemetry во vmagent от VictoriaMetrics.

1. Функция InsertHandler:

• Получает HTTP-запросы с метриками OpenTelemetry.
• Проверяет заголовки для определения кодировки и формата.
• Анализирует дополнительные метки из запроса.
• Использует соответствующий парсер (protobuf или Firehose для JSON).
• Вызывает insertRows для обработки проанализированных метрик.

2. Функция insertRows:

• Готовит контекст для написания метрик.
• Объединяет метки и выборки (samples) из всех временных рядов.
• Обрабатывает метрические метаданные, если это включено.
• Отправляет метрики в удаленное хранилище с помощью remotewrite.TryPush.
• Обновляет внутренние счетчики и гистограммы для мониторинга.

vmagent также использует общие библиотеки в promscrape для сбора данных в стиле Prometheus и lib для утилит, но они находятся за пределами vmagent.

/lib/promscrape/scraper.go

scraper.go является частью движка сбора данных VictoriaMetrics, совместимого с Prometheus.

Вкратце:
Этот код отвечает за обнаружение метрик на конечных точках, запуск/остановку скрейперов для каждой цели. Целью может быть веб-сервер с эндпоинтом /metrics, под или сервис Kubernetes, контейнер Docker, экспортер узлов, экспортер баз данных или любой сервер или сервис с конечной точкой HTTP, которая предоставляет метрики в формате Prometheus, а также за поддержание синхронизации с последней конфигурацией.

Это движок, который обеспечивает автоматизированный сбор показателей в VictoriaMetrics.

storage.go — это сердце бэкэнда VictoriaMetrics. Именно здесь находится основная логика базы данных временных рядов.

• Определяет механизм хранения:
  структура StorageA является основным компонентом, который управляет всеми данными временных рядов — метриками, временными метками, значениями и т. д.
• Управляет приемом данных:
  такие функции, как AddRows, позволяют VictoriaMetrics эффективно принимать и сохранять новые метрики.
• Управление индексами и кэшами:
  отслеживает индексы и кэши, обеспечивая быстрый поиск и выполнение запросов к данным.
• Контроль хранения и ограничениями:
  автоматическое удаление старых данных на основе настроек сохранения и предотвращает избыточное количество уникальных метрик(ограничений количества элементов).
• Поддержка снимков и резервных копий:
  вы можете создавать и удалять snapshots для резервного копирования и восстановления данных.
• Функции для запросов:
  такие функции, как SearchMetricNames, SearchLabelNames и SearchLabelValues помогают вам находить и анализировать ваши метрики.

Одно важное наблюдение: этот код использует примитивы параллелизма Go:

• sync.Mutex: используется для блокировки общих ресурсов (например, idbLock, deletedMetricIDsUpdateLock, pendingHourEntriesLock и т. д.).
• sync/atomic: используется для атомарных счетчиков и указателей (например, atomic.Uint64, atomic.Pointer и т. д.).
• Каналы и WaitGroups: используются для координации go-процедур (например, stopCh, WaitGroup fields).

Эти механизмы обеспечивают безопасный доступ к общим данным между несколькими горутинами, минимизируя риск возникновения нештатного состояния. Однако, как и в случае с любым параллельным кодом, для обеспечения безопасности во всех сценариях необходимы тщательный анализ и тестирование.

….а Prometheus?

А если Prometheus использует базу данных временных рядов, зачем ему использовать VictoriaMetrics? Вот простое объяснение:

Prometheus включает в себя собственную базу данных временных рядов, но она предназначена для краткосрочного хранения и конфигураций с одним узлом. По мере роста объема данных или необходимости высокой доступности масштабирование встроенной базы данных Prometheus становится сложной задачей.

VictoriaMetrics решает следующие проблемы:

• Он обеспечивает долгосрочное, масштабируемое и высокодоступное хранилище для показателей.
• Он может эффективно обрабатывать гораздо большие объемы данных и больше запросов.
• Поддерживает кластеризацию, репликацию и быстрые запросы.

Воркфлоу:

• Prometheus собирает метрики из приложений и систем.
• Вместо того чтобы хранить все данные локально, Prometheus пересылает (удалённо записывает) данные в VictoriaMetrics.
• VictoriaMetrics хранит, индексирует и обслуживает данные для дашбордов и оповещений.

Prometheus отлично подходит для сбора метрик, а VictoriaMetrics — для их хранения и масштабирования. Совместное использование этих двух инструментов даёт преимущество.

Вместо Prometheus вы можете использовать другие продукты , если они могут отправлять метрики в поддерживаемом формате.

StatsD, Graphite, InfluxDB: VictoriaMetrics нативно поддерживает прием данных по всем этим протоколам.