Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat: fetch sourcemaps from Elasticsearch #9722
feat: fetch sourcemaps from Elasticsearch #9722
Changes from 1 commit
8bcf7b4
3d61fc1
d18afa0
6b13bb3
27883df
4d8c011
f04473e
7a64c06
c96587d
855cb02
cd01a10
9890493
9518384
761802b
ac529cd
a9957ea
260d3d5
995e254
cf86bb3
813cdfb
6f0fb18
094dbfc
3f0c2be
cc35612
a3e65cb
b1a2bf2
0f4b3fa
a5ea7bf
3041003
9486691
b0b8646
0942d3d
3d72922
77ed8f1
5e80d77
61fed2d
2131a33
4d66334
16839e8
1031ac2
413385a
4532dfb
cff8dd0
7946c09
39510c4
020f869
870b635
06a59b1
b881da3
df99000
ffa8941
c5508d9
b342665
695c495
b3c5792
b48a882
7aded27
ba117b4
d4fccb2
54ab5b9
1aa9654
529b129
778ec6d
69e2859
faece2a
8c03743
878b025
558a473
7df5419
e186512
c194073
b56a1ea
7757b55
0b38f0d
a890a2f
174e87e
d12ebdf
90bc423
88f78a0
873b4c6
c919996
b674d5d
4bc95f7
e13870b
3066ce0
42bc926
f258815
0c34f3c
444c55b
b7389a6
4610931
ed99eb5
29d329d
cd6ae96
e2b24a0
0c3eef4
1d4d261
240da96
26ecdfe
cf94883
5c92302
c8ca86d
c593dfc
c87ce27
cc5a01a
f353cd1
04dc1fb
88c8011
824c68f
9efecb9
d466045
ed6c474
ffaef7f
c4e9407
6d1472c
ab147c5
dccaec4
067202b
5ff04ac
e64ddb3
a65af2a
0db75d9
711ed63
9c19470
55f95c9
868eb55
be3ea36
54be00c
17b485b
557e4a3
af66eda
6eb7746
2ac90e0
a44b82a
ee25e37
11c097b
3530b49
14d230a
d8924cc
3ef10e5
bbebe6a
c24db8d
08ae602
5b0dfb6
2e814f4
53c7d97
8028c46
8c61b76
4de127a
7b75446
a182dd2
1d74a28
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Are there any tests for the
MetadataCachingFetcher
logic? I was expecting a fair amount of unit tests covering the cache update logic etc.I might be missing something here, but with the escape hatch to fetch the body directly from ES, if the metadata cache is not ready, the system tests might still be running as expected even if the metadata cache is not populated.
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.
The
MetadataCachingFetcher
should always only run as a background job, fetching metadata and populating a cache. Whereas theCache
andElasticsearch
Fetcher are responsible for synchr. fetching soucemap bodies from either the cache or ES. TheFetch
method is called sync when processing incoming requests. Why exposing thisFetch
from theMetadataCachingFetcher
? This causes quite a strong coupling between the fetchers, especially theMetadataCachingFetcher
doesn't need to know anything about the sourcemap body fetcher. It only needs to expose a way to access the cache with the metadata.I guess I had rather expected it the other way around, that the
MetadataCachingFetcher
would expose a public methodGetID
and the fetcher would be passed as a parameter to theElasticsearchFetcher
.Nit: How about also renaming the
ElasticsearchFetcher
to something indicating what it fetches from ES, as theMetadataCachingFetcher
also fetches from ES.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've moved the logic for syncing and sending updates to a separate file and decoupled the fetchers.
Only the sync worker and the Elasticsearch fetchers are coupled/knows about ES. The fetchers have been renamed for clarity and they are decoupled from each other.
I'm not sure I fully understand where you are heading, do you want to merge Metadata and Body Caching fetchers ?
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.
What happens if ES is not yet reachable at this point but later?
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.
Looking back at this, I don't think it's a good idea, this will basically block until the cache is populated since we cannot retrieve sourcemaps until then with the current implementation.
I'm not sure what's the best way to proceed here. Returning nothing might be misleading. Should we bypass the cache and send the request to ES if the cache is not populated yet ?
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.
This would be if the metadata cache is not ready. If a sourcemap is part of the metadata cache but the body is not yet cached, it will be fetched from ES on request.
So let's take a look at the metadata cache. What are the scenarios for when the cache might not be ready?
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 don't think the metadata cache should be concerned If ES is not ready/reachable/available. A failure in that scenario would be "working as intended" imo because the metadata cache is proxying what it got from the ES fetcher (error, timeout, etc.).
I was thinking of "if init is not completed, forward the request to the backend fetcher". In theory the first request for each sourcemap would be forwarded to ES anyway so this wouldn't create additional work unless we get a request for a missing sourcemap on ES during init. The reasoning behind this was that when the metadata cache is not initialized:
WDYT ?
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.
So this is really used for triggering the first fetch, in case it hasn't yet been initiated?
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.
The logic has been reworked and now we forward the request to ES if the metadata cache is not ready.
This does not create additional costs since the response is cached in the lru cache.
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.
Why is it >=300 instead of >=400?
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.
That's what the current elasticsearch fetcher is using:
apm-server/internal/sourcemap/elasticsearch.go
Line 84 in da18d54