Как мерить SLI/SLO
SLI (Service Level Indicator) — что меряем: latency p99 < 200ms, error rate < 0.1%, availability > 99.9%. SLO (Service Level Objective) — target над SLI. Error Budget = 1 - SLO (99.9% → 0.1% = 43 мин/мес downtime allowed). Когда budget exhausted — freeze features, focus on reliability. Tools: SLOconf (Nobl9), Grafana SLO, OpenSLO spec.
Ниже: пошаговая инструкция, рабочие примеры, типичные ошибки, FAQ.
Бесплатный онлайн-инструмент — проверка HTTP-заголовков: результат мгновенно, без регистрации.
Пошаговая настройка
- Identify critical user journeys (login, checkout, core API)
- Define SLI per journey: latency p99, error rate, throughput
- Set SLO realistic — start с 99% (3.65d downtime/yr), grow to 99.9%
- Instrument с Prometheus metrics или OpenTelemetry
- Calculate error budget consumption: actual errors / allowed
- Alerting: burn-rate alert — не threshold-based, а "at this rate budget gone in 6h"
- Monthly review: miss SLO → postmortem + feature freeze
Рабочие примеры
| Сценарий | Конфиг |
|---|---|
| Prometheus SLO rules | groups:
- name: api_slo
rules:
- record: api_availability_sli
expr: |
sum(rate(http_requests_total{code!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
- alert: SLOBurnRate6h
expr: (1 - api_availability_sli) > (14.4 * (1 - 0.999))
for: 5m # burn 6-hour budget |
| OpenSLO spec | apiVersion: openslo/v1
kind: SLO
metadata: { name: api-availability }
spec:
description: 99.9% success rate for API
service: api-gateway
indicator:
metricSource:
type: prometheus
spec:
good: sum(rate(http_requests_total{code!~"5.."}[5m]))
total: sum(rate(http_requests_total[5m]))
objectives:
- displayName: 99.9% уверенный
target: 0.999
timeWindow: [{ rolling: { count: 28, unit: Day } }] |
| Latency SLI (p99) | # Prometheus
histogram_quantile(0.99,
rate(http_request_duration_seconds_bucket[5m])
) < 0.2 # 200ms |
| Burn-rate multi-window alert | # Fast burn (14.4x rate — exhaust 30d budget в 2d)
error_rate > 14.4 * (1 - 0.999) for 1h
# AND
error_rate > 14.4 * (1 - 0.999) for 5m
# → page SRE |
| Grafana SLO panel | # Using Grafana SLO plugin
# Panel type: SLO
# Time window: 28d rolling
# Good events: rate(http_requests{code!~"5.."}[1h])
# Total events: rate(http_requests[1h])
# Shows: SLI current, error budget remaining, burn rate |
Типичные ошибки
- Too tight SLO (99.999% = 26s/мес) → impossible для small team. Start 99% and tighten
- SLO без user impact — meaningless. "CPU < 80%" is not SLO, "checkout success > 99.9%" is
- Alert threshold-based (error > 1%) — noisy. Burn-rate alerts better
- Ignoring error budget в planning — deploy huge changes when budget exhausted = outage
- Monitoring только uptime (UP/DOWN ping) — misses latency + partial degradation
TL;DR: Как мерить SLI/SLO для сервиса
Чтобы измерять SLI (Service Level Indicator) и SLO (Service Level Objective) для сервиса, необходимо определить ключевые метрики, такие как доступность и производительность. Например, для веб-сервиса SLI может составлять 99.9% доступности, а SLO — 99.5% в течение месяца. Используйте инструменты мониторинга, такие как Prometheus, для сбора данных и Grafana для визуализации. Настройте алерты для уведомления о превышении порогов SLO.
Определение SLI и SLO: основные понятия
SLI и SLO являются ключевыми компонентами управления уровнем сервиса. SLI — это количественная метрика, которая измеряет уровень сервиса, предоставляемого пользователям. SLO, в свою очередь, представляет собой целевой уровень SLI, который команда стремится достичь. Например, если ваш сервис отвечает на запросы пользователей, SLI может быть определен как среднее время ответа, а SLO — как 95% запросов должны обрабатываться за 200 мс.
Важно, чтобы SLI и SLO были четко определены и согласованы с бизнес-целями. Это не только помогает в управлении ожиданиями пользователей, но и служит основой для анализа производительности сервиса.
Практический пример: настройка SLI и SLO для веб-сервиса
Рассмотрим пример настройки SLI и SLO для веб-сервиса. Предположим, у вас есть API, который обрабатывает запросы пользователей. Для начала определим SLI:
- Измерим среднее время ответа API за неделю.
- Запишем, сколько процентов запросов обрабатывается за 300 мс.
Для этого можно использовать Prometheus. Убедитесь, что у вас установлен и настроен Prometheus на вашем сервере. Вот пример конфигурации:
scrape_configs:- job_name: 'my_api'static_configs:- targets: ['localhost:8080']
Далее, создайте метрику для времени ответа:
http_request_duration_seconds{job="my_api"}Теперь определим SLO. Например, мы хотим, чтобы 95% запросов обрабатывались за 300 мс в течение месяца. Мы можем использовать следующую формулу:
SLO = (Количество успешных запросов / Общее количество запросов) * 100%
Если в течение месяца было 10000 запросов, и 9500 из них были успешными и выполнены в пределах времени, указанного в SLO, то:
SLO = (9500 / 10000) * 100% = 95%
Этот процесс поможет вам не только измерять SLI и SLO, но и улучшать качество сервиса, реагируя на проблемы, когда SLO не достигается.
Больше по теме
Часто задаваемые вопросы
SLO vs SLA?
SLO: internal target. SLA: legal contract с penalty. SLO всегда строже SLA (99.9% SLO → 99% SLA). Breach SLO → postmortem. Breach SLA → refund.
Реальные numbers?
AWS S3: 99.9%. Gmail: 99.97%. Stripe API: 99.99%. Для startup: 99% enough для MVP; 99.9% для B2B; 99.95%+ для critical infra.
Error budget ratio?
99.9% = 0.1% = 43m/мес. 99.99% = 4m/мес. Each 9 multiplies cost ~10x. Be realistic.
Enterno monitoring?
<a href="/monitors">Enterno Uptime Monitoring</a> tracks availability + latency + SSL. Alerts + SLA reports. Integrates с PagerDuty, Slack, Telegram.
Запустить инструмент, который описан в этой статье
Бесплатный тариф — 10 мониторов, проверки каждые 5 мин, без карты. Платные тарифы — интервал от 1 минуты и проверки из нескольких регионов.