Open Stack

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.viau at 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" <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
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev