Повышение устойчивости путем репликации рабочей области Log Analytics в разных регионах

Репликация вашего рабочей области Log Analytics в разных регионах повышает устойчивость, позволяя переключиться на реплицированную область и продолжать работу в случае сбоя в определенном регионе. This article explains how Log Analytics workspace replication works, how to replicate your workspace, how to switch over and back, and how to decide when to switch between your replicated workspaces.

Here's a video that provides a quick overview of how Log Analytics workspace replication works:

Как работает репликация рабочей области Log Analytics

Ваше исходное рабочее пространство и регион называются основными. Реплицированное рабочее пространство и альтернативный регион называются вторичными.

Процесс репликации рабочей области создает копию вашей рабочей области в дополнительном регионе. The process creates the secondary workspace with the same configuration as your primary workspace, and Azure Monitor automatically updates the secondary workspace with any future changes you make to your primary workspace configuration.

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

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

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

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

Защита от потери данных при передаче в случае регионального сбоя

Azure Monitor имеет несколько механизмов, чтобы гарантировать, что данные во время передачи не будут потеряны при сбое в основном регионе.

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

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

Если вы создаете собственный клиент для отправки данных журналов в вашу рабочую область Log Analytics, убедитесь, что клиент обрабатывает запросы на получение, которые завершились неудачно.

Рассмотрение развертывания

• Операции по управлению рабочим пространством нельзя инициировать во время переключения, включая:

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

• The failover process updates your Domain Name System (DNS) records to reroute all ingestion requests to your secondary region for processing. Некоторые HTTP-клиенты имеют "постоянные подключения" и могут занимать больше времени на получение обновлений DNS. Во время переключения эти клиенты могут попытаться загрузить журналы через основную область в течение некоторого времени. Вы можете отправлять журналы в ваше основное рабочее пространство, используя различных клиентов, включая устаревший агент Log Analytics, агент Azure Monitor, код (с использованием API для отправки журналов или устаревшего API для сбора данных через HTTP), а также другие сервисы, такие как Microsoft Sentinel.

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

• Microsoft Sentinel обновляет журналы в таблицах "Контрольный список" и "Аналитика угроз" каждые 12 дней. Таким образом, поскольку в дублируемую рабочую область будут поступать только новые журналы регистрации, может потребоваться до 12 дней, чтобы полностью реплицировать данные по списку наблюдения и аналитике угроз на вторичную площадку.

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

• В настоящее время эти функции не поддерживаются или поддерживаются только частично.

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

Поддерживаемые регионы

В настоящее время репликация рабочих областей поддерживается для рабочих областей в ограниченном наборе регионов, организованных по группам регионов (группы географически соседних регионов). При включении репликации выберите вторичное местоположение из списка поддерживаемых регионов в той же группе регионов, что и основное местоположение рабочего пространства. Например, рабочее пространство в Западной Европе можно реплицировать в Северной Европе, но не в Западных США 2, так как эти регионы находятся в разных группах регионов.

Поддерживаются следующие группы регионов и регионы:

Требования к местонахождению данных

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

Поддержка Microsoft Sentinel и других служб

Различные сервисы и функции, использующие рабочие области Log Analytics, совместимы с репликацией и переключением рабочей области. Эти услуги и функции продолжают работать, когда вы переключаетесь на вторичное рабочее пространство.

Например, региональные проблемы с сетью, вызывающие задержку при сборе журналов, могут повлиять на клиентов Microsoft Sentinel. Клиенты, которые используют реплицированные рабочие пространства, могут переключиться на свою вторичную область, чтобы продолжить работу с рабочим пространством Log Analytics и Sentinel. Однако, если проблема с сетью влияет на работоспособность службы Sentinel, переключение на другой регион не решает эту проблему.

Некоторые функции Azure Monitor, включая Application Insights и VM Insights, в настоящее время лишь частично совместимы с репликацией рабочего пространства и переключением. Для полного списка см. Deployment considerations.

Модель ценообразования

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

Требуются разрешения

Включение и отключение репликации рабочего пространства

