Open Stack

Alexandre, Great timing on this question and I agree with your proposal. I
work for HP and we are just about to open-source a project for Monitoring
as a Service (MaaS), called "Jahmon". Jahmon is based on our
customer-facing monitoring as a service solution and internal monitoring
projects.


Jahmon is a multi-tenant, highly performant, scalable, reliable and
fault-tolerant monitoring solution that scales to service provider levels
of metrics throughput. It has a RESTful API that is used for
storing/querying metrics, creating compound alarms, querying alarm
state/history, sending notifications and more.

I can go over the project with you as well as others that are interested.
We would like to start working with other open-source developers. I'll
also be at the Summit next week.

Regards --Roland


On 5/4/14, 1:37 PM, "John Dickinson" <me at not.mn> wrote:

>One of the advantages of the program concept within OpenStack is that
>separate code projects with complementary goals can be managed under the
>same program without needing to be the same codebase. The most obvious
>example across every program are the "server" and "client" projects under
>most programs.
>
>This may be something that can be used here, if it doesn't make sense to
>extend the ceilometer codebase itself.
>
>--John
>
>
>
>
>
>On May 4, 2014, at 12:30 PM, Denis Makogon <dmakogon at mirantis.com> wrote:
>
>> Hello to All.
>> 
>> I also +1 this idea. As I can see, Telemetry program (according to
>>Launchpad) covers the process of the infrastructure metrics (networking,
>>etc) and in-compute-instances metrics/monitoring.
>> So, the best option, I guess, is to propose add such great feature to
>>Ceilometer. In-compute-instance monitoring will be the great value-add
>>to upstream Ceilometer.
>> As for me, it's a good chance to integrate well-known production ready
>>monitoring systems that have tons of specific plugins (like Nagios etc.)
>> 
>> Best regards,
>> Denis Makogon
>> 
>> воскресенье, 4 мая 2014 г. пользователь John Griffith написал:
>> 
>> 
>> 
>> On Sun, May 4, 2014 at 9:37 AM, Thomas Goirand <zigo at debian.org> wrote:
>> On 05/02/2014 05:17 AM, Alexandre Viau wrote:
>> > Hello Everyone!
>> >
>> > My name is Alexandre Viau from Savoir-Faire Linux.
>> >
>> > We have submited a Monitoring as a Service blueprint and need
>>feedback.
>> >
>> > Problem to solve: Ceilometer's purpose is to track and
>>*measure/meter* usage information collected from OpenStack components
>>(originally for billing). While Ceilometer is usefull for the cloud
>>operators and infrastructure metering, it is not a *monitoring* solution
>>for the tenants and their services/applications running in the cloud
>>because it does not allow for service/application-level monitoring and
>>it ignores detailed and precise guest system metrics.
>> >
>> > Proposed solution: We would like to add Monitoring as a Service to
>>Openstack
>> >
>> > Just like Rackspace's Cloud monitoring, the new monitoring service -
>>lets call it OpenStackMonitor for now -  would let users/tenants keep
>>track of their ressources on the cloud and receive instant notifications
>>when they require attention.
>> >
>> > This RESTful API would enable users to create multiple monitors with
>>predefined checks, such as PING, CPU usage, HTTPS and SMTP or custom
>>checks performed by a Monitoring Agent on the instance they want to
>>monitor.
>> >
>> > Predefined checks such as CPU and disk usage could be polled from
>>Ceilometer. Other predefined checks would be performed by the new
>>monitoring service itself. Checks such as PING could be flagged to be
>>performed from multiple sites.
>> >
>> > Custom checks would be performed by an optional Monitoring Agent.
>>Their results would be polled by the monitoring service and stored in
>>Ceilometer.
>> >
>> > If you wish to collaborate, feel free to contact me at
>>alexandre.viau at savoirfairelinux.com
>> > The blueprint is available here:
>>https://blueprints.launchpad.net/openstack-ci/+spec/monitoring-as-a-servi
>>ce
>> >
>> > Thanks!
>> 
>> I would prefer if monitoring capabilities was added to Ceilometer rather
>> than adding yet-another project to deal with.
>> 
>> What's the reason for not adding the feature to Ceilometer directly?
>> 
>> Thomas
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> ​I'd also be interested in the overlap between your proposal and
>>Ceilometer.  It seems at first thought that it would be better to
>>introduce the monitoring functionality in to Ceilometer and make that
>>project more diverse as opposed to yet another project.​
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>