Назовите реальную систему сбора и объясните, какие показатели связывали с сервисом: CPU, память, ограничения, рестарты и состояние контейнеров. Дополните их метриками приложения. В Kubernetes Metrics Server обслуживает ресурсные метрики для системных потребителей, но сам по себе не заменяет историческое хранилище и полный мониторинг.
Использовали ли вы мониторинг контейнеров и как он был организован?
Что наблюдать у контейнеров и приложений: ресурсы, рестарты, состояние оркестратора и пользовательские показатели.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Начните с окружения: Docker на отдельных машинах, Kubernetes или другая платформа. Затем опишите инструменты, свою роль и путь метрик до графика или алерта.
На уровне контейнера обычно полезны потребление CPU и памяти, ограничения ресурсов, throttling, рестарты и причины завершения. Но интерпретация зависит от runtime и доступных метрик. Рост памяти сам по себе не доказывает утечку, а низкая загрузка CPU не гарантирует исправность сервиса.
Для Kubernetes дополнительно объясните состояние Pod, готовность, размещение и события. Сведения о состоянии объектов и показатели фактического потребления ресурсов — разные источники. Resource metrics pipeline обеспечивает CPU/память для механизмов вроде HPA и kubectl top; Metrics Server не является полноценным долговременным мониторингом.
Укажите, как связывали изменяющиеся имена Pod с приложением и окружением, какие метки сохраняли и как избегали лишней кардинальности. Для диагностики полезно сопоставлять рестарты с релизом, нагрузкой, логами и состоянием зависимостей.
Не ограничивайтесь инфраструктурой: приложение может успешно работать как процесс, но возвращать ошибки пользователям. Поэтому рядом нужны задержка, доля ошибок и полезная производительность.
Если вы только пользовались готовыми дашбордами, скажите это. Затем приведите реальный пример, когда мониторинг помог найти причину проблемы, без выдуманных чисел и инцидентов.