View a markdown version of this page

Risoluzione dei problemi relativi alle istanze gestite Lambda - AWS Lambda
Problemi di limitazione e scalabilitàProblemi di concorrenzaProblemi di prestazioniProblemi con i fornitori di capacitàProblemi di monitoraggio e osservabilitàOttenere ulteriore assistenzaFasi successive

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risoluzione dei problemi relativi alle istanze gestite Lambda

Problemi di limitazione e scalabilità

Limitazione occasionale

Problema: si verificano errori di limitazione (HTTP 429) durante le normali operazioni.

Causa: le istanze gestite da Lambda potrebbero rifiutare nuove invocazioni per proteggere le invocazioni già in corso. Se i tuoi ambienti di esecuzione hanno un utilizzo costantemente elevato, le nuove chiamate potrebbero essere limitate.

Soluzione::

  • Monitora le metriche di scalabilità: esamina il grafico Throttle Reasons per comprendere il motivo delle limitazioni e dei problemi di scalabilità della capacità. Nel seguente esempio, un aumento della CPU causa rallentamenti.

  • Verifica la configurazione delle funzioni: assicurati che la memoria funzionale e le impostazioni della vCPU supportino le esecuzioni simultanee multiple. Aumentate la memoria funzionale o l'allocazione della vCPU, se necessario. Se ExecutionEnvironmentVCPUUtilization è alto, prova ad aggiungere più vCPU per funzione.

    aws lambda update-function \
  --function-name my-function \
  ...
  --memory-size 8192

    Se ExecutionEnvironmentMemoryUtilization è alto, prova ad aggiungere più memoria per vCPU:

    aws lambda update-function \
  --function-name my-function \
  --capacity-provider-config '{
    "LambdaManagedInstancesCapacityProviderConfig": {
      "ExecutionEnvironmentMemoryGiBPerVCpu": 4.0
    }
  }'

Accelera durante lo scale-up

Problema: si verificano errori di limitazione (HTTP 429) quando il traffico aumenta rapidamente.

Causa: le istanze gestite Lambda sono scalabili in modo asincrono in base all'utilizzo delle risorse della CPU e alla saturazione di più concorrenti. Se il traffico raddoppia più che in 5 minuti, potresti riscontrare dei rallentamenti man mano che Lambda aumenta le istanze e gli ambienti di esecuzione per soddisfare la domanda.

Soluzioni:

  • Modifica l'utilizzo delle risorse target: se il carico di lavoro ha modelli di traffico prevedibili, imposta un utilizzo target inferiore per mantenere un margine aggiuntivo per i picchi di traffico.

    aws lambda create-capacity-provider \
  --name my-capacity-provider \
  ...
  --capacity-provider-scaling-config '{
    "ScalingMode": "Manual",
    "ScalingPolicies": [
      {
        "PredefinedMetricType": "LambdaCapacityProviderAverageCPUUtilization",
        "TargetValue": 30.0
      }
    ]
  }'

  • Pre-warm capacità: per aumentare il traffico pianificato, utilizza l'API per preriscaldare la PutFunctionScalingConfig capacità aggiuntiva.

    aws lambda put-function-scaling-config \
  --function-name my-function \
  --qualifier 1 \
  --function-scaling-config '{
    "MinExecutionEnvironments": 100
  }'

Scalabilità lenta

Problema: le istanze richiedono molto tempo per essere ridimensionate dopo la diminuzione del traffico.

Causa: le istanze gestite Lambda si riducono gradualmente per mantenere la disponibilità ed evitare rapide modifiche della capacità che potrebbero influire sulle prestazioni.

Soluzione::

Questo è il comportamento previsto. Lambda ridimensiona le istanze in modo conservativo per garantire la stabilità. Monitora le tue CloudWatch metriche per tenere traccia del numero di istanze in esecuzione.

Problemi di concorrenza

Ambienti di esecuzione con basse limitazioni all'esperienza di concorrenza

Problema: le tue funzioni subiscono limitazioni nonostante la capacità disponibile.

Causa: gli ambienti di esecuzione con una concorrenza massima molto bassa potrebbero avere difficoltà a scalare in modo efficace. Le istanze gestite Lambda sono progettate per applicazioni con più concorrenti.

Soluzioni:

  • Aumenta la concorrenza massima: se le chiamate di funzione utilizzano pochissima CPU, aumenta l'impostazione di concorrenza massima fino a 64 per vCPU.

    aws lambda update-function \
  --function-name ordering-api-backend \
  --capacity-provider-config '{
    "LambdaManagedInstancesCapacityProviderConfig": {
      "PerExecutionEnvironmentMaxConcurrency": 32
    }
  }'

  • Ottimizza il codice funzione: rivedi il codice della funzione per ridurre il consumo di CPU per chiamata, consentendo una maggiore concorrenza.

  • Regola la memoria della funzione e la vCPU: assicurati che la tua funzione disponga di risorse sufficienti per gestire più chiamate simultanee.

Problemi di sicurezza dei thread (runtime Java)

Problema: la funzione Java produce risultati errati o presenta condizioni di gara sotto carico.

Causa: più thread eseguono il metodo handler contemporaneamente e lo stato condiviso non è thread-safe.

Soluzione::

  • Usa AtomicInteger or per i contatori invece dei tipi AtomicLong primitivi

  • Sostituisci con HashMap ConcurrentHashMap

  • Collections.synchronizedList()Usare per avvolgere ArrayList

  • Usare ThreadLocal per uno stato specifico della richiesta

  • Accedi agli ID di traccia dall'oggetto Lambda Context, non dalle variabili di ambiente

Per una guida dettagliata, consulta la documentazione di Java runtime for Lambda Managed Instances.

Problemi di isolamento dello stato (runtime) Node.js

Problema: la Node.js funzione restituisce dati provenienti da diverse richieste o presenta un danneggiamento dei dati.

Causa: le variabili globali sono condivise tra chiamate simultanee sullo stesso thread di lavoro. Quando le operazioni asincrone cedono il controllo, altre chiamate possono modificare lo stato condiviso.

Soluzione::

  • Installazione e utilizzo @aws/lambda-invoke-store per tutti gli stati specifici della richiesta

  • Sostituisci le variabili globali con e InvokeStore.set() InvokeStore.get()

  • Usa nomi di file univoci negli /tmp ID delle richieste

  • Accedi agli ID di traccia utilizzando InvokeStore.getXRayTraceId() al posto delle variabili di ambiente

Per una guida dettagliata, consulta la documentazione relativa al Node.js runtime per Lambda Managed Instances.

Conflitti tra file (runtime Python)

Problema: la tua funzione Python legge dati errati dai file in. /tmp

Causa: più processi condividono la /tmp directory. Le scritture simultanee sullo stesso file possono causare il danneggiamento dei dati.

Soluzione::

  • Utilizza nomi di file univoci con ID di richiesta: /tmp/request_{context.request_id}.txt

  • Usa il blocco dei file con fcntl.flock() per i file condivisi

  • Pulisci i file temporanei con os.remove() After Use

Per una guida dettagliata, consulta la documentazione di Python runtime for Lambda Managed Instances.

Problemi di prestazioni

Elevato utilizzo della memoria

Problema: nelle funzioni si verifica un elevato utilizzo della memoria o si verificano errori di esaurimento della memoria.

Causa: ogni richiesta simultanea in Python viene eseguita in un processo separato con il proprio spazio di memoria. L'utilizzo totale della memoria equivale alla memoria per processo moltiplicata per i processi concorrenti.

Soluzione::

  • MemoryUtilizationMonitora la metrica in CloudWatch

  • Riduci l'MaxConcurrencyimpostazione se l'utilizzo della memoria si avvicina al limite di memoria della funzione

  • Aumentate l'allocazione della memoria della funzione per supportare una maggiore concorrenza

  • Ottimizza l'utilizzo della memoria caricando i dati su richiesta anziché durante l'inizializzazione

