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

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

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

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

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

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

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

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

Нативная для облака

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

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

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

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

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

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

Локальное расширение

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

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

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

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

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