Condividi tramite


Esempi di regole di raccolta dati in Monitoraggio di Azure

Questo articolo include regole di raccolta dati di esempio per scenari comuni di raccolta dati in Monitoraggio di Azure. È possibile modificare queste definizioni DCR in base alle esigenze per l'ambiente e creare il Registro Azure Container usando le indicazioni riportate in Creare o modificare una regola di raccolta dati. È anche possibile usare e combinare le strategie di base in questi esempi per creare controller di dominio per altri scenari.

Questi esempi richiedono una conoscenza della struttura DCR come descritto in Struttura di una regola di raccolta dati in Monitoraggio di Azure. È possibile configurare diversi elementi usando l'portale di Azure senza alcuna conoscenza dettagliata della struttura DCR. Usare questi esempi quando è necessario usare la definizione DCR stessa per eseguire configurazioni più avanzate o per automatizzare la creazione di controller di dominio.

Ognuno di questi esempi è incentrato su una particolare origine dati, anche se è possibile combinare più origini dati di tipi diversi in un singolo DCR. Includere un flusso di dati per ognuno per inviare i dati alla destinazione appropriata. Non esiste alcuna differenza funzionale tra la combinazione di più origini dati in un singolo DCR o la creazione di controller di dominio separati per ogni origine dati. La scelta dipende dai requisiti per la gestione e il monitoraggio della raccolta dati.

Nota

Questi esempi illustrati in questo articolo forniscono il codice JSON di origine necessario per creare il record di controllo di dominio. Dopo la creazione, la regola di raccolta dati avrà proprietà aggiuntive, come descritto in Struttura di una regola di raccolta dati in Monitoraggio di Azure.

Controller di dominio per l'agente di Monitoraggio di Azure

L'agente di Monitoraggio di Azure viene eseguito in macchine virtuali, set di scalabilità di macchine virtuali e cluster Kubernetes. Supporta informazioni dettagliate sulle macchine virtuali e informazioni dettagliate sui contenitori e supporta diversi scenari di raccolta dati per le macchine virtuali descritte nella raccolta dati dell'agente di Monitoraggio di Azure.

Gli esempi seguenti illustrano i controller di dominio per la raccolta di diversi tipi di dati usando l'agente di Monitoraggio di Azure.

Eventi Windows

I controller di dominio per gli eventi di Windows usano l'origine windowsEventLogs dati con il Microsoft-Event flusso in ingresso. Lo schema di questo flusso è noto, quindi non deve essere definito nella dataSources sezione . Gli eventi da raccogliere vengono specificati nella xPathQueries proprietà . Per altri dettagli sull'uso di XPaths per filtrare i dati specifici da raccogliere, vedere Raccogliere eventi di Windows con l'agente di Monitoraggio di Azure. Per iniziare, è possibile usare le linee guida contenute in questo articolo per creare un record di dominio usando il portale di Azure e quindi esaminare il codice JSON usando le linee guida riportate nella definizione del Registro Azure Container.

È possibile aggiungere una trasformazione alla dataFlows proprietà per le colonne calcolate e per filtrare ulteriormente i dati, ma è consigliabile usare XPath per filtrare i dati nell'agente il più possibile per l'efficienza ed evitare potenziali addebiti per l'inserimento.

Il DCR di esempio seguente esegue le azioni seguenti:

  • Raccoglie gli eventi di sistema e dell'applicazione Windows con livello di errore Avviso, Errore o Critico.
  • Invia i dati alla tabella Event nell'area di lavoro.
  • Usa una semplice trasformazione di un oggetto source che non apporta alcuna modifica ai dati in ingresso.
{
    "location": "eastus",
    "properties": {
      "dataSources": {
        "windowsEventLogs": [
          {
            "name": "eventLogsDataSource",
            "streams": [
              "Microsoft-Event"
            ],
            "xPathQueries": [
              "System!*[System[(Level = 1 or Level = 2 or Level = 3)]]",
              "Application!*[System[(Level = 1 or Level = 2 or Level = 3)]]"
            ]
          }
        ]
    },
      "destinations": {
        "logAnalytics": [
          {
            "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
            "name": "centralWorkspace"
          }
        ]
      },
      "dataFlows": [
        {
          "streams": [
            "Microsoft-Event"
          ],
          "destinations": [
            "centralWorkspace"
          ],
            "transformKql": "source",
            "outputStream": "Microsoft-Event"
        }
      ]
    }
  }

