Open Stack

Hi, Steve.

All metrics in Synaps only can be pushed via API. Agents should know their credentials to make signature for every API call by AWS Signature v2 [1]. To do that, the credentials should be deployed inside the instance. Synaps still has the problem that you are pointed out. I hope that we could find out a better way for this.

[1] http://docs.amazonwebservices.com/general/latest/gr/signature-version-2.html

Thank you,
June Yi


------- Original Message -------
Sender : Steven Hardy<shardy at redhat.com> 
Date   : 2012-10-11 16:49 (GMT+09:00)
Title  : Re: [openstack-dev] Introducing Synaps project that provides AWS
 CloudWatch compatible API

On Thu, Oct 11, 2012 at 05:53:32AM +0000, Deok-June Yi wrote:
> Hi Sam,
> 
> > Maybe it's related to this in the wiki: http://wiki.openstack.org/ResourceMonitorAlertsandNotifications and related BP: https://blueprints.launchpad.net/openstack-devops/+spec/resource-monitor-alerts-and-notifications 
> > 
> > Not sure if anybody started working on that. Hope it helps.
> >
> 
> I thought that it would be better to implement another seperated project rather than inside of Nova.
> 
> Hi Doug,
> 
> > Ceilometer collects data for use by a billing system, but it is not itself a billing system. It sounds like Synaps collects metrics far more frequently than ceilometer does.
> > 
> > Can you share a list of the things Synaps measures?
> >
> 
> Thank you for your corrections, Doug. 
> 
> Synaps can collect any metric if its value can be represented in double type just like AWS CloudWatch can. 
> 
> - Currently we have Synaps agent so called VMMON that gets following metrics, CPUUtilization, DiskReadOps, DiskWriteOps, DiskReadBytes, DiskWriteBytes, NetworkIn and NetworkOut from hypervisors and send them to Synaps.
> - If you have cloud service such as LBaaS or DBaaS, you can provide their metrics to your users easily by implementing an agent using Synaps API.
> - Users can also put their own custom metrics from in-instance.

Can you please provide more details on how your in-instance monitoring
works?

I assume you have an in instance agent (similar to cfn-push-stats?), which
pushes metrics via your cloudwatch API?

Or is it pushing data directly to your data-collection "engine"?

In either case, how do you handle authentication to ensure data collected
from inside the instances cannot be faked, and also to limit the scope for
attack should a single instance be compromised?

I am currently working on this problem for the heat project, and we are
figuring out how to get our cfn-push-stats to (securely) send data via our
cloudwatch API - a big problem is ensuring whatever credentials are deployed
inside the instance to authenticate with the API are sufficiently
unprivileged/separated to contain damage from any potential instance
compromise.

-- 
Steve Hardy
Red Hat Engineering, Cloud