Giugno 2018

Volume 33 Numero 6

Il presente articolo è stato tradotto automaticamente.

Azure Databricks - Monitoraggio di processi di Databricks con Application Insights

Dal massimo Fultz | 2018 giugno

Si lavora in un team che è incentrato sui dati e analitica per grandi aziende che vogliono implementare o le relative soluzioni la migrazione al cloud. Queste attività includono il lavoro ovvio dell'ottimizzazione e riprogettazione del applicazioni a vari livelli per assicurare che possono sfruttare le possibilità offerte di cloud. Grande quanto come questi sforzi possono essere utile per l'applicazione stessa, sono presenti problemi aggiuntivi per le organizzazioni appena avviata il viaggio cloud, come avviene deve anche tutte le operazioni eseguite insieme a estendere le capacità operative nel cloud. E, come le nuove tecnologie emerge evolvere, questi devono essere ridotti nei operational infrastruttura esistente, nonché. Si tratta di una delle sfide che esiste con soluzioni basate su Apache Hadoop e Spark. Sì, Ambari Apache è presente per fornire un dashboard con nice e ha un'API per esporre le metriche, ma molte organizzazioni dispongono già di un investimento in e una buona conoscenza di altre soluzioni di monitoraggio e creazione di dashboard, ad esempio Azure Application Insights.

Immaginare un processo Web che preleva i messaggi dagli hub di eventi di Azure, non una convalida iniziale e lo rilasci in archiviazione di Azure, a quel punto che i dati vengono elaborati tramite processi Spark diversi, come illustrato figura 1. L'obiettivo consiste nell'ottenere un dashboard singolo runtime che può fornire informazioni che mostra non soltanto qual è il problema, ma anche le informazioni specifiche di business e processo mentre è in fase di trasferimento. Inoltre, sarebbe incredibile sia in grado di tenere traccia del flusso di informazioni come un processo olistico e vedere i dettagli ai processi che lo costituiscono.

Figura 1 singola soluzione, processi distinti, due fasi distinte

Assicurarsi, è possibile visualizzare le metriche predefinito per i processi di processi Web di Application Insights e alcune informazioni da di Spark in Ambari e consentirà di all up with Analitica di Log di Azure Insights post hoc. Tuttavia, non si desidera vedere due processi distinti con quattro passaggi. Si desidera visualizzare il processo nel suo complesso e vogliamo insights di runtime e gli avvisi di runtime.

In questo articolo verranno esaminati considerazioni e la pianificazione per riportare l'intero progetto tra loro tramite Application Insights. Inoltre, verrà usato la versione di Azure Databricks di Spark perché contiene un interessante set di funzionalità che consentono di più facilmente lo sviluppo e rendere operativo il flusso di lavoro.

Pianificazione della telemetria di Application Insights

È non essere relativi a concetti di base, ma per una panoramica su questi concetti esaminare la documentazione online all'indirizzo bit.ly/2FYOCyp. Inoltre, Victor Mushkatin e Kanzhelev Sergey ha scritto un buon articolo sull'ottimizzazione della raccolta dati di telemetria, "Ottimizzare telemetria con Application Insights" (msdn.com/magazine/mt808502). In questo caso, ci concentreremo su organizzare i blocchi appunti e processi per facilitare la corretta nel formato dell'operazione, evento e i dati che vengono inviate dai nostri processi Databricks di rilevamento.

In Databricks, è possibile definire un processo come l'esecuzione di un blocco per Appunti con determinati parametri. Figura 2 illustra due approcci di base all'organizzazione di lavoro in un blocco per Appunti Databricks.

Figura 2 Opzioni organizzative di base per un processo di blocco per Appunti Databricks

