Add app.environment to payload sent to APM Server

To run Elastic APM on multiple environments of the same service, you’d previously normally add a post-fix to the serviceName, e.g: my-service-staging or my-service-prod.

In Elastic APM 6.2 we’ll introduce a new environment property tailored specifically for this. This means that users should use the same serviceName (my-service), and instead specify the environment via a separate property whos value should be sent up to the APM Server using service.environment in the payload.

We need to settle on the name of the config option, but we’ll probably name it either env or environment.

Example usage:

require('elastic-apm-node').start({
  serviceName: 'my-service',
  env: 'production'
})

The associated environment variable would then be either ELASTIC_APM_ENV or ELASTIC_APM_ENVIRONMENT depending on what name we end up choosing.

Related APM Server PR: elastic/apm-server#366

[geoffreybergdoll]

Hi everyone,

I found a lot of discussions/threads/issues redirecting to here (maybe the only related issue still open…) so I guess the discussion is happening here.

IMO, the UI discussion is not the right debate. As the General APM fields include the service.environment field (see here), any agent should implement it, regardless of how (& how good) it is used within the UI.

BTW, do you know that every other agent (except .Net) implements it? python, ruby, RUM, go and java Troll: Do we really want NodeJs to be compared to .Net ? ;D

As a conclusion, I kindly request to have a second look at PR like #150 and to implement this field soon (if not now) in order to match the APM Server expectations and to be future-proof on this matter, regardless of how & when the UI will evolve.

Many thanks in advance to you, who read until here and who will upvote this long (sorry) comment.

[watson]

It was an unfortunate mistake that the environment variable was made public in the other APM agents before it was fully supported by Elastic APM. When we discovered this mistake we updated the docs to include a warning not to use it.

So it’s on purpose we haven’t released support for it in Node.js. If we could do so, we’d have removed the support in the other agents. Unfortunately, this would have been a breaking change, so we just kept the warning.

However, we’ve been hard at work implementing support for environment throughout Elastic APM since and we’re now ready to release it in the next version of the stack (v7.2). We’ll release support for this field at the same time in this agent.