# Elastic Common Schema and Logstash and Ingest node processing tagging
**URL:** https://discuss.elastic.co/t/elastic-common-schema-and-logstash-and-ingest-node-processing-tagging/194317
**Category:** Logstash
**Tags:** ecs-elastic-common-schema
**Created:** [August 7, 2019, 7:46pm UTC](https://discuss.elastic.co/t/elastic-common-schema-and-logstash-and-ingest-node-processing-tagging/194317 "2019-08-07T19:46:14Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@tarp](https://discuss.elastic.co/u/tarp)
#### Post date: [August 7, 2019, 7:46pm UTC](https://discuss.elastic.co/t/elastic-common-schema-and-logstash-and-ingest-node-processing-tagging/194317/1 "2019-08-07T19:46:14Z")
Hi,
I'm working on setting up my custom sources to be more in line with ECS. In my filebeat configurations I had been adding the fields
environment (ex devl,qual,cert,prod)
building(ex buildingA)
location(ex thirdfloor)
ingest (pipeline)
Reading the ECS doc, I think the first three belong under the "host" top level.
host.environment
host.location
host.building
The last one I was using to track whether a message was processed through an ingest node (pipeline) or logstash.
I'm trying to figure out how this field would be better represented in ECS. Ideally, I want to record
Processed by logstash and which pipeline
or
Processed by ingest node and which pipeline
Does anyone have suggestions on how this should be represented? Or I could just use tags?
Thanks,
Tim
---
### Author:  [@guyboertje](https://discuss.elastic.co/u/guyboertje)
#### Post date: [August 12, 2019, 12:01pm UTC](https://discuss.elastic.co/t/elastic-common-schema-and-logstash-and-ingest-node-processing-tagging/194317/2 "2019-08-12T12:01:33Z")
I don't know if you will get an exact answer here.
One of the goals of ECS is the affordance of sharing Kibana visualisations, across teams and in "solutions" offered by Elastic and others.
If you need to use these visualisations then they probably will not have elements that visualise the mechanism the data was ingested - if you pick an ECS field to carry this data, be sure that any reused visualisations do not expect (and therefore use) the ECS field you picked for a different purpose.
In [this doc](https://www.elastic.co/guide/en/ecs/current/ecs-converting.html#ecs-conv) I see...
> - If no relevant ECS Extended field exists, consider keeping your field with its original details, or possibly renaming it using ECS naming guidelines and attempt to map one or more of your original event fields to it.
[ECS Naming guidelines](https://www.elastic.co/guide/en/ecs/current/ecs-guidelines.html#_general_guidelines)
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [September 9, 2019, 12:01pm UTC](https://discuss.elastic.co/t/elastic-common-schema-and-logstash-and-ingest-node-processing-tagging/194317/3 "2019-09-09T12:01:33Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
---
### Author:  [@webmat](https://discuss.elastic.co/u/webmat)
#### Post date: [November 29, 2019, 3:45pm UTC](https://discuss.elastic.co/t/elastic-common-schema-and-logstash-and-ingest-node-processing-tagging/194317/4 "2019-11-29T15:45:41Z")
Currently ECS doesn't define a whole lot, in terms of user's custom environments.
There's a few things you can use, in line with ECS.
- The "geo" field set can be nested in side host, and "geo.name" is for a free-form value (not the result of ip geolocation, for example. So concretely, perhaps you can capture the location in `host.geo.name`
- The rest I see should be in custom fields. The simplest place to add those is under `labels`, so perhaps `labels.environment: prod` & so on