Figura 2 Mostra due possibilità semplice in cui un processo è definito come un singolo blocco per Appunti con un numero di blocchi di codice o le funzioni per ottengano chiamate mentre l'altro processo consente di visualizzare un raccoglitore di controllo che coordina l'esecuzione di notebook figlio, in sequenza o in parallelo. Non si tratta, in qualsiasi modo, la sola organizzazione che può essere usata, ma è sufficiente per consentire di illustrare come preoccuparsi di correlazione. La relativa organizzazione i blocchi appunti e codice di creazione è certamente un argomento comprenderne il ed è estremamente variabile a seconda della dimensione e la natura del processo. Per un po' più approfondito nel flusso di lavoro Notebook Databricks, esaminare il post di blog, "Notebook i flussi di lavoro: Il modo più semplice per implementare Apache Spark pipeline"(bit.ly/2HOqvTj).

Si noti che organizzazione notebook è stato allineato con operazioni discrete che possono essere usato per l'evento del gruppo di gestione rapporti in Application Insights. In Application Insights, correlazione viene eseguita tramite due proprietà: Id dell'operazione e ID dell'operazione padre. Come illustrato nel figura 2, si desidera acquisire tutti gli eventi discreti e metriche relative all'interno di un codice di bloccare o separare notebook nel contesto di una singola operazione, viene eseguita tramite un'operazione distinct Id per ogni sezione. Inoltre, desideriamo vedere tali blocchi operazione separata di grandi dimensioni come parte di un intero, possiamo impostando operazione padre del contesto Id sullo stesso valore per tutte le metriche della creazione di report in ogni operazione. L'operazione padre Id è anche possibile passare da un trigger esterno per il processo, che quindi fornisce un meccanismo per tutte le operazioni discrete dal processo precedente e il processo di Azure Databricks come parte di un'operazione singola gestalt identificata da collegare il padre operazione Id in Application Insights.

È stata rappresentate alcuni scenari di seguito. Il punto importante è che è necessario considerare come si desidera organizzare le operazioni, gli eventi e metriche come parte dell'organizzazione processo complessivo.

Aggiunta di Application Insights per l'ambiente

Per preparare l'ambiente, è necessario installare la libreria Python Application Insights nel cluster, selezionare alcune impostazioni di configurazione e aggiungere il codice di supporto. È possibile trovare Application Insights nella pypi (pypi.python.org/pypi/applicationinsights/0.1.0). Per aggiungerlo al Databricks, è sufficiente scegliere una posizione nell'area di lavoro (abbiamo creato uno denominato Lib) e fare doppio clic su e scegliere Create, quindi libreria. Una volta, è possibile immettere il nome dell'applicazione pypi e Databricks Scarica e installa il pacchetto. L'ultima operazione che è necessario decidere è o meno cui si desidera collegare la libreria a tutti i cluster automaticamente.

Nel tentativo di ridurre la quantità di codice da aggiungere a ogni blocco per Appunti, è stato aggiunto un file di inclusione con un paio di funzioni di supporto:

def NewTelemetryClient (applicationId, operationId="",  
  parentOperationId=""):
  tc = TelemetryClient(instrumentationKey)
  tc.context.application.id = applicationId
  tc.context.application.ver = '0.0.1'
  tc.context.device.id = 'Databricks notebook'
  tc.context.operation.id = operationId
  tc.context.operation.parentId = parentOperationId
  return tc

Questo codice contiene una funzione factory denominata NewTelemetryClient per creare un oggetto client di telemetria, impostare alcune delle proprietà e restituire l'oggetto al chiamante. Come si può notare, richiede un elemento padre operazione Id e un ID dell'operazione. Inizializza l'oggetto, ma si noti che se si desidera modificare l'Id operazione, sarà necessario eseguire l'operazione in blocco per Appunti il processo direttamente. Inoltre importante notare che il TelemetryClient costruttore accetta una chiave di strumentazione, che è reperibile nel pannello delle proprietà dell'istanza di Application Insights che si desidera utilizzare. Abbiamo abbiamo assegnato in modo statico alcuni valori che sono necessari per l'esempio, ma l'oggetto di contesto TelemetryClient ha molte proprietà che sono disponibili e gli oggetti figlio. Se è necessaria per inizializzare altri valori, questo sarebbe il luogo per eseguire l'operazione. Separare la funzione factory mantiene il disordine verso il basso e semplifica inoltre l'implementazione per gli sviluppatori di conversione del blocco appunti da un tipo di prototipo sandbox di codice a un tipo di processo enterprise di implementazione. 

Con la libreria aggiunta al cluster e il blocco note il programma di installazione definiti, è sufficiente aggiungere una linea all'inizio del blocco note processo per eseguire il programma di installazione e poi si crea un oggetto dati di telemetria starter. È necessario rilasciare automaticamente % eseguire comandi nella parte superiore del blocco note:

%run ./AppInsightsSetup

Nella cella successiva si sarà semplicemente creare una nuova istanza dell'oggetto TelemetryClient.

Figura 3 viene illustrato il codice dell'esempio stima abbiamo creato. Esistono vari aspetti da prendere nota del. In primo luogo, è in corso passando una serie di variabili nel blocco note che vengono inviati come parte dell'inizializzazione di processo, viene eseguita tramite l'oggetto dbutils.widgets fornito come parte dell'ambiente Databricks. Poiché è necessario un paio di ID per l'operazione padre e l'operazione discreto, abbiamo proseguo e selezionare gli e, se vuoti, creare e assegnare nuovo UUID. Assegnare gli ID arbitrari in questo caso è principalmente per renderlo più facile da eseguire in modo interattivo. Tuttavia, altri approcci è stato possibile da eseguire, ad esempio che incapsula il codice del blocco per Appunti il processo in una serie di funzioni e l'esecuzione di test, chiamando la funzione di padre con un ID specifico. Sia sufficientemente sono ideali per lavoro a questo scopo. L'ultima operazione assegniamo è un nome di operazione, alla fine dell'elenco di Application Insights come è possibile utilizzare per Vista e group by, come illustrato nel figura 4.

Codice di inizializzazione Notebook figura 3

baseRatingsFile = dbutils.widgets.get("baseRatingsFile")
newRatingsFile = dbutils.widgets.get("newRatingsFile")
trainOperationId = dbutils.widgets.get("trainOperationId")
parentOperationId = dbutils.widgets.get("parentOperationId")
maxIterations =  int(dbutils.widgets.get("maxIterations"))
numFolds = int(dbutils.widgets.get("numFolds"))
numUserRecommendations = int(
  dbutils.widgets.get("numUserRecommendations"))
predictionFilePath = dbutils.widgets.get("predictionFilePath")
if trainOperationId == "":
  trainOperationId = NewCorrelationId()
if parentOperationId == "":
  parentOperationId = NewCorrelationId()
#setup other needed variables
telemetryClient = NewTelemetryClient("PredictionExample",
  trainOperationId, parentOperationId)
telemetryClient.context.operation.name = "Train Model"

Esaminando figura 3, si noterà che il nome dell'operazione è stato assegnato il valore di Train Model. Figura 4 illustra in una griglia dei dati dopo che è stato scelto come meccanismo di raggruppamento per i dati. Eseguire più processi e assegnare i nomi delle operazioni diverse, si sarà in grado di visualizzare quelli visualizzati nella visualizzazione, nonché. Con queste opzioni per concludere posto, siamo in buono per instrumentare il codice di processo per l'acquisizione di eventi e metriche.

Nome dell'operazione nella figura 4 in Application Insights

La strumentazione codice Databricks processo

Si analizzerà un esempio che usa Application Insights per monitorare un processo di progettazione dati tipico in Databricks. In questo scenario, viene usata pubblicamente disponibili dati da Fannie Mae (bit.ly/2AhL5sS) e richiedere dati di origine file non elaborato sulle prestazioni del prestito singolo e prepararla per la segnalazione e analitica. Sono necessari diversi passaggi per preparare correttamente i dati. A ogni passaggio, si verrà acquisire le informazioni come numero di record e il tempo trascorso e registrare questi valori in Application Insights. Figura 5 illustra i passaggi più importanti del processo. È stato scelto di utilizzare i titoli nella parte superiore della figura 5 per identificare il nostro operazioni distinte.

Figura 5 dati di progettazione del flusso di processo

Inoltre, Dell ha creato un set di misurazioni con nomi simili (ad esempio, scrivere durata, lettura durata, conteggio Record) che verranno segnalate negli eventi denominati in modo diverso. Si tratterà importante l'analitica come Microsoft esaminerà metriche specifiche e quindi visualizzarli in base operazione o l'evento. Come illustrato figura 5, prima è l'inserimento di più file di dati, quindi consolidare e trasformarli e infine scrivere in due percorsi di destinazione. Il set di dati completamente preparato è persistente nell'archiviazione Blob a lungo termine e un sottoinsieme aggregato viene inviato su questo sistema RDBMS, Database SQL di Azure. Naturalmente, all'interno di ogni passaggio di alto livello esistono alcuni passaggi secondari. In particolare, si importano quattro file distinti, unirli in un singolo frame di dati di Spark e scrivere il set di dati non elaborati e consolidati nell'archiviazione Blob. I dati consolidati viene letto nuovamente all'esterno di archiviazione Blob in un nuovo frame di dati per la pulizia e di trasformazione. Per completare la trasformazione è subset il frame di dati (vale a dire, restringere rilevante solo alle colonne), rinominare le colonne con nomi significativi e sostituire i valori null nella colonna del nome di riferimento. Il formato finale dei dati è persistente nel formato di file Parquet. L'ultimo passaggio in questo esempio di rendere persistenti i dati a un Database SQL di Azure.

Per questo esempio di processo Databricks di Azure, sono state l'approccio notebook singolo con i passaggi programmati in celle di codice separato. Operazione di un unico elemento padre Id è impostato per ogni esecuzione del processo. Un'operazione (figlio) Id viene applicata a ogni operazione all'interno del processo e viene definito come queste operazioni di acquisizione, trasformazione e la persistenza. È rilevare gli eventi che si verificano per ogni operazione, la registrazione di timestamp, numero di record, la durata e altri parametri in Application Insights in fase di esecuzione processo.

Come nell'esempio precedente le stime, è aggiungere il pacchetto di Python "applicationinsights" al cluster, eseguire il blocco note il programma di installazione e creare una nuova istanza dell'oggetto TelemetryClient. Questa volta si sarà DataEngineeringExample istanza il nome e quindi impostare il nome dell'operazione iniziale di un'acquisizione, per preparare per la prima serie di passaggi per acquisire dati di origine:

telemetryClient = NewTelemetryClient(
  "DataEngineeringExample", operationId, parentOperationId)
telemetryClient.context.operation.name = "Acquisition"

Successivamente, abbiamo acquisire l'ora corrente e rilevare il primo evento di Application Insights, che ha avviato il processo di registrazione:

import datetime
jobStartTime = datetime.datetime.now()
jobStartTimeStr = str(jobStartTime)
telemetryClient.track_event('Start Job', { 'Start Time': jobStartTimeStr,
  'perfDataFilePath':perfDataFilePath, 'perfDataFileNamePrefix' :  
  perfDataFileNamePrefix, 'consolidatedDataPath':consolidatedDataPath, 
  'transformedFilePath' : transformedFilePath, 'perfDBConnectionString':
  perfDBConnectionString, 'perfDBTableName': perfDBTableName})
telemetryClient.flush()

