In this demo,
I want to continue to show you
how to monitor a web application with Prometheus,
just like we did in the last demo.
But now, I want to show you
how you can cut with the Apdex score,
which is very useful to know
whether your application is performing well.
And you can also put alerts
if your application isn't.
So here on the Prometheus web UI,
I created a new graph based on
the flask request legacy seconds bucket.
And for this one, every hit to my flask web server
that gets processed in less than one second
is okay for me.
But every hit that takes longer than one second,
I only want to see a certain percentage
of the hits like that.
So let's say that I have the requirements,
the 95% of the hits on my flask web op need to
be handled within one second.
Then, it's best to create a graph
that shows you that percentage.
And that is exactly what this graph does.
So here I have the flask request legacy seconds bucket.
I'm filtering for the bucket that is one second.
I'm doing this by job,
so that I have one line per job,
so that I can bundle multiple apps,
so that I can compare my apps,
and how my apps are performing.
And this I divide by the flask
request legacy second count,
and this will give me a percentage
of how many of my requests were handled
in less than one second.
In the beginning of the previous lecture,
I was just hitting slash query,
so slash query was very quick to execute.
So all these requests were within a second.
So I have value one here,
100% of the requests were okay.
But then I start executing sleep,
and sleep takes definitely more than one second,
so the percentage is going down almost to zero
because I was running this slash sleep in a loop.
Then at some point, I canceled this loop.
And if I go back to my console,
you see now that I'm looping another script.
So, this was the first one I did,
so while true, do a curl on slash sleep.
That takes some time to return.
And now, I'm doing every second a query on slash query.
So, if I press enter,
you can see the time to execute
each query is all within one second.
So I keep this running, and that is what has been
executing for the last 5 to 10 minutes.
So you see now that now that
we are running another query,
the score is improving,
and it will go to 1 again.
So I've already refreshed this page, you see now
all my queries are slash query,
which have a very low execution time.
So now, all of my queries,
100% of my queries, are lower than one second.
But if I would cancel this,
and I went to again asleep,
maybe just one query,
then you will definitely see
a bump in the queries again.
So now, as the two of them,
have one that executed at six, and one at four,
and now let's run the normal query again.
So now we have normal traffic,
and now we hit two times the slower endpoint.
So let's wait a couple of seconds.
And if it didn't, hit execute again,
we see again, a bump.
This .98, so still,
if you put it on alert
at 95, so now (mumbles) is 95% needs to be
delivered in less than one second.
Then, we are still within limits.
This formula gives you a percentage,
but if you want to know the Apdex score,
which is a more universal way of knowing
how the application is performing,
so the Apdex stands for application performance index.
Then you can use this formula,
where we are not only going to use the one second
legacy bucket, but also our target.
Let's say that our target is that we have
all the requests done in less than a quarter of
a second, so .25 seconds, that up to our targets.
What we tolerate, whatever is between .25 and one.
If we divide that by two,
that's an approximation of the Apdex score.
It's not exactly the Apdex score,
as you will find them in commercial performance
analytics tool, but it comes very, very close.
Even then, execute it.
Then you will see roughly the same graph,
but it's closer to the real Apdex score.
So, here, whenever it falls under let's say, .95,
you would set an alert.
The difference really here is that you have
a target score so everything
should be less than .25 seconds.
But you allow for requests to be below one.
Everything that is higher than the graph drops,
and then you can report on that.
So this is the end of this lecture.
So these graphs are very interesting to use.
You should definitely try them out,
and if you have any questions about this approach,
use a Q&A and I'll try to help you.