Re: [Openstack-operators] Leveraging Gnocchi in Mitaka
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
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
[Openstack-operators] Leveraging Gnocchi in Mitaka
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. 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? 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. >yes, you can use gnocchi v2 with mitaka. you should have >gnocchiclient<3.0.0 for it to work. >truthfully, you should try to backport the dispatcher code from a newer >version as the newer gnocchi releases are still compatible with older >ceilometer versions (it just has different integration code). i'm not >sure gnocchi v2 is performant and you'll avoid the upgrade between >gnocchi v2->v3 which is required for newton. >people have had success backporting code found here: >https://github.com/openstack/ceilometer/tree/stable/ocata/ceilometer/dispatcher 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. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [gnocchi] Gnocchi, keystone, and Openstack Mitaka
I just saw this email, apologize for the delay. I installed the openstack
version, rather than the version in pip:
[r...@openstack-controller01.a.pc.ostk.com ~] # rpm -qa | grep
python-gnocchi
python-gnocchiclient-2.2.0-1.el7.noarch
python-gnocchi-2.1.4-1.el7.noarch
r...@openstack-controller01.a.pc.ostk.com ~] # rpm -qa | grep oslo-policy
python2-oslo-policy-1.6.0-1.el7.noarch
On 2/27/17, 1:17 PM, "gordon chung" wrote:
>can you add what version of gnocchi, gnocchiclient and oslo.policy you
>have? might be easier if open a bug[1]. i don't see anything wrong at
>first glance and i don't recall there being a similar issue in past.
>
>[1] https://bugs.launchpad.net/gnocchi
>
>On 23/02/17 11:54 AM, Tracy Comstock Roesler wrote:
>> I¹ve run into a problem with the gnocchi CLI. Whenever I run Œgnocchi
>> status¹ I get a 403 Forbidden, but I can run other commands like
>> 'gnocchi resource create¹ no problem.
>>
>> I¹ve checked the policy.json and it looks like ³admin² has rights to get
>> status, the same as create resources. I cannot figure out why get
>> status would show a 403 forbidden, but I can run other commands just
>>fine.
>>
>> [root ~] # gnocchi status --debug
>> REQ: curl -g -i -X GET http://keystone:35357/v3 -H "Accept:
>> application/json" -H "User-Agent: keystoneauth1/2.4.1
>> python-requests/2.10.0 CPython/2.7.5"
>> Starting new HTTP connection (1): keystone
>> "GET /v3 HTTP/1.1" 200 277
>> RESP: [200] Content-Type: application/json Content-Length: 277
>> Connection: keep-alive Date: Thu, 23 Feb 2017 16:52:40 GMT Server:
>> Apache/2.4.6 (CentOS) mod_wsgi/3.4 Python/2.7.5 Vary: X-Auth-Token
>> x-openstack-request-id: req-189a8db8-6210-4735-bc66-b2dc90b00a38
>> RESP BODY: {"version": {"status": "stable", "updated":
>> "2016-04-04T00:00:00Z", "media-types": [{"base": "application/json",
>> "type": "application/vnd.openstack.identity-v3+json"}], "id": "v3.6",
>> "links": [{"href": "http://keystone:35357/v3/";, "rel": "self"}]}}
>>
>> Making authentication request to http://keystone:35357/v3/auth/tokens
>> "POST /v3/auth/tokens HTTP/1.1" 201 3874
>> REQ: curl -g -i -X GET http://gnocchi:8041/v1/status -H "User-Agent:
>> keystoneauth1/2.4.1 python-requests/2.10.0 CPython/2.7.5" -H "Accept:
>> application/json, */*" -H "X-Auth-Token: {SHA1}AAA"
>> Starting new HTTP connection (1): gnocchi
>> "GET /v1/status HTTP/1.1" 403 54
>> RESP: [403] Content-Type: application/json; charset=UTF-8
>> Content-Length: 54 Connection: keep-alive Server: Werkzeug/0.9.1
>> Python/2.7.5 Date: Thu, 23 Feb 2017 16:52:40 GMT
>> RESP BODY: {"code": 403, "description": "", "title": "Forbidden"}
>>
>> Forbidden (HTTP 403)
>> Traceback (most recent call last):
>> File "/usr/lib/python2.7/site-packages/cliff/app.py", line 346, in
>> run_subcommand
>> result = cmd.run(parsed_args)
>> File "/usr/lib/python2.7/site-packages/cliff/display.py", line 79, in
>>run
>> column_names, data = self.take_action(parsed_args)
>> File
>> "/usr/lib/python2.7/site-packages/gnocchiclient/v1/status_cli.py", line
>> 21, in take_action
>> status = self.app.client.status.get()
>> File "/usr/lib/python2.7/site-packages/gnocchiclient/v1/status.py",
>> line 21, in get
>> return self._get(self.url).json()
>> File "/usr/lib/python2.7/site-packages/gnocchiclient/v1/base.py", line
>> 37, in _get
>> return self.client.api.get(*args, **kwargs)
>> File "/usr/lib/python2.7/site-packages/keystoneauth1/adapter.py", line
>> 173, in get
>> return self.request(url, 'GET', **kwargs)
>> File "/usr/lib/python2.7/site-packages/gnocchiclient/client.py", line
>> 38, in request
>> raise exceptions.from_response(resp, method)
>> Forbidden: Forbidden (HTTP 403)
>> Traceback (most recent call last):
>> File "/usr/bin/gnocchi", line 10, in
>> sys.exit(main())
>> File "/usr/lib/python2.7/site-packages/gnocchiclient/shell.py", line
>> 211, in main
>> return GnocchiShell().run(args)
>> File "/usr/lib/python2.7/site-packages/cliff/app.py", line 226, in run
>> result = self.run_subcommand(remainder)
>> File "/usr/lib/python2.7/site-packages/
[Openstack-operators] Gnocchi, keystone, and Openstack Mitaka
I’ve run into a problem with the gnocchi CLI. Whenever I run ‘gnocchi status’
I get a 403 Forbidden, but I can run other commands like 'gnocchi resource
create’ no problem.
I’ve checked the policy.json and it looks like “admin” has rights to get
status, the same as create resources. I cannot figure out why get status would
show a 403 forbidden, but I can run other commands just fine.
[root ~] # gnocchi status --debug
REQ: curl -g -i -X GET http://keystone:35357/v3 -H "Accept: application/json"
-H "User-Agent: keystoneauth1/2.4.1 python-requests/2.10.0 CPython/2.7.5"
Starting new HTTP connection (1): keystone
"GET /v3 HTTP/1.1" 200 277
RESP: [200] Content-Type: application/json Content-Length: 277 Connection:
keep-alive Date: Thu, 23 Feb 2017 16:52:40 GMT Server: Apache/2.4.6 (CentOS)
mod_wsgi/3.4 Python/2.7.5 Vary: X-Auth-Token x-openstack-request-id:
req-189a8db8-6210-4735-bc66-b2dc90b00a38
RESP BODY: {"version": {"status": "stable", "updated": "2016-04-04T00:00:00Z",
"media-types": [{"base": "application/json", "type":
"application/vnd.openstack.identity-v3+json"}], "id": "v3.6", "links":
[{"href": "http://keystone:35357/v3/";, "rel": "self"}]}}
Making authentication request to http://keystone:35357/v3/auth/tokens
"POST /v3/auth/tokens HTTP/1.1" 201 3874
REQ: curl -g -i -X GET http://gnocchi:8041/v1/status -H "User-Agent:
keystoneauth1/2.4.1 python-requests/2.10.0 CPython/2.7.5" -H "Accept:
application/json, */*" -H "X-Auth-Token: {SHA1}AAA"
Starting new HTTP connection (1): gnocchi
"GET /v1/status HTTP/1.1" 403 54
RESP: [403] Content-Type: application/json; charset=UTF-8 Content-Length: 54
Connection: keep-alive Server: Werkzeug/0.9.1 Python/2.7.5 Date: Thu, 23 Feb
2017 16:52:40 GMT
RESP BODY: {"code": 403, "description": "", "title": "Forbidden"}
Forbidden (HTTP 403)
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/cliff/app.py", line 346, in
run_subcommand
result = cmd.run(parsed_args)
File "/usr/lib/python2.7/site-packages/cliff/display.py", line 79, in run
column_names, data = self.take_action(parsed_args)
File "/usr/lib/python2.7/site-packages/gnocchiclient/v1/status_cli.py", line
21, in take_action
status = self.app.client.status.get()
File "/usr/lib/python2.7/site-packages/gnocchiclient/v1/status.py", line 21,
in get
return self._get(self.url).json()
File "/usr/lib/python2.7/site-packages/gnocchiclient/v1/base.py", line 37, in
_get
return self.client.api.get(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/keystoneauth1/adapter.py", line 173,
in get
return self.request(url, 'GET', **kwargs)
File "/usr/lib/python2.7/site-packages/gnocchiclient/client.py", line 38, in
request
raise exceptions.from_response(resp, method)
Forbidden: Forbidden (HTTP 403)
Traceback (most recent call last):
File "/usr/bin/gnocchi", line 10, in
sys.exit(main())
File "/usr/lib/python2.7/site-packages/gnocchiclient/shell.py", line 211, in
main
return GnocchiShell().run(args)
File "/usr/lib/python2.7/site-packages/cliff/app.py", line 226, in run
result = self.run_subcommand(remainder)
File "/usr/lib/python2.7/site-packages/cliff/app.py", line 346, in
run_subcommand
result = cmd.run(parsed_args)
File "/usr/lib/python2.7/site-packages/cliff/display.py", line 79, in run
column_names, data = self.take_action(parsed_args)
File "/usr/lib/python2.7/site-packages/gnocchiclient/v1/status_cli.py", line
21, in take_action
status = self.app.client.status.get()
File "/usr/lib/python2.7/site-packages/gnocchiclient/v1/status.py", line 21,
in get
return self._get(self.url).json()
File "/usr/lib/python2.7/site-packages/gnocchiclient/v1/base.py", line 37, in
_get
return self.client.api.get(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/keystoneauth1/adapter.py", line 173,
in get
return self.request(url, 'GET', **kwargs)
File "/usr/lib/python2.7/site-packages/gnocchiclient/client.py", line 38, in
request
raise exceptions.from_response(resp, method)
gnocchiclient.exceptions.Forbidden: Forbidden (HTTP 403)
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
