AWS Monitoring & Source Files

[00:00:00]
>> Scott Moss: The next thing is monitoring, so they have pretty much basic monitoring around what's happening inside your function so you have things like invocation count. The duration of your functions, how many errors, throttled invocations, we'll talk about throttling, iterator age, DLQ errors like pretty much, all the metrics you would need to figure out what's going on in your system.

[00:00:24]
But they're basically bare, I mean, you probably wanna use some other type of instrumentation on your lambdas to get more information out of them, but it's good enough. It's good enough to figure out that your lambda is performing pretty bad or pretty good and you can figure out what bottlenecks are.

[00:00:41]
>> Scott Moss: And the other two things up top are, we have this throttle thing here which basically throttles your lambda. So you know if you're experiencing downtime on your database or you're migrating or somebody's hacking you or something, you can throttle your lambda so it does exactly what it says, it's throttling your lambda.

[00:00:57]
And then qualifiers, these are basically the versions that I was talking about, so you can have a different versions of your lambda and then you can tag them with different names and then they became qualified versions of length which I can execute. This is very dent, the only time I've ever use this, is when I assume lambda on the edge was lambda on cold front.

[00:01:19]
You specifically have to give them versions, because it takes CloudFront, 30 minutes to deploy Orlando to every node across the world. So you have to do versions, so it's kinda crazy, other than that I've almost never used these and the actions are just actions. And that's about it as far as the difference between, deploying it on Lambda, and running it locally.

[00:01:41]
Basically it's just a GUI around the same thing you get inside your repo and some monitoring tools. And then I showed you logs, talked about the execution role in the VPC. Everything else is pretty much the same, any questions on Lambda on AWS?
>> Scott Moss: Okay and then one thing I showed earlier, but I was gonna show again, because I just cannot emphasize how important this is, especially if you use Webpack to bundle your functions.

[00:02:12]
But if you go to you can find the bucket name of your function. It's always gonna be your service-your stage and then it's gonna be -service deployed bucket with some key on it. So, that's the bucket for the service you're looking for. Click on that, click on server list, click on your stage, so if you have multiple stages they'll be listed here.

[00:02:34]
Click on that and then, for every deploy that you make, there's gonna be one of these. So this means I deploy it this many times, so pick on one of these for your latest deployment or whatever. And this is helpful because, especially if you're using Webpack, and you don't have source maps, you'll get an error, and you'll go look at the log in CloudFront or CloudTrail and you'll be like I have no idea what that is.

[00:03:00]
You wouldn't, you just won't know what it is. Cuz there's no stack trace, it's all a webpack, you won't know what's going on. So the best thing that I've been doing, that actually I would come in here and just download the ZIP file and just see what's going on in the compile code.

[00:03:13]
And that's actually been helping me, so this can be very helpful for that. It could also just be like, you know, just a sanity check to make sure that you got the right lambda on there. So you can just verify, like yeah this did get updated correctly, what's going on, because weird things do happen.

[00:03:28]
So yeah, this is where it is, so basically, when your lambda is invoked, remember I talked about the cold boot, there's a cold boot around the container starting up. There is a cold boot around the lambda being created. That's because your lambda is just a file, they have to go to S3 and unzip it.

[00:03:42]
So the bigger your lambda, the longer it's gonna take to unzip it. So you wanna keep your lambda small and thin and then you wanna keep those containers warm. And therefore you dont have any cold boots, so your lambdas are just zip files upload S3 for you. And in fact when lambda first came out you had to manually do this.

[00:03:58]
You had to manually zip your lambdas and put them here yourself and then they would get them and that was as horrible experience. Yes,.
>> Speaker 2: So if you do the reverse and destroy your function from the function GUI. Will AWS go back through all of these buckets and eliminate all of these files?

[00:04:21]
Or do you have to go do clean up yourself?
>> Scott Moss: They will not, yeah, they don't care, if you do it through CloudFormation, it will. If you just do it through the GUI, they will not, you will just be in a weird state. What will happen is if you did that, you deleted some stuff out of here and then you try to redeploy the servlet server, so it will just scrap out, couldn't do it because you told it to redeploy, you didn't tell it to create.

[00:04:43]
So they'll go try to redeploy to a bucket that no longer exists and then it'll just break. So then you would have to actually just delete everything and do a new deploy. So it's very straight and very robust on what it's doing. So yeah, unfortunately you couldn't and we ran into that tons of times which is why I said don't mix and match.

[00:05:01]
That's the biggest mistake I made when I was using Lambda, the first time.
>> Speaker 2: Is that your path then when you guys are tearing down functions? Do you go back and do all that or?
>> Scott Moss: No, when we were tearing down functions, we just used sls remove which removes the whole stack.

[00:05:16]
Goes to cloud formation, tells cloud formation to remove everything. And then cloud formation's like, cool, I'm just gonna take down everything, all the IM roles, the functions, every single thing. It's gonna remove everything for you, sometimes it takes a long time, sometimes it hangs and it'll be done and you won't even know, it's like an hour later.

[00:05:31]
This is why I said it's nice to be able to come to AWS and look at the cloud formation tab and watch it happening so you can see when it's done. It's more helpful that way, but, yeah that's what I would do. I just wouldn't mess with anything in here if I was doing serverless, it's too conflicting.

[00:05:48]
>> Scott Moss: Any questions on any of this stuff?
>> Speaker 3: Cloud formation logs, you said?
>> Scott Moss: Cloud form-
>> Speaker 3: Get to that real quick?
>> Scott Moss: Where?
>> Speaker 3: You said that, In order to watch the progress
>> Scott Moss: Yeah, watch the progress of course. That's confirmation, so if you go here and you click on the service name you'll see, when you scroll down you'll see all this stuff.

[00:06:10]
This is the history of what's been happening in a confirmation for you and it's all time stamped and everything. It's literally every single event and what called the event and what was the status of the event? Is pretty verbose, so yeah, you can also get most of this, too.

[00:06:26]
If, when you deploy, or you run any command with serverless, if you type -v for verbose, it'll print that cloud formation stack out for you, too, while it's happening. That way, you don't have to go through the dashboard and look at it. So that's if you want all that stuff in here.