So there is one thing that we still need to do, and that is actually passing the log entry.
So right now we have that whole log is one line, but we actually want to have them as individual key
value pair, just like these values here.
So we want to level 30 time, the time stamp value, et cetera.
So we want these values actually split and passed in this kind of structure so we can actually search
and filter those values as well.
And that will also give us a timestamp which later we can use to filter based on time.
So this is just the first draft, so to say.
So the final step, we're going to configure that Jason parser.
So let's go back to the config map here and configure the parsing for both application logs.
So after Fluent has read the application logs, we're going to add a parser here.
So I'm just going to paste in the code that I have.
So right here we are just matching everything that comes from this source log is basically the attribute
that holds the whole log entry.
So that's the key name.
And this is the parser multiform.
That is the plugin that we saw influent D container logs.
So this is where we use it, basically with multiform that you can define different formats.
We're going to use Jason, because both of our applications are logging in JSON and we're going to put
this configuration in the pattern.
So the format is, Jason, the time key that is going to be added is can we call the time?
And this one will just keep the time attribute in the log as well.
And there is one more thing that we have to do in order to make this work.
So basically, Java, Evernote blog entries will be past using this filter.
And here we are going to create separate indexes for these two applications.
And the reason why is because those two applications have the same filename log level with two different
data types.
So ElasticSearch won't be able to create one index with this filename that has two different data types.
That's why we're going to create separate indices for both.
And we can do that by defining own match for each application.
And here, instead of matching both, we're going to match each individually for matching Java tag.
And this is the index name.
So we're going to call it Java logs.
And we also need to adjust this one because this is the file where the logs get Bufford.
So obviously we need separate buffers for both.
And I'm just going to copy this one and create the second match, second forwarding for node up.
Let's call it node.
It looks index and this is it.
So it's updated.
We're going to restart the demon set and we should see our logs inelastic in a couple of seconds, all
flow and pods restarted.
So let's go back to eye actually removed the old Ines's.
So we have a clean slate.
And here you see those two Ines's got created.
This one has nine entries and this one has 12 entries.
Now, let's go to keyboarder index and create one.
So this name here, this name pattern will actually match both of industry so we can create one Kibwana
index that contains or that holds multiple elasticsearch indices so you can do filtering and search
on that level.
So we're going to go and do that.
And here you see time filled selection, which we didn't have previously when we created the Kibwana
index, and this comes from this log, this structure in see, so we moved all the key value pairs out
of that field, including the time filled.
And we also named it.
Here, and that's why we have a time stamp filled selection on the metro level of the index, so we're
going to create the index here.
So let's go back to Cubano and here we have the list of looks, we have both looks mixed here and you
see Timeful to you that we didn't have before because of this time, feel that we chose an indication.
And here you have a separate column for that as well, so you can filter for the time stamp, et cetera.
So we have Java entries here and down here.
You have no interest in here.
You see, the time is in the same format.
In other thing is that if I spend any one of those logs, you also see that our data got the structure.
So we have level info, logger method and all those different values as structured key value pairs.
And same for no Jessep.
If I spend one of those here again, we don't have this log take anymore.
We have again, message level, take time and all this takes separated so you can actually now filter
and log all this stuff.