Monitorare l'elaborazione di eventi serverless

Questo articolo fornisce indicazioni sul monitoraggio delle architetture basate su eventi serverless .

Il monitoraggio fornisce informazioni dettagliate sul comportamento e sull'integrità dei sistemi. Consente di creare una visualizzazione olistica dell'ambiente, recuperare tendenze storiche, correlare fattori diversi e misurare le variazioni delle prestazioni, del consumo o della frequenza degli errori. È possibile usare il monitoraggio per definire gli avvisi quando si verificano condizioni che potrebbero influire sulla qualità del servizio o quando si verificano condizioni di particolare interesse per l'ambiente specifico.

Questo articolo illustra l'uso di Monitoraggio di Azure per monitorare un'applicazione serverless compilata usando Hub eventi e Funzioni di Azure. Vengono illustrate le metriche utili da monitorare, viene descritto come eseguire l'integrazione con Application Insights e acquisire metriche personalizzate e vengono forniti esempi di codice.

Presupposti

Questo articolo presuppone che sia disponibile un'architettura simile a quella descritta nell'architettura di riferimento per l'elaborazione di eventi serverless. Fondamentalmente:

• Gli eventi arrivano alla Hub eventi di Azure.
• Viene attivata un'app per le funzioni per gestire l'evento.
• Monitoraggio di Azure è disponibile per l'uso con l'architettura.

Metriche da Monitoraggio di Azure

Prima di iniziare a formulare informazioni utili sull'architettura, è necessario decidere quali metriche saranno necessarie. Ogni risorsa esegue attività diverse e a sua volta genera metriche diverse.

Queste metriche dell'hub eventi saranno di interesse per acquisire informazioni utili:

• Richieste in ingresso
• Richieste in uscita
• Richieste limitate
• Richieste riuscite
• Messaggi in arrivo
• Messaggi in uscita
• Messaggi acquisiti
• Byte in ingresso
• Byte in uscita
• Byte acquisiti
• Errori utente

Analogamente, queste metriche di Funzioni di Azure saranno di interesse per acquisire informazioni utili:

• Numero di esecuzioni di funzioni
• Connessioni
• Dati in
• Dati in uscita
• Errori server HTTP
• Requests
• Richieste nella coda dell'applicazione
• Tempo di risposta

Uso della registrazione diagnostica per acquisire informazioni dettagliate

Quando vengono analizzate insieme, è possibile usare le metriche precedenti per formulare e acquisire le informazioni dettagliate seguenti:

• Frequenza delle richieste elaborate da Hub eventi
• Frequenza delle richieste elaborate da Funzioni di Azure
• Velocità effettiva totale dell'hub eventi
• Errori utente
• Durata del Funzioni di Azure
• Latenza end-to-end
• Latenza in ogni fase
• Numero di messaggi persi
• Numero di messaggi elaborati più volte

Per assicurarsi che Hub eventi acquisisca le metriche necessarie, è necessario prima abilitare i log di diagnostica (che sono disabilitati per impostazione predefinita). È quindi necessario selezionare i log desiderati e configurare l'area di lavoro Log Analytics corretta come destinazione.

Le categorie di log e metriche a cui si è interessati sono:

• OperationalLogs
• AutoScaleLogs
• KafkaCoordinatorLogs (per carichi di lavoro Apache Kafka)
• KafkaUserErrorLogs (per carichi di lavoro Apache Kafka)
• EventHubVNetConnectionEvent
• AllMetrics

La documentazione di Azure fornisce istruzioni su come configurare i log di diagnostica per un hub eventi di Azure. Lo screenshot seguente mostra un pannello di configurazione delle impostazioni di diagnostica di esempio con le categorie di log e metriche corrette selezionate e un'area di lavoro Log Analytics impostata come destinazione. Se viene usato un sistema esterno per analizzare i log, è possibile usare l'opzione Stream to an event hub (Trasmettere a un hub eventi ).

Nota

Per usare la diagnostica dei log per acquisire informazioni dettagliate, è necessario creare hub eventi in spazi dei nomi diversi. Questo è dovuto a un vincolo in Azure.

L'hub eventi impostato in uno spazio dei nomi di Hub eventi specificato è rappresentato nelle metriche di Monitoraggio di Azure in una dimensione denominata EntityName. Nella portale di Azure i dati per un hub eventi specifico possono essere normalmente visualizzati in tale istanza di Monitoraggio di Azure. Tuttavia, quando i dati delle metriche vengono indirizzati alla diagnostica del log, attualmente non è possibile visualizzare i dati per hub eventi filtrando in base alla EntityName dimensione.

