Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DataCenter Resource #1409

Open
hdost opened this issue Feb 23, 2021 · 7 comments
Open

DataCenter Resource #1409

hdost opened this issue Feb 23, 2021 · 7 comments
Assignees

Comments

@hdost
Copy link

hdost commented Feb 23, 2021

What are you trying to achieve?
Being able to track data center related information for anything running outside of a Cloud Provider.

What did you expect to see?
Semantic Conventions around DataCenters. I'm not sure if this should be merged somehow with the cloud provider.

Additional context.

When running in a Hybrid environment I should be able to track things whether they are in corporate datacenters owned by the company or datacenters managed by a cloud provider it should largely be interchangeable where possible.

@Oberon00
Copy link
Member

Which information do you want to track about the datacenter? I feel like it would make sense to add it to the host semantic conventions at https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/semantic_conventions/host.md. If it's just a single identifier, maybe host.datacenter_id or host.location.

hdost referenced this issue in hdost/opentelemetry-specification Feb 23, 2021
* Would be good to unify potentially with "Cloud" conventions. To try to
  be a little more generic.

Relates to #1458
@hdost
Copy link
Author

hdost commented Feb 23, 2021

@Oberon00 I put together a draft because. I feel like you might be right about the fact that maybe it should go on the host potentially, but then also would we want to have that true of the cloud.md ?

@Oberon00
Copy link
Member

but then also would we want to have that true of the cloud.md?

What do you mean? If the attribute should apply to things hosted in the cloud too? I think so. E.g. host.type is also rather cloud-specific. When hosted in the cloud, you should probably fill in the availability zone (as opposed to just the region) in the datacenter attribute.

@hdost
Copy link
Author

hdost commented Feb 23, 2021

I guess my question is around an application which is running across both on premises would conceptually the host could run in either a "cloud" or "my" DC or even "my" Colo. I understand that there should be some special fields for cloud related things, but at some level there is overlap between an owned host, a colocated host and a cloud host.

I think that host.type actually can be used. I know that in our infrastructure we allocate many of specific builds similar in concept to what you might see so you might have a "standard", "memory",etc. focused server. and that could slot into there just fine.

However when talking about being able to aggregate across different slices I wonder if it makes sense to have something that cuts equally between different hosting environments. Certain things in cloud don't necessarily matter that will in Owned or Colocated scenarios. However I don't know that the tags should be so different for everything. Giving the user an ability to contrast across metrics (or traces, etc) regarding the hosting scenario.

@hdost
Copy link
Author

hdost commented Mar 10, 2021

Not sure if anyone else has opinions on this.

@hdost
Copy link
Author

hdost commented Sep 16, 2024

@Oberon00 can you please re-open the PR associated with this?

hdost referenced this issue in hdost/opentelemetry-specification Sep 16, 2024
* Would be good to unify potentially with "Cloud" conventions. To try to
  be a little more generic.

Relates to #1458
@trask
Copy link
Member

trask commented Sep 16, 2024

moving this issue to https://github.com/open-telemetry/semantic-conventions

@trask trask transferred this issue from open-telemetry/opentelemetry-specification Sep 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants