Учимся разбирать сбои по метрикам, логам и трассировкам. Сначала изучите теорию и интерактивные модели, затем выполните три практических задания и тест внизу страницы. Всё сохраняется в этом браузере автоматически.
В прошлой работе вы описали требования к «Кампусу». Теперь представьте утро понедельника: преподаватели жалуются, что сохранение оценок зависает. Нужно установить, что сломалось, где и когда, а не сразу перезагружать все серверы.
Мониторинг систематически собирает сигналы о состоянии системы. Диагностика анализирует эти сигналы, чтобы сузить круг причин. Наблюдаемость описывает возможность исследовать внутреннее состояние по доступным сигналам; её часто строят вокруг метрик, журналов и трассировок.
Ошибка в браузере может появиться из-за недоступности API, медленного запроса к БД или проблем сети. Симптом — ещё не корневая причина.
| Сигнал | Какие вопросы отвечает | Пример для «Кампуса» |
|---|---|---|
| Метрика | Сколько? Как менялось во времени? | Процент HTTP 5xx, p95, загрузка CPU |
| Лог | Какое событие произошло? | Ошибка timeout при обращении к PostgreSQL |
| Трассировка | Где потрачено время конкретного запроса? | API 50 мс → обращение к БД 1800 мс |
Метрики удобны для поиска момента ухудшения. Логи раскрывают отдельные события и контекст, но могут быть шумными. Трассировки связывают шаги одного запроса через несколько компонентов. Эти источники дополняют друг друга.
Для веб-сервисов полезна система из четырёх сигналов: latency (задержка), traffic (интенсивность запросов), errors (ошибки), saturation (насыщение ресурсов). Это практическая модель из SRE, а не полный список показателей для любого оборудования.
| Сигнал | Возможная метрика | Вопрос |
|---|---|---|
| Latency | p95 response time в мс | Как долго ожидает пользователь? |
| Traffic | Запросов в секунду (RPS) | Сколько работы поступает? |
| Errors | Доля ошибок по выбранному определению | Как часто запрос не выполняет цель? |
| Saturation | Очередь БД, CPU, pool соединений | Насколько близки к пределу? |
В мониторинге типа Prometheus counter предназначен для накапливаемого счётчика, который может сброситься при перезапуске; gauge может увеличиваться и уменьшаться. Для распределения задержек часто применяют histogram. Нельзя измерять растущим счётчиком число открытых соединений, которое свободно уменьшается.
Последовательность первичной диагностики помогает не действовать хаотично: подтвердить проблему → определить затронутых пользователей → посмотреть динамику → сопоставить события → локализовать подозрительный компонент → проверить гипотезу. Если есть риск потери данных, приоритетом становится безопасное ограничение последствий.
Переключайте сценарии. Все значения ниже смоделированы для обучения, а не получены с настоящего сервера. Сравните признаки и сформулируйте первичную гипотезу.
Если после публикации версии резко вырос HTTP 500, это повод проверить изменения кода и конфигурации. Но совпадение по времени не заменяет доказательства причины.
Оповещение полезно, если позволяет выполнить понятное действие. «CPU выше 80% одну секунду» часто вызывает шум; «ошибки запросов больше 5% за 5 минут и пользовательская операция недоступна» отражает значимый симптом. Конкретный порог выбирают по профилю системы.
| Приоритет | Пример | Типичное действие |
|---|---|---|
| Критический | Массово недоступен вход в систему | Немедленно организовать реагирование |
| Высокий | Сохранение оценок периодически падает | Локализовать, ограничить влияние |
| Низкий | Растёт время фонового отчёта | Анализировать в плановом порядке |
Не записывайте пароли, токены авторизации, персональные данные целиком. Полезнее хранить время, код ошибки, идентификатор запроса, компонент и безопасный контекст. Примеры логов в этой работе специально обезличены.
Время с Z записано в UTC. При сопоставлении событий следует учитывать временные зоны и синхронизацию часов.
Мониторинг без представления о нормальном поведении не даёт устойчивых выводов. Базовая линия (baseline) — ориентир, полученный по типичным измерениям. В «Кампусе» за час до начала занятий нагрузка ниже, чем сразу после публикации оценок. Поэтому сравнение только с одной глобальной средней величиной может порождать ложные тревоги.
| Период | Средний RPS | p95 ответа | Ошибки |
|---|---|---|---|
| Обычный будний день, 08:00 | 80 | 250 мс | 0,2% |
| Публикация оценок, 16:00 | 450 | 620 мс | 0,4% |
| Инцидент при публикации | 430 | 4 200 мс | 9,1% |
В таблице показатели учебные. Трафик 430 RPS сам по себе допустим в период публикации, но резкое изменение задержек и ошибок при сходной нагрузке — повод расследовать. Полезно учитывать будни, выходные, релизы и изменения инфраструктуры.
Ложноположительное оповещение сообщает о проблеме там, где её нет; ложноотрицательное пропускает реальное нарушение. Хороший порог ищет компромисс между чувствительностью и шумом.
Прежде чем писать «сервер упал», важно подтвердить уровень отказа. Сервер может отвечать на ICMP, но приложение возвращать HTTP 503; DNS может указывать неправильный адрес при исправном API. Поэтому инструменты проверяют разные слои.
| Инструмент | Что проверяет | О чём помнить |
|---|---|---|
ping host | Достижимость по ICMP | ICMP может быть запрещён, приложение всё равно может работать |
curl -I https://example.org | HTTP-ответ для HEAD-запроса | Сайт может по-разному обрабатывать HEAD и GET |
df -h | Использование файловых систем в Linux | Заполнение диска — гипотеза, а не причина любого сбоя |
free -h | Использование памяти в Linux | ОС использует память под кэши; важен контекст |
| Диспетчер задач Windows | CPU, память, процессы | Уровень процесса не равен здоровью всего сервиса |
В этой работе не нужно выполнять команды на чужой инфраструктуре. Если преподаватель выдаёт лабораторную машину, результаты фиксируют с указанием времени и проверяемого узла.
Инженерный отчёт полезнее фразы «всё тормозило». В хронологии различают начало деградации, момент обнаружения, время реакции, предпринятое изменение и момент подтверждённого восстановления. Эти времена могут не совпадать.
| Время | Наблюдаемое событие | Вывод |
|---|---|---|
| 09:10 | Начало роста HTTP 5xx | Проблема уже влияет на часть запросов |
| 09:13 | Сработал алерт | Задержка обнаружения 3 мин |
| 09:18 | Инженер проверил БД и логи | Есть первичная гипотеза |
| 09:25 | Отключено проблемное изменение | Предпринято действие |
| 09:29 | Ошибки вернулись в норму | Услуга восстановлена по критерию |
В этом примере интервал деградации длится около 19 минут — с 09:10 по 09:29. Окончательное время доступности зависит от SLI, но именно такие границы нужны для прозрачного расчёта. После стабилизации команда фиксирует факторы, затруднившие обнаружение, и проверяет, нужны ли новые метрики или тесты.
Используйте сценарии A–D интерактивной панели. Задача — разделять наблюдение, гипотезу и проверку гипотезы. Нельзя объявлять корневую причину только по цвету виджета.
Выберите один ответ в каждом вопросе и нажмите «Проверить тест». После проверки появятся разборы. Практические задания и развёрнутые вопросы проверяет преподаватель — в процентах они не учитываются.
Эти вопросы оценивает преподаватель. Не копируйте определения: приведите собственный аргумент и, где необходимо, расчёт или пример.
Теоретические сведения адаптированы для обучения. Интерактивные расчёты и сценарии — учебные модели, не измерения работающей инфраструктуры. Внешние ссылки нужны только для дополнительного чтения: сама работа открывается без интернета.
Нажмите «Отправить работу — сохранить PDF» и в диалоге печати выберите «Сохранить как PDF». В PDF попадут ФИО, ответы, результат тестирования и задания. Никакие данные не отправляются на сервер.