Суммируйте данные в рабочей области Log Analytics с использованием правил сводки

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

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

• Экономия затрат на подробные журналы, которые можно сохранить столько, сколько вам нужно, в недорогой таблице журналов «Базовый» и отправлять суммированные данные в таблицу «Аналитики» для анализа и составления отчета.

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

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

Ниже приведено видео, в которое представлен обзор некоторых преимуществ сводных правил:

Перейдите к пошаговому примеру с помощью этого руководства по сводным правилам.

Как работают сводные правила

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

Диаграмма, показывающая, как данные поступают в пространство Log Analytics и агрегируются и повторно принимаются в пространство с помощью правила суммирования.

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

• _RuleName: сводное правило, создающее агрегированную запись журнала.
• _RuleLastModifiedTime: когда правило было в последний раз изменено.
• _BinSize: интервал агрегирования.
• _BinStartTime: время начала агрегирования.

Можно настроить до 100 активных правил для агрегирования данных из нескольких таблиц и отправки агрегированных данных в отдельные целевые таблицы или одну и ту же таблицу.

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

Пример. Суммирование данных ContainerLogsV2

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

Этот запрос можно использовать в сводном правиле для агрегирования всех уникальных записей журнала в течение 60 минут, сохраняя полезные данные для анализа и удаления данных, которые вам не нужны:

ContainerLogV2 | summarize Count = count() by  Computer, ContainerName, PodName, PodNamespace, LogSource, LogLevel, Message = tostring(LogMessage.Message)

Ниже приведены необработанные данные в ContainerLogsV2 таблице:

Ниже приведены агрегированные данные, которые правило сводки отправляет в целевую таблицу:

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

Требуемые разрешения

Вопросы реализации

• Максимальное количество активных правил в рабочей области — 100.
• Сводные правила в настоящее время доступны только в общедоступном облаке.
• Сводное правило обрабатывает входящие данные и не может быть настроено в течение исторического диапазона времени.
• Создание обобщённого правила с запросом в другом арендаторе в сервисе Lighthouse не поддерживается.
• Добавление преобразования рабочей области в таблицу назначения "Сводные правила" не поддерживается.
• Использование union * и isfuzzy=true в запросе правил сводки не поддерживается.

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

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

Например, вычисление затрат для почасового правила, возвращающего 100 записей за ячейку, составляет:

Дополнительные сведения см. в разделе цены Azure Monitor.

Создание или обновление сводного правила

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

• Аналитика: поддерживает все операторы и функции KQL, кроме следующих:
  • Запросы между различными ресурсами, использующие выражения , workspaces() и app(), и запросы между различными службами, использующие выражения resource() и .
  • Подключаемые модули, которые переделывают схему данных, включая распаковку, сужение и поворот.
• Базовый: поддерживает все операторы KQL в одной таблице. Вы можете объединить до пяти аналитических таблиц с помощью оператора поиска.
• Функции: определяемые пользователем функции не поддерживаются. Поддерживаются системные функции, предоставляемые Microsoft.

Правила сводки наиболее полезны в терминах затрат и опыта запросов, когда запрос в правиле включает summarize оператор, и значительно уменьшается как количество результатов, так и объём. Например, стремление к получению результатов, составляющих 0,01% или меньше по сравнению с исходными данными. Перед созданием правила выполните запрос эксперимента в Log Analytics и проверьте следующие параметры:

1. Убедитесь, что запрос создает ожидаемые результаты и схему.
2. Запрос не достигает или приближается к ограничениям API запросов. Если запрос близок к ограничениям запроса, рассмотрите возможность использования меньшего размера bin для обработки меньшего размера данных на ячейку. Вы также можете изменить запрос, чтобы вернуть меньше записей или полей с большим объемом.
3. Размер записи в результатах меньше 1 МБ.

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

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}?api-version=2025-07-01
Authorization: {credential}
Content-Type: application/json

{
  "properties": {
      "ruleType": "User",
      "description": "My test rule",
      "ruleDefinition": {
          "query": "StorageBlobLogs | summarize count() by AccountName",
          "binSize": 30,
          "destinationTable": "MySummaryLogs_CL"
      }
  }
}