You enable and disable workspace replication by using a REST command. Команда запускает длительную операцию, что означает, что для применения новых настроек может потребоваться несколько минут. После того как вы включите репликацию, может потребоваться до одного часа, чтобы все таблицы (типы данных) начали реплицироваться, и некоторые типы данных могут начать реплицироваться раньше других. Изменения, которые вы вносите в схемы таблиц после включения репликации рабочего пространства, например, новые таблицы пользовательских журналов или созданные вами пользовательские поля, или диагностические журналы, настроенные для новых типов ресурсов, могут начать реплицироваться в течение одного часа.

Используете выделенный кластер?

Если ваше рабочее пространство связано с выделенным кластером, сначала необходимо включить репликацию на кластере, а затем на рабочем пространстве. Эта операция создает второй кластер в вашем вторичном регионе (без дополнительных затрат сверх платы за репликацию), чтобы позволить вашему рабочему пространству продолжать использовать выделенный кластер, даже в случае отказа. This also means features like cluster managed keys (CMK) continue to work (with the same key) during failover. После включения репликации между регионами перейдите к включению репликации для одного или нескольких рабочих пространств, связанных с этим кластером.

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

Для включения репликации кластера используйте эту команду PUT:

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/clusters/<cluster_name>?api-version=2025-02-01

body:
{
    "properties": {
        "replication": {
            "enabled": true,
            "location": "<secondary_region>"
        }
    },
    "location": "<primary_region>"
}

Где

• <subscription_id>: Идентификатор подписки, связанный с вашим кластером.
• <resourcegroup_name> : Группа ресурсов, содержащая ваш кластер ресурсов Log Analytics.
• <cluster_name>: Название вашего выделенного кластера.
• <primary_region>: Основной регион для вашего выделенного кластера Log Analytics.
• <secondary_region>: Регион, в котором Azure Monitor создает вторичный выделенный кластер.

Проверить состояние подготовки кластера

Чтобы проверить состояние обеспечения вашего кластера, выполните эту команду GET.

GET

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/clusters/<cluster_name>?api-version=2025-02-01

Где

• <subscription_id>: Идентификатор подписки, связанный с вашим кластером.
• <resourcegroup_name>: группа ресурсов, содержащая ресурс вашего кластера Log Analytics.
• <cluster_name>: Название вашего кластера Log Analytics.

Используйте команду GET, чтобы проверить, что состояние подготовки кластера изменяется с Updating на Succeeded, и вторичный регион установлен в соответствии с ожиданиями.

Включить репликацию рабочей области

Чтобы включить репликацию в рабочем пространстве Log Analytics, используйте эту команду PUT.

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2025-02-01

body:
{
    "properties": {
        "replication": {
            "enabled": true,
            "location": "<secondary_region>"
        }
    },
    "location": "<primary_region>"
}

Где

• <subscription_id>: Идентификатор подписки, связанный с вашим рабочим пространством.
• <resourcegroup_name> : The resource group that contains your Log Analytics workspace resource.
• <workspace_name>: Имя вашего рабочего пространства.
• <primary_region>: Основной регион для вашего рабочего пространства Log Analytics.
• <secondary_region>: Регион, в котором Azure Monitor создает вторичное рабочее пространство.

For the supported location values, see Supported regions.

Команда PUT является длительной операцией, которая может занять некоторое время для завершения. Успешный вызов возвращает код состояния 200. Вы можете отслеживать состояние предоставления вашего запроса, как описано в Проверьте состояние предоставления рабочего пространства.

Проверьте состояние обеспечения рабочего пространства

Чтобы проверить состояние предоставления вашего рабочего пространства, выполните эту команду GET.

GET

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>?api-version=2025-02-01

Где

• <subscription_id>: Идентификатор подписки, связанный с вашим рабочим пространством.
• <resourcegroup_name>: Группа ресурсов, содержащая ресурс рабочего пространства Log Analytics.
• <workspace_name>: Название вашего рабочей области Log Analytics.

Используйте команду GET, чтобы убедиться, что состояние подготовки рабочего пространства изменяется с Updating на Succeeded, и что вторичный регион установлен, как ожидалось.

Свяжите правила сбора данных с конечной точкой сбора данных рабочего пространства

Агент мониторинга Azure, API приема логов и Azure Event Hubs собирают данные и отправляют их в указанный вами пункт назначения в зависимости от того, как вы настроили свои правила сбора данных (DCR).

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

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

