Service specific source maps

[stuartnelson3]

Motivation/summary

support configuring source maps from kibana and fetching them from fleet server.

closes #5002

Checklist

• Update CHANGELOG.asciidoc
• Documentation has been updated

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.

• Upload a sourcemap via kibana
• Confirm an updated config with the new source_maps block has been pushed to apm-server
• Confirm ingesting rum traces for the uploaded sourcemap get mapped appropriately

Related issues

depends on elastic/kibana#95393

[apmmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Build Cause: Pull request #5410 updated

• Start Time: 2021-06-23T09:36:35.727+0000

• Duration: 53 min 25 sec

• Commit: d098115

Test stats 🧪

Test	Results
Failed	0
Passed	6161
Skipped	119
Total	6280

Trends 🧪

[axw]

Approach looks good. The biggest unknown for me is where we get TLS config from for communicating with fleet-server.

[simitt]

Left a first high-level review.

[mergify]

This pull request is now in conflicts. Could you fix it @stuartnelson3? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b service-specific-source-maps upstream/service-specific-source-maps
git merge upstream/master
git push upstream service-specific-source-maps

[stuartnelson3]

@axw let me know if you spot anything else when you get the chance

[axw]

just a few more minor comments, otherwise LGTM!

[stuartnelson3]

jenkins run the tests

[axw]

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

	func TestRUMErrorSourcemapping(t *testing.T) {
	systemtest.CleanupElasticsearch(t)
	srv := apmservertest.NewUnstartedServer(t)
	srv.Config.RUM = &apmservertest.RUMConfig{Enabled: true}
	err := srv.Start()
	require.NoError(t, err)
	uploadSourcemap(t, srv, "../testdata/sourcemap/bundle.js.map",
	"http://localhost:8000/test/e2e/../e2e/general-usecase/bundle.js.map",
	"apm-agent-js",
	"1.0.1",
	)
	systemtest.Elasticsearch.ExpectDocs(t, "apm-*-sourcemap", nil)
	systemtest.SendRUMEventsPayload(t, srv, "../testdata/intake-v2/errors_rum.ndjson")
	result := systemtest.Elasticsearch.ExpectDocs(t, "apm-*-error", nil)
	systemtest.ApproveEvents(
	t, t.Name(), result.Hits.Hits,
	// RUM timestamps are set by the server based on the time the payload is received.
	"@timestamp", "timestamp.us",
	)
	}

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:

apm-server/beater/api/asset/sourcemap/handler.go

Line 130 in 29cfed3

smap.BundleFilepath = utility.CleanUrlPath(req.FormValue("bundle_filepath"))

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.

[axw]

Calling this one working as expected, there's elastic/kibana#105911 open to sort out the issue noted above.