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

Implement HTTP fullscrapes #462

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open

Conversation

mrd0ll4r
Copy link
Member

Fixes #369 (eventually)

WIP, but need travis

dist/example_config.yaml Outdated Show resolved Hide resolved
}
remoteIP := net.ParseIP(host)
if remoteIP == nil {
return nil, errors.New("unable to parse HTTP remote address as IP")
Copy link
Member

Choose a reason for hiding this comment

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

We parse IPs in a bunch of places. Maybe we should create one error for all of the failure cases across the codebase.

Copy link
Member Author

Choose a reason for hiding this comment

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

Well, it's kinda messy. Sometimes we return the IP and an error, sometimes we return an IP and a bool... then there's also the whole IP spoofing thing. UDP only copies around bytes/remote socket address and does no checks whatsoever.

I don't think we can unify all of those 😅

frontend/http/parser.go Outdated Show resolved Hide resolved
// This is a fullscrape.
start := time.Now()
resp = ps.fullscrapeSwarms(addressFamily)
recordFullscrapeDuration(time.Since(start))
Copy link
Member

Choose a reason for hiding this comment

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

Couldn't we pull the metric timing up to the caller of this function? Are we doing that for the non-full-scrape case? The caller can definitely make the check of whether the len(infoHashes) == 0

Copy link
Member Author

@mrd0ll4r mrd0ll4r Nov 26, 2019

Choose a reason for hiding this comment

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

Well, we're tracking some request durations in the frontends, if enabled via the config flag. This includes scrapes, although we currently only have one action "scrape", but that wouldn't be a problem to change...

I kinda see your point, as in: The prometheus metrics for the storage are all storage-internal, as in not visible to a frontend. I just added it here because I thought it would be interesting to see, similar to GC duration.

I expect fullscrapes to be an occasional thing, and I know from some people who didn't enable the request timing in the frontend (because it costs performance).

Opinion?

})
return
}
for i, ih := range infoHashes {
Copy link
Member

Choose a reason for hiding this comment

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

So redis doesn't support fullscrapes? :(

Copy link
Member Author

Choose a reason for hiding this comment

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

It's been a while since I wrote this, but my gut feeling is that this had some complexity due to the possibility of asynchronous stuff happening.. I'd probably have to design another WATCH ... MULTI ... EXEC block and prove that to be correct. What's the priority on this? How about just a note in the docs that redis currently doesn't do fullscrapes, and an issue to keep track of it?

@mrd0ll4r
Copy link
Member Author

@jzelinskie I could need some input here too :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants