Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Правило сводки позволяет агрегировать данные журнала в регулярных интервалах и отправлять агрегированные результаты в настраиваемую таблицу журналов в рабочей области Log Analytics. Используйте сводные правила для оптимизации данных:
Анализ и отчеты, особенно с большими наборами данных и диапазонами времени, необходимые для анализа безопасности и инцидентов, ежемесячного или ежегодного бизнес-отчетов и т. д. Часто истекает время ожидания сложных запросов к большому набору данных. Проще и эффективнее анализировать и сообщать о чистых и агрегированных сводных данных.
Экономия затрат на подробные журналы, которые можно сохранить столько, сколько вам нужно, в недорогой таблице журналов «Базовый» и отправлять суммированные данные в таблицу «Аналитики» для анализа и составления отчета.
Безопасность и конфиденциальность данных путем удаления или скрытия сведений о конфиденциальности в обобщенных общих данных и ограничения доступа к таблицам с необработанными данными.
В этой статье описывается, как работают правила сводки и как определять и просматривать сводные правила, а также приведены некоторые примеры использования и преимуществ сводных правил.
Ниже приведено видео, в которое представлен обзор некоторых преимуществ сводных правил:
Как работают сводные правила
Сводные правила выполняют пакетную обработку непосредственно в рабочей области Log Analytics. Сводное правило объединяет фрагменты данных, определенных размером двоичных объектов, на основе запроса KQL, и повторно собирает суммированные результаты в настраиваемую таблицу с планом журнала Аналитики в рабочей области Log Analytics.
Вы можете агрегировать данные из любой таблицы независимо от того, имеет ли таблица план аналитики или базовый план данных. Azure Monitor создает схему целевой таблицы на основе определяемого запроса. Если целевая таблица уже существует, Azure Monitor добавляет все столбцы, необходимые для поддержки результатов запроса. Все целевые таблицы также включают набор стандартных полей с информацией о сводных правилах, в том числе включая:
-
_RuleName: сводное правило, создающее агрегированную запись журнала. -
_RuleLastModifiedTime: когда правило было в последний раз изменено. -
_BinSize: интервал агрегирования. -
_BinStartTime: время начала агрегирования.
Можно настроить до 30 активных правил для агрегирования данных из нескольких таблиц и отправки агрегированных данных в отдельные целевые таблицы или одну и ту же таблицу.
Вы можете экспортировать сводные данные из пользовательской таблицы журналов в учетную запись хранения или Центры событий для дальнейшей интеграции, определив правило экспорта данных.
Пример. Суммирование данных ContainerLogsV2
Если вы отслеживаете контейнеры, вы загружаете большой объем подробных журналов в таблицу ContainerLogsV2.
Этот запрос можно использовать в сводном правиле для агрегирования всех уникальных записей журнала в течение 60 минут, сохраняя полезные данные для анализа и удаления данных, которые вам не нужны:
ContainerLogV2 | summarize Count = count() by Computer, ContainerName, PodName, PodNamespace, LogSource, LogLevel, Message = tostring(LogMessage.Message)
Ниже приведены необработанные данные в ContainerLogsV2 таблице:
Ниже приведены агрегированные данные, которые правило сводки отправляет в целевую таблицу:
Вместо ведения журнала сотен аналогичных записей в течение часа в целевой таблице отображается количество каждой уникальной записи, как определено в запросе KQL. Задайте базовый планContainerLogsV2 данных в таблице для дешевого хранения необработанных данных и используйте суммированные данные в целевой таблице для анализа.
Требуемые разрешения
| Действие | Требуемые разрешения |
|---|---|
| Создание или обновление сводного правила |
Microsoft.Operationalinsights/workspaces/summarylogs/write разрешения на рабочую область Log Analytics, как указано встроенной ролью Участника Log Analytics, например |
| Создание или обновление целевой таблицы |
Microsoft.OperationalInsights/workspaces/tables/write разрешения на рабочую область Log Analytics, как указано встроенной ролью Участника Log Analytics, например |
| Включение функции запроса в рабочей области |
Microsoft.OperationalInsights/workspaces/query/read разрешения на рабочую область Log Analytics, предоставляемые встроенной ролью Log Analytics Reader, например |
| Запросить все таблицы в рабочей области |
Microsoft.OperationalInsights/workspaces/query/*/read разрешения на рабочую область Log Analytics, предоставляемые встроенной ролью Log Analytics Reader, например |
| Запрос данных журналов в таблице |
Microsoft.OperationalInsights/workspaces/query/<table>/read разрешения на рабочую область Log Analytics, предоставляемые встроенной ролью Log Analytics Reader, например |
| Журналы запросов в таблице (действие таблицы) |
Microsoft.OperationalInsights/workspaces/tables/query/read разрешения на рабочую область Log Analytics, предоставляемые встроенной ролью Log Analytics Reader, например |
| Использование запросов, зашифрованных в управляемой клиентом учетной записи хранения |
Microsoft.Storage/storageAccounts/* разрешения для учетной записи хранилища, определенные встроенной ролью Участника учетной записи хранилища, например |
Вопросы реализации
- Максимальное количество активных правил в рабочей области — 30.
- Сводные правила в настоящее время доступны только в общедоступном облаке.
- Сводное правило обрабатывает входящие данные и не может быть настроено в течение исторического диапазона времени.
- Когда повторные попытки выполнения корзины исчерпаны, ячейка пропускается и не может быть выполнена повторно.
- Запрос рабочей области Log Analytics в другом клиенте с помощью Lighthouse не поддерживается.
- Добавление преобразования рабочей области в таблицу назначения "Сводные правила" не поддерживается.
Модель ценообразования
Для правил сводки не взимается дополнительная плата. Вы платите только за запрос и прием результатов в целевую таблицу на основе плана таблицы исходной таблицы, в которой выполняется запрос:
| План исходной таблицы | Затраты на запросы | Общая стоимость интеграции результатов |
|---|---|---|
| Аналитика | Бесплатны. | Прием журналов Аналитики |
| Базовый и вспомогательный | Сканирование данных | Прием журналов Аналитики |
Например, вычисление затрат для почасового правила, возвращающего 100 записей за ячейку, составляет:
| План исходной таблицы | Ежемесячное вычисление цен |
|---|---|
| Аналитика | Цена приема x объем записей x количество записей x 24 часа x 30 дней. |
| Базовый и вспомогательный | Цена сканирования данных x отсканированный объем и цена приема x объем записи x количество записей x 24 часа x 30 дней. Для непрерывного выполнения правила выполняется проверка всех входящих данных в исходную таблицу. |
Дополнительные сведения см. в разделе о ценах на Azure Monitor.
Создание или обновление сводного правила
Операторы, которые можно использовать в правиле обобщения запроса, зависят от плана исходной таблицы в запросе.
- Аналитика: поддерживает все операторы и функции KQL, кроме следующих:
- Запросы между различными ресурсами, использующие выражения ,
workspaces()иapp(), и запросы между различными службами, использующие выраженияresource()и . - Подключаемые модули, которые переделывают схему данных, включая распаковку, сужение и поворот.
- Запросы между различными ресурсами, использующие выражения ,
- Базовый: поддерживает все операторы KQL в одной таблице. Вы можете объединить до пяти аналитических таблиц с помощью оператора поиска.
- Функции: определяемые пользователем функции не поддерживаются. Поддерживаются системные функции, предоставляемые Microsoft.
Правила сводки наиболее полезны в плане затрат и запросов при значительном сокращении количества результатов или объема. Например, стремление к получению результатов, составляющих 0,01% или меньше по сравнению с исходными данными. Прежде чем создать правило, выполните запрос эксперимента в Log Analytics и проверьте следующее:
- Убедитесь, что запрос создает ожидаемые результаты и схему.
- Запрос не достигает или приближается к ограничениям API запросов.
- Размер записи в результатах меньше 1 МБ.
Если запрос близок к ограничениям запроса, рассмотрите возможность использования меньшего размера bin для обработки меньшего размера данных на ячейку. Вы также можете изменить запрос, чтобы вернуть меньше записей или полей с большим объемом.
При обновлении запроса, если в сводных результатах становится меньше полей, Azure Monitor автоматически не удаляет столбцы из целевой таблицы, и вам необходимо вручную удалить столбцы из вашей таблицы.
Чтобы создать или обновить сводное правило, выполните этот PUT вызов API:
PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}?api-version=2023-01-01-preview
Authorization: {credential}
{
"properties": {
"ruleType": "User",
"description": "My test rule",
"ruleDefinition": {
"query": "StorageBlobLogs | summarize count() by AccountName",
"binSize": 30,
"destinationTable": "MySummaryLogs_CL"
}
}
}
В этой таблице описаны параметры сводного правила:
| Параметр | Допустимые значения | Описание |
|---|---|---|
ruleType |
User или System |
Указывает тип правила. - User: определяемые правила. - System: предопределенные правила, управляемые службами Azure. |
description |
Строка | Описывает правило и ее функцию. Этот параметр полезен при наличии нескольких правил и может помочь в управлении правилами. |
binSize |
20, 30, 60120180360720или 1440 (минуты) |
Определяет интервал агрегирования и диапазон времени обратного просмотра. Например, если задано "binSize": 120, вы можете получить записи для 02:00 to 04:00 и 04:00 to 06:00. |
query |
Запрос языка запросов Kusto (KQL) | Определяет запрос, выполняемый в правиле. Не нужно указывать диапазон времени, так как binSize параметр определяет интервал агрегирования, например, 02:00 to 03:00 если "binSize": 60. При добавлении временного фильтра в запрос используемый временной диапазон определяется как пересечение фильтра и размера интервала. |
destinationTable |
tablename_CL |
Указывает имя конечной настраиваемой таблицы журналов. Значение имени должно иметь суффикс _CL. Azure Monitor создает таблицу в рабочей области, если она еще не существует, на основе запроса, заданного в правиле. Если таблица уже существует в рабочей области, Azure Monitor добавляет новые столбцы, представленные в запросе. Если результаты сводки включают зарезервированное имя столбца, например TimeGenerated, _IsBillable, _ResourceIdTenantIdили Type Azure Monitor, добавляет префикс к _Original исходным полям, чтобы сохранить их исходные значения. |
binDelay (необязательно) |
Целое число (минуты) | Задает время ожидания перед выполнением пакета данных, что обычно полезно при работе с поздно поступающими данными, также известными как задержка загрузки, чтобы позволить основным данным прибыть. Задержка по умолчанию составляет от трех с половиной минут до 10 % binSize значения. Если вы знаете, что данные, которые вы запрашиваете, обычно приемируются с задержкой, задайте binDelay параметр с известным значением задержки или больше, до 1440 минут. Дополнительные сведения см. в разделе "Настройка времени агрегирования".В некоторых случаях Azure Monitor может начать выполнение bin немного позже установленной задержки, чтобы обеспечить надежность службы и успешное выполнение запросов. |
binStartTime (необязательно) |
Дата/время в%Y-%n-%eT%H:%M %Z формат |
Указывает дату и время начального выполнения ячейки. Значение может начинаться с даты создания правила минус значение или более поздние binSize и целые часы. Например, если дата и время имеет 2023-12-03T12:13ZbinSize значение 1440, самое раннее допустимое binStartTime значение равно 2023-12-02T13:00Z, а агрегирование включает данные, зарегистрированные в диапазоне от 02T13:00 до 03T13:00. В этом сценарии правила начинают агрегировать 03T13:00 плюс значение по умолчанию или указанную задержку. Параметр binStartTime полезен в ежедневных сценариях сводки. Предположим, что вы находитесь в часовом поясе UTC-8, и вы создаете ежедневное правило в 2023-12-03T12:13Z. Вы хотите, чтобы правило завершилось до начала вашего дня, который начинается в 8:00 (00:00 UTC). Установите для параметра binStartTime значение 2023-12-02T22:00Z. Первая агрегирование включает все данные, зарегистрированные в диапазоне от 02T:06:00 до 03T:06:00, а правило выполняется одновременно ежедневно. Дополнительные сведения см. в разделе "Настройка времени агрегирования".При обновлении правил можно выполнить следующие действия. — Используйте существующее binStartTime значение или удалите binStartTime параметр, в этом случае выполнение продолжается на основе начального определения.— Обновите правило, установив новое значение binStartTime, чтобы задать новое значение даты и времени. |
displayName (необязательно) |
Строка | Указывает отображаемое имя правила в интерфейсах портала Azure. |
timeSelector (необязательно) |
TimeGenerated |
Определяет поле метки времени, которое Azure Monitor использует для агрегирования данных. Например, если задано "binSize": 120, можно получить записи со значением TimeGenerated между 02:00 и 04:00. |
Настройка времени агрегирования
По умолчанию сводное правило создает первую агрегирование вскоре после следующего часа.
Короткая задержка, которую добавляет Azure Monitor, учитывает задержку на этапе приема данных, или время, прошедшее между созданием данных в отслеживаемой системе и временем, когда они становятся доступными для анализа в Azure Monitor. По умолчанию эта задержка составляет от трех с половиной минут до 10 % от значения размера 'bin' перед агрегированием каждой ячейки. В большинстве случаев эта задержка гарантирует, что Azure Monitor агрегирует все данные, зарегистрированные в течение каждого периода bin.
Например:
Вы создаете сводное правило с интервалом в 30 минут в 14:44.
Правило создает первую агрегацию вскоре после 15:00 , например, в 15:04 для данных, зарегистрированных в диапазоне от 14:30 до 15:00.
Вы создаете сводное правило с размером 720 минут (12 часов) в 14:44.
Правило создает первую агрегацию в 16:12 — через 72 минуты (10% от размера корзины 720) после 13:00 — для данных, зарегистрированных в диапазоне от 03:00 до 15:00.
Используйте параметры binStartTime и binDelay для изменения времени первой агрегации и задержки, которую добавляет Azure Monitor перед каждой агрегацией.
В следующих разделах приведены примеры времени агрегирования по умолчанию и более сложные параметры времени агрегирования.
Использование времени агрегирования по умолчанию
В этом примере сводное правило создается в 2023-06-07 в 14:44, а Azure Monitor добавляет задержку по умолчанию в четыре минуты.
| binSize (минуты) | Начальное выполнение правила | Первое агрегирование | Второе агрегирование |
|---|---|---|---|
| 1440 | 2023-06-07 15:04 | 2023-06-06 15:00 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-08 15:00 |
| 720 | 2023-06-07 15:04 | 2023-06-07 03:00 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-08 03:00 |
| 360 | 2023-06-07 15:04 | 2023-06-07 09:00 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-07 21:00 |
| 180 | 2023-06-07 15:04 | 2023-06-07 12:00 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-07 18:00 |
| 120 | 2023-06-07 15:04 | 2023-06-07 13:00 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-07 17:00 |
| шестьдесят | 2023-06-07 15:04 | 2023-06-07 14:00 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-07 16:00 |
| 30 | 2023-06-07 15:04 | 2023-06-07 14:30 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-07 15:30 |
| 20 | 2023-06-07 15:04 | 2023-06-07 14:40 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-07 15:20 |
Настройка необязательных параметров времени агрегирования
В этом примере сводное правило создается в 2023-06-07 в 14:44, а правило включает следующие дополнительные параметры конфигурации:
-
binStartTime: 08.06.2023 07:00 -
binDelay: 8 минут
| binSize (минуты) | Начальное выполнение правила | Первое агрегирование | Второе агрегирование |
|---|---|---|---|
| 1440 | 2023-06-09 07:08 | 2023-06-08 07:00 - 2023-06-09 07:00 | 2023-06-09 07:00 - 2023-06-10 07:00 |
| 720 | 2023-06-08 19:08 | 2023-06-08 07:00 - 2023-06-08 19:00 | 2023-06-08 19:00 - 2023-06-09 07:00 |
| 360 | 2023-06-08 13:08 | 2023-06-08 07:00 - 2023-06-08 13:00 | 2023-06-08 13:00 - 2023-06-08 19:00 |
| 180 | 2023-06-08 10:08 | 2023-06-08 07:00 - 2023-06-08 10:00 | 2023-06-08 10:00 - 2023-06-08 13:00 |
| 120 | 2023-06-08 09:08 | 2023-06-08 07:00 - 2023-06-08 09:00 | 2023-06-08 09:00 - 2023-06-08 11:00 |
| шестьдесят | 2023-06-08 08:08 | 2023-06-08 07:00 - 2023-06-08 08:00 | 08.06.2023 08:00 - 08.06.2023 09:00 |
| 30 | 2023-06-08 07:38 | 2023-06-08 07:00 - 2023-06-08 07:30 | 2023-06-08 07:30 - 2023-06-08 08:00 |
| 20 | 2023-06-08 07:28 | 2023-06-08 07:00 - 2023-06-08 07:20 | 2023-06-08 07:20 - 2023-06-08 07:40 |
Просмотр правил сводки
Используйте этот GET вызов API для просмотра конфигурации для определенного сводного правила:
GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName1}?api-version=2023-01-01-preview
Authorization: {credential}
Используйте этот GET вызов API для просмотра конфигурации всех сводных правил в рабочей области Log Analytics:
GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs?api-version=2023-01-01-preview
Authorization: {credential}
Остановка и перезапуск сводного правила
Вы можете остановить правило на некоторое время — например, если вы хотите убедиться, что данные загружаются в таблицу, и не хотите влиять на сводные таблицы и отчеты. При перезапуске правила Azure Monitor начинает обработку данных со следующего часа или на основе определенного binStartTime (необязательного) параметра.
Чтобы остановить правило, используйте этот POST вызов API:
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}/stop?api-version=2023-01-01-preview
Authorization: {credential}
Чтобы перезапустить правило, используйте этот POST вызов API:
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}/start?api-version=2023-01-01-preview
Authorization: {credential}
Удалить правило сводки
В рабочей области Log Analytics можно использовать до 30 активных правил сводки. Если вы хотите создать новое правило, но у вас уже есть 30 активных правил, необходимо остановить или удалить активное правило сводки.
Чтобы удалить правило, используйте этот DELETE вызов API:
DELETE https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}?api-version=2023-01-01-preview
Authorization: {credential}
Контроль правил сводки
Чтобы отслеживать правила сводки, включите категорию "Сводные журналы" в параметрах диагностики рабочей области Log Analytics. Azure Monitor отправляет сведения об исполнении сводного правила, включая информацию о начале выполнения, успешном и неудачном завершении, в таблицу LASummaryLogs в вашей рабочей области.
Мы рекомендуем вам настроить правила оповещений журнала для получения уведомления о сбоях контейнера или когда выполнение контейнера приближается к тайм-ауту, как показано ниже. В зависимости от причины сбоя можно уменьшить размер ячейки для обработки меньшего количества данных при каждом выполнении или изменить запрос, чтобы вернуть меньше записей или полей с большим объемом.
Этот запрос возвращает неудачные запуски:
LASummaryLogs | where Status == "Failed"
Этот запрос возвращает серии пакетов, в которых значение QueryDurationMs превышает 0,9, умноженное на 600 000 миллисекунд.
LASummaryLogs | where QueryDurationMs > 0.9 * 600000
Проверка полноты данных
Сводные правила предназначены для масштабирования и включают механизм повторных попыток для преодоления временных сбоев служб или запросов, связанных с ограничениями запросов, например. Механизм повторных попыток делает 10 попыток объединить неудачный контейнер в течение восьми часов и пропускает его, если все попытки исчерпаны. Правило isActive: false устанавливается и приостанавливается после восьми последовательных повторных попыток bin. Если включить правила сводки мониторинга, Azure Monitor регистрирует событие в LASummaryLogs таблице в рабочей области.
Вы не можете повторно запустить неудачный запуск корзины, но для просмотра неудачных запусков можно использовать следующий запрос:
let startTime = datetime("2024-02-16");
let endtTime = datetime("2024-03-03");
let ruleName = "myRuleName";
let stepSize = 20m; // The stepSize value is equal to the bin size defined in the rule
LASummaryLogs
| where RuleName == ruleName
| where Status == 'Succeeded'
| make-series dcount(BinStartTime) default=0 on BinStartTime from startTime to endtTime step stepSize
| render timechart
Этот запрос отображает результаты в виде диаграммы времени:
См. раздел правил сводки монитора для вариантов исправления правил и упреждающих оповещений.
Шифрование запросов сводного правила с помощью ключей, управляемых клиентом
Запрос KQL может содержать конфиденциальную информацию в комментариях или синтаксисе запроса. Чтобы зашифровать запросы сводного правила, свяжите учетную запись хранения с рабочей областью Log Analytics и используйте ключи, управляемые клиентом.
Рекомендации при работе с зашифрованными запросами:
- Связывание учетной записи хранения для шифрования запросов не прерывает существующие правила.
- По умолчанию Azure Monitor хранит запросы сводного правила в хранилище Log Analytics. Если у вас есть правила сводки перед связыванием учетной записи хранения с рабочей областью Log Analytics, обновите правила сводки, чтобы запросы сохраняли существующие запросы в учетной записи хранения.
- Запросы, сохраненные в учетной записи хранения, находятся в таблице
CustomerConfigurationStoreTable. Эти запросы считаются артефактами службы и их формат может измениться. - Вы можете использовать ту же учетную запись хранения для запросов по сводным правилам, сохраненных запросов в Log Analytics и журнальных оповещений.
Устранение неполадок с правилами сводки
В этом разделе представлены советы по устранению неполадок со сводными правилами.
Таблица назначения сводного правила случайно удалена
При удалении целевой таблицы во время активности сводного правила правило приостанавливается, а Azure Monitor отправляет событие LASummaryLogs в таблицу с сообщением о том, что правило приостановлено.
Если не требуется сводка результатов в целевой таблице, удалите правило и таблицу. Если вам нужно восстановить сводные результаты, выполните действия, описанные в разделе "Создание или обновление сводных правил", чтобы повторно создать таблицу. Целевая таблица восстанавливается, включая данные, поглощенные перед удалением, в зависимости от политики хранения в таблице.
Если не требуется сводка результатов в целевой таблице, удалите правило и таблицу. Если вам нужны сводные результаты, выполните действия, описанные в разделе "Создание или обновление сводных правил ", чтобы повторно создать целевую таблицу и восстановить все данные, включая данные, принятые перед удалением, в зависимости от политики хранения в таблице.
Запрос использует операторы, создающие новые столбцы в целевой таблице
Схема целевой таблицы определяется при создании или обновлении правила сводки. Если запрос в правиле сводки включает операторы, разрешающие расширение выходной схемы на основе входящих данных, например, если запрос использует функцию arg_max(expression, *), то Azure Monitor не добавляет новые столбцы в целевую таблицу после создания или обновления правила сводки, и выходные данные, которые требуют эти столбцы, будут отброшены. Чтобы добавить новые поля в целевую таблицу, обновите сводное правило или добавьте столбец в таблицу вручную.
Данные в удаленных столбцах остаются в рабочей области на основе параметров хранения таблицы
При удалении поля в запросе столбцы и данные остаются в месте назначения и на основе периода хранения , определенного в таблице или рабочей области. Если вам не нужны данные в целевой таблице, удалите столбцы из схемы таблицы. Если вы добавите столбцы с тем же именем, все данные, которые не старше срока хранения отображаются снова.
Связанный контент
- Узнайте больше о планах данных для журналов Azure Monitor.
- Ознакомьтесь с руководством по использованию режима KQL в Log Analytics.
- Доступ к полной справочной документации по KQL.