Display Prometheus sparkline in Merge Request

Resources

UX @tauriedavis | FE @fatihacet

Description

Currently when a Merge Request is deployed, it is not easy to view the impact to performance of the changes in a simple way. We can improve this by having a sparkline on the Merge Request page illustrate the impact.

Proposal / Design

We can offer a simple and concise summary of the impact of a Merge Request on performance, by display a sparkline on the workflow itself. The best single metric for now would be Memory, which would be applicable for more deployment environments than CPU. We should display 30 minutes before and after the merged code was deployed.

We can use the mockup created for the Prometheus monitoring demo as a good starting point.

old	New

Design spec url: https://gitlab-org.gitlab.io/gitlab-design/progress/dimitrie/Object-views-issues-mr-pipelines-builds-commits/25424-Refine-MR-Widget/25424-Refine-MR-Widget-spec-previews/#artboard24

Links / references

mentioned in issue #26905 (closed)

changed milestone to %8.17

added ~1069035 ~19492 feature proposal labels

@tauriedavis What would you recommend for layout if we are unable to compare before/after to get actual delta in a metric? For this release, we may only be able to display the sparkline without the associated analysis.

What would you recommend for layout if we are unable to compare before/after to get actual delta in a metric? For this release, we may only be able to display the sparkline without the associated analysis.

I think we need to label the sparkline in some way. If we don't have the delta information, can we change the text from Memory increased from [#] to [#] to Memory usage over the last [time period] instead?

Yea, I think that is a good way to go.

@bjk-gitlab what do you think about +/- 10 minutes from the deployment time? What are your thoughts around the data, especially depending on the retention length on the Prometheus server?

Ideally we'd store the time series data we are interested in, but I imagine that will be more effort. That could be a challenge given the shortened window we have in 8.17.

Let's start with +-30min. The default graphs many people look at are a 1 hour timeframe. Depending on the code, deployment size, and warm-up for the app, it could take 5-10min just to deploy.

mentioned in issue #27439 (closed)

mentioned in issue #27442 (closed)

added Stretch label

mentioned in issue #27545 (moved)

Two quick items on this:

1. When displaying the chart, when there has been less than 30 minutes since deployment... We should show the chart left aligned with the 30m prior to deployment. Then after that the sparkline should build to the right, until we hit the 30m time window after deployment.

2. We should make sure we gracefully fail if for some reason there isn't any Prometheus data available for this environment. This could happen if the Prometheus server went down, has no data, or it expired.

3. I have opened #27545 (moved) to locally persist this data after 30m, as people will load the MR up later and expect it to be there, perhaps a significant time later. We can do this later, though.

mentioned in issue #23841 (closed)

When displaying the chart, when there has been less than 30 minutes since deployment... We should show the chart left aligned with the 30m prior to deployment. Then after that the sparkline should build to the right, until we hit the 30m time window after deployment.

I'm confused by what you mean by left aligned with the 30m prior to deployment. Can you elaborate @joshlambert ?

@tauriedavis, sorry for not being clear. Typically with charts illustrating performance, "current time" is at the far (right) end of the X axis, and data then starts to fill in as the timescale on the X axis proceeds forward. And indeed, this is how the behavior of our Environment chart should work.

However with our sparkline here, we should anchor the timestamp of the MR in the center. And as time continues on (if it has been less than 30m since merging) the sparkline should then build out to the right until it hits 30 minutes.

Essentially it should start something like this "---| " and then proceed "---| ", "---|-- " etc. Hopefully this is more clear.

Ah yes, that makes perfect sense. Thanks @joshlambert !

changed milestone to %9.0

added Deliverable and removed Stretch labels

mentioned in issue #25424 (closed)

added ~122770 label

I think we should pull metrics from environment which is running the target branch.

If we pull them from the environment running the source branch, it really isn't the MR that is the event but each and every commit that makes up the MR.

cc @bjk-gitlab to confirm you agree on this one.

Yes, that seems right to me.

@joshlambert is there already a MR for this one? 😃

Also do you want an updated design for this because of:

• https://gitlab.com/gitlab-org/gitlab-ce/issues/25424
• https://gitlab.com/gitlab-org/gitlab-ce/issues/28185

