Creare una query di log in più aree di lavoro e app in Monitoraggio di Azure

I log di Monitoraggio di Azure supportano l'esecuzione di query in più aree di lavoro Log Analytics e applicazioni Insights app nello stesso gruppo di risorse, in un altro gruppo di risorse o in un'altra sottoscrizione. Si ottiene così una vista dei dati dell'intero sistema.

Se si gestiscono le sottoscrizioni in altri tenant di Azure Active Directory (Azure AD) tramite Azure Lighthouse, è possibile includere aree di lavoro Log Analytics create nei tenant dei clienti nelle query.

Esistono due metodi per eseguire query sui dati archiviati in più aree di lavoro e app:

  1. Specificando in modo esplicito i dettagli dell'area di lavoro e dell'app. Questa tecnica è dettagliata in questo articolo.
  2. Uso implicito delle query di contesto delle risorse. Quando si esegue una query nel contesto di una risorsa specifica, un gruppo di risorse o una sottoscrizione, i dati pertinenti verranno recuperati da tutte le aree di lavoro che contengono dati per queste risorse. L'applicazione Insights dati archiviati nelle app non verrà recuperata.

Importante

Se si usa una risorsa di Application Insights basata sull'area di lavoro, i dati di telemetria vengono archiviati in un'area di lavoro Log Analytics con tutti gli altri dati di log. Usare l'espressione workspace() per scrivere una query che include applicazioni in più aree di lavoro. Per più applicazioni nella stessa area di lavoro, non è necessaria una query tra aree di lavoro.

Limiti di query tra risorse

  • Il numero di risorse Insights applicazioni e aree di lavoro log analytics che è possibile includere in una singola query è limitato a 100.
  • Le query su più risorse non sono supportate Progettazione visualizzazioni. È possibile creare una query in Log Analytics e aggiungerla al dashboard di Azure per visualizzare una query di log o includere in Workbooks.
  • Le query tra risorse negli avvisi di log sono supportate solo nell'API scheduledQueryRules corrente. Se si usa l'API avvisi di Log Analytics legacy, è necessario passare all'API corrente.

Esecuzione di query tra aree di lavoro di Log Analytics e da Application Insights

Per fare riferimento a un'altra area di lavoro nella query, usare l'identificatore workspace, mentre per un'app di Application Insights usare l'identificatore app.

Identificazione delle risorse dell'area di lavoro

Gli esempi seguenti dimostrano che le query eseguite su più aree di lavoro di Log Analytics restituiscono un riepilogo del numero di log dalla tabella di aggiornamento in un'area di lavoro denominata contosoretail-it.

Esistono vari modi per identificare un'area di lavoro:

  • Nome risorsa - Un nome dell'area di lavoro leggibile dall'utente, spesso definito genericamente nome del componente.

    Importante

    Poiché i nomi dell'app e dell'area di lavoro non sono univoci, questo identificatore potrebbe essere ambiguo. È consigliabile fare riferimento in base al nome qualificato, all'ID area di lavoro o all'ID risorsa di Azure.

    workspace("contosoretail-it").Update | count

  • Nome qualificato: è il "nome completo" dell'area di lavoro, composto dal nome della sottoscrizione, dal gruppo di risorse e dal nome del componente in questo formato: subscriptionName/resourceGroup/componentName.

    workspace('contoso/contosoretail/contosoretail-it').Update | count

    Nota

    Poiché i nomi delle sottoscrizioni di Azure non sono univoci, questo identificatore potrebbe essere ambiguo.

  • ID area di lavoro - L'ID dell'area di lavoro è l'identificatore univoco e non modificabile assegnato a ogni area di lavoro rappresentato come identificatore univoco globale (GUID).

    workspace("b459b4u5-912x-46d5-9cb1-p43069212nb4").Update | count

  • ID risorsa Azure - L'identità univoca definita da Azure dell'area di lavoro. Si usa quando il nome della risorsa è ambiguo. Per le aree di lavoro, il formato è: /subscriptions/subscriptionId/resourcegroups/resourceGroup/providers/microsoft.OperationalInsights/workspaces/componentName.

    Ad esempio:

    workspace("/subscriptions/e427519-5645-8x4e-1v67-3b84b59a1985/resourcegroups/ContosoAzureHQ/providers/Microsoft.OperationalInsights/workspaces/contosoretail-it").Update | count
    

Identificazione di un'applicazione

