Feilsøking av serverless-applikasjoner
Oppdag teknikker for effektiv feilsøking av Lambda-funksjoner, blant annet lokal testing, ekstern feilsøking og tolkning av CloudWatch-logger for å løse problemer
Feilsøking av serverless-applikasjoner er en gratis leksjon i Serverløs utvikling med AWS Lambda på CoddyKit. Dette er leksjon 3 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Serverløs utvikling med AWS Lambda, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Serverløs utvikling med AWS Lambda inneholder totalt 4 leksjoner.
Introduksjon til feilsøking av Lambda
Feilsøking av serverløse applikasjoner, spesielt AWS Lambda-funksjoner, byr på unike utfordringer. I motsetning til tradisjonelle applikasjoner er Lambda-funksjoner tilstandsløse og kortvarige.
I denne leksjonen utforsker vi praktiske teknikker for effektivt å identifisere og løse problemer i Lambda-funksjonene dine, fra lokal testing til tolkning av logger.
Hvorfor feilsøking av serverløse systemer er unikt
Tradisjonell feilsøking innebærer ofte at du går gjennom koden linje for linje ved hjelp av en IDE. Med Lambda er dette ikke alltid like enkelt, fordi:
- Kortvarighet: Funksjonene kjører bare når de blir påkalt, og forsvinner deretter.
- Tilstandsløshet: Det finnes ikke noe vedvarende minne mellom påkallinger.
- Distribuerte systemer: Problemer kan oppstå i samspillet mellom mange tjenester.
Vi er derfor i stor grad avhengige av logger, målinger og sporing for å forstå hva som skjer.
Lokal testing med SAM CLI
En av de mest effektive måtene å feilsøke på er å teste Lambda-funksjonene dine lokalt før du distribuerer dem til AWS.
AWS Serverless Application Model (SAM) CLI lar deg påkalle Lambda-funksjonene dine på den lokale maskinen, og simulerer kjøretidsmiljøet for AWS Lambda.
- Raskere tilbakemeldingssløyfe.
- Bruk de lokale feilsøkingsverktøyene du kjenner.
Demo: Lokal påkalling med SAM CLI
Her er en enkel Python Lambda-funksjon. Ved lokal testing kan du simulere en hendelse og en kontekst. Prøv å kjøre den!
import json
def lambda_handler(event, context):
message = event.get('message', 'Hello from Lambda!')
print(f"Received event: {json.dumps(event)}")
print(f"Processing message: {message}")
return {
'statusCode': 200,
'body': json.dumps({'response': message})
}
# This block allows local execution
if __name__ == '__main__':
# Simulate an event
test_event = {'message': 'Local debug test'}
# Simulate a context object
test_context = type('obj', (object,), {'invoked_function_arn': 'local'})()
response = lambda_handler(test_event, test_context)
print("\n--- Lambda Response ---")
print(json.dumps(response, indent=2))
CloudWatch Logs for feilsøking
Når Lambda-funksjonen din er distribuert, blir Amazon CloudWatch Logs det viktigste verktøyet ditt for å forstå hvordan den oppfører seg og feilsøke problemer.
Hver gang Lambda-funksjonen din blir påkalt, sendes logger til en dedikert logggruppe. Hver påkalling får en unik Request ID, som gjør det enklere å spore kjøringen.
- Logggrupper: Inneholder logger for en bestemt funksjon.
- Loggstrømmer: Inneholder logger fra bestemte forekomster av funksjonen.
Finne problemer i logger
Når det oppstår en feil, er CloudWatch Logs det første stedet du bør se. Du kan:
- Filtrere logger: Søke etter nøkkelord som "ERROR", "Exception" eller bestemte meldinger.
- Log Insights: Bruke et kraftig spørrespråk til å analysere logger, gruppere feil og identifisere trender.
- Request ID: Bruke Request ID fra påkallingen til å finne alle logger som gjelder en bestemt kjøring.
Kontroller alltid hele stacktracen for detaljert informasjon om feilen.
Feilsøking med loggsetninger
Den enkleste, men samtidig kraftigste, feilsøkingsteknikken for Lambda er å bruke setninger med print() (Python) eller console.log() (Node.js).
Ved å legge til loggsetninger på strategiske steder kan du følge med på variabelverdier, kjøringsforløp og funksjonstilstand på ulike punkter i koden. La oss se på et eksempel:
import json
def calculate_discount(price, discount_percentage):
print(f"DEBUG: Initial price: {price}")
if not isinstance(price, (int, float)) or price < 0:
raise ValueError("Price must be non-negative.")
if not isinstance(discount_percentage, (int, float)) or not (0 <= discount_percentage <= 100):
raise ValueError("Discount must be between 0 and 100.")
discount_amount = price * (discount_percentage / 100)
final_price = price - discount_amount
print(f"DEBUG: Final price: {final_price}")
return final_price
def lambda_handler(event, context):
try:
data = json.loads(event['body'])
price = data['price']
discount = data['discount']
final_price = calculate_discount(price, discount)
return {
'statusCode': 200,
'body': json.dumps({'originalPrice': price, 'finalPrice': final_price})
}
except Exception as e:
print(f"ERROR: An error occurred: {e}")
return {
'statusCode': 400,
'body': json.dumps({'error': str(e)})
}
if __name__ == '__main__':
# Test case 1: Valid input
test_event_1 = {'body': json.dumps({'price': 100, 'discount': 10})}
response_1 = lambda_handler(test_event_1, None)
print("\n--- Test Case 1 Response ---")
print(json.dumps(response_1, indent=2))
# Test case 2: Invalid discount
test_event_2 = {'body': json.dumps({'price': 50, 'discount': 110})}
response_2 = lambda_handler(test_event_2, None)
print("\n--- Test Case 2 Response ---")
print(json.dumps(response_2, indent=2))
Forstå påkallingsfeil
Lambda-funksjoner kan mislykkes av mange ulike årsaker. Det er viktig å skille mellom forskjellige feiltyper:
- Funksjonsfeil: Koden din utløste et uhåndtert unntak. Disse vises i CloudWatch Logs med en stacktrace.
- Påkallingsfeil: Problemer som oppstår før koden din i det hele tatt kjører, for eksempel tillatelsesfeil eller begrensninger på nyttelastens størrelse. Disse vises kanskje ikke direkte i funksjonens logger.
- Tidsavbruddsfeil: Funksjonen din overskred den konfigurerte kjøretiden.
CloudWatch-målinger og X-Ray (i en annen leksjon!) hjelper deg med å identifisere disse.
Spore forespørselsflyten
I komplekse serverløse applikasjoner kan én enkelt forespørsel involvere flere Lambda-funksjoner, API Gateway, SQS, DynamoDB og mer.
Det er avgjørende for feilsøkingen å forstå hvordan en forespørsel flyter gjennom disse tjenestene. Bruk Request ID (som ofte videreformidles som x-amzn-RequestId eller noe tilsvarende) til å knytte sammen logger fra ulike komponenter.
AWS X-Ray (som omtales i en senere leksjon) gir visuell sporing for dette formålet.
Beste praksis for feilsøking
Følg disse prinsippene for å redusere utfordringene med feilsøking:
- Omfattende logging: Logg inndata, utdata og tilstanden til viktige variabler.
- Strukturert logging: Bruk JSON-logger for enklere tolking og spørring.
- Idempotens: Utform funksjonene slik at de gir samme resultat selv om de blir påkalt flere ganger.
- Små funksjoner: De er enklere å isolere og teste.
- Automatisert testing: Enhets- og integrasjonstester oppdager problemer tidlig.
Feilsøkingsutfordring
Du har en Lambda-funksjon som behandler brukerregistrering. Brukere rapporterer at registreringen noen ganger mislykkes, men du ser ingen "ERROR"-meldinger i CloudWatch Logs for Lambda-funksjonen din.
Hva er den mest sannsynlige årsaken, og hvor bør du undersøke først?
Oppsummering: Feilsøking av serverløse systemer
Vi har gått gjennom viktige teknikker for feilsøking av serverløse applikasjoner:
- Lokal testing med SAM CLI for rask iterasjon.
- Bruk av CloudWatch Logs til å analysere funksjonens virkemåte og identifisere feil.
- Bruk av loggmeldinger til å spore kjøringsflyten.
- Forståelse av ulike typer Lambda-feil.
- Beste praksis for å bygge serverløse funksjoner som er enkle å feilsøke.
Når De behersker disse teknikkene, vil det forbedre evnen Deres til å bygge robuste serverløse applikasjoner betydelig.
Lær deg Serverløs utvikling med AWS Lambda med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 12
- Leksjoner
- 48
Ofte stilte spørsmål
Er leksjonen «Feilsøking av serverless-applikasjoner» gratis?
Ja – hele teksten i «Feilsøking av serverless-applikasjoner» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Serverløs utvikling med AWS Lambda-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Serverløs utvikling med AWS Lambda inneholder totalt 4 leksjoner.
Hva lærer jeg i «Feilsøking av serverless-applikasjoner»?
Oppdag teknikker for effektiv feilsøking av Lambda-funksjoner, blant annet lokal testing, ekstern feilsøking og tolkning av CloudWatch-logger for å løse problemer Du øver på Serverløs utvikling med AWS Lambda med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med Serverløs utvikling med AWS Lambda?
Ingen tidligere erfaring er nødvendig. Serverløs utvikling med AWS Lambda på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 3 av 4.
Hvor lang tid tar leksjonen «Feilsøking av serverless-applikasjoner»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne Serverløs utvikling med AWS Lambda-leksjonen?
Ja. Alle Serverløs utvikling med AWS Lambda-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- CloudWatch-logger og -måltall
- Feilhåndtering og nye forsøk
- Feilsøking av serverless-applikasjoner
- Egendefinerte måltall og CloudWatch-alarmer