fix: enable ctr for prometheus reporting

[klopfdreh]

Currently the CTR does not report to prometheus-rsocket-proxy - even if the environment variables are given from the SCDF server. With this fix the CTR is reporting to the prometheus-rsocket-proxy like all other task applications

[klopfdreh]

@cppwfs - I think there are still references of the build which points to the spring repository instead of central.

[corneil]

@cppwfs - I think there are still references of the build which points to the spring repository instead of central.

@cppwfs - I think there are still references of the build which points to the spring repository instead of central.

The latest commit contains a fix for the doc-resources issues.

[klopfdreh]

This issue resolves #5357 .

No this issue is not the same.

This PR solves the issue that the CTR sends the metrics to the Prometheus Proxy as the dependencies were only scope test which was wrong.

The issue linked by you occurs if you scale up the replicas of SCDF to 2 or higher. When you do so there are two instances of the SCDF server reporting the values to prometheus with the same application. So one overrides the values of the other. In this case the dashboard needs to be adjusted. In the issue itself I mentioned how to fix this.

[cppwfs]

Whoops! You are correct. I'll remove my comment from before to remove confusion.

[corneil]

The docresources is still and issue. I thought the changes was in.
Creating a PR for it now.

[cppwfs]

Probably need to add an application.properties where Prometheus is disabled by default. i.e.
management.metrics.export.prometheus.rsocket.enabled=false
management.metrics.export.prometheus.enabled=false
This way users who do use Prometheus can enable it when they need it.

[klopfdreh]

As far as I know those properties are disabled by default, but given when ever Prometheus RSocket Proxy is enabled in the SCDF.

I think separate properties are not needed.

[onobc]

Thanks @cppwfs and @klopfdreh. They are indeed disabled by default here.

I have not caught up on this thread but will digest shortly to see if I have anything to add.

[onobc]

LGTM @klopfdreh - thanks for another excellent contribution!

[onobc]

Closed via 5df193a