Skip to content
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

Do not start / expose metrics by default #242

Closed
binarylogic opened this issue Apr 3, 2019 · 2 comments
Closed

Do not start / expose metrics by default #242

binarylogic opened this issue Apr 3, 2019 · 2 comments
Assignees
Labels
domain: cli Anything related to Vector's CLI domain: observability Anything related to monitoring/observing Vector type: enhancement A value-adding code change that enhances its existing functionality.

Comments

@binarylogic
Copy link
Contributor

Related #230

We should not expose a Prometheus specific metrics endpoint by default. I'm assuming #230 is a better solution to this, until then I think this should be explicitly enabled.

@binarylogic binarylogic added type: enhancement A value-adding code change that enhances its existing functionality. domain: cli Anything related to Vector's CLI domain: observability Anything related to monitoring/observing Vector labels Apr 3, 2019
@michaelfairley michaelfairley self-assigned this Apr 8, 2019
@LucioFranco
Copy link
Contributor

I'd like to add to this, that this should also not set the metrics subscriber as it is a bit heavy right now (internally uses locks) which will go away soon but if I disable metrics I expect for those costs to not exist. So this means that instead of wrapping the tokio-trace-fmt subscriber we should just set that as the sub.

This is the line where it wraps the FmtSubscriber https://github.com/timberio/vector/blob/master/src/main.rs#L58

@michaelfairley
Copy link
Contributor

@LucioFranco
tokio_trace::subscriber::with_default, can't take a dyn Subscriber, so I can't pass it a Boxed subscriber, so there's no simple way for me to sometimes have a MetricsSubscriber and sometimes not. I think my 2 best options are:

  1. Always use the MetricsSubscriber. #YOLO
  2. Write an EitherSubscriber that implements Subscriber and forwards all of its calls to one of the two concrete implementations.

Any thoughts?

aholmberg pushed a commit to aholmberg/vector that referenced this issue Feb 14, 2024
feat(docker): use buildx for image build+publish step
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain: cli Anything related to Vector's CLI domain: observability Anything related to monitoring/observing Vector type: enhancement A value-adding code change that enhances its existing functionality.
Projects
None yet
Development

No branches or pull requests

3 participants