1. В портале Azure выберите Правила сбора данных.

2. С экрана Правила сбора данных выберите правило сбора данных, которое отправляет данные в ваше основное рабочее пространство Log Analytics.

3. На странице Обзор правила сбора данных выберите Настроить DCE и выберите конечную точку сбора данных рабочего пространства из доступного списка.

   Для получения подробностей о System DCE, изучите свойства объекта рабочей области.

Что проверить, если репликация рабочей области не выполняется

• Рабочая область связана с выделенным кластером?
  • Репликация должна быть включена на кластере, прежде чем ее можно будет включить на рабочем пространстве.
  • Репликация как кластера, так и рабочего пространства должна быть настроена на одинаковое вторичное местоположение. Например, если кластер реплицируется в Северную Европу, то рабочие пространства, связанные с ним, также могут быть реплицированы только в Северную Европу.
• Вы использовали REST API для включения репликации?
  • Убедитесь, что вы используете версию API 2025-02-01 или более позднюю.
• Основное рабочее пространство расположено в East US, East US 2 или South Central US?
  • East US, East US 2 и South Central US не могут реплицироваться друг с другом.
• Где находится основное рабочее место и где вторичное? Оба местоположения должны находиться в одной группе регионов. Например, рабочие области, расположенные в регионах США, не могут иметь репликацию (дополнительный регион) в Европе и наоборот. Список групп регионов см. в разделе Поддерживаемые регионы.
• У вас есть необходимые разрешения?
• Вы выделили достаточно времени для завершения операции репликации? Репликация — это длительная операция. Отслеживайте состояние операции, как объяснено в Проверка состояния развертывания рабочего пространства.
• Вы пытались повторно включить репликацию, чтобы изменить вторичное расположение рабочей области? Чтобы изменить местоположение вашего вторичного рабочего пространства, сначала необходимо отключить репликацию рабочего пространства, дождаться завершения операции и только потом включить репликацию в другое вторичное местоположение.

Что нужно проверить, если репликация рабочей области установлена, но журналы не реплицируются?

• Репликация может занять до часа, чтобы начаться, и некоторые типы данных могут начать реплицироваться раньше других.
• Журналы, добавленные в рабочее пространство до того, как была включена репликация, не копируются в вторичное рабочее пространство. Реплицируются только те журналы, которые поступили после включения репликации.
• Если некоторые журналы реплицируются, а другие нет, проверьте, правильно ли настроены все правила сбора данных (DCR), которые направляют журналы в рабочее пространство. Чтобы просмотреть DCR, нацеленные на рабочую область, откройте вкладку сбора данных Log Analytics Workspace Insights в Azure Portal.

Отключить репликацию рабочей области

Чтобы отключить репликацию для рабочей области, используйте эту команду PUT.

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2025-02-01

body:
{
    "properties": {
        "replication": {
            "enabled": false
        }
    },
    "location": "<primary_region>"
}

Где

• <subscription_id>: Идентификатор подписки, связанный с вашим рабочим пространством.
• <resourcegroup_name> : Группа ресурсов, содержащая ресурс вашего рабочего пространства.
• <workspace_name>: Название вашего рабочего пространства.
• <primary_region>: Основной регион для вашего рабочего пространства.

Команда PUT является длительной операцией, которая может занять некоторое время для завершения. Успешный вызов возвращает код состояния 200. Вы можете отслеживать состояние предоставления вашего запроса, как описано в Проверьте состояние предоставления рабочего пространства.

Отключить репликацию кластера

Отключение репликации кластера возможно только после отключения репликации для всех рабочих областей, связанных с этим кластером (если она была включена ранее). Чтобы отключить репликацию для рабочей области, используйте эту команду PUT.

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/clusters/<cluster_name>?api-version=2025-02-01

body:
{
    "properties": {
        "replication": {
            "enabled": false
        }
    },
    "location": "<primary_region>"
}

Где

• <subscription_id>: Идентификатор подписки, связанный с вашим кластером.
• <resourcegroup_name> : Группа ресурсов, содержащая ресурсы вашего кластера.
• <workspace_name>: Название вашего кластера.
• <primary_region>: Основной регион для вашего кластера.

