-: Okay so let's have a look at
the type of errors that can be
generated from load balancers.
So a successful request is going to be 200,
which is pretty standard,
but then if the clients did do an error.
So if your web browser, for example, did do an error,
you're going to receive a 4XX type of error.
Okay. You don't need to remember all of that.
I'm going to give you,
but it's just to gives you illustration.
So 400 is bad requests, 401 is unauthorized, 403 is
forbidden, 460 is client closed connection,
463 is that the header X forward for, was malformed.
Okay.
And anything that is going to be an error on the server
side. So it could be the load balancer,
or it could be your backend east two instances is going to
be a 5xx type of code.
So 500 means that there's an internal server error.
502 is by gateway, 503 is service unavailable,
which is when your institute instances are not available to
send back the reply to the bouncer,
which is an important code to know 504 is gateway
timeouts, and 561 is unauthorized, okay.
So from an exempt perspective,
just remember that's 4XX codes are client side errors.
So that hints at a client problem,
and 5XX errors are going to be server problems, okay.
So this is just for you to be able to determine the kind of
metrics to look at on your load balancer.
So talking about metrics on your load balancer.
So there are metrics push directly from the ALB.
I mean, to any live answer, relate to CloudWatch metrics.
So it could be backend connection errors to monitor.
If your Institute instances are airing out,
unhealthy code host counts,
and a healthy host counts is super important,
which is it was illustrated right here.
So say you have a load balancer, six instances,
and two of them are down. So in this case,
the healthiest counts is going to be four,
and the unhealthy host count is going to be two. Okay.
Just to illustrate it.
But this is important to see at once next,
the number of times that there was a 2XX successful
request in the backend 3XX, 4XXs,
which is hinting at the client's error codes and 5XX,
which is hinting at server error codes. Okay.
Then we have latency information,
So how fast is it to get a request back to the clients,
the request council,
which is the overall request counts for your ALB,
the request counts per target, which is very interesting,
which is how many each,
how many instances has received a request on average,
which is a good metric to monitor and to scale on, and the
search queue length.
So this is the number of total number of requests that are
pending and being routed to healthy instances. Okay.
And this can help, for example, out your ASG,
the max value is 1000,
So you don't want to have a big queue of requests.
You want to make sure that,
of course this queue remains closed.
The queue is close to zero and spillover is that number of
requests that were rejected because
the queue was full, okay,
and this is something you never want to have better over
zero. That means that if you're over zero,
you need to really scale your backend to serve these
additional requests, and that the clients are losing some
requests.
Now, if you want to troubleshoot using metrics.
So a 400 by request,
meaning that the client sends BA and from request of 503,
it means that again,
there are no healthy instances available for your load
balancer.
And so you could have a look at the healthy host counts
metric and CloudWatch of 504 is a gateway timeouts.
So check if the keep alive
setting on your EC2 instances
are enabled and make sure that to keep it live timeouts is
greater than the idle timeouts setting of the load balancer,
and overall sets alarms for your load balancer,
and troubleshoots using the documentation.
I recommend you to take a look at this link just to
understand things better,
and you'll be good to go.
next for your load balancer access logs. Okay.
So these are the access logs from the load balancer,
and they can be stored in S3, and they will contain all the
requests made to your load balancer,
So this includes just a minute.
So the time, the client IP address,
the latencies request path,
server response trace ID,
and you're only going to pay for the S3 storage of sending
these logs to Amazon and straight.
It is very helpful for
compliance reason and for debugging.
And it's helpful to keep access data,
even after the ELB, or your easy
two instances are terminated
and the excess logs are encrypted for additional security
finally, for request for tracing.
So there is a request tracing.
There is a custom header called X Amazon trust ID that is
being added to every HTP request. And here's an example.
So this is going to be very helpful in logs or for
distributed tracing platform to track a single request.
But just so you know,
the AOB is not yet integrated with x-ray.
So you're not going to see that request tracing appearing in
x-ray just yet,
but it will update it as soon as it's available.
So here in my ALB, I have the option to look at monitoring,
which shows me all the kind of a common metrics I just
mentioned. So it shows you the HTP 400, the 500,
the ALB 400, and 500.
And so on the target connection errors, all these are very,
very, very interesting,
the active connection counts, and so on.
So you can have a look at the metrics right here and you can
do them all in CloudWatch. Okay.
And what I want to show you is that if you click on your Alb
and you can edit some attributes, you can, for example,
have the access logs and the access,
logs can be enabled and sent to an S3 buckets,
and you can create the location directly from this UI as
well. Okay.
So that's it for this lecture, I hope you liked it,
and I will see you in the next lecture.