Open Stack

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
<https://launchpad.net/%7Eopenstack> 
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
<https://launchpad.net/%7Eopenstack> 
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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120406/6cb127b8/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5201 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120406/6cb127b8/attachment-0002.bin>