[receiver/vcenterreceiver] No attributes to define datacenter

[StefanKurek]

Component(s)

receiver/vcenter

What happened?

Description

Currently, when collecting against any environment, none of the existing resources have resource attributes that define which datacenter they belong to. If there were multiple datacenters, this could cause confusion and even allow for the possibility of two resources with the exact same resource attribute key/values.

Steps to Reproduce

Collect against any vCenter environment.

Expected Result

All returned resources have a vcenter.datacenter.name resource attribute

Actual Result

No returned resources have resource attributes related to datacenter

Collector version

v1.5.0/v0.98.0

Environment information

No response

OpenTelemetry Collector configuration

extensions:
  basicauth/prom:
    client_auth:
      username: [PROMUSER]
      password: [PROMPASS]

exporters:
  prometheusremotewrite:
    endpoint: [PROMENDPOINT]
    auth:
      authenticator: basicauth/prom
    resource_to_telemetry_conversion:
      enabled: true # Convert resource attributes to metric labels

processors:
  batch:
    # https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor/batchprocessor

receivers:
  vcenter:
    endpoint: https://[VCENTERHOST]
    username: [VCENTERUSER]
    password: [VCENTERPASS]
    tls:
      insecure: true
    collection_interval: 1m
    initial_delay: 1s

service:
  extensions: [basicauth/prom]
  pipelines:
    metrics:
      receivers: [vcenter]
      processors: [batch]
      exporters: [prometheusremotewrite]

Log output

No response

Additional context

No response

[github-actions]

Pinging code owners:

• receiver/vcenter: @djaglowski @schmikei

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[djaglowski]

To clarify, this attribute would be applied to all resources emitted by the receiver, because all the components described are always associated with one data center. Is that right?

If so, this makes sense to me. We need to add it first as an optional resource attribute and can enable it by default in a future version. Same mechanism as #24071 (comment) should be used.

[StefanKurek]

@djaglowski yep, right now I think it makes the most sense to put it on every single resource type. I can update the related PR to do as you suggested with the optional resource attribute.

[StefanKurek]

@djaglowski You mention a warning log in the linked issue with a version (when is this log emitted?). Is this relevant to this attribute as well?

[djaglowski]

Yes, we'll have to do it before enabling the attribute by default. Adding it immediately seems fine to me.