[RUM Dashboard] Create new path for client side monitoring

[shahzad31]

Summary

Fixes: elastic/uptime#240
Created a new entry point for client side monitoring solutions, code as of now will remain part of APM, so simply just registered a new feature.

For permission perspective, it will continue to use apm_user role.

Also used lazy loading in plugin setup to reduce initial page load bundle size.

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[legrego]

Sorry for my lack of understanding, but I need some more context. I'm also sorry for the wall of text that follows.

From what I can tell, this appears to be existing functionality that we are extracting from APM into its own top-level application/feature. If that is the case, then I have some thoughts around the privilege/access model.

1. APM users in 7.9 have access to this feature within APM itself. After upgrading, they won't have access to this anymore, based on the way this is currently configured. I don't think this is what you want, as it's considered a breaking change to take features away from users who were previously authorized.
2. Does APM continue to function if the user doesn't have access to this new Client Side Monitoring app?
3. Does Client Side Monitoring function if the user doesn't have access to the APM feature? What type of access is required for me to test and verify this?
   3a) Does Client Side Monitoring rely on any API routes defined by the APM application? APM secures access to its routes using the access:apm tag, and others. Client Side Monitoring is not configured to grant access to these APIs, so if you're relying on them, then we'll need to adjust the feature definition accordingly.
   3b) Does Client Side Monitoring rely on any UI Capabilities defined by the APM feature? If so, how will this work for users who don't have access to APM itself?
4. Should users with the existing apm_user role have access to this new Client Side Monitoring feature?

[shahzad31]

Sorry for my lack of understanding, but I need some more context. I'm also sorry for the wall of text that follows.

From what I can tell, this appears to be existing functionality that we are extracting from APM into its own top-level application/feature. If that is the case, then I have some thoughts around the privilege/access model.

1. APM users in 7.9 have access to this feature within APM itself. After upgrading, they won't have access to this anymore, based on the way this is currently configured. I don't think this is what you want, as it's considered a breaking change to take features away from users who were previously authorized.
2. Does APM continue to function if the user doesn't have access to this new Client Side Monitoring app?
3. Does Client Side Monitoring function if the user doesn't have access to the APM feature? What type of access is required for me to test and verify this?
   3a) Does Client Side Monitoring rely on any API routes defined by the APM application? APM secures access to its routes using the access:apm tag, and others. Client Side Monitoring is not configured to grant access to these APIs, so if you're relying on them, then we'll need to adjust the feature definition accordingly.
   3b) Does Client Side Monitoring rely on any UI Capabilities defined by the APM feature? If so, how will this work for users who don't have access to APM itself?
4. Should users with the existing apm_user role have access to this new Client Side Monitoring feature?

@legrego thanks for the feedback, So this was kind of hidden feature within apm in 7.9, which was only accessible through a URL, acting kind of as a preview for users.

So now it will be totally dependant on apm_user role. I have removed the new server feature file.

Only apm users will be able to access this new feature.

[legrego]

Thanks for the updates @shahzad31 - your new changes mean you don't technically need my review anymore, so LGTM from a security perspective

[dgieselaar]

Mostly some remarks around parallelisation and a bug in the observability dashboard. Also I think we should use csm consistently rather than rum or clientSideMonitoring where appropriate, but will leave that up to you.

[shahzad31]

@dgieselaar Thanks for the feedback, i have addressed all of it.

[andrewvc]

I think @dgieselaar has done a better job reviewing here than I can, so I have nothing to add other than confirming his findings.

[dgieselaar]

I think there's one or two lines that could be removed and a translation that should be added, but other than that, LGTM!

[kibanamachine]

💛 Build succeeded, but was flaky

• continuous-integration/kibana-ci/pull-request
• Commit: e6ea937
• Flaky suites:
  • oss-pluginFunctional

---

Test Failures

Plugin Functional Tests.test/plugin_functional/test_suites/core/route·ts.core route timeouts idle socket should timeout if servers response is too slow

Link to Jenkins

Standard Out

Failed Tests Reporter:
  - Test has not failed recently on tracked branches

[00:00:00]       │
[00:00:00]         └-: core
[00:00:00]           └-> "before all" hook
[00:00:00]           └-: route
[00:00:00]             └-> "before all" hook
[00:00:00]             └-: timeouts
[00:00:00]               └-> "before all" hook
[00:00:00]               └-: idle socket
[00:00:00]                 └-> "before all" hook
[00:00:00]                 └-> should timeout if payload sending has too long of an idle period
[00:00:00]                   └-> "before each" hook: global before each
[00:00:00]                   └- ✓ pass  (55ms) "core route timeouts idle socket should timeout if payload sending has too long of an idle period"
[00:00:00]                 └-> should not timeout if payload sending does not have too long of an idle period
[00:00:00]                   └-> "before each" hook: global before each
[00:00:00]                   └- ✓ pass  (230ms) "core route timeouts idle socket should not timeout if payload sending does not have too long of an idle period"
[00:00:00]                 └-> should timeout if servers response is too slow
[00:00:00]                   └-> "before each" hook: global before each
[00:00:00]                   │ info Taking screenshot "/dev/shm/workspace/parallel/2/kibana/test/functional/screenshots/failure/core route timeouts idle socket should timeout if servers response is too slow.png"
[00:00:01]                   │ info Current URL is: data:/,
[00:00:01]                   │ info Saving page source to: /dev/shm/workspace/parallel/2/kibana/test/plugin_functional/failure_debug/html/core route timeouts idle socket should timeout if servers response is too slow.html
[00:00:01]                   └- ✖ fail: core route timeouts idle socket should timeout if servers response is too slow
[00:00:01]                   │      Error: expected 'read ECONNRESET' to equal 'socket hang up'
[00:00:01]                   │       at Assertion.assert (packages/kbn-expect/expect.js:100:11)
[00:00:01]                   │       at Assertion.be.Assertion.equal (packages/kbn-expect/expect.js:227:8)
[00:00:01]                   │       at Assertion.be (packages/kbn-expect/expect.js:69:22)
[00:00:01]                   │       at result.then.err (test/plugin_functional/test_suites/core/route.ts:147:38)
[00:00:01]                   │       at process._tickCallback (internal/process/next_tick.js:68:7)
[00:00:01]                   │ 
[00:00:01]                   │ 

Stack Trace

Error: expected 'read ECONNRESET' to equal 'socket hang up'
    at Assertion.assert (packages/kbn-expect/expect.js:100:11)
    at Assertion.be.Assertion.equal (packages/kbn-expect/expect.js:227:8)
    at Assertion.be (packages/kbn-expect/expect.js:69:22)
    at result.then.err (test/plugin_functional/test_suites/core/route.ts:147:38)
    at process._tickCallback (internal/process/next_tick.js:68:7)

---

Build metrics

@kbn/optimizer bundle module count

id	value	diff	baseline
apm	942	+1	941

async chunks size

id	value	diff	baseline
apm	4.7MB	⚠️ +1.0MB	3.7MB

page load bundle size

id	value	diff	baseline
apm	40.6KB	-217.4KB	258.0KB

History

• 💚 Build #68666 succeeded 548cf11
• 💚 Build #68534 succeeded 78fbe89
• 💚 Build #68374 succeeded dad1bc8
• 💔 Build #68188 failed 3d1c5e1
• 💔 Build #68125 failed 452c07f

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream