-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Customising service metrics with additional views, reader and server #7696
Conversation
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
952ac3d
to
42e0fbb
Compare
42e0fbb
to
c379a56
Compare
Hello, if a maintainer has a chance to review and opine whether this approach has potential, it would be much appreciated please :) |
@open-telemetry/collector-maintainers any thoughts? |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
ping @open-telemetry/collector-maintainers |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
There are two changes in the PR:
service.New
function./metric
server.This could be useful to users of the Collector who want to leverage the functionality of the service module, but who need to extend it with their own metric server, views and readers.
The change in this PR was discussed recently on the CNCF slack channel for the collector, on this thread.
Alternative solutions to this problem have already been discussed in #4970. So far they have mostly been turned down because overriding telemetry settings could contradict other settings in the service config.
There is one potential issue with this change. Unfortunately, the
useExternalMetricsServer
could indeed contradict the config. If the config specifies a telemetry metrics address anduseExternalMetricsServer = true
, then Collector wouldn't start a Prometheus server. However, if you think passing views and metric readers is ok, I could think of a way to minimise the contradictions whichuseExternalMetricsServer
would introduce.On Slack it was also mentioned that there is work underway to include metric readers and views in the config, and that this change could potentially contradict them (or at least provide another way to configure the same thing):
I would be happy to add a changelog entry, tests and documentation if needed. There is currently no GitHub issue created for this particular approach, but I would be happy to create one if needed as well.