Руководство по принятию решений о ведении журналов и создании отчетов

Статья
03/16/2023

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

Точка перегиба при определении стратегии ведения журналов и отчетов в облаке основана в первую очередь на следующих принципах:

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

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

Планирование инфраструктуры мониторинга

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

Вопрос	Облачная среда	Интеграция с локальными системами	Гибридный мониторинг	Агрегация шлюза
Имеется ли у вас существующая локальная инфраструктура мониторинга?	Нет	Да	Да	Нет
Есть ли у вас требования, препятствующие хранению данных журналов во внешних хранилищах?	Нет	Да	Нет	Нет
Вам необходимо интегрировать облачный мониторинг с локальными системами?	Нет	Нет	Да	Нет
Необходимо ли обрабатывать или фильтровать данные телеметрии перед их отправкой в системы мониторинга?	Нет	Нет	Нет	Да

Облачная среда

Облачное решение SaaS, например Azure Monitor, является более простым выбором, если:

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

В этом сценарии все данные журнала записываются и хранятся в облаке. Платформа Azure и Azure Monitor предоставляют средства ведения журналов и отчетов, которые обрабатывают и передают информацию ит-специалистам.

При необходимости реализуйте пользовательские решения ведения журнала на основе Azure Monitor для каждой подписки или рабочей нагрузки в небольших или экспериментальных развертываниях. Эти решения централизованы для отслеживания данных журнала во всем облачном пространстве.

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

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

Интеграция с локальными системами

Могут потребоваться значительные усилия по изменению приложений и служб, переносимых в облако, чтобы поддерживать облачные решения для ведения журналов и отчетности, таких как Azure Monitor. В этом случае рекомендуется разрешить рабочим нагрузкам продолжать отправлять данные телеметрии в существующие локальные системы.

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

Этот подход основан на существующих инвестициях в средства мониторинга с ограниченными изменениями каких-либо облачных приложений или служб. Кроме того, этот подход часто является самым быстрым способом поддержки мониторинга во время миграции lift-and-shift. Но он не будет собирать данные журнала, созданные облачными ресурсами PaaS и SaaS. Он также пропускает журналы, связанные с виртуальными машинами, созданные самой облачной платформой, например состояние виртуальной машины. В результате этот шаблон должен быть временным решением, пока не будет реализовано более комплексное решение для гибридного мониторинга.

Предположения, доступные только для локальной среды: При использовании локальной системы ведения журнала и отчетности предполагается следующее:

Данные журнала сохраняются только в локальной среде. Храните данные журнала таким образом либо в соответствии с техническими требованиями, либо в соответствии с нормативными требованиями или требованиями политики.
Локальные системы не поддерживают гибридные решения для ведения журналов и отчетов или агрегирования шлюзов.
Облачные приложения могут отправлять данные телеметрии непосредственно в локальные системы ведения журнала. Или агенты мониторинга, которые передают данные в локальную среду, можно развернуть на виртуальных машинах рабочей нагрузки.
Рабочие нагрузки не зависят от служб PaaS или SaaS, требующих ведения журналов и создания отчетов в облаке.

Агрегация шлюза

Служба агрегирования шлюза данных журнала может потребоваться для сценариев, в которых:

Объем данных телеметрии в облаке велик.
Существующие локальные системы мониторинга нуждаются в изменении данных журнала перед обработкой.

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

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

Предположения относительно агрегации шлюза:

Ожидаются очень большие объемы данных телеметрии из облачных приложений или служб.
Перед отправкой данных телеметрии в системы мониторинга необходимо отформатировать или иным образом оптимизировать их.
Ваши системы мониторинга используют API или другие механизмы для приема данных журналов после их обработки шлюзом.

Гибридный мониторинг (локальный)

Гибридное решение для мониторинга объединяет данные журналов из локальных и облачных ресурсов, обеспечивая интегрированное представление рабочего состояния ИТ-среды.

При наличии инвестиций в локальные системы мониторинга, которые трудно или дорого заменить, может потребоваться интегрировать данные телеметрии из облачных рабочих нагрузок в имеющиеся локальные решения для мониторинга. В гибридной локальной системе мониторинга локальные данные телеметрии продолжают использовать существующую локальную систему мониторинга. Облачные данные телеметрии отправляются непосредственно в локальную систему мониторинга или сохраняются в Azure Monitor, где они регулярно компилируются и передаются в локальную систему.

Допущения локального гибридного мониторинга: Использование локальной системы ведения журналов и отчетов для гибридного мониторинга предполагает следующие условия:

Для мониторинга облачных рабочих нагрузок необходимо использовать существующие локальные системы отчетов.
Вы сохраняете права владения данными журнала в локальной среде.
Локальные системы управления используют API или другие механизмы для приема данных журналов из облачных систем.

Совет

В рамках итеративного подхода к миграции в облако по мере развития и интеграции облачных ресурсов и служб в составе ИТ-активов вероятен переход от строго облачного или локального мониторинга к варианту гибридного подхода.

Гибридный мониторинг (облачный)

Если у вас нет необходимости в обслуживании локальной системы мониторинга или вы хотите заменить локальные системы мониторинга централизованным облачным решением, вы также можете интегрировать локальные данные журналов с Azure Monitor, чтобы создать централизованную облачную систему мониторинга.

Зеркальное отображение локального подхода по центру. В этом сценарии облачные рабочие нагрузки будут отправлять данные телеметрии напрямую в Azure Monitor. А локальные приложения и службы будут отправлять данные телеметрии непосредственно в Azure Monitor или агрегировать эти данные в локальной среде для приема в Azure Monitor через регулярные интервалы. Azure Monitor здесь выполняет роль основной системы мониторинга и отчетности для всей ИТ-инфраструктуры.

Допущения облачного гибридного мониторинга: Использование облачных систем ведения журналов и отчетов для гибридного мониторинга предполагает следующие условия:

Вы не зависите от существующих локальных систем мониторинга.
Для рабочих нагрузок нет нормативных требований или требований политики для локального хранения данных журнала.
Облачные системы мониторинга используют API или другие механизмы для приема данных журналов из локальных приложений и служб.

Многооблачная среда

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

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

Дополнительные сведения

Azure Monitor — это стандартная служба создания отчетов и мониторинга в Azure. Служба предоставляет:

Унифицированную платформу для сбора телеметрии приложений, телеметрии узлов (например, виртуальных машин), метрик контейнеров, метрик платформы Azure и журналов событий.
Визуализацию, запросы, оповещения и аналитические инструменты. Это позволяет получать аналитические сведения о виртуальных машинах, гостевых операционных системах, виртуальных сетях и событиях приложений рабочей нагрузки.
REST API для интеграции с внешними службами и автоматизации служб мониторинга и оповещений.
Интеграцию со многими популярными сторонними поставщиками.

Дальнейшие действия

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

Руководства по принятию решений об архитектуре