Re: [openstack-dev] [Ceilometer] Unable to add new metrics using meters.yaml
Thanks Gord Yes, for my quick test, I directly added a new exchange to listen for in meter/notifications.py and verified that the custom metrics are getting processed after that. Thanks Srikanth -Original Message- From: gordon chung [mailto:g...@live.ca] Sent: Monday, January 16, 2017 6:09 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Ceilometer] Unable to add new metrics using meters.yaml On 13/01/17 06:47 PM, Srikanth Vavilapalli wrote: > So the question is, is there any config that I can use to let > "ceilometer/meter/notifications.py" listen on other rabbitmq exchanges in > addition to predefined ones, such that this framework can be extended to > receive meters from non openstack services? Appreciate your inputs. sorry, hit send to quickly. you could also hack the code to support your exchange[1]. i also believe in theory, you should be able to re-use http_control_exchanges to leverage your custom exchanges[2] [1] https://github.com/openstack/ceilometer/blob/aa3f491bb714c613681125d242e4c9ea254bdbe2/ceilometer/meter/notifications.py#L210 [2] https://github.com/openstack/ceilometer/blob/34a699a598122f2f1f44e5f169ee21d6c22665d0/ceilometer/middleware.py#L30 cheers, -- gord __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Unable to add new metrics using meters.yaml
Hi Yurii Thanks for your inputs. Yes, I have noticed that statement in the guide and enabled disable_non_metric_meters in my conf file, but that didn't change the behavior. If you notice, that condition is only applicable for "meters that have a volume as 1". But in my case, the meter that I have defined is of type metric with a proper value for volume. I think I have found the issue why my meters are not processed by notification agents. If I look at the ceilometer generic meter notification listener module (ceilometer/meter/notifications.py), it listens for all the meters as defined in meters.yaml in the "notifications.info" topic at pre-defined rabbitmq exchanges as defined in ceilometer/exchange_control.py file. But in my case, my service is publishing its meters to "notifications.info" topic at a different exchange name. That means I need to make a change to ceilometer/meter/notifications.py to listen on some default rabbitmq exchange for all non openstack services to publish their telemetry data. So the question is, is there any config that I can use to let "ceilometer/meter/notifications.py" listen on other rabbitmq exchanges in addition to predefined ones, such that this framework can be extended to receive meters from non openstack services? Appreciate your inputs. Thanks Srikanth -Original Message- From: Yurii Prokulevych [mailto:yprok...@redhat.com] Sent: Thursday, January 12, 2017 12:34 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ceilometer] Unable to add new metrics using meters.yaml Hi Srikanth, As U've noticed those meters are derived from notifications emitted by other OpenStack services. So please check that 'cord.dns.cache.size' events are processed correctly. Also, the last sentences from the guide: ''' These meters are not loaded by default. To load these meters, flip the `disable_non_metric_meters` option in the ceilometer.conf file ''' Do U have this enabled ? --- Regards, Yurii On Thu, 2017-01-12 at 02:01 +, Srikanth Vavilapalli wrote: > Hi > > I was following the instructions @ http://docs.openstack.org/admin-gu > ide/telemetry-data-collection.html#meter-definitions to add new meters > to Ceilometer, but not able to make it work. > > I verified meters.yaml file in meter/data folder: > > ubuntu@mysite-ceilometer-3:/usr/lib/python2.7/dist- > packages/ceilometer/meter/data$ ls > meters.yaml > > > I add the following new meter to the end of that file: > > - name: $.payload.name > event_type: 'cord.dns.cache.size' > type: 'gauge' > unit: 'entries' > volume: $.payload.cache_size > user_id: $.payload.user_id > project_id: $.payload.project_id > resource_id: '"cord-" + $.payload.base_id' > > When I inject 'cord.dns.cache.size' metric from a sample publisher to > rabbitmq server (@ exchange 'openstack') on which the ceilometer > notification agents are listening, I don't see these metrics appearing > in 'ceilometer meter-list' output. Can any one plz let me know if I > missing any config or change that prevents custom meter processing in > Ceilometer? > > Appreciate ur inputs. > > Thanks > Srikanth > > _ > _ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] Unable to add new metrics using meters.yaml
Hi I was following the instructions @ http://docs.openstack.org/admin-guide/telemetry-data-collection.html#meter-definitions to add new meters to Ceilometer, but not able to make it work. I verified meters.yaml file in meter/data folder: ubuntu@mysite-ceilometer-3:/usr/lib/python2.7/dist-packages/ceilometer/meter/data$ ls meters.yaml I add the following new meter to the end of that file: - name: $.payload.name event_type: 'cord.dns.cache.size' type: 'gauge' unit: 'entries' volume: $.payload.cache_size user_id: $.payload.user_id project_id: $.payload.project_id resource_id: '"cord-" + $.payload.base_id' When I inject 'cord.dns.cache.size' metric from a sample publisher to rabbitmq server (@ exchange 'openstack') on which the ceilometer notification agents are listening, I don't see these metrics appearing in 'ceilometer meter-list' output. Can any one plz let me know if I missing any config or change that prevents custom meter processing in Ceilometer? Appreciate ur inputs. Thanks Srikanth __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Scale deployment
Thanks Gordon for your inputs, Quick follow-up question: I see few new alternatives existing in place of ceilometer mongo storage: Gnocchi and Panko. Are these recommended data storage options from now on for Ceilometer? Also, I suppose Gnocchi and Panko needs to be deployed on a separate node in a cluster mode to support scale and performance. Plz let me know if otherwise. Thanks Srikanth -Original Message- From: gordon chung [mailto:g...@live.ca] Sent: Monday, January 09, 2017 6:58 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Ceilometer] Scale deployment On 08/01/17 07:28 PM, Srikanth Vavilapalli wrote: > > - Deploying database cluster on separate nodes with sharding > and replica-sets enabled > we don't recommend you use ceilometer storage since it's deprecated and hasn't been worked on for over a year. > > > My questions are: > > 1. How to determine the number of ceilometer-agent-notification > that I should deploy? For example I have 3 node environment to deploy > ceilometer where a 3-node RabbitMq cluster is running. Should I deploy > three ceilometer-agent-notification each of them pointing to 3-node > rabbitmq cluster or can I deploy 1 or 2 notification agents that can > fetch the messages from rabbitmq nodes? Is there any guidline for this? i don't think there is a guide line. a single agent for 3 nodes is suffice. i would probably just suggest you monitor notifications.* queues and if they start lagging, add more notification agents as required. i believe a single agent can handle hundreds of notifications per second. > > 2. How do the ceilometer-agent-notification distribute the > received messages from rabbitmq among themselves? Is it round robin > among all messages or share the load at rabbitmq exchange levels? For > example if rabbitmq cluster is deployed with N number of exchanges > where telemetry data is sent equally among all these exchanges, can I > partition the rabbitmq exchanges such that each notification agents > process a subset of exchanges? notification agents just greedily grab from queues it's subscribed to when it can. it'll then requeue them (if you have multiple agents and workload_partitioning) enabled. > > 3. Do I need to deploy "ceilometer-collector" daemon also in > multiples in order to handle the load coming from > ceilometer-agent-notifications and to write to database replicas? > ceilometer collector is not a required service and probably just adds more load to your rabbitmq. you can send data directly from notification agent using direct:// publisher (or one of the aliases if you're master.) only suggestion i have off top of head is to enabled batching (set batch_size, batch_timeout in notification agent) cheers, -- gord __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] Scale deployment
Hi Can anyone plz point me to any document that captures how Ceilometer can be deployed in a scaled environment? I found in different documentation that Ceilometer can be configured for scaled environment (as below), but could not find a unified document that covers all the details together for ceilometer deployment in a scaled environment: - More than one rabbitmq servers is deployed for faster data collection - More than one Notification agents can be deployed with "workload_partitioning" enabled for faster data fetching from rabbitmq - Enabling multiple pipeline processing queues "pipeline_processing_queues" for faster pipeline processing - Deploying database cluster on separate nodes with sharding and replica-sets enabled My questions are: 1. How to determine the number of ceilometer-agent-notification that I should deploy? For example I have 3 node environment to deploy ceilometer where a 3-node RabbitMq cluster is running. Should I deploy three ceilometer-agent-notification each of them pointing to 3-node rabbitmq cluster or can I deploy 1 or 2 notification agents that can fetch the messages from rabbitmq nodes? Is there any guidline for this? 2. How do the ceilometer-agent-notification distribute the received messages from rabbitmq among themselves? Is it round robin among all messages or share the load at rabbitmq exchange levels? For example if rabbitmq cluster is deployed with N number of exchanges where telemetry data is sent equally among all these exchanges, can I partition the rabbitmq exchanges such that each notification agents process a subset of exchanges? 3. Do I need to deploy "ceilometer-collector" daemon also in multiples in order to handle the load coming from ceilometer-agent-notifications and to write to database replicas? Appreciate your inputs... Thanks Srikanth __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' hangs in "Making authentication request to keystone"
Hi We have root caused the issue. It is due to longer MTU setting in the VMs and because VxLAN tunneling is used for VM to VM communication on different compute nodes, the encapsulated packets are going beyond MTUs in the underlying network and getting fragmented and causing the connection issues. So I have set the MTU in the VMs to 1400 and the TCP MSS getting adjusted accordingly and now communication is working between VM1 & VM2. Thanks Srikanth -Original Message- From: Srikanth Vavilapalli [mailto:srikanth.vavilapa...@ericsson.com] Sent: Wednesday, November 23, 2016 9:54 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' hangs in "Making authentication request to keystone" We have ensured that the both UDP and TCP communication is good between VM1 and VM2. Also if you see ceilometer debug output in my initial e-mail, the first keystone REST (curl -g -i -X GET http://mysite-ceilometer-6:5000/v2.0) from VM2 to VM1 was successful, it hanged only at the second keystone REST (POST http://mysite-ceilometer-6:5000/v2.0/tokens). So communication seems like not a problem here. ubuntu@mysite-ceilometer-7:~$ ping 10.0.4.4 PING 10.0.4.4 (10.0.4.4) 56(84) bytes of data. 64 bytes from 10.0.4.4: icmp_seq=1 ttl=64 time=3.51 ms 64 bytes from 10.0.4.4: icmp_seq=2 ttl=64 time=2.03 ms 64 bytes from 10.0.4.4: icmp_seq=3 ttl=64 time=1.37 ms ^C --- 10.0.4.4 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 1.372/2.307/3.511/0.893 ms ubuntu@mysite-ceilometer-6:~$ nc -l 1048 Hello How is the connection? Good ubuntu@mysite-ceilometer-7:~$ nc 10.0.4.4 1048 Hello How is the connection? Good -Original Message- From: gordon chung [mailto:g...@live.ca] Sent: Wednesday, November 23, 2016 8:22 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' hangs in "Making authentication request to keystone" On 23/11/16 09:16 PM, Srikanth Vavilapalli wrote: > Yes, I agree, this issue is not related to ceilometer. We have verified that > none of the keystone commands (keystone endpoint-list, keystone catalog, > keystone user-list) are working in that VM2, they all stuck in getting the > token-get operation (/v2.0/tokens). > > If I had to suspect the keystone server setup in my VM1, then the keystone > client on VM3 also wouldn't work. So seems something else is going wrong > here. The keystone debugs logs also not helping much here... you could try seeing if you can access vm1 from vm2. i imagine you have some networking issues. > > On the last part, could you plz point us to any existing wiki pages that > describe to migrate away from ceilometer-api? Thanks for ur help... we have a guide on how to switch to Gnocchi[1]. we don't currently have a guide to switch to anything else but you can always just use either udp or http publishers and push to your required target... that our just push to oslo.messaging topic and have your service consume from it. [1] http://docs.openstack.org/developer/ceilometer/install/dbreco.html#moving-from-ceilometer-to-gnocchi cheers, -- gord __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' hangs in "Making authentication request to keystone"
We have ensured that the both UDP and TCP communication is good between VM1 and VM2. Also if you see ceilometer debug output in my initial e-mail, the first keystone REST (curl -g -i -X GET http://mysite-ceilometer-6:5000/v2.0) from VM2 to VM1 was successful, it hanged only at the second keystone REST (POST http://mysite-ceilometer-6:5000/v2.0/tokens). So communication seems like not a problem here. ubuntu@mysite-ceilometer-7:~$ ping 10.0.4.4 PING 10.0.4.4 (10.0.4.4) 56(84) bytes of data. 64 bytes from 10.0.4.4: icmp_seq=1 ttl=64 time=3.51 ms 64 bytes from 10.0.4.4: icmp_seq=2 ttl=64 time=2.03 ms 64 bytes from 10.0.4.4: icmp_seq=3 ttl=64 time=1.37 ms ^C --- 10.0.4.4 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 1.372/2.307/3.511/0.893 ms ubuntu@mysite-ceilometer-6:~$ nc -l 1048 Hello How is the connection? Good ubuntu@mysite-ceilometer-7:~$ nc 10.0.4.4 1048 Hello How is the connection? Good -Original Message- From: gordon chung [mailto:g...@live.ca] Sent: Wednesday, November 23, 2016 8:22 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' hangs in "Making authentication request to keystone" On 23/11/16 09:16 PM, Srikanth Vavilapalli wrote: > Yes, I agree, this issue is not related to ceilometer. We have verified that > none of the keystone commands (keystone endpoint-list, keystone catalog, > keystone user-list) are working in that VM2, they all stuck in getting the > token-get operation (/v2.0/tokens). > > If I had to suspect the keystone server setup in my VM1, then the keystone > client on VM3 also wouldn't work. So seems something else is going wrong > here. The keystone debugs logs also not helping much here... you could try seeing if you can access vm1 from vm2. i imagine you have some networking issues. > > On the last part, could you plz point us to any existing wiki pages that > describe to migrate away from ceilometer-api? Thanks for ur help... we have a guide on how to switch to Gnocchi[1]. we don't currently have a guide to switch to anything else but you can always just use either udp or http publishers and push to your required target... that our just push to oslo.messaging topic and have your service consume from it. [1] http://docs.openstack.org/developer/ceilometer/install/dbreco.html#moving-from-ceilometer-to-gnocchi cheers, -- gord __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' hangs in "Making authentication request to keystone"
Hi Gordon
Yes, I agree, this issue is not related to ceilometer. We have verified that
none of the keystone commands (keystone endpoint-list, keystone catalog,
keystone user-list) are working in that VM2, they all stuck in getting the
token-get operation (/v2.0/tokens).
If I had to suspect the keystone server setup in my VM1, then the keystone
client on VM3 also wouldn't work. So seems something else is going wrong here.
The keystone debugs logs also not helping much here...
On the last part, could you plz point us to any existing wiki pages that
describe to migrate away from ceilometer-api? Thanks for ur help...
Thanks
Srikanth
-Original Message-
From: gordon chung [mailto:g...@live.ca]
Sent: Wednesday, November 23, 2016 4:20 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list'
hangs in "Making authentication request to keystone"
i would probably just try to get a token from vm2 and see if that's even
possible. seems unrelated to ceilometerclient.
that said, i'm going to throw in obligatory: "ceilometer api is deprecated and
has been unmaintained for over a year. i suggest you switch to another storage
solution whether that's gnocchi or another time-series service"
On 23/11/16 06:35 PM, Srikanth Vavilapalli wrote:
> Hi
>
> We are facing few issues with keystone access in our setups.
>
> We have a setup which has three VMs. VM1 and VM3 are on same compute host
> whereas VM2 is on a different compute host.
>
> - VM1 (mysite-ceilometer-6): Running Mitaka Ceilometer service +
> Keystone (v2) service
> - VM2 (mysite-ceilometer-7): Running Ceilometer client
> - VM3 (mysite-ceilometer-8): Running Ceilometer client
>
> I have the keystone endpoints setup on VM1 as shown below: 'keystone
> endpoint-list'
> +--+---+--+--+---+--+
> | id | region | publicurl |
>internalurl |adminurl |
>service_id|
> +--+---+--+--+---+--+
> | 7c56f9e61 | RegionOne | http://mysite-ceilometer-6:5000/v2.0 |
> http://mysite-ceilometer-6:5000/v2.0 | http://mysite-ceilometer-6:35357/v2.0
> | 4d871 |
> | adc3ac02f | RegionOne | http://mysite-ceilometer-6:8777|
> http://mysite-ceilometer-6:8777|http://mysite-ceilometer-6:8777|
> 50fb869 |
> +--+---+--+--+---+--+
>
> I have set the following OS variables in both VM2 and VM3:
> OS_USERNAME="admin"
> OS_PASSWORD="password"
> OS_TENANT_NAME="admin"
> OS_AUTH_URL="http://mysite-ceilometer-6:5000/v2.0";
>
> The interesting observation I have made is that I am able to run the
> ceilometer or keystone commands successfully only from VM3 (which is on the
> same compute host as VM1) but not from VM2. Attached some of the logs I have
> collected during this observation. Can any of you help us with identifying
> what is going wrong here in this setup? Or any pointers on debugging why
> keystone/tokens REST API is not responding in some scenarios...? Thanks for
> ur help.
>
> The output from VM3 (mysite-ceilometer-8):
> -
> root@69861113613c:/usr/local/share# ceilometer -d meter-list DEBUG
> (session) REQ: curl -g -i -X GET http://mysite-ceilometer-6:5000/v2.0 -H
> "Accept: application/json" -H "User-Agent: python-keystoneclient"
> INFO (connectionpool) Starting new HTTP connection (1):
> mysite-ceilometer-6 DEBUG (connectionpool) "GET /v2.0 HTTP/1.1" 200
> 345 DEBUG (session) RESP: [200] Content-Length: 345 Vary: X-Auth-Token
> Keep-Alive: timeout=5, max=100 Server: Apache/2.4.7 (Ubuntu)
> Connection: Keep-Alive Date: Wed, 23 Nov 2016 22:49:28 GMT
> x-openstack-request-id: req-da4329a5-0374-48de-9a07-229636042f64
> Content-Type: application/json X-Distribution: Ubuntu RESP BODY:
> {"version": {"status": "stable", "updated": "2014-04-17T00:00:00Z",
> "media-types": [{"base": "application/json", "type":
> "application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0",
>
[openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' hangs in "Making authentication request to keystone"
Hi
We are facing few issues with keystone access in our setups.
We have a setup which has three VMs. VM1 and VM3 are on same compute host
whereas VM2 is on a different compute host.
- VM1 (mysite-ceilometer-6): Running Mitaka Ceilometer service + Keystone (v2)
service
- VM2 (mysite-ceilometer-7): Running Ceilometer client
- VM3 (mysite-ceilometer-8): Running Ceilometer client
I have the keystone endpoints setup on VM1 as shown below: 'keystone
endpoint-list'
+--+---+--+--+---+--+
| id | region | publicurl |
internalurl |adminurl |
service_id|
+--+---+--+--+---+--+
| 7c56f9e61 | RegionOne | http://mysite-ceilometer-6:5000/v2.0 |
http://mysite-ceilometer-6:5000/v2.0 | http://mysite-ceilometer-6:35357/v2.0 |
4d871 |
| adc3ac02f | RegionOne | http://mysite-ceilometer-6:8777|
http://mysite-ceilometer-6:8777|http://mysite-ceilometer-6:8777|
50fb869 |
+--+---+--+--+---+--+
I have set the following OS variables in both VM2 and VM3:
OS_USERNAME="admin"
OS_PASSWORD="password"
OS_TENANT_NAME="admin"
OS_AUTH_URL="http://mysite-ceilometer-6:5000/v2.0";
The interesting observation I have made is that I am able to run the ceilometer
or keystone commands successfully only from VM3 (which is on the same compute
host as VM1) but not from VM2. Attached some of the logs I have collected
during this observation. Can any of you help us with identifying what is going
wrong here in this setup? Or any pointers on debugging why keystone/tokens REST
API is not responding in some scenarios...? Thanks for ur help.
The output from VM3 (mysite-ceilometer-8):
-
root@69861113613c:/usr/local/share# ceilometer -d meter-list
DEBUG (session) REQ: curl -g -i -X GET http://mysite-ceilometer-6:5000/v2.0 -H
"Accept: application/json" -H "User-Agent: python-keystoneclient"
INFO (connectionpool) Starting new HTTP connection (1): mysite-ceilometer-6
DEBUG (connectionpool) "GET /v2.0 HTTP/1.1" 200 345
DEBUG (session) RESP: [200] Content-Length: 345 Vary: X-Auth-Token Keep-Alive:
timeout=5, max=100 Server: Apache/2.4.7 (Ubuntu) Connection: Keep-Alive Date:
Wed, 23 Nov 2016 22:49:28 GMT x-openstack-request-id:
req-da4329a5-0374-48de-9a07-229636042f64 Content-Type: application/json
X-Distribution: Ubuntu
RESP BODY: {"version": {"status": "stable", "updated": "2014-04-17T00:00:00Z",
"media-types": [{"base": "application/json", "type":
"application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0", "links":
[{"href": "http://mysite-ceilometer-6:5000/v2.0/";, "rel": "self"}, {"href":
"http://docs.openstack.org/";, "type": "text/html", "rel": "describedby"}]}}
DEBUG (v2) Making authentication request to
http://mysite-ceilometer-6:5000/v2.0/tokens
DEBUG (connectionpool) "POST /v2.0/tokens HTTP/1.1" 200 1293
DEBUG (session) REQ: curl -g -i -X GET http://mysite-ceilometer-6:5000/v2.0 -H
"Accept: application/json" -H "User-Agent: python-keystoneclient"
INFO (connectionpool) Starting new HTTP connection (1): mysite-ceilometer-6
DEBUG (connectionpool) "GET /v2.0 HTTP/1.1" 200 345
DEBUG (session) RESP: [200] Content-Length: 345 Vary: X-Auth-Token Keep-Alive:
timeout=5, max=100 Server: Apache/2.4.7 (Ubuntu) Connection: Keep-Alive Date:
Wed, 23 Nov 2016 22:49:28 GMT x-openstack-request-id:
req-491da351-24c1-4b4d-9558-b6d66a280c35 Content-Type: application/json
X-Distribution: Ubuntu
RESP BODY: {"version": {"status": "stable", "updated": "2014-04-17T00:00:00Z",
"media-types": [{"base": "application/json", "type":
"application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0", "links":
[{"href": "http://mysite-ceilometer-6:5000/v2.0/";, "rel": "self"}, {"href":
"http://docs.openstack.org/";, "type": "text/html", "rel": "describedby"}]}}
DEBUG (v2) Making authentication request to
http://mysite-ceilometer-6:5000/v2.0/tokens
DEBUG (connectionpool) "POST /v2.0/tokens HTTP/1.1" 200 1293
DEBUG (client) REQ: curl -g -i -X 'GET'
'http://mysite-ceilometer-6:8777/v2/meters' -H 'User-Agent:
ceilometerclient.openstack.common.apiclient' -H 'X-Auth-Token: {SHA1}a9'
INFO (connectionpool) Starting new HTTP connection (1): mysite-ceilometer-6
DEBUG (connectionpool) "GET /v2/meters HTTP/1.1" 200 2
DEBUG (client) RESP: [200] {'Date': 'Wed, 23 Nov 2016 22:49:29 GMT',
'Content-Length': '2', 'Content-Type': 'application/json; charset=UTF-
Re: [openstack-dev] [devstack][mitaka] Unable stack.sh on ubuntu 14.04.5LTS (TypeError: 'Documentation' object is not iterable)
Hi
One quick update on this issue:
For some reason I see this issue only with devstack mitaka on vagrant VM
spawned using virtualbox provider(Ubuntu/trusty64 box). It used to work before
though...
On the same vagrant VM, I installed devstack Liberty which is working without
any issues. Also I tried devstack mitaka on vagrant VM spawned using libvirt
provider and interestingly that is also working.
Not sure what the issue with vagrant virtualbox VM...
Thanks
Srikanth
From: Srikanth Vavilapalli [mailto:srikanth.vavilapa...@ericsson.com]
Sent: Saturday, October 29, 2016 3:03 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [devstack][mitaka] Unable stack.sh on ubuntu
14.04.5LTS (TypeError: 'Documentation' object is not iterable)
Hi
I am consistently getting the following error when I run stack.sh on my vagrant
VM with Ubuntu 14.04.5 OS. I tried to upgrade setuptools and distribute, but
none of them were able to solve this error. Can you plz help me how to resolve
this error. Plz let me know if u need further data here...
Thanks
Srikanth
2016-10-29 21:52:27.289 | Configuring Horizon
+./stack.sh:main:1057 configure_horizon
+lib/horizon:configure_horizon:79 setup_develop /opt/stack/horizon
+inc/python:setup_develop:271 local project_dir=/opt/stack/horizon
+inc/python:setup_develop:272 local extras=
+inc/python:setup_develop:273 _setup_package_with_constraints_edit
/opt/stack/horizon -e
+inc/python:_setup_package_with_constraints_edit:303 local
project_dir=/opt/stack/horizon
+inc/python:_setup_package_with_constraints_edit:304 local flags=-e
+inc/python:_setup_package_with_constraints_edit:305 local extras=
+inc/python:_setup_package_with_constraints_edit:307 '[' -n
/opt/stack/requirements ']'
+inc/python:_setup_package_with_constraints_edit:309 local name
++inc/python:_setup_package_with_constraints_edit:310 awk '/^name.*=/ {print
$3}' /opt/stack/horizon/setup.cfg
+inc/python:_setup_package_with_constraints_edit:310 name=horizon
+inc/python:_setup_package_with_constraints_edit:312
/opt/stack/requirements/.venv/bin/edit-constraints
/opt/stack/requirements/upper-constraints.txt -- horizon '-e
file:///opt/stack/horizon#egg=horizon'
+inc/python:_setup_package_with_constraints_edit:316 setup_package
/opt/stack/horizon -e
+inc/python:setup_package:332 local project_dir=/opt/stack/horizon
+inc/python:setup_package:333 local flags=-e
+inc/python:setup_package:334 local extras=
+inc/python:setup_package:338 [[ -n -e ]]
+inc/python:setup_package:338 [[ -z '' ]]
+inc/python:setup_package:338 [[ ! -e =~ ^-.* ]]
+inc/python:setup_package:343 [[ ! -z '' ]]
+inc/python:setup_package:347 pip_install -e /opt/stack/horizon
+inc/python:pip_install:84 local xtrace result
++inc/python:pip_install:85 set +o
++inc/python:pip_install:85 grep xtrace
+inc/python:pip_install:85 xtrace='set -o xtrace'
+inc/python:pip_install:86 set +o xtrace
+inc/python:pip_install:155sudo -H http_proxy= https_proxy=
no_proxy= PIP_FIND_LINKS= SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite
/usr/local/bin/pip2.7 install -c /opt/stack/requirements/upper-constraints.txt
--upgrade -e /opt/stack/horizon
Ignoring dnspython3: markers u"python_version=='3.4'" don't match your
environment
Obtaining file:///opt/stack/horizon
Obtaining horizon from file:///opt/stack/horizon#egg=horizon (from -c
/opt/stack/requirements/upper-constraints.txt (line 1))
Requirement already up-to-date: Babel===2.2.0 in
/usr/local/lib/python2.7/dist-packages (from -c
/opt/stack/requirements/upper-constraints.txt (line 3))
...
Requirement already up-to-date: python-openstackclient===2.3.0 in
/usr/local/lib/python2.7/dist-packages (from -c
/opt/stack/requirements/upper-constraints.txt (line 305))
Requirement already up-to-date: python-swiftclient===3.0.0 in
/usr/local/lib/python2.7/dist-packages (from -c
/opt/stack/requirements/upper-constraints.txt (line 313))
Requirement already up-to-date: pytz===2015.7 in
/usr/local/lib/python2.7/dist-packages (from -c
/opt/stack/requirements/upper-constraints.txt (line 316))
Collecting rcssmin===1.0.6 (from -c
/opt/stack/requirements/upper-constraints.txt (line 320))
Using cached rcssmin-1.0.6.tar.gz
Complete output from command python setup.py egg_info:
running egg_info
creating pip-egg-info/rcssmin.egg-info
writing pip-egg-info/rcssmin.egg-info/PKG-INFO
writing top-level names to pip-egg-info/rcssmin.egg-info/top_level.txt
writing dependency_links to
pip-egg-info/rcssmin.egg-info/dependency_links.txt
writing manifest file 'pip-egg-info/rcssmin.egg-info/SOURCES.
[openstack-dev] [devstack][mitaka] Unable stack.sh on ubuntu 14.04.5LTS (TypeError: 'Documentation' object is not iterable)
Hi
I am consistently getting the following error when I run stack.sh on my vagrant
VM with Ubuntu 14.04.5 OS. I tried to upgrade setuptools and distribute, but
none of them were able to solve this error. Can you plz help me how to resolve
this error. Plz let me know if u need further data here...
Thanks
Srikanth
2016-10-29 21:52:27.289 | Configuring Horizon
+./stack.sh:main:1057 configure_horizon
+lib/horizon:configure_horizon:79 setup_develop /opt/stack/horizon
+inc/python:setup_develop:271 local project_dir=/opt/stack/horizon
+inc/python:setup_develop:272 local extras=
+inc/python:setup_develop:273 _setup_package_with_constraints_edit
/opt/stack/horizon -e
+inc/python:_setup_package_with_constraints_edit:303 local
project_dir=/opt/stack/horizon
+inc/python:_setup_package_with_constraints_edit:304 local flags=-e
+inc/python:_setup_package_with_constraints_edit:305 local extras=
+inc/python:_setup_package_with_constraints_edit:307 '[' -n
/opt/stack/requirements ']'
+inc/python:_setup_package_with_constraints_edit:309 local name
++inc/python:_setup_package_with_constraints_edit:310 awk '/^name.*=/ {print
$3}' /opt/stack/horizon/setup.cfg
+inc/python:_setup_package_with_constraints_edit:310 name=horizon
+inc/python:_setup_package_with_constraints_edit:312
/opt/stack/requirements/.venv/bin/edit-constraints
/opt/stack/requirements/upper-constraints.txt -- horizon '-e
file:///opt/stack/horizon#egg=horizon'
+inc/python:_setup_package_with_constraints_edit:316 setup_package
/opt/stack/horizon -e
+inc/python:setup_package:332 local project_dir=/opt/stack/horizon
+inc/python:setup_package:333 local flags=-e
+inc/python:setup_package:334 local extras=
+inc/python:setup_package:338 [[ -n -e ]]
+inc/python:setup_package:338 [[ -z '' ]]
+inc/python:setup_package:338 [[ ! -e =~ ^-.* ]]
+inc/python:setup_package:343 [[ ! -z '' ]]
+inc/python:setup_package:347 pip_install -e /opt/stack/horizon
+inc/python:pip_install:84 local xtrace result
++inc/python:pip_install:85 set +o
++inc/python:pip_install:85 grep xtrace
+inc/python:pip_install:85 xtrace='set -o xtrace'
+inc/python:pip_install:86 set +o xtrace
+inc/python:pip_install:155sudo -H http_proxy= https_proxy=
no_proxy= PIP_FIND_LINKS= SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite
/usr/local/bin/pip2.7 install -c /opt/stack/requirements/upper-constraints.txt
--upgrade -e /opt/stack/horizon
Ignoring dnspython3: markers u"python_version=='3.4'" don't match your
environment
Obtaining file:///opt/stack/horizon
Obtaining horizon from file:///opt/stack/horizon#egg=horizon (from -c
/opt/stack/requirements/upper-constraints.txt (line 1))
Requirement already up-to-date: Babel===2.2.0 in
/usr/local/lib/python2.7/dist-packages (from -c
/opt/stack/requirements/upper-constraints.txt (line 3))
...
Requirement already up-to-date: python-openstackclient===2.3.0 in
/usr/local/lib/python2.7/dist-packages (from -c
/opt/stack/requirements/upper-constraints.txt (line 305))
Requirement already up-to-date: python-swiftclient===3.0.0 in
/usr/local/lib/python2.7/dist-packages (from -c
/opt/stack/requirements/upper-constraints.txt (line 313))
Requirement already up-to-date: pytz===2015.7 in
/usr/local/lib/python2.7/dist-packages (from -c
/opt/stack/requirements/upper-constraints.txt (line 316))
Collecting rcssmin===1.0.6 (from -c
/opt/stack/requirements/upper-constraints.txt (line 320))
Using cached rcssmin-1.0.6.tar.gz
Complete output from command python setup.py egg_info:
running egg_info
creating pip-egg-info/rcssmin.egg-info
writing pip-egg-info/rcssmin.egg-info/PKG-INFO
writing top-level names to pip-egg-info/rcssmin.egg-info/top_level.txt
writing dependency_links to
pip-egg-info/rcssmin.egg-info/dependency_links.txt
writing manifest file 'pip-egg-info/rcssmin.egg-info/SOURCES.txt'
warning: manifest_maker: standard file '-c' not found
Traceback (most recent call last):
File "", line 1, in
File "/tmp/pip-build-T8bWPt/rcssmin/setup.py", line 42, in
setup()
File "/tmp/pip-build-T8bWPt/rcssmin/setup.py", line 33, in setup
return run(script_args=args, ext=ext, manifest_only=_manifest)
File "_setup/py2/setup.py", line 421, in run
return _core.setup(**kwargs)
File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
dist.run_commands()
File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "build/bdist.linux-x86_64/egg/setuptools/command/egg_info.py", line
279, in run
File "build/bdist.linux-x86_64/egg/setuptools/command/eg
Re: [openstack-dev] [Ceilometer]:Subscribe and Publish Notification frame work in Ceilometer !
Thanks very much Gord for the pointers.
I have looked at this file reload feature and it addresses some part of my
problem description (avoiding the restart of the ceilometer services to reflect
the pipeline changes). However, this still requires users to directly access
the internal ceilometer file (pipeline.yaml) to make any updates to pipeline.
There are no APIs introduced as part of this feature to allow user to
configure/unconfigure these pipeline. In one of the deployment that we are
currently looking for, we wanted to expose only ceilometer API service to the
users and block access to any internal modules of ceilometer. In the same
deployment, we are also thinking of allowing users to configure/unconfigure a
pipeline for a set of meters for only a subset of resources instead of getting
notified about events/meters of all the resources as shown below.
sources:
- name: user1_meter_source
meters:
- "cpu_util"
query/filter:
- {{field:"project_id",op:"eq",value:"11"}}
sinks:
- user1_meter_sink
sinks:
- name: user1_meter_sink
transformers:
publishers:
- udp://:
We have found a related blueprint [1], which is exactly addressing this dynamic
provisioning of pipelines via an API and making use of a new data store to
store this configuration. But seems like that blueprint was abandoned due its
limited usage. We agree that it may not be that frequent operation to change
the pipeline configuration in all deployments, but in certain deployments,
where applications desire to turn ON/OFF receiving these notifications based on
some other trigger (like anomaly detection, where application might have sensed
an anomaly based on some set of meters and wanted to turn ON few additional set
of event/meters to confirm that and turn OFF once the anomaly is confirmed).
Thanks
Srikanth
[1]
https://wiki.openstack.org/wiki/Ceilometer/blueprints/Configuration-via-data-store
From: gord chung [mailto:g...@live.ca]
Sent: Thursday, November 19, 2015 9:08 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ceilometer]:Subscribe and Publish Notification
frame work in Ceilometer !
On 19/11/15 10:26 PM, Srikanth Vavilapalli wrote:
Hi Gord
On your second point, Yes, Ceilometer does provide a framework to capture a
notification and republish to multiple "publish targets" in addition to the
collector service using udp/kafka/notification as the transport mechanisms...
We believe this is how "Event Alarm Evaluator" module in Aodh project get
notified directly from Notification Agents.
However seems like the configuration of these additional "publish targets" is
supported only through updating the pipeline_cfg_file and restarting the
corresponding ceilometer services. i.e. the users need to manually update the
pipeline config files to insert their "publish targets" in the sink-publisher
configuration for a set of event filters of their interest. This type of
provisioning is very static.
As per our understanding, ceilometer currently does not provide means for users
to dynamically register/unregister their "publish targets" with ceilometer
framework for a subset events of their interest? i.e User invokes a ceilometer
API with a set of event filters and associated publish targets, that can be
stored in a data store, which will eventually be used by the ceilometer
Publisher to dispatch the notification to those configured destinations in
addition to the statically configured "publish targets". Plz let us know if our
understanding is wrong or if there are any other means to achieve the above
functionality. We believe this as a very key functionality needed to build
latency sensitive (sub-second) analytics application on-top of ceilometer
framework. We are seeking the feedback from community on having this kind of
functionality inside ceilometer before proceeding with blueprint submission.
actually, in Liberty you can configure a reload[1][2] to refresh pipeline when
a change happens. based on survey results, most operators don't need this
functionality so it's off by default but it seems you do. :)
[1]
https://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/reload-file-based-pipeline-configuration.html
[2]
https://github.com/openstack/ceilometer/blob/master/ceilometer/pipeline.py#L50-L58
cheers,
--
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer]:Subscribe and Publish Notification frame work in Ceilometer !
Hi Gord On your second point, Yes, Ceilometer does provide a framework to capture a notification and republish to multiple "publish targets" in addition to the collector service using udp/kafka/notification as the transport mechanisms... We believe this is how "Event Alarm Evaluator" module in Aodh project get notified directly from Notification Agents. However seems like the configuration of these additional "publish targets" is supported only through updating the pipeline_cfg_file and restarting the corresponding ceilometer services. i.e. the users need to manually update the pipeline config files to insert their "publish targets" in the sink-publisher configuration for a set of event filters of their interest. This type of provisioning is very static. As per our understanding, ceilometer currently does not provide means for users to dynamically register/unregister their "publish targets" with ceilometer framework for a subset events of their interest? i.e User invokes a ceilometer API with a set of event filters and associated publish targets, that can be stored in a data store, which will eventually be used by the ceilometer Publisher to dispatch the notification to those configured destinations in addition to the statically configured "publish targets". Plz let us know if our understanding is wrong or if there are any other means to achieve the above functionality. We believe this as a very key functionality needed to build latency sensitive (sub-second) analytics application on-top of ceilometer framework. We are seeking the feedback from community on having this kind of functionality inside ceilometer before proceeding with blueprint submission. One alternative approach could be to republishing all the notifications from Notification Agents to a centralized common module, which in turn provides a Subscribe-Publish type of interface to user. But the downside of this two level approach is additional latencies introduced at each layer before the event gets delivered to the user/application. Plz let us know your inputs... Thanks Srikanth From: gord chung [mailto:g...@live.ca] Sent: Thursday, November 05, 2015 2:59 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Ceilometer]:Subscribe and Publish Notification frame work in Ceilometer ! On 05/11/2015 5:11 AM, Raghunath D wrote: Hi Pradeep, Presently we are looking for a monitoring service.Using monitoring service user's/application's will subscribe for few notification's/events from openstack infrastructure and monitoring service will publish these notification to user's/application's. We are exploring Ceilometer for this purpose.We came across below blue print which is similar to our requirement. https://blueprints.launchpad.net/ceilometer/+spec/declarative-notifications. i'm not exactly clear on what you are trying to achieve. that said, the basic premise of the above blueprint is that if serviceX (nova, neutron, etc...) starts publishing a new notification with a metric of interest, Ceilometer can be easily configured to capture said metric by adding a metric definition to a definition file[1] or a custom definition file[2]. the same can be done for events[3]. We have few queries on declarative-notifications frame work,could you please help us in addressing them: 1.We are looking for an API for Subcribing/Publishing notification.Do this frame work exposes any such API,if yes could you please provide us API doc or spec how to use it. 2.If the frame work doesn't have such API,does any of the development group is working in this area. 3.Please suggest what would be the best place in ceilometer notification frame work(publisher/dispatcher/..) to implement the Subscribe and Publish API. from what is described, it seems like you'd like Ceilometer to capture a notification and republish it rather than stored in a Ceilometer supported storage driver (ie Gnocchi, ElasticSearch, SQL, etc...). currently, the only way to do this is to not enable a collector service. doing so, the Event/Sample will be published to a message queue (default) which you can configure your service to pull from. currently, i don't believe oslo.messaging supports pub/sub work flow. alternatively, you can use one of the other publishers[4]. the kafka publisher should allow you to do a pub/sub type workflow. i know RAX has atom hopper[5] which uses atom feeds to support pub/sub functionality. there was discussions on adding support for this but no work has been done on it. feel free to propose it if you feel it's worthwhile. [1] https://github.com/openstack/ceilometer/blob/master/ceilometer/meter/data/meters.yaml [2] https://github.com/openstack/ceilometer/blob/master/ceilometer/meter/notifications.py#L31 [3] https://github.com/openstack/ceilometer/blob/master/etc/ceilometer/event_definitions.yaml [4] http://docs.openstack.org/admin-guide-cloud/telemetry-data-retrieval.html#publishers [5] http
Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum" and "average" fields in statistics query
I have raised the bug for this (https://bugs.launchpad.net/ceilometer/+bug/1508220) I have checked the ceilometer-api logs when I ran the query and have not found any errors or warnings. I could see only the below two logs: 2015-10-20 17:47:06.771 84151 DEBUG ceilometer.api.controllers.v2.meters [-] computed value coming from u'(,)' statistics /usr/lib/python2.7/dist-packages/ceilometer/api/controllers/v2/meters.py:407 2015-10-20 17:47:06.773 84151 INFO werkzeug [-] 192.168.0.3 - - [20/Oct/2015 17:47:06] "GET /v2/meters/vcpe.dns.cache.size/statistics HTTP/1.1" 200 - Thanks Srikanth -Original Message- From: gord chung [mailto:g...@live.ca] Sent: Tuesday, October 20, 2015 1:39 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum" and "average" fields in statistics query could you open a bug on https://bugs.launchpad.net/ceilometer/+bugs?orderby=-id&start=0 and reference this thread i would also check to see if ceilometer-api logs have any noticeable warning/errors. it's possible a datatype is being restricted there as well. thanks On 20/10/2015 12:22 PM, Srikanth Vavilapalli wrote: > Hi > > I am using MongoDB backend. > > Thanks > Srikanth > > -Original Message- > From: gord chung [mailto:g...@live.ca] > Sent: Tuesday, October 20, 2015 9:20 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum" > and "average" fields in statistics query > > which backend are you using? this potentially may be a bug where we're > hitting some size limit restricted by datatype. > > On 19/10/2015 4:02 PM, Srikanth Vavilapalli wrote: >> Hi >> >> I have observed "inf" values for "sum" and "average" fields in a ceilometer >> statistics query on one of my custom meter as shown below. I have also >> verified the samples query for this meter and there are 1544 samples (output >> shown below) with all of them having value as "150.0". So ideally the "Avg" >> filed should be "150.0" in this scenario. Could anyone tell me in what >> scenario we will see these two fields as "inf" in the meter statistics >> query? Plz let me know if you need more details or logs here. Appreciate >> your help. >> >> Thanks >> Srikanth >> >> >> svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer >> statistics --meter=vcpe.dns.cache.size >> ++++---+---+-+-+---++++ >> | Period | Period Start | Period End | Max | >> Min | Avg | Sum | Count | Duration | Duration Start | >> Duration End | >> ++++---+---+-+-+---++++ >> | 0 | 2015-10-17T01:30:24.999000 | 2015-10-19T17:47:20.587000 | 150.0 | >> 150.0 | inf | inf | 1544 | 231415.588 | 2015-10-17T01:30:24.999000 | >> 2015-10-19T17:47:20.587000 | >> ++++---+---+-+-+---++++ >> >> >> svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer >> sample-list --meter=vcpe.dns.cache.size >> +-+-+---++-++ >> | Resource ID | Name| Type | Volume | Unit| Timestamp >>| >> +-+-+---++-++ >> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | >> 2015-10-19T17:47:20.587000 | >> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | >> 2015-10-19T17:47:00.048000 | >> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | >> 2015-10-19T17:42:20.47 | >> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | >> 2015-10-19T17:41:59.921000 | >> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | >> 2015-10-19T17:37:20.362000 | >> . >> . >> . >> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | >> 2015-10-17T01:50:25.499000 | >> | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | >> 2015-10-17T01:4
Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum" and "average" fields in statistics query
Hi I am using MongoDB backend. Thanks Srikanth -Original Message- From: gord chung [mailto:g...@live.ca] Sent: Tuesday, October 20, 2015 9:20 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Ceilometer] "Infinite" values for "sum" and "average" fields in statistics query which backend are you using? this potentially may be a bug where we're hitting some size limit restricted by datatype. On 19/10/2015 4:02 PM, Srikanth Vavilapalli wrote: > Hi > > I have observed "inf" values for "sum" and "average" fields in a ceilometer > statistics query on one of my custom meter as shown below. I have also > verified the samples query for this meter and there are 1544 samples (output > shown below) with all of them having value as "150.0". So ideally the "Avg" > filed should be "150.0" in this scenario. Could anyone tell me in what > scenario we will see these two fields as "inf" in the meter statistics query? > Plz let me know if you need more details or logs here. Appreciate your help. > > Thanks > Srikanth > > > svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer > statistics --meter=vcpe.dns.cache.size > ++++---+---+-+-+---++++ > | Period | Period Start | Period End | Max | > Min | Avg | Sum | Count | Duration | Duration Start | > Duration End | > ++++---+---+-+-+---++++ > | 0 | 2015-10-17T01:30:24.999000 | 2015-10-19T17:47:20.587000 | 150.0 | > 150.0 | inf | inf | 1544 | 231415.588 | 2015-10-17T01:30:24.999000 | > 2015-10-19T17:47:20.587000 | > ++++---+---+-+-+---++++ > > > svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer > sample-list --meter=vcpe.dns.cache.size > +-+-+---++-++ > | Resource ID | Name| Type | Volume | Unit| Timestamp > | > +-+-+---++-++ > | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | > 2015-10-19T17:47:20.587000 | > | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | > 2015-10-19T17:47:00.048000 | > | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | > 2015-10-19T17:42:20.47 | > | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | > 2015-10-19T17:41:59.921000 | > | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | > 2015-10-19T17:37:20.362000 | > . > . > . > | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | > 2015-10-17T01:50:25.499000 | > | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | > 2015-10-17T01:45:46.255000 | > | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | > 2015-10-17T01:45:25.374000 | > | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | > 2015-10-17T01:40:46.131000 | > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- gord __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] "Infinite" values for "sum" and "average" fields in statistics query
Hi I have observed "inf" values for "sum" and "average" fields in a ceilometer statistics query on one of my custom meter as shown below. I have also verified the samples query for this meter and there are 1544 samples (output shown below) with all of them having value as "150.0". So ideally the "Avg" filed should be "150.0" in this scenario. Could anyone tell me in what scenario we will see these two fields as "inf" in the meter statistics query? Plz let me know if you need more details or logs here. Appreciate your help. Thanks Srikanth svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer statistics --meter=vcpe.dns.cache.size ++++---+---+-+-+---++++ | Period | Period Start | Period End | Max | Min | Avg | Sum | Count | Duration | Duration Start | Duration End | ++++---+---+-+-+---++++ | 0 | 2015-10-17T01:30:24.999000 | 2015-10-19T17:47:20.587000 | 150.0 | 150.0 | inf | inf | 1544 | 231415.588 | 2015-10-17T01:30:24.999000 | 2015-10-19T17:47:20.587000 | ++++---+---+-+-+---++++ svavilap@ctl:/usr/lib/python2.7/dist-packages/ceilometer$ ceilometer sample-list --meter=vcpe.dns.cache.size +-+-+---++-++ | Resource ID | Name| Type | Volume | Unit| Timestamp | +-+-+---++-++ | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | 2015-10-19T17:47:20.587000 | | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | 2015-10-19T17:47:00.048000 | | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | 2015-10-19T17:42:20.47 | | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | 2015-10-19T17:41:59.921000 | | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | 2015-10-19T17:37:20.362000 | . . . | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | 2015-10-17T01:50:25.499000 | | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | 2015-10-17T01:45:46.255000 | | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | 2015-10-17T01:45:25.374000 | | vcpe-170| vcpe.dns.cache.size | gauge | 150.0 | entries | 2015-10-17T01:40:46.131000 | __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Meter-list with multiple filters in simple query is not working
Hi
Thanks for your reply.
Yes, I need the logical OR operation here.
Seems the simple query is not either doing logical "AND" operation also.
Because, if so, the output should be empty list in my example. However, the
output is list of meters with the project_id value as d41cd...*. If I
interchange the project_id field values in my query, the resulting output is
list of meters with the project_id value as f28d2...*. i.e. the API is using
the last q.field value for filtering for the "project_id" field.
I have seen the complex query format supporting these additional operations
like logical "OR", but my understanding from the documentation was that these
complex queries are supported only for Samples, Alarms and Alarms History, but
not for "Meters". Nevertheless I still tried this complex query with /v2/meters
by following /v2/query/samples example and it was returning 404 Not found. Plz
correct me if I am doing something wrong here.
curl -X POST -H 'X-Auth-Token:eed134b917914fd987e50d8ec1651213' -H
'Content-Type: application/json' -d '{"filter" : "{\"or\":[{\"=\":
{\"project_id\": \"f28d2e522e1f466a95194c10869acd0c\"}},{\"=\":
{\"project_id\": \"d41cdd2ade394e599b40b9b50d9cd623\"}}]}}'
"http://10.11.10.1:8777/v2/query/meters";
Thanks
Srikanth
-Original Message-
From: Eoghan Glynn [mailto:egl...@redhat.com]
Sent: Monday, October 12, 2015 4:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Meter-list with multiple filters in
simple query is not working
> Hi
>
> Can anyone plz help me on how to specify a simple query with multiple
> values for a query field in a Ceilometer meter-list request? I need to
> fetch meters that belongs to more than one project id. I have tried
> the following query format, but only the last query value (in this
> case, project_id=
> d41cdd2ade394e599b40b9b50d9cd623) is used for filtering. Any help is
> appreciated here.
>
> curl -H 'X-Auth-Token:'
> http://localhost:8777/v2/meters?q.field=project_id&q.op=eq&q.value=f28
> d2e522e1f466a95194c10869acd0c&q.field=project_id&q.op=eq&q.value=d41cd
> d2ade394e599b40b9b50d9cd623
>
> Thanks
> Srikanth
By "not working" you mean "not doing what you (incorrectly) expect it to do"
Your query asks for samples with aproject_id set to *both* f28d.. *and* d41c..
The result is empty, as a sample can't be associated with two project_ids.
The ceilometer simple query API combines all filters using logical AND.
Seems like you want logical OR here, which is possible to express via complex
queries:
http://docs.openstack.org/developer/ceilometer/webapi/v2.html#complex-query
Cheers,
Eoghan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] Meter-list with multiple filters in simple query is not working
Hi Can anyone plz help me on how to specify a simple query with multiple values for a query field in a Ceilometer meter-list request? I need to fetch meters that belongs to more than one project id. I have tried the following query format, but only the last query value (in this case, project_id= d41cdd2ade394e599b40b9b50d9cd623) is used for filtering. Any help is appreciated here. curl -H 'X-Auth-Token:' http://localhost:8777/v2/meters?q.field=project_id&q.op=eq&q.value=f28d2e522e1f466a95194c10869acd0c&q.field=project_id&q.op=eq&q.value=d41cdd2ade394e599b40b9b50d9cd623 Thanks Srikanth __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Meters
Hi The vcpus, memory and disk usage related nova measurements are of "notification" type. So Plz ensure you have the following configuration settings in your nova.conf file on your compute node and restart your nova-compute service if you made any changes to that file. instance_usage_audit=True instance_usage_audit_period=hour notify_on_state_change=vm_and_task_state notification_driver = messagingv2 notification_topics = notifications notify_on_any_change = True Thanks Srikanth From: Abhishek Talwar [mailto:abhishek.tal...@tcs.com] Sent: Monday, September 07, 2015 11:05 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Ceilometer] Meters Hi Folks, I have installed a kilo devstack setup install and I am trying to get the memory and disk usage for my VM's. But on checking the "ceilometer meter-list" I can't find memory.usage or disk.usage meters. I am searched a lot for this and still couldn't find a solution. So how to enable these meters to our meter-list. I want all these meters in the ceilometer meter-list so that I can use them to monitor my instances. Currently the output of ceilometer meter-list is as follows: +--++--+--+--+ | Name | Type | Resource ID | User ID | Project ID | +--++--+--+--+ | cpu | cumulative | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77 | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 | | cpu_util | gauge | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77 | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 | | disk.read.bytes | cumulative | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77 | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 | | disk.read.requests | cumulative | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77 | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 | | disk.write.bytes | cumulative | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77 | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 | | disk.write.requests | cumulative | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77 | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 | | image| gauge | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de | | 22f22fb60bf8496cb60e8498d93d56e8 | | image| gauge | acd6beef-13e6-4d64-a83d-9e96beac26ef | | 22f22fb60bf8496cb60e8498d93d56e8 | | image| gauge | ecefcd31-ae47-4079-bd19-efe07f4c33d3 | | 22f22fb60bf8496cb60e8498d93d56e8 | | image.download | delta | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de | | 22f22fb60bf8496cb60e8498d93d56e8 | | image.serve | delta | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de | | 22f22fb60bf8496cb60e8498d93d56e8 | | image.size | gauge | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de | | 22f22fb60bf8496cb60e8498d93d56e8 | | image.size | gauge | acd6beef-13e6-4d64-a83d-9e96beac26ef | | 22f22fb60bf8496cb60e8498d93d56e8 | | image.size | gauge | ecefcd31-ae47-4079-bd19-efe07f4c33d3 | | 22f22fb60bf8496cb60e8498d93d56e8 | | image.update | delta | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de | | 22f22fb60bf8496cb60e8498d93d56e8 | | image.upload | delta | 55a0a2c2-8cfb-4882-ad05-01d7c821b1de | | 22f22fb60bf8496cb60e8498d93d56e8 | | instance | gauge | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77 | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 | | instance:m1.small| gauge | 5314c72b-a2b4-4b2b-bcb1-4057c3d96f77 | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 | | network.incoming.bytes | cumulative | nova-instance-instance-0022-fa163e3bd74e | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 | | network.incoming.packets | cumulative | nova-instance-instance-0022-fa163e3bd74e | 92876a1aad3c477398137b702a8467d3 | 22f22fb60bf8496cb60e8498d93d56e8 | | network.outgoing.bytes | cumulative | nova-instance-instance-0022-fa163e3bd74e | 92876a1aad3c477398137b702a8467d3
Re: [openstack-dev] [Ceilometer] Unable to get the neutron network related meters in ceilometer
Thanks gord. I will enable "store_events" and see if neutron related meters/state events are appearing under "ceilometer events-list" Thanks Srikanth -Original Message- From: gord chung [mailto:g...@live.ca] Sent: Thursday, July 30, 2015 2:05 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Ceilometer] Unable to get the neutron network related meters in ceilometer On 30/07/2015 1:55 PM, Srikanth Vavilapalli wrote: > I was able to resolve this issue by adding the following configuration line > (by default, disable_non_metric_meters is set to True, and most of the > Neutron meters are of type non-metric) in /etc/ceilometer/ceilometer.conf > and restarting all ceilometer services.. Hope this helps others... > > [notification] > disable_non_metric_meters = false to followup, in Ceilometer, we capture data in two different models: Meters and Events[1]. Meters are designed for numeric, measurement data such as: cpu time, cpu_util, incoming.bytes, etc... Events are a more generic model which represent the state of a resource. historically, we never had Events so we captured non-measurement data (see Neutron 'meters') as Meters. going forward, consumers should enable store_events (if not already) to capture non-measurement data as Events. Events offer better granularity and are more query-able. [1] http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-events.html cheers, -- gord __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Unable to get the neutron network related meters in ceilometer
I was able to resolve this issue by adding the following configuration line (by default, disable_non_metric_meters is set to True, and most of the Neutron meters are of type non-metric) in /etc/ceilometer/ceilometer.conf and restarting all ceilometer services.. Hope this helps others... [notification] disable_non_metric_meters = false Thanks Srikanth -Original Message- From: Srikanth Vavilapalli [mailto:srikanth.vavilapa...@ericsson.com] Sent: Wednesday, July 29, 2015 2:25 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Ceilometer] Unable to get the neutron network related meters in ceilometer Hi I have manually installed latest ceilometer service in my devstack (master branch) cluster with MongoDB as backend. I have configured all the ceilometer services (notification, central, collector, api services on controller node and ceilometer-agent-compute on compute nodes) as per the installation guide. Also I have enabled "nova", "glance", "cinder" and "neutron" to send notifications to oslo messaging queue by modifying the corresponding .conf file. When I run "ceilometer meter-list" command, I can see only the meters from compute, glance and cinder, but not from "neutron" service. Could any of provide me any pointers on how I can troubleshoot this issue? Plz let me know if you need any info from my setup.. Thanks Srikanth __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] Unable to get the neutron network related meters in ceilometer
Hi I have manually installed latest ceilometer service in my devstack (master branch) cluster with MongoDB as backend. I have configured all the ceilometer services (notification, central, collector, api services on controller node and ceilometer-agent-compute on compute nodes) as per the installation guide. Also I have enabled "nova", "glance", "cinder" and "neutron" to send notifications to oslo messaging queue by modifying the corresponding .conf file. When I run "ceilometer meter-list" command, I can see only the meters from compute, glance and cinder, but not from "neutron" service. Could any of provide me any pointers on how I can troubleshoot this issue? Plz let me know if you need any info from my setup.. Thanks Srikanth __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
