Отправка данных журнала ресурсов Azure
Журналы ресурсов Azure — это журналы платформы, которые предоставляют аналитические сведения об операциях, выполненных с ресурсом Azure. Содержимое журналов ресурсов зависит от типа ресурса и конкретной службы Azure. По умолчанию журналы ресурсов не собираются. В этой статье описывается параметр диагностики, необходимый для каждого ресурса Azure, чтобы он мог отправлять журналы ресурсов в разные назначения.
Отправка в рабочую область Log Analytics
Отправьте журналы ресурсов в рабочую область Log Analytics, чтобы включить функции журналов Azure Monitor, например:
- сопоставление данных журнала ресурсов с другими данными мониторинга, собранными Azure Monitor;
- объединение записей журнала из нескольких ресурсов Azure, подписок и клиентов в единое место для совместного анализа;
- использование запросов журналов для сложного анализа и получения подробных аналитических сведений о данных журнала;
- Используйте оповещения поиска по журналам с сложной логикой оповещения.
Создайте параметр диагностики для отправки журналов ресурсов в рабочую область Log Analytics. Эти данные хранятся в таблицах, как описано в статье о структуре журналов Azure Monitor. Таблицы, используемые журналами ресурсов, зависят от типа коллекции, используемой ресурсом.
- Диагностика Azure — все данные записываются в таблицу AzureDiagnostics.
- Для конкретного ресурса — данные записываются в отдельную таблицу для каждой категории ресурса.
Для конкретного ресурса
В этом режиме отдельные таблицы в выбранной рабочей области создаются для каждой категории, выбранной в параметре диагностики. Мы рекомендуем этот метод, так как он:
- упрощает работу с данными в запросах журнала;
- улучшает обнаруживаемость схем и их структуры;
- повышает производительность в отношении задержки приема и времени выполнения запроса;
- позволяет предоставлять права управления доступом на основе ролей Azure для определенной таблицы.
Все службы Azure в конечном итоге будут использовать режим для конкретного ресурса.
В следующем примере создается три таблицы:
таблица
Service1AuditLogs;Поставщик ресурсов Категория A B О Служба 1 AuditLogs x1 y1 z1 Служба 1 AuditLogs x5 y5 z5 ... таблица
Service1ErrorLogs;Поставщик ресурсов Категория D E F Служба 1 ErrorLogs q1 w1 e1 Служба 1 ErrorLogs q2 w2 e2 ... таблица
Service2AuditLogs;Поставщик ресурсов Категория G H I Служба 2 AuditLogs j1 k1 l1 Служба 2 AuditLogs j3 k3 l3 ...
Режим диагностики Azure
В этом режиме все данные из любого параметра диагностики будут собираться в таблицу AzureDiagnostics. Этот устаревший метод используется сегодня большинством служб Azure. Так как несколько типов ресурсов отправляют данные в одну и ту же таблицу, их схема является надмножеством схем всех собираемых типов данных. Сведения о структуре этой таблицы и о том, как она работает с потенциально большим количеством столбцов, см. в статье Справочник по AzureDiagnostics.
Рассмотрим пример, когда параметры диагностики собираются в одной рабочей области для следующих типов данных:
- журналы аудита службы 1 со схемой, состоящей из столбцов A, B и C;
- журналы ошибок службы 1 со схемой, состоящей из столбцов D, E и F;
- журналы аудита службы 2 со схемой, состоящей из столбцов G, H и I.
Таблица AzureDiagnostics выглядит так:
| ResourceProvider | Категория | A | B | C | D | E | F | G | H | I |
|---|---|---|---|---|---|---|---|---|---|---|
| Microsoft.Service1 | AuditLogs | x1 | y1 | z1 | ||||||
| Microsoft.Service1 | ErrorLogs | q1 | w1 | e1 | ||||||
| Microsoft.Service2 | AuditLogs | j1 | k1 | l1 | ||||||
| Microsoft.Service1 | ErrorLogs | q2 | w2 | e2 | ||||||
| Microsoft.Service2 | AuditLogs | j3 | k3 | l3 | ||||||
| Microsoft.Service1 | AuditLogs | x5 | y5 | z5 | ||||||
| ... |
Выбор режима коллекции
Большинство ресурсов Azure записывают данные в рабочую область в режиме диагностики Azure или для конкретного ресурса, не предоставляя возможности выбора. Дополнительные сведения см. в статье Общая схема и схема для конкретных служб для журналов ресурсов Azure.
Все службы Azure в конечном итоге будут использовать режим конкретного ресурса. В рамках этого перехода некоторые ресурсы позволяют выбрать режим в параметре диагностики. Укажите режим для конкретного ресурса для любых новых параметров диагностики, так как этот режим упрощает управление данными. Это также поможет избежать сложных миграций позже.
Примечание.
Пример, в котором задается режим сбора с помощью шаблона Azure Resource Manager, см. в разделе Примеры шаблонов Resource Manager для параметров диагностики в Azure Monitor.
Можно изменить существующий параметр диагностики на режим, зависящий от ресурса. В этом случае собранные данные будут оставаться в таблице AzureDiagnostics до тех пор, пока не будут удалены в соответствии с параметром хранения для рабочей области. В выделенной таблице будут собираться новые данные. Для запроса данных из обеих таблиц используйте оператор union.
Перейдите к блогу об обновлениях Azure, чтобы просмотреть объявления о службах Azure с поддержкой режима для конкретного ресурса.
Отправка в Центры событий Azure
Отправьте журналы ресурсов в концентратор событий, чтобы отправить их за пределы Azure. Например, журналы ресурсов могут быть отправлены в стороннее решение SIEM или другие решения для анализа журналов. Журналы ресурсов из концентраторов событий потребляются в формате JSON с элементом records, который содержит записи во всех полезных данных. Схема зависит от типа ресурса, как описано в статье Общая схема и схемы для конкретных служб для журналов ресурсов Azure.
Следующий пример выходных данных взят из Центров событий Azure для журнала ресурсов.
{
"records": [
{
"time": "2019-07-15T18:00:22.6235064Z",
"workflowId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
"resourceId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA/RUNS/08587330013509921957/ACTIONS/SEND_EMAIL",
"category": "WorkflowRuntime",
"level": "Error",
"operationName": "Microsoft.Logic/workflows/workflowActionCompleted",
"properties": {
"$schema": "2016-04-01-preview",
"startTime": "2016-07-15T17:58:55.048482Z",
"endTime": "2016-07-15T18:00:22.4109204Z",
"status": "Failed",
"code": "BadGateway",
"resource": {
"subscriptionId": "00000000-0000-0000-0000-000000000000",
"resourceGroupName": "JohnKemTest",
"workflowId": "243aac67fe904cf195d4a28297803785",
"workflowName": "JohnKemTestLA",
"runId": "08587330013509921957",
"location": "westus",
"actionName": "Send_email"
},
"correlation": {
"actionTrackingId": "29a9862f-969b-4c70-90c4-dfbdc814e413",
"clientTrackingId": "08587330013509921958"
}
}
},
{
"time": "2019-07-15T18:01:15.7532989Z",
"workflowId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
"resourceId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA/RUNS/08587330012106702630/ACTIONS/SEND_EMAIL",
"category": "WorkflowRuntime",
"level": "Information",
"operationName": "Microsoft.Logic/workflows/workflowActionStarted",
"properties": {
"$schema": "2016-04-01-preview",
"startTime": "2016-07-15T18:01:15.5828115Z",
"status": "Running",
"resource": {
"subscriptionId": "00000000-0000-0000-0000-000000000000",
"resourceGroupName": "JohnKemTest",
"workflowId": "243aac67fe904cf195d4a28297803785",
"workflowName": "JohnKemTestLA",
"runId": "08587330012106702630",
"location": "westus",
"actionName": "Send_email"
},
"correlation": {
"actionTrackingId": "042fb72c-7bd4-439e-89eb-3cf4409d429e",
"clientTrackingId": "08587330012106702632"
}
}
}
]
}
Отправка в службу хранилища Azure
Отправьте журналы ресурсов в службу хранилища Azure, чтобы сохранить их для архивации. После создания параметра диагностики в учетной записи хранения будет создан контейнер хранилища, как только в одной из включенных категорий журналов возникнет событие журнала.
Примечание.
Вместо этого для архивации можно настроить отправку журнала ресурсов в рабочую область Log Analytics с политикой архивирования.
Большие двоичные объекты в контейнере используют следующее соглашение об именовании.
insights-logs-{log category name}/resourceId=/SUBSCRIPTIONS/{subscription ID}/RESOURCEGROUPS/{resource group name}/PROVIDERS/{resource provider name}/{resource type}/{resource name}/y={four-digit numeric year}/m={two-digit numeric month}/d={two-digit numeric day}/h={two-digit 24-hour clock hour}/m=00/PT1H.json
Например, BLOB-объект для группы безопасности сети может иметь примерно такое имя:
insights-logs-networksecuritygrouprulecounter/resourceId=/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/TESTRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUP/TESTNSG/y=2016/m=08/d=22/h=18/m=00/PT1H.json
Каждый PT1H.json большой двоичный объект содержит объект JSON с событиями из файлов журнала, полученных в течение часа, указанного в URL-адресе БОЛЬШОго двоичного объекта. В течение текущего часа события добавляются в файл PT1H.json по мере их получения независимо от того, когда они были созданы. Значение минуты в URL-адресе m=00 всегда создается как 00 большие двоичные объекты создаются по часам.
В файле PT1H.json каждое событие сохраняется в следующем формате. При этом используется общая схема верхнего уровня, но она будет уникальной для каждой службы Azure, как описано в статье Схемы журналов ресурсов.
Примечание.
Журналы записываются в большие двоичные объекты на основе времени получения журнала независимо от времени его создания. Это означает, что указанный большой двоичный объект может содержать данные журнала, которые находятся за пределами часа, указанного в URL-адресе БОЛЬШОго двоичного объекта. Где источник данных, например Application Insights, поддерживает отправку устаревших данных телеметрии большого двоичного объекта, который может содержать данные из предыдущих 48 часов.
В начале нового часа возможно, что существующие журналы по-прежнему записываются в большой двоичный объект предыдущего часа, а новые журналы записываются в большой двоичный объект нового часа.
{"time": "2016-07-01T00:00:37.2040000Z","systemId": "46cdbb41-cb9c-4f3d-a5b4-1d458d827ff1","category": "NetworkSecurityGroupRuleCounter","resourceId": "/SUBSCRIPTIONS/s1id1234-5679-0123-4567-890123456789/RESOURCEGROUPS/TESTRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/TESTNSG","operationName": "NetworkSecurityGroupCounters","properties": {"vnetResourceGuid": "{12345678-9012-3456-7890-123456789012}","subnetPrefix": "10.3.0.0/24","macAddress": "000123456789","ruleName": "/subscriptions/ s1id1234-5679-0123-4567-890123456789/resourceGroups/testresourcegroup/providers/Microsoft.Network/networkSecurityGroups/testnsg/securityRules/default-allow-rdp","direction": "In","type": "allow","matchedConnections": 1988}}
Интеграция Azure Monitor с продуктами партнеров
Журналы ресурсов также можно отправлять в партнерские решения, полностью интегрированные в платформу Azure. Список этих решений и сведения об их настройке см. в разделе Интеграции партнеров Azure Monitor.