Мониторинг метрик отслеживает числовые показатели системы во времени — загрузку CPU, объем памяти, задержку ответа, количество запросов в секунду. Мониторинг логов работает с текстовыми записями событий: кто, когда и что сделал, какая ошибка возникла и в каком модуле. Метрики отвечают на вопрос «что происходит с системой прямо сейчас», логи — на вопрос «почему это произошло». На практике оба вида дополняют друг друга: метрика показывает всплеск задержки, а лог объясняет, из-за какого запроса или исключения он возник.
Метрики: агрегированные данные для быстрой диагностики
Метрики собираются агентами-коллекторами с фиксированным интервалом — обычно от 5 до 60 секунд — и хранятся как time-series, то есть последовательность значений с меткой времени. Это делает их компактными и удобными для дашбордов и алертинга.
- показывают тренды и аномалии: рост потребления памяти за час, падение throughput после релиза;
- легко агрегируются — средние значения, перцентили p95, p99, суммы по кластеру;
- занимают мало места по сравнению с логами, поэтому ретеншн метрик обычно дольше;
- слабое место — низкая детализация: метрика покажет рост ошибок 500, но не укажет, какой именно запрос упал и почему.
Логи: подробный след событий
Лог — текстовая запись конкретного события: HTTP-запрос, исключение в коде, попытка авторизации, изменение конфигурации. В логах сохраняется контекст — stack trace, IP-адрес, ID пользователя, параметры запроса, — которого в метриках нет по определению.
- дают возможность восстановить точную последовательность действий перед сбоем;
- незаменимы при расследовании инцидентов и поиске root cause;
- требуют больше ресурсов на хранение, парсинг и индексацию, чем метрики;
- при высокой нагрузке объем логов быстро растет, поэтому часто применяют сэмплирование или фильтрацию по уровню — debug, info, error.
Зачем объединять оба вида мониторинга
При разборе инцидента метрики обычно первыми сигнализируют о проблеме через алерт, а логи и трейсы отвечают на вопрос, что пошло не так и в какой части системы искать причину. Если данные разнесены по разным системам, расследование замедляется — приходится переключаться между интерфейсами и вручную сопоставлять время событий.
Для крупной ИТ-инфраструктуры удобнее, когда мониторинг ит инфраструктуры объединяет логи, метрики и трейсы в едином интерфейсе, поддерживает Linux и Windows и построен на cloud-native архитектуре для масштабируемости и отказоустойчивости. Такие платформы обеспечивают распределенный сбор данных в реальном времени, а лицензии привязаны к количеству контролируемых хостов — доступны как срочные, так и бессрочные варианты.
Частые вопросы
Что дешевле хранить — логи или метрики?
Метрики компактнее и дешевле в хранении за счет агрегации, логи занимают больше места из-за текстового формата и детализации каждого события.
Можно ли обойтись только метриками без логов?
Для базового контроля состояния системы метрик достаточно, но при расследовании инцидентов без логов сложно найти точную причину сбоя — метрики показывают симптом, а не источник проблемы.
Что такое трейсинг и чем он отличается от логов и метрик?
Трейсинг фиксирует путь запроса через несколько сервисов и помогает понять, на каком этапе возникла задержка или ошибка; в отличие от логов он структурирован и привязан к конкретному запросу end-to-end.
Как часто нужно собирать метрики?
Обычно интервал сбора — от 5 до 60 секунд в зависимости от критичности сервиса; более частый сбор повышает точность, но увеличивает нагрузку на систему хранения.
Нужно ли хранить все логи одинаково долго?
Нет, часто применяют разные политики ретеншна: критические ошибки хранят дольше, debug-логи — несколько дней, это снижает затраты на хранение без потери значимых данных.