|
Рубрика:
Администрирование /
Мониторинг
|
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
Какая задача мониторинга
отнимает больше всего времени?
Многие системные администраторы тратят до 30% рабочего времени на рутину мониторинга. Но никто не говорит, какая именно рутина мешает.
Комментируют ситуацию Максим Захаренко, СЕО «Облакотека» и Ришат Салихов, старший системный архитектор ICL Services.
 Максим Захаренко,
СЕО «Облакотека»
«Идеальный порог — это всегда баланс. С одной стороны, важно не пропустить реальную проблему, с другой — не перегрузить команду шумом. На практике это достигается только через настройку под конкретную инфраструктуру и регулярный пересмотр правил»
Анализируя работу инфраструктурных команд, можно заметить, что больше всего времени съедает не настройка мониторинга, а борьба с его последствиями.
Самая болезненная тема — это алерты. Когда система генерирует слишком много уведомлений, большая часть из которых не требует действий, команда постепенно перестает им доверять. В итоге важные сигналы теряются на фоне шума. И люди тратят часы не на решение проблем, а на фильтрацию того, что вообще стоит внимания.
Если говорить про конкретный пример, то мы, например, недавно отключали алерты по кратковременным всплескам нагрузки на CPU. Они срабатывали слишком часто, но не влияли на пользовательский опыт и в итоге только отвлекали команду. После корректировки порогов количество ложных срабатываний заметно снизилось.
На втором месте — анализ логов. В теории все логируется, но на практике быстро найти причину инцидента сложно: данные разбросаны, нет единого контекста, поиск неудобный. Особенно это заметно в распределённых системах и облачных средах.
Ещё одна проблема — интеграция. У компаний редко бывает один инструмент. Обычно это набор решений, которые слабо связаны между собой. В результате, чтобы понять картину, нужно переключаться между несколькими системами.
Обработка инцидентов тоже часто занимает больше времени, чем должна. Причина простая — нет четких runbook’ов. Каждый раз команда фактически заново решает одну и ту же задачу вместо того, чтобы следовать отработанному сценарию. Это увеличивает время, затраченное на восстановления сервисов, и создает дополнительную нагрузку на специалистов. При этом накопленный опыт не фиксируется и не масштабируется, а значит, проблема воспроизводится от инцидента к инциденту.
Идеальный порог — это всегда баланс. С одной стороны, важно не пропустить реальную проблему, с другой — не перегрузить команду шумом. На практике это достигается только через настройку под конкретную инфраструктуру и регулярный пересмотр правил.
Если обобщить, то главная задача сегодня — не просто собирать метрики, а выстраивать осмысленный мониторинг, который помогает принимать решения, а не создает дополнительную нагрузку.
 Ришат Салихов,
старший системный архитектор ICL Services
«Корректные пороги и сам мониторинг в рабочем состоянии — это всегда результат постепенной настройки. Сначала система запускается с базовыми параметрами, затем накапливается статистика, и уже на ее основе все адаптируется под реальные условия. Универсального решения здесь не существует»
Если смотреть на проблему шире, то дело не столько в самих задачах мониторинга, сколько в отсутствии выстроенных процессов. Когда мониторинг внедрен формально и не до конца настроен, инженеры постоянно сталкиваются с одними и теми же ситуациями и каждый раз решают их заново. В итоге время уходит не на развитие или улучшение системы, а повторяющуюся ручную работу.
Если говорить про конкретную рутину, то больше всего времени, как правило, съедают ложные срабатывания. Это следствие некорректно настроенных алертов: система сигнализирует о проблеме, инженер подключается, начинает разбираться , в итоге выясняется, что ничего критичного не произошло. В таком режиме большая часть времени уходит не на устранение инцидентов, а на проверку их релевантности.
При этом многие другие задачи, которые обычно упоминаются — интеграции, отчетность, работа с логами — на практике не являются основной ежедневной нагрузкой. Чаще это либо разовые активности, либо задачи, которые настраиваются один раз и дальше требуют минимального участия.
Что касается отключения алертов, чаще всего из мониторинга убирают не критичные метрики утилизации инфраструктуры. Например, второстепенные показатели по сети или отдельные параметры по дискам, которые не влияют напрямую на доступность сервисов, но при этом создают дополнительный шум и отвлекают инженеров.
Говоря об идеальном пороге срабатывания, универсального значения здесь нет. Да, существуют базовые ориентиры — например, по загрузке CPU, но дальше все зависит от конкретной инфраструктуры. В нагруженных системах такие пороги обычно сдвигаются выше, потому что стандартные значения будут давать слишком много срабатываний. В менее загруженных их могут снижать, чтобы вовремя заметить аномалии.
В целом корректные пороги и сам мониторинг в рабочем состоянии — это всегда результат постепенной настройки. Сначала система запускается с базовыми параметрами, затем накапливается статистика, и уже на ее основе все адаптируется под реальные условия. Универсального решения здесь не существует.
Так, грамотно выстроенные процессы позволят тонко настроить мониторинг — это означает выявлять «возможную» проблему (с помощью превентивных механизмов) и снизить трудозатраты на решение инцидентов (оперативное оповещение об инциденте с описанием корневой причины и с возможным сценарием устранения проблем).
Ключевые слова: мониторинг, алерты, шум, порог срабатывания, логи
Подпишитесь на журнал
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
Какая задача мониторинга отнимает больше всего времени?
