Re: [Openstack-operators] Leveraging Gnocchi in Mitaka

2017-06-27 Thread Tracy Comstock Roesler 
No worries, it makes me feel better to know I’m not doing something wrong.

Thanks for all the assistance.

On 6/27/17, 6:54 AM, "gordon chung"  wrote:

>
>
>On 26/06/17 06:07 PM, Tracy Comstock Roesler wrote:
>> If I understand what you¹re saying, you think I can try
>> direct://?publisher=gnocchi in the pipeline.yaml on the controller
>>nodes,
>> but not the compute nodes to bypass the collector?
>
>sorry, i just looked at the code again, it was only implemented in
>ceilometer newton:
>https://github.com/openstack/ceilometer/blob/stable/newton/ceilometer/publ
>isher/direct.py#L35-L37
>
>i imagine you could just backport that to mitaka if you wanted. here's
>the patch for reference:
>https://github.com/openstack/ceilometer/commit/8ed2e7735ec3f17881008a2ffe2
>fd2dc8ac1db7e
>
>apologies for the false hope.
>
>
>-- 
>gord
>

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Leveraging Gnocchi in Mitaka

2017-06-27 Thread gordon chung 


On 26/06/17 06:07 PM, Tracy Comstock Roesler wrote:
> If I understand what you¹re saying, you think I can try
> direct://?publisher=gnocchi in the pipeline.yaml on the controller nodes,
> but not the compute nodes to bypass the collector?

sorry, i just looked at the code again, it was only implemented in 
ceilometer newton: 
https://github.com/openstack/ceilometer/blob/stable/newton/ceilometer/publisher/direct.py#L35-L37

i imagine you could just backport that to mitaka if you wanted. here's 
the patch for reference: 
https://github.com/openstack/ceilometer/commit/8ed2e7735ec3f17881008a2ffe2fd2dc8ac1db7e

apologies for the false hope.


-- 
gord

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Leveraging Gnocchi in Mitaka

2017-06-26 Thread Tracy Comstock Roesler 
Hi Gordon,

If I understand what you¹re saying, you think I can try
direct://?publisher=gnocchi in the pipeline.yaml on the controller nodes,
but not the compute nodes to bypass the collector?

When I attempted to do so I received an error (full stack trace ommitted):

2017-06-26 14:52:51.625 41444 ERROR ceilometer.pipeline
[req-e8ac0e01-32f1-4df0-979d-185cd445c7d
5 - - - - -] Pipeline cpu_sink: Continue after error from publisher



...

2017-06-26 14:52:51.625 41444 ERROR ceilometer.pipeline ProgrammingError:
(pymysql.err.Programmi
ngError) (1146, u"Table 'ceilometer.meter' doesn't exist") [SQL: u'SELECT
meter.id \nFROM meter
\nWHERE meter.name = %(name_1)s AND meter.type = %(type_1)s AND meter.unit
= %(unit_1)s'] [param
eters: {u'type_1': 'gauge', u'name_1': 'cpu_util', u'unit_1': '%'}]
2017-06-26 14:52:51.625 41444 ERROR ceilometer.pipeline



It looks like it¹s attempting to pull something from the mysql table for
ceilometer, which we don¹t have tables for.

On 6/26/17, 6:47 AM, "gordon chung"  wrote:

>
>
>On 24/06/17 10:49 PM, Mike Smith wrote:
>> We use ceilometer-compute and we would like to have it push metrics
>>directly to Gnocchi, bypassing the rabbit queues that ceilometer uses in
>>the default Mitaka configuration.  Currently our ceilometer-compute
>>pushes to the notification queue, which gets consumed by a ceilometer
>>process and put into the metrics queue, which in turn gets consumed and
>>pushed to gnocchi by the another ceilometer process.
>>
>> We have tried to set the Œpublisher¹ in the ceilometer pipeline.yaml
>>file to gnocchi:// instead of notifier://, but it doesn¹t seem to do
>>anything.  No errors or anything, it just doesn¹t seem to try and send
>>metrics to the configured gnocchi endpoint.
>>
>> We are running RDO and have openstack-ceilometer-compute-6.1.3-2.el7.
>>We¹re curious if a different version of openstack-ceilometer-compute is
>>required in order to send metrics directly to gnocchi
>
>changing publiser to gnocchi:// won't work in mitaka. this was only done
>in Ocata i believe. you'd have to backport[1] if you want to use
>gnocchi:// directly. alternatively, you can put direct:// and it should
>allow you to avoid collector service.
>
>that said, you cannot push directly from polling agents -- not without
>some hacking. all the pipeline work is handled by notification agent. if
>you don't need any transformations than it's possible to skip
>notification agent but this requires hacking your code as we do not
>support this. i imagine this would be a welcomed addition, we just don't
>have resources to implement it.
>
>[1] 
>https://github.com/openstack/ceilometer/commit/f843b7882fb806cf564c5b3106f
>601815a48c93b
>
>
>-- 
>gord
>
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Leveraging Gnocchi in Mitaka

2017-06-26 Thread gordon chung 


On 24/06/17 10:49 PM, Mike Smith wrote:
> We use ceilometer-compute and we would like to have it push metrics directly 
> to Gnocchi, bypassing the rabbit queues that ceilometer uses in the default 
> Mitaka configuration.  Currently our ceilometer-compute pushes to the 
> notification queue, which gets consumed by a ceilometer process and put into 
> the metrics queue, which in turn gets consumed and pushed to gnocchi by the 
> another ceilometer process.
>
> We have tried to set the ‘publisher’ in the ceilometer pipeline.yaml file to 
> gnocchi:// instead of notifier://, but it doesn’t seem to do anything.  No 
> errors or anything, it just doesn’t seem to try and send metrics to the 
> configured gnocchi endpoint.
>
> We are running RDO and have openstack-ceilometer-compute-6.1.3-2.el7.   We’re 
> curious if a different version of openstack-ceilometer-compute is required in 
> order to send metrics directly to gnocchi