Si tratta del codice per impostare il timestamp corrente come ora di inizio per il processo e archiviarla nel primo evento di Application Insights. È in primo luogo, importare Data/ora libreria Python per pratico funzioni di data e ora e quindi impostare jobStartTime variabile al timestamp corrente. Vale la pena notare che la firma per il track_event ([eventName], [{props}], [{misurazioni}]) metodo accetta i parametri per il nome dell'evento, dizionario delle proprietà e un dizionario di misurazioni. A tal fine, la variabile di timestamp deve essere serializzabile in JSON per includerlo nelle proprietà dell'evento di telemetria. In tal caso, è il cast dell'oggetto jobStartTime sotto forma di stringa e inserire il valore in un nuovo jobStartTimeStr variabile. Nel passaggio successivo, inviamo questo evento di telemetria iniziale con il metodo track_event, passando il nome di evento personalizzato ora di inizio insieme a diversi parametri che è selezionato per l'acquisizione di questo evento. Sono stati inclusi i parametri per vari percorsi di file e le stringhe di connessione che vengono fatto riferimento nel processo. Ad esempio, perfDataFilePath contiene il percorso dei file di dati di origine e perfDBConnectionString contiene la stringa di connessione per il Database SQL di Azure, in cui è necessario rendere persistenti alcuni dei dati. Si tratta di informazioni utili in tali casi in cui vediamo un record 0 connettersi o impostare un avviso; possiamo eseguire un rapido controllo di dati di telemetria dell'operazione correlata e verificare rapidamente il file di database e/o che vengano utilizzati.

Ora è possibile procedere attraverso le celle di comando del blocco note, aggiunta di codice di registrazione degli eventi simile all'interno di ogni passaggio, con poche modifiche rilevanti per i passaggi del processo interni. Poiché risulta spesso utile utilizzare i conteggi di record in un processo di decodifica di dati che assicuri volume di dati di monitoraggio delle prestazioni e utilizzo delle risorse, è stato aggiunto una misura Conteggio record per ogni evento rilevato.

Figura 6 mostra alcune trasformazioni di dati di base, seguite dall'evento di rilevamento per Application Insights. All'interno del blocco Try di gestione delle eccezioni, eseguiamo tre tipi di trasformazioni in una sola volta su perfTransformDF frame di dati. È il frame di dati, mantenendo solo un gruppo selezionato di colonne rilevanti e ignorare il resto di subset. È necessario sostituire i valori null nella colonna il nome con "Sconosciuto". E, poiché i nomi di colonna originali sono stati non significativi (ad esempio, "_C0", "_C1"), è rinominare il subset di colonne rilevante nomi significativi, ad esempio "loan_id" e "loan_age".

Figura 6 dati trasformazione-rilevamento eventi di codice

if notebookError == "":
  try:
    perfTransformedDF = perfTransformedDF['_c0','_c1','_C2','_C3','_C4', \
                                          '_C5','_C6','_C7','_C8','_C9', \
                                          '_C10','_C11','_C12','_C13'] \
      .fillna({'_C2':'UNKNOWN'}) \
      .withColumnRenamed("_C0", "loan_id") \
      .withColumnRenamed("_C1", "period") \
      .withColumnRenamed("_C2", "servicer_name") \
      .withColumnRenamed("_C3", "new_int_rt") \
      .withColumnRenamed("_C4", "act_endg_upb") \
      .withColumnRenamed("_C5", "loan_age") \
      .withColumnRenamed("_C6", "mths_remng") \
      .withColumnRenamed("_C7", "aj_mths_remng") \
      .withColumnRenamed("_C8", "dt_matr") \
      .withColumnRenamed("_C9", "cd_msa") \
      .withColumnRenamed("_C10", "delq_sts") \
      .withColumnRenamed("_C11", "flag_mod") \
      .withColumnRenamed("_C12", "cd_zero_bal") \
      .withColumnRenamed("_C13", "dt_zero_bal")
    print("nulls replaced")
    end = datetime.datetime.now()
    rowCount = perfTransformedDF.count()
    duration = round((end - start).total_seconds(), 1)
    telemetryClient.track_event('Transformation Complete', {}, \
                                { 'Records Transformed': rowCount, \
                                 'Transformation Duration':duration })
    telemetryClient.flush()
  except Exception as e:
    notebookError = str(e)
    telemetryClient.track_exception(e,{"action":"column transform"},{})
