Наблюдаемость и мониторинг
Мониторинг отвечает на вопрос «здоров ли сервис прямо сейчас?», а наблюдаемость — на «почему он ведёт себя так?». Система непрерывно собирает сигналы о хостах и сервисах, хранит их во времени, визуализирует и поднимает алерты при пересечении порога. Цель — обнаруживать сбои и деградацию рано и давать данные для диагностики, пока проблема не стала инцидентом.
Тема связывает четыре навыка senior-инженера эксплуатации. Первый — понимать, зачем нужен мониторинг и какими инструментами он строится. Второй — различать три столпа: метрики отвечают «здоров ли?», логи — «что случилось?», трейсы — «где тормозит?». Третий — читать конкретные сигналы, прежде всего load average, и по ним локализовать узкое место (CPU, диск, память). Четвёртый — приводить конфигурацию сотен хостов к единому состоянию идемпотентно, а не руками. Разбор — в слоях ниже.
Карта темы
- Основы мониторинга — цель системы мониторинга, порядок «сбор → хранение → визуализация → алерт» и инструменты.
- Метрики, логи и трейсы — три столпа наблюдаемости и на какой вопрос отвечает каждый.
- Load average — что измеряет средняя нагрузка, как читать её тренд и связь с числом ядер.
- Управление конфигурацией — идемпотентные инструменты вроде Ansible и раскатка агентов на тысячи хостов.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Считать метрики, логи и трейсы взаимозаменяемыми | Не тот инструмент под вопрос — диагностика буксует |
| Читать load average без учёта числа ядер | «50 — катастрофа» на 64-ядерном хосте — ложная тревога |
| Путать высокий load с высоким CPU | Load может расти из-за ожидания I/O при простое CPU |
| Хранить только логи, без метрик | Нет дешёвых агрегатов и трендов — сбой виден поздно |
| Настраивать хосты вручную | Дрейф конфигурации; на 1000 хостов — неуправляемо |
| Считать playbook неидемпотентным | Боязнь повторного запуска; теряется главное свойство инструмента |
Значение для собеседований
На senior-уровне наблюдаемость проверяют практикой: показывают экран top или набор метрик и просят назвать узкое место. Кандидат, который по «load 38 на 4 ядрах, CPU простаивает, wa 86%» сразу говорит «хост упирается в диск, а не в CPU», демонстрирует то, ради чего задают вопрос, — умение диагностировать по сигналам.
Что обычно проверяют:
- Цель мониторинга и типичные инструменты (Prometheus, Zabbix, Grafana, ELK).
- Три столпа и на какой вопрос отвечает каждый.
- Чтение load average относительно числа ядер и по тренду 1/5/15 минут.
- Идемпотентность и раскатку агента на тысячи хостов через управление конфигурацией.
Типичный неверный ответ: «высокий load average — значит перегружен процессор». Не обязательно: load считает и процессы в непрерываемом ожидании I/O, поэтому при высокой wa и простое CPU виноват диск. И «настрою хосты по SSH руками» — на масштабе это ведёт к дрейфу конфигурации.