changing publiser to gnocchi:// won't work in mitaka. this was only done 
in Ocata i believe. you'd have to backport[1] if you want to use 
gnocchi:// directly. alternatively, you can put direct:// and it should 
allow you to avoid collector service.

that said, you cannot push directly from polling agents -- not without 
some hacking. all the pipeline work is handled by notification agent. if 
you don't need any transformations than it's possible to skip 
notification agent but this requires hacking your code as we do not 
support this. i imagine this would be a welcomed addition, we just don't 
have resources to implement it.

[1] 
https://github.com/openstack/ceilometer/commit/f843b7882fb806cf564c5b3106f601815a48c93b


-- 
gord

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Leveraging Gnocchi in Mitaka

2017-06-24 Thread Mike Smith 
Thanks for the response Gordon.  I work together with Tracy and can add a 
couple of things:

We use ceilometer-compute and we would like to have it push metrics directly to 
Gnocchi, bypassing the rabbit queues that ceilometer uses in the default Mitaka 
configuration.  Currently our ceilometer-compute pushes to the notification 
queue, which gets consumed by a ceilometer process and put into the metrics 
queue, which in turn gets consumed and pushed to gnocchi by the another 
ceilometer process.  

We have tried to set the ‘publisher’ in the ceilometer pipeline.yaml file to 
gnocchi:// instead of notifier://, but it doesn’t seem to do anything.  No 
errors or anything, it just doesn’t seem to try and send metrics to the 
configured gnocchi endpoint.  

We are running RDO and have openstack-ceilometer-compute-6.1.3-2.el7.   We’re 
curious if a different version of openstack-ceilometer-compute is required in 
order to send metrics directly to gnocchi.

Mike


> On Jun 23, 2017, at 2:07 PM, gordon chung  wrote:
> 
> 
> 
> On 23/06/17 02:50 PM, Tracy Comstock Roesler wrote:
>> We’ve been using gnocchi in mitaka for a few months now but we’ve run
>> into some issues with performance, predominantly because of the number
>> of data points sent along rabbitmq.
> 
> i'm not sure what rabbitmq has to do with gnocchi since gnocchi itself 
> does not utilise rabbitmq? you mean ceilometer? here? which queues are 
> growing in rabbitmq?
> 
>> 
>> We’ve tried to bypass rabbit, but  configuring our pipeline.yaml to push
>> to 'gnocchi://' hasn’t failed.  Do you think we’d have better luck with
>> 'direct://', or is it just not possible?
>> 
> 
> what is your error? gnocchi:// is just an alias for direct:// publisher 
> so it won't change much.
> 
>> I’ve also seen emails about potentially updating/backporting the
>> dispatcher code while using a gnocchi 2.1 installation.  Is this a safe
>> method?  I’m guessing by upgrading the dispatching code, I can resolve
>> the problem of having to publish our stuff to rabbit.
>> 
> 
> is it safe? i'm not sure if backporting newer ceilometer code will work 
> with gnocchiv2.1. that said, i don't recommend you use gnocchiv2.1 as i 
> would say only starting in gnocchiv3 is it actually usable (my personal 
> opinion). if you backport newer dispatcher but use gnocchiv3+ or 
> gnocchiv4, it should work but you should probably understand the code 
> before doing so.
> 
>> 
>> I’m trying to resolve a backlog issue we’re having because we leverage
>> gnocchi and metricd for canary instances as elastic scaling of nodes.
>> 
> 
> backlog in gnocchi? if you mean when you run 'gnocchi status', the 
> values never stop growing, then i would say 1) only gnocchiv3+ is usable 
> 2) add more metricd workers 3) gnocchiv4 is better than gnocchiv3.
> 
> cheers,
> 
> -- 
> gord
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Leveraging Gnocchi in Mitaka

2017-06-23 Thread gordon chung 


On 23/06/17 02:50 PM, Tracy Comstock Roesler wrote:
> We’ve been using gnocchi in mitaka for a few months now but we’ve run
> into some issues with performance, predominantly because of the number
> of data points sent along rabbitmq.

i'm not sure what rabbitmq has to do with gnocchi since gnocchi itself 
does not utilise rabbitmq? you mean ceilometer? here? which queues are 
growing in rabbitmq?

>
> We’ve tried to bypass rabbit, but  configuring our pipeline.yaml to push
> to 'gnocchi://' hasn’t failed.  Do you think we’d have better luck with
> 'direct://', or is it just not possible?
>

what is your error? gnocchi:// is just an alias for direct:// publisher 
so it won't change much.

> I’ve also seen emails about potentially updating/backporting the
> dispatcher code while using a gnocchi 2.1 installation.  Is this a safe
> method?  I’m guessing by upgrading the dispatching code, I can resolve
> the problem of having to publish our stuff to rabbit.
>

is it safe? i'm not sure if backporting newer ceilometer code will work 
with gnocchiv2.1. that said, i don't recommend you use gnocchiv2.1 as i 
would say only starting in gnocchiv3 is it actually usable (my personal 
opinion). if you backport newer dispatcher but use gnocchiv3+ or 
gnocchiv4, it should work but you should probably understand the code 
before doing so.

>
> I’m trying to resolve a backlog issue we’re having because we leverage
> gnocchi and metricd for canary instances as elastic scaling of nodes.
>

backlog in gnocchi? if you mean when you run 'gnocchi status', the 
values never stop growing, then i would say 1) only gnocchiv3+ is usable 
2) add more metricd workers 3) gnocchiv4 is better than gnocchiv3.

cheers,

-- 
gord
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators