[receiver/postgresql] Add service.instance.id resource attribute to metrics and logs

[sv-splunk]

Description

The service.instance.id attribute is added into resourceAttributes of metrics and logs to uniquely identify
PostgreSQL hosts. The format is :. And defaults to 'unknown:5432' in case of any errors in constructing this value.

Link to tracking issue

Fixes #43907

Testing

Unit tests added/updated

Documentation

Updated

[dmitryax]

This isn't needed because net.SplitHostPort(config.Endpoint) doesn't pass validation

[sv-splunk]

@dmitryax do you mean config.Endpoint will always be valid and so we wouldn't need a fallback ?

[dmitryax]

Why not use server.address and server.port? I see it's defined in semconv for some databases like OracleDB while service.instance.id isn't mentioned

[XSAM]

Why not use server.address and server.port?

I won't object to have server.address and server.port, but our purpose is to have a unified resource attribute that can be used to identify a database instance across all database types. While some databases can use the combination of server.address and server.port, certain databases like Oracle need additional attributes like instance.name (the result would be example.com:1521/XE instead of example.com:1521).

Writing aggregation queries on a metric system can be painful when dynamic resource attribute filtering is required across different system types. In this context, service.instance.id is quite useful, as it simplifies the process and makes the query database-agnostic.

This approach also aligns with prometheus receiver where it uses service.instance.id to identify a unique prometheus instance.

I see it's defined in semconv for some databases like OracleDB while service.instance.id isn't mentioned

This is a semconv for client spans. It is a good reference but there is no such a semconv for data fetched from database servers that a database receiver can use. 😢

[cyrille-leclerc]

Did you look how this could work for K8s deployments of MySQL and the support of the specs Specify resource attributes using Kubernetes annotations related to service.instance.id?
I could imagine the OTel Collector Receiver Creator being capable of generating service.instance.id from the specs and then passing it to the mysql receiver config.

[lmolkova]

@XSAM you might find this discussion interesting: open-telemetry/semantic-conventions#2147 (comment) (suggestion to capture Oracel instance name in a dedicated attribute)

I think #43913 (comment) brings an important point: receiver does not know in which context / environment database runs, resource detectors do. Postgres receiver can't support k8s, docker, cloud provider-specific, etc resource detection, and if it populates service.instance.id on postgres metrics using service address and port, it won't match instance on logs or host metrics by the resource detection processor.

Do we know if resource detection processor overrides service.instance.id or would it back off and keep the original one (leading to discrepancies)?

Would it be reasonable to set server.address and server.port as well as any other attributes identifying databased instance within a host as dedicated attributes and let resource detectors populate service.instance.id ?