error "missing port in address" in 0.5.1

[FedeHAL]

I'm submitting a ...

• [X ] bug report

What is the current behavior?

With 0.5.0/0.5.1 there is an error "missing port in address" on the exporter log and no metrics are collected.

ts=2023-09-07T13:56:29.078Z caller=collector.go:262 level=error Errorpingingoracle:="missing port in address"
ts=2023-09-07T13:56:29.078Z caller=main.go:70 level=info msg="Starting oracledb_exporter" version="(version=, branch=, revision=unknown)"
ts=2023-09-07T13:56:29.078Z caller=main.go:71 level=info msg="Build context" build="(go=go1.19.9, platform=linux/amd64, user=, date=, tags=unknown)"
ts=2023-09-07T13:56:29.078Z caller=main.go:72 level=info msg="Collect from: " metricPath=/metrics
ts=2023-09-07T13:56:29.078Z caller=tls_config.go:274 level=info msg="Listening on" address=[::]:9161
ts=2023-09-07T13:56:29.078Z caller=tls_config.go:277 level=info msg="TLS is disabled." http2=false address=[::]:9161

/k8s # kubectl exec -it oracle-exporter-65d677454f-k46vl -- bash
groups: cannot find name for group ID 472
ubuntu@oracle-exporter-65d677454f-k46vl:/$ echo $DATA_SOURCE_NAME
myuser/[email protected]:1521/CDBTEST

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

defining DATA_SOURCE_NAME variable as "myuser/[email protected]:1521/CDBTEST", fails with "missing port in address" in a container running exporter version 0.5.0/0.5.1 and up.

What is the expected behavior?

The exporter connects to the DB, using the same DSN string in a 0.4.3 container works and metrics are collected.

Status: Downloaded newer image for ghcr.io/iamseth/oracledb_exporter:0.4.3
ts=2023-09-07T14:31:13.093Z caller=main.go:596 level=info msg="Starting oracledb_exporter" version=0.4.3
ts=2023-09-07T14:31:13.094Z caller=main.go:566 level=info msg="Successfully loaded default metrics" file=default-metrics.toml
ts=2023-09-07T14:31:13.094Z caller=main.go:581 level=info msg="No custom metrics defined"
ts=2023-09-07T14:31:27.341Z caller=main.go:316 level=error msg="Error scraping for" context=process metricsDesc="unsupported value type" since=6.133370108s err="Oracle query timed out"
ts=2023-09-07T14:31:27.664Z caller=main.go:316 level=error msg="Error scraping for" context=tablespace metricsDesc="unsupported value type" since=6.45584448s err="Oracle query timed out"
ts=2023-09-07T14:31:27.664Z caller=main.go:316 level=error msg="Error scraping for" context=activity metricsDesc="unsupported value type" since=6.456358559s err="Oracle query timed out"
ts=2023-09-07T14:31:27.665Z caller=tls_config.go:232 level=info msg="Listening on" address=[::]:9161
ts=2023-09-07T14:31:27.665Z caller=tls_config.go:235 level=info msg="TLS is disabled." http2=false address=[::]:9161

What is the motivation / use case for changing the behavior?

none

Please tell us about your environment:

Version: 0.5.0/0.5.1

[towo]

@FedeHAL Hey there, were you using a C## user or similar? I've stumbled over the issue that it appears to be parsing the # as a comment…

[towo]

cf #352

[FedeHAL]

No, I'm using dbsnmp.

[littlestar1998]

If there is a "#" symbol in the account name, it won't work. In reality, this is a valid username. I changed "##" to "%23%23," and it worked correctly.

[postum]

I have the same error. Moreover, it looks like with that version I've lost a possibility to resolve database alias via tnsnames.ora

[taomaree]

export DATA_SOURCE_NAME="oracle://user:pass@host:port/service"

and replace "#" with "%23", and it works with 0.5.1