Ми часто стикаємося з ситуацією, коли моніторинг показує зелений, а користувачі скаржаться на гальма. SLO без SLI — просто число в документі. SLI без SLO — метрика без сенсу. Разом вони відповідають на бізнес-питання: «Чи працює сервіс достатньо добре?» Наш досвід показує: розрив між дашбордом та користувацьким досвідом — джерело прихованих проблем. Ми налаштовуємо SLO/SLI-моніторинг так, щоб кожен алерт мав пряме бізнес-обґрунтування. Одного разу ми мали замовника в e-commerce: моніторинг показував 99.9% аптайму, але конверсія падала. Виявилося, алерти не враховували latency — сторінки завантажувалися по 5 секунд. Після впровадження SLI latency та SLO 95% запитів <200ms проблема зникла. Якщо схожий випадок, ми допоможемо. Докладніше про концепцію див. SLO (Service Level Objective).
SLI: що вимірюємо
SLI (Service Level Indicator) — конкретна вимірювана метрика, що описує поведінку сервісу з точки зору користувача. Не «завантаження CPU», а «частка успішних запитів». Не «вільна пам'ять», а «затримка відповіді».
Стандартні SLI для HTTP-сервісу: Availability SLI — частка успішних запитів (не 5xx) від усіх запитів:
sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m])) Latency SLI — частка запитів, виконаних швидше порогового значення. «99% запитів швидше 300ms» — це SLI. Формула:
sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) / sum(rate(http_request_duration_seconds_count[5m])) Важно: latency SLI через histogram. Якщо метрики йдуть лише як gauge (середнє значення) — SLI буде неточним. histogram_quantile по нативних histogram-метриках — правильний підхід.
Як вибрати правильні SLI для вашого сервісу?
Вибір SLI залежить від бізнес-логіки. Для API критична доступність, для стрімінгу — затримка першого байта, для платіжного шлюзу — успішність транзакцій. Ми починаємо з аудиту: збираємо поточні метрики, виявляємо прогалини (наприклад, відсутність histogram), потім узгоджуємо SLI з командою та product owner. Без цього будь-яке налаштування — стрільба наосліп.
SLO: цільове значення
SLO (Service Level Objective) — цільове значення SLI за період. Типові приклади:
- Availability: 99.9% запитів успішні за 30 днів
- Latency: 95% запитів завершуються за 200ms за 30 днів
- Freshness (для data pipelines): 99% даних з'являється в таблиці протягом 5 хвилин після створення
99.9% доступності за 30 днів — це 43.8 хвилини допустимого downtime на місяць. Це error budget. Порушення SLO = перевищення бюджету.
Recording Rules для SLO
SLO рахується за довгий період (30 днів). Рахувати PromQL-запит за 30 днів у реальному часі — дорого. Рішення — recording rules, які агрегують дані поступово.
У prometheus-rules.yml:
---
groups:
- name: slo.rules
interval: 1m
rules:
- record: slo:http_availability:ratio_rate5m
expr: |
sum(rate(http_requests_total{status!~"5..", service="checkout"}[5m])) / sum(rate(http_requests_total{service="checkout"}[5m]))
- record: slo:http_availability:ratio_rate30d
expr: |
sum_over_time(slo:http_availability:ratio_rate5m[30d]) / count_over_time(slo:http_availability:ratio_rate5m[30d])
Перша rule — поточне 5-хвилинне вікно (швидко змінюється, для real-time дашборду). Друга — ковзне 30-денне вікно (змінюється повільно, показує виконання SLO).
На Grafana-дашборді stat panel з slo:http_availability:ratio_rate30d покаже: 99.96% — і одразу видно, чи вклалися в SLO 99.9%.
Чому Burn Rate — найкращий підхід до alerting?
Наївний алерт «SLI впав нижче SLO» спрацьовує занадто пізно — коли бюджет уже витрачено. Правильний підхід — Multi-Window, Multi-Burn-Rate alerting (стандарт Google SRE Book). Burn rate — швидкість витрачання error budget. Burn rate = 1 означає витрату рівно за планом. Burn rate = 14.4 означає, що за поточних темпів error budget витратиться за 2 години замість 30 днів.
Алерт на критично високий burn rate (fast burn):
---
- alert: SLOHighBurnRate
expr: |
( slo:http_availability:ratio_rate1h < (1 - 14.4 * (1 - 0.999)) )
and
( slo:http_availability:ratio_rate5m < (1 - 14.4 * (1 - 0.999)) )
for: 2m
labels:
severity: critical
service: checkout
annotations:
summary: "High burn rate: error budget depletes in <2h"
Алерт спрацьовує лише коли обидва вікна (1h та 5m) показують високий burn rate — це запобігає false positives від короткочасних сплесків.
Інструменти для SLO
Вручну писати всі recording rules та алерти — трудомістко. Є інструменти:
Sloth — генератор SLO rules для Prometheus. Описуєш SLO в YAML, Sloth генерує recording rules та multi-window alerting rules:
---
version: "prometheus/v1"
service: "checkout-api"
labels:
team: backend
slos:
- name: requests-availability
objective: 99.9
sli:
events:
error_query: sum(rate(http_requests_total{status=~"5..", service="checkout"}[{{.window}}]))
total_query: sum(rate(http_requests_total{service="checkout"}[{{.window}}]))
---Pyrra — Kubernetes-native SLO framework з власним UI та автоматичною генерацією Prometheus rules через CRD.
| Інструмент | Формат конфігурації | UI | Інтеграція з Kubernetes |
|---|---|---|---|
| Sloth | YAML | Ні | Через helm chart |
| Pyrra | CRD (Custom Resource Definition) | Так | Рідна |
Що входить в налаштування SLO/SLI
Наші інженери з 5+ роками досвіду в observability та 50+ проектами з моніторингу гарантують:
- Аудит поточних метрик (джерела, повнота, точність)
- Визначення SLO спільно з власниками сервісів
- Написання recording rules та multi-window alerting
- Розробка дашборду з error budget та burn rate
- Документування в runbook (дії при перевищенні бюджету, відповідальні особи)
- Підтримка після впровадження (2 тижні консультацій)
Середня вартість години простою в e-commerce може сягати значних сум. Наше налаштування SLO знижує MTTR на 40%, запобігаючи значним збиткам на рік на одному сервісі.
Покрокове налаштування SLO
- Аудит метрик: перевіряємо наявність histogram, коректність карт кодів відповідей.
- Визначення SLI: обираємо метрики, що відображають користувацький досвід.
- Узгодження SLO: з product owner встановлюємо цільові відсотки та періоди.
- Написання recording rules: створюємо Prometheus rules для довгострокових агрегатів.
- Налаштування multi-window alerting: впроваджуємо алерти на основі burn rate.
- Дашборд та runbook: візуалізуємо error budget, документуємо дії.
Приклад типових SLO для різних сервісів
| Тип сервісу | SLI | SLO | Error budget (30 днів) |
|---|---|---|---|
| API gateway | Availability (не 5xx) | 99.95% | 21.6 хв. |
| Web frontend | Latency (p95 < 300ms) | 95% | 36 годин перевищень |
| Data pipeline | Freshness (затримка < 5 хв) | 99% | 7.2 години запізнень |
Чек-лист готовності до впровадження SLO
- Збір HTTP-метрик з histogram для latency.
- Чітке розділення кодів відповідей на успіх/помилку.
- Визначення критичних шляхів запитів (endpoints).
- Наявність власника сервісу для узгодження SLO.
- Інструмент для алертингу (Alertmanager).
Як будується робота
Починаємо з визначення SLO — це розмова з product owner та командою розробки, не технічне питання. Важно визначити, яке значення availability прийнятне, та яка latency — межа між «працює» та «повільно». Без цих домовленостей налаштовувати нічого.
Далі: аудит поточних метрик (чи є histogram для latency, чи правильно позначаються помилки), написання recording rules та SLO-алертів, розробка SLO-дашборду з error budget.
Документування SLO в runbook: що робити при високому burn rate, хто відповідальний, де дивитися далі.
Строки: налаштування SLO для одного сервісу з дашбордом та алертами — 2–3 дні.
Отримайте прозорий контроль над надійністю. Зв'яжіться з нами — розкажемо, як впровадити SLO-моніторинг на вашому стеку. Або просто напишіть — підберемо оптимальне рішення під ваш бюджет.
