-
Notifications
You must be signed in to change notification settings - Fork 381
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
Add first opentelemetry metric #393
base: main
Are you sure you want to change the base?
Conversation
@erebe first draft PR for the metrics provider. This is mostly to make sure the general style fits your expectations, though could already be merged as is. This is the ~MVP of getting some prometheus metrics with the opentelemetry tooling. The main potentially contentious point I see: This tooling is quite beta/alpha stage in the rust ecosystem. |
self.metrics.connections.add( | ||
1, | ||
&[ | ||
KeyValue::new("remote_host", format!("{}", remote.host)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should avoid setting remote_host and port as label as it will make too much cardinality for prometheus, and create a data leak for us.
If a user request random host / port our metrics are going to fill the available memory of wstunnel until it OOM as they are never cleaned.
metrics should not jeopardize the stability of the system
https://stackoverflow.com/a/69167162
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll have to think about this a bit.
I see why you say that, and agree with the point you make.
OTOH, I need the cardinality to get the information I need. So I'll have to think about some way to customize this.
In my case, k8s and multiple replicas make an OOM less serious.
Overall, looks ok 👍 |
79824d2
to
ae52331
Compare
a3375f3
to
d065bfa
Compare
No description provided.