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" <m...@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 <dmako...@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 <z...@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.v...@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@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
