postgresql receiver inconsistently does not include schemaname in tablename for some metrics

[cultpony]

Component(s)

receiver/postgresql

What happened?

Description

When retreiving the metrics for index and sequential scans (postgresql.sequential_scan and postgresql.index.scan), the tablename in the metricset is inconsistently constructed;

Sequential Scan Metrics will concat the schema to the tablename (schema.relation), while Index.Scan will only use the Table Name, omitting the schema (relation)

You can see the issue here in these two codeblocks:

https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/v0.88.0/receiver/postgresqlreceiver/client.go#L270

https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/v0.88.0/receiver/postgresqlreceiver/client.go#L376

The same occurs with locks, which also do not include a schema.

The issue is that as a result, it becomes harder to actually correlate between the datasets, especially if tables exists with the same name in two schemas.

Steps to Reproduce

1. Enable postgresql Metrics with optional metrics such as postgresql.sequential_scans

Expected Result

Metrics have consistent names for the resources they track.

Actual Result

Metrics have inconsistent names and cannot be reliably correlated.

Collector version

v0.88.0, v0.90.0, 3b84eae

Environment information

not relevant

OpenTelemetry Collector configuration

receivers:
  postgresql:
    endpoint: "localhost:5432"
    username: postgres
    password: postgres
    metrics:
      postgresql.sequential_scans:
        enabled: true

Log output

not relevant

Additional context

I'm happy to write a patch to change the index.* metrics to use a "schema.relation" name mapping in the same way all the other metrics for postgres work. It would be nice if all metrics had consistent tagging.

[github-actions]

Pinging code owners:

• receiver/postgresql: @djaglowski

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

[djaglowski]

Thanks for pointing this out @cultpony. I agree we should be consistent across the receiver.

We seem to have two options here. Either have postgresql.database.name: "schema.relation", or add a new attribute postgresql.schema.name and store the fields separately.

Generally I lean towards using separate attributes when we have two pieces of information. WDYT?

[cultpony]

Using two attributes would be definitely the better choice, IMO

[crobert-1]

Removing needs triage as the next steps and solution has been agreed upon.

[hughesjj]

Made a comment in the PR, but have we thought about backwards compatibility/migration path for anyone reliant on the old naming scheme?

[cultpony]

I mentioned it in the PR (and to bring this on the issue so that discussion isn't fragmented too much) but the best option would be to recommend users to migrate their system to rely on the newer attributes, since they are simply more reliable.

To restore old behaviour a transform step in the pipeline would be sufficient:

transform:
  error_mode: ignore
  metric_statements:
  - context: resource
    statements:
    - set(attributes["postgresql.table.name"], Concat(attributes["postgresql.table.schema"],attributes["postgresql.table.name"],"."))

[djaglowski]

Thanks @hughesjj for bringing up backwards compatibility, and @cultpony for putting together the PR. I saw the PR first so commented there, but really our backwards compatibility policy requires us to make breaking changes like this via a feature gate. That said, it's very helpful to have the corresponding transform for those who wish to keep the old format longer term, so thanks for putting that together as well.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• receiver/postgresql: @djaglowski

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

[crobert-1]

Resolved by #30142