Hi Alexandre, I wanted to let this discussion develop a little before jumping in, as we've already had many circular debates about the cross-over between ceilometer and monitoring infrastructure in general.
Personally I'm in favor of the "big tent/broad church" interpretation of ceilometer's project mandate, and would welcome further development of our capabilities in this area (whether directly within the ceilometer code-tree itself, or within a parallel repo aligned with the Telemetry program). In terms of furthering the discussion, unfortunately you've missed the boat in terms of securing a slot in the design summit next week in Atlanta (proposal deadline was April 20th, and the scheduling has all been finalized at this stage). However, we do have a project pod space available for ad-hoc overflow sessions. I would suggest that we organize something on this theme after the main ceilometer track[1] has completed, say on the Thursday or Friday. Please reach out on IRC to discuss availability for this and we'll work out something around remote participation. Thanks, Eoghan [1] http://junodesignsummit.sched.org/overview/type/ceilometer ----- Original Message ----- > 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 > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
