Подходит ли платформа для начинающих без опыта работы?

Да, курсы разбиты по уровням: Junior, Middle, Senior. Начинающие могут стартовать с базовых тем Python, Docker и алгоритмов и постепенно двигаться к более сложным темам.

Как быстро можно подготовиться к собеседованию на позицию Junior разработчика?

При занятиях 1–2 часа в день — от 2 до 4 недель на основные темы. Платформа анализирует слабые места по результатам квизов и строит персональный план подготовки.

Какие технологии охватывает платформа?

Python, FastAPI, Django, Docker, алгоритмы и структуры данных, Agile/Scrum, SQL, CI/CD, системный дизайн, код-ревью и более 50 других тем для разработчиков.

Платформа бесплатная?

Большинство учебных материалов и квизов доступны бесплатно после регистрации. Регистрация занимает менее минуты.

Как платформа помогает найти работу программистом?

Платформа даёт фундаментальные знания, которые проверяют на технических собеседованиях: алгоритмы, архитектура, фреймворки. Мок-интервью имитирует реальное собеседование. Система прогресса показывает, какие темы нужно подтянуть перед собеседованием.

advanced_promql

Продвинутый PromQL: сложные запросы и оптимизация

Глубокое погружение в PromQL: подзапросы, корреляции, прогнозирование, оптимизация производительности запросов

Продвинутый PromQL: сложные запросы и оптимизация

«PromQL — это не просто запросы, это язык мышления о метриках»

Введение

Вы уже знаете основы PromQL: rate(), агрегации, histogram_quantile(). Теперь углубимся в сложные паттерны, оптимизацию и edge cases.

Подзапросы (Subqueries)

Подзапросы позволяют применять функции к результату другого запроса.

Синтаксис

function[resolution:step]

resolution — диапазон данных
step — интервал между точками (по умолчанию = scrape_interval)

Пример 1: Максимум за час, вычисленный по 5-минутным средним

# Среднее CPU за 5 минут, затем максимум за час
max_over_time(avg_over_time(node_cpu_usage_percent[5m])[1h:5m])

Как работает:

avg_over_time(...[5m]) — среднее за 5 минут для каждой точки
[1h:5m] — берёт эти средние за последний час (12 точек)
max_over_time(...) — максимум среди этих 12 точек

Зачем: сглаживает кратковременные скачки, показывает устойчивые пики.

Пример 2: Изменение rate во времени

# Как менялась скорость запросов (rate от rate)
rate(rate(http_requests_total[5m])[1h:5m])

Зачем: ускорение или замедление трафика (второе производство).

Пример 3: Пики за период

# Максимальный rate за последние 24 часа
max_over_time(rate(http_requests_total[5m])[24h:5m])

Корреляция метрик

Сравнение с прошлым периодом

# Запросов сейчас vs неделю назад
sum(rate(http_requests_total[5m])) 
/
sum(rate(http_requests_total[5m] offset 7d))

Результат: 1.15 = на 15% больше, чем неделю назад.

Отклонение от базовой линии

# Насколько текущий rate отличается от среднего за неделю
(
  sum(rate(http_requests_total[5m]))
  -
  avg_over_time(sum(rate(http_requests_total[5m]))[7d:1h])
)
/
avg_over_time(sum(rate(http_requests_total[5m]))[7d:1h])
* 100

Результат: +25% = на 25% выше среднего за неделю.

Корреляция между сервисами

# Корреляция между ошибками API и задержками БД
correlate(
  sum(rate(api_errors_total[5m])),
  avg(database_latency_seconds)
)

Примечание: correlate() — экспериментальная функция, доступна не во всех версиях. Альтернатива — визуальное сравнение в Grafana.

Прогнозирование и аномалии

predict_linear() для прогнозирования

# Предсказание места на диске через 4 часа
predict_linear(node_disk_free_bytes[24h], 4*3600)

Ограничения: работает только для линейных трендов. Не подходит для циклических паттернов (дневных, недельных).

Выявление аномалий через отклонение

# Аномалия: текущее значение > 3 стандартных отклонений от среднего
(
  node_cpu_usage_percent 
  - 
  avg_over_time(node_cpu_usage_percent[24h])
)
/
stddev_over_time(node_cpu_usage_percent[24h])
> 3

Как работает: Z-score > 3 означает, что значение выходит за пределы 99.7% нормальных значений.

Holt-Winters для прогнозирования

# Экспериментальная функция для прогнозирования временных рядов
holt_winters(node_disk_free_bytes[7d], 0.5, 0.5)

Параметры: smoothing factor (0-1), trend factor (0-1).

Сложные агрегации

Группировка по нескольким лейблам

sum by (service, endpoint, method) (rate(http_requests_total[5m]))

