<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 21, 2017 at 4:21 PM, Michal Skrivanek <span dir="ltr">&lt;<a href="mailto:michal.skrivanek@redhat.com" target="_blank">michal.skrivanek@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
&gt; On 21 Feb 2017, at 14:44, Yaniv Kaul &lt;<a href="mailto:ykaul@redhat.com">ykaul@redhat.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Feb 21, 2017 at 1:06 PM Francesco Romani &lt;<a href="mailto:fromani@redhat.com">fromani@redhat.com</a>&gt; wrote:<br>
&gt; Hello everyone,<br>
&gt;<br>
&gt;<br>
&gt; in the last weeks I&#39;ve been submitting PRs to collectd upstream, to<br>
&gt; bring the virt plugin up to date with Vdsm and oVirt needs.<br>
&gt;<br>
&gt; Previously, the collectd virt plugin reported only a subset of metrics<br>
&gt; oVirt uses.<br>
&gt;<br>
&gt; In current collectd master, the collectd virt plugin provides all the<br>
&gt; data Vdsm (thus Engine) needs. This means that it is now<br>
&gt;<br>
&gt; possible for Vdsm or Engine to query collectd, not Vdsm/libvirt, and<br>
&gt; have the same data.<br>
&gt;<br>
&gt; Do we wish to ship the unixsock collectd plugin? I&#39;m not sure we do these days (4.1).<br>
&gt; We can do that later, of course, when we ship this.<br>
<br>
</span>we haven’t decided on the actual solution yet, unixsocket is one possibility.<br>
it is tracked in <a href="https://trello.com/c/alAOm1tQ" rel="noreferrer" target="_blank">https://trello.com/c/alAOm1tQ</a><br>
<br>
we can also have engine pulling it from collectd remotely, then we can eliminate periodic get vm stats<br>
or another (crazy) option to use fluentd to push data straight to engine’s postgres:)<br></blockquote><div><br></div><div>why crazy? sounds like where we want to be, without going through vdsm at all</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
michal<br>
<div class="HOEnZb"><div class="h5"><br>
&gt; Y.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; There are only two caveats:<br>
&gt;<br>
&gt; 1. it is yet to be seen which version of collectd will ship all those<br>
&gt; enhancements<br>
&gt;<br>
&gt; 2. collectd *intentionally* report metrics as rates, not as absolute<br>
&gt; values as Vdsm does. This may be one issue in presence of restarts/data<br>
&gt; loss in the link between collectd and the metrics store.<br>
&gt;<br>
&gt;<br>
&gt; Please keep reading for more details:<br>
&gt;<br>
&gt;<br>
&gt; How to get the code?<br>
&gt;<br>
&gt; ------------------------------<wbr>--<br>
&gt;<br>
&gt; This somehow tricky until we get one official release. If one is<br>
&gt; familiar with the RPM build process, it is easy to build one custom packages<br>
&gt;<br>
&gt; from a snapshot from collectd master<br>
&gt; (<a href="https://github.com/collectd/collectd" rel="noreferrer" target="_blank">https://github.com/collectd/<wbr>collectd</a>) and a recent 5.7.1 RPM (like<br>
&gt; <a href="https://koji.fedoraproject.org/koji/buildinfo?buildID=835669" rel="noreferrer" target="_blank">https://koji.fedoraproject.<wbr>org/koji/buildinfo?buildID=<wbr>835669</a>)<br>
&gt;<br>
&gt;<br>
&gt; How to configure it?<br>
&gt;<br>
&gt; ------------------------------<br>
&gt;<br>
&gt; Most thing work out of the box. One currently in progress Vdsm patch<br>
&gt; ships the recommended configuration<br>
&gt; <a href="https://gerrit.ovirt.org/#/c/71176/6/static/etc/collectd.d/virt.conf" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>71176/6/static/etc/collectd.d/<wbr>virt.conf</a><br>
&gt;<br>
&gt; The meaning of the configuration option is documented in man 5 collectd.conf<br>
&gt;<br>
&gt;<br>
&gt; How it looks like?<br>
&gt;<br>
&gt; --------------------------<br>
&gt;<br>
&gt;<br>
&gt; Let me post one &quot;screenshot&quot; :)<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;   $ collectdctl listval | grep a0<br>
&gt;   a0/virt/disk_octets-hdc<br>
&gt;   a0/virt/disk_octets-vda<br>
&gt;   a0/virt/disk_ops-hdc<br>
&gt;   a0/virt/disk_ops-vda<br>
&gt;   a0/virt/disk_time-hdc<br>
&gt;   a0/virt/disk_time-vda<br>
&gt;   a0/virt/if_dropped-vnet0<br>
&gt;   a0/virt/if_errors-vnet0<br>
&gt;   a0/virt/if_octets-vnet0<br>
&gt;   a0/virt/if_packets-vnet0<br>
&gt;   a0/virt/memory-actual_balloon<br>
&gt;   a0/virt/memory-rss<br>
&gt;   a0/virt/memory-total<br>
&gt;   a0/virt/ps_cputime<br>
&gt;   a0/virt/total_requests-flush-<wbr>hdc<br>
&gt;   a0/virt/total_requests-flush-<wbr>vda<br>
&gt;   a0/virt/total_time_in_ms-<wbr>flush-hdc<br>
&gt;   a0/virt/total_time_in_ms-<wbr>flush-vda<br>
&gt;   a0/virt/virt_cpu_total<br>
&gt;   a0/virt/virt_vcpu-0<br>
&gt;   a0/virt/virt_vcpu-1<br>
&gt;<br>
&gt;<br>
&gt; How to consume the data?<br>
&gt; ------------------------------<wbr>-----------<br>
&gt;<br>
&gt; Among the ways to query collectd, the two most popular (and most fitting<br>
&gt; for oVirt use case) ways are perhaps the network protocol<br>
&gt; (<a href="https://collectd.org/wiki/index.php/Binary_protocol" rel="noreferrer" target="_blank">https://collectd.org/wiki/<wbr>index.php/Binary_protocol</a>)<br>
&gt; and the plain text protocol<br>
&gt; (<a href="https://collectd.org/wiki/index.php/Plain_text_protocol" rel="noreferrer" target="_blank">https://collectd.org/wiki/<wbr>index.php/Plain_text_protocol</a>)<wbr>. The first<br>
&gt; could be used by Engine to get the data directly, or to consolidate the<br>
&gt; metrics in one database (e.g to run any kind of query, for historical<br>
&gt; series...).<br>
&gt; The latter will be used by Vdsm to keep reporting the metrics (again<br>
&gt; <a href="https://gerrit.ovirt.org/#/c/71176/6" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>71176/6</a>)<br>
&gt;<br>
&gt; Please note that the performance of the plain text protocol are known to<br>
&gt; be lower than the binary protocol<br>
&gt;<br>
&gt; What about the unresponsive hosts?<br>
&gt; ------------------------------<wbr>-------------------------<br>
&gt;<br>
&gt; We know from experience that hosts may become unresponsive, and this can<br>
&gt; disrupt monitoring. however, we do want to keep monitoring the<br>
&gt; responsive hosts, avoiding that one rogue hosts makes us lose all the<br>
&gt; monitoring data.<br>
&gt; To  cope with this need, the virt plugin gained support for &quot;partition<br>
&gt; tag&quot;. With this, we can group VMs together using one arbitrary tag. This<br>
&gt; is completely transparent to collectd, and also completely optional.<br>
&gt; oVirt can use this tag to group VMs per-storage-domain, or however it<br>
&gt; sees fit, trying to minimize the disruption should one host become<br>
&gt; unresponsive.<br>
&gt;<br>
&gt; Read the full docs here:<br>
&gt; <a href="https://github.com/collectd/collectd/commit/999efc28d8e2e96bc15f535254d412a79755ca4f" rel="noreferrer" target="_blank">https://github.com/collectd/<wbr>collectd/commit/<wbr>999efc28d8e2e96bc15f535254d412<wbr>a79755ca4f</a><br>
&gt;<br>
&gt;<br>
&gt; What about the collectd-ovirt plugin?<br>
&gt; ------------------------------<wbr>--------------------------<br>
&gt;<br>
&gt; Some time ago I implemented one out-of-tree collectd plugin leveraging<br>
&gt; the libvirt bulk stats: <a href="https://github.com/fromanirh/collectd-ovirt" rel="noreferrer" target="_blank">https://github.com/fromanirh/<wbr>collectd-ovirt</a><br>
&gt; This plugin is meant to be a modern, drop-in replacement for the<br>
&gt; existing virt plugin.<br>
&gt; The development of that out of tree plugin is now halted, because we<br>
&gt; have everything we need in the upstream collectd plugin.<br>
&gt;<br>
&gt; Future work<br>
&gt; ------------------<br>
&gt;<br>
&gt; We believe we have reached feature parity, so we are looking for<br>
&gt; bugixes/performance tuning in the near term future. I&#39;ll be happy to<br>
&gt; provide more patches/PRs about that.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Thanks and bests,<br>
&gt;<br>
&gt; --<br>
&gt; Francesco Romani<br>
&gt; Red Hat Engineering Virtualization R &amp; D<br>
&gt; IRC: fromani<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; Devel mailing list<br>
&gt; <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
&gt; <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
&gt; ______________________________<wbr>_________________<br>
&gt; Devel mailing list<br>
&gt; <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
&gt; <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
<br>
______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><span style="font-size:12.8px"><b>Yaniv Bronhaim.</b></span><br></div></div></div></div></div>
</div></div>