Eventi SysLog

I controller di dominio per gli eventi Syslog usano l'origine syslog dati con il flusso in ingresso Microsoft-Syslog . Lo schema di questo flusso è noto, quindi non deve essere definito nella dataSources sezione . Gli eventi da raccogliere vengono specificati nelle facilityNames proprietà e logLevels . Per altri dettagli, vedere Raccogliere eventi Syslog con l'agente di Monitoraggio di Azure. Per iniziare, è possibile usare le linee guida contenute in questo articolo per creare un record di dominio usando il portale di Azure e quindi esaminare il codice JSON usando le linee guida riportate nella definizione del Registro Azure Container.

È possibile aggiungere una trasformazione alla dataFlows proprietà per funzionalità aggiuntive e per filtrare ulteriormente i dati, ma è consigliabile usare facilityNames e logLevels per filtrare il più possibile in modo da evitare potenziali addebiti per l'inserimento.

Il DCR di esempio seguente esegue le azioni seguenti:

  • Raccoglie tutti gli eventi dalla cron struttura.
  • Warning Raccoglie e più eventi da syslog e daemon strutture.
    • Invia dati alla tabella Syslog nell'area di lavoro.
    • Usa una semplice trasformazione di un oggetto source che non apporta alcuna modifica ai dati in ingresso.
{
    "location": "eastus",
    "properties": {
      "dataSources": {
        "syslog": [
          {
            "name": "cronSyslog",
            "streams": [
              "Microsoft-Syslog"
            ],
            "facilityNames": [
              "cron"
            ],
            "logLevels": [
              "Debug",
              "Info",
              "Notice",
              "Warning",
              "Error",
              "Critical",
              "Alert",
              "Emergency"
            ]
          },
          {
            "name": "syslogBase",
            "streams": [
              "Microsoft-Syslog"
            ],
            "facilityNames": [
              "daemon",              
              "syslog"
            ],
            "logLevels": [
              "Warning",
              "Error",
              "Critical",
              "Alert",
              "Emergency"           
            ]
          }
        ]
      },
      "destinations": {
        "logAnalytics": [
          {
            "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
            "name": "centralWorkspace"
          }
        ]
      },
      "dataFlows": [
        {
          "streams": [
            "Microsoft-Syslog"
          ],
          "destinations": [
            "centralWorkspace"
          ],
            "transformKql": "source",
            "outputStream": "Microsoft-Syslog"
        }
      ]
    }
  }

Contatori delle prestazioni

I controller di dominio per i dati sulle prestazioni usano l'origine performanceCounters dati con i flussi e Microsoft-Perf in ingressoMicrosoft-InsightsMetrics. Microsoft-InsightsMetrics viene usato per inviare dati alle metriche di Monitoraggio di Azure, mentre Microsoft-Perf viene usato per inviare dati a un'area di lavoro Log Analytics. È possibile includere entrambe le origini dati nel Registro Azure Container se si inviano dati sulle prestazioni a entrambe le destinazioni. Gli schemi di questi flussi sono noti, quindi non devono essere definiti nella dataSources sezione .

I contatori delle prestazioni da raccogliere vengono specificati nella counterSpecifiers proprietà . Per altri dettagli, vedere Raccogliere contatori delle prestazioni con l'agente di Monitoraggio di Azure. Per iniziare, è possibile usare le linee guida contenute in questo articolo per creare un record di dominio usando il portale di Azure e quindi esaminare il codice JSON usando le linee guida riportate nella definizione del Registro Azure Container.

È possibile aggiungere una trasformazione alla dataFlows proprietà per Microsoft-Perf altre funzionalità e per filtrare ulteriormente i dati, ma è consigliabile selezionare solo i contatori necessari per counterSpecifiers garantire l'efficienza in per evitare potenziali addebiti per l'inserimento.

Il DCR di esempio seguente esegue le azioni seguenti:

  • Raccoglie un set di contatori delle prestazioni ogni 60 secondi e un altro set ogni 30 secondi.
  • Invia dati alle metriche di Monitoraggio di Azure e a un'area di lavoro Log Analytics.
  • Usa una semplice trasformazione di un oggetto source che non apporta alcuna modifica ai dati in ingresso.
{
    "location": "eastus",
    "properties": {
      "dataSources": {
        "performanceCounters": [
          {
            "name": "perfCounterDataSource60",
            "streams": [
              "Microsoft-Perf",
              "Microsoft-InsightsMetrics"
            ],
            "samplingFrequencyInSeconds": 60,
            "counterSpecifiers": [
              "\\Processor(_Total)\\% Processor Time",
              "\\Memory\\Committed Bytes",
              "\\LogicalDisk(_Total)\\Free Megabytes",
              "\\PhysicalDisk(_Total)\\Avg. Disk Queue Length"
            ]
          },
          {
            "name": "perfCounterDataSource30",
            "streams": [
              "Microsoft-Perf"
            ],
            "samplingFrequencyInSeconds": 30,
            "counterSpecifiers": [
              "\\Process(_Total)\\Thread Count"
            ]
          }
        ]
      },
      "destinations": {
        "logAnalytics": [
          {
            "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
            "name": "centralWorkspace"
          }
        ],
        "azureMonitorMetrics": 
        {
            "name": "azureMonitorMetrics-default"
        }
      },
      "dataFlows": [
        {
            "streams": [
                "Microsoft-Perf"
            ],
            "destinations": [
                "centralWorkspace"
            ],
            "transformKql": "source",
            "outputStream": "Microsoft-Perf"
        },
        {
            "streams": [
                "Microsoft-Perf"
            ],
            "destinations": [
                "azureMonitorMetrics-default"
            ],
            "outputStream": "Microsoft-InsightsMetrics"
        }
      ]
    }
}

Log di testo

I controller di dominio per i log di testo hanno un'origine logfiles dati con i dettagli per i file di log che devono essere raccolti dall'agente. Questo include il nome di un flusso che deve essere definito in streamDeclarations con le colonne dei dati in ingresso. Questo è attualmente un elenco di set come descritto in Raccogliere i log da un file di testo con l'agente di Monitoraggio di Azure.

Aggiungere una trasformazione alla dataFlows proprietà per filtrare i record che non si desidera raccogliere e formattare i dati in modo che corrispondano allo schema della tabella di destinazione. Uno scenario comune consiste nell'analizzare un file di log delimitato in più colonne, come descritto in File di log delimitati.

Il DCR di esempio seguente esegue le azioni seguenti:

  • Raccoglie le voci da tutti i file con estensione di .txt nella c:\logs cartella del computer agente.
  • Usa una trasformazione per suddividere i dati in ingresso in colonne in base a un delimitatore virgola (,). Questa trasformazione è specifica del formato del file di log e deve essere modificata per i file di log con altri formati.
  • Invia i log raccolti a una tabella personalizzata denominata MyTable_CL. Questa tabella deve esistere già e avere l'output delle colonne dalla trasformazione .
  • Raccoglie e per il FilePath log di testo come descritto in Flusso in ingresso.Computer Queste colonne devono esistere anche nella tabella di destinazione.
{
    "location": "eastus",
    "properties": {
        "dataCollectionEndpointId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.Insights/dataCollectionEndpoints/my-dce",
        "streamDeclarations": {
            "Custom-MyLogFileFormat": {
                "columns": [
                    {
                        "name": "TimeGenerated",
                        "type": "datetime"
                    },
                    {
                        "name": "RawData",
                        "type": "string"
                    },
                    {
                        "name": "FilePath",
                        "type": "string"
                    },
                    {
                        "name": "Computer",
                        "type": "string"
                    }
                ]
            }
        },
        "dataSources": {
            "logFiles": [
                {
                    "streams": [
                        "Custom-MyLogFileFormat"
                    ],
                    "filePatterns": [
                        "C:\\logs\\*.txt"
                    ],
                    "format": "text",
                    "settings": {
                        "text": {
                            "recordStartTimestampFormat": "ISO 8601"
                        }
                    },
                    "name": "myLogFileFormat-Windows"
                }
            ]
        },
        "destinations": {
            "logAnalytics": [
                {
                    "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
                    "name": "MyDestination"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                    "Custom-MyLogFileFormat"
                ],
                "destinations": [
                    "MyDestination"
                ],
                "transformKql": "source | project d = split(RawData,\",\") | project TimeGenerated=todatetime(d[0]), Code=toint(d[1]), Severity=tostring(d[2]), Module=tostring(d[3]), Message=tostring(d[4])",
                "outputStream": "Custom-MyTable_CL"
            }
        ]
    }
}