Prestazioni incoerenti

Problema: le prestazioni delle funzioni variano notevolmente tra una chiamata e l'altra.

Causa: Lambda potrebbe selezionare diversi tipi di istanze in base alla disponibilità oppure le funzioni potrebbero essere eseguite su istanze con disponibilità di risorse variabile.

Soluzione::

  • Specifica i tipi di istanze consentiti: se hai requisiti prestazionali specifici, configura i tipi di istanze consentiti nel tuo capacity provider per limitare i tipi di istanze che Lambda può selezionare.

  • Monitora le metriche a livello di istanza: monitora CPUUtilization e MemoryUtilization a livello di fornitore di capacità per identificare i vincoli relativi alle risorse.

  • Rivedi le metriche sulla capacità: verifica vCPUAvailable e MemoryAvailable assicurati che siano disponibili risorse sufficienti sulle tue istanze.

Problemi con i fornitori di capacità

La versione della funzione non riesce a diventare ATTIVA

Problema: la versione della funzione rimane in sospeso dopo la pubblicazione.

Causa: Lambda sta avviando le istanze gestite e avviando gli ambienti di esecuzione. Questo processo richiede tempo, soprattutto per la prima versione della funzione su un nuovo fornitore di capacità.

Soluzione::

Attendi che Lambda completi il processo di inizializzazione. Lambda avvia tre istanze di default per la resilienza AZ e avvia tre ambienti di esecuzione prima di contrassegnare la versione della funzione come ACTIVE. Questo richiede in genere diversi minuti.

Impossibile eliminare il fornitore di capacità

Problema: viene visualizzato un errore quando si tenta di eliminare un fornitore di capacità.

Causa: non è possibile eliminare un fornitore di capacità a cui sono associate versioni di funzioni.

Soluzione::

  1. Identifica tutte le versioni delle funzioni utilizzando il fornitore di capacità con l'ListFunctionVersionsByCapacityProviderAPI.

  2. Elimina o aggiorna tali versioni della funzione per rimuovere l'associazione del fornitore di capacità.

  3. Riprova a eliminare il fornitore di capacità.

Messaggi di errore generici durante la pubblicazione delle funzioni

Problema: durante la pubblicazione delle funzioni vengono visualizzati messaggi di errore generici come «Si è verificato un errore interno durante la pubblicazione».

Soluzione::

  • Verifica le autorizzazioni IAM: assicurati di disporre dell'lambda:PassCapacityProviderautorizzazione per il fornitore di capacità che stai cercando di utilizzare.

  • Verifica la configurazione del fornitore di capacità: conferma che il tuo fornitore di capacità sia attivo utilizzando l'GetCapacityProviderAPI.

  • Verifica la configurazione del VPC: assicurati che le sottoreti e i gruppi di sicurezza specificati nel tuo fornitore di capacità siano configurati correttamente e accessibili.

  • AWS CloudTrail Registri di controllo: rivedi CloudTrail i registri per informazioni dettagliate sugli errori relativi all'operazione non riuscita.

Problemi di monitoraggio e osservabilità

Metriche mancanti CloudWatch

Problema: non vengono visualizzate le metriche previste CloudWatch per il fornitore di capacità o le funzioni.

Causa: le metriche vengono pubblicate a intervalli di 5 minuti. I nuovi fornitori di capacità o le nuove funzioni potrebbero non disporre di metriche immediatamente disponibili.

Soluzione::

Attendi almeno 5-10 minuti dopo la pubblicazione di una versione della funzione prima di aspettarti che le metriche vengano visualizzate. CloudWatch Verifica di visualizzare il namespace (AWS/Lambda) e le dimensioni (CapacityProviderName,, o) corretti. FunctionName InstanceType

Impossibile trovare i log CloudWatch

Problema: la funzione viene eseguita correttamente, ma non è possibile trovare i CloudWatch log in Logs.

