Monitorare Funzioni di Azure con Application Insights di Monitoraggio di Azure

  • Articolo

Funzioni di Azure offre l'integrazione predefinita con Application Insights per monitorare le funzioni. Per i linguaggi diversi da .NET e .NET Core, sono necessari altri ruoli di lavoro/estensioni specifici del linguaggio per ottenere i vantaggi completi della traccia distribuita.

Application Insights raccoglie i dati di log, prestazioni e errori e rileva automaticamente le anomalie delle prestazioni. Application Insights include potenti strumenti di analisi che consentono di diagnosticare i problemi e comprendere come vengono usate le funzioni. Quando si ha visibilità nei dati dell'applicazione, è possibile migliorare continuamente le prestazioni e l'usabilità. È anche possibile usare Application Insights durante lo sviluppo di un progetto locale di app per le funzioni.

La strumentazione di Application Insights necessaria è incorporata in Funzioni di Azure. È sufficiente un stringa di connessione valido per connettere l'app per le funzioni a una risorsa di Application Insights. Il stringa di connessione deve essere aggiunto alle impostazioni dell'applicazione quando la risorsa dell'app per le funzioni viene creata in Azure. Se l'app per le funzioni non ha già un stringa di connessione, è possibile impostarla manualmente. Per altre informazioni, vedere Monitorare le esecuzioni in stringhe di Funzioni di Azure e Connessione ion.

Nota

Il 31 marzo 2025, il supporto per l'inserimento delle chiavi di strumentazione terminerà. L'inserimento di chiavi di strumentazione continuerà a funzionare, ma non forniamo più aggiornamenti o supporto per la funzionalità. Passare alle stringa di connessione per sfruttare le nuove funzionalità.

Per un elenco degli scenari di strumentazione automatica supportati, vedere Ambienti, lingue e provider di risorse supportati.

Traccia distribuita per applicazioni Java

Nota

Questa funzionalità è stata usata per avere un'implicazione di avvio a freddo da 8 a 9 secondi, che è stata ridotta a meno di 1 secondo. Se si è stati early adopter di questa funzionalità (ad esempio, prima di febbraio 2023), esaminare la sezione "Risoluzione dei problemi" per eseguire l'aggiornamento alla versione corrente e trarre vantaggio dalla nuova avvio più veloce.

Per visualizzare più dati dalle applicazioni di Funzioni di Azure basate su Java rispetto a quelle raccolte per impostazione predefinita, abilitare l'agente Java 3.x di Application Insights. Questo agente consente ad Application Insights di raccogliere e correlare automaticamente dipendenze, log e metriche dalle librerie più diffuse e dagli SDK (Software Development Kit) di Azure. Questi dati di telemetria si aggiungono ai dati di telemetria delle richieste già acquisiti da Funzioni.

Usando la mappa delle applicazioni e una visualizzazione più completa delle transazioni end-to-end, è possibile diagnosticare meglio i problemi. Si ha una visione topologica del modo in cui i sistemi interagiscono con i dati sulle prestazioni medie e sulle percentuali di errore. Sono disponibili anche altri dati per la diagnostica end-to-end. È possibile usare la mappa dell'applicazione per trovare facilmente la causa radice dei problemi di affidabilità e dei colli di bottiglia delle prestazioni per ogni richiesta.

Per casi d'uso più avanzati, è possibile modificare i dati di telemetria aggiungendo intervalli, aggiornando lo stato dell'intervallo e aggiungendo attributi span. È anche possibile inviare dati di telemetria personalizzati usando le API standard.

Abilitare la traccia distribuita per le app per le funzioni Java

Nel riquadro Panoramica dell'app per le funzioni passare ad Application Insights. In Livello di raccolta selezionare Consigliato.

Screenshot che mostra come abilitare l'agente Java di AppInsights.

Risoluzione dei problemi

Le funzioni Java potrebbero avere tempi di avvio lenti se questa funzionalità è stata adottata prima di febbraio 2023. Nel riquadro Panoramica dell'app per le funzioni passare a Configurazione nel menu di spostamento sul lato sinistro. Selezionare quindi Impostazioni applicazione e seguire questa procedura per risolvere il problema.

