Сегодня мониторинг инфраструктуры и приложений — лишь начальный этап ИТ-мониторинга, поскольку с появлением контейнеров, микрослужб и сред без серверов значительно увеличилось количество компонентов, которые необходимо отслеживать специалистам по разработке и операциям (DevOps).

Было время, когда определение ИТ-мониторинга было относительно простым. Теперь же ИТ-мониторинг — многосторонняя деятельность, охватывающая различные инструменты, процессы и стратегии. Сейчас уже бессмысленно говорить просто о «мониторинге», потому что существует множество его оттенков и типов, выходящих далеко за рамки мониторинга инфраструктуры и приложений.

Насколько сложен современный ландшафт ИТ-мониторинга? И как специалисты по разработке и операциям могут справиться с проблемами мониторинга? Попробуем разобраться.

Краткая история ИТ-мониторинга

Когда-то приложения и инфраструктура, в которой они размещались, были относительно простыми. Все компоненты выполнялись локально, о микрослужбах никто не слышал, а методы балансировки нагрузки были элементарными. Все сводилось к мониторингу приложений и инфраструктуры, а, в сущности, к контролю функционирования. Реализовать его не составляло труда с помощью базового инструментария, который можно было подготовить самостоятельно; часто для выявления проблем было достаточно простого сценария, который опрашивал серверы и проверял их отклик.

Впоследствии появились такие инструменты мониторинга, как Nagios (https://www.nagios.org/). С их помощью описанные выше процессы удалось автоматизировать. Дополнительно они могли выполнить некоторые простые проверки нагрузки, чтобы известить пользователя о том, что для данного компонента инфраструктуры превышен определенный порог. Тем не менее в основу этих инструментов были положены общие принципы контроля времени доступности: они обнаруживали, когда какой-то элемент переставал быть доступным.

Современный ИТ-мониторинг

Вернемся в день сегодняшний. Способы развертывания приложений сильно изменились. Инфраструктура часто состоит в значительной степени из программно определяемых компонентов, соотношение которых с физической инфраструктурой постоянно меняется. Одно приложение может быть развернуто локально, в «облаке», в нескольких «облаках» или с помощью некоторого сочетания перечисленных методов. Контейнеры, микрослужбы и среды без серверов значительно увеличили количество компонентов, которые необходимо отслеживать специалистам по разработке и эксплуатации.

Эти изменения помогут объяснить, почему сегодня ИТ-мониторинг (https://www.gartner.com/reviews/market/it-infrastructure-monitoring-tools) делится на несколько категорий.

  • Мониторинг времени доступности. Нам по-прежнему важно контролировать доступность приложений и служб, хотя мониторинг времени доступности сам по себе недостаточен для достижения всех целей.
  • Мониторинг инфраструктуры. Современный мониторинг инфраструктуры предполагает новый уровень сложности, так как значительная часть инфраструктуры, которую нужно контролировать, например виртуальные машины и контейнеры, создается программным образом, то есть, как сейчас говорят, «программно-определяема». Современным инструментам мониторинга инфраструктуры обычно приходится одновременно контролировать локальную и «облачную» инфраструктуру, поскольку многие компании развертывают рабочие нагрузки в средах обоих типов.
  • Мониторинг сети. Мониторинг сети (http://www.itprotoday.com/manage­ment-mobility/3-network-monitoring-systems) превратился в отдельную дисциплину. Теперь в процессе такого мониторинга выясняется, что имеется достаточная полоса пропускания; кроме того, сеть оптимизируется и выполняется балансировка нагрузки. В ходе мониторинга сети обычно требуется следить за программно-определяемыми сетями с постоянно меняющимися настройками. В некоторых случаях мониторинг сети пересекается с мониторингом безопасности, поскольку сеть — наиболее распространенная цель атаки для злоумышленников.
  • Наблюдение за производительностью приложений Application Performance Monitoring (APM). APM поможет идентифицировать и решить проблемы производительности. В его основе лежит идея о том, что недостаточно просто обеспечить постоянную работоспособность приложений и служб; необходимо поддерживать их работу на пике эффективности.
  • Мониторинг системы безопасности. Мониторинг системы безопасности, по-видимому, можно было бы разделить на несколько подкатегорий. Большинство инструментов мониторинга безопасности анализируют данные, чтобы обнаружить аномалии, свидетельствующие о вторжении, но на самом деле охват гораздо шире. Тест на проникновение также относится к этой категории, вместе с инструментами анализа настроек для поиска уязвимостей.
  • Мониторинг API. Концепция мониторинга прикладных интерфейсов API — более новая, нежели многие другие типы мониторинга, но несколько поставщиков предлагают инструменты, предназначенные специально для этой категории мониторинга. Это неудивительно, учитывая, как важны API-интерфейсы для организации коммуникаций между микрослужбами и доступа приложений к удаленным ресурсам, таким как «облачные» хранилища.
  • Мониторинг данных. Метод мониторинга данных менее известен среди специалистов по разработке и операциям. Но, как отметят администраторы данных, важен мониторинг наборов данных в поиске ошибок качества данных, особенно потому, что сегодня на основе данных строятся аналитика и автоматизация.
  • Мониторинг аварийного восстановления. Инструменты мониторинга аварийного восстановления помогут обеспечить надежное резервное копирование данных и приложений и быстрое восстановление в случае непредвиденных событий.
  • Мониторинг соответствия требованиям. Трудно полностью автоматизировать мониторинг соответствия требованиям, но это не мешает поставщикам предлагать программы мониторинга, помогающие обнаружить проблемы соответствия требованиям. Можно предположить, что по мере усложнения правил цифрового соответствия важность инструментов ИТ-мониторинга этих типов неуклонно возрастает.

Когда мониторинг слишком сложен

Наличие большого числа различных типов мониторинга затрудняет эффективный контроль инфраструктуры и приложений. Это тем более верно потому, что в эпоху концепции DevOps предполагается, что каждый инженер знаком со всеми функциями ИТ-подразделения. Если вы считаете, например, что мониторинг сети должен быть заботой исключительно администраторов сети или что только инженеры по безопасности должны заниматься мониторингом безопасности, то ваш подход не укладывается в рамки DevOps. Вы сторонник концепции изолированных областей.

Каким образом могут специалисты по разработке и эксплуатации справляться с разнообразными и сложными задачами мониторинга в современной ИТ-среде? Очевидно, автоматизация — важная часть ответа на этот вопрос. Вам помогут такие платформы, как PagerDuty, VictorOps и OpsGenie, которые, в сущности, являются программами мониторинга для программных продуктов мониторинга.

Но возможности автоматизации небезграничны. В определенный момент группам DevOps приходится признать, что мониторинг — сложная задача, требующая серьезных затрат времени и ресурсов. В действительности, учитывая значительно возросшую в последние годы сложность процессов и инструментов мониторинга, идея полной автоматизации мониторинга выглядит нереалистично. Вероятно, теперь на мониторинг придется тратить еще больше времени и сил, чем в прошлом.

С таким положением вещей трудно смириться. Большинство ИТ-специалистов не считают мониторинг увлекательным занятием. Он воспринимается как помеха, отвлекающая от основной деятельности.

Несмотря ни на что, мониторинг очень важен — и сложен. Следует это признать и позаботиться о том, чтобы обеспечить все его нужды необходимым персоналом, процессами и инструментарием.