Is your feature request related to a problem?

We are trying to replicate a logging setup that we can do with ecs-logging-java with log_ecs_reformatting. We can't expose certain ECS, ecs-logging-java and custom fields trough the APM Java Agent apm-agent-attach-cli.jar

Describe the solution you'd like

include a nominal or generic way to set the ecs-logging-java Encoder/Layout parameter in apm-agent-attach-cli.jar Konfiguration. (We are using --args-provider)

nominal

maybe with a prefix like ecs_logging?

ecs_logging_includeOrigin=true
ecs_logging_additionalFields=key1=value1,key2=value2

The ecs_logging_additionalFields reuses the JUL nomenclature from https://www.elastic.co/guide/en/ecs-logging/java/current/setup.html#_use_the_ecs_encoderformatterlayout

Obivous disadvantage: Once the ecs-logging-java team adds a new field, this needs to be repeated in APM Java Agent

generic

some kind of generic approach like anything after ecs_logging_ will be passed to ecs-logging.

ecs_logging_includeOrigin=true
ecs_logging_additionalFields=key1=value1,key2=value2
ecs_logging_futureValue=foo
ecs_logging_misspelledValue=bar

Obivous disadvantage: ecs_logging_misspelledValue. Where would I see the error message that I misspelled it. Ideally in the APM Java Agent log file. https://www.elastic.co/guide/en/apm/agent/java/current/config-logging.html#config-log-file

Describe alternatives you've considered

For additionalFields we considered abusing existing fields like "service.name" and concat all information that we need into this field. Then write some ingest pipelines that split up the field and cleans up the mess. This must then be done for Log and APM ingests. This is shady and not obvious.

For includeOrigin we failed to find a solution

Additional context

We hope/assume that the APM-Java-Agent team reuses the source code from ecs-logging-java as a dependency so our feature request is realisitc.

This is related to #1881