Fields vs. tags for app/service/environment identification


In our configuration, we are planning to use a single unified ELK stack deployment for all our development needs (i. e. multiple products, each consisting of multiple services, each deployed in multiple environments). This means that we have to separate incoming events at Logstash level for storage in the appropriate indices. The index name will include app name, service name and likely the environment name in order to support different versions of the code having different logging schemata.

I see two different options:

  • either providing a set of tags (e. g. [ "app=foo", "service=bar", "environment=qa" ]) to the logger implementation and then parsing those tags into key-value pairs at Logstash level,
  • or providing extra fields (e. g. { "app": "foo", "service": "bar", "environment": "qa" }) via some sort of contextual filter and then simply referring to them at Logstash level to construct the index name.

What would be a better/more idiomatic way of doing that?

Using fields rather than tags seems much more natural to me.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.