Raccogliere eventi e contatori delle prestazioni dalle macchine virtuali con l'agente di Monitoraggio di Azure
Questo articolo descrive come raccogliere eventi e contatori delle prestazioni dalle macchine virtuali usando l'agente di Monitoraggio di Azure.
Prerequisiti
Per completare questa procedura, è necessario:
- Area di lavoro Log Analytics in cui si hanno almeno i diritti di collaboratore.
- Autorizzazioni per creare oggetti Regola raccolta dati nell'area di lavoro.
- Associare la regola di raccolta dati a macchine virtuali specifiche.
Creare una regola di raccolta dati
È possibile, ad esempio, definire una regola di raccolta dati per inviare dati da più computer a più aree di lavoro Log Analytics, incluse aree di lavoro in un'area o un tenant diverso. Creare la regola di raccolta dati nella stessa area dell'area di lavoro Log Analytics. È possibile inviare i dati di eventi e Syslog di Windows solo ai log di Monitoraggio di Azure. È possibile inviare contatori delle prestazioni sia alle metriche di Monitoraggio di Azure sia ai log di Monitoraggio di Azure.
Nota
Al momento, le risorse Microsoft.HybridCompute (server abilitati per Azure Arc) non possono essere visualizzate in Esplora metriche (l'esperienza utente portale di Azure), ma possono essere acquisite tramite l'API REST delle metriche (Spazi dei nomi delle metriche - Elenco, Definizioni delle metriche - Elenco e Metriche - Elenco).
Nota
Per inviare dati tra tenant, è prima necessario abilitare Azure Lighthouse.
Nel menu Monitoraggio selezionare Regole di raccolta dati.
Selezionare Crea per creare una nuova regola di raccolta dati e le relative associazioni.
Immettere un nome regola e specificare una sottoscrizione, un gruppo di risorse, un'area e un tipo di piattaforma:
- In Area viene specificata la regione in cui verrà creata la regola di raccolta dati. Le macchine virtuali e le relative associazioni possono trovarsi in qualsiasi sottoscrizione o gruppo di risorse presente nel tenant.
- In Tipo di piattaforma viene specificato il tipo di risorse a cui può essere applicata questa regola. L'opzione Custom consente sia i tipi Windows che Linux.
Nella scheda Risorse :
-
Selezionare + Aggiungi risorse e associare le risorse alla regola di raccolta dati. Le risorse possono essere macchine virtuali, set di scalabilità di macchine virtuali e Azure Arc per server. Il portale di Azure installa l'agente di Monitoraggio di Azure nelle risorse che non sono già installate.
Importante
Il portale abilita l'identità gestita assegnata dal sistema nelle risorse di destinazione, insieme alle identità assegnate dall'utente esistenti, se presenti. Per le applicazioni esistenti, a meno che non si specifichi l'identità assegnata dall'utente nella richiesta, per impostazione predefinita il computer usa l'identità assegnata dal sistema.
Se è necessario l'isolamento di rete usando collegamenti privati, selezionare gli endpoint esistenti dalla stessa area per le rispettive risorse o creare un nuovo endpoint.
Selezionare Abilitare gli endpoint di raccolta dei dati.
Selezionare un endpoint di raccolta dati per ognuna delle risorse associate alla regola di raccolta dati.
Nella scheda Raccogli e recapita selezionare Aggiungi origine dati per aggiungere un'origine dati e impostare una destinazione.
Selezionare un tipo di Origine dati.
Selezionare i dati che si desidera raccogliere. Per i contatori delle prestazioni, è possibile selezionare un set predefinito di oggetti e la relativa frequenza di campionamento. Per gli eventi, è possibile scegliere da un set di log e livelli di gravità.
Selezionare Personalizzato per raccogliere log e contatori delle prestazioni che non sono origini dati attualmente supportate o per filtrare gli eventi tramite query XPath. È quindi possibile specificare un XPath per raccogliere valori specifici.
Per raccogliere un contatore delle prestazioni non disponibile per impostazione predefinita, usare il formato
\PerfObject(ParentInstance/ObjectInstance#InstanceIndex)\Counter. Se il nome del contatore contiene un e commerciale (&), sostituirlo con&. Ad esempio:\Memory\Free & Zero Page List Bytes.Per esempi di controller di dominio di dominio, vedere Regole di raccolta dati di esempio in Monitoraggio di Azure.
Nella scheda Destinazione aggiungere una o più destinazioni per l'origine dati. È possibile selezionare più destinazioni di uno stesso tipo o di tipi diversi. Ad esempio, è possibile selezionare più aree di lavoro Log Analytics (operazione nota anche come multihoming).
È possibile inviare origini dati di Syslog e di eventi Windows solo ai log di Monitoraggio di Azure. È possibile inviare contatori delle prestazioni sia alle metriche di Monitoraggio di Azure sia ai log di Monitoraggio di Azure. Al momento, le risorse di calcolo ibrido (Arc for Server) non supportano la destinazione Metriche di Monitoraggio di Azure (anteprima).
Selezionare Aggiungi origine dati e quindi Rivedi e crea per esaminare i dettagli della regola di raccolta dati e la relativa associazione con il set di macchine virtuali.
Selezionare Crea per creare la regola di raccolta dati.
File di parametri
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vmName": {
"value": "my-azure-vm"
},
"associationName": {
"value": "my-windows-vm-my-dcr"
},
"dataCollectionRuleId": {
"value": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/my-resource-group/providers/microsoft.insights/datacollectionrules/my-dcr"
}
}
}
Nota
L'invio dei dati alle destinazioni può richiedere fino a 5 minuti dopo la creazione della regola di raccolta dati.
Filtrare gli eventi usando query XPath
Vengono addebitati i costi per i dati raccolti in un'area di lavoro Log Analytics. Pertanto, è consigliabile raccogliere solo i dati dell'evento necessari. La configurazione di base nella portale di Azure offre una possibilità limitata di filtrare gli eventi.
Suggerimento
Per le strategie per ridurre i costi di Monitoraggio di Azure, vedere Ottimizzazione dei costi e Monitoraggio di Azure.
Per specificare altri filtri, usare la configurazione personalizzata e specificare un XPath che filtra gli eventi non necessari. Le voci XPath vengono scritte nel formato LogName!XPathQuery. Ad esempio, potrebbe essere necessario restituire solo gli eventi dal registro eventi dell'applicazione con un ID evento 1035. L'oggetto XPathQuery per questi eventi sarà *[System[EventID=1035]]. Poiché si desidera recuperare gli eventi dal registro eventi dell'applicazione, XPath è Application!*[System[EventID=1035]]
Estrarre query XPath da Windows Visualizzatore eventi
In Windows è possibile usare Visualizzatore eventi per estrarre query XPath, come illustrato negli screenshot.
Quando si incolla la query XPath nel campo nella schermata Aggiungi origine dati, come illustrato nel passaggio 5, è necessario aggiungere la categoria del tipo di log seguita da un punto esclamativo (!).
Suggerimento
È possibile usare il cmdlet Get-WinEvent di PowerShell con il FilterXPath parametro per testare prima la validità di una query XPath nel computer. Per altre informazioni, vedere il suggerimento fornito nelle istruzioni sulle connessioni basate su agente windows. Il Get-WinEvent cmdlet di PowerShell supporta fino a 23 espressioni. Le regole di raccolta dati di Monitoraggio di Azure supportano fino a 20. Lo script seguente mostra un esempio:
$XPath = '*[System[EventID=1035]]'
Get-WinEvent -LogName 'Application' -FilterXPath $XPath
- Nel cmdlet precedente il valore del
-LogNameparametro è la parte iniziale della query XPath fino al punto esclamativo (!). Il resto della query XPath entra nel$XPathparametro . - Se lo script restituisce eventi, la query è valida.
- Se viene visualizzato il messaggio "Non sono stati trovati eventi che corrispondono ai criteri di selezione specificati", la query potrebbe essere valida ma non sono presenti eventi corrispondenti nel computer locale.
- Se viene visualizzato il messaggio "La query specificata non è valida", la sintassi della query non è valida.
Esempi di utilizzo di un XPath personalizzato per filtrare gli eventi:
| Descrizione | XPath |
|---|---|
| Raccogliere solo gli eventi di sistema con ID evento = 4648 | System!*[System[EventID=4648]] |
| Raccogliere eventi del log di sicurezza con ID evento = 4648 e un nome di processo di consent.exe | Security!*[System[(EventID=4648)]] and *[EventData[Data[@Name='ProcessName']='C:\Windows\System32\consent.exe']] |
| Raccogliere tutti gli eventi critici, di errore, di avviso e di informazioni dal registro eventi di sistema, ad eccezione dell'ID evento = 6 (driver caricato) | System!*[System[(Level=1 or Level=2 or Level=3) and (EventID != 6)]] |
| Raccogliere tutti gli eventi di sicurezza con esito positivo e negativo, ad eccezione dell'ID evento 4624 (accesso riuscito) | Security!*[System[(band(Keywords,13510798882111488)) and (EventID != 4624)]] |
Nota
Per un elenco delle limitazioni nel registro eventi XPath supportato dal registro eventi di Windows, vedere Limitazioni di XPath 1.0.
Ad esempio, è possibile usare le funzioni "position", "Band" e "timediff" all'interno della query, ma altre funzioni come "starts-with" e "contains" non sono attualmente supportate.
Domande frequenti
Questa sezione fornisce le risposte alle domande comuni.
Come è possibile raccogliere eventi di sicurezza di Windows usando l'agente di Monitoraggio di Azure?
Esistono due modi per raccogliere gli eventi di sicurezza usando il nuovo agente quando si esegue l'invio a un'area di lavoro Log Analytics:
- È possibile usare l'agente di Monitoraggio di Azure per raccogliere in modo nativo gli eventi di sicurezza, come altri eventi di Windows. Questi vengono inviati alla tabella 'Event' nell'area di lavoro Log Analytics.
- Se Nell'area di lavoro è abilitato Microsoft Sentinel, gli eventi di sicurezza vengono trasmessi tramite l'agente di Monitoraggio di Azure nella
SecurityEventtabella (come se si usa l'agente di Log Analytics). Questo scenario richiede sempre che la soluzione sia abilitata per prima.
Duplicare gli eventi se si usa l'agente di Monitoraggio di Azure e l'agente di Log Analytics nello stesso computer?
Se si raccolgono gli stessi eventi con entrambi gli agenti, si verifica la duplicazione. Questa duplicazione potrebbe essere l'agente legacy che raccoglie dati ridondanti dai dati di configurazione dell'area di lavoro, raccolti dalla regola di raccolta dati. In alternativa, è possibile raccogliere eventi di sicurezza con l'agente legacy e abilitare gli eventi di sicurezza di Windows con i connettori dell'agente di Monitoraggio di Azure in Microsoft Sentinel.
Limitare gli eventi di duplicazione solo al momento della transizione da un agente all'altro. Dopo aver testato completamente la regola di raccolta dati e verificato la raccolta dei dati, disabilitare la raccolta per l'area di lavoro e disconnettere i connettori dati di Microsoft Monitoring Agent.
L'agente di Monitoraggio di Azure offre opzioni di filtro degli eventi più granulari diverse dalle query Xpath e specifica i contatori delle prestazioni?
Per gli eventi Syslog in Linux, è possibile selezionare le funzionalità e il livello di log per ogni funzionalità.
Se si creano regole di raccolta dati che contengono lo stesso ID evento e le si associano alla stessa macchina virtuale, gli eventi verranno duplicati?
Sì. Per evitare la duplicazione, assicurarsi che la selezione degli eventi effettuata nelle regole di raccolta dati non contenga eventi duplicati.
Passaggi successivi
- Raccogliere i log di testo usando l'agente di Monitoraggio di Azure.
- Altre informazioni sull'agente di Monitoraggio di Azure.
- Altre informazioni sulle regole di raccolta dati.