Привет, коллеги!
Если вы когда-нибудь просыпались среди ночи от алертов о том, что «всё упало», но не могли понять, почему — эта статья для вас. Поговорим о том, как построить нормальный мониторинг и перестать гадать на кофейной гуще.
В современном мире, где многие компании переходят на облачные технологии и используют managed-сервисы, важно понимать, какие метрики действительно необходимо мониторить самостоятельно, а какие можно оставить на усмотрение провайдера. Managed-ресурсы предоставляют множество преимуществ, включая автоматическое управление инфраструктурой и встроенные инструменты мониторинга. Однако это не освобождает вас от ответственности за мониторинг критичных для бизнеса метрик.
Автор статьи — Максим Гусев, спикер курса «SRE: data-driven подход к управлению надёжностью систем».
Системные метрики: железо и его причуды
CPU: не дайте процессору задохнуться
Load Average
Это среднее количество процессов, готовых к выполнению
Измеряется за 1,5 и 15 минут
Если больше количества ядер — система перегружена
Помогает предсказать проблемы с производительностью
Пример из жизни: Load Average 30 на 8-ядерной машине. Спойлер: кто-то запустил парсинг логов в проде.
CPU Usage по типам
User time — время выполнения пользовательских процессов
System time — время выполнения системных вызовов
Iowait — время ожидания ввода/вывода
Idle — время простоя
Steal — для виртуалок: время, украденное гипервизором
Реальный кейс: высокий iowait выдал проблему с логированием — приложение писало логи быстрее, чем диск успевал их сохранять.
Context Switches
Количество переключений между процессами
Высокие значения = потеря производительности
Помогает найти проблемы с многопоточностью
История из практики: однажды неправильная настройка thread pool привела к 100k+ переключений в секунду. Процессор был занят, но не работой.
Memory: когда «просто добавить оперативки» не помогает
Used/Available Memory
RSS (Resident Set Size) — реально используемая память
Virtual Memory — зарезервированная память
Heap — память для объектов в Java
Non-Heap — память для метаданных JVM
Dirty pages — данные, ожидающие записи на диск
Пример: приложение с memory leak съело всю память за 3 часа. Графики показали проблему за час до падения.
Swap Usage
Использование диска как дополнительной памяти
Swap In — чтение из swap в память
Swap Out — выгрузка из памяти в swap
Высокая активность swap = серьезное падение производительности
Кейс: система «тормозила», потому что база данных ушла в swap. Спасибо OOM Killer за «помощь».
Application Metrics: что творится в вашем коде
Response Time: почему пользователи жалуются на лаги
Latency (P95/P99)
P95 — время ответа для 95% запросов
P99 — время ответа для 99% запросов
Помогает найти «медленные» запросы
Важнее среднего времени ответа
Разбивка по эндпоинтам критична
Учет размера ответа
История: API с средним временем 100ms и P99 в 5 секунд. Причина? Один «тяжёлый» запрос к базе данных.
Apdex Score (Application Performance Index)
Оценка удовлетворенности пользователей от 0 до 1
T — целевое время ответа
Satisfied: < T (считается как 1)
Tolerating: < 4T (считается как 0.5)
Frustrated: > 4T (считается как 0)
Пример: если T = 300ms:
Отлично: < 300ms
Терпимо: < 1.2s
Плохо: > 1.2s.
Traffic: понимаем нагрузку
RPS (Requests per Second)
Количество запросов в секунду
Разбивка по:
HTTP методам (GET, POST, etc)
эндпоинтам
статус-кодам
Помогает планировать мощности
Кейс: резкий рост 404 ошибок выявил проблему с кешированием старых URL.
Concurrent Users
Количество одновременных пользователей
Active Sessions — активные сессии
User Flow — путь пользователя по системе
Geographic Distribution — распределение по регионам
Пример: пиковая нагрузка по понедельникам в 10 утра — готовимся заранее.
Database Metrics: когда база данных решает пойти погулять
Connection Pool
Active connections — активные соединения с базой
Idle connections — простаивающие соединения
Max connections — максимум возможных соединений
Connection timeouts — таймауты при получении соединения
Connection acquisition time — время получения соединения
История из жизни: connection leak в тестах убил прод через неделю после деплоя. Никто не ожидал, что тесты могут влиять на прод.
Query Performance
Query execution time — время выполнения запросов
Slow queries — запросы дольше определенного порога
Table scans — полные просмотры таблиц (спойлер: это обычно плохо)
Index usage — использование индексов
Lock contentions — конфликты блокировок
Buffer cache hit ratio — эффективность кеширования
Кейс: один «безобидный» JOIN без индекса положил всю базу. Привет, полночный дебаг!
Storage Metrics
Disk IOPS — операций ввода/вывода в секунду
Write/Read latency — задержки записи/чтения
Storage space usage — использование места
WAL/Binlog size — размер журнала транзакций
Пример: однажды логи транзакций съели все место на диске. Угадайте, когда это случилось? Правильно, в пятницу вечером!
Security Metrics: потому что параноик — это не диагноз, а профессия
Authentication Failures
Failed login attempts — неудачные попытки входа
Password reset requests — запросы сброса пароля
Brute force attempts — попытки подбора
IP-based patterns — подозрительные паттерны по IP
Geographic anomalies — странная география запросов
Пример: брутфорс атака из Китая в 3 часа ночи. Спасибо rate limiting и геоблокировке!
Resource Access Patterns
Unusual data access — нетипичные обращения к данным
Privilege escalations — повышение привилегий
API usage anomalies — аномалии использования API
Data exfiltration attempts — попытки выгрузки данных
Suspicious user behavior — подозрительное поведение пользователей
Кейс: необычный паттерн запросов выявил утечку данных через API. Кто-то «умный» пытался выгрузить всю базу клиентов…
Infrastructure Security
Port scan attempts — попытки сканирования портов
DDoS indicators — индикаторы DDoS атак
SSL/TLS issues — проблемы с сертификатами
Firewall denials — отказы файрвола
История: однажды забытый open port чуть не стал причиной взлома. Теперь у нас есть регулярные проверки.
Cost Metrics: чтобы финансовый директор не поседел раньше времени
Resource Utilization vs Cost
Cost per service — стоимость каждого сервиса
Resource efficiency — насколько эффективно используются ресурсы
Idle resources — простаивающие (и бесполезно дорогие) ресурсы
Autoscaling efficiency — насколько правильно работает автомасштабирование
Reserved vs On-demand usage — использование зарезервированных мощностей
История: забытый тестовый кластер «съел» месячный бюджет за неделю. Теперь у нас есть автоматическое удаление тестовых окружений.
Traffic Costs
Egress traffic — исходящий трафик (самый дорогой в облаках)
Inter-region traffic — трафик между регионами
API calls — вызовы API (особенно платные)
Storage operations — операции с хранилищем
CDN usage — использование CDN
Пример оптимизации: перенос бэкапов в тот же регион сэкономил 30% бюджета. Кто же знал, что межрегиональный трафик такой дорогой?
Роль провайдера в мониторинге
Что обычно берет на себя провайдер:
Базовый мониторинг инфраструктуры
Автоматическое масштабирование
DDoS защита
Базовые метрики безопасности
Мониторинг доступности сервисов.
Что остается на нашей совести:
Мониторинг бизнес-метрик
Специфичные для приложения метрики
Кастомные алерты и пороговые значения
Мониторинг затрат и оптимизация
End-to-end мониторинг пользовательского опыта.
Пример из жизни: провайдер радостно рапортовал, что «всё работает», пока пользователи жаловались на тормоза. Оказалось, что наш кеш был жив, но работал как улитка.
Общие рекомендации по настройке мониторинга
1. Начните с главного
Определите критичные бизнес-метрики
Настройте базовые системные метрики
Добавьте мониторинг основных компонентов
Кейс: начали с 500 метрик, закончили 50-ю действительно важными.
2. Настройте правильные алерты
Избегайте ложных срабатываний
Используйте разные уровни важности
Добавьте контекст к алертам
Настройте правильную маршрутизацию
История: после сотого ложного алерта в 3 часа ночи мы наконец научились их правильно настраивать.
3. Правильное хранение метрик
Определите retention policy для разных типов метрик
Настройте агрегацию для старых данных
Планируйте storage capacity заранее
Используйте разные интервалы сбора для разных метрик
Пример: CPU metrics каждые 10 секунд, а бизнес-метрики раз в минуту.
4. Визуализация, которая реально помогает
Создавайте тематические дашборды
Группируйте связанные метрики
Добавляйте аннотации для важных событий
Используйте разные типы графиков для разных данных
Кейс: после добавления deployment markers на графики поиск проблем ускорился в разы.
5. Автоматизация мониторинга
Используйте Infrastructure as Code для конфигурации
Автоматизируйте создание дашбордов
Настройте автоматическое реагирование на типовые проблемы
Регулярно проверяйте и обновляйте конфигурацию
История: автоматическое увеличение диска при 80% заполнении спасло не один наш уикенд.
Практические советы по внедрению
Для начинающих
Начните с базовых метрик:
CPU, Memory, Disk
Basic HTTP metrics
Error rates
Response times.
Добавьте простые алерты:
Disk space > 80%
Error rate > 1%
Response time P95 > 1s.
Для продвинутых
Внедрите трейсинг:
Distributed tracing
Service mesh metrics
Custom business metrics.
Настройте продвинутую аналитику:
Anomaly detection
Trend analysis
Capacity planning.
Типичные ошибки и как их избежать
Слишком много метрик
Проблема: Information overload
Решение: начните с малого, расширяйтесь по необходимости
Пример: из 1000 метрик реально использовались только 100.
Плохие алерты
Проблема: Alert fatigue
Решение: настраивайте значимые пороги, используйте агрегацию
Кейс: после пересмотра порогов количество ночных вызовов уменьшилось на 90%.
Отсутствие контекста
Проблема: сложно понять причину проблемы
Решение: добавляйте метаданные, связывайте метрики
Пример: добавление version tags помогло быстро находить проблемные деплои.
Заключение: как построить мониторинг, который реально работает
Ключевые принципы
Мониторинг должен приносить пользу
Не собирайте метрики «просто потому что можно»
Каждая метрика должна помогать принимать решения
Регулярно пересматривайте набор метрик.
Баланс между полнотой и простотой
Слишком много данных так же плохо, как и слишком мало
Фокусируйтесь на том, что действительно важно
Начинайте с простого, усложняйте по необходимости.
Культура мониторинга
Обучайте команду работе с метриками
Документируйте решения и настройки
Проводите регулярные ревью системы мониторинга.
Чек-лист для проверки вашего мониторинга
✅ Базовые метрики
CPU, Memory, Disk metrics настроены
Application metrics работают
Error tracking налажен
Performance metrics собираются.
✅ Алертинг
Критичные алерты настроены
Есть разные уровни важности
Настроена правильная маршрутизация
Документированы действия по алертам.
✅ Визуализация
Основные дашборды созданы
Метрики сгруппированы логически
Графики понятны и информативны
Есть документация по метрикам.
Напоследок: золотые правила мониторинга
Не усложняйте без необходимости
Простой и работающий мониторинг лучше сложного и сломанного
Начните с малого, растите постепенно.
Думайте о людях
Метрики должны быть понятны всей команде
Алерты должны быть действительно важными
Документация должна быть актуальной.
Регулярно улучшайте
Собирайте фидбек от команды
Анализируйте инциденты
Обновляйте пороги и правила.
P.S. И помните, хороший мониторинг — это не тот, который собирает все возможные метрики, а тот, который помогает решать реальные проблемы до того, как о них узнают пользователи.
P.P.S. Да, и ещё раз про пятничные деплои — настройте особые алерты на вечер пятницы. Почему-то именно в это время все любят заливать в прод «маленькие безобидные фиксы», которые потом чинит вся команда в субботу.
Полезные ссылки и инструменты
Популярные стеки мониторинга:
Инструменты для трейсинга:
Тулзы для логирования:
Удачного мониторинга! И пусть ваши графики всегда будут красивыми, а алерты — только по делу!
Больше полезного про метрики, алерты и не только — на курсе учебного центра Слёрм «SRE: Observability». Возьмите под контроль состояние системы! Программа и условия — по ссылке.
