Open Stack

Hey German,

I totally agree on the security/privacy aspect of logs, especially due to
the SSL/TLS Termination feature.

After looking at BP [1] and the spec [2] for metering, it looks like it is
proposing to send more than just billable usage to cielometer. From my
previous email I considered this "tracking" usage ("billable" usage can be
a subset of tracking usage). It also appears to me that there is an
implied interface  for cielometer as we need to be able to capture metrics
from various lb devices (HAProxy, Nginx, Netscaler, etc.), standardize
them, and then send them off. That said, what type of implementation was
HP thinking of to gather these metrics? Instead of focusing on my idea of
using logging I'd like to change the discussion and get a picture as to
what you all are envisioning for a possible implementation direction.
Important items for Rackspace include accuracy of data, no lost data (i.e.
when sending to upstream system ensure it gets there), reliability of
cadence when sending usage to upstream system, and the ability to
backtrack and audit data whenever there seems to be a discrepancy in a
customer's monthly statement. Keep in mind that we need to integrate with
our current billing pipeline so we are not planning on using cielometer at
the moment. Thus, we need to make this somewhat configurable for those not
using cielometer.

Cheers,
--Jorge

[1] 
https://blueprints.launchpad.net/ceilometer/+spec/ceilometer-meter-lbaas

[2] https://review.openstack.org/#/c/94958/12/specs/juno/lbaas_metering.rst


On 10/24/14 5:19 PM, "Eichberger, German" <german.eichberger at hp.com> wrote:

>Hi Jorge,
>
>I agree completely with the points you make about the logs. We still feel
>that metering and logging are two different problems. The ceilometers
>community has a proposal on how to meter lbaas (see
>http://specs.openstack.org/openstack/ceilometer-specs/specs/juno/lbaas_met
>ering.html) and we at HP think that those values are be sufficient for us
>for the time being.
>
>I think our discussion is mostly about connection logs which are emitted
>some way from amphora (e.g. haproxy logs). Since they are customer's logs
>we need to explore on our end the privacy implications (I assume at RAX
>you have controls in place to make sure that there is no violation :-).
>Also I need to check if our central logging system is scalable enough and
>we can send logs there without creating security holes.
>
>Another possibility is to log like syslog our apmphora agent logs to a
>central system to help with trouble shooting debugging. Those could be
>sufficiently anonymized to avoid privacy issue. What are your thoughts on
>logging those?
>
>Thanks,
>German
>
>-----Original Message-----
>From: Jorge Miramontes [mailto:jorge.miramontes at RACKSPACE.COM]
>Sent: Thursday, October 23, 2014 3:30 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements
>
>Hey German/Susanne,
>
>To continue our conversation from our IRC meeting could you all provide
>more insight into you usage requirements? Also, I'd like to clarify a few
>points related to using logging.
>
>I am advocating that logs be used for multiple purposes, including
>billing. Billing requirements are different that connection logging
>requirements. However, connection logging is a very accurate mechanism to
>capture billable metrics and thus, is related. My vision for this is
>something like the following:
>
>- Capture logs in a scalable way (i.e. capture logs and put them on a
>separate scalable store somewhere so that it doesn't affect the amphora).
>- Every X amount of time (every hour, for example) process the logs and
>send them on their merry way to cielometer or whatever service an
>operator will be using for billing purposes.
>- Keep logs for some configurable amount of time. This could be anything
>from indefinitely to not at all. Rackspace is planing on keeping them for
>a certain period of time for the following reasons:
>	
>	A) We have connection logging as a planned feature. If a customer turns
>on the connection logging feature for their load balancer it will already
>have a history. One important aspect of this is that customers (at least
>ours) tend to turn on logging after they realize they need it (usually
>after a tragic lb event). By already capturing the logs I'm sure
>customers will be extremely happy to see that there are already X days
>worth of logs they can immediately sift through.
>	B) Operators and their support teams can leverage logs when providing
>service to their customers. This is huge for finding issues and resolving
>them quickly.
>	C) Albeit a minor point, building support for logs from the get-go
>mitigates capacity management uncertainty. My example earlier was the
>extreme case of every customer turning on logging at the same time. While
>unlikely, I would hate to manage that!
>
>I agree that there are other ways to capture billing metrics but, from my
>experience, those tend to be more complex than what I am advocating and
>without the added benefits listed above. An understanding of HP's desires
>on this matter will hopefully get this to a point where we can start
>working on a spec.
>
>Cheers,
>--Jorge
>
>P.S. Real-time stats is a different beast and I envision there being an
>API call that returns "real-time" data such as this ==>
>http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#9.
>
>
>From:  <Eichberger>, German <german.eichberger at hp.com>
>Reply-To:  "OpenStack Development Mailing List (not for usage questions)"
><openstack-dev at lists.openstack.org>
>Date:  Wednesday, October 22, 2014 2:41 PM
>To:  "OpenStack Development Mailing List (not for usage questions)"
><openstack-dev at lists.openstack.org>
>Subject:  Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements
>
>
>>Hi Jorge,
>> 
>>Good discussion so far + glad to have you back J
>> 
>>I am not a big fan of using logs for billing information since
>>ultimately (at least at HP) we need to pump it into ceilometer. So I am
>>envisioning either the  amphora (via a proxy) to pump it straight into
>>that system or we collect it on the controller and pump it from there.
>> 
>>Allowing/enabling logging creates some requirements on the hardware,
>>mainly, that they can handle the IO coming from logging. Some operators
>>might choose to  hook up very cheap and non performing disks which
>>might not be able to deal with the log traffic. So I would suggest that
>>there is some rate limiting on the log output to help with that.
>>
>> 
>>Thanks,
>>German
>> 
>>From: Jorge Miramontes [mailto:jorge.miramontes at RACKSPACE.COM]
>>
>>Sent: Wednesday, October 22, 2014 6:51 AM
>>To: OpenStack Development Mailing List (not for usage questions)
>>Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage
>>Requirements
>>
>>
>> 
>>Hey Stephen (and Robert),
>>
>> 
>>
>>For real-time usage I was thinking something similar to what you are
>>proposing. Using logs for this would be overkill IMO so your
>>suggestions were what I was  thinking of starting with.
>>
>> 
>>
>>As far as storing logs is concerned I was definitely thinking of
>>offloading these onto separate storage devices. Robert, I totally hear
>>you on the scalability  part as our current LBaaS setup generates TB of
>>request logs. I'll start planning out a spec and then I'll let everyone
>>chime in there. I just wanted to get a general feel for the ideas I had
>>mentioned. I'll also bring it up in today's meeting.
>>
>> 
>>
>>Cheers,
>>
>>--Jorge
>>
>>
>>
>>
>> 
>>
>>From:
>>Stephen Balukoff <sbalukoff at bluebox.net>
>>Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>><openstack-dev at lists.openstack.org>
>>Date: Wednesday, October 22, 2014 4:04 AM
>>To: "OpenStack Development Mailing List (not for usage questions)"
>><openstack-dev at lists.openstack.org>
>>Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Usage
>>Requirements
>>
>> 
>>
>>>Hi Jorge!
>>>
>>> 
>>>
>>>Welcome back, eh! You've been missed.
>>>
>>> 
>>>
>>>Anyway, I just wanted to say that your proposal sounds great to me,
>>>and it's good to finally be closer to having concrete requirements for
>>>logging, eh. Once this  discussion is nearing a conclusion, could you
>>>write up the specifics of logging into a specification proposal
>>>document?
>>>
>>> 
>>>
>>>Regarding the discussion itself: I think we can ignore UDP for now, as
>>>there doesn't seem to be high demand for it, and it certainly won't be
>>>supported in v 0.5  of Octavia (and maybe not in v1 or v2 either,
>>>unless we see real demand).
>>>
>>> 
>>>
>>>Regarding the 'real-time usage' information: I have some ideas
>>>regarding getting this from a combination of iptables and / or the
>>>haproxy stats interface. Were  you thinking something different that
>>>involves on-the-fly analysis of the logs or something?  (I tend to
>>>find that logs are great for non-real time data, but can often be
>>>lacking if you need, say, a gauge like 'currently open connections' or
>>>something.)
>>>
>>> 
>>>
>>>One other thing: If there's a chance we'll be storing logs on the
>>>amphorae themselves, then we need to have log rotation as part of the
>>>configuration here. It  would be silly to have an amphora failure just
>>>because its ephemeral disk fills up, eh.
>>>
>>> 
>>>
>>>Stephen
>>>
>>>
>>> 
>>>On Wed, Oct 15, 2014 at 4:03 PM, Jorge Miramontes
>>><jorge.miramontes at rackspace.com> wrote:
>>>Hey Octavia folks!
>>>
>>>
>>>First off, yes, I'm still alive and kicking. :)
>>>
>>>I,d like to start a conversation on usage requirements and have a few
>>>suggestions. I advocate that, since we will be using TCP and
>>>HTTP/HTTPS based protocols, we inherently enable connection logging
>>>for load balancers for several reasons:
>>>
>>>1) We can use these logs as the raw and granular data needed to track
>>>usage. With logs, the operator has flexibility as to what usage
>>>metrics they want to bill against. For example, bandwidth is easy to
>>>track and can even be split into header and body data so that the
>>>provider can choose if they want to bill on header data or not. Also,
>>>the provider can determine if they will bill their customers for
>>>failed requests that were the fault of the provider themselves. These
>>>are just a few examples; the point is the flexible nature of logs.
>>>
>>>2) Creating billable usage from logs is easy compared to other options
>>>like polling. For example, in our current LBaaS iteration at Rackspace
>>>we bill partly on "average concurrent connections". This is based on
>>>polling and is not as accurate as it possibly can be. It's very close,
>>>but it doesn't get more accurate that the logs themselves.
>>>Furthermore, polling is more complex and uses up resources on the
>>>polling cadence.
>>>
>>>3) Enabling logs for all load balancers can be used for debugging,
>>>support and audit purposes. While the customer may or may not want
>>>their logs uploaded to swift, operators and their support teams can
>>>still use this data to help customers out with billing and setup
>>>issues. Auditing will also be easier with raw logs.
>>>
>>>4) Enabling logs for all load balancers will help mitigate uncertainty
>>>in terms of capacity planning. Imagine if every customer suddenly
>>>enabled logs without it ever being turned on. This could produce a
>>>spike in resource utilization that will be hard to manage. Enabling
>>>logs from the start means we are certain as to what to plan for other
>>>than the nature of the customer's traffic pattern.
>>>
>>>Some Cons I can think of (please add more as I think the pros outweigh
>>>the
>>>cons):
>>>
>>>1) If we every add UDP based protocols then this model won't work. <
>>>1% of our load balancers at Rackspace are UDP based so we are not
>>>looking at using this protocol for Octavia. I'm more of a fan of
>>>building a really good TCP/HTTP/HTTPS based load balancer because UDP
>>>load balancing solves a different problem. For me different problem ==
>>>different product.
>>>
>>>2) I'm assuming HA Proxy. Thus, if we choose another technology for
>>>the amphora then this model may break.
>>>
>>>
>>>Also, and more generally speaking, I have categorized usage into three
>>>categories:
>>>
>>>1) Tracking usage - this is usage that will be used my operators and
>>>support teams to gain insight into what load balancers are doing in an
>>>attempt to monitor potential issues.
>>>2) Billable usage - this is usage that is a subset of tracking usage
>>>used to bill customers.
>>>3) Real-time usage - this is usage that should be exposed via the API
>>>so that customers can make decisions that affect their configuration
>>>(ex.
>>>"Based off of the number of connections my web heads can handle when
>>>should I add another node to my pool?").
>>>
>>>These are my preliminary thoughts, and I'd love to gain insight into
>>>what the community thinks. I have built about 3 usage collection
>>>systems thus far (1 with Brandon) and have learned a lot. Some basic
>>>rules I have discovered with collecting usage are:
>>>
>>>1) Always collect granular usage as it "paints a picture" of what
>>>actually happened. Massaged/un-granular usage == lost information.
>>>2) Never imply, always be explicit. Implications usually stem from bad
>>>assumptions.
>>>
>>>
>>>Last but not least, we need to store every user and system load
>>>balancer event such as creation, updates, suspension and deletion so
>>>that we may bill on things like uptime and serve our customers better
>>>by knowing what happened and when.
>>>
>>>
>>>Cheers,
>>>--Jorge
>>>
>>>
>>>_______________________________________________
>>>OpenStack-dev mailing list
>>>OpenStack-dev at lists.openstack.org
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> 
>>>
>>>--
>>>
>>>Stephen Balukoff
>>>Blue Box Group, LLC
>>>(800)613-4305 x807
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev