Thanks to everyone for the feedback. I agree that this falls under the Telemetry Program and I have moved the blueprint.
You can find it here: https://blueprints.launchpad.net/ceilometer/+spec/monitoring-as-a-service Wiki page: https://wiki.openstack.org/wiki/MaaS Etherpad: https://etherpad.openstack.org/p/MaaS > 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. Roland, I currently have no plans to be at the Summit next week. However, I would be interested in exploring what you have already done and learn from it. Maybe we can schedule a meeting? You can always contact me on IRC (aviau) or by e-mail at alexandre.v...@savoirfairelinux.com For now, I think we should focus on the use cases. I invite all of you to help us list them on the Etherpad. Alexandre On 14-05-05 12:00 PM, Hochmuth, Roland M wrote: > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