Log JSON

I controller di dominio per i log JSON hanno un'origine logfiles dati con i dettagli per i file di log che devono essere raccolti dall'agente. Questo include il nome di un flusso che deve essere definito in streamDeclarations con le colonne dei dati in ingresso. Per altri dettagli, vedere Raccogliere log da un file JSON con l'agente di Monitoraggio di Azure.

Aggiungere una trasformazione alla dataFlows proprietà per filtrare i record che non si desidera raccogliere e formattare i dati in modo che corrispondano allo schema della tabella di destinazione.

Il DCR di esempio seguente esegue le azioni seguenti:

  • Raccoglie le voci da tutti i file con estensione di .json nella c:\logs cartella del computer agente. Il file deve essere formattato in json e avere le colonne elencate nella dichiarazione del flusso.
  • Invia i log raccolti a una tabella personalizzata denominata MyTable_CL. Questa tabella deve esistere già e avere le stesse colonne del flusso in ingresso. Se le colonne non corrispondono, è necessario modificare la trasformazione nella transformKql proprietà per formattare i dati per la tabella di destinazione.
{
    "location": "eastus",
    "properties": {
        "dataCollectionEndpointId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.Insights/dataCollectionEndpoints/my-dce",
        "streamDeclarations": {
            "Custom-Json-stream": {
                "columns": [
                    {
                        "name": "TimeGenerated",
                        "type": "datetime"
                    },
                    {
                        "name": "FilePath",
                        "type": "string"
                    },
                    {
                        "name": "Code",
                        "type": "int"
                    },
                    {
                        "name": "Module",
                        "type": "string"
                    },
                    {
                        "name": "Message",
                        "type": "string"
                    }
                ]
            }
        },
        "dataSources": {
            "logFiles": [
                {
                    "streams": [
                        "Custom-Json-stream"
                    ],
                    "filePatterns": [
                        "C:\\logs\\*.json"
                    ],
                    "format": "json",
                    "name": "MyJsonFile"
                }
            ]
        },
        "destinations": {
            "logAnalytics": [
                {
                    "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
                    "name": "MyDestination"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                    "Custom-Json-stream"
                ],
                "destinations": [
                    "MyDestination"
                ],
                "transformKql": "source",
                "outputStream": "Custom-MyTable_CL"
            }
        ]
    }
}

Inviare dati a Hub eventi o archiviazione

I controller di dominio che inviano dati agli hub eventi o agli account di archiviazione usano le stesse origini dati di altri controller di dominio che raccolgono dati con l'agente di Monitoraggio di Azure, ma hanno una o più delle destinazioni seguenti. Per altri dettagli, vedere Inviare dati a Hub eventi e archiviazione (anteprima).

  • eventHubsDirect
  • storageBlobsDirect
  • storageTablesDirect

Nota

I controller di dominio che inviano dati agli hub eventi o agli account di archiviazione devono avere "kind": "AgentDirectToStore"

