<div dir="ltr">Hi All,<br><br>I am contributing to the engine for three months now. While I dug into the code I<br>started to wonder how to visualize what the engine is actually doing.<br><br>To get better insights I added hystrix[1] to the engine. Hystrix is a circuit<br>breaker library which was developed by Netflix and has one pretty interesting<br>feature: Real time metrics for commands.<br><br>In combination with hystrix-dashboard[2] it allows very interesting insights.<br>You can easily get an overview of commands involved in operations, their<br>performance and complexity. Look at [2] and the attachments in [5] and [6] for<br>screenshots to get an Impression.<br><br>I want to propose to integrate hystrix permanently because from my perspective<br>the results were really useful and I also had some good experiences with hystrix<br>in past projects.<br><br>A first implementation can be found on gerrit[3].<br><br># Where is it immediately useful?<br><br>During development and QA.<br><br>An example: I tested the hystrix integration on /api/vms and /api/hosts rest<br>endpoints and immediately saw that the number of command exectuions grew<br>lineary whit the number of vms and hosts. The bug reports [5] and [6] are the<br>result.<br><br># How to monitor the engine?<br><br>It is as easy as starting a hystrix-dashboard [2] with<br><br>  $ git clone <a href="https://github.com/Netflix/Hystrix.git" target="_blank">https://github.com/Netflix/Hystrix.git</a><br>  $ cd Hystrix/hystrix-dashboard<br>  $ ../gradlew jettyRun<br><br>and point the dashboard to <br><br>   https://&lt;customer.engine.ip&gt;/ovirt-engine/hystrix.stream.<br><br># Other possible benefits?<br><br> * Live metrics at customer site for admins, consultants and support.<br><br> * Historical metrics for analysis in addition to the log files.<br>   The metrics information is directly usable in graphite [7]. Therefore it would be<br>   possible to collect the json stream for a certain time period and analyze them<br>   later like in [4]. To do that someone just has to run<br><br>      curl --user admin@internal:engine <a href="http://localhost:8080/ovirt-engine/api/hystrix.stream" target="_blank">http://localhost:8080/ovirt-engine/api/hystrix.stream</a> &gt; hystrix.stream<br><br>   for as long as necessary. The results can be analyzed later.<br><br># Possible architectural benefits?<br><br>In addition to the live metrics we might also have use for the real hystrix features:<br><br> * Circuit Breaker<br> * Bulk execution of commands<br> * De-dublication of commands (Caching)<br> * Synchronous and asynchronous execution support<br> * ...<br><br>Our commands do already have a lot of features, so I don&#39;t think that there are<br>some quick wins, but maybe there are interesting opportunities for infra.<br><br># Overhead?<br><br>In [5] the netflix employees describe their results regarding the overhead of<br>wrapping every command into a new instance of a hystrix command.<br><br>They ran their tests on a standard 4-core Amazon EC2 server with a load of 60<br>request per second.<br><br>When using threadpools they measured a mean overhead of less than one<br>millisecond (so negligible).  At the 90th percentile they measured an overhead<br>of 3 ms. At the 99th percentile of about 9 ms.<br><br>When configuring the hystrix commands to use semaphores instead of threadpools<br>they are even faster.<br><br># How to integrate?<br><br>A working implementation can be found on gerrit[3].  These patch sets wrap a<br>hystrix command around every VdcAction, every VdcQuery and every VDSCommand.<br>This just required four small modifications in the code base.<br><br># Security?<br><br>In the provided patches the hystrix-metrics-servlet is accessible at<br>/ovirt-engine/api/hystrix.stream. It is protected by basic auth but accessible<br>for everyone who can authenticate. We should probably restrict it to admins.<br><br># Todo?<br><br>1) We do report failed actions with return values. Hystrix expects failing<br>commands to throw an exception.  So on the dashboard almost every command looks<br>like a success.  To overcome this, it would be pretty easy to throw an<br>exception inside the command and catch it immediately after it leaves the<br>hystrix wrapper.<br><br>2) Finetuning<br>Do we want semaphores or a thread pool. When the thread pool, what size do we want? <br><br>3) Three unpackaged dependencies: archaius, hystrix-core, hystrix-contrib<br><br># References<br><br>[1] <a href="https://github.com/Netflix/Hystrix" target="_blank">https://github.com/Netflix/Hystrix</a><br>[2] <a href="https://github.com/Netflix/Hystrix/tree/master/hystrix-dashboard" target="_blank">https://github.com/Netflix/Hystrix/tree/master/hystrix-dashboard</a> <br>[3] <a href="https://gerrit.ovirt.org/#/q/topic:hystrix" target="_blank">https://gerrit.ovirt.org/#/q/topic:hystrix</a> <br>[4] <a href="http://www.nurkiewicz.com/2015/02/storing-months-of-historical-metrics.html" target="_blank">http://www.nurkiewicz.com/2015/02/storing-months-of-historical-metrics.html</a><br>[5] <a href="https://github.com/Netflix/Hystrix/wiki/FAQ#what-is-the-processing-overhead-of-using-hystrix" target="_blank">https://github.com/Netflix/Hystrix/wiki/FAQ#what-is-the-processing-overhead-of-using-hystrix</a><br>[5] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1268216" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1268216</a> <br>[6] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1268224" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1268224</a><br>[7] <a href="http://graphite.wikidot.com" target="_blank">http://graphite.wikidot.com</a><br></div>