openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #10444
Re: Monitoring / Billing Architecture proposed
On 04/23/2012 10:09 PM, Sandy Walsh wrote:
> Flavor information is copied to the Instance table on creation so the
> Flavors can change and still be tracked in the Instance. It may just
> need to be sent in the notification payload.
>
> The current events in the system are documented here:
> http://wiki.openstack.org/SystemUsageData
>
Hi,
Metering needs to account for the "volume of data sent to external network destinations " ( i.e. n4 in http://wiki.openstack.org/EfficientMetering ) or the disk I/O etc. This kind of resource is billable.
The information described at http://wiki.openstack.org/SystemUsageData will be used by metering but other data sources need to be harvested as well.
Cheers
> -Sandy
>
>
> On 04/23/2012 02:50 PM, Brian Schott wrote:
>> So, we could build on this. No reason to reinvent, but we might want to
>> expand the number of events. I'm concerned about things like what
>> happens when flavors change over time. Maybe the answer is, always
>> append to the flavor/instance-type table. The code I remember and the
>> admin interface that Ken wrote allowed you to modify flavors. That
>> would break billing unless you also track flavor modifications.
>>
>> -------------------------------------------------
>> Brian Schott, CTO
>> Nimbis Services, Inc.
>> brian.schott@xxxxxxxxxxxxxxxxxx <mailto:brian.schott@xxxxxxxxxxxxxxxxxx>
>> ph: 443-274-6064 fx: 443-274-6060
>>
>>
>>
>> On Apr 23, 2012, at 1:40 PM, Luis Gervaso wrote:
>>
>>> I have been looking at : http://wiki.openstack.org/SystemUsageData
>>>
>>> On Mon, Apr 23, 2012 at 7:35 PM, Brian Schott
>>> <brian.schott@xxxxxxxxxxxxxxxxxx
>>> <mailto:brian.schott@xxxxxxxxxxxxxxxxxx>> wrote:
>>>
>>> Is there a document somewhere on what events the services emit?
>>>
>>> -------------------------------------------------
>>> Brian Schott, CTO
>>> Nimbis Services, Inc.
>>> brian.schott@xxxxxxxxxxxxxxxxxx
>>> <mailto:brian.schott@xxxxxxxxxxxxxxxxxx>
>>> ph: 443-274-6064 <tel:443-274-6064> fx: 443-274-6060
>>> <tel:443-274-6060>
>>>
>>>
>>>
>>> On Apr 23, 2012, at 12:39 PM, Monsyne Dragon wrote:
>>>
>>>> This already exists in trunk. The Notification system was
>>>> designed specifically to feed billing and monitoring systems.
>>>>
>>>> Basically, we don't want Nova/Glance/etc to be in the business of
>>>> trying to determine billing logic, since it is different for
>>>> pretty much everyone, so we just emit notifications to a queue
>>>> and the interested pull what they want, and aggregate according
>>>> to their own rules.
>>>>
>>>> On Apr 22, 2012, at 1:50 PM, Luis Gervaso wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I want to share the architecture i am developing in order to
>>>>> perform the monitorig / billing OpenStack support:
>>>>>
>>>>> 1. AMQP Client which listen to RabbitMQ / QPid (this should be
>>>>> interchangeable) (Own Stuff or ServiceMix / Camel)
>>>>
>>>>> 2. Events should be stored on a NoSQL document oriented database
>>>>> (I think mongodb is perfect, since we can query in a super easy
>>>>> fashion)
>>>> We have an existing system called Yagi
>>>> (https://github.com/Cerberus98/yagi/) that listens to the
>>>> notification queues and persists events to a Redis database. It
>>>> then provides feeds as ATOM formatted documents that a billing
>>>> system can pull to aggregate data, It also can support PubSub
>>>> notification of clients thru the pubsubhubub protocol, and push
>>>> events to a long-term archiving store thru the AtomPub protocol.
>>>>
>>>> That said, the notification system outputs its events as JSON, so
>>>> it should be easy to pipe into a json document-oriented db if
>>>> that's what you need. (we only use ATOM because we have a
>>>> atom-based archiving/search/aggregation engine (it's open
>>>> source: http://atomhopper.org/ ) our in-house systems already
>>>> plug into. )
>>>>
>>>>
>>>>
>>>>> 3a. The monitoring system can pull/push MongoDB
>>>>>
>>>>> 3b. The billing system can pull to create invoices
>>>>>
>>>>> 4. A mediation EIP should be necessary to integrate a
>>>>> billing/monitoring product. (ServiceMix / Camel)
>>>>>
>>>>> This is to receive your feedback. So please, critics are welcome!
>>>>>
>>>>> Cheers!
>>>>>
>>>>> --
>>>>> -------------------------------------------
>>>>> Luis Alberto Gervaso Martin
>>>>> Woorea Solutions, S.L
>>>>> CEO & CTO
>>>>> mobile: (+34) 627983344 <tel:%28%2B34%29%20627983344>
>>>>> luis@ <mailto:luis.gervaso@xxxxxxxxx>woorea.es <http://woorea.es/>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>>>>> <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help : https://help.launchpad.net/ListHelp
>>>> --
>>>> Monsyne M. Dragon
>>>> OpenStack/Nova
>>>> cell 210-441-0965 <tel:210-441-0965>
>>>> work x 5014190
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>>> --
>>> -------------------------------------------
>>> Luis Alberto Gervaso Martin
>>> Woorea Solutions, S.L
>>> CEO & CTO
>>> mobile: (+34) 627983344
>>> luis@ <mailto:luis.gervaso@xxxxxxxxx>woorea.es <http://woorea.es/>
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
--
Loïc Dachary Chief Research Officer
// eNovance labs http://labs.enovance.com
// ✉ loic@xxxxxxxxxxxx ☎ +33 1 49 70 99 82
Follow ups
References