<div dir="ltr">I think Sensu is the best monitoring approach out there atm. Nagios / Icinga are way to static and scale badly imho.  The kind of checks you proposed are quite interesting. I would suggest to wrap a sensu check around Tempest but that's going to far for the first cycle. <div><br></div><div>The two stacks (Sensu + Unchiwa and TICK) only really overlap in metrics collection which can be done via Sensu and Telegraf. I don't know if it makes sense to have both ... I definitely think we need Sensu though simply to monitor service availability and other thresholds and events which aren't covered in TICK as not everything is time series data and to have the alerting. Only with Sensu we don't have insight into performance and trends, with TICK only we lack alerting on events and non-performance metric data (Is Keystone up? etc)</div><div><br></div><div>I think it won't hurt to develop theses two stacks in parallel and maybe we'll join them together in a chain as I described earlier.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-24 14:25 GMT+02:00 Dave Walker <span dir="ltr"><<a href="mailto:email@daviey.com" target="_blank">email@daviey.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks <span style="font-size:12.8px;white-space:nowrap">Mathias,</span><div><span style="font-size:12.8px;white-space:nowrap"><br></span></div><div><span style="font-size:12.8px;white-space:nowrap">I'm not tied to Sensu.. anything can really fill that gap in my mind.  You've done a good job at outlining the steps involved.  I created a blueprint with the steps I had in mind[0]</span></div><div><span style="font-size:12.8px;white-space:nowrap"><br></span></div><div><span style="font-size:12.8px;white-space:nowrap">For this cycle, I wanted to keep it simple so it was easily achievable.  I only planned to have some basic up/down for each node and throw the performance data on the floor.</span></div><div><span style="font-size:12.8px;white-space:nowrap"><br></span></div><div><span style="font-size:12.8px;white-space:nowrap">I wanted to include the option to include local configs, as json blobs.  </span><span style="font-size:12.8px;white-space:nowrap">Some of the things I was thinking as local config:</span></div><div><span style="font-size:12.8px;white-space:nowrap">  - daily checkouts, can instances be built with networking</span></div><div><span style="font-size:12.8px;white-space:nowrap">  - remaining resources count (ie, does each subnet have X remaining ip addresses available)</span></div><div><span style="font-size:12.8px;white-space:nowrap">  - Is Ceph healthy?</span></div><div><span style="font-size:12.8px;white-space:nowrap"><br></span></div><div><span style="font-size:12.8px;white-space:nowrap">So, these things aren't really performance over time interesting.. which means the intention does differ.  However, I do agree that both stacks could achieve both objectives.</span></div><div><span style="font-size:12.8px;white-space:nowrap"><br></span></div><div><span style="font-size:12.8px;white-space:nowrap">I've essentially got much of this working locally, but would require about a day of cleaning up for submission... but if your work can achieve the objectives above, i'm happy to discontinue... or help make your stack pluggable.</span></div><div><span style="font-size:12.8px;white-space:nowrap"><br></span></div><div><span style="font-size:12.8px;white-space:nowrap">[0] <a href="https://blueprints.launchpad.net/kolla/+spec/sensu" target="_blank">https://blueprints.launchpad.net/kolla/+spec/sensu</a></span></div><span class=""><div><span style="font-size:12.8px;white-space:nowrap"><br></span></div><div><span style="font-size:12.8px;white-space:nowrap">--</span></div><div><span style="font-size:12.8px;white-space:nowrap">Kind Regards,</span></div><div><span style="font-size:12.8px;white-space:nowrap">Dave Walker</span></div></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 24 July 2016 at 11:56, Mathias Ewald <span dir="ltr"><<a href="mailto:mewald@evoila.de" target="_blank">mewald@evoila.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Monitoring is a difficult topic as the number of options regarding the toolset and mechanisms are very high. We had some chats about it in IRC that discovered even more options than I thought existed :D I believe Dave's view on Sensu is generally correct in that Sensu is more directed to monitoring in the form of "if X running/working" but of course has the ability to transport metrics, too, but lacks the good dashboarding capabilities for performance data. One set up I could images is<div><br></div><div>1. Sensu Client to collect checks and metrics</div><div>2. RabbitMQ for transport</div><div>3. Sensu Server to receive, evaluate, alarm and write metrics to InfluxDB</div><div>4. Uchiwa as a Dashboard to Sensu</div><div>5. InfluxDB to store metrics</div><div>6. Grafana to dashboard metrics</div><div><br></div><div>So Sensu could be used as a replacement for (or in addition to) a metrics collection daemon like Collectd or what I decided to use: Telegraf. For my implementation, this means I will add a parameter to make Telegraf optional. This way, someone else may implement the rest of the stack and the user can decide which one to use.</div><div><br></div><div>What do you think?</div><div><br></div><div>Mathias</div><div><br></div><div><br></div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">2016-07-23 21:51 GMT+02:00 Stephen Hindle <span dir="ltr"><<a href="mailto:shindle@llnw.com" target="_blank">shindle@llnw.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My understanding was Sensu could produce metrics ?<br>
And Kapacitor can do alerting for the TICK stack stuff mewald is doing...<br>
I really don't see them as that different ?<br>
<div><div><br>
<br>
On Fri, Jul 22, 2016 at 5:19 PM, Dave Walker <<a href="mailto:email@daviey.com" target="_blank">email@daviey.com</a>> wrote:<br>
> Yes, this is my thought.<br>
><br>
> The scope of the Sensu work is: "Is this thing working?" (with the reference<br>
> being up/down)<br>
> But the scope of the Grafana and friends is, "How hard is this working?"<br>
> (but no alerting)<br>
><br>
> They are certainly complementary.... However, Sensu can throw data at a<br>
> Grafana stack (aiui).. but I fear that is too much to achieve this cycle.<br>
><br>
> --<br>
> Kind Regards,<br>
> Dave Walker<br>
><br>
> On 23 July 2016 at 00:11, Fox, Kevin M <<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>> wrote:<br>
>><br>
>> I think those are two different, complementary things.<br>
>><br>
>> One's metrics and the other is monitoring. You probably want both at the<br>
>> same time.<br>
>><br>
>> Thanks,<br>
>> Kevin<br>
>> ________________________________________<br>
>> From: Steven Dake (stdake) [<a href="mailto:stdake@cisco.com" target="_blank">stdake@cisco.com</a>]<br>
>> Sent: Friday, July 22, 2016 3:52 PM<br>
>> To: OpenStack Development Mailing List (not for usage questions)<br>
>> Subject: Re: [openstack-dev] [kolla] Monitoring tooling<br>
>><br>
>> Thanks for pointing that out.  Brain out to lunch today it appears :(<br>
>><br>
>> I think choices are a good thing even though they increase our<br>
>> implementation footprint.  Anyone opposed to implementing both with<br>
>> something in globals.yml like<br>
>> monitoring: grafana or<br>
>> monitoring: sensu<br>
>><br>
>> Comments questions or concerns welcome.<br>
>><br>
>> Regards<br>
>> -steve<br>
>><br>
>> On 7/22/16, 3:42 PM, "Stephen Hindle" <<a href="mailto:shindle@llnw.com" target="_blank">shindle@llnw.com</a>> wrote:<br>
>><br>
>> >Don't forget mewalds implementation as well - we now have 2 monitoring<br>
>> >options for kolla :-)<br>
>> ><br>
>> >On Fri, Jul 22, 2016 at 3:15 PM, Steven Dake (stdake) <<a href="mailto:stdake@cisco.com" target="_blank">stdake@cisco.com</a>><br>
>> >wrote:<br>
>> >> Hi folks,<br>
>> >><br>
>> >> At the midcycle we decided to push off implementing Monitoring until<br>
>> >>post<br>
>> >> Newton.  The rationale for this decision was that the core review team<br>
>> >>has<br>
>> >> enough on their plates and nobody was super keen to implement any<br>
>> >>monitoring<br>
>> >> solution given our other priorities.<br>
>> >><br>
>> >> Like all good things, communities produce new folks that want to do new<br>
>> >> things, and Sensu was proposed as Kolla's monitoring solution (atleast<br>
>> >>the<br>
>> >> first one).  A developer that has done some good work has shown up to<br>
>> >>do the<br>
>> >> job as well :)  I have heard good things about Sensu, minus the fact<br>
>> >>that it<br>
>> >> is implemented in Ruby and I fear it may end up causing our gate a lot<br>
>> >>of<br>
>> >> hassle.<br>
>> >><br>
>> >> <a href="https://review.openstack.org/#/c/341861/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/341861/</a><br>
>> >><br>
>> >><br>
>> >> Anyway I think we can work through the gate problem.<br>
>> >><br>
>> >> Does anyone have any better suggestion?  I'd like to unblock Dave's<br>
>> >> work<br>
>> >> which is blocked on a ­2 pending a complete discussion of our<br>
>> >> monitoring<br>
>> >> solution.  Note we may end up implementing more than one down the road<br>
>> >> ­<br>
>> >> Sensu is just where the original interest was.<br>
>> >><br>
>> >> Please provide feedback, even if you don't have a preference, whether<br>
>> >>your a<br>
>> >> core reviewer or not.<br>
>> >><br>
>> >> My take is we can merge this work in non-prioirty order, and if it<br>
>> >>makes the<br>
>> >> end of the cycle fantastic ­ if not, we can release it in Ocatta.<br>
>> >><br>
>> >> Regards<br>
>> >> -steve<br>
>> >><br>
>> >><br>
>> >><br>
>><br>
>> >> >>_________________________________________________________________________<br>
>> >>_<br>
>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> Unsubscribe:<br>
>> >><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >><br>
>> ><br>
>> ><br>
>> ><br>
>> >--<br>
>> >Stephen Hindle - Senior Systems Engineer<br>
>> ><a href="tel:480.807.8189" value="+14808078189" target="_blank">480.807.8189</a> <a href="tel:480.807.8189" value="+14808078189" target="_blank">480.807.8189</a><br>
>> ><a href="http://www.limelight.com" rel="noreferrer" target="_blank">www.limelight.com</a> Delivering Faster Better<br>
>> ><br>
>> >Join the conversation<br>
>> ><br>
>> >at Limelight Connect<br>
>> ><br>
>> >--<br>
>> >The information in this message may be confidential.  It is intended<br>
>> >solely<br>
>> >for<br>
>> >the addressee(s).  If you are not the intended recipient, any disclosure,<br>
>> >copying or distribution of the message, or any action or omission taken<br>
>> >by<br>
>> >you<br>
>> >in reliance on it, is prohibited and may be unlawful.  Please immediately<br>
>> >contact the sender if you have received this message in error.<br>
>> ><br>
>> ><br>
>><br>
>> > >__________________________________________________________________________<br>
>> >OpenStack Development Mailing List (not for usage questions)<br>
>> >Unsubscribe:<br>
>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> ><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
Stephen Hindle - Senior Systems Engineer<br>
<a href="tel:480.807.8189" value="+14808078189" target="_blank">480.807.8189</a> <a href="tel:480.807.8189" value="+14808078189" target="_blank">480.807.8189</a><br>
<a href="http://www.limelight.com" rel="noreferrer" target="_blank">www.limelight.com</a> Delivering Faster Better<br>
<br>
Join the conversation<br>
<br>
at Limelight Connect<br>
<br>
--<br>
The information in this message may be confidential.  It is intended solely<br>
for<br>
the addressee(s).  If you are not the intended recipient, any disclosure,<br>
copying or distribution of the message, or any action or omission taken by<br>
you<br>
in reliance on it, is prohibited and may be unlawful.  Please immediately<br>
contact the sender if you have received this message in error.<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div>-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Mobil: <a href="tel:%2B49%20176%2010567592" value="+4917610567592" target="_blank">+49 176 10567592</a><br>E-Mail: <a href="mailto:mewald@evoila.de" target="_blank">mewald@evoila.de</a><br><br>evoila GmbH<br>Wilhelm-Theodor-Römheld-Str. 34 <br>55130 Mainz<br>Germany<br><br>Geschäftsführer: Johannes Hiemer<br><br>Amtsgericht Mainz HRB 42719<br><br>Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.<br><br>This e-mail may contain confidential and/or privileged information. If You are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.<br></div></div></div></div>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></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">Mobil: +49 176 10567592<br>E-Mail: <a href="mailto:mewald@evoila.de" target="_blank">mewald@evoila.de</a><br><br>evoila GmbH<br>Wilhelm-Theodor-Römheld-Str. 34 <br>55130 Mainz<br>Germany<br><br>Geschäftsführer: Johannes Hiemer<br><br>Amtsgericht Mainz HRB 42719<br><br>Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.<br><br>This e-mail may contain confidential and/or privileged information. If You are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.<br></div></div></div></div>
</div>