Come soluzione alternativa, la creazione di hub eventi in spazi dei nomi diversi consente di individuare le metriche per un hub specifico.

Utilizzo di Application Insights

È possibile abilitare Application Insights per acquisire metriche e dati di telemetria personalizzati da Funzioni di Azure. In questo modo è possibile definire analisi adatte ai propri scopi, offrendo un altro modo per ottenere informazioni importanti per lo scenario di elaborazione di eventi serverless.

Questo screenshot mostra un elenco di esempio di metriche e dati di telemetria personalizzati in Application Insights:

Metriche personalizzate predefinite

In Application Insights le metriche personalizzate per Funzioni di Azure vengono archiviate nella customMetrics tabella. Include i valori seguenti, esteso su una sequenza temporale per istanze di funzione diverse:

• AvgDurationMs
• MaxDurationMs
• MinDurationMs
• Successes
• Failures
• SuccessRate
• Count

Queste metriche possono essere usate per calcolare in modo efficiente le medie aggregate tra più istanze di funzione richiamate in un'esecuzione.

Questo screenshot mostra l'aspetto di queste metriche personalizzate predefinite quando vengono visualizzate in Application Insights:

Messaggi personalizzati

I messaggi personalizzati registrati nel codice della funzione di Azure (usando ) ILoggervengono ottenuti dalla tabella di Application Insights traces .

La traces tabella presenta le proprietà importanti seguenti (tra le altre):

• timestamp
• cloud_RoleInstance
• operation_Id
• operation_Name
• message

Di seguito è riportato un esempio dell'aspetto di un messaggio personalizzato nell'interfaccia di Application Insights:

Se il messaggio dell'hub eventi in arrivo o EventData[] viene registrato come parte di questo messaggio personalizzato ILogger , viene reso disponibile anche in Application Insights. Questo può essere molto utile.

Per lo scenario di elaborazione degli eventi serverless, viene registrato il corpo del messaggio serializzato JSON ricevuto dall'hub eventi. In questo modo è possibile acquisire la matrice di byte non elaborata, insieme SystemProperties ad esempio x-opt-sequence-number, x-opt-offsete x-opt-enqueued-time. Per determinare quando ogni messaggio è stato ricevuto dall'hub eventi, viene usata la x-opt-enqueued-time proprietà .

Query di esempio:

traces
| where timestamp between(min_t .. max_t)
| where message contains "Body"
| extend m = parse_json(message))
| project timestamp = todatetime(m.SystemProperties.["x-opt-enqueued-time"])

La query di esempio restituisce un messaggio simile al risultato di esempio seguente, che viene registrato per impostazione predefinita in Application Insights. Le proprietà di Trigger Details possono essere usate per individuare e acquisire informazioni aggiuntive sui messaggi ricevuti per PartitionId, Offsete SequenceNumber.

Risultato di esempio della query di esempio:

"message": Trigger Details: PartitionId: 26, Offset: 17194119200, EnqueueTimeUtc: 2020-11-03T02:14:01.7740000Z, SequenceNumber: 843572, Count: 10,

Avviso

La libreria per Funzioni Java di Azure presenta attualmente un problema che impedisce l'accesso PartitionID a e quando PartitionContext si usa EventHubTrigger. Per altre informazioni, vedere questo report sui problemi di GitHub.

Rilevamento del flusso dei messaggi tramite un ID transazione con Application Insights

In Application Insights è possibile visualizzare tutti i dati di telemetria correlati a una determinata transazione eseguendo una query di ricerca transazioni sul valore della Operation Id transazione. Ciò può essere particolarmente utile per acquisire i valori percentili dei tempi medi per i messaggi quando la transazione passa attraverso la pipeline del flusso di eventi.

Lo screenshot seguente mostra una ricerca transazionale di esempio nell'interfaccia di Application Insights. L'elemento desiderato Operation ID viene immesso nel campo della query, identificato con un'icona a forma di lente di ingrandimento (e mostrata qui in una casella rossa). Nella parte inferiore del riquadro principale la Results scheda mostra gli eventi corrispondenti in ordine sequenziale. In ogni voce di evento il Operation ID valore è evidenziato in blu scuro per facilitare la verifica.

Una query generata per un ID operazione specifico sarà simile alla seguente. Si noti che il Operation ID GUID viene specificato nella clausola della where * has terza riga. Questo esempio restringe ulteriormente la query tra due diversi datetimes.

