7. Особенности мониторинга компонентов системы

1. Особенности мониторинга компонентов системы

2. Основные цели

1
2
3
4
Планирование емкости
(Capacity Planning):
Снижение времени
простоя (Increase
Availability):
Снижение среднего
времени
восстановления (MTTR
- Mean Time To Repair):
Понимание поведения
системы
(Understanding System
Behavior):
Быстро находить корневую
причину сбоя.
Как система ведет себя под
нагрузкой? Где "узкие
места" (bottlenecks)?
На основе трендов
предсказать, когда
потребуются новые ресурсы
(диск, ЦП, память).
Обнаруживать проблемы
быстрее пользователей.

3. Подходы к мониторингу

Наивный мониторинг
("Работает/Не работает")
Проверка, отвечает ли сервер по ping.
Не дает никакой информации
о качестве работы
Мониторинг на основе
ресурсов ("Как себя
чувствуют серверы?")
Сбор метрик по ЦП, памяти, дискам.
Лучше, но все равно не говорит о том,
удовлетворены ли пользователи.
Мониторинг на основе
приложения/бизнес-логики
("Довольны ли
пользователи?")
Фокус на метриках, которые напрямую
влияют на пользовательский опыт:
скорость загрузки страницы, частота
ошибок при оплате, успешность
регистрации.

4. Четыре золотых сигнала

Задержка (Latency)
Ошибки (Errors)
Время, затраченное на обслуживание
одного запроса.
Частота запросов, которые завершаются
неудачей
Явные ошибки: HTTP 5xx, HTTP 4xx, исключения в
логах.
Неявные ошибки: Ответы с кодом 200 OK, но с
некорректным содержимым (например, пустой список
товаров вместо результатов поиска).
Ошибки по бизнес-логике: Неудачные попытки оплаты,
ошибочные заказы.
Трафик (Traffic)
Насыщение (Saturation)
Мера того, насколько система
востребована.
Насколько "полон" ваш ресурс.
Для веб-сервиса: HTTP-запросы в секунду.
Для стриминга: Мбит/секунду.
Для базы данных: Количество транзакций или запросов
в секунду.
Показывает нагрузку в процентах от максимальной
возможности системы.
Особенность: Ресурс может быть насыщен даже до
достижения 100% использования. Например, задержка
дисковых операций может резко вырасти уже при 70%
нагрузке.
Примеры: Загрузка CPU, использование оперативной
памяти, использование пропускной способности сети,
количество свободных файловых дескрипторов.

5. Мониторинг Процессора

Ключевые метрики и их интерпретация:
cpu_usage_percent (Общая загрузка):
Что показывает: Процент времени, когда CPU не находился в режиме простоя (idle).
Норма: Высокая загрузка (80-90%) сама по себе не является проблемой, если система отзывчива. Это
означает, что вы эффективно используете ресурсы.
Проблема: Постоянная загрузка >90% в сочетании с высокой нагрузкой и ростом задержки.

6. Мониторинг Процессора

Ключевые метрики и их интерпретация:
load average (Средняя нагрузка) - САМАЯ ВАЖНАЯ МЕТРИКА:
Что показывает: Среднее количество процессов, находящихся в состоянии "готов к выполнению" (Runnable)
или ожидающих ресурсов ввода-вывода (Uninterruptible Sleep, т.е. D состояние в top) за 1, 5 и 15 минут.
Как интерпретировать: Значение нужно сравнивать с количеством ядер CPU.
Для одноядерного CPU: load average = 1.00 означает, что ядро загружено на 100%.
Для 4-ядерного CPU: load average = 4.00 означает полную загрузку.
load average > (число ядер) означает, что процессы начинают выстраиваться в очередь. Чем выше
значение, тем длиннее очередь и больше задержка.
Пример: На 8-ядерном сервере load average постоянно выше 8 — это сигнал о нехватке вычислительных
мощностей.

7. Мониторинг Процессора

Ключевые метрики и их интерпретация:
cpu_iowait_percent (Ожидание ввода-вывода):
Что показывает: Процент времени, когда ЦП простаивал, потому что ждал завершения операций с
диском или сетью.
Интерпретация: Высокий iowait (например, >10-20%) — это почти никогда не проблема CPU! Это
явный индикатор того, что основное "узкое место" (bottleneck) — это диски или сеть. Процессоры ждут,
пока медленные подсистемы подадут им данные.
Инструменты: top, htop, vmstat, mpstat, node_exporter (метрики node_load1,5,15, node_cpu_seconds_total).

8. Мониторинг Памяти (RAM)

memory_used_percent (Общее использование):
Особенность: В Linux свободная память — это потраченная впустую память. Ядро использует
свободную RAM для кэширования дисковых операций (cache/buffer). Поэтому метрика "used" часто
вводит в заблуждение.
Более точная метрика: memory_available или memory_freeable. Она учитывает, что кэш можно быстро
освободить для нужд приложений.

9. Мониторинг Памяти (RAM)

swap_used и swap_activity (Использование и активность подкачки):
Факт №1: Само по себе использование swap (например, 1-2 Гб) не страшно, если нет активной
записи/чтения.
Факт №2: Активная подкачка (si - swap in, so - swap out) — это КАТАСТРОФА для
производительности. Диск в тысячи раз медленнее RAM. Когда система начинает активно "свопиться", она
увязает в операциях ввода-вывода, что приводит к лавинообразному росту load average и iowait, и полному
"зависанию" сервера.
Правило: На высоконагруженных серверах swap часто отключают полностью, чтобы избежать риска такого
сценария.
Инструменты: free -h (обращайте внимание на столбец available), vmstat 1 (смотрите на si/so), cat /proc/meminfo.

10. Мониторинг Дисков (Disks, I/O Subsystem)

disk_used_percent (Занятое место):
Проблема: Файловые системы резко замедляются, когда свободного места остается мало
(<10-15%). Могут возникать сбои в работе приложений.
Стратегия мониторинга: Ставить предупреждение (warning) на 80% и критическое
(critical) на 90%.
disk_await или disk_latency (Средняя задержка операции ввода-вывода):
Самая важная метрика для пользовательского опыта! Показывает, сколько времени в
среднем запрос проводит в очереди и на выполнение (в миллисекундах).
Нормы:
HDD (механические): 5-15 мс — норма, >20 мс — проблема.
SSD (твердотельные): 0.1-1 мс — норма, >5 мс — проблема.
Высокая задержка — прямой признак перегруженности дисковой подсистемы.

11. Мониторинг Дисков (Disks, I/O Subsystem)

disk_utilization (Утилизация):
Что показывает: Процент времени, когда диск был занят обработкой
запросов.
Интерпретация: 100% утилизация означает, что диск постоянно занят.
Это приводит к росту disk_await.
disk_queue_length (Длина очереди):
Среднее количество запросов, ожидающих обработки диском.
Растущая очередь при высокой утилизации подтверждает, что диск не
справляется с нагрузкой.
Инструменты: iostat -x 1 (основной инструмент), iotop, node_exporter (метрики node_disk_*).

12. Четыре золотых сигнала

Оповещайте о симптомах, а не
о причинах.
Избегайте "шумных"
оповещений.
Пользователю все равно, что CPU
загружен, ему важно, что сайт тормозит.
Если на оповещение постоянно не
реагируют, его нужно либо удалить, либо
перенести в более низкий уровень. "Alert
fatigue" (усталость от оповещений) —
главный враг.
Настраивайте многоуровневые
оповещения
Каждое оповещение должно
иметь runbook
Warning (Предупреждение): Что-то требует
внимания инженера в рабочее время. (Диск
заполнен на 85%).
Critical (Критическое): Проблема,
требующая немедленного вмешательства,
днем и ночью. (Сайт недоступен, ошибки
при оплате).
Документ, в котором описано: что означает
это оповещение, по каким шагам его
исследовать, как исправить проблему.

13. Логирование (Logging)

Структурированное
логирование (Structured
Logging)
Используйте JSON вместо простого
текста.
Используйте
корреляционные
идентификаторы (Correlation
ID/Trace ID)
При прохождении запроса через несколько
сервисов (микросервисная архитектура)
добавляйте к каждому логируемому событию
уникальный ID запроса. Это позволит собрать
"историю жизни" одного запроса по логам
всех сервисов.

14. Уровни логирования

1
DEBUG
Детальная информация для
отладки. Включается только
на тестовых стендах.
2
3
4
INFO
WARN
ERROR
Информационные
сообщения о нормальной
работе (запуск/остановка
сервиса, успешные
операции).
Подозрительная ситуация,
которая пока не является
ошибкой (например,
повторная попытка
соединения).
Ошибка, которая повлияла
на один конкретный запрос,
но не привела к падению
всего сервиса.
5
FATAL
Критическая ошибка, после
которой приложение не
может продолжать работу.