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 ](lambda-managed-instances-java-runtime.md) 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. ](lambda-managed-instances-nodejs-runtime.md) ### 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 ](lambda-managed-instances-python-runtime.md) 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:**: + `MemoryUtilization`Monitora la metrica in CloudWatch + Riduci l'`MaxConcurrency`impostazione 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'`ListFunctionVersionsByCapacityProvider`API. 1. Elimina o aggiorna tali versioni della funzione per rimuovere l'associazione del fornitore di capacità. 1. 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:PassCapacityProvider`autorizzazione 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'`GetCapacityProvider`API. + **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/. ](https://console.aws.amazon.com/vpc/) 1. Nel pannello di navigazione, seleziona **Endpoints (Endpoint)**. 1. Seleziona **Crea endpoint**. 1. Per **Service category (Categoria servizio)**, scegli **AWS services**. 1. Per Nome del ** servizio**, seleziona `com.amazonaws.region.logs` (sostituisci `region` con la tua AWS regione). 1. Per ** VPC**, seleziona il VPC utilizzato dal tuo fornitore di capacità. 1. 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à. 1. 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. 1. Abilita il DNS ** privato ** per l'endpoint. 1. 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 1. La tabella di routing indirizza il `0.0.0.0/0` traffico verso il gateway Internet 1. 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 1. La tabella di routing della sottorete privata indirizza il `0.0.0.0/0` traffico verso il gateway NAT 1. La tabella di routing della sottorete pubblica indirizza il `0.0.0.0/0` traffico verso un gateway Internet 1. 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. ](lambda-managed-instances-networking.md) ### 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à. 1. **Controlla AWS CloudTrail i log: ** rivedi CloudTrail i log per informazioni dettagliate sulle chiamate e sugli errori delle API. 1. **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 + Scopri i fornitori di [ capacità per le istanze gestite Lambda ](lambda-managed-instances-capacity-providers.md) + Scopri la [ scalabilità per le istanze gestite Lambda ](lambda-managed-instances-scaling.md) + Consulta le guide specifiche per il runtime per [ Java e Python ](lambda-managed-instances-java-runtime.md) [ Node.js ](lambda-managed-instances-nodejs-runtime.md) [Runtime Python per istanze gestite Lambda](lambda-managed-instances-python-runtime.md) + Monitora le istanze gestite da Lambda con le metriche [ CloudWatch ](lambda-managed-instances-monitoring.md) + Consulta [ le best practice per le istanze gestite Lambda ](lambda-managed-instances-best-practices.md)