Causa: le istanze gestite Lambda vengono eseguite nel tuo VPC e richiedono la connettività di rete per inviare i log ai log. CloudWatch Senza una corretta configurazione della connettività VPC, le tue funzioni non possono raggiungere l'endpoint del CloudWatch servizio Logs.

Soluzione::

Configura la connettività VPC per consentire alle tue funzioni di inviare i log ai log. CloudWatch Sono disponibili tre opzioni:

Opzione 1: VPC endpoint for CloudWatch Logs (consigliato per la produzione)

  1. Apri la console Amazon VPC all'indirizzo console.aws.amazon. com/vpc/.

  2. Nel pannello di navigazione, seleziona Endpoints (Endpoint).

  3. Seleziona Crea endpoint.

  4. Per Service category (Categoria servizio), scegli AWS services.

  5. Per Nome del servizio, seleziona com.amazonaws.region.logs (sostituisci region con la tua AWS regione).

  6. Per VPC, seleziona il VPC utilizzato dal tuo fornitore di capacità.

  7. Per le sottoreti, seleziona le sottoreti in cui desideri creare le interfacce di rete degli endpoint. Per un’elevata disponibilità, utilizza sottoreti in più zone di disponibilità.

  8. Per i gruppi di sicurezza, seleziona i gruppi di sicurezza che consentono il traffico HTTPS in entrata (porta 443) dal gruppo di sicurezza della tua funzione.

  9. Abilita il DNS privato per l'endpoint.

  10. Seleziona Crea endpoint.

Opzione 2: sottorete pubblica con gateway Internet

Se il tuo fornitore di capacità utilizza sottoreti pubbliche, assicurati che:

  1. Un gateway Internet è collegato al tuo VPC

  2. La tabella di routing indirizza il 0.0.0.0/0 traffico verso il gateway Internet

  3. I gruppi di sicurezza consentono il traffico HTTPS in uscita sulla porta 443

Opzione 3: sottorete privata con gateway NAT

Se il tuo fornitore di capacità utilizza sottoreti private, assicurati che:

  1. Un gateway NAT esiste in una sottorete pubblica

  2. La tabella di routing della sottorete privata indirizza il 0.0.0.0/0 traffico verso il gateway NAT

  3. La tabella di routing della sottorete pubblica indirizza il 0.0.0.0/0 traffico verso un gateway Internet

  4. I gruppi di sicurezza consentono il traffico HTTPS in uscita sulla porta 443

Per una guida dettagliata sulle opzioni di connettività VPC, consulta Connettività VPC per le istanze gestite Lambda.

Difficoltà a correlare i log delle richieste simultanee

Problema: i log di richieste diverse sono interlacciati, rendendo difficile il tracciamento delle singole richieste.

Causa: l'interlacciamento dei log è previsto e si comporta come standard nei sistemi con più concorrenti.

Soluzione::

  • Usa la registrazione strutturata con formato JSON: includi l'ID della richiesta in tutte le istruzioni di registro

  • Java: usa Log4j con ThreadContext per includere automaticamente l'ID della richiesta

  • Node.js: utilizzare console.log() con la formattazione JSON e includere InvokeStore.getRequestId()

  • Python: usa il modulo di registrazione standard con formattazione JSON e includi context.request_id

Per una guida dettagliata, consulta le pagine di documentazione specifiche del runtime.

Ottenere ulteriore assistenza

Se continui a riscontrare problemi dopo aver provato queste soluzioni:

  1. Rivedi CloudWatch le metriche: controlla le metriche del fornitore di capacità e dell'ambiente di esecuzione per identificare i vincoli delle risorse o i problemi di scalabilità.

  2. Controlla AWS CloudTrail i log: rivedi CloudTrail i log per informazioni dettagliate sulle chiamate e sugli errori delle API.

  3. Contatta l' AWS assistenza: se non riesci a risolvere il problema, contatta l' AWS assistenza con i dettagli sulla configurazione del tuo capacity provider, sulla configurazione delle funzioni e sui messaggi di errore specifici che ricevi.

Fasi successive