Il DCR di esempio seguente esegue le azioni seguenti:

  • Raccoglie i contatori delle prestazioni e gli eventi di Windows dai computer Windows con l'agente di Monitoraggio di Azure .
  • Invia i dati all'hub eventi, all'archiviazione BLOB e all'archiviazione tabelle.
{
    "location": "eastus",
    "kind": "AgentDirectToStore",
    "properties": {
        "dataSources": {
            "performanceCounters": [
                {
                "streams": [
                    "Microsoft-Perf"
                ],
                "samplingFrequencyInSeconds": 10,
                "counterSpecifiers": [
                    "\\Process(_Total)\\Working Set - Private",
                    "\\Memory\\% Committed Bytes In Use",
                    "\\LogicalDisk(_Total)\\% Free Space",
                    "\\Network Interface(*)\\Bytes Total/sec"
                ],
                "name": "perfCounterDataSource"
                }
            ],
            "windowsEventLogs": [
                {
                "streams": [
                    "Microsoft-Event"
                ],
                "xPathQueries": [
                    "Application!*[System[(Level=2)]]",
                    "System!*[System[(Level=2)]]"
                ],
                "name": "eventLogsDataSource"
                }
            ]
        },
        "destinations": {
            "eventHubsDirect": [
                {
                "eventHubResourceId": "/subscriptions/71b36fb6-4fe4-4664-9a7b-245dc62f2930/resourceGroups/my-resource-group/providers/Microsoft.EventHub/namespaces/my-eventhub-namespace/eventhubs/my-eventhub",
                "name": "myEh"
                }
            ],
            "storageBlobsDirect": [
                {
                "storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
                "containerName": "myperfblob",
                "name": "PerfBlob"
                },
                {
                "storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
                "containerName": "myeventblob",
                "name": "EventBlob"
                }
            ],
            "storageTablesDirect": [
                {
                "storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
                "containerName": "myperftable",
                "name": "PerfTable"
                },
                {
                "storageAccountResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.Storage/storageAccounts/mystorageaccount",
                "containerName": "mymyeventtable",
                "name": "EventTable"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                "Microsoft-Perf"
                ],
                "destinations": [
                "myEh",
                "PerfBlob",
                "PerfTable"
                ]
            },
            {
                "streams": [
                "Microsoft-Event"
                ],
                "destinations": [
                "myEh",
                "EventBlob",
                "EventTable"
                ]
            },
        ]
    }
}

API di inserimento dei log

I controller di dominio per l'API di inserimento dei log devono definire lo schema del flusso in ingresso nella streamDeclarations sezione della definizione DCR. I dati in ingresso devono essere formattati in JSON con uno schema corrispondente alle colonne in questa definizione. Non è necessaria alcuna trasformazione se questo schema corrisponde allo schema della tabella di destinazione. Se gli schemi non corrispondono, è necessario aggiungere una trasformazione alla dataFlows proprietà per formattare i dati. Per altri dettagli, vedere l'API di inserimento dei log in Monitoraggio di Azure.

Il DCR di esempio seguente contiene i dettagli seguenti:

  • Invia dati a una tabella denominata MyTable_CL in un'area di lavoro denominata my-workspace. Prima di installare questo DCR, è necessario creare la tabella con le colonne seguenti:
    • TimeGenerated
    • Computer
    • AdditionalContext
    • ExtendedColumn (definito nella trasformazione)
  • Applica una trasformazione ai dati in ingresso per formattare i dati per la tabella di destinazione.

Importante

Questo esempio non include la dataCollectionEndpointId proprietà perché viene creata automaticamente al momento della creazione del record di dominio. È necessario il valore di questa proprietà perché si tratta dell'URL a cui l'applicazione invierà i dati. Per creare questa proprietà, è necessario che kind:Direct il record di controllo di dominio sia necessario. Per altri dettagli, vedere Proprietà .

{
    "location": "eastus",
    "kind": "Direct",
    "properties": {
        "streamDeclarations": {
            "Custom-MyTable": {
                "columns": [
                    {
                        "name": "Time",
                        "type": "datetime"
                    },
                    {
                        "name": "Computer",
                        "type": "string"
                    },
                    {
                        "name": "AdditionalContext",
                        "type": "string"
                    }
                ]
            }
        },
        "destinations": {
            "logAnalytics": [
                {
                    "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/cefingestion/providers/microsoft.operationalinsights/workspaces/my-workspace",
                    "name": "LogAnalyticsDest"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                    "Custom-MyTable"
                ],
                "destinations": [
                    "LogAnalyticsDest"
                ],
                "transformKql": "source | extend jsonContext = parse_json(AdditionalContext) | project TimeGenerated = Time, Computer, AdditionalContext = jsonContext, ExtendedColumn=tostring(jsonContext.CounterName)",
                "outputStream": "Custom-MyTable_CL"
            }
        ]
    }
}

Regole di raccolta dati per la trasformazione dell'area di lavoro

