Эпизод 48.
Метрики мониторинга для системного аналитика: RPS, CPU, брокеры, SLO, SLI, SLA и SRE
Мониторинг — это не только про DevOps.
Системный аналитик, который не понимает метрики, рискует написать требования, которые невозможно проверить, выполнить или измерить.
Telegram-канал сообщества: https://t.me/getanalysts
В этом выпуске разбираем мониторинг с точки зрения аналитика:
— что такое метрики мониторинга и откуда они берутся;
— как метрики связаны с нефункциональными требованиями;
— как описывать требования при пиковых нагрузках;
— какие метрики нужны для брокеров сообщений;
— чем отличаются SLO, SLI и SLA;
— что такое четыре золотых сигнала SRE от Google: latency, traffic, errors, saturation.
Отдельно говорим про реальный опыт проекта: как использовались Prometheus, Grafana и Kibana, и почему аналитику важно понимать, что именно команда будет мониторить при проблемах в продакшн.
Выпуск будет полезен системным и бизнес-аналитикам, которые работают с нефункциональными требованиями, интеграциями, архитектурой, брокерами сообщений, API и вопросами надёжности систем. Заберёте для себя много полезных примеров НФТ.
RuTube
VK
YouTube
Если плеер YouTube не запускается, необходимо включить VPN, либо переключиться на другой плеер (вкладки сверху).
Тайм-коды эпизода:
00:00 | Введение
00:18 | Почему нужно знать про метрики мониторинга системным аналитикам
01:47 | Что такое метрики мониторинга
05:03 | Нефункциональные требования, влияющие на мониторинг
09:15 | Этапы работы аналитика с метриками мониторинга
12:20 | Ключевые метрики мониторинга и их источники
14:18 | Детальный разбор каждой метрики мониторинга
18:59 | Загрузка CPU и требования при пиковых нагрузках
21:01 | Метрики мониторинга для брокеров сообщений
23:02 | Метрики SLO, SLI и SLA
26:21 | Инструменты для мониторинга: опыт реального проекта
31:44 | Золотые сигналы SRE от Google
34:10 | Итоги и чек-лист
Метрики мониторинга: полный гайд для системного аналитика
Метрики — это количественные показатели, отображающие фактическое состояние системы в цифрах (время отклика, ошибки, загрузка ресурсов). Они переводят абстрактное «быстро/надежно» в конкретные значения.
Роль аналитика: на каких этапах проекта нужно работать с мониторингом
- Сбор требований: Перевод бизнес-требований («хотим быстро») в измеримые НФТ (например, «95-й процентиль < 200 мс»),.
- Контроль контрактов: Использование метрик как доказательства выполнения условий ТЗ на этапе приемки.
- Прогнозирование: Анализ трендов роста нагрузки для своевременного масштабирования (до того, как система упадет),.
- Аргументация: Отказ в реализации «тяжелых» фич в пиковые часы на основе данных о ресурсах.
Группы метрик: что именно мы измеряем?
Важно собирать данные с каждого компонента системы: сервиса, frontend, базы данных (БД) и брокера сообщений.
А. Производительность (Performance)
- Latency (Латентность): Время, которое система «думает» над запросом,.
- RPS (Requests Per Second): Интенсивность потока запросов,.
- Процент ошибок: Доля неудачных запросов.
- 4xx (клиентские): Ошибки логики или валидации,.
- 5xx (серверные): Системные сбои или падения по тайм-ауту.
Б. Ресурсы (Infrastructure)
- CPU (Процессор): Загрузка > 80% — критический порог.
- RAM (Память): Если потребление только растет и не падает — это признак утечки памяти.
- Saturation (Насыщенность): Насколько система близка к пределу своих возможностей.
В. Очереди и Брокеры (Kafka/RabbitMQ)
- Consumer Lag (Лаг): Разница между записанными и прочитанными сообщениями. Показывает отставание обработки.
- Время в очереди: Сколько сообщение ждет, прежде чем его «заберут». Критично для бизнес-процессов (например, доставка SMS).
SLO, SLI, SLA
- SLO (Objective): Наша внутренняя цель (план).
Это про деньги и штрафы перед заказчиком. - SLI (Indicator): Реальный показатель на дашборде, который показывает как фактически работает система.
Всегда должен быть строже, чем SLA (создаем «запас прочности»). - SLA (Agreement): Юридический контракт по соблюдению метрик с санкциями за невыполнение.
«Золотые сигналы» SRE (от Google)
Если вы только начинаете внедрять мониторинг, сфокусируйтесь на этих четырех показателях, которые покрывают 90% проблем:
- Латентность (как долго).
- Трафик (сколько запросов).
- Ошибки (как часто падает).
- Насыщенность (сколько ресурсов осталось).
Инструменты мониторинга
- Grafana + Prometheus: Визуализация метрик в динамике. Позволяет видеть не «скучные цифры», а понятные графики,.
- ELK Stack (Elasticsearch, Kibana): Работа с логами. Помогает найти конкретную ошибку, когда «всё сломалось»,.
- OpenTelemetry: Универсальный стандарт для передачи данных мониторинга, не привязанный к конкретному вендору.
Примеры дашбордов мониторинга Grafana
1. Общий вид - вход в Grafana
2. Список дашбордов внутри Grafana
3. Пример дашборда Grafana: мониторинг сервиса
4. Пример дашборда Grafana: мониторинг хранилища s3
5. Пример дашборда Grafana: мониторинг брокера
Полезные ссылки
Подкаст
5 метрик мониторинга, которые решают 80% проблем
https://getanalyst.ru/podcast/monitoring
Скачать материалы по метрикам мониторинга для аналитиков
✔️ Чек-лист местрик мониторинга с примерами НФТ
✔️ Презентация к эпизоду
Ещё эпизоды, которые могут вас заинтересовать
Бесплатное обучение
Получайте полезные материалы и учитесь новому каждый день в наших социальных сетях.
*Instagram и LinkedIn — запрещенные на территории РФ организации
Контакты
+7 (499) 686-15-46
Лицензия №Л035-01255-50/01366872 от 28.08.2024
Практический опыт здесь, 2021-2026
Индивидуальный предприниматель
Алтунин Дмитрий Михайлович
ИНН 503610364488
Мы используем файлы cookie, для персонализации сервисов и повышения удобства пользования сайтом. Если вы не согласны на их использование, поменяйте настройки браузера.