Управление SLO

SLOzy предоставляет RESTful API для полного управления Service Level Objectives. Обработкой запросов занимается internal/handlers/slo.go.

Модель SLO

Поле	Тип	Описание
target	float64	Целевой процент SLO (0–100), например 99.9
time_window	string	Окно оценки: 1h, 24h, 7d, 30d, 90d
metric_type	string	Тип метрики: availability, latency, throughput
metric_query	string	PromQL запрос для расчёта метрики
team_id	int	Идентификатор команды-владельца SLO

CRUD операции

Создание SLO

POST /slos
Content-Type: application/json

{
  "name": "Доступность API",
  "target": 99.9,
  "time_window": "30d",
  "metric_type": "availability",
  "metric_query": "sum(rate(http_requests_total{status=~\"2..\"}[5m])) / sum(rate(http_requests_total[5m]))",
  "team_id": 1
}

Получение списка SLO

GET /slos?page=1&page_size=10

Возвращает пагинированные результаты, отсортированные по created_at DESC. Включены только активные SLO (active = true).

Получение SLO по ID

GET /slos/{id}

Обновление SLO

PATCH /slos/{id}
Content-Type: application/json

{ "target": 99.99, "time_window": "7d" }

Используется динамическое построение запроса — обновляются только переданные поля.

Удаление SLO

DELETE /slos/{id}

Выполняет мягкое удаление: устанавливает active = false. Данные сохраняются в таблице slo_versions для аудита.

Индикаторы статуса

Статус SLO определяется функцией determineSLOStatus() в internal/prometheus/calculator.go:

Статус	Условие (availability)	Условие (latency)
healthy	current / target >= 0.99	current <= target × 1.2
warning	0.95 <= current / target < 0.99	current <= target × 1.5
critical	current / target < 0.95	current > target × 1.5

Для метрик доступности (availability) выше — лучше. Для задержек (latency) — ниже лучше.

Error Budget и Burn Rate

Error Budget вычисляется как ((target - current) / target) × 100. Бюджет потребляется, когда фактическая производительность падает ниже целевого значения.

Burn Rate выводится из скорости потребления error budget за временное окно. При превышении настроенных порогов автоматически срабатывают оповещения.

Версионирование

Каждое изменение SLO фиксируется в таблице slo_versions:

CREATE TABLE slo_versions (
    id SERIAL PRIMARY KEY,
    slo_id INT NOT NULL REFERENCES slos(id) ON DELETE CASCADE,
    diff_type VARCHAR(20) CHECK (diff_type IN ('create', 'update', 'delete')),
    changes JSONB NOT NULL,
    snapshot JSONB NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW(),
    created_by INT
);

JSON-патч изменений и полный снепшот SLO позволяют выполнять откат к любой предыдущей версии и формировать аудит-трейл.