union isfuzzy=true availabilityResults, requests, exceptions, pageViews, traces, customEvents, dependencies
| where timestamp > datetime("2020-10-09T06:58:40.024Z") and timestamp < datetime("2020-11-11T06:58:40.024Z")
| where * has "1c8c9d7073a00e4bbdcc8f2e6570e46"
| order by timestamp desc
| take 100

Di seguito è riportato uno screenshot dell'aspetto della query e dei risultati corrispondenti nell'interfaccia di Application Insights:

Acquisire metriche personalizzate da Funzioni di Azure

Funzioni .NET

La registrazione strutturata viene usata nelle funzioni di Azure .NET per acquisire dimensioni personalizzate nella tabella delle tracce di Application Insights. Queste dimensioni personalizzate possono quindi essere usate per l'esecuzione di query sui dati.

Di seguito è riportato un esempio dell'istruzione di log in .NET TransformingFunction:

log.LogInformation("TransformingFunction: Processed sensorDataJson={sensorDataJson}, " +
    "partitionId={partitionId}, offset={offset} at {enqueuedTimeUtc}, " +
    "inputEH_enqueuedTime={inputEH_enqueuedTime}, processedTime={processedTime}, " +
    "transformingLatencyInMs={transformingLatencyInMs}, processingLatencyInMs={processingLatencyInMs}",
    sensorDataJson,
    partitionId,
    offset,
    enqueuedTimeUtc,
    inputEH_enqueuedTime,
    processedTime,
    transformingLatency,
    processingLatency);

I log risultanti creati in Application Insights contengono i parametri precedenti come dimensioni personalizzate, come illustrato in questo screenshot:

Questi log possono essere sottoposti a query come indicato di seguito:

traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name == "{Function_Name}"
| where message has "{Function_Name}: Processed"
| project timestamp = todatetime(customDimensions.prop__enqueuedTimeUtc)

Nota

Per assicurarsi di non influire sulle prestazioni in questi test, sono state attivate le impostazioni di campionamento dei log delle funzioni di Azure per Application Insights usando il host.json file, come illustrato di seguito. Ciò significa che tutte le statistiche acquisite dalla registrazione vengono considerate valori medi e non conteggi effettivi.

Esempio di host.json:

"logging": {
    "applicationInsights": {
        "samplingExcludedTypes": "Request",
        "samplingSettings": {
            "isEnabled": true
        }
    }
}

Funzioni Java

Attualmente, la registrazione strutturata non è supportata nelle funzioni java di Azure per l'acquisizione di dimensioni personalizzate nella tabella delle tracce di Application Insights.

Di seguito è riportato un esempio dell'istruzione di log in Java TransformingFunction:

LoggingUtilities.logSuccessInfo(
    context.getLogger(), 
    "TransformingFunction", 
    "SuccessInfo", 
    offset, 
    processedTimeString, 
    dateformatter.format(enqueuedTime), 
    transformingLatency
);

I log risultanti creati in Application Insights contengono i parametri precedenti nel messaggio, come illustrato di seguito:

Questi log possono essere sottoposti a query come indicato di seguito:

traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name in ("{Function name}") and message contains "SuccessInfo"
| project timestamp = todatetime(tostring(parse_json(message).enqueuedTime))

Nota

Per assicurarsi di non influire sulle prestazioni in questi test, sono state attivate le impostazioni di campionamento dei log delle funzioni di Azure per Application Insights usando il host.json file, come illustrato di seguito. Ciò significa che tutte le statistiche acquisite dalla registrazione vengono considerate valori medi e non conteggi effettivi.

Esempio di host.json:

"logging": {
    "applicationInsights": {
        "samplingExcludedTypes": "Request",
        "samplingSettings": {
            "isEnabled": true
        }
    }
}

Autori di contributi

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai collaboratori seguenti.

Autore principale:

• Rajasa Savant | Senior Software Engineer

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Risorse correlate

• L'elaborazione di eventi serverless è un'architettura di riferimento che descrive in dettaglio un'architettura tipica di questo tipo, con esempi di codice e considerazioni importanti.
• La de-batching e il filtro nell'elaborazione di eventi serverless con Hub eventi descrive in modo più dettagliato il funzionamento di queste parti dell'architettura di riferimento.
• Lo scenario di collegamento privato nell'elaborazione del flusso di eventi è un'idea di soluzione per implementare un'architettura simile in una rete virtuale (VNet) con endpoint privati, al fine di migliorare la sicurezza.
• Azure Kubernetes nell'elaborazione del flusso di eventi descrive una variante di un'architettura basata su eventi serverless in esecuzione in Azure Kubernetes con scalabilità KEDA.