-
Notifications
You must be signed in to change notification settings - Fork 525
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
Service specific source maps #5410
Service specific source maps #5410
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪 |
Re-use the RoundTripper configuration code for the es client to configure the fleet http client the same way. Internally, the es client is instrumented, so do that as well.
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.
Approach looks good. The biggest unknown for me is where we get TLS config from for communicating with fleet-server.
this was a temporary fix
if a series of requests come in at once for a key that isn't in the cache, coordinate a single request to the backend to retrieve it and have the others wait until the request is complete.
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.
Left a first high-level review.
Limit the number of open requests that are waiting for a response from the sourcemap backend
we won't be re-using elasticsearch config for fleet-server configuration.
This pull request is now in conflicts. Could you fix it @stuartnelson3? 🙏
|
Remove the TestDataStreams tests, which test the server's internal/private/undocumneted configuration for enabling data streams. At least for now, this is only intended to be used with Fleet, so we should instead just rely on the Fleet system test. There was a bug in the Fleet test where apm-server would create "traces-apm-default" as a plain old index instead of a data stream in certain conditions: if the apm integration had previously been installed, then the traces-apm template would be deleted by CleanupElasticsearch. Because the package was already installed, creating the policy would not automatically reinstall it and add the missing template. We fix the Fleet issue by uninstalling the package during Fleet cleanup, after unenrolling agents.
@axw let me know if you spot anything else when you get the chance |
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.
just a few more minor comments, otherwise LGTM!
jenkins run the tests |
Serve service-specific sourcemaps from fleet-server (cherry picked from commit 9453fe2) # Conflicts: # apmpackage/apm/manifest.yml # changelogs/head.asciidoc
* Service specific source maps (#5410) Serve service-specific sourcemaps from fleet-server (cherry picked from commit 9453fe2) # Conflicts: # apmpackage/apm/manifest.yml # changelogs/head.asciidoc * Update manifest.yml * Delete head.asciidoc Co-authored-by: stuart nelson <[email protected]>
Serve service-specific sourcemaps from fleet-server (cherry picked from commit 9453fe2) # Conflicts: # apmpackage/apm/manifest.yml # beater/beater.go # beater/beater_test.go # changelogs/head.asciidoc # sourcemap/fleet_store.go # sourcemap/fleet_store_test.go # sourcemap/store_test.go # tests/system/test_integration_sourcemap.py
I tested this with the current Kibana API which requires sending the source map as a string, rather than as a file. It works, but there's a small issue. I essentially manually ran this system test, but using the Kibana API for uploading the source map: apm-server/systemtest/sourcemap_test.go Lines 38 to 60 in 29cfed3
The issue is that the "bundle_filepath" is apparently not being cleaned. The path with "e2e/../e2e" in it does not match, but when I manually clean it (i.e. change that substring to "e2e"), then it does match. The existing APM Server endpoint cleans the URL path before storing it in Elasticsearch:
Kibana should probably do the same. Alternatively we could clean it after receiving it in the APM Server, but seems better to store it cleaned in the first place. I'll open a Kibana issue. |
Calling this one working as expected, there's elastic/kibana#105911 open to sort out the issue noted above. |
Motivation/summary
support configuring source maps from kibana and fetching them from fleet server.
closes #5002
Checklist
How to test these changes
Run elasticsearch + and elastic-agent in fleet mode.
Start kibana with the code from elastic/kibana#95393 has been completed, and apm-server with the fleet-server sourcemap code.
source_maps
block has been pushed to apm-serverRelated issues
depends on elastic/kibana#95393