‫So now let's talk about API Gateway Logging and Tracing.
‫So the first option is to use CloudWatch Logs.
‫And when you enable CloudWatch log integration
‫with API Gateway,
‫you're going to get information about the request
‫and the response body
‫that goes through the API gateway.
‫You can enable it at the Stage Level
‫and you define your Log Level,
‫if you want to have the ERROR logs only, or DEBUG, or INFO.
‫And obviously the DEBUG is going
‫to give you the most amount of information,
‫and you can override this setting on a per API basis.
‫So to make it dead clear,
‫we're going to get a user that makes a request
‫into the API gateway,
‫and automatically that request is going to be logged
‫into CloudWatch Logs.
‫Then the request is making it to your backend,
‫your backend will then give a response to the API gateway,
‫and the response again, will be sent to CloudWatch Logs
‫and finally, make it to the user.
‫So it's very helpful to get the request and the response,
‫but be careful if you do enable this,
‫then you may get a lot
‫of sensitive information into CloudWatch Logs.
‫For X-Ray, well, this is to get tracing information
‫about the requests that go through the API gateway.
‫And if you enable X-Ray for API gateway and Lambda,
‫that gives you of course the full picture, for your API.
‫Then API gateway can be monitored with CloudWatch Metrics
‫and their per stage, and you can enable detail metrics.
‫And so there's a few metrics you need to know about,
‫before going to go in the exam.
‫The first one is called CacheHitCount,
‫and the other one is called CacheMissCount,
‫which gives you some information
‫about the efficiency of your cache.
‫So if your cache is very efficient,
‫the cache hit will be very high.
‫If it's not efficient, the cache miss will be very low.
‫The count is a number of API requests in a given period.
‫The IntegrationLatency is how long the API takes to
‫relay a request to the backend,
‫and waiting for receiving a response from the backend,
‫so it indicates to you,
‫how long the backend is taking to reply to the API gateway.
‫And the Latency itself,
‫is the time between when the API gateway
‫receives a request from the client,
‫and when it returns a response to the client.
‫So that includes the IntegrationLatency,
‫but also adds anything the API gateway is doing.
‫That includes, for example,
‫checking the authorization and authentication,
‫checking the cache, doing some mapping templates, and so on.
‫So the Latency is always going to be a bit higher
‫than the IntegrationLatency.
‫And so you should note,
‫that the maximum amount of time that an API gateway
‫can perform any request is 29 seconds.
‫So if your Latency
‫or your IntegrationLatency is over 29 seconds,
‫that means you will see a timeout from your API gateway.
‫So this is two,
‫these are two really good metrics to look at.
‫Then we have two kinds of errors.
‫So we're getting some metrics related to these errors.
‫You have a 4XX metric, called client-side errors.
‫So this is how many errors we're getting
‫on the client side.
‫And 5XXError
‫which is how many errors we're getting on the server side.
‫So server-side means backend,
‫and client-side means the clients using your API gateway.
‫Okay, so we've seen the API gateway can do some throttling
‫with the usage plans and so on.
‫So we can define also Account Limits,
‫And by default your API gateway will throttle requests
‫at 10,000 requests per second,
‫across all the API's,
‫such as a soft limit and can be increased upon request.
‫So that means that if one of your API is under heavy use
‫the other APIs can also be throttled.
‫So in case you see a throttling, what will you see?
‫You will see an error code, 429 Too Many Requests
‫which is a clients error, because the clients
‫are doing too many requests,
‫and it's retriable but you should use something
‫like exponential back off, to retry these requests.
‫You can also, to improve throttling and performance
‫set stage limits and method limits
‫to make sure that each stage
‫does not use all the quotas of the request,
‫if it's under attack.
‫Or, we've seen before we can define a usage plan,
‫if we want to be able to throttle, per customer.
‫So just like Lambda Concurrency, if one API is overloaded,
‫if not limited,
‫it can cause other APIs to be throttled.
‫So we've seen this
‫with Lambda Reserve Concurrency and concurrency overall
‫but this is also applicable to API Gateway.
‫Okay, finally, let's talk
‫about the errors we can see in the API gateway.
‫So 4xx means Client errors,
‫So the clients using your API Gateway.
‫This could be 400:Bad Request
‫403:Access Denied, or the web application firewall
‫did not accept your request.
‫429, for example, if your quota has been exceeded
‫and you're seeing some throttling.
‫And anything with 5XX, means Server errors, so your backend.
‫So 502 means that for example,
‫your Lambda proxy integration did not respond well,
‫or 503 is that your backend is unavailable.
‫Or 504 is that there was an Integration Failure,
‫and one of these failures is that
‫the API gateway did request timeout and after 29 seconds
‫did not receive a request from the backend
‫and therefore we returned a 504:Integration Failure,
‫due to this timeout.
‫So that's it for the API Gateway Monitoring.
‫I hope you liked it, and I will see you in the next lecture.