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

New flag to disable detailed metrics for path #841

Merged
merged 2 commits into from
Aug 26, 2024

Conversation

Kuzbekov
Copy link
Contributor

Flag detailed-metrics added to provide a way to disable exposing all accessed paths to the metrics and prevent potential metrics cardinality explosion

Issue ref: #828

main.go Outdated
@@ -97,6 +98,7 @@ func main() {
flag.BoolVar(&watchAllNamespaces, "watch-all-namespaces", true,
"Watch for custom resources in all namespaces, if set to false it will only watch the runtime namespace.")
flag.DurationVar(&rateLimitInterval, "rate-limit-interval", 5*time.Minute, "Interval in which rate limit has effect.")
flag.BoolVar(&detailedMetrics, "detailed-metrics", true, "Count metrics for every requested path")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would name the flag --export-http-path-metrics and have it set to false by default. The description could be: When enabled, the requests full path is included in the HTTP server metrics (risk as high cardinality).

Copy link
Member

@souleb souleb May 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is the other way around.

maybe something like:

--set-metrics-handlerID and have it set to false by default. The description: When enabled, the requests full path is included in the HTTP server metrics as handler label (this will keep cardinality low because all urls path will have same handler label on the metrics).

Like this we keep the actual behavior by default.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I don't think we should keep the default behaviour, given that people expose the receiver on the internet, best is to ship with a secure default.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @stefanprodan, but the only concern is if somebody have already build alerts system based on path labels that they have in their systems. Probability is low, but still this change would silently break metrics and affect monitoring for those who rely on this label. Probably we could keep current behaviour and switch to more secure on next major release with proper notification in release notes ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR will not go into a patch release anyway. It will be part of Flux v2.4 and we'll document the flag and the behaviour change accordingly.

@stefanprodan stefanprodan added the enhancement New feature or request label May 30, 2024
@stefanprodan
Copy link
Member

@Kuzbekov can you please rebase and force push, we're getting close to Flux 2.4 release and this PR can now be merged.

Flag detailed-metrics added to provide a way to disable exposing all accessed paths to the metrics and  prevent potential metrics cardinality explosion

Signed-off-by: Alexey Kuzbekov <[email protected]>
Signed-off-by: Alexey Kuzbekov <[email protected]>
@Kuzbekov
Copy link
Contributor Author

@Kuzbekov can you please rebase and force push, we're getting close to Flux 2.4 release and this PR can now be merged.

done

Copy link
Member

@stefanprodan stefanprodan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Thanks @Kuzbekov 🏅

@stefanprodan stefanprodan merged commit b81755d into fluxcd:main Aug 26, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants