ecs.version seems hardcoded as 1.2.0

[Fr33Radical]

Hi, Is it possible to upgrade the ecs.version use to 1.10? Is it an issue related to https://github.com/elastic/ecs-logging-java/issues/38 because the ecs fields are not generated automatically?

The ecs version looks hardcoded in this class line 52: https://github.com/elastic/ecs-logging-java/blob/fb287cc003ca48cbb9440243b50d79031e2dfa4f/ecs-logging-core/src/main/java/co/elastic/logging/EcsJsonSerializer.java

Regards

[eyalkoren]

Is it possible to upgrade the ecs.version use to 1.10?

What is the meaning of upgrading? What is the problem you need fixing?

[Fr33Radical]

Hello, The meaning is that I am sending the value source.subdomain to ELK and it is not indexed in Kibana. We use that field for different sub environment. For instance, 'ACCEPTANCE-A' or 'ACCEPTANCE-B' which contains different version of the service for different release date. This field only appear in ECS.version 1.7. It appears that the value of ecs version comes from the project java-ecs-logging (the value 1.2) and that Kibana does not recognized the field source.subdomain. Hence, this field is supposed to be indexed by default since it is ECS related.

[felixbarny]

The value of ecs.version does not impact which fields get indexed. You might have to update your ES index template to specify how source.subdomain should be indexed. Also, have you tried to refresh the index pattern in Kibana?

[Fr33Radical]

Hello, My collegue effectively update the ecs.version in the backend side of elasticsearch. It worked and we were wrong about thinking it was due to the value hardcoded. Though it's confusing to see ecs.version to 1.2 even if it is 1.10 but that is not really a concern.

I close this ticket. Thank you for your help, appreciated.