Ecs: Add new top level field "environment"

[vbohata]

I propose to add a new top level field named "environment" as discussed here: #143
This field should be reusable because usually it is needed just top level environment for everything but rarely host and app environment can be different.

I propose following fields:

• environment.name
  (user-defined environment name like "test", "sandbox", "quality", "production")
• environment.type
  (type of this environment like "test", "production")

Examples:
environment.name: sandbox
environment.type: test

environment.name: production
environment.type: production

Maybe there could be also environment.id for env unique identification and environment.kind with values like "onpremise", "cloud".

[webmat]

Very interesting. I have always used environment as a single string (production, staging, development). But I've sometimes felt the need for environment types ("like prod").

[jakauppila]

We also utilize environment names and types (nonprod/prod) and would see value in this.

[SHolzhauer]

In my opinion there is value in this. We use multiple environments too and are already adding fields for this. If this could be incorporated in ECS and down the line usable in the kibana apps that would add amazing value; For example SIEM app to only work with environment.type:production

I would suggest to use the (as far as I know) widely used/known DTAP for the environment.type field.

environment.name
User defined string for the environment, test, sandbox, windows-development, etc.
environment.type
Values: development, test, acceptance, production
environment.code
User defined code for the environment, eg: tst, sbx, windev, prd

[ebeahan]

@cyrille-leclerc is currently working on an RFC for environment field(s) use cases.

[jasonrhodes]

I'm just catching up with this discussion as well as the service.environment discussion in that RFC: https://github.com/elastic/ecs/pull/1070

I'm curious about how this "top level environment" field somehow made its way into the "service" block? From an infrastructure metrics perspective, it seems like environments may often live outside of services. If we want to show all hosts or pods based on environment, I don't think we could use service.environment for that.

Are there other conversations about environment elsewhere?

cc: @sorantis @kaiyan-sheng @cyrille-leclerc