1

00:00:02,950 --> 00:00:05,210

First of all, what is ElasticSearch?



2

00:00:05,500 --> 00:00:12,610

It is a datastore for search and analytics, that's why the name ElasticSearch, it can store data of



3

00:00:12,610 --> 00:00:20,440

many different forms like SQL databases, for example, that stored data in structured form only, which



4

00:00:20,440 --> 00:00:23,140

is data in tables and rows and columns.



5

00:00:23,410 --> 00:00:30,850

ElasticSearch can also store all sorts of unstructured data, meaning without any predefined form and



6

00:00:30,850 --> 00:00:31,480

structure.



7

00:00:31,570 --> 00:00:35,050

Its main strength is the powerful search mechanism.



8

00:00:35,290 --> 00:00:38,770

ElasticSearch is based on index concept.



9

00:00:38,770 --> 00:00:45,040

Dividing data and storing them in indices makes them more efficient and faster search possible.



10

00:00:45,310 --> 00:00:48,250

We will be creating such indices in the demo part.



11

00:00:48,550 --> 00:00:55,630

ElasticSearch usually gets deployed as a part of a famous elastics stick, which includes the three



12

00:00:55,630 --> 00:00:58,840

components you need for all its use cases.



13

00:00:59,260 --> 00:01:05,500

You have the elasticsearch itself, which stores the data, but the data must come from somewhere,



14

00:01:05,500 --> 00:01:05,860

right?



15

00:01:05,980 --> 00:01:14,550

So you have Loks dish that aggregates and processes data and sends it to ElasticSearch to be saved.



16

00:01:14,830 --> 00:01:21,670

So processing the data can mean reformatting the data, adding some meta information like timestamp



17

00:01:21,670 --> 00:01:29,640

or where this data is coming from, etc. So you have more information, higher quality data inelastic.



18

00:01:29,650 --> 00:01:36,430

And finally, you of course, need to see this data in an easily digestible forum in a user interface



19

00:01:36,670 --> 00:01:41,170

as well as you need to be able to search and filter it just as easily.



20

00:01:41,450 --> 00:01:43,490

So for that you have Caivano.



21

00:01:43,510 --> 00:01:49,690

This is the third component, which is very flexible in part because you can do a lot of stuff in its



22

00:01:49,690 --> 00:01:50,650

user interface.



23

00:01:50,860 --> 00:01:59,260

You can create very complex queries and build your data visualization dashboards where you see all the



24

00:01:59,260 --> 00:02:01,840

relevant information you need.



25

00:02:01,840 --> 00:02:09,610

In a nice overview in our set up along with Kibwana in ElasticSearch, we will use an alternative to



26

00:02:09,610 --> 00:02:11,910

lock sesh, which is fluency.



27

00:02:12,280 --> 00:02:18,370

I think it's better fit for communities, ecosystem and setup, but the concepts are really similar.



28

00:02:18,580 --> 00:02:24,640

Flu and data is basically the same as LOCKSS, which is aggregating the data, preparing it before sending



29

00:02:24,640 --> 00:02:25,300

to elastic.



30

00:02:25,540 --> 00:02:28,930

But as I said, I think it's better fit for a Cuban.



31

00:02:28,930 --> 00:02:32,590

It is specifically an elastic ecosystem.



32

00:02:32,590 --> 00:02:38,350

There are a bunch of other tools as well, with obviously each one having its own pros and cons.



33

00:02:38,680 --> 00:02:46,450

So our use case with elastic stake will be collecting, searching and analysing application logs, which



34

00:02:46,450 --> 00:02:48,580

is one of elastics use cases.



35

00:02:49,510 --> 00:02:56,410

As you saw previously, our two applications are already logging the data in Jason format, which is



36

00:02:56,590 --> 00:03:00,310

much easier for the collector tools like fluence dialogue.



37

00:03:00,320 --> 00:03:07,270

So that's why we just formatted it into Jason floor and we will then collect these log entries that



38

00:03:07,330 --> 00:03:15,610

our applications are producing, process them like, format them a timestamp or pod where the log data



39

00:03:15,610 --> 00:03:20,230

is coming from in some other important metadata and send them to ElasticSearch.



40

00:03:20,440 --> 00:03:25,690

Then using Kibwana, we can query this data and filter them or search them.



41

00:03:25,740 --> 00:03:28,270

So we have an easy overview of the logs.



42

00:03:28,480 --> 00:03:32,110

We can also search across this log data from different applications.



43

00:03:32,500 --> 00:03:38,560

So we're going to see an example of that for you to imagine the advantages of such a system deployed



44

00:03:38,560 --> 00:03:40,000

in your company, this cluster.



45

00:03:40,450 --> 00:03:42,130

Imagine the following scenario.



46

00:03:42,550 --> 00:03:49,180

Let's say you have a microcircuits application with 10 or 20 micro services that are connected to each



47

00:03:49,180 --> 00:03:51,610

other or communicate with each other.



48

00:03:51,760 --> 00:03:54,110

And they have two common services.



49

00:03:54,520 --> 00:04:02,380

Now, suppose you see an exception in one of your micro service applications, which occurred at 10



50

00:04:02,380 --> 00:04:09,490

a.m. yesterday, and you don't know what caused it or what consequence it had on other services.



51

00:04:09,850 --> 00:04:18,040

With the elastic stick set up, what you could do is you could query through Cheban up all the logs



52

00:04:18,040 --> 00:04:25,870

of all micro services and those two common services around the same time of 10 m yesterday.



53

00:04:26,230 --> 00:04:32,380

So you can better visualize the correlation in other use case would be you could actually configure



54

00:04:32,380 --> 00:04:40,180

for each of your applications sort of a dashboard or visualization dashboard incubator that shows you



55

00:04:40,180 --> 00:04:48,670

immediately with a very easy overview, how many exceptions or what exceptions have happened in each



56

00:04:48,670 --> 00:04:55,330

of your micro service applications and then use the data to analyze if there is a problem in your application.



57

00:04:55,690 --> 00:05:02,500

If you're logging X's information, you can also create overview of how many EXIS requests each application.



58

00:05:02,730 --> 00:05:08,460

Gets per day and then you can compare this data between the applications or different days now compared



59

00:05:08,460 --> 00:05:15,150

to traditional way of looking through log files and scrolling through a bunch of log entries of different



60

00:05:15,150 --> 00:05:20,140

applications and then trying to figure out the correlation between them and the cause of exception.



61

00:05:20,490 --> 00:05:22,490

The advantage is pretty obvious.



62

00:05:22,830 --> 00:05:28,860

So there are all sorts of different things that you can analyze, but easily visualizing the data from



63

00:05:28,860 --> 00:05:30,180

your application logs.