<br><br><div class="gmail_quote">On Wed, Jan 30, 2013 at 8:32 AM, Julien Danjou <span dir="ltr"><<a href="mailto:julien@danjou.info" target="_blank">julien@danjou.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Jan 29 2013, Angus Salkeld wrote:<br>
<br>
> Nice walk through, I need to try digest how that is all going to fit together.<br>
><br>
> It initially seems to me that there is a new entity "Notification/TracePoint"?<br>
> They don't really seem like meters, and it might make sense to just model<br>
> correctly rather than trying to squeeze them into meters.<br>
<br>
</div>+1<br>
<br>
>From what I understand from your video, StackTach logs raw notifications<br>
and then feed data into a few tables, doing some computing.<br>
<br>
So what it does is down to:<br>
1. Stock raw notifications<br>
2. Compute values from these notifications and cache them (= store them<br>
   into a few tables)<br>
   Some of these values might be meters.<br>
<br>
I don't think Ceilometer collector is going to store raw notifications.<br>
There's no point into the whole Ceilometer project to store this data.<br></blockquote><div><br></div><div>I disagree. </div><div><br></div><div>StackTach is answering questions we aren't, yet, like "how long did an operation take?", "what actually happened during processing of the request?", etc. I think we would benefit from adding at least some of that to ceilometer, particularly for SLA auditing. I agree with Angus' suggestion of adding new models, though, rather than trying to squeeze it into the existing data model as Sandy seems to be suggesting in the video. We would also likely want a new API endpoint for querying the new types of data.</div>
<div><br></div><div>My first suggestion was going to be to add a notification handler plugin that listened for the interesting notification messages and then stored them in the database, but if we are going to bring this into the core we should just add that step to the existing processing loop in the collector and then extend the storage engine API with a new method to store the notification.</div>
<div><br></div><div>We may even be able to reduce some of the duplication of metadata if we just include a reference to the notification in the meter table instead of the entire metadata blob (I need to think more about whether that would actually work).</div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Your best call here is probably to keep that part of StackTach if you<br>
really need all the raw notifications.<br>
<br>
For things are likely to be meter (i.e. things with a duration and/or a<br>
volume), you can write some Ceilometer notification plugin building a<br>
bunch of meter from what you get. Multi-publisher can also help you<br>
building more advanced counter through the use of transformer if you<br>
wish.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Julien Danjou<br>
;; Free Software hacker & freelance<br>
;; <a href="http://julien.danjou.info" target="_blank">http://julien.danjou.info</a><br>
</font></span><br>_______________________________________________<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>
<br></blockquote></div><br>