Skicka Azure-resursloggdata

  • Artikel

Azure-resursloggar är plattformsloggar som ger insikter om åtgärder som har utförts i en Azure-resurs. Innehållet i resursloggarna varierar beroende på Azure-tjänst och resurstyp. Resursloggar samlas inte in som standard. I den här artikeln beskrivs diagnostikinställningen som krävs för att varje Azure-resurs ska kunna skicka sina resursloggar till olika mål.

Skicka till Log Analytics-arbetsytan

Skicka resursloggar till en Log Analytics-arbetsyta för att aktivera funktionerna i Azure Monitor-loggar, där du kan:

  • Korrelera resursloggdata med andra övervakningsdata som samlas in av Azure Monitor.
  • Konsolidera loggposter från flera Azure-resurser, prenumerationer och klientorganisationer till en plats för analys tillsammans.
  • Använd loggfrågor för att utföra komplex analys och få djupgående insikter om loggdata.
  • Använd loggsökningsaviseringar med komplex aviseringslogik.

Skapa en diagnostikinställning för att skicka resursloggar till en Log Analytics-arbetsyta. Dessa data lagras i tabeller enligt beskrivningen i Struktur för Azure Monitor-loggar. Vilka tabeller som används av resursloggar beror på vilken typ av samling resursen använder:

  • Azure-diagnostik: Alla data skrivs till AzureDiagnostics-tabellen.
  • Resursspecifik: Data skrivs till enskilda tabeller för varje kategori av resursen.

Resursspecifik

I det här läget skapas enskilda tabeller i den valda arbetsytan för varje kategori som valts i diagnostikinställningen. Vi rekommenderar den här metoden eftersom den:

  • Gör det enklare att arbeta med data i loggfrågor.
  • Ger bättre identifiering av scheman och deras struktur.
  • Förbättrar prestanda mellan svarstider för inmatning och frågetider.
  • Ger möjlighet att bevilja rollbaserad åtkomstkontroll i Azure i en specifik tabell.

Alla Azure-tjänster migreras så småningom till resursspecifikt läge.

I exemplet nedan skapas tre tabeller:

  • Tabell Service1AuditLogs

    Resursprovider Kategori A B C
    Tjänst 1 AuditLogs x1 y1 Z1
    Tjänst 1 AuditLogs x5 y5 z5
    ...

  • Tabell Service1ErrorLogs

    Resursprovider Kategori D E F
    Tjänst 1 ErrorLogs f1 w1 e1
    Tjänst 1 ErrorLogs q2 w2 e2
    ...

  • Tabell Service2AuditLogs

    Resursprovider Kategori G H I
    Tjänst 2 AuditLogs j1 k1 l1
    Tjänst 2 AuditLogs j3 k3 l3
    ...

Azure-diagnostikläge

I det här läget samlas alla data från alla diagnostikinställningar in i tabellen AzureDiagnostics . Den här äldre metoden används idag av de flesta Azure-tjänster. Eftersom flera resurstyper skickar data till samma tabell är schemat superuppsättningen av scheman för alla olika datatyper som samlas in. Mer information om strukturen i den här tabellen och hur den fungerar med det här potentiellt stora antalet kolumner finns i Referens för AzureDiagnostics.

Tänk dig ett exempel där diagnostikinställningar samlas in på samma arbetsyta för följande datatyper:

  • Granskningsloggar för tjänst 1 har ett schema som består av kolumnerna A, B och C
  • Felloggar för tjänst 1 har ett schema som består av kolumnerna D, E och F
  • Granskningsloggar för tjänst 2 har ett schema som består av kolumnerna G, H och I

Tabellen AzureDiagnostics ser ut så här:

ResourceProvider Kategori A B C D E F G H I
Microsoft.Service1 AuditLogs x1 y1 Z1
Microsoft.Service1 ErrorLogs f1 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
...

Välj samlingsläge

De flesta Azure-resurser skriver data till arbetsytan i antingen Azure-diagnostik eller resursspecifikt läge utan att ge dig något val. Mer information finns i Vanliga och tjänstspecifika scheman för Azure-resursloggar.

Alla Azure-tjänster kommer så småningom att använda det resursspecifika läget. Som en del av den här övergången kan du med vissa resurser välja ett läge i diagnostikinställningen. Ange resursspecifikt läge för nya diagnostikinställningar eftersom det här läget gör data enklare att hantera. Det kan också hjälpa dig att undvika komplexa migreringar senare.

Screenshot that shows the Diagnostics settings mode selector.

Kommentar

Ett exempel som anger samlingsläget med hjälp av en Azure Resource Manager-mall finns i Resource Manager-mallexempel för diagnostikinställningar i Azure Monitor.

Du kan ändra en befintlig diagnostikinställning till resursspecifikt läge. I det här fallet finns data som redan samlats in kvar i AzureDiagnostics tabellen tills de tas bort enligt kvarhållningsinställningen för arbetsytan. Nya data samlas in i den dedikerade tabellen. Använd union-operatorn för att fråga efter data i båda tabellerna.

Fortsätt att titta på Azure Uppdateringar-bloggen för meddelanden om Azure-tjänster som stöder resursspecifikt läge.

Skicka till Azure Event Hubs

Skicka resursloggar till en händelsehubb för att skicka dem utanför Azure. Resursloggar kan till exempel skickas till en SIEM från tredje part eller andra log analytics-lösningar. Resursloggar från händelsehubbar används i JSON-format med ett records element som innehåller posterna i varje nyttolast. Schemat beror på resurstypen enligt beskrivningen i Vanliga och tjänstspecifika scheman för Azure-resursloggar.

Följande exempeldata kommer från Azure Event Hubs för en resurslogg:

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

Skicka till Azure Storage

Skicka resursloggar till Azure Storage för att behålla dem för arkivering. När du har skapat diagnostikinställningen skapas en lagringscontainer i lagringskontot så snart en händelse inträffar i någon av de aktiverade loggkategorierna.

Kommentar

En alternativ strategi för arkivering är att skicka resursloggen till en Log Analytics-arbetsyta med en arkivprincip.

Blobarna i containern använder följande namngivningskonvention:

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

Blobben för en nätverkssäkerhetsgrupp kan ha ett namn som liknar det här exemplet:

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

Varje PT1H.json blob innehåller ett JSON-objekt med händelser från loggfiler som togs emot under den timme som anges i blob-URL:en. Under den här timmen läggs händelser till i PT1H.json-filen när de tas emot, oavsett när de genererades. Minutvärdet i URL:en m=00 är alltid 00 som blobar skapas per timme.

I filen PT1H.json lagras varje händelse i följande format. Den använder ett vanligt schema på den översta nivån men är unikt för varje Azure-tjänst, enligt beskrivningen i Schemat för resursloggar.

Kommentar

Loggar skrivs till blobar baserat på den tid då loggen togs emot, oavsett när den genererades. Det innebär att en viss blob kan innehålla loggdata som ligger utanför den timme som anges i blobens URL. Om en datakälla som Application Insights stöder uppladdning av inaktuell telemetri kan en blob innehålla data från de senaste 48 timmarna.
I början av en ny timme är det möjligt att befintliga loggar fortfarande skrivs till föregående timmes blob medan nya loggar skrivs till den nya timmens 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}}

Partnerintegrering i Azure Monitor

Resursloggar kan också skickas till partnerlösningar som är helt integrerade i Azure. En lista över dessa lösningar och information om hur du konfigurerar dem finns i Azure Monitor-partnerintegreringar.

Nästa steg