Here you are.
And welcome back now into this, we will be discussing about different type of heretics that are available
as part of Routt 53.
Now, there are three primary types of Hatake that are supported in part 53 for this issue, jeepneys
GDP is Helvetic.
Second is at PCP's healthy and third is EPA and EPA setpiece Hatake with string matching.
So let's go ahead and understand all of them in more detail now before we continue.
Let me quickly show you on which step to reconfigure the type of health take.
So basically, under the protocol here, you have HTP, you have EGD and you have PXP.
So in case, if you go ahead and use EPA is another other set configurations here you have the option
of string matching.
So if you do a Yes, Audur, so this becomes the third time.
So basically EPA, EPA is one, then you have a PXP, which is the second one, and then HDB EPA along
with string match.
So this is something that we were discussing in terms of three primary health checks that are supported
in drought 53.
So let's go ahead and discuss about the first type of health, which is based on EPA.
So when you enable this type of health, there are two important things that Drought 53 Health TICAS
will take.
First one is that the drought 53 must be able to establish a PXP connection with the endpoint within
four seconds.
So this is the first requirement in order for the endpoint status to be healthy.
And second is in addition to this first point, endpoint must respond within.
It should be status quo of two executrix within two seconds after connecting.
All right.
So forsworn is the TCP connection should be succeeded.
And second is the EPA response goal should be in two or three range.
So, for example, let me go back.
And in one of the health where is is healthy, let's quickly open this up.
So I'll quickly paste this here.
Now, if you'll quickly go to the inspect within the browser, it will go to the network.
Let's refresh this page and you'll see that you're basically getting a status code of 386.
So this is three zero four, not modified primarily because multiple requests had been made here.
So either to six is fine or even three six based code is also acceptable.
Now, the second type of health check that is supported is based on PXP.
So in this type of health, check it out, 53 must be able to establish a DCPI connection with the endpoint
within 10 seconds.
And if the TCP connection is successfully established, it considers the endpoint to be healthy.
So in terms of Whipsnade, so let's say you were running a health risk based on Web sites, and if the
type is TCBY, then irrespective of the EDP response code that is coming from the Web server, it will
still consider it to be healthy.
So make sure that depending upon the use cases, you select the right health check.
So let's go ahead and understand this in more detail.
So let's say that this is the endpoint and within this endpoint, if I just add a specific part of a
statistic.
So in the output, you basically get data pages, not fun.
And in fact, if you do inspect Aurier, let's go to network.
Let's refresh this page.
So the status quo that is coming here is four zero four.
Now, do note that in case if you're using a ETP is GDP based health check.
And if this status score is four zero four, then it will consider the endpoint to be unhealthy.
However, for the BCB based health check, it does not really look into the status quo at all.
It will verify is that DCB condition establishment?
And since you're the DCB connection is successfully established, the endpoint will be considered to
be healthy.
So let's quickly try this out.
So what I do here is that for the Ingenix website, let me edit the hatcheck and in the part will just
give it the best estimate, similar to what we had added within the tab and click on it and will go
ahead and create one more health.
Let's call it as DCB Health Check and IP address here.
Let's copy the IP address, I'll paste it and then in the protocol will be selecting PXP Aurier.
So as soon as you selected PXP, you see the ultimately the part went away once, then let's do a next
and we'll create.
Great.
So now at this stage both of the health check has been created.
Let's wait for a moment here for this status to be updated.
So now after a refresh this page, after two to three minute interval, you're for the engineers website.
Now, you see it went from healthy to.
Unhealthy status, primarily because even though the website is working, but that is to be responsibilities
for 04 and for the PXP health check it is showing is healthy because all it does is it verifies that
BCB connection.
That's great.
So at this moment, I hope at a high level overview, you understood the basics about the first two
health check.
Now, let's also discuss in detail about the third one, which is the ETP needs to be presented with
string matching.
Now, this is very similar to that of the first health check where it goes ahead and verify asymptotically
connection can be established within the first four seconds.
Then it verifies if the EDP status code is to or 386.
And the third thing which makes it unique, it basically verifies if the response body that it receives
contains a certain specific string.
So, for example, if a response body, let's say it receives copyleft, then it might consider it as
healthy if it sees some other response body it might consider as not healthy.
So let's also try this out practically.
So let me do one thing.
Let's go ahead and quickly connect to what is he doing stance here.
Let's switch to the road.
User will go to the part of users, share in the next e-mail and within your will create a new file,
let's call it has strings attached.
And let me just specify Capela and Gordon will see that once Then let's go to the road 53.
So let's do one thing within Route 43.
Let me go ahead and quickly create one more check.
I'll just call it a spring health check.
The I.P. address will be similar.
Let me just copy this up and I'll be there and within the path.
I this is a very strong statement.
Now let's also verify that if it is working, so I'll specify string, not e-mail and in the outproduce
epilepsies appearing.
So this endpoint is working perfectly well now within the advanced configuration, you will go ahead
and select string matching from no to yet and insert string I'll say.
So what it will do is if it is able to find the key pillars in this specific page, it will consider
it to be healthy.
Right.
So once then let's go ahead and do a next and we'll create Elting.
That's great.
So let's quickly wait for the status to be updated.
So when you see the status of this health check is healthy.
So now let's do one thing.
Let's go ahead and modify this file yet again and I'll add some different content.
So let me just add it.
Orange alert.
I'll go ahead and I'll see that.
You know, if you refresh this page, the content changed from Kepi Labs to oranges.
So now let's look into how the health check will behave.
So now you see the string health check is changed from a little unhealthy.
So with this, I hope you understood in detail about each and every hatake that are part of it.
Out of pity.
No.
One more important thing that I wanted to show you specifically in terms of the health check, which
supports string matching, is that the string, whatever string that you specify must appear entirely
within the first five one two zero bytes of the response body?
This is very important.
If it does not appear in the first five and two zettabytes, then the health endpoint would consider
to be filled.
So this is one thing that you should remember specifically if you are implementing it within the production
environment.
Now, one more important thing before we conclude, make sure that you go ahead and delete all of these
health checks in case if you are trying this out, otherwise it will unnecessarily add to your overall
budget.
So that's the high level overview.
And with this will conclude today's video.