Динамическая группировка

# Группировка по всем лейблам кроме instance
sum without (instance) (rate(http_requests_total[5m]))

Агрегация с условием

# Сумма только для значений > 0
sum(http_requests_total > 0)

Вложенные агрегации

# Среднее по инстансам от суммы по эндпоинтам
avg by (service) (
  sum by (service, instance) (rate(http_requests_total[5m]))
)

Работа с histogram

Перцентили с группировкой

# 95-й перцентиль по всем инстансам
histogram_quantile(0.95, 
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
)

Важно: by (le) обязателен — le (last edge) это специальный лейбл histogram.

Среднее из histogram

# Среднее время ответа
sum(rate(http_request_duration_seconds_sum[5m])) 
/ 
sum(rate(http_request_duration_seconds_count[5m]))

Процент запросов медленнее порога

# Какой процент запросов медленнее 1 секунды
(
  sum(rate(http_request_duration_seconds_bucket{le="+Inf"}[5m]))
  -
  sum(rate(http_request_duration_seconds_bucket{le="1.0"}[5m]))
)
/
sum(rate(http_request_duration_seconds_count[5m]))
* 100

Оптимизация запросов

Избегайте дорогих операций

Дорого:

# Сканирует все метрики
{__name__=~".*"}

Дёшево:

# Конкретная метрика
http_requests_total

Используйте селективность лейблов

Медленно:

# Сначала берёт все метрики, потом фильтрует
{job="api"} |= "error"

Быстро:

# Сразу фильтрует по лейблу
{job="api", level="error"}

Избегайте regex без необходимости

Медленно:

http_requests_total{endpoint=~"/api/.*"}

Быстро:

http_requests_total{endpoint=~"/api/"}

Ограничивайте диапазон

Плохо:

rate(http_requests_total[24h])  # Огромное окно

Хорошо:

rate(http_requests_total[5m])  # Разумное окно

Отладка сложных запросов

Шаг 1: Разбейте на части

Сложный запрос:

max_over_time(avg_over_time(node_cpu[5m])[1h:5m])

Разбейте:

Сначала проверьте avg_over_time(node_cpu[5m])
Затем avg_over_time(...)[1h:5m]
Наконец max_over_time(...)

Шаг 2: Используйте Graph view в Prometheus UI

Показывает график результата — помогает понять, что происходит.

Шаг 3: Проверьте объяснение запроса

curl -g 'http://localhost:9090/api/v1/query?query=...'

Практические примеры

Пример 1: Apdex Score

Apdex (Application Performance Index) — индекс удовлетворённости пользователей.

# Satisfied (<250ms) + Tolerating (250-1000ms) / 2
(
  sum(rate(http_request_duration_seconds_bucket{le="0.25"}[5m]))
  +
  sum(rate(http_request_duration_seconds_bucket{le="1.0"}[5m])) 
  - 
  sum(rate(http_request_duration_seconds_bucket{le="0.25"}[5m]))
  / 2
)
/
sum(rate(http_request_duration_seconds_count[5m]))

Результат: 0-1, где 1 = все пользователи довольны.

Пример 2: Error Budget Burn Rate

# Насколько быстро «сжигаем» error budget (для SLO 99.9%)
(
  sum(rate(http_requests_total{status=~"5.."}[5m]))
  /
  sum(rate(http_requests_total[5m]))
)
/ 0.001  # 0.1% допустимых ошибок

Интерпретация:

1x = сжигаем бюджет с нормальной скоростью
10x = в 10 раз быстрее нормы (тревога!)
0.5x = в 2 раза медленнее (всё хорошо)

Пример 3: Availability % за период

# Процент времени доступности за 30 дней
avg_over_time(up[30d]) * 100

Пример 4: Dependency Health

# Здоровье зависимостей (БД, кэш, внешние API)
(
  avg(probe_success{job="blackbox"}) 
  + 
  (1 - avg(rate(database_errors_total[5m])))
  +
  (1 - avg(rate(cache_errors_total[5m])))
)
/ 3 * 100

Резюме

Подзапросы — функции от функций, [resolution:step] синтаксис.
Корреляция — сравнение с прошлым периодом через offset.
Прогнозирование — predict_linear() для линейных трендов.
Аномалии — Z-score > 3 стандартных отклонений.
Histogram — by (le) для перцентилей, _sum / _count для среднего.
Оптимизация — конкретные метрики, селекция лейблами, разумные окна.
Отладка — разбивайте на части, используйте Graph view.

Что дальше?

В следующей теме вы изучите Recording Rules — предрасчёт сложных метрик для снижения нагрузки на Prometheus.

Проверьте свои знания

Вопросы ещё не добавлены

Вопросы для этой подтемы ещё не добавлены.