else:
  print("command skipped due to previous error")

Dopo aver complete le trasformazioni, abbiamo acquisire il timestamp corrente nella variabile "end" come l'ora di questo passaggio è stata; contare le righe nel frame di dati; e calcolare la durata del passaggio in base alle ore di inizio e fine. Si invia la telemetria ad Application Insights con il metodo telemetryClient.track_event usando che il nome dell'evento "Trasformazione completo" e si includono le misurazioni per record trasformati e la durata di trasformazione.

Aggiungiamo alcune eccezioni molto semplice in notebook esclusivamente per illustrare rilevamento le eccezioni con Application Insights, e. Si noti all'interno del, ad eccezione di blocco in figura 6 che se si intercetta un'eccezione, verrà chiamato il metodo track_exception. L'eccezione viene passata come primo parametro e i parametri successivi sono gli stessi tipi come track_event, consente di registrare le informazioni per l'evento che presto. Una nota importante da sottolineare non è che sono attualmente alcuna semantica di gestione delle eccezioni per sql inline. In tal caso, potrebbe essere preferibile ignorare magics quale sql % per i processi di produzione finché il supporto per la gestione delle eccezioni viene aggiunto.

Gli altri passaggi nel processo decodifica dei dati, incluse operazioni per l'acquisizione e la persistenza, seguono il modello illustrato nel codice di trasformazione per l'invio di eventi di telemetria con misure personalizzate ad Application Insights.

Configurazione di Analitica e avvisi

Con il codice in grado di inviare i dati di telemetria, è attiva per la configurazione di Application Insights per creare dashboard in tempo reale, esaminare eventi e i dettagli degli eventi correlati e impostare avvisi per informare ed eventualmente eseguire l'azione in base al trigger di evento.

Figura 7 illustra alcuni grafici che abbiamo configurato tramite il pannello Esplora metriche e il pannello metriche (anteprima) in Application Insights e quindi aggiunto al Dashboard portale di Azure.

Figura 7 Application Insights grafici nel Dashboard di Azure

Prendere nota dei due a destra quartili. Alto a destra visualizza una griglia di durate raggruppati in base al nome dell'operazione che viene segnalato la telemetria in quando è stato aggiunto le chiamate di rilevamento. Nell'angolo inferiore destro mostra una misura Conteggio record raggruppata per il nome dell'evento che è stato usato. Assicurarsi sufficientemente "Persistenti per database SQL" è molto inferiore rispetto alle altre, perché si è verificato l'evento che ha scritto solo un subset di piccole dimensioni, filtrato dei dati in Database SQL di Azure. La scelta di raggruppamenti di operazione, i nomi delle operazioni e i nomi degli eventi è una parte importante della pianificazione che paga off a questo punto si ottiene per visualizzare e creare report sui dati in modo appropriato per il modo in cui si pensa delle operazioni.

Stimare i due quartili a sinistra in figura 7 Mostra i grafici creati con le metriche (anteprima), che ha una configurazione nice dell'interfaccia utente, nonché alcune funzionalità aggiuntive per suddividere le misure in base a un'altra proprietà. In alto a sinistra è possibile visualizzare il numero di record, ma è stato suddiviso in modo che il problema viene segnalato dal nome dell'evento, fornire un grafico e i dati per il functoid Conteggio record per diversi eventi. Qui è in corso il confronto tra i conteggi di record eseguiti quando i dati di origine è stata letta di conteggi di record eseguiti in un secondo momento quando è stati caricati dati consolidati in un frame di dati. Si tratta di una caratteristica importante poiché conteggio Record potrebbe essere una misura molto comune nei nostri operazione padre, ma si desidera visualizzarlo in ogni operazione o l'evento.

