First of all, what is ElasticSearch?
It is a datastore for search and analytics, that's why the name ElasticSearch, it can store data of
many different forms like SQL databases, for example, that stored data in structured form only, which
is data in tables and rows and columns.
ElasticSearch can also store all sorts of unstructured data, meaning without any predefined form and
structure.
Its main strength is the powerful search mechanism.
ElasticSearch is based on index concept.
Dividing data and storing them in indices makes them more efficient and faster search possible.
We will be creating such indices in the demo part.
ElasticSearch usually gets deployed as a part of a famous elastics stick, which includes the three
components you need for all its use cases.
You have the elasticsearch itself, which stores the data, but the data must come from somewhere,
right?
So you have Loks dish that aggregates and processes data and sends it to ElasticSearch to be saved.
So processing the data can mean reformatting the data, adding some meta information like timestamp
or where this data is coming from, etc. So you have more information, higher quality data inelastic.
And finally, you of course, need to see this data in an easily digestible forum in a user interface
as well as you need to be able to search and filter it just as easily.
So for that you have Caivano.
This is the third component, which is very flexible in part because you can do a lot of stuff in its
user interface.
You can create very complex queries and build your data visualization dashboards where you see all the
relevant information you need.
In a nice overview in our set up along with Kibwana in ElasticSearch, we will use an alternative to
lock sesh, which is fluency.
I think it's better fit for communities, ecosystem and setup, but the concepts are really similar.
Flu and data is basically the same as LOCKSS, which is aggregating the data, preparing it before sending
to elastic.
But as I said, I think it's better fit for a Cuban.
It is specifically an elastic ecosystem.
There are a bunch of other tools as well, with obviously each one having its own pros and cons.
So our use case with elastic stake will be collecting, searching and analysing application logs, which
is one of elastics use cases.
As you saw previously, our two applications are already logging the data in Jason format, which is
much easier for the collector tools like fluence dialogue.
So that's why we just formatted it into Jason floor and we will then collect these log entries that
our applications are producing, process them like, format them a timestamp or pod where the log data
is coming from in some other important metadata and send them to ElasticSearch.
Then using Kibwana, we can query this data and filter them or search them.
So we have an easy overview of the logs.
We can also search across this log data from different applications.
So we're going to see an example of that for you to imagine the advantages of such a system deployed
in your company, this cluster.
Imagine the following scenario.
Let's say you have a microcircuits application with 10 or 20 micro services that are connected to each
other or communicate with each other.
And they have two common services.
Now, suppose you see an exception in one of your micro service applications, which occurred at 10
a.m. yesterday, and you don't know what caused it or what consequence it had on other services.
With the elastic stick set up, what you could do is you could query through Cheban up all the logs
of all micro services and those two common services around the same time of 10 m yesterday.
So you can better visualize the correlation in other use case would be you could actually configure
for each of your applications sort of a dashboard or visualization dashboard incubator that shows you
immediately with a very easy overview, how many exceptions or what exceptions have happened in each
of your micro service applications and then use the data to analyze if there is a problem in your application.
If you're logging X's information, you can also create overview of how many EXIS requests each application.
Gets per day and then you can compare this data between the applications or different days now compared
to traditional way of looking through log files and scrolling through a bunch of log entries of different
applications and then trying to figure out the correlation between them and the cause of exception.
The advantage is pretty obvious.
So there are all sorts of different things that you can analyze, but easily visualizing the data from
your application logs.