Gli esempi seguenti restituiscono il riepilogo del numero di richieste eseguite su un'app denominata fabrikamapp in Application Insights.

L'identificazione di un'applicazione in Application Insights può essere eseguita con l'espressione app(Identifier). L'argomento Identifier specifica l'app usando uno degli elementi seguenti:

  • Nome risorsa - Nome dell'app leggibile dall'utente, spesso definito genericamente nome del componente.

    app("fabrikamapp")

    Nota

    L'identificazione di un'applicazione in base al nome presuppone l'univocità in tutte le sottoscrizioni accessibili. Se sono presenti più applicazioni con il nome specificato, la query avrà esito negativo a causa dell'ambiguità. In questo caso è necessario usare uno degli altri identificatori.

  • Nome completo - Nome completo dell'app, composto dal nome della sottoscrizione, dal gruppo di risorse e dal nome del componente nel formato seguente: subscriptionName/resourceGroup/componentName.

    app("AI-Prototype/Fabrikam/fabrikamapp").requests | count

    Nota

    Poiché i nomi delle sottoscrizioni di Azure non sono univoci, questo identificatore potrebbe essere ambiguo.

  • ID - GUID dell'app.

    app("b459b4f6-912x-46d5-9cb1-b43069212ab4").requests | count

  • ID risorsa Azure - Identità univoca dell'app definita da Azure. Si usa quando il nome della risorsa è ambiguo. Il formato è: /subscriptions/subscriptionId/resourcegroups/resourceGroup/providers/microsoft.OperationalInsights/components/componentName.

    Ad esempio:

    app("/subscriptions/b459b4f6-912x-46d5-9cb1-b43069212ab4/resourcegroups/Fabrikam/providers/microsoft.insights/components/fabrikamapp").requests | count
    

Esecuzione di una query in più risorse

È possibile eseguire una query su più risorse da una qualsiasi delle istanze di risorse, ad esempio aree di lavoro e app combinate.

Esempio di query in due aree di lavoro:

union Update, workspace("contosoretail-it").Update, workspace("b459b4u5-912x-46d5-9cb1-p43069212nb4").Update
| where TimeGenerated >= ago(1h)
| where UpdateState == "Needed"
| summarize dcount(Computer) by Classification

Uso di una query tra risorse per più risorse

Quando si usano query tra risorse per correlare i dati di più aree di lavoro di Log Analytics e di risorse di Application Insights, la query può diventare complessa e difficile da gestire. È consigliabile sfruttare le funzioni delle query di log di Monitoraggio di Azure per separare la logica della query dall'ambito delle risorse della query, semplificando così la struttura della query stessa. L'esempio seguente mostra come è possibile monitorare più risorse di Application Insights e visualizzare il numero di richieste non riuscite per nome applicazione.

Creare una query come la seguente, che fa riferimento all'ambito delle risorse di Application Insights. Il comando withsource= SourceApp aggiunge una colonna che indica il nome dell'applicazione che ha inviato il log. Salvare la query come funzione con l'alias applicationsScoping.

// crossResource function that scopes my Application Insights resources
union withsource= SourceApp
app('Contoso-app1').requests, 
app('Contoso-app2').requests,
app('Contoso-app3').requests,
app('Contoso-app4').requests,
app('Contoso-app5').requests

A questo punto è possibile usare questa funzione in una query tra risorse come la seguente. L'alias di funzione applicationsScoping restituisce l'unione della tabella delle richieste da tutte le applicazioni definite. La query filtra quindi le richieste non riuscite e visualizza le tendenze per applicazione. L'operatore parse è facoltativo in questo esempio. Estrae il nome dell'applicazione dalla proprietà SourceApp.

applicationsScoping 
| where timestamp > ago(12h)
| where success == 'False'
| parse SourceApp with * '(' applicationName ')' * 
| summarize count() by applicationName, bin(timestamp, 1h) 
| render timechart

Nota

Questo metodo non può essere usato con avvisi di log perché la convalida di accesso delle risorse della regola di avviso, incluse aree di lavoro e applicazioni, viene eseguita al momento della creazione degli avvisi. L'aggiunta di nuove risorse alla funzione dopo la creazione dell'avviso non è supportata. Se si preferisce usare la funzione per l'ambito delle risorse negli avvisi di log, è necessario modificare la regola di avviso nel portale o con un modello di Resource Manager per aggiornare le risorse con ambito. In alternativa, è possibile includere l'elenco di risorse nella query di avviso di log.

Timechart

Passaggi successivi