Рекомендации по мониторингу журналов Azure

В этой статье приведены рекомендации по архитектуре для журналов мониторинга Azure. Руководство основано на пяти основных принципах архитектуры, описанных в Azure Well-Architected Framework.

Надежность

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

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

функции мониторинга журналов Azure, повышающие устойчивость

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

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

Защита в регионе с помощью зон доступности

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

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

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

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

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

Резервное копирование данных из определенных таблиц с помощью непрерывного экспорта

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

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

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

Замечание

Данные можно получить доступ в учетной записи хранения из логов мониторинга Azure с помощью оператора externaldata. Однако экспортированные данные хранятся в пятиминутных блоках, и анализ данных, охватывающих несколько блоков, может быть затруднительным. Таким образом, экспорт данных в учетную запись storage является хорошим механизмом резервного копирования данных, но наличие резервных копий данных в учетной записи storage не идеально подходит, если требуется для анализа в журналах мониторинга Azure. Вы можете запрашивать большие объемы данных объектов BLOB с помощью Azure Data Explorer, Фабрика данных Azure или любого другого средства доступа к хранилищу.

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

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

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

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

Контрольный список проектирования

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

Рекомендации по настройке

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

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

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

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

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

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

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

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

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

Функция экспорта данных Azure Monitor позволяет непрерывно экспортировать данные, направляемые в определенные таблицы, в хранилище Azure, где они могут храниться в течение длительного времени. Используйте учетную запись геоизбыточного хранилища (GRS) или геозонально-избыточного хранилища (GZRS), чтобы обеспечить безопасность данных даже в том случае, если весь регион становится недоступным. Чтобы сделать данные доступными для чтения из других регионов, настройте учетную запись хранения для доступа для чтения во вторичный регион. Дополнительные сведения см. в разделе служба хранилища Azure резервирование в вторичном регионе и служба хранилища Azure чтение данных в вторичном регионе.

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

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

Сравните функции устойчивости журналов Azure Monitor

Функция Устойчивость службы Резервное копирование данных Высокая доступность Область защиты Настройка Себестоимость
Репликация рабочей области Защита межрегионов от региональных инцидентов Включите репликацию рабочих областей и связанных правил сбора данных. Переключение между регионами по мере необходимости. На основе количества реплицированных гигабайт и региона.
Зоны доступности
В поддерживаемых регионах
Защита от проблем центра обработки данных в регионе Автоматическое включение в поддерживаемых регионах. Без затрат
Экспорт непрерывных данных Защита от потери данных из-за регионального сбоя 1 Включите для каждой таблицы. Стоимость экспорта данных + объектов BLOB-хранилища или центров обработки событий

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

Безопасность

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

Предоставлять доступ к данным в рабочей области по мере необходимости

  1. Задайте режим контроля доступа рабочей области Использовать разрешения ресурса или рабочей области, чтобы владельцы ресурсов могли использовать resource-context для доступа к их данным без предоставления явного доступа к рабочей области. Это упрощает настройку рабочей области и помогает гарантировать, что у пользователей есть только access необходимых данных.
    Instructions: Управляйте доступом к рабочим областям Log Analytics
  2. Назначьте соответствующую встроенную роль, чтобы предоставить администраторам разрешения рабочей области на уровне подписки, группы ресурсов или рабочей области в зависимости от их области обязанностей.
    Instructions: Управляйте доступом к рабочим областям Log Analytics
  3. Примените управление доступом на уровне таблицы (RBAC) для пользователей, которым требуется доступ к набору таблиц в нескольких ресурсах. Пользователи с разрешениями на таблицу имеют доступ ко всем данным в таблице, независимо от разрешений ресурса.
    Instructions: Управляйте доступом к рабочим областям Log Analytics

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

Если вы используете агенты, соединители или API журналов для запроса или отправки данных в рабочую область, используйте протокол TLS 1.2 или более поздней версии, чтобы обеспечить безопасность передаваемых данных. Более старые версии TLS и SSL имеют уязвимости и, хотя они по-прежнему могут работать для обеспечения обратной совместимости, они не рекомендуется, и отрасль быстро переместилась, чтобы отказаться от поддержки этих старых протоколов.

Совет по стандартам безопасности PCI установил крайний срок 30 июня 2018 года, чтобы отключить старые версии TLS/SSL и обновить до более безопасных протоколов. После удаления устаревшей поддержки Azure клиенты, которые не полностью взаимодействуют по протоколу TLS 1.2 или более поздней версии, не смогут отправлять или запрашивать данные для Azure журналов мониторинга.

Не настраивайте агенты, соединители данных или приложения API явным образом, чтобы использовать только TLS 1.2, если это не необходимо. Рекомендуется позволить автоматически обнаруживать, согласовывать и использовать будущие стандарты безопасности. В противном случае вы можете пропустить добавленную безопасность более новых стандартов и, возможно, возникнуть проблемы, если TLS 1.2 когда-либо устарел в пользу этих новых стандартов.

Это важно

В соответствии с выводом из эксплуатации устаревших версий TLS на платформе Azure протокол TLS 1.0/1.1 будет полностью заблокирован для Azure Monitor Logs в соответствии с датами в следующей таблице. Чтобы обеспечить лучшее в своем классе шифрование, журналы Azure Monitor уже используют TLS 1.2/1.3, выбранные механизмы шифрования.

Дата применения Запрос конечных точек API Версия протокола TLS
1 июль 2025 г. Конечные точки API для запросов Logs TLS 1.2 или более поздней версии
1 марта 2026 г. конечные точки API приема Logs Ingestion API TLS 1.2 или более поздней версии

Чтобы избежать потенциальных сбоев служб, убедитесь, что ресурсы, взаимодействующие с конечными точками API журналов, не имеют зависимостей от протоколов TLS 1.0 или 1.1 и полностью поддерживают TLS 1.2.

Общие вопросы о проблеме устаревшего TLS или о том, как протестировать поддерживаемые наборы шифров, см. в статьях Решение проблем TLS и Поддержка TLS в Azure Resource Manager.

Настройка аудита запросов журнала

  1. Настройте аудит запросов журнала для записи сведений о каждом запросе, выполняемом в рабочей области.
    Инструкции: Аудит запросов в журналах Azure Monitor
  2. Необходимо рассматривать данные аудита запросов журнала как данные безопасности и обеспечить безопасный доступ к таблице LAQueryLogs.
    Instructions: Настройте доступ к данным в рабочей области в зависимости от необходимости.
  3. Если вы отделяете данные о работе и безопасности, отправьте журналы аудита для каждой рабочей области в локальную рабочую область или консолидируйте в выделенную рабочую область безопасности.
    Instructions: Настройте доступ к данным в рабочей области в зависимости от необходимости.
  4. Используйте аналитику рабочей области Log Analytics для периодического просмотра данных аудита запросов журнала.
    Инструкции: Инсайты рабочей области Log Analytics.
  5. Создайте правила генерации оповещений поиска по журналам, чтобы уведомить вас о попытке несанкционированных пользователей выполнять запросы.
    Инструкции: Правила оповещения для поиска в логах.

Обеспечение неизменяемости данных аудита

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

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

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

    1. Определите определенные типы данных, которые следует экспортировать. Не все типы журналов имеют одинаковую релевантность для соответствия требованиям, аудита или безопасности.
    2. Используйте экспорт data для отправки данных в учетную запись Azure storage.
      Инструкции: экспорт данных в Azure Monitor из рабочей области Log Analytics
    3. Задайте политики неизменяемости для защиты от изменения данных.
      Instructions: Настройка неизменяемости политик для версий BLOB-объектов

Фильтрация или скрытие конфиденциальных данных в рабочей области

Если данные журнала содержат конфиденциальную информацию:

  1. Фильтрация записей, которые не должны собираться с помощью конфигурации для конкретного источника данных.
  2. Используйте преобразование, если следует удалить или запутать только определенные столбцы в данных.
    Инструкции: Трансформации в Azure Monitor
  3. Если у вас есть стандарты, требующие, чтобы исходные данные были неизменены, используйте литерал 'h' в запросах KQL для маскировки результатов запросов, отображаемых в рабочих книгах.
    Инструкции: Обфусцированные строковые литералы

