Registos de recursos do Azure

Os registos de recursos Azure são registos de plataformas que fornecem informações sobre operações que foram realizadas dentro de um recurso Azure. O conteúdo dos registos de recursos varia consoduros em função do serviço Azure e do tipo de recurso. Os registos de recursos não são recolhidos por defeito. Este artigo descreve a definição de diagnóstico necessária para que cada recurso Azure envie os seus registos de recursos para diferentes destinos.

Enviar para a área de trabalho do Log Analytics

Envie registos de recursos para um espaço de trabalho do Log Analytics para ativar as funcionalidades de Registos do Monitor Azure, onde pode:

  • Correlacionar os dados de registo de recursos com outros dados de monitorização recolhidos pelo Azure Monitor.
  • Consolidar entradas de registo de múltiplos recursos Azure, subscrições e inquilinos em um local para análise em conjunto.
  • Use consultas de registo para realizar análises complexas e obtenha informações profundas sobre dados de registo.
  • Utilize alertas de registo com lógica de alerta complexa.

Crie uma definição de diagnóstico para enviar registos de recursos para um espaço de trabalho Log Analytics. Estes dados são armazenados em tabelas conforme descrito na Estrutura de Registos monitores Azure. As tabelas utilizadas pelos registos de recursos dependem do tipo de recolha que o recurso está a utilizar:

  • Diagnósticos Azure: Todos os dados são escritos na tabela AzureDiagnostics .
  • Específico de recursos: Os dados são escritos em tabelas individuais para cada categoria do recurso.

Específico de recursos

Neste modo, são criadas tabelas individuais no espaço de trabalho selecionado para cada categoria selecionada na definição de diagnóstico. Recomendamos este método porque:

  • Facilita o trabalho com os dados em consultas de registo.
  • Proporciona uma melhor descoberta dos esquemas e da sua estrutura.
  • Melhora o desempenho através da latência da ingestão e dos tempos de consulta.
  • Fornece a capacidade de conceder ao Azure direitos de controlo de acesso baseados em funções numa tabela específica.

Todos os serviços da Azure irão eventualmente migrar para o modo específico de recursos.

O exemplo anterior cria três tabelas:

  • Tabela Service1AuditLogs

    Fornecedor de recursos Categoria A B C
    Serviço1 AuditLogs x1 y1 z1
    Serviço1 AuditLogs x5 y5 z5
    ...
  • Tabela Service1ErrorLogs

    Fornecedor de recursos Categoria D E F
    Serviço1 ErrorLogs q1 w1 e1
    Serviço1 ErrorLogs q2 w2 e2
    ...
  • Tabela Service2AuditLogs

    Fornecedor de recursos Categoria G H I
    Serviço2 AuditLogs j1 k1 L1
    Serviço2 AuditLogs j3 k3 L3
    ...

Modo de diagnóstico Azure

Neste modo, todos os dados de qualquer definição de diagnóstico são recolhidos na tabela AzureDiagnostics . Este método legado é usado hoje pela maioria dos serviços da Azure. Como vários tipos de recursos enviam dados para a mesma tabela, o seu esquema é o superconjunto dos esquemas de todos os diferentes tipos de dados que estão a ser recolhidos. Para mais detalhes sobre a estrutura desta tabela e como funciona com este número potencialmente grande de colunas, consulte a referência AzureDiagnostics.

Considere um exemplo em que as definições de diagnóstico são recolhidas no mesmo espaço de trabalho para os seguintes tipos de dados:

  • Os registos de auditoria do serviço 1 têm um esquema que consiste nas colunas A, B e C
  • Os registos de erro do serviço 1 têm um esquema que consiste nas colunas D, E e F
  • Os registos de auditoria do serviço 2 têm um esquema que consiste nas colunas G, H e I

A AzureDiagnostics tabela parece este exemplo:

ResourceProvider Categoria A B C D E F G H I
Microsoft. Serviço1 AuditLogs x1 y1 z1
Microsoft. Serviço1 ErrorLogs q1 w1 e1
Microsoft. Serviço2 AuditLogs j1 k1 L1
Microsoft. Serviço1 ErrorLogs q2 w2 e2
Microsoft. Serviço2 AuditLogs j3 k3 L3
Microsoft. Serviço1 AuditLogs x5 y5 z5
...