Se viene visualizzato qualcosa in uno dei grafici operativi che richiede una ricerca, è possibile cercare tramite tutti i dati di telemetria. Figura 8 vengono illustrati i risultati di una ricerca e un grafico che mostra un numero di occorrenze nel corso del tempo nel riquadro sinistro. Nel riquadro di destra è possibile esaminare tutte le informazioni registrate nell'evento. Richiamare il track_event ([nome], [proprietà], [misurazioni]) firma. È stato effettuato il pull dei dettagli di una persistenza all'evento di database di SQL Server in cui è possibile visualizzare le proprietà personalizzate nella parte superiore. Al centro, con l'etichetta dati personalizzati, è dove è possibile trovare le misure personalizzate che sono state inviate con i dati di telemetria. Nell'angolo inferiore destro sono tutti gli elementi correlati in cui è possibile passare a tutti gli eventi che appartengono all'operazione o all'operazione padre. Inoltre, è presente una riga nella parte inferiore per visualizzare tutti i dati di telemetria disponibili al momento dell'evento. Se è stata normalizzati in Application Insights per il monitoraggio di runtime, questo è un ottimo strumento per la comprensione dello stato complessivo del sistema e il contesto operativo di un evento. Durata o dovere comprendere cosa sta accadendo su vasta scala potrebbe spiegare quando disattivati conteggi di record è sghembe.

Figura 8 evento ricerca e dettagli

L'ultima operazione desiderata per coprire per Application Insights è la possibilità di impostare un avviso. In figura 9 è possibile vedere parte della configurazione dell'avviso. Come gli altri elementi è stato esaminato, le informazioni personalizzate che abbiamo inviato negli eventi viene visualizzato qui a Microsoft per scegliere come criterio per gli avvisi.

Figura 9 impostazione di un avviso nella metrica

Come prevedibile, l'avviso può inviare un messaggio di posta elettronica. Tuttavia, inoltre possibile chiamare un WebHook, che consente di eseguire altre azioni che potrebbero desiderato in modo facile e comodo. Funzioni di Azure è perfetto adatta per il programma di installazione e consente di creare qualsiasi azione personalizzata desiderato. Più interessante, Application Insights è direttamente integrato con la logica app. In questo modo la capacità nativa integrare e orchestrano azioni in una vasta gamma di integrazioni e Microsoft Azure. Di conseguenza, un avviso di Application Insights è stato possibile avvertire gli utenti durante l'avvio eseguire azioni di compensazione e/o correttive tramite orchestrazione App per la logica, incluse le azioni e integrazioni con i sistemi a monte e a valle.

Conclusioni

Si desidera assicurarsi che si evidenzia il bit della chiave di informazioni. Application Insights non è una soluzione Analitica di Log. Si integra con Azure Log Analitica, che fornisce l'analisi post hoc e alla conservazione dei log a lungo termine. Application Insights è per il monitoraggio e analitica delle operazioni di runtime, offrendo informazioni, insights e avvisi sulle novità relative a questo punto. Integrazione diretta con altri servizi di Azure e ampia disponibilità di platform SDK rende un adattamento per rendere operative le i processi di Azure Databricks nice. Di conseguenza, il monitoraggio per tali processi non viene eseguito in un silo, ma piuttosto all'interno del contesto dell'architettura della soluzione completa.

Joseph Fultz è architetti di soluzioni cloud Microsoft. Lavora con i clienti Microsoft lo sviluppo di architetture per la risoluzione dei problemi aziendali lev-eraging Microsoft Azure. In precedenza, era responsabile per lo sviluppo e di programma del margine lordo condivisione car Fultz (mavendrive.com). Pulsante con quest'ultimo su Twitter: @JosephRFultz o tramite posta elettronica al jofultz@microsoft.com.

Ryan Murphy è gli architetti di soluzioni che vivono in Saint Louis, MO. Giorgio ha compiliamo e innovazioni con i dati per circa 20 anni, tra cui notevole impegno in settori agricoltura e giochi. Attualmente, Murphy aiuta alcune organizzazioni più grandi al mondo modernizzare azienda con soluzioni di data basato sul Cloud di Microsoft Azure. Seguire quest'ultimo su Twitter: @murphrp.