Share via

Inserire dati da Telegraf in Azure Esplora dati

  • Articolo

Importante

Questo connettore può essere usato in Analisi in tempo reale in Microsoft Fabric. Usare le istruzioni in questo articolo con le eccezioni seguenti:

Azure Esplora dati supporta l'inserimento dati da Telegraf. Telegraf è un agente di stampa open source, leggero e minimo per i piè di pagina di memoria 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 (VM) 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:

  • Microsoft Entra applicazioni con chiavi o certificati dell'app.

  • Microsoft Entra token utente

    • Consente al plug-in di eseguire l'autenticazione come un utente. È consigliabile usare questo metodo solo a scopo di sviluppo.

  • Token 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 dei 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, il plug-in non riuscirà a eseguire l'autenticazione.

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):Microsoft Entra ID applicazione e segreto.

    • AZURE_TENANT_ID: ID tenant 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 applicazione Microsoft Entra): Microsoft Entra ID applicazione e un certificato X.509.

    • AZURE_TENANT_ID: ID tenant 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 Microsoft Entra): Microsoft Entra utente e password. Non è consigliabile usare questo tipo di concessione. Se è necessario un accesso interattivo, usare l'account di accesso del dispositivo.

    • AZURE_TENANT_ID: ID tenant 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 non supporta gli account con MFA abilitato.

  • 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 le trasformazioni e le query dei dati in Azure Esplora dati.

Plug-in di input SQL

La tabella seguente illustra i dati delle metriche di esempio raccolti dal plug-in di input SQL:

name tags timestamp fields
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,"scritture":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 metrica raccolto è un tipo complesso, i campi e le colonne dei tag vengono archiviati come tipi di dati dinamici. Esistono diversi 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 può 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 l'esecuzione di 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 illustra i dati delle metriche di esempio raccolti dal plug-in di input Syslog:

name tags timestamp fields
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","hostname":"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 viene modificato, 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')