Агрегированные данные в рабочей области Log Analytics с помощью правил сводки (предварительная версия)
Правило сводки позволяет агрегировать данные журнала в регулярных интервалах и отправлять агрегированные результаты в настраиваемую таблицу журналов в рабочей области 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()также выражения и межслужбные запросы, использующиеADX()выражения иARG()выражения. - Подключаемые модули, которые переделывать схему данных, включая распаковку, сужение и сводку.
- Запросы между ресурсами, которые используют
- Базовый: поддерживает все операторы KQL в одной таблице. Вы можете объединить до пяти таблиц Аналитики с помощью оператора подстановки .
- Функции: определяемые пользователем функции не поддерживаются. Поддерживаются системные функции, предоставляемые Microsoft.
Правила сводки наиболее полезны в плане затрат и запросов при значительном сокращении количества результатов или объема. Например, цель получения тома результатов 0,01% или меньше источника. Прежде чем создать правило, выполните запрос эксперимента в Log Analytics и убедитесь, что запрос не достигает или находится рядом с ограничениями API запросов. Убедитесь, что запрос создает ожидаемые результаты и схему. Если запрос близок к ограничениям запроса, рассмотрите возможность использования меньшего размера 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"
}
}
}
В этой таблице описаны параметры сводного правила:
| Параметр | Допустимые значения | Description |
|---|---|---|
ruleType |
User или System |
Указывает тип правила. - User: определяемые правила. - System: предопределенные правила, управляемые службами Azure. |
description |
Строка | Описывает правило и ее функцию. Этот параметр полезен при наличии нескольких правил и может помочь в управлении правилами. |
binSize |
20, 30, 60360720120180или 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 после задержки набора bin, чтобы обеспечить надежность службы и успешное выполнение запросов. |
binStartTime (необязательно) |
Дата и время в%Y-%n-%eT%H:%M %Z формат |
Указывает дату и время начального выполнения ячейки. Значение может начинаться с даты создания правила минус значение или более поздние binSize и целые часы. Например, если дата и время имеет 2023-12-03T12:13Z binSize значение 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 значением, чтобы задать новое значение datetime. |
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 |
| 60 | 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: 2023-06-08 07:00binDelay: 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 |
| 60 | 2023-06-08 08:08 | 2023-06-08 07:00 - 2023-06-08 08:00 | 2023-06-08 08:00 - 2023-06-08 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 отправляет сведения о выполнении сводного правила, включая краткое выполнение правила Start, Succeeded и Failed information, в таблицу LASummaryLogs в рабочей области.
Рекомендуется настроить правила генерации оповещений журнала для получения уведомлений о сбоях корзины или при истечении времени ожидания выполнения корзины, как показано ниже. В зависимости от причины сбоя можно уменьшить размер ячейки для обработки меньшего количества данных при каждом выполнении или изменить запрос, чтобы вернуть меньше записей или полей с большим объемом.
Этот запрос возвращает неудачные запуски:
LASummaryLogs | where Status == "Failed"
Этот запрос возвращает ячейку, в которой QueryDurationMs значение больше 0,9 x 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.