$subscriptionId = "<subscriptionId>"
$resourceGroup  = "<resourcegroup>"
$workspace      = "<workspace>"
$ruleName       = "<ruleName>"

$uri = "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.OperationalInsights/workspaces/$workspace/summarylogs/$ruleName?api-version=2025-07-01"

$token = (Get-AzAccessToken -ResourceUrl "https://management.azure.com/").Token

$headers = @{
    "Authorization" = "Bearer $token"
    "Content-Type"  = "application/json"
}

$body = @{
    properties = @{
        ruleType    = "User"
        description = "My test rule"
        ruleDefinition = @{
            query            = "StorageBlobLogs | summarize count() by AccountName"
            binSize          = 30
            destinationTable = "MySummaryLogs_CL"
        }
    }
} | ConvertTo-Json -Depth 10

Invoke-RestMethod `
    -Method Put `
    -Uri $uri `
    -Headers $headers `
    -Body $body

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "workspaceName": {
      "type": "String",
      "metadata": {
        "description": "The workspace name where summary rule is deployed."
      }
    },
    "summaryRuleName": {
      "type": "String",
      "metadata": {
        "description": "The summary rule name."
      }
    },
    "description": {
      "type": "String",
      "metadata": {
        "description": "A description of the rule."
      }
    },
    "location": {
      "defaultValue": "[resourceGroup().location]",
      "type": "String",
      "metadata": {
        "description": "The Location of the workspace summary rule is deployed."
      }
    },
    "ruleType": {
      "defaultValue": "User",
      "allowedValues": [
        "User"
      ],
      "type": "String",
      "metadata": {
        "description": "The summary rule type (User,System). Should be 'User' for and rule with query that you define."
      }
    },
    "query": {
      "type": "String",
      "metadata": {
      "description": "The query used in summary rules."
      }
    },
    "binSize": {
      "defaultValue": 60,
      "allowedValues": [
        20,
        30,
        60,
        120,
        180,
        360,
        720,
        1440
      ],
      "type": "Int",
      "metadata": {
        "description": "The execution interval in minutes, and the lookback time range."
      }
    },
    "destinationTable": {
      "type": "String",
      "metadata": {
        "description": "The name of the custom log table that the summary results are sent to. Name must end with '_CL'."
      }
    }
    // ----- optional -----
    // "displayName": {
    //   "type": "String",
    //   "metadata": {
    //     "description": "Optional - The summary rule display name when provided."
    //   }
    // },
    // "binDelay": {
    //   "type": "Int",
    //   "metadata": {
    //     "description": "Optional - The minimum wait time in minutes before bin execution. For example, value of '10' cause bin (01:00-02:00) to be executed after 02:10."
    //   }
    // },
    // "timeSelector": {
    //   "defaultValue": "TimeGenerated",
    //   "allowedValues": [
    //     "TimeGenerated"
    //   ],
    //   "type": "String",  
    //   "metadata": {
    //     "description": "Optional - The time field to be used by the summary rule. Must be 'TimeGenerated'."
    //   }
    // },
    // "binStartTime": {
    //   "type": "String",
    //   "metadata": {
    //     "description": "Optional - The Time of initial bin. Can start at current time minus binSize, or future, and in whole hours. For example: '2024-01-01T08:00'."
    //   }
    // }
  },
  "variables": {},
  "resources": [
    {
      "type": "Microsoft.OperationalInsights/workspaces/summaryLogs",
      "apiVersion": "2025-07-01",
      //"name": "[format('{0}/{1}', parameters('workspaceName'), parameters('summaryRuleName'))]",
      "name": "[concat(parameters('workspaceName'), '/', parameters('summaryRuleName'))]",
      "properties": {
        "ruleType": "[parameters('ruleType')]",
        "description": "[parameters('description')]",
        "ruleDefinition": {
          "query": "[parameters('query')]",
          "binSize": "[parameters('binSize')]",
          "destinationTable": "[parameters('destinationTable')]"
          // ----- optional -----
          //"binDelay": "[parameters('binDelay')]",
          //"timeSelector": "[parameters('timeSelector')]",
          //"binStartTime": "[parameters('binStartTime')]"
        }
      }
    }
  ]
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "workspaceName": {
      "value": "myworkspace"
    },
    "summaryRuleName": {
      "value": "myrulename"
    },
    "description": {
      "value": "My rule description"
    },
    "location": {
      "value": "eastus" //Log Analytics workspace region
    },
    "ruleType": {
      "value": "User"
    },
    "query": {
      "value": "StorageBlobLogs | summarize Count = count(), DurationMs98 = percentile(DurationMs, 90) by StatusCode, CallerIpAddress, OperationName"
    },
    "binSize": {
      "value": 20
    },
    "destinationTable": {
      "value": "MySummaryLogs_CL"
    }
  }
}

В этой таблице описаны параметры сводного правила:

Настройка времени агрегирования

По умолчанию сводное правило создает первую агрегирование вскоре после следующего часа.

Небольшая задержка в Azure Monitor учитывает время задержки приема — время между созданием данных в отслеживаемой системе и моментом, когда данные становятся доступными для анализа в Azure Monitor. По умолчанию эта задержка составляет от трех с половиной минут до 10 % от значения размера 'bin' перед агрегированием каждой ячейки. В большинстве случаев эта задержка гарантирует, что Azure Monitor агрегирует все данные, зарегистрированные в течение каждого периода bin.

Например:

• Вы создаете сводное правило с интервалом в 30 минут в 14:44. Первая агрегация создается в 15:04, что является следующим целым часом плюс 4 минуты задержки.
• Вы создаете сводное правило с размером 720 минут в 14:44. Первая агрегирование создается в 16:12, что является следующим целым часом плюс 72 минут (10% размером 720 ячеек) задержки.

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

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

Использование времени агрегирования по умолчанию

В этом примере сводное правило создается 07.06.2023 в 14:44, а Azure Monitor добавляет задержку по умолчанию четыре минуты.

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

В этом примере сводное правило создается в 2023-06-07 в 14:44, а правило включает следующие дополнительные параметры конфигурации:

• binStartTime: 08.06.2023 07:00
• binDelay: 8 минут

Просмотр сводного правила

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName1}?api-version=2025-07-01
Authorization: {credential}
Content-Type: application/json

# Variables
$subscriptionId = "<subscriptionId>"
$resourceGroup  = "<resourcegroup>"
$workspace      = "<workspace>"
$ruleName       = "<ruleName1>"

$uri = "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.OperationalInsights/workspaces/$workspace/summarylogs/$ruleName?api-version=$2025-07-01"

$token = (Get-AzAccessToken -ResourceUrl "https://management.azure.com/").Token

$headers = @{
    "Authorization" = "Bearer $token"
    "Content-Type"  = "application/json"
}

$response = Invoke-RestMethod `
    -Method Get `
    -Uri $uri `
    -Headers $headers

$response

Просмотр всех правил сводки

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs?api-version=2025-07-01
Authorization: {credential}
Content-Type: application/json

$subscriptionId = "<subscriptionId>"
$resourceGroup  = "<resourcegroup>"
$workspace      = "<workspace>"
$ruleName       = "<ruleName1>"

$uri = "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.OperationalInsights/workspaces/$workspace/summarylogs?api-version=2025-07-01"

$token = (Get-AzAccessToken -ResourceUrl "https://management.azure.com/").Token

$headers = @{
    "Authorization" = "Bearer $token"
    "Content-Type"  = "application/json"
}

$response = Invoke-RestMethod `
    -Method Get `
    -Uri $uri `
    -Headers $headers

$response

Остановка сводного правила

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

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}/stop?api-version=2025-07-01
Authorization: {credential}
Content-Type: application/json

$subscriptionId = "<subscriptionId>"
$resourceGroup  = "<resourcegroup>"
$workspace      = "<workspace>"
$ruleName       = "<ruleName>"

$uri = "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.OperationalInsights/workspaces/$workspace/summarylogs/$ruleName/stop?api-version=2025-07-01"

$token = (Get-AzAccessToken -ResourceUrl "https://management.azure.com/").Token

$headers = @{
    "Authorization" = "Bearer $token"
    "Content-Type"  = "application/json"
}