Команда PUT является длительной операцией, которая может занять некоторое время для завершения. Успешный вызов возвращает код состояния 200. Вы можете отслеживать состояние предоставления вашего запроса, как описано в Проверьте состояние предоставления рабочего пространства.

Отслеживать состояние рабочего пространства и услуг

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

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

• Создайте оповещения на основе состояния ресурсов рабочего пространства

• Установите собственные пороговые значения для метрик здоровья рабочего пространства

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

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

Переключитесь на свое вторичное рабочее пространство

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

Когда мне нужно переключиться?

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

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

Тип и масштаб проблемы

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

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

Длительность проблемы

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

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

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

данные вторичной рабочей области

Логи, полученные в вашу основную рабочую область до того, как вы включите репликацию, не будут скопированы во вторичную рабочую область. Если вы включили репликацию рабочего пространства три часа назад и теперь переключаетесь на вторичное рабочее пространство, ваши запросы могут возвращать данные только за последние три часа.

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

Переключение по триггеру

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

Чтобы переключиться на ваше вторичное рабочее пространство, используйте эту команду: POST

POST 
https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/locations/<secondary_region>/workspaces/<workspace_name>/failover?api-version=2025-02-01

Где

• <subscription_id>: Идентификатор подписки, связанный с вашим рабочим пространством.
• <resourcegroup_name> : Группа ресурсов, содержащая ресурс вашего рабочего пространства.
• <secondary_region>: Регион, на который нужно переключиться во время переключения.
• <workspace_name>: Название рабочего пространства, на которое нужно переключиться во время переключения.

Команда POST является длительной операцией, которая может занять некоторое время для завершения. A successful call returns a 202 status code. Вы можете отслеживать состояние предоставления вашего запроса, как описано в Проверьте состояние предоставления рабочего пространства.

Что проверить, если переключение (отказоустойчивость) не удалось

• Вы использовали REST API для инициирования переключения (фейловера)?
  • Убедитесь, что вы используете версию API 2025-02-01 или более позднюю.
  • Убедитесь, что резервное расположение, указанное в команде переключения на резервный источник, является резервным расположением, установленным для этой рабочей области. Эта информация доступна в представлении рабочего пространства на Azure Portal, а также через API.
• Переключение регионов требует роли участника Log Analytics на группе ресурсов рабочей области, а не только на самой рабочей области.

Переключитесь обратно на основное рабочее пространство

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

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

Когда мне вернуться обратно?

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

Состояние репликации журнала

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

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

Основное состояние рабочего пространства

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

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

Для примеров того, как выполнить запросы к основному рабочему пространству, когда ваше вторичное рабочее пространство активно, и обойти перенаправление запросов во вторичное рабочее пространство, см. Аудит неактивного рабочего пространства.

Активировать переключение назад

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

Процесс возврата обновляет ваши DNS-записи. После обновления записей DNS может потребоваться время, чтобы все клиенты получили обновленные настройки DNS и возобновили маршрутизацию в основной рабочий стол.

Чтобы вернуться к вашему основному рабочему пространству, используйте эту команду POST.

POST

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>/failback?api-version=2025-02-01

Где

• <subscription_id>: Идентификатор подписки, связанный с вашим рабочим пространством.
• <resourcegroup_name> : Группа ресурсов, содержащая ресурс вашего рабочего пространства.
• <workspace_name>: Название рабочего пространства, к которому нужно переключиться при возврате.

Команда POST является длительной операцией, которая может занять некоторое время для завершения. Успешный вызов возвращает код состояния 202. Вы можете отслеживать состояние предоставления вашего запроса, как описано в Проверьте состояние предоставления рабочего пространства.

Провести аудит неактивного рабочего пространства.

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

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

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

Запрос неактивного региона

Чтобы запросить данные журнала в неактивном регионе, используйте эту команду GET:

GET

api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=<query>&timespan=<timespan-in-ISO8601-format>&overrideWorkspaceRegion=<primary|secondary>

Например, чтобы выполнить простой запрос, такой как Perf | count, за прошедший день в вашем вторичном регионе, используйте:

GET

api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=Perf%20|%20count&timespan=P1D&overrideWorkspaceRegion=secondary

