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
Prometheus retention config not resolved correctly when using defaults in prom #5734
Comments
We drive a few things off of the time-based retention, I don't think there is much we can do about the size-based retention. It is important that we get it right, so I guess you are saying that if |
Either that, or always use the Or perhaps, simply change Kiali's default to 15days (rather than 6 hours) to be aligned to what Prometheus would do, assuming it's going to be hard that Prometheus would ever change that default. |
@jmazzitelli , @nrfox , We've been reducing our use of the debug endpoints, what happens when api is disabled? Even if it isn't disabled, I wonder if we should do something here? |
@jshaughn from what I can tell, this issue is not about istio. It's solely about prometheus and which endpoint to query for prometheus. It looks like there's two recommendations here:
Seems like we could do both fairly easily. |
@nrfox Oh, right (duh moment for me). I think we should probably do this, especially with the increasing possibility of unified stores, etc. |
Just some more details on prometheus storage retention config. See https://prometheus.io/docs/prometheus/latest/storage/
So the
We would need to parse that string and ignore the first space character and everything to the right of it. That resulting string may not be time-based - if we determine it is not time-based, we would then use the default Based on this page, the format of the time-based retention period is:
We know a value is size-based if it has a "B" in it (even doing a case-insensitive test). This is because all valid size units have a "B" in it, but no time-based units have a "B" in it. So that's an easy way to determine if the value we have is time-based or size-based. So easy pseudo-code that allows us to determine what the storage retention period is could be:
or // parseStorageRetentionTime parses the storage retention as reported by Prometheus endpoint /api/v1/status/runtimeinfo
// see:
// https://prometheus.io/docs/prometheus/latest/command-line/prometheus/
// https://prometheus.io/docs/prometheus/latest/storage/
func parseStorageRetentionTime(str string) string {
if strings.Index(str, " ") != -1 {
str = (strings.Fields(str))[0]
}
if !strings.Contains(strings.ToLower(str), "b") {
return str
}
return "15d" // only size-based retention is configured; return the Prometheus default of 15d
} |
Since long ago, Kiali fetches prometheus retention settings from Prometheus's config endpoints. Specifically, and apparently, retention settings seem to be retrieved using the
/api/v1/status/flags
endpoint of Prometheus.When retention settings are set (via command line args when starting Prometheus), the
/api/v1/status/flags
will correctly list such configuration. However, if related CLI args are omitted, this endpoint may provide0s
and won't reflect the retention that went into effect (which at the time of writing is 15 days).Looks like a better way to fetch the retention interval is by querying the
/api/v1/status/runtimeinfo
endpoint which seems to provide the configuration in effect, although if multiple retention settings are set, it takes more complex forms like the following:The text was updated successfully, but these errors were encountered: