Устранение «слепых зон» при мониторинге гибридного облака

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

Что такое гибридная облачная среда?

Под гибридной облачной средой понимается ИТ-архитектура, которая объединяет по крайней мере одну облачную службу и локальные ресурсы, работающие в инфраструктуре, принадлежащей компании (независимо от того, находятся ли они внутри компании, в совместном владении или в стороннем ЦОД). Например, организация может использовать базовую систему ERP вместе с аварийным восстановлением в облаке AWS и вспомогательные системы (электронная почта, Office 365, система управления персоналом) по модели SaaS.

Итак, вы можете спросить, необходим ли по-прежнему мониторинг сети в облаке? Определенно да. Хотя сторонние SLA и гарантируют работоспособность услуг и приложений, ответственность за их качество и производительность несет команда эксплуатации ИТ. И вы не хотите оставаться без доказательств в ситуации, когда система важного клиента или сотрудника дает сбой в работе, а поставщик полностью отрицает свою ответственность. Недостаток прозрачности в конечном итоге приводит к неспособности контролировать качество обслуживания.

Проблемы мониторинга гибридного облака

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

• network telemetry (NetFlow, IPFIX etc.),
• flow logs in cloud (ie. Amazon VPC Flow Logs) 
• network packets (see Inside Data: Full Packet Capture Analysis whitepaper) 
• device logs,
• SNMP, WMI,
• agents and APIs,
• synthetic tests.

Благодаря сочетанию собственной и арендованной инфраструктур существует множество потенциальных точек сбоя в доставке приложений, но в целом вы столкнетесь с двумя основными проблемами.

Децентрализованное владение создает «слепые зоны»

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

Разрозненные стратегии мониторинга влияют на MTTR

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

• Используйте инструменты поставщика облачных услуг (см. Операционный пакет Google Cloud, Amazon CloudWatch, Azure Monitor).
• Используйте vTAP облачного провайдера для зеркалирования трафика на ваше устройство мониторинга (см. статьи Amazon VPC Traffic Mirroring, Google Packet Mirroring).
• Используйте сторонний vTAP (если это возможно в данной среде).
• Используйте flow-логи (если облачная платформа позволяет их экспорт).
• Воспользуйтесь специализированным агентным решением (New Relic, AppDynamics).
• Проблема в том, что, применяя различные стратегии мониторинга, вы можете получить точечное понимание, но упустить «общую картину».

Легкий инструмент для мониторинга производительности гибридного облака?

Так есть ли легкий способ, который охватит все важные сценарии использования в единой панели инструментов? Посмотрите на рис. 1 ниже, на котором показана простая гибридная облачная среда.