Надежность в журналах службы Azure Monitor

Журналы Azure Monitor — это централизованная платформа SaaS для сбора, анализа и реагирования на системные данные, генерируемые ресурсами и приложениями Azure и не Azure.

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

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

Рекомендации по развертыванию в производственной среде

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

Подробные сведения о ценах см. в разделе Цены на Azure Monitor.

Некоторые Log Analytics функции несовместимы со всеми функциями надежности. Например, репликация рабочей области не поддерживает вспомогательные таблицы. Дополнительные сведения о совместимости функций см. в разделе «Лучшие практики по обеспечению надежности для Log Analytics».

Обзор архитектуры надежности

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

Логическая архитектура

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

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

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

• Ingestion — это путь, через который данные журнала передаются в рабочую область Log Analytics. Служба Azure Monitor подтверждает получение данных только после записи в хранилище. Путь приема включает несколько компонентов:

  • Источники данных создают данные телеметрии. Некоторые источники, такие как журналы платформы Azure, передают данные непосредственно в службу Azure Monitor с помощью параметров диагностики. Для других источников требуется агент для сбора и пересылки данных. Приложения также могут использовать API приема Logs Ingestion для отправки журналов непосредственно в Azure Monitor.

  • Правила сбора данных (DCR) определяют, какие данные необходимо собирать, как его преобразовывать и куда отправлять. Контроллеры домена направляют данные в службу Azure Monitor через конечную точку сбора данных data (DCE).

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

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

Дополнительные сведения об основных компонентах журналов Azure Monitor см. в разделе Azure Monitor Logs overview.

Физическая архитектура

Внутри Azure Monitor Logs используются несколько реплик как для вычислительных компонентов, так и для компонентов хранения данных журнала. Microsoft управляет этими репликами, и вам не нужно настраивать или управлять ими.

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

Устойчивость к временным сбоям

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

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

Рассмотрим следующие типы временных сбоев в журналах Azure Monitor:

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

• Временные сбои, влияющие на подключение приёма: Агенты и параметры диагностики Azure буферизуют данные локально и повторяют попытки доставки, когда конечная точка приёма временно недоступна, что делает путь передачи данных более устойчивым к временным сбоям.

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

  • Задержка приема
  • Количество неудачных загрузок данных
  • Сбои экспорта
  • Частота сбоев запросов

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

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

Устойчивость к сбоям зоны доступности

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

журналы Azure Monitor поддерживают две типы поддержки зоны доступности в зависимости от региона и типа кластера рабочей области:

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

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

• Устойчивость службы обеспечивает избыточность зоны для приема и непрерывности запросов во время сбоя зоны доступности.

  Только некоторые регионы обеспечивают устойчивость служб.

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

Требования

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

• Выделенный кластер: Для обеспечения устойчивости данных в некоторых регионах требуется выделенный кластер .

Рекомендации

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

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

Cost

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

Настройка поддержки зоны доступности

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

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

Планирование ресурсов и управление ими

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

Поведение, когда все зоны работоспособны

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

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

• Cross-zone data replication: Для кластеров с устойчивостью данных служба Azure Monitor фиксирует все записи в несколько реплик в отдельных зонах перед подтверждением.

Поведение во время сбоя зоны

В этом разделе описано, чего ожидать, если рабочая область Log Analytics настроена с избыточностью между зонами и в одной из зон происходит сбой.

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

• Уведомление: Microsoft не уведомляет вас автоматически, когда зона отключена. Однако вы можете использовать Работоспособность служб Azure для понимания общего состояния службы, включая любые сбои зоны, и настроить оповещения Service Health для уведомления о проблемах.

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

• Активные запросы: Во время сбоя зоны все активные запросы могут завершиться ошибкой.

  Все активные запросы могут быть завершены. Клиенты могут повторить запросы.

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

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

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

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

Восстановление зоны

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

Тестирование на сбои в зоне

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

Устойчивость к сбоям на уровне региона

Azure Monitor Logs поддерживает многорегиональные сценарии с помощью репликации рабочей области.

Репликация рабочей области

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

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

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

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

Требования

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

• Выделенные кластеры: Если рабочая область связана с выделенным кластером, сначала включите репликацию в кластере.

Рекомендации

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

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

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

  • Установите мониторинг (здоровье репликации, задержка приема данных, метрики здоровья рабочей области) для активного региона. Перед переключением проверяйте неактивную область рабочей области.
  • Рассмотрите возможность создания модулей Runbook для определения критериев переключения, которые могут быть частью планирования аварийного восстановления. Например, можно отслеживать задержку приема данных на уровне региона, нарушения целевых показателей уровня обслуживания (SLO), устойчиво высокий уровень сбоев запросов или уведомления Работоспособность служб Azure. Регулярно тестируйте модули Runbook.
  • Задокументируйте критерии переключения на другой режим и возврата к предыдущему режиму.
  • Убедитесь, что все пользователи или субъекты-службы, которые активируют переключение, имеют необходимые разрешения роли.

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

• Microsoft Sentinel: Списки наблюдений и записи анализа угроз Microsoft Sentinel реплицируются только при обновлении, поэтому могут потребоваться до 12 дней для достижения полной синхронности после первоначальной активации.

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

