Inserire dati da Telegraf in Azure Esplora dati
Importante
Questo connettore può essere usato in Intelligenza in tempo reale in Microsoft Fabric. Usare le istruzioni in questo articolo con le eccezioni seguenti:
- Se necessario, creare database usando le istruzioni riportate in Creare un database KQL.
- Se necessario, creare tabelle usando le istruzioni riportate in Creare una tabella vuota.
- Ottenere URI di query o inserimento usando le istruzioni in URI di copia.
- Eseguire query in un set di query KQL.
Azure Esplora dati supporta l'inserimento dati da Telegraf. Telegraf è un agente open source, leggero e con un footprint della memoria minimo per la raccolta, l'elaborazione e la scrittura di dati di telemetria, inclusi log, metriche e dati IoT. Telegraf supporta centinaia di plug-in di input e output. È ampiamente usato e ben supportato dalla community open source. Il plug-in di output di Azure Esplora dati funge da connettore da Telegraf e supporta l'inserimento di dati da molti tipi di plug-in di input in Azure Esplora dati.
Prerequisiti
- Una sottoscrizione di Azure. Creare un account Azure gratuito.
- Un cluster e un database di Esplora dati di Azure. Creare un cluster e un database.
- Telegraf. Ospitare Telegraf in una macchina virtuale o in un contenitore. Telegraf può essere ospitato localmente in cui viene distribuita l'app o il servizio monitorato o in remoto in un ambiente di calcolo/contenitore di monitoraggio dedicato.
Metodi di autenticazione supportati
Il plug-in supporta i metodi di autenticazione seguenti:
Applicazioni Microsoft Entra con chiavi o certificati dell'app.
- Per informazioni su come creare e registrare un'app in Microsoft Entra ID, vedere Registrare un'applicazione.
- Per informazioni sulle entità servizio, vedere Oggetti applicazione e entità servizio in Microsoft Entra ID.
Token utente di Microsoft Entra
- Consente al plug-in di eseguire l'autenticazione come un utente. È consigliabile usare questo metodo solo a scopo di sviluppo.
Token dell'identità del servizio gestito di Azure
- Questo è il metodo di autenticazione preferito se si esegue Telegraf in un ambiente di Azure di supporto, ad esempio Azure Macchine virtuali.
A qualsiasi metodo usato, all'entità designata deve essere assegnato il ruolo Utente database in Azure Esplora dati. Questo ruolo consente al plug-in di creare le tabelle necessarie per l'inserimento di dati. Se il plug-in è configurato con create_tables=false
, l'entità designata deve avere almeno il ruolo Database Ingestor .
Configurare il metodo di autenticazione
Il plug-in verifica la presenza di configurazioni specifiche delle variabili di ambiente per determinare il metodo di autenticazione da usare. Le configurazioni vengono valutate nell'ordine specificato e viene usata la prima configurazione rilevata. Se non viene rilevata una configurazione valida, l'autenticazione del plug-in non riuscirà.
Per configurare l'autenticazione per il plug-in, impostare le variabili di ambiente appropriate per il metodo di autenticazione scelto:
Credenziali client (token dell'applicazione Microsoft Entra): ID applicazione Microsoft Entra e segreto.
AZURE_TENANT_ID
: ID tenant di Microsoft Entra usato per l'autenticazione.AZURE_CLIENT_ID
: ID client di una registrazione dell'app nel tenant.AZURE_CLIENT_SECRET
: segreto client generato per la registrazione dell'app.
Certificato client (token dell'applicazione Microsoft Entra): ID applicazione Microsoft Entra e certificato X.509.
AZURE_TENANT_ID
: ID tenant di Microsoft Entra usato per l'autenticazione.AZURE_CERTIFICATE_PATH
: percorso del certificato e della coppia di chiavi private in formato PEM o PFX, che può autenticare la registrazione dell'app.AZURE_CERTIFICATE_PASSWORD
: password impostata per il certificato.
Password del proprietario della risorsa (token utente Di Microsoft Entra): utente e password di Microsoft Entra. Non è consigliabile usare questo tipo di concessione. Se è necessario un accesso interattivo, usare l'account di accesso del dispositivo.
AZURE_TENANT_ID
: ID tenant di Microsoft Entra usato per l'autenticazione.AZURE_CLIENT_ID
: ID client di una registrazione dell'app nel tenant.AZURE_USERNAME
: nome utente, noto anche come upn, di un account utente Microsoft Entra.AZURE_PASSWORD
: password dell'account utente Microsoft Entra. Si noti che questo non supporta gli account con MFA abilitata.
Identità del servizio gestito di Azure: delegare la gestione delle credenziali alla piattaforma. Questo metodo richiede che il codice venga eseguito in Azure, ad esempio la macchina virtuale. Tutte le configurazioni vengono gestite da Azure. Per altre informazioni, vedere Identità del servizio gestito di Azure. Questo metodo è disponibile solo quando si usa Azure Resource Manager.
Configurare Telegraf
Telergraf è un agente basato sulla configurazione. Per iniziare, è necessario installare Telegraf e configurare i plug-in di input e output necessari. Il percorso predefinito del file di configurazione è il seguente:
- Per Windows: C:\Programmi\Telegraf\telegraf.conf
- Per Linux: etc/telegraf/telegraf.conf
Per abilitare il plug-in di output di Azure Esplora dati, è necessario rimuovere il commento dalla sezione seguente nel file di configurazione generato automaticamente:
[[outputs.azure_data_explorer]]
## The URI property of the Azure Data Explorer resource on Azure
## ex: https://myadxresource.australiasoutheast.kusto.windows.net
# endpoint_url = ""
## The Azure Data Explorer database that the metrics will be ingested into.
## The plugin will NOT generate this database automatically, it's expected that this database already exists before ingestion.
## ex: "exampledatabase"
# database = ""
## Timeout for Azure Data Explorer operations, default value is 20 seconds
# timeout = "20s"
## Type of metrics grouping used when ingesting to Azure Data Explorer
## Default value is "TablePerMetric" which means there will be one table for each metric
# metrics_grouping_type = "TablePerMetric"
## Name of the single table to store all the metrics (Only needed if metrics_grouping_type is "SingleTable").
# table_name = ""
## Creates tables and relevant mapping if set to true(default).
## Skips table and mapping creation if set to false, this is useful for running telegraf with the least possible access permissions i.e. table ingestor role.
# create_tables = true
Tipi di inserimento supportati
Il plug-in supporta l'inserimento gestito (streaming) e l'inserimento in coda (invio in batch). Il tipo di inserimento predefinito è in coda.
Importante
Per usare l'inserimento gestito, è necessario abilitare l'inserimento in streaming nel cluster.
Per configurare il tipo di inserimento per il plug-in, modificare il file di configurazione generato automaticamente, come indicato di seguito:
## Ingestion method to use.
## Available options are
## - managed -- streaming ingestion with fallback to batched ingestion or the "queued" method below
## - queued -- queue up metrics data and process sequentially
# ingestion_type = "queued"
Eseguire query sui dati inseriti
Di seguito sono riportati esempi di dati raccolti usando i plug-in di input SQL e syslog insieme al plug-in di output di Azure Esplora dati. Per ogni metodo di input, è disponibile un esempio di come usare trasformazioni e query di dati in Azure Esplora dati.
Plug-in di input SQL
La tabella seguente mostra i dati delle metriche di esempio raccolti dal plug-in di input SQL:
name | tag | timestamp | campi |
---|---|---|---|
sqlserver_database_io | {"database_name":"azure-sql-db2","file_type":"DATA","host":"adx-vm","logical_filename":"tempdev","measurement_db_type":"AzureSQLDB","physical_filename":"tempdb.mdf","replica_updateability":"READ_WRITE","sql_instance":"adx-sql-server"} | 2021-09-09T13:51:20Z | {"current_size_mb":16,"database_id":2,"file_id":1,"read_bytes":2965504,"read_latency_ms":68,"reads":47, "rg_read_stall_ms":42,"rg_write_stall_ms":0,"space_used_mb":0,"write_bytes":1220608,"write_latency_ms":103,"writes":149} |
sqlserver_waitstats | {"database_name":"azure-sql-db2","host":"adx-vm","measurement_db_type":"AzureSQLDB","replica_updateability":"READ_WRITE","sql_instance":"adx-sql-server","wait_category":"Thread di lavoro","wait_type":"THREADPOOL"} | 2021-09-09T13:51:20Z | {"max_wait_time_ms":15,"resource_wait_ms":4469,"signal_wait_time_ms":0,"wait_time_ms":4469,"waiting_tasks_count":1464} |
Poiché l'oggetto metriche raccolto è un tipo complesso, i campi e le colonne dei tag vengono archiviati come tipi di dati dinamici. Esistono molti modi per eseguire query su questi dati, ad esempio:
Eseguire query sugli attributi JSON direttamente: è possibile eseguire query sui dati JSON in formato non elaborato senza analizzarli.
Esempio 1
Tablename | where name == "sqlserver_azure_db_resource_stats" and todouble(fields.avg_cpu_percent) > 7
Esempio 2
Tablename | distinct tostring(tags.database_name)
Nota
Questo approccio potrebbe influire sulle prestazioni quando si usano volumi elevati di dati. In questi casi, usare l'approccio ai criteri di aggiornamento.
Usare un criterio di aggiornamento: trasformare le colonne del tipo di dati dinamico usando un criterio di aggiornamento. È consigliabile usare questo approccio per eseguire query su grandi volumi di dati.
// Function to transform data .create-or-alter function Transform_TargetTableName() { SourceTableName | mv-apply fields on (extend key = tostring(bag_keys(fields)[0])) | project fieldname=key, value=todouble(fields[key]), name, tags, timestamp } // Create destination table with above query's results schema (if it doesn't exist already) .set-or-append TargetTableName <| Transform_TargetTableName() | take 0 // Apply update policy on destination table .alter table TargetTableName policy update @'[{"IsEnabled": true, "Source": "SourceTableName", "Query": "Transform_TargetTableName()", "IsTransactional": true, "PropagateIngestionProperties": false}]'
Plug-in di input Syslog
La tabella seguente mostra i dati delle metriche di esempio raccolti dal plug-in di input Syslog:
name | tag | timestamp | campi |
---|---|---|---|
syslog | {"appname":"azsecmond","facility":"user","host":"adx-linux-vm","hostname":"adx-linux-vm","severity":"info"} | 2021-09-20T14:36:44Z | {"facility_code":1,"message":" 2021/09/20 14:36:44.890110 Impossibile connettersi a mdsd: dial unix /var/run/mdsd/default_djson.socket: connect: no such file or directory","procid":"2184","severity_code":6,"timestamp":"1632148604890477000","version":1} |
syslog | {"appname":"CRON","facility":"authpriv","host":"adx-linux-vm","nome host":"adx-linux-vm","severity":"info"} | 2021-09-20T14:37:01Z | {"facility_code":10,"message":" pam_unix(cron:session): sessione aperta per la radice utente da (uid=0)","procid":"26446","severity_code":6,"timestamp":"1632148621120781000","version":1} |
Esistono diversi modi per rendere flat le colonne dinamiche usando l'operatore extend o il plug-in bag_unpack(). È possibile usarli nella funzione Transform_TargetTableName() dei criteri di aggiornamento.
Usare l'operatore extend: è consigliabile usare questo approccio perché è più veloce e affidabile. Anche se lo schema cambia, non interromperà query o dashboard.
Tablename | extend facility_code=toint(fields.facility_code), message=tostring(fields.message), procid= tolong(fields.procid), severity_code=toint(fields.severity_code), SysLogTimestamp=unixtime_nanoseconds_todatetime(tolong(fields.timestamp)), version= todouble(fields.version), appname= tostring(tags.appname), facility= tostring(tags.facility),host= tostring(tags.host), hostname=tostring(tags.hostname), severity=tostring(tags.severity) | project-away fields, tags
Usa plug-in bag_unpack(): questo approccio decomprime automaticamente le colonne di tipo dinamico. La modifica dello schema di origine può causare problemi durante l'espansione dinamica delle colonne.
Tablename | evaluate bag_unpack(tags, columnsConflict='replace_source') | evaluate bag_unpack(fields, columnsConflict='replace_source')