Очистка конфиденциальных данных, собранных случайно

  1. Периодически проверяйте частные данные, которые могут случайно собираться в рабочей области.
  2. Используйте очистку данных для удаления нежелательных данных. Обратите внимание, что данные в таблицах с вспомогательным планом в настоящее время не могут быть удалены.
    Instructions: Управление персональными данными в журналах Azure Monitor и Application Insights

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

  • Управляемые клиентом ключи для повышения гибкости и управления жизненным циклом ключей. Если вы используете Microsoft Sentinel, убедитесь, что знакомы с рассмотрениями по настройке ключа Microsoft Sentinel, управляемого клиентом.
  • Customer Lockbox для Microsoft Azure для проверки, утверждения или отклонения запросов на доступ к данным клиента. Замок клиента используется, когда инженер Майкрософт должен получить доступ к данным клиентов, будь то в ответ на запрос в службу поддержки, инициированный клиентом, или для решения проблемы, выявленной корпорацией Майкрософт. В настоящее время Lockbox не может применяться к таблицам с вспомогательным планом.

Инструкции: Создание и управление выделенным кластером в журналах мониторинга Azure

Корпорация Майкрософт защищает подключения к общедоступным конечным точкам с помощью сквозного шифрования. Если требуется частная конечная точка, используйте Azure private link, чтобы разрешить ресурсам подключаться к рабочей области Log Analytics через авторизованные частные сети. Вы также можете использовать Private link для принудительного приема данных рабочей области через ExpressRoute или VPN.

Инструкции: Спроектируйте настройку Приватный канал Azure

Оптимизация затрат

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

Замечание

Ознакомьтесь с рекомендациями по оптимизации затрат в Azure Monitor для всех функций Azure Monitor.

Контрольный список проектирования

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

Рекомендации по настройке

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

Дополнительные сведения об уровнях обязательств и рекомендациях по определению наиболее подходящих для вашего уровня использования см. в разделе Azure Monitor Logs расчеты стоимости и варианты. См. статью Данные об использовании и предполагаемые расходы для получения сведений о предполагаемых расходах на использование в разных ценовых категориях.
Настройте интерактивное и долгосрочное хранение данных. Взимается плата за удержание данных в рабочей области Log Analytics, если их срок хранения превышает стандартные 31 день (до 90 дней, если в рабочей области включён Sentinel, и 90 дней для данных из Application Insights). Учитывайте конкретные требования к доступности данных для запросов журналов. Вы можете значительно сократить затраты, настроив долгосрочное хранение, который позволяет хранить данные до двенадцати лет и по-прежнему иметь доступ иногда с помощью поисковых заданий или восстановления набора данных в пространство.
Настройте таблицы, используемые для отладки, устранения неполадок и аудита в качестве базовых журналов. Таблицы в рабочей области Log Analytics, настроенной для Basic Logs, имеют более низкую стоимость приема в обмен на ограниченные функции и оплату за запросы к журналам. Если вы обращаетесь к этим таблицам нечасто и не используете их для уведомления об ошибках, стоимость этого запроса может быть компенсирована за счёт снижения стоимости приема.
Ограничьте сбор данных из источников данных для рабочей области. Основным фактором для затрат на Azure Monitor является объем данных, собираемых в рабочей области Log Analytics, поэтому необходимо убедиться, что вы не собираете больше данных, необходимых для оценки работоспособности и производительности служб и приложений. Дополнительные сведения о принятии решения для вашей среды, сбалансировав его с критериями в других столпах, см. в статье "Разработка архитектуры рабочей области Log Analytics".

