I'm just looking for some general ideas of mapping java log fields to the elastic common schema.
A couple fields are already taken care of, such as log.level and process.thread.id, but there's a couple fields that I feel like are missing from ECS. Such as transaction id, class name, and class method.
I was just hoping to get some general ideas from the community as to what everyone thinks these fields should be mapped to.
In general, we are following the below approach,
whenever we need to map any field which is missing in ECS then mapping that under a custom object, under the corresponding major section. If ECS includes these fields in future ECS versions, there will be no conflict, and we can migrate from our custom object.
Eg: for class name, if we can map as log.class_name then in future ECS version if the same field get mapped log.class.name then we will be having a conflict (field vs object or vice versa)
I didn't think about looking at the apm fields. None of those are documented in the reference. Thanks, we're going to use transaction.id for that part.
As for the classes and methods, is there a reason you made it a custom object under log or just to avoid possible future conflicts?
It would be nice if the schema implemented a class field, then we could have class.name, class.method, and class.instance
Usually, I think like, which major section this field will fit. I thought classes and methods are some information about log data. So, if you think it will fit better under process.thread, then I would say create custom obj under process.thread.customobj.class_name. This way we will not have any impact with ECS updates in the future.
If there are multiple class fields then it might be better to have a class obj.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.