Herion and welcome back now in today's we will be discussing about the unified cloud, what Egypt needed
is whenever you go ahead and launch an easy doing things, there are certain metrics that are captured
by default.
So if you look into the screenshot all year and this is something that you have already seen, so some
of the metrics that are captured by default include CPU utilization, some of the network related metrics,
some of the disk related metrics and so on.
So although this is good, but in production environment, there are a lot of other metrics related
to various things like memory, disk usage, etc. that are very important to be captured.
And Allen needs to be set based on that.
So the default set of cloud watch me takes are something that are not really very helpful in the overall
proactive approach to detect issues.
So when we discuss about the challenge on, more metrics are needed.
So some of the metrics that are very important can be related to memory metrics can be related to this
usage matrix, the ability to manage that and so on.
So I still remember in one of the organization where I had recently joined, we were only two members
and one of them who was a senior member since many years he was on leave and suddenly the database went
down and people were really after me, like, what is happening?
So then we further investigated.
It was found that the disk was completely full to 100 percent of the disk was full and the database
was not able to search the connection there.
So temporarily, because inevitably even the Ebb's extension takes time.
So if you want to extend your Ibbs volume, that is something that can also take a little amount of
time.
So temporarily that we went ahead and we used to delete the logs, whatever logs were, their audit
logs, some of the database logs or any other logs.
Temporarily, we went ahead and deleted them so that the database started to run.
However, this kind of issue could have been solved if there was a disk usage metrics that were available
and the alarm was set based on that.
So this is one of the things that is very important in production environment.
And the challenge, too, is related to log monitoring.
So a typical server can contain a lot of important log files.
It can range from system log files to the application log files.
Now, during debugging of issue, it can be a security related issue or application related issue.
It is important to have a log files at hand.
So, for example, let's say that you have what you see two instance and all of the logs related to
application is stored in a file file or log.
And you do some recent application is not working and the developer has to gain insight into what exactly
is happening.
So what you'll have to do, you'll have to give access to the developer, to the U.S. to instance so
that he can log in and he can go ahead and read the file dot log and perform the troubleshooting accordingly.
Now, this sort of approach has its own set of disadvantages.
And the first disadvantage is that the access must be given to the server, to the developer.
So this is one of the important disadvantages.
So, for example, if there are 100 developers, you might have to give access to all of them.
And this is something that you do not really need.
Second primary disadvantage is that it is surrogate's terminated.
The logs are lost.
And this is specifically applicable to the easy two instances that are part of the auto scaling group.
And the third disadvantages that there is no way to set up an alarm on certain conditions or create
complex filters.
So, for example, let's say that you have various EDV delete related request from the public Internet.
This is something that you do not really need.
So there can be alarm that can be set on it.
However, if the logs are stored locally on the server, setting up an alarm or conditions is something
that is not a very straightforward approach.
So a better way for logging related use case is you can go ahead and create a central log server where
all of your devices may be firewall servers, network switches.
They can send the data to a central log monitoring server business, which you can create an alarm and
also create complex filters.
So in order to overcome these two challenges related to the matrix collision as well as the localization
that we were discussing, Adris has come up with a solution with the help of the cloud.
What a unified Egin.
So Cloud was unified.
Egin allows customers to capture both the internal system level matrix.
It can be disk usage and memory usage, et cetera, as well as perform the localization.
So if you look into the overall flow architecture, you have a cloud.
What unified Egin that must be installed within the EU instant and this unified agent has the capability
to go ahead and send a matrix related to disk memory and others and also send the logs that are part
of the server to a centralized dashboard of cloud.
Great.
So before we conclude, let's go ahead and have a quick.
Now for today's video, I have I see two instances that is running, and as we know, it will quickly
go to the monitoring.
There will be a different set of metrics related to CPU utilization, networking networks and others,
data captured.
However, this is something that we have already discussed is not really sufficient for the production
environment.
So what I have done is I have already installed a unified agent inside this Ishita instance here.
Let me quickly show you.
So currently connected to this so very quickly to a system QTL status on the Amazon cloud Vortigern,
you will see that the cloud agent is active and running.
So this is basically the unified agent that we were discussing.
So this unified agent is currently sending both The Matrix as well as the log related information.
So let's quickly look into both of them.
So under the cloud watch console, open up the log group Solidere.
And within the law group, you have a large group named Messages, which basically has a log stream
of intensity.
So intensity and there will be zero.
So you can quickly verify.
So this is basically and within you basically have all the contents which are part of the world of messages
folder.
So this is what the cloud what unified agent is sending.
The second thing that we were discussing is The Matrix.
So let's go ahead and also explore the matrix here within you.
You have a custom namespace of cloud.
What agent?
And within you there are multiple matrix sets that are captured.
So let's open one among them, the first one here, and let's look into the Matrix.
Yet they are mostly related to the file system like disk used that disk anodes free and so many others.
So let's go back to the cloud.
Watch here and let's open up the other set of Matrix.
Let's look into what is been captured.
So you have a memory used personal data of a Nextag BCB connection established.
You also have a swap related detail.
So if I quickly open this up, you'll also see a certain set of graphs that you can also quickly modify.
So if you do not really need a line, instead you need a number that is also something that can be looked.
So if you look at memory use percentages, eleven point nine percent and so on, that's great.
So I hope with this you understood the basics of cloud.
What unified agent?
So before the unified agent was launched, there were various other ways people used to make use of
scripts to capture memory matrix, disk usage matrix and send them to the cloud watch console and also
for the monitoring related area.
You used to have a cloud watch agent which used to do the job related to the logs collection.
However, with the unified agent, you have a single agent that can do both of these things.
So that's the overview about the unified agent.
And with this will conclude today's video.