Компромисс. Может быть компромисс между затратами и требованиями к мониторингу. Например, вы можете быстро обнаружить проблему производительности с высокой скоростью выборки, но может потребоваться более низкая скорость выборки для экономии затрат. Большинство сред имеют несколько источников данных с различными типами сбора, поэтому необходимо сбалансировать определенные требования с целевыми показателями затрат для каждого из них. Рекомендации по настройке сбора данных для различных источников см. в разделе Оптимизация затрат в Azure Monitor.
Регулярно анализируйте собранные данные для выявления тенденций и аномалий. Используйте возможности рабочей области Log Analytics, чтобы периодически проверять объем данных, собранных в вашей рабочей области. Помимо понимания объема данных, собранных различными источниками, он будет определять аномалии и тенденции повышения в сборе данных, которые могут привести к превышению затрат. Дальнейший анализ сбора данных с использованием методов в рабочей области Log Analytics для анализа использования поможет определить, есть ли дополнительная конфигурация, которая может уменьшить объем использования. Это особенно важно при добавлении нового набора источников данных, например нового набора virtual machines или подключения новой службы.
Создайте оповещение, когда сбор данных высок. Чтобы избежать непредвиденных счетов, вы должны быть заранее уведомлены в любое время, когда вы испытываете чрезмерное использование. Уведомление позволит устранить любые потенциальные аномалии до окончания периода выставления счетов.
Рассмотрите ежедневное ограничение в качестве профилактической меры, чтобы убедиться, что вы не превышаете определенный бюджет. Ежедневное ограничение отключает сбор данных в рабочей области Log Analytics в течение остального дня после достижения настроенного значения ограничения. Это не следует использовать в качестве метода для снижения затрат, как описано в разделе "Когда использовать ежедневное ограничение".

