Open adussarps opened 6 months ago
Pinging code owners:
receiver/postgresql: @djaglowski
See Adding Labels via Comments if you do not have permissions to add labels yourself.
Since client_addr
is a common resource attribute, I think we should use a default value (e.g. "unknown") when it is null or empty.
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:
See Adding Labels via Comments if you do not have permissions to add labels yourself.
Any solution/workaround for this?
Reviewing the thread, I think we just need a PR which sets a default value when client_addr
is null.
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:
See Adding Labels via Comments if you do not have permissions to add labels yourself.
Component(s)
receiver/postgresql
What happened?
Description
I've recently initiated monitoring on our SQL databases hosted on OVH using the PostgreSQL receiver. While the receiver successfully establishes a connection to the database, it encounters an error during the scraping process, resulting in failed metrics retrieval.
Note that there is indeed a null value in the pg_stat_activity; 'client_addr' column.
Expected Result
Ideally, the collector should be capable of gracefully handling rows containing NULL values, thereby bypassing them during the scraping process rather than halting due to such instances.
This issue impedes our ability to effectively monitor our databases and necessitates a resolution to ensure seamless metric collection.
Collector version
v0.88.0
PostgreSQL - version 15
Environment information
Environment
Installed via Helm version v0.99.0 on Kubernetes
OpenTelemetry Collector configuration
Log output
Additional context
No response