Invoke-RestMethod `
    -Method Post `
    -Uri $uri `
    -Headers $headers

Запуск правила сводки

При перезапуске правила Azure Monitor начинает обработку данных со следующего часа или на основе определенного параметра binStartTime (необязательно).

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}/start?api-version=2025-07-01
Authorization: {credential}
Content-Type: application/json

$subscriptionId = "<subscriptionId>"
$resourceGroup  = "<resourcegroup>"
$workspace      = "<workspace>"
$ruleName       = "<ruleName>"

$uri = "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.OperationalInsights/workspaces/$workspace/summarylogs/$ruleName/start?api-version=2025-07-01"

$token = (Get-AzAccessToken -ResourceUrl "https://management.azure.com/").Token

$headers = @{
    "Authorization" = "Bearer $token"
    "Content-Type"  = "application/json"
}

Invoke-RestMethod `
    -Method Post `
    -Uri $uri `
    -Headers $headers

Удалить правило сводки

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

DELETE https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}?api-version=2025-07-01
Authorization: {credential}
Content-Type: application/json

$subscriptionId = "<subscriptionId>"
$resourceGroup  = "<resourcegroup>"
$workspace      = "<workspace>"
$ruleName       = "<ruleName>"

$uri = "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.OperationalInsights/workspaces/$workspace/summarylogs/$ruleName?api-version=2025-07-01"

$token = (Get-AzAccessToken -ResourceUrl "https://management.azure.com/").Token

$headers = @{
    "Authorization" = "Bearer $token"
    "Content-Type"  = "application/json"
}

Invoke-RestMethod `
    -Method Delete `
    -Uri $uri `
    -Headers $headers

Корзина повторных попыток

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

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}?api-version=2025-07-01
Authorization: {credential}
Content-Type: application/json

{
  "properties": {
    "retryBinStartTime": "2026-02-16T10:00:00Z"
  }
}

# Variables
$subscriptionId = "<subscriptionId>"
$resourceGroup  = "<resourcegroup>"
$workspace      = "<workspace>"
$ruleName       = "<ruleName>"
$binStartTime   = "<YYYY-MM-DDTHH:mm:ssZ>"

$uri = "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.OperationalInsights/workspaces/$workspace/summarylogs/$ruleName?api-version=2025-07-01"

$token = (Get-AzAccessToken -ResourceUrl "https://management.azure.com/").Token

$headers = @{
    "Authorization" = "Bearer $token"
    "Content-Type"  = "application/json"
}

$body = @{
    properties = @{
        retryBinStartTime = $binStartTime 
    }
} | ConvertTo-Json -Depth 5

Invoke-RestMethod `
    -Method Put `
    -Uri $uri `
    -Headers $headers `
    -Body $body

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "workspaceName": {
      "type": "string"
    },
    "ruleName": {
      "type": "string"
    },
    "retryBinStartTime": {
      "type": "string"
    }
  },
  "resources": [
    {
      "type": "Microsoft.OperationalInsights/workspaces/summarylogs",
      "apiVersion": "2025-07-01",
      "name": "[format('{0}/{1}', parameters('workspaceName'), parameters('ruleName'))]",
      "properties": {
        "retryBinStartTime": "[parameters('retryBinStartTime')]"
      }
    }
  ]
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "workspaceName": {
      "value": "my-law-workspace"
    },
    "ruleName": {
      "value": "my-summary-rule"
    },
    "retryBinStartTime": {
      "value": "<YYYY-MM-DDTHH:mm:ssZ>"
    }
  }
}

Контроль правил сводки

Чтобы отслеживать сводные правила, включите категорию Summary Logs в diagnostic settings рабочей области Log Analytics. Azure Monitor отправляет сведения о выполнении сводного правила, включая время начала (Start), успешного (Succeeded) и неудавшегося (Failed) выполнения, в таблицу LASummaryLogs в рабочей области.

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

Этот запрос возвращает неудачные запуски:

LASummaryLogs | where Status == "Failed"

Этот запрос возвращает серии пакетов, в которых значение QueryDurationMs превышает 0,9, умноженное на 600 000 миллисекунд.

LASummaryLogs | where QueryDurationMs > 0.9 * 600000

Проверка полноты данных

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

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

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 Logs.
• Пройдите пошаговое руководство по использованию Log Analytics.
• Доступ к полной справочной документации по KQL.