журналов ресурсов Azure.

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

Отправка в рабочую область Log Analytics

Отправьте журналы ресурсов в рабочую область Log Analytics, чтобы включить функции журналов Azure Monitor, например:

  • сопоставление данных журнала ресурсов с другими данными мониторинга, собранными Azure Monitor;
  • объединение записей журнала из нескольких ресурсов Azure, подписок и клиентов в единое место для совместного анализа;
  • использование запросов журналов для сложного анализа и получения подробных аналитических сведений о данных журнала;
  • использование оповещений журнала со сложной логикой.

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

  • Диагностика Azure — все данные записываются в таблицу AzureDiagnostics.
  • Для конкретного ресурса — данные записываются в отдельную таблицу для каждой категории ресурса.

Зависящий от ресурса

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

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

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

В предыдущем примере создаются три таблицы:

  • таблица Service1AuditLogs;

    Поставщик ресурсов Категория Объект B C
    Service1 AuditLogs x1 y1 z1
    Service1 AuditLogs x5 y5 z5
    ...
  • таблица Service1ErrorLogs;

    Поставщик ресурсов Категория D E C
    Service1 ErrorLogs q1 w1 e1
    Service1 ErrorLogs q2 w2 e2
    ...
  • таблица Service2AuditLogs.

    Поставщик ресурсов Категория G H I
    Service2 AuditLogs j1 k1 l1
    Service2 AuditLogs j3 k3 l3
    ...

Режим диагностики Azure

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

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

  • журналы аудита службы 1 со схемой, состоящей из столбцов A, B и C;
  • журналы ошибок службы 1 со схемой, состоящей из столбцов D, E и F;
  • журналы аудита службы 2 со схемой, состоящей из столбцов G, H и I.

Таблица AzureDiagnostics выглядит так:

ResourceProvider Категория Объект B C D E C 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 в конечном итоге будут использовать режим для конкретного ресурса. В рамках этого перехода некоторые ресурсы позволяют выбрать режим в параметре диагностики. Укажите режим для конкретного ресурса для любых новых параметров диагностики, так как этот режим упрощает управление данными. Это также поможет избежать сложных миграций позже.

Screenshot that shows the Diagnostics settings mode selector.

Примечание

Пример, в котором задается режим сбора с помощью шаблона 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

Каждый BLOB-объект PT1H.json содержит BLOB-объект JSON с событиями, произошедшими в течение часа, как указано в URL-адресе этого объекта (например, h=12). В течение заданного часа события добавляются в файл PT1H.json по мере возникновения. Значение минуты (m=00) всегда равно 00, так как события журнала разбиваются на отдельные BLOB-объекты каждый час.

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

Примечание

Журналы записываются в BLOB-объект, соответствующий времени создания каждого журнала, а не времени его получения. Следовательно, при переходе к новому часу некоторое время запись ведется сразу в два BLOB-объекта: за предыдущий и за текущий час.

{"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.

Дальнейшие действия