<div dir="ltr">Hi Jorge,<div><br></div><div>This thread as started mostly to try to determine what people are actually after, as far as stats collection goes. Surprisingly (to me at least), it doesn't look like we need all that much to meet the needs of those who have responded to this thread thus far.</div>
<div><br></div><div>In any case, my sights are set on preparation for next week's hack-a-thon, and in any case I don't see stats gathering as a high priority for this group right now. (Though basic stats will need to happen before we can consider the service "minimally viable," IMO.) In any case, I'm seeing nothing anyone is asking for, stats-wise, which is going to cause problems for us as we continue on our current course developing LBaaS.</div>
<div><br></div><div>And having this thread to look back on when it comes time to actually solve the stats problem will be a good thing, eh.</div><div><br></div><div>Stephen</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, Jun 6, 2014 at 11:35 AM, Jorge Miramontes <span dir="ltr"><<a href="mailto:jorge.miramontes@rackspace.com" target="_blank">jorge.miramontes@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey Stephen,<br>
<br>
What we really care about are the following:<br>
<br>
- Inbound bandwidth (bytes)<br>
- Outbound bandwidth (bytes)<br>
- "Instance" Uptime (requires create/delete events)<br>
<br>
Just to note our current LBaaS implementation at Rackspace keeps track of<br>
when features are enabled/disabled. For example, we have markers for when<br>
SSL is turned on/off, markers for when we suspend/unsuspend load<br>
balancers, etc. Some of this stuff is used for tracking purposes, some of<br>
it is used for billing purposes and some of it used for both purposes. We<br>
also keep track of all user initiated API requests to help us out when<br>
issues arise.<br>
<br>
>From my experience building usage collection systems just know it is not a<br>
trivial task, especially if we need to track events. One good tip is to be<br>
as explicit as possible and as granular as possible. Being implicit causes<br>
bad things to happen. Also, if we didn't have UDP as a protocol I would<br>
recommend using Hadoop's map reduce functionality to get accurate<br>
statistics by map-reducing request logs.<br>
<br>
I would not advocate tracking per node statistics as the user can track<br>
that information by themselves if they really want to. We currently, don't<br>
have any customers that have asked for this feature.<br>
<br>
If you want to tackle the usage collection problem for Neutron LBaaS I<br>
would be glad to help as I've got quite a bit of experience in this<br>
subject matter.<br>
<br>
Cheers,<br>
--Jorge<br>
<br>
<br>
<br>
<br>
From:  <Eichberger>, German <<a href="mailto:german.eichberger@hp.com">german.eichberger@hp.com</a>><br>
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Date:  Tuesday, June 3, 2014 5:20 PM<br>
<div class="">To:  "OpenStack Development Mailing List (not for usage questions)"<br>
</div><<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject:  Re: [openstack-dev] [Neutron][LBaaS] Requirements around<br>
statistics and  billing<br>
<br>
<div class=""><br>
>Hi Stephen,<br>
><br>
>We would like all those numbers as well<br>
>J<br>
><br>
>Additionally, we measure:<br>
>·<br>
>When a lb instance was created, deleted, etc.<br>
>·<br>
>For monitoring we ³ping² a load balancers health check and report/act on<br>
>the results<br>
>·<br>
>For user¹s troubleshooting we make the haproxy logs available. Which<br>
>contain connection information like from, to, duration, protocol, status<br>
>(though<br>
> we frequently have been told that this is not really useful for<br>
</div>>debuggingŠ) and of course having that more gui-fied would be neat<br>
<div><div class="h5">><br>
>German<br>
><br>
><br>
><br>
>From: Stephen Balukoff [mailto:<a href="mailto:sbalukoff@bluebox.net">sbalukoff@bluebox.net</a>]<br>
><br>
>Sent: Tuesday, May 27, 2014 8:22 PM<br>
>To: OpenStack Development Mailing List (not for usage questions)<br>
>Subject: [openstack-dev] [Neutron][LBaaS] Requirements around statistics<br>
>and billing<br>
><br>
><br>
>Hi folks!<br>
><br>
><br>
>We have yet to have any kind of meaningful discussion on this list around<br>
>load balancer stats (which, I presume to include data that will<br>
>eventually need to be consumed by a billing system). I'd like to get the<br>
>discussion started here,<br>
> as this will have significant meaning for how we both make this data<br>
>available to users, and how we implement back-end systems to be able to<br>
>provide this data.<br>
><br>
><br>
><br>
>So!  What kinds of data are people looking for, as far as load balancer<br>
>statistics.<br>
><br>
><br>
><br>
>For our part, as an absolute minimum we need the following per<br>
>loadbalancer + listener combination:<br>
><br>
><br>
><br>
>* Total bytes transferred in for a given period<br>
><br>
>* Total bytes transferred out for a given period<br>
><br>
><br>
><br>
>Our product and billing people I'm sure would like the following as well:<br>
><br>
><br>
><br>
>* Some kind of peak connections / second data (95th percentile or average<br>
>over a period, etc.)<br>
><br>
>* Total connections for a given period<br>
><br>
>* Total HTTP / HTTPS requests served for a given period<br>
><br>
><br>
><br>
>And the people who work on UIs and put together dashboards would like:<br>
><br>
><br>
><br>
>* Current requests / second (average for last X seconds, either<br>
>on-demand, or simply dumped regularly).<br>
><br>
>* Current In/Out bytes throughput<br>
><br>
><br>
><br>
>And our monitoring people would like this:<br>
><br>
><br>
><br>
>* Errors / second<br>
><br>
>* Current connections / second and bytes throughput secant slope (ie.<br>
>like derivative but easier to calculate from digital data) for last X<br>
>seconds (ie. detecting massive spikes or drops in traffic, potentially<br>
>useful for detecting a problem<br>
> before it becomes critical)<br>
><br>
><br>
><br>
>And some of our users would like all of the above data per pool, and not<br>
>just for loadbalancer + listener. Some would also like to see it per<br>
>member (though I'm less inclined to make this part of our standard).<br>
><br>
><br>
><br>
>I'm also interested in hearing vendor capabilities here, as it doesn't<br>
>make sense to design stats that most can't implement, and I imagine<br>
>vendors also have valuable data on what their customer ask for / what<br>
>stats are most useful in troubleshooting.<br>
><br>
><br>
><br>
>What other statistics data for load balancing are meaningful and<br>
>hopefully not too arduous to calculate? What other data are your users<br>
>asking for or accustomed to seeing?<br>
><br>
><br>
><br>
>Thanks,<br>
><br>
>Stephen<br>
><br>
><br>
><br>
>--<br>
>Stephen Balukoff<br>
>Blue Box Group, LLC<br>
><a href="tel:%28800%29613-4305%20x807" value="+18006134305">(800)613-4305 x807</a><br>
<br>
<br>
</div></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807

</div>