cc: @dzaporozhets @fatihacet @selfup (as this is marked as a Deliverable and can perhaps be related to existing work already done, although i don't see big hurdles or anything)

@dimitrieh Updated designs would be fantastic. I will move this to Stretch, based on the fact that our backend resource is still working on 8.17 regressions/issue and has #26910 (closed) up first.

Would be great to get the UX nailed down though just in case we have time.

added Stretch and removed Deliverable labels

@joshlambert updated design, based on https://gitlab.com/gitlab-org/gitlab-ce/issues/25424

old	New

Design spec url: https://gitlab-org.gitlab.io/gitlab-design/progress/dimitrie/Object-views-issues-mr-pipelines-builds-commits/25424-Refine-MR-Widget/25424-Refine-MR-Widget-spec-previews/#artboard24

Updated issue description as well.

cc: @tauriedavis

Will unlabel UX for now!

removed ~19492 label

mentioned in issue #28185 (closed)

added frontend label

Thanks @dimitrieh!

added Deliverable and removed Stretch labels

changed milestone to %9.1

mentioned in merge request !9950 (closed)

@joshlambert I've uploaded my current changes to !9950 (closed) MR. The only thing its missing right now are some rudimentary unit tests for new query functionality. This MR introduces endpoint that will return metrics only concerning 1hr timeframe around Deployment.

@pchojnacki what kind of data that endpoint will return? Can you paste a sample data here?

/cc @oswaldo ^

@fatihacet In general they follow the same format as current metrics at .../environments/:env_id/metrics.json

e.g.

MBP-Pawel:gitlab pawel$ curl 'http://localhost:3000/root/josh-hello/environments/6/deployments/3/metrics.json' -H 'If-None-Match: W/"e03dfaa8fce995185fced735d57e3145"' -H 'DNT: 1' -H 'Accept-Encoding: gzip, deflate, sdch, br' -H 'Accept-Language: pl-PL,pl;q=0.8,en-US;q=0.6,en;q=0.4,fr;q=0.2' -H 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Cache-Control: max-age=0' -H 'Cookie: remember_user_token=W1sxXSwiJDJhJDEwJEw1M2JwUjl4THVKL29LV0xYZEwwMmUiLCIxNDg5MDk3NzU1LjQxNDU4NiJd--de127ceaac729d78f848952d487b29d8132f4f06; _gitlab_session=21019344490387059c6679d2e93803a6' -H 'Connection: keep-alive' --compressed

returns:

{"success":true,"metrics":{"memory_values":[{"metric":{},"values":[[1489524201,"10.98046875"],[1489524261,"10.98046875"],[1489524321,"10.90625"],[1489524381,"10.90625"],[1489524441,"10.90625"],[1489524501,"10.90625"],[1489524561,"10.90625"],[1489524621,"10.84375"],[1489524681,"10.84375"],[1489524741,"10.84375"],[1489524801,"10.84375"],[1489524861,"10.84375"],[1489524921,"10.84375"],[1489524981,"10.6796875"],[1489525041,"10.6796875"],[1489525101,"10.6796875"],[1489525161,"10.6796875"],[1489525221,"10.6796875"],[1489525281,"10.21484375"],[1489525341,"10.21484375"],[1489525401,"10.21484375"],[1489525461,"10.21484375"],[1489525521,"10.21484375"],[1489525581,"10.21484375"],[1489525641,"10.21484375"],[1489525701,"10.21484375"],[1489525761,"10.21484375"],[1489525821,"10.21484375"],[1489525881,"10.21484375"],[1489525941,"10.21484375"],[1489526001,"16.3125"],[1489526061,"17.7734375"],[1489526121,"17.7734375"],[1489526181,"17.7734375"],[1489526241,"17.390625"],[1489526301,"7.17578125"],[1489526361,"7.17578125"],[1489526421,"7.17578125"],[1489526481,"7.17578125"],[1489526541,"7.17578125"],[1489526601,"7.17578125"],[1489526661,"7.17578125"],[1489526721,"7.17578125"],[1489526781,"7.17578125"],[1489526841,"7.17578125"],[1489526901,"7.17578125"],[1489526961,"7.17578125"],[1489527021,"7.17578125"],[1489527081,"7.17578125"],[1489527141,"7.17578125"],[1489527201,"7.17578125"],[1489527261,"7.17578125"],[1489527321,"7.17578125"],[1489527381,"7.17578125"],[1489527441,"7.17578125"],[1489527501,"7.17578125"],[1489527561,"7.17578125"],[1489527621,"7.17578125"],[1489527681,"7.17578125"],[1489527741,"7.17578125"],[1489527801,"7.17578125"]]}],"memory_current":[{"metric":{},"value":[1489527801,"7.17578125"]}],"memory_previous":[{"metric":{},"value":[1489524201,"10.98046875"]}],"cpu_values":[{"metric":{},"values":[[1489524201,"0.00012136589268366878"],[1489524261,"0.00013629677228252924"],[1489524321,"0.00017998314445697447"],[1489524381,"0.0009827584630767011"],[1489524441,"0.0009918182649358627"],[1489524501,"0.00012105887843346643"],[1489524561,"0.00011065626964322616"],[1489524621,"0.00010434061276773673"],[1489524681,"0.00015477378616735764"],[1489524741,"0.00010424000457151763"],[1489524801,"0.00010732056757918497"],[1489524861,"0.00012987228814688957"],[1489524921,"0.00010601637142857337"],[1489524981,"0.00011706186666666257"],[1489525041,"0.00016982676190476298"],[1489525101,"0.00023225287859884451"],[1489525161,"0.0002654416919062003"],[1489525221,"0.0002341981047619047"],[1489525281,"0.00010737544667597162"],[1489525341,"0.00014387145286732557"],[1489525401,"0.00016059962857143024"],[1489525461,"0.0001073686380030918"],[1489525521,"0.0001147176000000001"],[1489525581,"0.00016095238956932722"],[1489525641,"0.00013953914575496462"],[1489525701,"0.00009762868571428892"],[1489525761,"0.0001464013142857146"],[1489525821,"0.00013619682482238392"],[1489525881,"0.0001421064085103956"],[1489525941,"0.00014589273353084073"],[1489526001,"0.00010787751021666243"],[1489526061,"0.0006530594139386754"],[1489526121,"0.00022928998371413064"],[1489526181,"0.0001643923084981763"],[1489526241,"0.000136318622922718"],[1489526301,"0.00024408020952380966"],[1489526361,"0.0002578990019237729"],[1489526421,"0.00025357654274986386"],[1489526481,"0.0003153278809130256"],[1489526541,"0.0003185294661054077"],[1489526601,"0.00021090772922479218"],[1489526661,"0.00013990048265202592"],[1489526721,"0.00025255341904761885"],[1489526781,"0.00025646201320037715"],[1489526841,"0.00011114179999999989"],[1489526901,"0.00010511810476190479"],[1489526961,"0.00011122324150254656"],[1489527021,"0.00012241192546583846"],[1489527081,"0.00011289356089105628"],[1489527141,"0.00009540568005409588"],[1489527201,"0.00011961359631996488"],[1489527261,"0.000116596660984181"],[1489527321,"0.00010234247619047617"],[1489527381,"0.00011585189664860324"],[1489527441,"0.0001256002552332339"],[1489527501,"0.00010966405481075191"],[1489527561,"0.00010428651696129987"],[1489527621,"0.00009176062857142876"],[1489527681,"0.00008594574544069308"],[1489527741,"0.0001365537280597326"],[1489527801,"0.0001269702761904761"]]}],"cpu_current":[{"metric":{},"value":[1489527801,"0.0001269702761904761"]}],"cpu_previous":[{"metric":{},"value":[1489524201,"0.00012136589268366878"]}]},"last_update":"2017-03-15T12:24:48.938Z"}

The only difference now is I've added additional field called cpu_previous that along with cpu_current can be used to display total change between deployments. i.e. 130MB -> 143MB

Thanks @pchojnacki, looks great!

@pchojnacki data looks good. I need to figure out how can I create the graph using this data. Thanks 👍

@fatihacet Would recommend looking at this MR: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8935

It includes the frontend work with d3 for charting the Prometheus json data.

added ~974571 label

/cc @jschatz1

I am writing a little vue component that @fatihacet can just stick in there. I didn't need d3 or anything like that. just used canvas. https://codepen.io/jschatz1/full/LWdxyg/

I'll make it a vue component for you @fatihacet Let you know when I am done.

@fatihacet here is the vue component you can use. If it has any math problems let me know. You should be able to plug and play it. https://codepen.io/jschatz1/pen/evMyLo?editors=1000

var Sparkline = {
  props: {
    data: {
      type: Object,
      default: {}
    },
    width: {
      type: Number,
      default: 150
    },
    height:  {
      type: Number,
      default: 50
    },
  },
  template: '<canvas id="sparkline" :width="width" :height="height" ></canvas>',
  mounted: function() {
    this.loadData()
  },
  
  methods: {
    loadData: function() {
      this.data = this.data.map(function(d) {
        return parseFloat(d)
      });
      this.draw()
    },
    
    draw: function() {
      var canvas = document.getElementById('sparkline');
      var ctx = canvas.getContext('2d');
      var maxNum = Math.max.apply(null, this.data);
      var minNum = Math.min.apply(null, this.data);
      var linePerPixel = canvas.width/this.data.length;
      var diff = maxNum-minNum;
      var diffPerc = canvas.height / diff;
      diffPerc -= 1.5;
      if(diff < canvas.height) diffPerc = 1;
      
      // add some padding;
      var bottomPadding = 4;
      ctx.beginPath();
      ctx.strokeStyle = 'rgb(78,141,235)';
      ctx.lineWidth = 2;
      ctx.moveTo(0, this.data[0] * diffPerc);
      this.data.forEach(function(v,i){
        console.log(v*diffPerc-minNum)
        ctx.lineTo(Math.round(i*linePerPixel), (v*diffPerc) - bottomPadding);
      });
      ctx.stroke();
    }
  }
}

@fatihacet It's kind of cheap to use the canvas you add to the screen through the template but it works. I can't think of another way unless I create a directive which would work too. I like to component better.

@jschatz1 I tried as SVG for science - https://codepen.io/psimyn/full/dvmewX

converting that to Vue could save some canvas drawing (you could use computed value for path rather than a draw method)

also flipped Y-coordinate so it was up the right way, not sure if that's fixed in the snippet above

@psimyn Cool. six of one, half a dozen of the other. They would prob both be just as fast. It's just 60 points being draw. Even 2000 points would be nothing. You can see the Vue component above. You could make yours a vue component too.

Mine is prob upside down but the thing you'd have to fix is the scale. I think my calcs are most likely off a little but I multiply by the difference percentage so if it is rendering numbers in the thousands or millions it should scale to though. You can't just render whatever the numbers are or it won't work everytime. That's what all the extra stuff is.

I cleaned up the canvas a little to make it work on retina displays and non retina. https://codepen.io/jschatz1/pen/evMyLo

@psimyn the cool thing is @fatihacet can use this today. We can fix as we need. NBD. 😄

Also canvas will always have better performance than SVG.

@jschatz1 the SVG uses viewBox to handle the scaling - Y values are between 0 and diff, and retina/non should Just Work. May need scaling for aspect ratio

For either of them, just need to do maxNum - Y for converting from Y0 being at the top

Not Vue for mine yet :)

Edit: yeah, canvas perf will demolish SVG (especially if you want any animation or draw lots of points).

Yours scaled very nicely. Mine did not. Maybe yours is better for this case. https://codepen.io/jschatz1/pen/XMEQGL Unless I fix the scaling issues for mine.

Thanks @jschatz1 and @psimyn, this is looking good! Is it possible to left align the sparkline in the event we don't have the full dataset (+/- 30 mins), rather than center align?

@joshlambert if we have a known number of points it'll be left aligned (the max length of the dataset)

Example here http://codepen.io/psimyn/pen/PpezKr

@psimyn we won't. But you should be able to left align it. That is centered. 😄 There is always a way 🚀

@psimyn as @jschatz1 mentioned we unfortunately aren't able to know the number of points in advance, as we do support customers bringing their own Prometheus server. This means they can control the sample interval, which would affect the number of points within the given hour period.

That said we do know the time bounds and we will always get 30 minutes prior to the merge which is the first half of the chart, and eventually 30 minutes after the merge. (We may not get all 30 minutes in the event this runs into the future) Could we use this timestamps to align instead of just the # of data points?

@joshlambert I explained poorly earlier, there are a few options for scaling as you described. As Jacob said, "There is always a way 🚀"

/cc @kushalpandya

assigned to @kushalpandya

mentioned in merge request !10408 (merged)

mentioned in merge request !10440 (merged)

added docs-missing label

Because of challenges with displaying the deploy time (the ball in the chart) we will push that for now and just display the sparkline for 9.1. Issue for displaying the deploy time: #30576 (closed)

mentioned in merge request !10319 (merged)

Moving to 9.2.

changed milestone to %9.2

mentioned in issue #30576 (closed)

Duplicate issue https://gitlab.com/gitlab-org/gitlab-ce/issues/30576

mentioned in merge request !11030 (merged)

mentioned in merge request !11209 (merged)

closed via merge request !11209 (merged)

mentioned in commit 5354c293

mentioned in commit 38a7f46b

@joshlambert do we have any docs for this feature?

mentioned in issue #32603 (closed)

Yes, see above. =)

mentioned in issue gitlab#8090