You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 17, 2023. It is now read-only.
Remember that every unique combination of key-value label pairs represents a new time series, which can dramatically increase the amount of data stored. Do not use labels to store dimensions with high cardinality (many different label values), such as user IDs, email addresses, or other unbounded sets of values.
Because of this, there should be no label where the value of the label does not come from the configuration file, or is not a fixed value.
So the labels I don't really understand are:
uid
ike_sa_uid
ike_sa_local_id
ike_sa_remote_id
ike_sa_remote_identity
reqid
The text was updated successfully, but these errors were encountered:
pokab
added a commit
to idatahu/ipsec_exporter
that referenced
this issue
Jan 4, 2023
…akinen#9"
Revert "fix tests for previous e3480a1"
Revert "fix again"
... because of a new method to try to eliminate high cardinality uids
This reverts commits:
e3480a15bfc7d31f32235
Hey @pokab, yeah, it looked like a simple idea to get a traffic usage across sessions at that time but it was definitely not a great idea.
On the one hand, it will be nice to sort it out in v2 while keeping an ability to monitor a traffic but on the other hand, I've completely switched to WireGuard and thinking on archiving this because I have too many other things to focus on (and hopefully - to share). At least I hope this repository should be useful to others with a working codebase with unit and integration tests...
I've got a working solution pushed in my repository, but not yet in the master branch. Will clean it up later.
No problem if you don't want a pull request or maintain this application.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
If I understand it correctly, UIDs in libreswan are generated dynamically and are always changing.
If this is true, including UIDs in metrics, like this:
is a bad practice since it will cause an unbounded number of unique prometheus time series, as described in https://prometheus.io/docs/practices/naming/ :
Because of this, there should be no label where the value of the label does not come from the configuration file, or is not a fixed value.
So the labels I don't really understand are:
The text was updated successfully, but these errors were encountered: