Метрики

Что такое метрики в Astra Monitoring?

Метрика — это числовое значение, характеризующее состояние системы, приложения или оборудования в определенный момент времени. В Astra Monitoring используется формат Prometheus, который позволяет собирать, хранить и анализировать временные ряды данных.

Основные понятия

Метрика (Metric) — именованное значение (например, cpu_usage, memory_free).

Лейбл (Label) — дополнительная метаинформация (например, host=»server1», service=»nginx»).

Таймстамп (Timestamp) — временная отметка.

Значение (Value) — числовые данные (целые/дробные числа).

Как формируются метрики в Prometheus-формате?

Метрика записывается в виде:

<имя_метрики>{<лейбл1>=<значение>, <лейбл2>=<значение>} <значение>

При сборе метрики к ней добавляется timestamp. В базе данных метрика хранится в таком виде:

<имя_метрики>{<лейбл1>=<значение>, <лейбл2>=<значение>} <значение> <таймстамп>

Когда и где добавляется таймстамп к метрикам?

В системе мониторинга Astra Monitoring, работающей с форматом Prometheus, применяется следующий принцип обработки временных меток:

На уровне экспортера

Экспортеры не добавляют таймстамп при предоставлении метрик

Пример сырых данных от node_exporter:

node_cpu_seconds_total{cpu="0",mode="idle"} 123456.78
node_memory_free_bytes 8589934592

Формат: <имя_метрики>{лейблы} значение

На уровне Prometheus-сервера

Таймстамп добавляется в момент сбора метрики сервером Prometheus

Временная метка соответствует моменту scrape’а

Хранится вместе с метрикой в базе данных временных рядов

Формат хранения метрик с таймстампом

В базе данных каждая запись содержит:

  1. Имя метрики

  2. Набор лейблов

  3. Значение

  4. Таймстамп (в Unix-формате, наносекунды)

Пример полной записи в хранилище:

{
  "metric": {
    "__name__": "http_requests_total",
    "method": "GET",
    "handler": "/api"
  },
  "values": [1500],
  "timestamps": [1672531200000000000]
}

Особенности работы с таймстампами

Как правило, экспортер не предоставляет таймстамп, в таком случае используется время scrape’а агентом

Проблемы рассинхронизации

Ситуация

Последствия

Решение

Задержка сбора данных

Метрики с неправильным временем

Настроить scrape_timeout

Разные часы на серверах

Искажение временных рядов

Использовать NTP на всех узлах

Примеры метрик

Простая метрика (без лейблов)

cpu_temperature 65.3

Метрика с лейблами

http_requests_total{method="GET", endpoint="/api/users", status="200"} 1500

Best Practices работы с метриками

Именование метрик:

  • Используется snake_case (cpu_usage, а не cpuUsage).

  • Начинается с имени сущности (node_memory_free, а не просто memory_free).

Лейблы:

  • Не рекомендуется использовать постоянно меняющиеся лейблы (слишком много лейблов = нагрузка на БД).

  • Используйте лейблы для условно динамических параметров (ID пользователя, URL).

Частота записи:

  • Оптимально: 15-60 секунд (чаще — нагрузка, реже — потеря детализации).

Типы метрик:

  • Counter (монотонно растет, например, requests_total).

  • Gauge (может увеличиваться/уменьшаться, например, cpu_usage).

  • Histogram и Summary (для распределений, например, request_duration_seconds).

Нюансы хранения метрик в БД временных рядов

Особенности работы с данными

Сжатие данных: Старые метрики автоматически агрегируются (например, 1 точка в день вместо 1440).

Retention Policy: Данные хранятся ограниченное время (можно настроить).

Индексирование: Лейблы ускоряют поиск, но увеличивают объем БД.

Оптимальные стратегии

Для долгосрочного хранения используйте downsampling (агрегацию старых данных).

Избегайте «мусорных» метрик (например, debug_info), которые не используются.

Настройте алерты на аномалии (rate(http_errors[5m]) > 0.1).