Дополнительные сведения см. в разделе "Рекомендации по развертыванию".

Cost

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

Настройка поддержки нескольких регионов

• Включение репликации рабочей области: Ниже приведены общие действия, необходимые для включения репликации рабочей области:

  1. Включите репликацию и укажите дополнительный регион.

  2. Проверьте состояние подготовки.

     Подсказка

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

  3. Свяжите контроллеры домена с конечной точкой сбора данных рабочей области (DCE) после включения репликации для репликации этих потоков во время переключения.

• Отключение репликации рабочей области: Подробные инструкции по отключению репликации рабочей области см. в разделе "Включение и отключение репликации рабочей области".

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

Планирование ресурсов и управление ими

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

Поведение, когда все регионы работоспособны

В этом разделе описывается, чего ожидать при настройке рабочей среды Log Analytics для воспроизведения рабочей среды, когда все регионы находятся в рабочем состоянии.

• Межрегиональная работа: Все операции приёма данных и запросы направляются в рабочую область основного региона, пока она работает нормально. Рабочая область дополнительного региона содержит пассивные реплики данных, схем и конфигурации до переключения.

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

Репликация рабочей области применяется на уровне рабочей области, поэтому вы не можете выбрать отдельные таблицы для репликации. Однако вы можете управлять репликацией, связывая с конечной точкой сбора данных рабочей области только те DCR, которые содержат критически важные потоки данных. Контроллеры домена, не связанные с рабочей областью DCE, не реплицируют свои данные. Дополнительные сведения см. в разделе "Связывание правил сбора данных".

Поведение во время сбоя региона

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

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

  Сведения о том, как решить, когда переключиться, см. в разделе "Когда следует переключиться?". Чтобы узнать, как отслеживать работоспособность рабочей области во время потенциального переключения, см. статью "Мониторинг производительности рабочей области с помощью запросов".

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

• Уведомления: Microsoft не уведомляет вас автоматически, когда регион отключается. Однако вы можете использовать Работоспособность служб Azure, чтобы понять общее состояние службы, включая сбои в любом регионе, и настроить оповещения Service Health для уведомления о проблемах.

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

• Активные запросы: Любой активный прием в регионе сбоя может завершиться ошибкой, и все запросы, выполняемые в регионе сбоем, также могут завершиться ошибкой.

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

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

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

  Общий объем потери данных иногда называется целевой точкой восстановления (RPO).

• Ожидаемое время простоя: Процесс переключения включает активацию приема в вторичную рабочую область и обновление записей DNS рабочей области.

  Хотя изменение записи DNS происходит быстро, распространение DNS может занять больше времени. Если агенты или другие клиенты не учитывают время жизни записи DNS (TTL), они могут продолжать попытки подключения к основной рабочей области. Убедитесь, что клиенты не кэшируют записи DNS дольше, чем срок жизни.

  После завершения переключения выполнение запросов возобновляется во вторичной рабочей области.

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

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

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

Восстановление региона

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

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

Проверка сбоев в регионе

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

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

Кастомные многорегиональные решения для повышения отказоустойчивости

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

• Двойная запись: Настройте источники, такие как параметры диагностики, агенты и прием на основе DCR, для отправки журналов в две независимые рабочие области в разных регионах.

  Этот подход обеспечивает аналитику практически в режиме реального времени в обоих регионах. Однако это удваивает стоимость приёма данных и создаёт риск рассогласования конфигурации между рабочими областями.

• Экспорт и восстановление: Если ваш регион связан с другим регионом Azure, вы можете использовать экспорт данных для непрерывного вывода журналов в Хранилище BLOB-объектов Azure. Настройте учетную запись хранилища для использования одного из типов геоизбыточного хранилища (GRS). служба хранилища Azure автоматически и асинхронно реплицирует экспортированные журналы в парный регион.

  Во время катастрофы разверните новую рабочую область и выборочно загружайте последние критически важные данные. Вы также можете вручную запрашивать долгосрочный журнал непосредственно из Хранилище BLOB-объектов с помощью Azure Data Explorer. Дополнительные сведения см. в статье "Запрос экспортированных данных".

Резервное копирование и восстановление

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

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

Устойчивость к случайным удалениям

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

Устойчивость к обслуживанию служб

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

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

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

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

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Дополнительные сведения см. в разделе SLA для онлайн-услуг.

Журналы Azure Monitor уникальны среди онлайн-служб, поскольку это рекомендуемая платформа для сбора важных данных и аналитики, необходимых для подачи обращения в службу поддержки Microsoft по вопросу нарушения SLA.

Два соглашения об уровне обслуживания охватывают журналы Azure Monitor:

• SLA доступности запросов Log Analytics определяет показатели доступности для запросов к данным из рабочей области Log Analytics.

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

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

• Наилучшие практики обеспечения надежности для журналов Azure Monitor
• Зоны доступности в Azure Monitor
• Укрепите устойчивость за счет репликации пространства Log Analytics
• Экспорт данных из рабочей области Log Analytics
• Правила сбора данных
• Создание выделенного кластера и управление ими