Вы можете подтвердить, что Azure Monitor выполняет ваш запрос в нужном регионе, проверив эти поля в таблице LAQueryLogs, которая создается при включении аудита запросов в рабочем пространстве Log Analytics.

• isWorkspaceInFailover: Указывает, находилось ли рабочее пространство в режиме переключения во время запроса. The data type is Boolean (True, False).
• workspaceRegion: Область рабочей области, на которую направлен запрос. Тип данных — строка.

Monitor workspace performance using queries

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

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

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

Мониторинг задержки приема данных от начала до конца.

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

• Задержка агента: Время, необходимое агенту для сообщения о событии.
• Задержка конвейера загрузки (бэкенд): Время, необходимое конвейеру загрузки для обработки журналов и записи их в ваше рабочее пространство.

Разные типы данных имеют различную задержку приёма. You can measure ingestion for each data type separately, or create a generic query for all types, and a more fine-grained query for specific types that are of higher importance to you. We suggest you measure the 90th percentile of the ingestion latency, which is more sensitive to change than the average or the 50th percentile (median).

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

Оцените базовую задержку поглощения данных для конкретных таблиц.

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

Этот пример запроса создает диаграмму 90-го процентиля задержки поступления данных в таблице Perf.

// Assess the ingestion latency baseline for a specific data type
Perf
| where TimeGenerated > ago(3d) 
| project TimeGenerated, 
IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize LatencyIngestion90Percentile=percentile(IngestionDurationSeconds, 90) by bin(TimeGenerated, 1h) 
| render timechart

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

Отслеживайте и предупреждайте о текущей задержке приёмки

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

Этот запрос вычисляет задержку загрузки за последние 20 минут:

// Track the recent ingestion latency (in seconds) of a specific table
Perf
| where TimeGenerated > ago(20m) 
| extend IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize Ingestion90Percent_seconds=percentile(IngestionDurationSeconds, 90)

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

Определите источник задержки загрузки данных

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

Этот запрос строит график задержки на 90-м процентиле как агентов, так и конвейера отдельно.

// Assess agent and pipeline (backend) latency
Perf
| where TimeGenerated > ago(1h) 
| extend AgentLatencySeconds = (_TimeReceived-TimeGenerated)/1s,
	  PipelineLatencySeconds=(ingestion_time()-_TimeReceived)/1s
| summarize percentile(AgentLatencySeconds,90), percentile(PipelineLatencySeconds,90) by bin(TimeGenerated,5m)
| render columnchart

Monitor ingestion volume

Измерения объема потребления могут помочь выявить неожиданные изменения в общем объеме потребления или объеме потребления для конкретной таблицы в вашем рабочем пространстве. Измерения объёма запросов могут помочь вам выявить проблемы с производительностью при передаче журналов. Some useful volume measurements include:

• Объем данных, загружаемых в каждую таблицу
• Постоянный объем потребления (остановка)
• Аномалии загрузки — резкие изменения и падения объёма загрузки

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

Мониторинг общего объема загрузки для каждой таблицы.

You can define a query to monitor the ingestion volume per table in your workspace. Запрос может включать оповещение, которое проверяет неожиданные изменения общих или специфичных для таблицы объемов.

Этот запрос вычисляет общий объем поглощения данных за последний час для каждой таблицы в мегабайтах в секунду (МБ/с).

// Calculate total ingestion volume over the past hour per table
Usage 
| where TimeGenerated > ago(1h) 
| summarize BillableDataMB = sum(_BilledSize)/1.E6 by bin(TimeGenerated,1h), DataType

Проверьте на остановку процесса поглощения

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

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

// Count agent heartbeats in the last ten minutes
Heartbeat 
| where TimeGenerated>ago(10m) 
| count

Отслеживание аномалий при поглощении

Вы можете определить пики и падения данных об объеме поступлений в рабочем пространстве различными способами. Используйте функцию series_decompose_anomalies(), чтобы извлечь аномалии из объемов ввода, которые вы контролируете в своём рабочем пространстве, или создайте собственный детектор аномалий для поддержки уникальных сценариев вашего рабочего пространства.

Определите аномалии, используя series_decompose_anomalies

