[Openstack] [Ops] OpenStack and Operations: Input from the Wild

Huang Zhiteng winston.d at gmail.com
Mon Apr 9 03:41:41 UTC 2012


Hi Tim,

Could you elaborate more on 'performance metrics'?  Like what kind of
metrics are considered as performance ones?  Thanks.

On Sat, Apr 7, 2012 at 2:13 AM, Tim Bell <Tim.Bell at cern.ch> wrote:

> ** **
>
> Splitting monitoring into****
>
> ** **
>
> **1.       **Gathering of metrics (availability, performance) and
> reporting in a standard fashion should be part of OpenStack. ****
>
> **2.       **Best practice sensors should sample the metrics and provide
> alarms for issues which could cause service impacts. Posting of these
> alarms to a monitoring system should be based on plug ins****
>
> **3.       **Reference implementations for standard monitoring systems
> such as Nagios should be available that queries the data above and feeds it
> into the package selected****
>
> ** **
>
> Each site does not want to be involved in defining the best practice.
> Equally, each monitoring system should not have to have an intimate
> understanding of OpenStack to produce a red/green light.  The components
> for 1 and 2 fall under the associated openstack component. Component 3 is
> the monitoring solution provider.****
>
> ** **
>
> Tim****
>
> ** **
>
> *From:* openstack-bounces+tim.bell=cern.ch at lists.launchpad.net [mailto:
> openstack-bounces+tim.bell=cern.ch at lists.launchpad.net] *On Behalf Of *David
> Kranz
> *Sent:* 06 April 2012 16:44
> *To:* Andrew Clay Shafer
> *Cc:* openstack-operators at lists.openstack.org; openstack; Duncan McGreggor
> *Subject:* Re: [Openstack] [Ops] OpenStack and Operations: Input from the
> Wild****
>
> ** **
>
> This is a really great list! With regard to cluster health and monitoring,
> I did a bunch of stuff with Swift before turning to nova and really
> appreciated the
> way each swift service has a "healthcheck" call that can be used by a
> monitoring system. While I don't think providing a production-ready
> monitoring system should be part of core OpenStack, it is the core
> architects who really know what needs to be checked to ensure that a system
> is healthy. There are various sets of poking at ports, process lists and so
> on that Crowbar, Zenoss, etc. set up but it would be a big improvement for
> deployers if each openstack service provided healthcheck apis based on
> expert knowledge of what is supposed to be happening inside. That would
> also insulate deployers from changes in the code that might impact what it
> means to be running properly. Looking forward to the discussion.
>
>  -David
>
>
>
> On 4/6/2012 1:06 AM, Andrew Clay Shafer wrote: ****
>
> Interested in devops.****
>
> ** **
>
> Off the top of my head.****
>
> ** **
>
> live upgrades****
>
> api queryable indications of cluster health****
>
> api queryable cluster version and configuration info****
>
> enabling monitoring as a first class concern in OpenStack (either as a
> cross cutting concern, or as it's own project)****
>
> a framework for gathering and sharing performance benchmarks with
> architecture and configuration****
>
> ** **
>
> ** **
>
> On Thu, Apr 5, 2012 at 1:52 PM, Duncan McGreggor <duncan at dreamhost.com>
> wrote:****
>
> For anyone interested in DevOps, Ops, cloud hosting management, etc.,
> there's a proposed session we could use your feedback on for topics of
> discussion:
>  http://summit.openstack.org/sessions/view/57
>
> Respond with your thoughts and ideas, and I'll be sure to add them to the
> list.
>
> Thanks!
>
> d
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp****
>
>
>
>
>
> ****
>
> _______________________________________________****
>
> Mailing list: https://launchpad.net/~openstack****
>
> Post to     : openstack at lists.launchpad.net****
>
> Unsubscribe : https://launchpad.net/~openstack****
>
> More help   : https://help.launchpad.net/ListHelp****
>
> ** **
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Regards
Huang Zhiteng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120409/a8324226/attachment.html>


More information about the Openstack mailing list