Inviare i dati del log delle risorse di Azure
I log delle risorse di Azure sono log della piattaforma che forniscono informazioni dettagliate sulle operazioni eseguite all'interno di una risorsa di Azure. Il contenuto dei log delle risorse varia in base al servizio di Azure e al tipo di risorsa. I log delle risorse non vengono raccolti per impostazione predefinita. Questo articolo descrive l'impostazione di diagnostica necessaria per ogni risorsa di Azure per inviare i log delle risorse a destinazioni diverse.
Inviare all'area di lavoro Log Analytics
Inviare i log delle risorse a un'area di lavoro Log Analytics per abilitare le funzionalità dei log di Monitoraggio di Azure, in cui è possibile:
- Correlare i dati del log delle risorse con altri dati di monitoraggio raccolti da Monitoraggio di Azure.
- Consolidare le voci di log da più risorse, sottoscrizioni e tenant di Azure in un'unica posizione per l'analisi.
- Usare le query di log per eseguire analisi complesse e ottenere informazioni approfondite sui dati di log.
- Usare gli avvisi di ricerca log con logica di avviso complessa.
Creare un'impostazione di diagnostica per inviare i log delle risorse a un'area di lavoro Log Analytics. Questi dati vengono archiviati in tabelle, come descritto in Struttura dei log di Monitoraggio di Azure. Le tabelle usate dai log delle risorse dipendono dal tipo di raccolta usato dalla risorsa:
- Diagnostica di Azure: tutti i dati vengono scritti nella tabella AzureDiagnostics .
- Specifico della risorsa: i dati sono scritti in singole tabelle per ogni categoria della risorsa.
Specifico della risorsa
In questa modalità vengono create singole tabelle nell'area di lavoro selezionata per ogni categoria selezionata nell'impostazione di diagnostica. È consigliabile usare questo metodo perché:
- Semplifica l'uso dei dati nelle query di log.
- Offre una migliore individuabilità degli schemi e della relativa struttura.
- Migliora le prestazioni tra latenza di inserimento e tempi di query.
- Offre la possibilità di concedere diritti di controllo degli accessi in base al ruolo di Azure in una tabella specifica.
Tutti i servizi di Azure eseguiranno infine la migrazione alla modalità specifica della risorsa.
L'esempio seguente crea tre tabelle:
Tavolo
Service1AuditLogsProvider di risorse Categoria Un B A Servizio 1 AuditLogs x1 y1 Z1 Servizio 1 AuditLogs x5 y5 z5 ... Tavolo
Service1ErrorLogsProvider di risorse Categoria D E F Servizio 1 ErrorLogs q1 w1 e1 Servizio 1 ErrorLogs q2 w2 e2 ... Tavolo
Service2AuditLogsProvider di risorse Categoria G H I Servizio 2 AuditLogs j1 k1 l1 Servizio 2 AuditLogs j3 k3 l3 ...
Modalità diagnostica di Azure
In questa modalità, tutti i dati di qualsiasi impostazione di diagnostica vengono raccolti nella tabella AzureDiagnostics . Questo metodo legacy viene attualmente usato dalla maggior parte dei servizi di Azure. Poiché più tipi di risorse inviano dati alla stessa tabella, lo schema è il superset degli schemi di tutti i diversi tipi di dati raccolti. Per informazioni dettagliate sulla struttura di questa tabella e sul relativo funzionamento con questo numero potenzialmente elevato di colonne, vedere Informazioni di riferimento su AzureDiagnostics.
Si consideri un esempio in cui le impostazioni di diagnostica vengono raccolte nella stessa area di lavoro per i tipi di dati seguenti:
- I log di controllo del servizio 1 hanno uno schema costituito da colonne A, B e C
- I log degli errori del servizio 1 hanno uno schema costituito da colonne D, E e F
- I log di controllo del servizio 2 hanno uno schema costituito da colonne G, H e I
La tabella è simile all'esempio AzureDiagnostics seguente:
| ResourceProvider | Categoria | Un | 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 | ||||||
| ... |
Selezionare la modalità raccolta
La maggior parte delle risorse di Azure scrive i dati nell'area di lavoro in modalità diagnostica di Azure o specifica della risorsa senza scegliere. Per altre informazioni, vedere Schemi comuni e specifici del servizio per i log delle risorse di Azure.
Tutti i servizi di Azure useranno infine la modalità specifica della risorsa. Come parte di questa transizione, alcune risorse consentono di selezionare una modalità nell'impostazione di diagnostica. Specificare la modalità specifica della risorsa per le nuove impostazioni di diagnostica perché questa modalità semplifica la gestione dei dati. Può anche essere utile evitare migrazioni complesse in un secondo momento.
Nota
Per un esempio che imposta la modalità raccolta usando un modello di Azure Resource Manager, vedere Esempi di modelli di Resource Manager per le impostazioni di diagnostica in Monitoraggio di Azure.
È possibile modificare un'impostazione di diagnostica esistente in modalità specifica della risorsa. In questo caso, i dati già raccolti rimangono nella AzureDiagnostics tabella fino a quando non vengono rimossi in base all'impostazione di conservazione per l'area di lavoro. I nuovi dati vengono raccolti nella tabella dedicata. Usare l'operatore union per eseguire query sui dati in entrambe le tabelle.
Continuare a guardare il blog di Azure Aggiornamenti per gli annunci sui servizi di Azure che supportano la modalità specifica delle risorse.
Inviare all'Hub eventi di Azure
Inviare i log delle risorse a un hub eventi per inviarli all'esterno di Azure. Ad esempio, i log delle risorse potrebbero essere inviati a una soluzione SIEM di terze parti o ad altre soluzioni di log analytics. I log delle risorse dagli hub eventi vengono utilizzati in formato JSON con un records elemento che contiene i record in ogni payload. Lo schema dipende dal tipo di risorsa, come descritto in Schema comune e specifico del servizio per i log delle risorse di Azure.
I dati di output di esempio seguenti provengono da Hub eventi di Azure per un log delle risorse:
{
"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"
}
}
}
]
}
Inviare ad Archiviazione di Azure
Inviare i log delle risorse a Archiviazione di Azure per conservarli per l'archiviazione. Dopo aver creato l'impostazione di diagnostica, viene creato un contenitore di archiviazione nell'account di archiviazione non appena si verifica un evento in una delle categorie di log abilitate.
Nota
Una strategia alternativa per l'archiviazione consiste nell'inviare il log delle risorse a un'area di lavoro Log Analytics con criteri di archiviazione.
I BLOB all'interno del contenitore usano la convenzione di denominazione seguente:
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
Il BLOB per un gruppo di sicurezza di rete potrebbe avere un nome simile a questo esempio:
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
Ogni PT1H.JSON BLOB contiene un oggetto JSON con eventi dei file di log ricevuti durante l'ora specificata nell'URL del BLOB. Durante l'ora corrente, gli eventi vengono aggiunti al file di PT1H.json durante la ricezione, indipendentemente dal momento in cui sono stati generati. Il valore del minuto nell'URL m=00 è sempre 00 quando i BLOB vengono creati su base oraria.
All'interno del file PT1H.json, ogni evento viene archiviato nel formato seguente. Usa uno schema di primo livello comune, ma è univoco per ogni servizio di Azure, come descritto in Schema dei log delle risorse.
Nota
I log vengono scritti nei BLOB in base al momento in cui il log è stato ricevuto, indipendentemente dal momento in cui è stato generato. Ciò significa che un determinato BLOB può contenere dati di log esterni all'ora specificata nell'URL del BLOB. Se un'origine dati come Application Insights supporta il caricamento di dati di telemetria non aggiornati, un BLOB può contenere dati delle 48 ore precedenti.
All'inizio di una nuova ora, è possibile che i log esistenti vengano ancora scritti nel BLOB dell'ora precedente mentre i nuovi log vengono scritti nel BLOB della nuova ora.
{"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}}
Integrazioni partner del monitoraggio di Azure
I log delle risorse possono anche essere inviati alle soluzioni partner completamente integrate in Azure. Per un elenco di queste soluzioni e informazioni dettagliate su come configurarle, vedere Integrazioni dei partner di Monitoraggio di Azure.