Opentelemetry-specification: Server hostname, datacenter, region, availability zone missing in general conventions area:semantic-conventions

[ecourreges-orange]

I think we need to add conventions for attributes that help find problems related to specific servers and their topology.

The net.host.name attribute helps but perhaps it should be required for all spans, not just network ones.

It would be useful to add attributes like datacenter or region or az, trying to find some uniform naming between in-house and cloud hosting solutions.

The goal is to be able to make easy selections and groupings in GUIs or Trace Backends.

I am slighlty afraid that requiring several of these attributes for all spans will bloat things, but all of these information are usually present in logs, so why not in traces? Especially if we want to avoid logging each request while still keeping a good observability.

Comments welcome !
Thanks.

[arminru]

Hi Emmanuel!
Could you please have a look at the Resource Semantic Conventions (Environment>Cloud section) and specify if you're missing any attributes from there?
Thanks.

[ecourreges-orange]

Hi Emmanuel!
Could you please have a look at the Resource Semantic Conventions (Environment>Cloud section) and specify if you're missing any attributes from there?
Thanks.

Thank you, I had missed the concept of Resource!

Maybe I am not the only one to miss it coming from OpenTracing, so a link from the Trace Semantic conventions could be nice, and explaining the overlap between net.host.name and host.hostname/host.name ?
Some form of reminder that "static info" should be in resources, if one sees that one is repeating identical info on each span.

The only one missing in my list is what we call platform or environment (e.g staging, production, dev, sandbox), hard to find common wording here, but could be in a custom "Deployment Service".

Feel free to close.
Thanks.

[arminru]

Good point! I added links between them in #603 as a quick fix.
We should add general guidance on where which information should go as well if that's not already written down somewhere and also clarify potential overlap in a follow-up.

Feel free to propose the environment info you'd like to see in a PR and we're happy to discuss it there and maybe can come up with some even better wording. It sounds like a reasonable addition to me.

[cyrille-leclerc]

FYI I created an issue dedicated to the "environment" attribute: https://github.com/open-telemetry/opentelemetry-specification/issues/752

[ecourreges-orange]

I could go for environment_name which has the most votes so far, but I don't know where to document it as it would be the first and only attribute that is not in a namespace.
Right now, all attributes are namespaced and are in their own separate markdown file per namespace.
Here I would have to add it in the resource README.md directly in a new section (how to name that new section?) or create another markdown linked in a new section, but what would it be?
IMHO I don't see the obligation to have more than one item per namespace, but I agree that environment_name is still more clear than deployment.environment, and deployment.environment_name is over the top.
So, I am a little stuck...
Thanks

[Oberon00]

Right now, all attributes are namespaced

Good point. I'm fine with deployment.environment too (would even be my preferred name) but @tigrannajaryan had concerns about using the deployment namespace?

IMHO I don't see the obligation to have more than one item per namespace

I'd agree. And if we find a new property in the future that makes sense (deployment.tier to group multiple production environments to the same tier=production?) we can add it to this namespace.

@tigrannajaryan What do you think?

[tigrannajaryan]

My concern is not that it will be a group/namespace with a single attribute. That is fine. My concern is that we are occupying the "deployment" namespace and in the future we may want to use it for something else, unrelated and will not be able to because logically it has nothing to do with environment.

This is a weak concern though since I can't come up with good examples for how else "deployment" could be used. Feel free to ignore and go ahead.

[ecourreges-orange]

This is a weak concern though since I can't come up with good examples for how else "deployment" could be used. Feel free to ignore and go ahead.

My PR #606 is ready, so you may review it now.
Thanks.