Если вы устанавливаете ежедневное ограничение, помимо создания оповещения при достижении ограничения, убедитесь, что вы также создадите правило генерации оповещений, чтобы получать уведомления о достижении определенного процента (например, 90 %. Это дает возможность исследовать и устранять причину увеличения данных, прежде чем ограничение отключает сбор данных.
Настройте оповещения в рекомендациях по затратам Помощник по Azure для рабочих пространств Log Analytics. Помощник по Azure рекомендации для рабочих областей Log Analytics заранее оповещают вас, когда есть возможность оптимизировать затраты. Создайте оповещения Помощник по Azure для этих рекомендаций по затратам.
  • Рассмотрите возможность настройки экономичного плана "Базовый" для журналов на выбранных таблицах. Мы обнаружили поступление данных объемом более 1 ГБ в месяц в таблицы, подходящие для плана данных журнала "Базовый" с низкой стоимостью. Базовый план журнала предоставляет возможность выполнения запросов для отладки и устранения неполадок за меньшую стоимость.
  • Рассмотрите возможность изменения уровня цен на основе вашего текущего объема использования; изучите возможность изменения уровня обязательств, чтобы получить скидку и снизить затраты.
  • Рассмотрите возможность удаления неиспользуемых восстановленных таблиц. У вас есть одна или несколько таблиц с восстановленными данными, активными в рабочей области. Если вы больше не используете восстановленные данные, удалите таблицу, чтобы избежать ненужных расходов.
  • Обнаружена аномалия приема данных. Мы обнаружили значительное увеличение частоты приема данных за прошлую неделю на основе данных о приеме в течение трех предыдущих недель. Запишите это изменение и ожидаемые изменения в затратах.
Вы также можете просмотреть автоматически созданную рекомендацию, выбрав "Обзорные>рекомендации" или "Рекомендации помощника" в меню ресурсов рабочей области Log Analytics.

Эффективность работы

Operational excellence относится к процессам операций, необходимым для обеспечения надежной работы службы в условиях эксплуатации. Используйте следующие сведения, чтобы свести к минимуму операционные требования для поддержки рабочих областей Log Analytics.

Контрольный список проектирования

  • Разработка архитектуры рабочей области с минимальным количеством рабочих областей в соответствии с вашими бизнес-требованиями.
  • Используйте инфраструктуру как код (IaC) при управлении несколькими рабочими областями.
  • Используйте аналитику рабочей области Log Analytics для отслеживания работоспособности и производительности рабочих областей Log Analytics.
  • Создайте правила генерации оповещений для упреждающего уведомления о операционных проблемах в рабочей области.
  • Убедитесь, что у вас есть четко определенный рабочий процесс для разделения данных.

Рекомендации по настройке

Рекомендация Преимущества
Разработайте стратегию рабочей области для удовлетворения бизнес-требований. Для получения рекомендаций по проектированию стратегии рабочих областей Log Analytics, включая их количество и размещение, посмотрите «Проектирование архитектуры рабочей области Log Analytics».

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

У вас могут быть требования к нескольким рабочим пространствам, например, нескольким арендаторам, или вам могут потребоваться рабочие пространства в нескольких регионах для поддержки требований к доступности. В этих случаях убедитесь, что у вас есть соответствующие процессы для управления этой повышенной сложностью.
Используйте инфраструктуру как код (IaC) при управлении несколькими рабочими областями. Используйте инфраструктуру как код (IaC), чтобы определить сведения о рабочих областях в ARM, BICEP или Terraform. Это позволяет использовать существующие процессы DevOps для развертывания новых рабочих областей и Политика Azure для обеспечения соблюдения их конфигурации.
Используйте аналитику рабочей области Log Analytics для отслеживания работоспособности и производительности рабочих областей Log Analytics. Аналитика рабочей области Log Analytics предоставляет единое представление об использовании, производительности, работоспособности, агентах, запросах и журналах изменений для всех рабочих областей. Просмотрите эти сведения регулярно, чтобы отслеживать работоспособность и работу каждой рабочей области.
Создайте правила генерации оповещений для упреждающего уведомления о операционных проблемах в рабочей области. Каждая рабочая область содержит таблицу операций, которая регистрирует важные действия, влияющие на рабочую область. Создайте правила генерации оповещений на основе этой таблицы, чтобы заранее получать уведомления при возникновении операционной проблемы. Чтобы упростить создание наиболее критически важных правил генерации оповещений, можно использовать рекомендуемые оповещения для рабочей области .
Убедитесь, что у вас есть четко определенный рабочий процесс для разделения данных. У вас могут быть разные требования к различным типам данных, хранящимся в рабочей области. Убедитесь, что вы четко понимаете такие требования, как хранение данных и безопасность при разработке стратегии рабочей области и настройке параметров, таких как разрешения и долгосрочное хранение. Вы также должны иметь четко определенный процесс, чтобы иногда очищать данные с личной информацией, которые случайно собираются.

Эффективность производительности

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

Оптимизация производительности начинается с запросов

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

Контрольный список проектирования

  • Оптимизируйте запросы журналов.
  • Настройка аудита запросов журнала.
  • Используйте аналитические сведения о рабочей области Log Analytics, чтобы определить медленные и неэффективные запросы.
  • Рассмотрите, подходит ли сценарий для правил сводки.

Рекомендации по настройке

Рекомендация Преимущества
Оптимизируйте запросы журналов, следуя инструкциям в Оптимизация запросов журналов в Azure Monitor. Хорошо оптимизированные запросы выполняются быстрее и потребляют меньше ресурсов, быстрее предоставляя статистическую информацию по данным и менее подвержены ограничению или отклонению. Чтобы повысить производительность, следуйте рекомендациям по написанию эффективных запросов языка запросов Kusto (KQL).
Настройка аудита запросов журнала. Аудит запросов журнала сохраняет время вычислений, необходимое для выполнения каждого запроса, и время, пока результаты не будут возвращены.
Используйте аналитические сведения о рабочей области Log Analytics, чтобы определить медленные и неэффективные запросы. Инструменты рабочего пространства Log Analytics используют эти данные для перечисления потенциально неэффективных запросов в рабочей области.
Рассмотрите, подходит ли ваш сценарий для сводных правил, таких как панели мониторинга за месяц или отчеты в течение длительного диапазона времени. Сводные правила повторно собирают данные больших наборов данных после определенной задержки, создавая сводные таблицы. Сводные таблицы запрашиваются более эффективно, чем исходные необработанные данные. Обратите внимание на правила сводки для создания и управления сводными таблицами в вашей рабочей области Log Analytics.

Следующий шаг

  • Дополнительные сведения о начале работы с Azure Monitor.