Hello, and welcome to secure JavaScript programming with Vladimir de Turckheim. This video will talk about several s logging and monitoring. So here we've got to wear sanctions that we created a couple videos ago. And actually it returns the Levenstein distance between two worlds that you can pass as parameters here. This function is deployed on Google Cloud service functions project. And if we check the looks, yeah, bad. But we saw if you remember the first video that when we had an error were not able to know why there was an error and we had to imagine it. Well, that's because we made the first mistake is that we forgot to add locks. So questions that everyone asked is should you look input parameters of Philomena of the function? Well, you should not because there are a lot of things that you don't want to log in input objects that can include cookies, that can include other shared secret, reason web tokens or even IP addresses of your end user. And you don't want to have that in logs because you want to separate who has access to each piece of information. When things that you can do is to log what's important for the functioning of the function. So in this example, we do console the drug eggs and then we just were logged the two worlds. Also, we know that logging is critical when things don't go well. So another thing we need to log is console.Log. And we need to log, the most of things we can because we need to understand why it failed. So we can do something like this. That's actually presented to new line. And what that way if we don't want to disclose the arguments directly. Well, we would be able to at least disclose their value. Also by checking the code, there is another reason why it could fail and it's query keys. Actually, the user may be pushing the wrong clarity's to the function. That's actually important to evaluates all the reasons that could bring you to this error cut path because you want to make sure that it will give you enough pieces of information for when things will go wrong. Let's say I would have just logged, I wouldn't have like this because it would be confidential data and I would have need log the type of world 1 and world 2. Well, if a user has returned world went two instead of one where I wouldn't be able to tell them they did that. I won't be able to fix where they failed. And probably, I would not be able to learn from this mistake. So let's just wait for this to redeploy. And here we can see that we have the world being looked. Now let's retry. Let's refresh. I apologize in advance if Google changes there, the language of my interface, I don't know why, but for some reason today it wants me to see Google in French. So here we have run and the Iraqis function execution started and it's still catching up with the logs. So as you can see, we have the argument being logged, it's not always the best practices needs to be understood. But here we've got a foreign read zero. And actually cougar is having a bad time. Here it is. And here we've got to our logs, we know that world 1 was a string, but world 2 was not. And that we only had a query key for world 2. As you can say, Google is not deterministic, the older way it gives user look. The other thing you want to monitor when you have a lambda function is the number of invocations. Actually, the number of invocation as a direct impact on your billing, because you pay by billing and that by invocation and time. So you want to keep an eye on that. And for this part of the cloud provider usually have pretty good ways of telling you this. However, the interesting part is that they don't tell you about the details of the execution time. They just tell you your Lambda is being slow, your Lambda is being quick. And as you have seen, the logs are not that helpful when you would have a lot of conferencing. So either you are able to understand why your lambda is, your function is slow by correlating the logs with a peak of invocation time. But you also need to know that there is what's called the cold start time, meaning booting a new container with your function. Either you achievement is an APM. So for instance, Datadog or I'm British and neurotic has it too. APMs such as Datadog, New Relic, Dynatrace your names, what was when you like have actually support for Lambdas and serverless. They must have partnered with AWS so far because AWS provides what's called a layer that has actually been designed for monitoring your AWS Lambda. I was always in Google cloud, you will just have to run it as an APM. The APM will actually tell you on a transaction what is slow. And if it knows about your cloud infrastructure, for instance, if you deploy Datadog, AW Uric and AWS Lambda, it will actually be able to tell you about what is really slow in your infrastructure, but also in your code. If you have a transaction that is slow because of a database call, it will give you span a span tree and actually tells you why you are being a slow. Those are the 2, 3 main important things to log in production. So compared to usual applications as not much. So you want to know about the logs to make sure that when things go bad, you can audit them. You want to know about impact in terms of billing. Also, if you ask Google Cloud about the billing part, they will give you high level views on the billing problematic and tell you where you have spent that much cost on lenders or another situations. That's actually pretty handy to use. I'm on a free plan so they don't really tell as much about that. And I should be cautious when should you use this part because there is my credit card number somewhere in this dashboard. Also you want to be able to look the performances of the application. So you know for instance that this call to this function is actually slower than all the rest of the code path. All that database query takes much more time than it should to respond to your user. The attacks that can come out of that is that actually well time is money and that's actually very true with function as a service. Because the longer your function takes to execute, the more cost you will have. So instead of doing actual does by disabling your systems and presenting your systems from being accessible on the Internet. Well, the attacks by hammering serverless functions hits you when it's paid full of your wallet and you will just pay insane fees out of a called function calls. There's actually when good thing is that you can create a budget. And you will get alerts when charges exceeding amount. And for all cloud provider systems, there is a way to limit your cost and say, hey, I'm not getting more, much more than that money on the table. Also out of my experience, if that's the first time you have very high issues and cost because of poorly predicted cost or attacks are badly used services, cloud providers might. And I'm not engaging anywhere and I'm not affiliated with any cloud provider. When they say that some cloud providers might actually forget about your billing for one month. If you spend really, really too much money, but that's one to one negotiation, you must have with your contact securities under come on, the cloud provider site. Thanks so much for watching this video. I hope you enjoyed it. And I hope it's clear for you to protect serverless applications. Now have a great day.
