Поделиться через


Отправка журналов ресурсов Azure в рабочие области Log Analytics, Центры событий или служба хранилища Azure

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

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

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

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

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

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

Для конкретного ресурса

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

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

Описание журналов и таблиц, относящихся к ресурсам, см. в разделе "Поддерживаемые категории журналов ресурсов" для Azure Monitor

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

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

Таблица AzureDiagnostics содержит идентификатор ресурса ресурса, создающего журнал, категорию журнала и время создания журнала, а также свойства конкретного ресурса.

Снимок экрана: таблица AzureDiagnostics в рабочей области Log Analytics.

Выбор режима коллекции

Большинство ресурсов 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/AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
            "resourceId": "/SUBSCRIPTIONS/AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E/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": "AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E",
                    "resourceGroupName": "JohnKemTest",
                    "workflowId": "2222cccc-33dd-eeee-ff44-aaaaaa555555",
                    "workflowName": "JohnKemTestLA",
                    "runId": "08587330013509921957",
                    "location": "westus",
                    "actionName": "Send_email"
                },
                "correlation": {
                    "actionTrackingId": "3333dddd-44ee-ffff-aa55-bbbbbbbb6666",
                    "clientTrackingId": "08587330013509921958"
                }
            }
        },
        {
            "time": "2019-07-15T18:01:15.7532989Z",
            "workflowId": "/SUBSCRIPTIONS/AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
            "resourceId": "/SUBSCRIPTIONS/AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E/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": "AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E",
                    "resourceGroupName": "JohnKemTest",
                    "workflowId": "dddd3333-ee44-5555-66ff-777777aaaaaa",
                    "workflowName": "JohnKemTestLA",
                    "runId": "08587330012106702630",
                    "location": "westus",
                    "actionName": "Send_email"
                },
                "correlation": {
                    "actionTrackingId": "ffff5555-aa66-7777-88bb-999999cccccc",
                    "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/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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": "a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1","category": "NetworkSecurityGroupRuleCounter","resourceId": "/SUBSCRIPTIONS/AAAA0A0A-BB1B-CC2C-DD3D-EEEEEE4E4E4E/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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/testresourcegroup/providers/Microsoft.Network/networkSecurityGroups/testnsg/securityRules/default-allow-rdp","direction": "In","type": "allow","matchedConnections": 1988}}

Интеграция Azure Monitor с продуктами партнеров

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

Следующие шаги