I controller di dominio di trasformazione dell'area di lavoro hanno una sezione vuota datasources perché le trasformazioni vengono applicate a tutti i dati inviati alle tabelle supportate nell'area di lavoro. Deve includere una voce e solo per workspaceResourceId e una voce in dataFlows per ogni tabella con una trasformazione. Deve anche avere "kind": "WorkspaceTransforms".

Il DCR di esempio seguente contiene i dettagli seguenti:

  • Trasformazione per la LAQueryLogs tabella che filtra le query della tabella stessa e aggiunge una colonna con il nome dell'area di lavoro.
  • Trasformazione per la Event tabella che filtra gli eventi Di informazioni e rimuove la ParameterXml colonna. Questo vale solo per i dati provenienti dall'agente di Log Analytics deprecato e non dall'agente di Monitoraggio di Azure, come illustrato in DCR trasformazione Area di lavoro.
{
    "kind": "WorkspaceTransforms",
    "location": "eastus",
    "properties": {
        "dataSources": {},
        "destinations": {
            "logAnalytics": [
                {
                    "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
                    "name": "clv2ws1"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                    "Microsoft-Table-LAQueryLogs"
                ],
                "destinations": [
                    "clv2ws1"
                ],
                "transformKql": "source | where QueryText !contains 'LAQueryLogs' | extend Context = parse_json(RequestContext) | extend Workspace_CF = tostring(Context['workspaces'][0]) | project-away RequestContext, Context"
            },
            {
                "streams": [
                    "Microsoft-Table-Event"
                ],
                "destinations": [
                    "clv2ws1"
                ],
                "transformKql": "source | where EventLevelName in ('Error', 'Critical', 'Warning') | project-away ParameterXml"
            }
        ]
    }
}

Inviare dati a più tabelle

Esistono diversi motivi per cui è consigliabile inviare dati da una singola origine dati a più tabelle nella stessa area di lavoro Log Analytics, tra cui:

  • Risparmiare sui costi di inserimento inviando record usati per la risoluzione dei problemi occasionali in una tabella dei log di base.
  • Inviare record o colonne con dati sensibili a una tabella con autorizzazioni o impostazioni di conservazione diverse.

Per inviare dati da una singola origine dati a più tabelle, creare più flussi di dati nel Registro Azure Container con una query di trasformazione e una tabella di output univoca per ognuna, come illustrato nel diagramma seguente.

Importante

Attualmente, le tabelle nel Registro Azure Container devono trovarsi nella stessa area di lavoro Log Analytics. Per inviare a più aree di lavoro da una singola origine dati, usare più controller di dominio e configurare l'applicazione per inviare i dati a ognuno.

Diagramma che mostra la trasformazione che invia dati a più tabelle.

L'esempio seguente filtra i record inviati alla tabella eventi dall'agente di Monitoraggio di Azure. Solo gli eventi di avviso e di errore vengono inviati alla tabella Event. Altri eventi vengono inviati a una copia della tabella eventi denominata Event_CL configurata per i log di base.

Nota

Questo esempio richiede una copia della tabella Event creata nella stessa area di lavoro denominata Event_CL.

{
    "location": "eastus",
    "properties": {
        "dataSources": {
            "windowsEventLogs": [
              {
                "name": "eventLogsDataSource",
                "streams": [
                  "Microsoft-Event"
                ],
                "xPathQueries": [
                  "System!*[System[(Level = 1 or Level = 2 or Level = 3)]]",
                  "Application!*[System[(Level = 1 or Level = 2 or Level = 3)]]"
                ]
              }
            ]
        },
        "destinations": {
            "logAnalytics": [
                {
                    "workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
                    "name": "MyDestination"
                }
            ]
        },
        "dataFlows": [
            {
                "streams": [
                    "Microsoft-Event"
                ],
                "destinations": [
                    "MyDestination"
                ],
                "transformKql": "source | where EventLevelName in ('Error', 'Warning')",
                "outputStream": "Microsoft-Event"
            },
            {
                "streams": [
                    "Microsoft-Event"
                ],
                "destinations": [
                    "MyDestination"
                ],
                "transformKql": "source | where EventLevelName !in ('Error', 'Warning')",
                "outputStream": "Custom-Event_CL"
            }
        ]
    }
}

Passaggi successivi