Функция series_decompose_anomalies() выявляет аномалии в ряду значений данных. Запрос вычисляет ежечасный объем данных для каждой таблицы в вашем рабочем пространстве Log Analytics и использует series_decompose_anomalies() для идентификации аномалий.

// Calculate hourly ingestion volume per table and identify anomalies
Usage
| where TimeGenerated > ago(24h)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| summarize
    Timestamp=make_list(TimeGenerated),
    IngestionVolumeMB=make_list(IngestionVolumeMB)
    by DataType
| extend series_decompose_anomalies(IngestionVolumeMB)
| mv-expand
    Timestamp,
    IngestionVolumeMB,
    series_decompose_anomalies_IngestionVolumeMB_ad_flag,
    series_decompose_anomalies_IngestionVolumeMB_ad_score,
    series_decompose_anomalies_IngestionVolumeMB_baseline
| where series_decompose_anomalies_IngestionVolumeMB_ad_flag != 0

Для получения дополнительной информации о том, как использовать series_decompose_anomalies(), чтобы обнаруживать аномалии в данных журналов, ознакомьтесь с разделом Обнаружение и анализ аномалий с использованием возможностей машинного обучения KQL в Azure Monitor.

Создайте свой собственный детектор аномалий

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

Следующий запрос вычисляет:

• Ожидаемый объем загрузки: В час, по таблице (основывается на медиане медиан, но вы можете настроить логику)
• Фактический объем загрузки: В час, по таблице

Чтобы устранить незначительные различия между ожидаемым и фактическим объёмом ввода данных, запрос применяет два фильтра:

• Скорость изменения: Более 150% или менее 66% от ожидаемого объема, согласно таблице
• Объем изменения: Указывает, превышает ли увеличение или уменьшение объема 0,1% от ежемесячного объема данной таблицы.

// Calculate expected vs actual hourly ingestion per table
let TimeRange=24h;
let MonthlyIngestionByType=
    Usage
    | where TimeGenerated > ago(30d)
    | summarize MonthlyIngestionMB=sum(Quantity) by DataType;
// Calculate the expected ingestion volume by median of hourly medians
let ExpectedIngestionVolumeByType=
    Usage
    | where TimeGenerated > ago(TimeRange)
    | project TimeGenerated, DataType, Quantity
    | summarize IngestionMedian=percentile(Quantity, 50) by bin(TimeGenerated, 1h), DataType
    | summarize ExpectedIngestionVolumeMB=percentile(IngestionMedian, 50) by DataType;
Usage
| where TimeGenerated > ago(TimeRange)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| join kind=inner (ExpectedIngestionVolumeByType) on DataType
| extend GapVolumeMB = round(IngestionVolumeMB-ExpectedIngestionVolumeMB,2)
| where GapVolumeMB != 0
| extend Trend=iff(GapVolumeMB > 0, "Up", "Down")
| extend IngestedVsExpectedAsPercent = round(IngestionVolumeMB * 100 / ExpectedIngestionVolumeMB, 2)
| join kind=inner (MonthlyIngestionByType) on DataType
| extend GapAsPercentOfMonthlyIngestion = round(abs(GapVolumeMB) * 100 / MonthlyIngestionMB, 2)
| project-away DataType1, DataType2
// Determine whether the spike/deep is substantial: over 150% or under 66% of the expected volume for this data type
| where IngestedVsExpectedAsPercent > 150 or IngestedVsExpectedAsPercent < 66
// Determine whether the gap volume is significant: over 0.1% of the total monthly ingestion volume to this workspace
| where GapAsPercentOfMonthlyIngestion > 0.1
| project
    Timestamp=format_datetime(todatetime(TimeGenerated), 'yyyy-MM-dd HH:mm:ss'),
    Trend,
    IngestionVolumeMB,
    ExpectedIngestionVolumeMB,
    IngestedVsExpectedAsPercent,
    GapAsPercentOfMonthlyIngestion

Следить за успешностью и неудачами запросов

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

Этот запрос подсчитывает количество запросов, которые вернули код ошибки сервера.

// Count query errors
LAQueryLogs 
| where ResponseCode>=500 and ResponseCode<600 
| count

Связанный контент

• Мониторинг состояния рабочей области Log Analytics
• Отслеживайте эксплуатационные проблемы в вашей рабочей области Azure Monitor Log Analytics