Cloudwatch on AWS Lamda and Gateway

I recently tested my newly created API Gateway pointing at Lamda using

npx aws-api-gateway-cli-test

It took quite a lot of parameters…

Well anyway… long story short, I got this … a lot

npx: installed 110 in 13.123s
Authenticating with User Pool
Getting temporary credentials
Making API request
{ status: 403,
statusText: 'Forbidden',
data: { message: 'Forbidden' } }

So it’s time to learn how to add logging my little pointless API.

The goals

  1. Adding Cloudwatch to API Gateway
  2. Adding Cloudwatch to Lamda’s

Part one — create the API Gateway Role and get ARN

  1. Go into IAM
  2. Open Roles
  3. Click Create Role
  4. Select API Gateway
  5. Complete the wizard and capture the ARN reference

Part 2 — Add the ARN to your API Gateway

Go to the API Gateway you want to log, and open settings to see:

Paste the link and save it.

Part3 — Turn on the logging

You can find this in your gateways ‘stages’ section. Once this is done you’re capturing logs.

Looking at the logs

Gateway logs

I’ve found that AWS surfaces these logs in a lot of places. The first and easiest place to find is in Cloudwatch itself.

I found there to be groupings for my Lamda’s and also the API Gateway itself that we just configured.

Viewing the API Gateway shows you streams of activity, from my own testing a stream doesn’t mean a single invocation. It can contain multiple logs from many invocations. Its simply a log of activity, pretty useful.

On clicking on a single stream you’ll see a list of logs which can be expanded

Lamda Logs

If you open up a log group for the lamda you see this

This was then drillable by opening the log stream and in here I was able to pull a single invocation. Unsure from my testing if this would be polluted by multiple invocations or not.

It also showed my console.log’s which I needed to diagnose my own issues.

Another place I was able to get metrics was in AWS Lamda itself.

This gave me more metric data than logging

But I did like the clarity on invocations, memory consumption and billing costs. Incidentally clicking on those log streams takes you back to Cloudwatch. Looks like the minimum billing duration is 100ms, good to know 😁.

Logs from the CLI

One thing I found that I liked was the serverless logs command. Though I’ll say this now, if like me you have some STDOUT issue on GIT Bash… then use cmd.exe (windows life) or you get diddly squat.

serverless logs -f create --tail

Will offer you a live tail end feed of the function you want to log. This is going to be REALLY beneficial when trying to debug an issue.

Even as I’m venturing into serverless a lot more, this was a missing piece for me. I’ve never felt so blind to the going’s on of my actions. I miss the debugger. The local invocations stuff is really helpful, where i can pass it stubbed data -this is better than some other API stuff I’ve worked on. Though the meatiest issues are often configurations and those do not surface well [so far]… often from a security standpoint, they’re vague by design.

Fullish-stack engineer (codebykev.dev) and Lead front-end engineer @Pushdoctor with 15+ years developing web apps, installations, AR toys and other fun stuff.