[RFC] service.environment field

[cyrille-leclerc]

Proposal to adopt the service.environment attribute to qualify the environment from which an event is emitted (e.g. production, staging, qa, dev).

[webmat]

Thanks for opening this, Cyrille!

I agree this should go through the RFC process, even if at this time your proposal is only about adding one field. Reasons why I think the RFC is appropriate are 1) that Beats and APM appear to use different fields for capturing the environment and 2) there's been discussions in the past going in different directions than this, which you've noted in the concerns section 👍

There's wide agreement that capturing environment information is appropriate for ECS. So I have one procedural comment, but I'll adjust this when merging.

We'll get into all the requirements and deeper discussions at the other stages 💬

[webmat]

@cyrille-leclerc @roncohen

For the stage 1 proposal I'd like the RFC to be adjusted in a few ways.

Could you also add a link to #508 in the references? It's not only about environments, but I think it's also relevant.

Please rephrase the proposal a bit more generally, as a proposal to add support for capturing environment information in ECS. APM's current approach is of course a top contender, since it's already in use. But I'd like the proposal to also consider the more flexible approach discussed in #268. In this proposal, the contributor suggests creating this as a field set with a few fields. In the simplest cases where a user has only 2 environments, they could use simply environment.type: production|staging. But this approach opens up much more flexibility for other situations. Common examples are production deployments in different settings (multi-tenancy, different locations like "on prem" vs "cloud", different purposes like "main" vs "canary"), etc.

I'd like to loop in someone from the Cloud team and see if more robust support for environment details would be interesting to them.

[cyrille-leclerc]

See also

• https://en.wikipedia.org/wiki/Deployment_environment
• add environment attribute: Deployment Environment open-telemetry/opentelemetry-specification#606
• Convention: environment attribute (production, staging...) open-telemetry/opentelemetry-specification#752

[webmat]

Great additional resources, thanks for dropping these notes here.

When do you think you can open the PR for the next stage?

[cyrille-leclerc]

When do you think you can open the PR for the next stage?

I may have changed my mind brainstorming on open-telemetry/opentelemetry-specification#752 .

I'm wondering if we should support defining the "deployment environment" at multiple level: on the host itself and on the "deployed service".

I would like to discuss this with @sorantis

[sorantis]

Typically orgs/teams use custom tags for such information, which should be accomplished with labels available in the base ECS reference.

[felixbarny]

@cyrille-leclerc do other observability teams plan to adopt service.environment?

[cyrille-leclerc]

@felixbarny the standardisation of the "environment" qualifier is moving slowly.

Last time I discussed with @sorantis, we saw that

• most beats (metricsbeat, filebeat) use custom tags for the moment,
• it's not easy for infrastructure to talk of "environment=prod/staging/..." as infrastructure is often multi tenant
• Using "service.*" iis often not what people are looking at to characterize their infrastructure.

Moreover, for application logs, we plan to solve the problem of characterising the environment having the application agent being deeply integrated with filebeat.

I have recently discussed this ECS RFC with @webmat , we are likely to just standardise at the application layer, excluding the infrastructure layer for the moment.