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

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

Перейти к разделу: Планирование инфраструктуры мониторинга | Полностью облачные решения | Интеграция с локальными системами | Агрегация шлюза | Гибридный мониторинг (локальный) | Гибридный мониторинг (на основе облака) | Многооблачные решения | Дополнительные сведения

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

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

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

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

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

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

Облачное решение 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 для интеграции с внешними службами и автоматизации служб мониторинга и оповещений.
• Интеграцию со многими популярными сторонними поставщиками.

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

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