Here I see with the wording here that this is the conflict field, because here in the node it has a
value of a number or integer, and in Java it has a value of string, which is info.
So how LASTIC indices actually work is that when you send ElasticSearch data entries, it will create
an index.
And based on the first very first entry that you send it for that index, it will also create the schema.
So it will create the fields and it will create data types for each field.
So for example, when the next log entry comes in with different fields, those fields get added to
the schema.
However, if the next entry sent to a plastic contains a field name that already exists in the schema
but the value is of different type, then ElasticSearch will not accept it.
So basically, based on your configuration, it will either discard that value or it will give you an
exception that you can't add this very because it doesn't match the schema.
And this is the case with these two FS because we have the same field name with two different value
types.
Now, when you are logging in your application, you can, of course, try to adjust it.
So in this case, we could go to know JS and configure Peno to log string instead of no.
But if you don't have so much control over these fields, for example, if you're collecting logs from
other application, then obviously you can change the code.
In that case, you have to just create different indices as we created.
Now, this is maybe an important point here to mention when working with Lustick indices and then displaying
them and keep on them.
So this is exactly the mapping conflict mentioned here that says a field is defined as several types
string an integer.
Another thing that I also want to show you is an exception in Java.
So if I expanded this was our exception log in here.
Also important that you actually see the whole stack is one log entry.
So you also have this multi-line log support.
So this is the end of our setup.
So we basically have both application logs in the elasticsearch and we have them visualized in Kobana.
So of course, if you want to collect and store logs of other applications like Kibwana itself or Ingenix
Ingress ElasticSearch, you can add them to the flow and configuration and pass them using other parsers
and also save them as separate Ines's.
So you have that data as well.