Windows

  1. Verificare se esistono le impostazioni seguenti e rimuoverle:

    XDT_MicrosoftApplicationInsights_Java -> 1
ApplicationInsightsAgent_EXTENSION_VERSION -> ~2

  2. Abilitare la versione più recente aggiungendo questa impostazione:

    APPLICATIONINSIGHTS_ENABLE_AGENT: true

Linux dedicato/Premium

  1. Verificare se esistono le impostazioni seguenti e rimuoverle:

    ApplicationInsightsAgent_EXTENSION_VERSION -> ~3

  2. Abilitare la versione più recente aggiungendo questa impostazione:

    APPLICATIONINSIGHTS_ENABLE_AGENT: true

Nota

Se la versione più recente dell'agente Java di Application Insights non è disponibile in Funzioni di Azure, caricarla manualmente seguendo queste istruzioni.

Testare la connettività tra l'host dell'applicazione e il servizio di inserimento

Gli SDK e gli agenti di Application Insights inviano dati di telemetria per essere inseriti come chiamate REST agli endpoint di inserimento. È possibile testare la connettività dal server Web o dal computer host dell'applicazione agli endpoint del servizio di inserimento usando client REST non elaborati da PowerShell o comandi curl. Vedere Risolvere i problemi di telemetria delle applicazioni mancanti in Application Insights di Monitoraggio di Azure.

Log duplicati

Se si usa log4j o logback per la registrazione della console, la traccia distribuita per Funzioni Java crea log duplicati. Questi log duplicati vengono quindi inviati ad Application Insights. Per evitare questo comportamento, usare le soluzioni alternative seguenti.

Log4j

Aggiungere il filtro seguente al log4j.xml:

<Filters>
  <ThresholdFilter level="ALL" onMatch="DENY" onMismatch="NEUTRAL"/>
</Filters>

Esempio:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
  <Appenders>
    <Console name="Console" target="SYSTEM_OUT">
      <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
      <Filters>
        <ThresholdFilter level="ALL" onMatch="DENY" onMismatch="NEUTRAL"/>
      </Filters>
    </Console>
  </Appenders>
  <Loggers>
    <Root level="error">
      <AppenderRef ref="Console"/>
    </Root>
  </Loggers>
</Configuration>
Logback

Aggiungere il filtro seguente al logback.xml:

<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
  <level>OFF</level>
</filter>

Esempio:

<configuration debug="true">
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <!-- encoders are  by default assigned the type
         ch.qos.logback.classic.encoder.PatternLayoutEncoder -->
    <encoder>
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} -%kvp- %msg%n</pattern>
      <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
        <level>OFF</level>
      </filter>  
    </encoder>
  </appender>
  <root level="debug">
    <appender-ref ref="STDOUT" />
  </root>
</configuration>

Traccia distribuita per le app per le funzioni di Node.js

Per visualizzare più dati dalle applicazioni Node Funzioni di Azure rispetto a quelle raccolte per impostazione predefinita, instrumentare la funzione usando la distribuzione OpenTelemetry di Monitoraggio di Azure.

Traccia distribuita per le app per le funzioni Python

Per raccogliere dati di telemetria da servizi come Richieste, urllib3, httpx, PsycoPG2 e altro ancora, usare la distribuzione OpenTelemetry di Monitoraggio di Azure. Le richieste in ingresso rilevate provenienti dall'applicazione Python ospitata in Funzioni di Azure non verranno correlate automaticamente con i dati di telemetria rilevati al suo interno. È possibile ottenere manualmente la correlazione di traccia estraendo traceContext direttamente come illustrato di seguito:

import azure.functions as func

from azure.monitor.opentelemetry import configure_azure_monitor
from opentelemetry import trace
from opentelemetry.propagate import extract

# Configure Azure monitor collection telemetry pipeline
configure_azure_monitor()

def main(req: func.HttpRequest, context) -> func.HttpResponse:
   ...
   # Store current TraceContext in dictionary format
   carrier = {
      "traceparent": context.trace_context.Traceparent,
      "tracestate": context.trace_context.Tracestate,
   }
   tracer = trace.get_tracer(__name__)
   # Start a span using the current context
   with tracer.start_as_current_span(
      "http_trigger_span",
      context=extract(carrier),
   ):
      ...

Passaggi successivi