Что хотят услышать интервьюеры:

Важно показать, что мониторинг строится не вокруг одного графика, а вокруг набора метрик, которые отражают здоровье системы. Обычно смотрят на ошибки, задержки, нагрузку на ресурсы и доступность сервиса. Хороший ответ связывает метрики с практическими действиями: когда считать систему деградирующей и что делать дальше.

Определение:

Для оценки состояния системы на этапе мониторинга обычно используют метрики доступности, ошибок, задержек, пропускной способности и потребления ресурсов.
Ключевая идея — отслеживать не только факт работы системы, но и качество её работы: насколько быстро она отвечает, как часто падает, хватает ли CPU, памяти, диска и сети.

Пример использования:

Например, для Python-сервиса можно смотреть:

p95/p99 latency — чтобы понять, не растёт ли время ответа;
error rate — чтобы увидеть долю 4xx/5xx и исключений;
RPS или throughput — чтобы понимать, справляется ли сервис с нагрузкой;
CPU, memory, disk I/O — чтобы находить упирание в ресурсы;
queue length или job lag — если есть фоновые задачи;
uptime и health checks — чтобы контролировать доступность.

# Пример логики оценки состояния по метрикам
def system_is_healthy(latency_p95, error_rate, cpu_usage, memory_usage):
    if error_rate > 0.05:
        return False
    if latency_p95 > 500:  # ms
        return False
    if cpu_usage > 85:
        return False
    if memory_usage > 90:
        return False
    return True

Пояснение кода:

Код показывает упрощённую проверку состояния системы по порогам метрик.
Если доля ошибок выше 5%, p95 задержки больше 500 мс или ресурсы почти закончились, система считается проблемной.
На практике такие проверки обычно не пишут вручную в бизнес-коде, а выносят в monitoring/alerting систему, где пороги можно настраивать отдельно.

Ключевые моменты:

Метрики выбирают по принципу «что реально влияет на пользователей и стабильность».
Минимальный набор: latency, error rate, throughput, CPU, memory, disk, network.
Для фоновых процессов важны длина очереди, лаг обработки и число ретраев.
Нужны не только текущие значения, но и тренды, p95/p99, аномалии и пороги.
Хороший мониторинг помогает отличать сбой приложения от нехватки ресурсов или проблем инфраструктуры.
Метрики должны быть связаны с алертами и понятными действиями при инциденте.

Какие показатели вы использовали для оценки состояния системы на этапе мониторинга?