Selecione o modo de recolha

A maioria dos recursos Azure escrevem dados para o espaço de trabalho em diagnósticos Azure ou modo específico de recursos sem lhe dar uma escolha. Para obter mais informações, consulte esquemas comuns e específicos de serviço para registos de recursos Azure.

Todos os serviços Azure eventualmente utilizam o modo específico de recursos. Como parte desta transição, alguns recursos permitem-lhe selecionar um modo na definição de diagnóstico. Especifique o modo específico de recursos para quaisquer novas definições de diagnóstico, pois este modo facilita a gestão dos dados. Também pode ajudá-lo a evitar migrações complexas mais tarde.

Screenshot que mostra o seletor do modo de definição de diagnóstico.

Nota

Para um exemplo que define o modo de recolha utilizando um modelo de Resource Manager Azure, consulte Resource Manager amostras de modelo para configurações de diagnóstico no Azure Monitor.

Pode modificar uma definição de diagnóstico existente para o modo específico de recursos. Neste caso, os dados que já foram recolhidos permanecem na AzureDiagnostics tabela até que sejam removidos de acordo com a sua definição de retenção para o espaço de trabalho. Novos dados são recolhidos na tabela dedicada. Utilize o operador sindical para consultar dados em ambas as tabelas.

Continue a ver o blog Azure Atualizações para anúncios sobre os serviços Azure que suportam o modo específico de recursos.

Enviar para Hubs de Eventos do Azure

Envie registos de recursos para um centro de eventos para enviá-los para fora de Azure. Por exemplo, os registos de recursos podem ser enviados para um SIEM de terceiros ou outras soluções de análise de registo. Os registos de recursos dos centros de eventos são consumidos no formato JSON com um records elemento que contém os registos em cada carga útil. O esquema depende do tipo de recurso descrito no esquema comum e específico de serviço para registos de recursos Azure.

Os seguintes dados de saída de amostra são de Hubs de Eventos do Azure para um registo de recursos:

{
    "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"
                }
            }
        }
    ]
}

Enviar para o Armazenamento do Azure

Envie registos de recursos para o Azure Storage para retê-los para arquivar. Depois de ter criado a definição de diagnóstico, um recipiente de armazenamento é criado na conta de armazenamento assim que ocorre um evento numa das categorias de registo ativado.

Nota

Uma estratégia alternativa para arquivar é enviar o registo de recursos para um espaço de trabalho Log Analytics com uma política de arquivo.

As bolhas dentro do recipiente utilizam a seguinte convenção de nomeação:

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

A bolha para um grupo de segurança de rede pode ter um nome semelhante a este exemplo:

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

Cada blob PT1H.json contém um objeto JSON com eventos de ficheiros de registo que foram recebidos durante a hora especificada no URL blob. Durante a presente hora, os eventos são anexados ao ficheiro PT1H.json à medida que são recebidos, independentemente de quando foram gerados. O valor minúsculo no URL é m=00 sempre 00 como bolhas são criadas por hora.

Dentro do ficheiro PT1H.json, cada evento é armazenado no seguinte formato. Usa um esquema comum de alto nível, mas é único para cada serviço Azure, como descrito no esquema de registos de recursos.

Nota

Os registos são escritos para bolhas com base no tempo em que o registo foi recebido, independentemente do tempo que foi gerado. Isto significa que uma determinada bolha pode conter dados de registo que estão fora da hora especificada no URL do blob. Quando uma fonte de dados como a Aplicação insights, suporta o upload de telemetria velha, uma bolha pode conter dados das 48 horas anteriores.
No início de uma nova hora, é possível que os registos existentes ainda estejam a ser escritos para a bolha da hora anterior, enquanto novos registos são escritos para a bolha da nova hora.

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

Integrações de parceiros do Azure Monitor

Os registos de recursos também podem ser enviados para soluções parceiras que estão totalmente integradas no Azure. Para obter uma lista destas soluções e detalhes sobre como configurá-las, consulte as integrações de parceiros do Azure Monitor.

Passos seguintes