Yes, it looks like ECS should help you accomplish your goal. Note that the "Use cases" section in the ECS repo is quite out of date, so you should ignore it for now. We'll be making a big push to get better ECS documentation in time for the release of 7.0.
There's a few ways you can start migrating to ECS.
The upcoming release of the Elastic Stack 7.0 will come with a full set of Beats that are migrated to ECS. If you plan on upgrading to 7 in short order, you may want to wait for that, and get most of this migration work done for you automatically. If you're using the Beats templates and example dashboards, they will also be migrated for you, mainly using Elasticsearch field aliases. In other words, if you had visualizations that depended on
nginx.access.remote_ip, Filebeat 7's index template will have the field
nginx.access.remote_ip be an alias to
source.ip, ensuring all of your visualizations just keep working. After the stack upgrade, you can then adjust all of your visualizations as time permits, to directly refer to the ECS fields.
If you'd rather not wait for 7.0, you can start migrating to ECS right away. Being a Logstash user, I assume you're comfortable managing your own index templates. This is all that's required in order to start using ECS with Elastic Stack 6.x. I say this because you can't use the 6.x Filebeat index templates, as it has a
source field of type
keyword, whereas ECS has
source as an object, with multiple fields instead.
But if you create your own index template to match ECS (you can start from the
template.json in the ECS repo), then you're good to start creating indices with it, and start benefiting from these common names.
One last note: you'll undoubtedly have fields that don't map to ECS at some point. Contrary to other schemas, with ECS you're free to define more fields in your template, that aren't specified in ECS. You should try to nest them in such a way that won't conflict with future versions of ECS. If you nest your fields under your organization name (e.g.
acme.x_forwarded_for) or nest them under a product name (
nginx.x_forwarded_for) you should be good.