Understand our blackbox monitoring in more detail
Related to checking out performance #1830 (closed)
(also related: #1877 (closed))
We have blackbox monitoring for a number of hand picked URLs, at http://monitor.gitlab.net/dashboard/db/gitlab-web-status?refresh=1m&orgId=1
- Where does that measurement start and end?
- How does it relate to what @brycepj is building in https://gitlab.com/brycepj/gitlab-frontend-monitor ?
- With either of those tools, make sure we monitor the top 10 used pages on GitLab.com and understand how to drive down latency for those. I.e. need to discover which pages are our top 10.
I'd also like to use this issue to address more user experience data gathering, per @andrewn 's description of a prior use case at Gitter:
"I'm referring to instrumenting the code that runs on users browsers and measuring things like the times between clicking on an element and the new page being totally loaded. Measuring the perceived performance that the user is experiencing takes into account all the variables discussed in this document, nginx queue times, unicorn queue times, etc etc and also takes into account others which we're not (possibly) not recording right now, like Javascript asset load and parse times, etc. These metrics accurately measure the end-to-end performance and they're easy to add. We did this with Gitter and it was our key metric when we were working to speed up the application."
- Sid asked if we can perform real user monitoring with javascript code that has an open source license on the client?
- Previous and current efforts on this front:
- Performance monitoring for Frontend https://gitlab.com/gitlab-org/gitlab-ce/issues/17422
- Adding prometheus instrumenting to gitlab webapp https://gitlab.com/gitlab-org/gitlab-ce/issues/29118
- Adding metrics instrumentation to GitLab internals https://gitlab.com/gitlab-org/gitlab-ce/issues/28465
- @andrewn how did you do this at Gitter? What tool set did you use and are there OS alternatives?