Re: [Openstack] [Ceilometer/Heat in Havana]: Should autoscaling groups work already?
Hi Juha,
The problem you're encountering is a known restriction of the sqlalchemy storage
driver, which doesn't yet provide the capability to select the statistics for
the
given Heat autoscaling group on which the scale up/down alarms are based (the
so-
called metaquery feature).
In order for this feature to be present in the ceilometer API service, you'll
need
to use the mongodb storage driver instead.
Thanks,
Eoghan
- Original Message -
> Hi,
>
> I met the problem when tried to be using autoscaling groups in heat templates
> with havana (see:
> https://bugs.launchpad.net/heat/+bug/1223710 )
>
> Can anyone confirm whether the autoscaling should already work with havana?
>
> Currently the evaluation of the ceilometer alarm/meter data seems to be
> failing:
>
>
>
> ceilometer-alarm-singleton:
> ==
> 2013-09-11 10:16:28.074 5326 INFO ceilometer.alarm.threshold_evaluation [-]
> initiating evaluation cycle on 3 alarms
> 2013-09-11 10:16:28.108 5326 ERROR ceilometer.alarm.threshold_evaluation [-]
> alarm stats retrieval failed
> ...
> 2013-09-11 10:16:28.108 5326 TRACE ceilometer.alarm.threshold_evaluation File
> "/opt/stack/python-ceilometerclient/ceilometerclient/v2/statistics.py", line
> 29, in list
> 2013-09-11 10:16:28.108 5326 TRACE ceilometer.alarm.threshold_evaluation
> '/v2/meters/' + meter_name + '/statistics',
> 2013-09-11 10:16:28.108 5326 TRACE ceilometer.alarm.threshold_evaluation
> TypeError: cannot concatenate 'str' and 'NoneType' objects
>
> ceilometer-api:
> ===
> 2013-09-11 10:16:28.221 4500 ERROR wsme.api [-] Server-side error: "metaquery
> not implemented". Detail:
> Traceback (most recent call last):
>
> File "/usr/local/lib/python2.7/dist-packages/wsmeext/pecan.py", line 70, in
> callfunction
> result = f(self, *args, **kwargs)
>
> File "/opt/stack/ceilometer/ceilometer/api/controllers/v2.py", line 693, in
> statistics
> for c in computed]
>
> File "/opt/stack/ceilometer/ceilometer/storage/impl_sqlalchemy.py", line 517,
> in get_meter_statistics
> query = self._make_stats_query(sample_filter, groupby)
>
> File "/opt/stack/ceilometer/ceilometer/storage/impl_sqlalchemy.py", line 468,
> in _make_stats_query
> return make_query_from_filter(query, sample_filter)
>
> File "/opt/stack/ceilometer/ceilometer/storage/impl_sqlalchemy.py", line 137,
> in make_query_from_filter
> raise NotImplementedError('metaquery not implemented')
>
> NotImplementedError: metaquery not implemented
>
>
> Many thanks,
> -Juha
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Ceilometer/Heat in Havana]: Should autoscaling groups work already?
;, 'op': 'le'}, {'field': 'timestamp', 'value':
> '2013-09-12T11:49:31.250748', 'op': 'ge'}] _statistics
> /opt/stack/ceilometer/ceilometer/alarm/threshold_evaluation.py:120
> ...
> 2013-09-12 14:50:31.391 17868 DEBUG ceilometer.alarm.threshold_evaluation
> [-] sanitize stats [] _sanitize
> /opt/stack/ceilometer/ceilometer/alarm/threshold_evaluation.py:111
> 2013-09-12 14:50:31.395 17868 DEBUG ceilometer.alarm.threshold_evaluation
> [-] pruned statistics to 0 _sanitize
> /opt/stack/ceilometer/ceilometer/alarm/threshold_evaluation.py:115
> --clap--
>
> Br,
> -Juha
>
>
> On 12 September 2013 10:03, Eoghan Glynn wrote:
>
> >
> >
> > Hi Juha,
> >
> > The problem you're encountering is a known restriction of the sqlalchemy
> > storage
> > driver, which doesn't yet provide the capability to select the statistics
> > for the
> > given Heat autoscaling group on which the scale up/down alarms are based
> > (the so-
> > called metaquery feature).
> >
> > In order for this feature to be present in the ceilometer API service,
> > you'll need
> > to use the mongodb storage driver instead.
> >
> > Thanks,
> > Eoghan
> >
> > - Original Message -
> > > Hi,
> > >
> > > I met the problem when tried to be using autoscaling groups in heat
> > templates
> > > with havana (see:
> > > https://bugs.launchpad.net/heat/+bug/1223710 )
> > >
> > > Can anyone confirm whether the autoscaling should already work with
> > havana?
> > >
> > > Currently the evaluation of the ceilometer alarm/meter data seems to be
> > > failing:
> > >
> > >
> > >
> > > ceilometer-alarm-singleton:
> > > ==
> > > 2013-09-11 10:16:28.074 5326 INFO ceilometer.alarm.threshold_evaluation
> > [-]
> > > initiating evaluation cycle on 3 alarms
> > > 2013-09-11 10:16:28.108 5326 ERROR ceilometer.alarm.threshold_evaluation
> > [-]
> > > alarm stats retrieval failed
> > > ...
> > > 2013-09-11 10:16:28.108 5326 TRACE ceilometer.alarm.threshold_evaluation
> > File
> > > "/opt/stack/python-ceilometerclient/ceilometerclient/v2/statistics.py",
> > line
> > > 29, in list
> > > 2013-09-11 10:16:28.108 5326 TRACE ceilometer.alarm.threshold_evaluation
> > > '/v2/meters/' + meter_name + '/statistics',
> > > 2013-09-11 10:16:28.108 5326 TRACE ceilometer.alarm.threshold_evaluation
> > > TypeError: cannot concatenate 'str' and 'NoneType' objects
> > >
> > > ceilometer-api:
> > > ===
> > > 2013-09-11 10:16:28.221 4500 ERROR wsme.api [-] Server-side error:
> > "metaquery
> > > not implemented". Detail:
> > > Traceback (most recent call last):
> > >
> > > File "/usr/local/lib/python2.7/dist-packages/wsmeext/pecan.py", line 70,
> > in
> > > callfunction
> > > result = f(self, *args, **kwargs)
> > >
> > > File "/opt/stack/ceilometer/ceilometer/api/controllers/v2.py", line 693,
> > in
> > > statistics
> > > for c in computed]
> > >
> > > File "/opt/stack/ceilometer/ceilometer/storage/impl_sqlalchemy.py", line
> > 517,
> > > in get_meter_statistics
> > > query = self._make_stats_query(sample_filter, groupby)
> > >
> > > File "/opt/stack/ceilometer/ceilometer/storage/impl_sqlalchemy.py", line
> > 468,
> > > in _make_stats_query
> > > return make_query_from_filter(query, sample_filter)
> > >
> > > File "/opt/stack/ceilometer/ceilometer/storage/impl_sqlalchemy.py", line
> > 137,
> > > in make_query_from_filter
> > > raise NotImplementedError('metaquery not implemented')
> > >
> > > NotImplementedError: metaquery not implemented
> > >
> > >
> > > Many thanks,
> > > -Juha
> > >
> > > ___
> > > Mailing list:
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > > Post to : openstack@lists.openstack.org
> > > Unsubscribe :
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > >
> >
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [ceilometer] MySQL Support
Yes, via the sqlalchemy storage driver. Configure by setting: [database] connection = mysql://USERNAME:PASSWORD@HOST/ceilometer in /etc/ceilometer/ceilometer.conf. Ensure you run the ceilometer DB sync script to create the schema. Note however that the sqlalchmey driver is not as yet feature-complete. In particular, it is missing the metadata query facility required by horizon and alarming. We intend to discuss addressing this shortcoming in the HK design summit. Cheers, Eoghan - Original Message - > > > Hi, > > > > Does MySQL support exists for Ceilometer? > > > > Thanks, > > Sairam > > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Memory utilization meter from ceilometer for libvert
- Original Message - > Hey all, > > In an archived conversation > (http://www.mail-archive.com/openstack@lists.launchpad.net/msg24776.html), I > see that memory utilization meter for libvert was not available in > ceilometer and plans were to support it after a fix is available in a new > release of libvert. Does anyone know if this fix is already available in > libvert and whether ceilometer now supports memory utilization meter? I > didn't see any bug for the same as well. > > Thanks, > Piyush Hi Piyush, Ceilometer does not currently meter memory util, but we plan to add this functionality during the Icehouse cycle. It was one of the many topics discussed at the design summit last week: https://etherpad.openstack.org/p/icehouse-summit-ceilometer-future-of-alarming I intend to file blueprints this week for the design sessions I led in HK, and this requirement will be included in a "Wider variety of metrics suitable for alarming" BP. Cheers, Eoghan ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [openstack][ceilometer] Periodic checks error on Compute node with ceilometer
Hi Jean-Daniel, That doesn't look like a ceilometer issue. Rather, IIUC it's a case of the nova-compute agent reporting an issue from the nova-conductor service when it calls out to the conductor over RPC to record the beginning of a task in the task log. Interestingly, the error message seems to suggest that the nova-conductor is using sqlite: DBError SQLite DateTime type only accepts Python datetime and date objects as input. whereas the nova.conf you quote suggests that mysql is in use: connection = mysql://nova:password@infra-eval-03/nova Please check the config used by your nova-conductor service, as the same DB should be configured for the nova services across the board. Cheers, Eoghan - Original Message - > Hi stackers! > > When integrating ceilometer I experience periodic task errors on a compute > node. > I paste below my configurations, if anyone has experienced this or a clue of > what could be the cause info would be very helpful. > > The error output is: > nova-compute.log== > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task > Traceback (most recent call last): > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File > "/usr/lib/python2.7/dist-packages/nova/openstack/common/periodic_task.py", > line 180, in run_periodic_tasks > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task > task(self, context) > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File > "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 4495, in > _instance_usage_audit > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task > self.host, num_instances) > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File > "/usr/lib/python2.7/dist-packages/nova/compute/utils.py", line 372, in > start_instance_usage_audit > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task > "Instance usage audit started...") > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File > "/usr/lib/python2.7/dist-packages/nova/conductor/api.py", line 279, in > task_log_begin_task > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task > task_items, message) > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File > "/usr/lib/python2.7/dist-packages/nova/conductor/rpcapi.py", line 411, in > task_log_begin_task > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task > task_items=task_items, message=message) > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File > "/usr/lib/python2.7/dist-packages/nova/rpcclient.py", line 85, in call > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task > return self._invoke(self.proxy.call, ctxt, method, **kwargs) > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File > "/usr/lib/python2.7/dist-packages/nova/rpcclient.py", line 63, in _invoke > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task > return cast_or_call(ctxt, msg, **self.kwargs) > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File > "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/proxy.py", line > 126, in call > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task > result = rpc.call(context, real_topic, msg, timeout) > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File > "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/__init__.py", > line 139, in call > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task > return _get_impl().call(CONF, context, topic, msg, timeout) > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File > "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py", > line 816, in call > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task > rpc_amqp.get_connection_pool(conf, Connection)) > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File > "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py", line > 574, in call > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task rv = > list(rv) > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File > "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py", line > 539, in __iter__ > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task raise > result > 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task > RemoteError: Remote error: DBError SQLite DateTime type only accepts Python > datetime and date objects as input. (original cause: TypeError: SQLite > DateTime type only accepts Python datetime and date objects as input.) > 'INSERT INTO task_log (created_at, updated_at, deleted_at, deleted, > task_name, state, host
Re: [Openstack] [Ceilometer] Alarms
Hi Greg, The alarming feature of ceilometer is intended to be user-oriented, i.e. focused on the user-view of cloud resources. It is not intended to be infrastructure-oriented, i.e. focused on the operator-view of the underpinning datacenter fabric. So if understand your question correctly, the answer I thing is no, we are not addressing the ‘general’ cases you had in mind. Cheers, Eoghan - Original Message - > > > A general question about Alarms in Ceilometer … > > > > Is the intent that Ceilometer is collecting, managing & distributing > ‘general’ OpenStack Alarms ? > > · All of the documentation around Alarms in Ceilometer is about PM Threshold > Alarms; > i.e. Alarms triggered when a PM Counter crosses a specified threshold > > · But there are other types of Alarms associated with an OpenStack Cloud > > o Alarms related to equipment failures, > > o Alarms related to network failures, > > o Etc. > > · I have not seen any discussions suggesting that Ceilometer be used to > collect, manage & distribute ‘general’ OpenStack Alarms > > · The architecture for managing Alarms would be very similar to that of PMs … > > o The Ceilometer Architecture of Listener / Pollster Plugins and Publisher > Plugins applies well to general Alarm Management as well > > § i.e. Listener / Pollster Plugins for listening or monitoring fault > conditions > > § Publisher Plugins for generating the appropriate Alarms and sending to an > Alarm Collector > > § An Alarm Collector with backend plugins for Northbound Management > Interfaces (SNMP, Netconf, etc.) > > > > Comments ? > > > > > > Greg. > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] devstack log files
- Original Message - > Hi, > > > Im running devstack, but cant seem to find the log files. I cannot > find them in /opt/stack, nor in /var/log. > > Do I need to do some configuring before devstack will create log > files, or am i simply looking in the wrong location ? By default devstack uses screen logging, which you can see via: $ screen -r # navigate to the required service: ctrl+a " # enter copy-mode to page-up or search ctrl+a [ # search backward for a pattern ?pattern ... etc. If you want logging output to be preserved to a file instead, set LOGFILE in your localrc in advance of running stack.sh. For more details, see: http://devstack.org/localrc.html Cheers, Eoghan > Thanks. > > > > Regards, > > > John Smith. > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Ceilometer network and disk Mb/s measurements
Hi Nick, I'm planning to add rate-per-second meters deriving from the cumulative disk and network meters: https://blueprints.launchpad.net/ceilometer/+spec/rates-derived-from-cumulative However, the intent is to average these over the polling period, which typically would be in the range 60s to 600s, and not to incur the cost of sub-second hypervisor polling. Cheers, Eoghan - Original Message - > Hi, > > Well, that is the problem exactly - I need to get info every second to track > traffic bursts, i.e. depth of precision should be on seconds level. So, in > my case I`ll have to either poll it every second - or approximate it by > computing an average… > > Thanks a lot for your answers! > > NM > -- > Nick Maslov > Sent with Airmail > > > > On November 29, 2013 at 11:47:50 AM, Julien Danjou ( jul...@danjou.info ) > wrote: > > > On Fri, Nov 29 2013, Nick Maslov wrote: > > Hi Nick, > > > How do you think, is it a right way to meter such data with ceilometer? I > > mean, such statistics should be transferred to collector each second, and > > in > > case of >1000 VM`s can easily bring down database. How do you think? > > You don't _have to_ poll every seconds, you can poll every minute and > compute an average. That really depends on what precision you need. > > You can do the same things with the existing samples provided by > Ceilometer. > > -- > Julien Danjou > /* Free Software hacker * independent consultant > http://julien.danjou.info */ > > - signature.asc, 851 bytes > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Heat] Problems with AutoScaling
Hi Johnny (or Richard?) So the problem here doesn't seem directly related to autoscaling with ceilometer. Rather it results from the way heat only validates credentials for the created stack in certain circumstances (specifically if a ScalingPolicy, HARestarter, or WaitConditionHandle is contained in the teamplate, see [1]) So I think you've discovered that you can invoke heat stack-create without creds for simple templates, but then you're tripping over the lack of credentials when you attempt to use more advanced templates. Can you ensure that the OS_* env vars are set *before* invoking 'heat stack-create'? e.g. on devstack: $ . devstack/openrc admin admin Cheers, Eoghan [1] https://github.com/openstack/heat/commit/af238fbd - Original Message - > Hi all, > > I posted yesterday and forgot to post it in plain-text. Because of this I > wrote this one a second time, but the right way. I very much apologize!! So > here's the last post: > > I have Problems with heat and ceilometer. > > I want to autoscale with ceilometer and heat. The example in the > Heat-quick-start guide works. I used the following: > https://raw.github.com/openstack/heat-templates/master/hot/F18/WordPress_Native.yaml > > For this example, I get datas with the "ceilometer statistics -m > cpu_util"-command. > > Then I wrote my own Autoscaling-Template, which I posted here: > https://gist.github.com/anonymous/7767732[https://gist.github.com/anonymous/7767732] > > The AutoScaling-templates didn't work. I shortened my Template to find the > Problem. As I comment in the AutoScaling-Resources I get the following: > > > ERROR: Missing required credential: X-Auth-User > Traceback (most recent call last): > File "/opt/stack/heat/heat/openstack/common/rpc/amqp.py", line 461, in > _process_data > **args) > File "/opt/stack/heat/heat/openstack/common/rpc/dispatcher.py", line 172, > in dispatch > result = getattr(proxyobj, method)(ctxt, **kwargs) > File "/opt/stack/heat/heat/engine/service.py", line 60, in wrapped > return func(self, ctx, *args, **kwargs) > File "/opt/stack/heat/heat/engine/service.py", line 279, in create_stack > self._validate_deferred_auth_context(cnxt, stack) > File "/opt/stack/heat/heat/engine/service.py", line 229, in > _validate_deferred_auth_context > raise exception.MissingCredentialError(required='X-Auth-User') > MissingCredentialError: Missing required credential: X-Auth-User > > I tried the example below with AutoScaling too and get the same error: > > https://raw.github.com/openstack/heat-templates/master/cfn/F17/AutoScalingCeilometer.yaml[https://raw.github.com/openstack/heat-templates/master/cfn/F17/AutoScalingCeilometer.yaml] > > Hope you can help me. Many thanks in advance! > > Johnny > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Heat] Problems with AutoScaling
How old is your heat client? I think your issue may have been addressed by this commit from yesterday: https://github.com/openstack/python-heatclient/commit/e259163d To check, try: $ cd /opt/stack/python-heatclient ; git show e259163d # if the commit not found ... $ git fetch ; git rebase origin/master Cheers, Eoghan - Original Message - > > Hi Johnny (or Richard?) > > So the problem here doesn't seem directly related to autoscaling with > ceilometer. > > Rather it results from the way heat only validates credentials for the > created > stack in certain circumstances (specifically if a ScalingPolicy, HARestarter, > or > WaitConditionHandle is contained in the teamplate, see [1]) > > So I think you've discovered that you can invoke heat stack-create without > creds > for simple templates, but then you're tripping over the lack of credentials > when > you attempt to use more advanced templates. > > Can you ensure that the OS_* env vars are set *before* invoking 'heat > stack-create'? > > e.g. on devstack: > > $ . devstack/openrc admin admin > > Cheers, > Eoghan > > > [1] https://github.com/openstack/heat/commit/af238fbd > > - Original Message - > > Hi all, > > > > I posted yesterday and forgot to post it in plain-text. Because of this I > > wrote this one a second time, but the right way. I very much apologize!! So > > here's the last post: > > > > I have Problems with heat and ceilometer. > > > > I want to autoscale with ceilometer and heat. The example in the > > Heat-quick-start guide works. I used the following: > > https://raw.github.com/openstack/heat-templates/master/hot/F18/WordPress_Native.yaml > > > > For this example, I get datas with the "ceilometer statistics -m > > cpu_util"-command. > > > > Then I wrote my own Autoscaling-Template, which I posted here: > > https://gist.github.com/anonymous/7767732[https://gist.github.com/anonymous/7767732] > > > > The AutoScaling-templates didn't work. I shortened my Template to find the > > Problem. As I comment in the AutoScaling-Resources I get the following: > > > > > > ERROR: Missing required credential: X-Auth-User > > Traceback (most recent call last): > > File "/opt/stack/heat/heat/openstack/common/rpc/amqp.py", line 461, in > > _process_data > > **args) > > File "/opt/stack/heat/heat/openstack/common/rpc/dispatcher.py", line 172, > > in dispatch > > result = getattr(proxyobj, method)(ctxt, **kwargs) > > File "/opt/stack/heat/heat/engine/service.py", line 60, in wrapped > > return func(self, ctx, *args, **kwargs) > > File "/opt/stack/heat/heat/engine/service.py", line 279, in create_stack > > self._validate_deferred_auth_context(cnxt, stack) > > File "/opt/stack/heat/heat/engine/service.py", line 229, in > > _validate_deferred_auth_context > > raise exception.MissingCredentialError(required='X-Auth-User') > > MissingCredentialError: Missing required credential: X-Auth-User > > > > I tried the example below with AutoScaling too and get the same error: > > > > https://raw.github.com/openstack/heat-templates/master/cfn/F17/AutoScalingCeilometer.yaml[https://raw.github.com/openstack/heat-templates/master/cfn/F17/AutoScalingCeilometer.yaml] > > > > Hope you can help me. Many thanks in advance! > > > > Johnny > > > > ___ > > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > Post to : openstack@lists.openstack.org > > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Ceilometer "Authentication required" Error
- Original Message -
> Hi All,
>
> I'm trying to get Ceilometer working on OpenStack Havana (installed via
> DevStack ) but running into issues with the APIs. I believe Ceilometer is
> installed and enabled but when I hit http://[my_vm_hostname]:8777/ just like
> that or with any parameters I just get "Authentication required" back.
>
> I thought maybe this was an issue with my Keystone configuration so I tried
> following the instructions found here but whenever I try making a keystone
> call I just get "You are not authorized to perform the requested action,
> admin_required. (HTTP 403)."
>
> When I ran keystone token-get it looks like the user_id it's returning is
> implying that I'm running as the "demo" user but I don't know how to switch
> to the "admin" user.
To switch to the admin user:
unset $(env | awk -F= '/^OS_/ {print $1}')
. openrc admin admin
> Looks like the openrc file from DevStack already set
> all the necessary environment variables as far as I can tell and I've
> sourced that so should be all good there.
>
> I tried following the instructions here to create an admin user but, no
> surprise, I get the not authorized error again.
>
> Any help in this matter would be greatly appreciated, really looking forward
> to using Ceilometer!
>
> Thanks,
> Mark
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [metering] ceilometer database - mysql vs mongo
The mongodb driver is the only one in Havana that is feature complete. In particular, the metaquery feature (i.e. the ability to compose queries constrained on sample metadata) was not supported by the sqlalchemy driver in Havana. We plan to bring the sqlalchemy driver up to feature parity though during Icehouse. Cheers, Eoghan - Original Message - > Hi, > > Is there a preference why mongo is preferred than mysql for the ceilometer > production deployments ? > > In the Ceilometer Havana documentation, there was some reference to > "metadata" support available only in mongo. Can someone provide some insight > on this ? > > > Thanks, > Prashanth > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Ceilometer - info on VM creation time
The timestamp on the first instance sample recorded by the ceilometer
with give you that.
A brute-force way of retrieving it:
ceilometer sample-list -m instance -q "resource_id=$INSTANCE_ID" | grep
instance | tail -1 | awk '{printf("%s created at %s\n", $2, $(NF-1))}'
(it would be better if a reverse-timestampt ordering could be specified
via the CLI, in which case we could just limit to result set to 1).
Cheers,
Eoghan
- Original Message -
> Hi,
>
> Is it possible to get info about creation time of a particular VM via
> ceilometer? Like, this VM was created at that date.
>
> Thanks,
> NM
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Ceilometer] Ceilometer not fetching Nova Compute Notifications compute.instance.create.start/end
Hi Sravani, Here are the compute notification event types that ceilometer is actually interested in (modulo wildcard expansion): * 'compute.instance.*' * 'compute.instance.delete.samples' * 'scheduler.run_instance.scheduled' See respectively: * https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/notifications.py#L73 * https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/notifications.py#L161 * https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/notifications.py#L54 So, clearly ceilometer is only interested in a subset of these notifications, hence that's all that it processes. Cheers, Eoghan - Original Message - > Hi All, > > I'm trying to catch Nova Compute Notifications in Ceilometer > > I have Openstack installed on Ubuntu 13.04 using devstack. > > While launching an instance, Nova Compute is sending the required > notifications to notifications.info queue. > > > The same could be seen in the Nova Compute logs: > > 2013-12-03 12:19:07.617 DEBUG nova.openstack.common.rpc.amqp > [req-32a523c5-ebeb-4885-88e9-986918ab7f86 demo demo] > Sending compute.instance.create.start on notifications.info from > (pid=5418) notify > /opt/stack/nova/nova/openstack/common/rpc/amqp.py:621 > .. > > > 2013-12-03 12:19:11.313 DEBUG nova.openstack.common.rpc.amqp > [req-32a523c5-ebeb-4885-88e9-986918ab7f86 demo demo] > Sending compute.instance.create.end on notifications.info from > (pid=5418) notify > /opt/stack/nova/nova/openstack/common/rpc/amqp.py:621 > > > But the ceilometer is unable to fetch these notifications from > notifications.info. Instead it is fetching only > compute.instance.update notification. > > The same could be seen in the ceilometer-agent-notification: > > 2013-12-03 12:19:06.999 14017 DEBUG ceilometer.notification [-] > notification u'compute.instance.update' process_notification > /opt/stack/ceilometer/ceilometer/notification.py:124 > 2013-12-03 12:19:07.000 14017 AUDIT ceilometer.pipeline [-] Flush > pipeline degree.temperature.current > 2013-12-03 12:19:07.001 14017 AUDIT ceilometer.pipeline [-] Flush > pipeline meter_pipeline > 2013-12-03 12:19:07.001 14017 AUDIT ceilometer.pipeline [-] Flush > pipeline cpu_pipeline > 2013-12-03 12:19:07.001 14017 AUDIT ceilometer.pipeline [-] Flush > pipeline instance_pipeline > 2013-12-03 12:19:07.002 14017 AUDIT ceilometer.pipeline [-] Flush > pipeline degree.temperature.current > 2013-12-03 12:19:07.002 14017 AUDIT ceilometer.pipeline [-] Flush > pipeline meter_pipeline > 2013-12-03 12:19:07.002 14017 AUDIT ceilometer.pipeline [-] Flush > pipeline cpu_pipeline > 2013-12-03 12:19:07.002 14017 AUDIT ceilometer.pipeline [-] Flush > pipeline instance_pipeline > > I am facing the same issue with the below mentioned Compute notifications > too: > compute.instance.delete.start/.end > compute.instance.shutdown.start/.end > compute.instance.power_off.start/.end > > > Please find my Configuration setup in the below mentioned files: > > [nova.conf] > > firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver > compute_driver = libvirt.LibvirtDriver > libvirt_cpu_mode = none > libvirt_type = qemu > rabbit_password = root > rabbit_host = > rpc_backend = nova.openstack.common.rpc.impl_kombu > notification_driver = nova.openstack.common.notifier.rpc_notifier > notification_driver = ceilometer.compute.nova_notifier > notify_on_state_change = vm_and_task_state > notification_topics = notifications > topics = notifications > control_exchange = openstack > notify_api_faults = true > > > [ceilometer.conf] > > verbose = True > debug = True > notification_topics = notifications > rabbit_password = root > rabbit_host = > rpc_backend = ceilometer.openstack.common.rpc.impl_kombu > nova_control_exchange = nova > default_notification_level=INFO > notification_driver = nova.openstack.common.notifier.rpc_notifier > > So, what changes can be done for Ceilometer to fetch the all the > notifications which the Nova Compute sends on the notifications.info ? > > Kindly let me know if any more information is required. > > Thank You. > > Regards, > Sravani M > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Ceilometer] VM instance CPU/disk/network utilization data
Hi Mark, A common issue is a mismatch between the hostname used by nova to associate instances with hosts, and the hostname used by the ceilometer compute agent to constrain the query it uses to discover the instances running on the local host. Typically a mismatch might result from the hostname defaulting to a FQDN in the nova case, and perhaps explicitly configured as an plain hostname in the ceilometer case. In fact the default hostname used by *both* service is by design the same, socket.gethostname(), so if it's not explicitly configured for both services, it will naturally match. So check your /etc/ceilometer/ceilometer.conf for an explicit setting of the host option in the [DEFAULT] section. You can just comment that out to fall back onto the default value for the variable Cheers, Eoghan - Original Message - > I see the nova-compute service enabled and running in the Horizon > dashboard and I followed the instructions here > (http://docs.openstack.org/havana/install-guide/install/yum/content/ceilome > ter-install-nova.html) to install the Telemetry/Ceilometer compute agent > on the same node but I still don't see any of the CPU/disk/network > utilization data in the meter or resource lists (retrieved using CLI and > API queries - > http://docs.openstack.org/developer/ceilometer/webapi/v2.html#api-and-cli-q > uery-examples). > > Any ideas? Keep in mind, I am new to this and still trying to understand > how everything works together so please let me know if I'm looking in the > wrong places or not setting this up correctly. > > Thanks, > Mark > > > On 12/11/13 12:50 AM, "Julien Danjou" wrote: > > >On Wed, Dec 11 2013, Mark Vlcek (mavlcek) wrote: > > > >> How do I get CPU/disk/network utilization data? Do I need to update my > >> ceilometer.conf file or is something else not setup/running correctly? > > > >You need to run the ceilometer compute agent on each of your compute > >node. > > > >-- > >Julien Danjou > >/* Free Software hacker * independent consultant > > http://julien.danjou.info */ > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Heat] Ceilometer with Multi-Node
You appear to be missing the following line from each of your alarm resource definitions in the Heat template: repeat_actions: True (this is required for the Heat autoscaling cooldown logic to work) On the second compute node, do you actually have any nova instances running there? Cheers, Eoghan - Original Message - > Hi all, > > I want to autoscale with ceilometer and heat in devstack. The > Single-Node-Configuration works. But now I want to configure for Multi-Node. > > Here is the localrc of the controller-node: > https://gist.github.com/anonymous/8006733 > > And here is the localrc of the compute-node: > https://gist.github.com/anonymous/8006723 > > At the Hypervisor-tab in horizon I can see both servers. With the "ceilometer > statistics -m cpu_util -p 30" I am getting only the values of the VM at the > controller-node, I guess. I tried it with different "DesiredCapacity" > (3,5,7) in my template and saw, that in the "count"-column the value is > everytime the same as the amount of used Virtual CPUs at the > controller-node. > Furthermore did the scaling not work. I used the cpu_util-metric and > stress-program at the VMs. The initial capacity were created, but the > scaling did not work. Probably the two problems stick together, don't they? > :) > > Here is the template: > https://gist.github.com/anonymous/8009540 > > Did I forget a service to enable at the compute-node? I used the > devstack-multinode-guide from devstack.org and the manual of openstack > (install the orchestration/telemetry service). > > Many thanks in advance! > > Johnny > > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Fw: Aw: Re: [Heat] Ceilometer with Multi-Node
- Original Message - > Thanks for your help. > Now I added to the template: > repeat_actions: True > > I omitted it, because I read in the guide: > Optional property, defaults to “true”. Can you provide a link to that docco, because it seems wrong and potentially very misleading. So we need to open an LP docco bug and get that fixed ASAP. > With repeat_actions it scals, but only at the base of the instances running > at the controller (probably). OK. > Did you mean the controller node, because you wrote the second compute node? > If I create f. e. 5 instances, these are in running-state. > At the Hypervisor-Tab I can see f. e. 3 VCPUs(used) at the controller and 2 > at the compute-node. > But in the statistics the count value is exact the same of the VCPUs at the > controller. Sounds like the ceilometer compute agent on the compute-node is not publishing cpu_util metrics for the local instances. Can you set debug=True in /etc/ceilometer/ceilometer.conf, restart the compute agent and check the compute agent log for errors etc? > Cheers, > Johnny > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Ceilometer] Meter statistics with period parameter
Hi Mark, It's my-meter-name as opposed to my-meter-id, but something like the following should work: http://host:8777/v2/meters/cpu_util/statistics?period=60 What version are you using? Cheers, Eoghan - Original Message - > Hi all, > > I notice in the Ceilometer V2 web API that it's possible to set a period for > meter statistics but I don't quite understand the format of how to do so. In > the functional examples section it says to pass URL parameters, but when I > send a GET to > > http://my-vm-hostname:8777/v2/meters/my-meter-id/statistics?period=3600 > > I get an error that contains faultstring": "unsupported operand type(s) for > -: 'NoneType' and 'NoneType'" > > Can somebody point me to what I'm doing wrong? > > Thanks, > Mark > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Ceilometer meter list not showing all meters
Hi Swapnil, The key distinction between the compute meters you're seeing and the ones that are absent is that the latter are derived from notifications emitted by nova, whereas the former are generated via polling of the hypervisor. I suspect the reason you're not seeing the notification-driven meters is a side-effect of the recent split-off of the notification agent from the collector service: https://blueprints.launchpad.net/ceilometer/+spec/split-collector Is your devstack clone sufficiently recent to include the following commit? https://github.com/openstack-dev/devstack/commit/1c402286 If not, you'll need to fetch and rebase your devstack. If so, please also check that your localrc includes ceilometer-anotification in the enabled services, e.g. grep 'enable_service .*ceilometer-anotification' devstack/localrc Cheers, Eoghan - Original Message - > > > Hi, > > > > I have the latest openstack deployed(through devstack) with Ceilometer > (ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api) > installed. > > > > from the meter list i am getting only the following meters data. > > > > cpu, cpu_util, disk.read.bytes, disk.read.requests, disk.write.bytes, > disk.write.requests, instance, instance:m1.nano, network.incoming.bytes, > network.incoming.packets, network.outgoing.bytes, network.outgoing.packets > > > > What about the rest of the meters like ram,vcpus,etc as mentioned in this > url: http://docs.openstack.org/developer/ceilometer/measurements.html > > > > I referred the following web pages for additional configurations required : > http://docs.openstack.org/developer/ceilometer/configuration.html > > http://docs.openstack.org/developer/ceilometer/install/manual.html#installing-manually > > > > I have also asked it on Launchpad: > https://answers.launchpad.net/ceilometer/+question/241511 > > > > Why i am not able to get other meters data? > > > > > > Regards, > > Swapnil > > > DISCLAIMER == This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Ceilometer - Formulas From low level metrics to QoS
Hi Rima, What precisely do you mean by QoS values? Are you talking about the responsiveness of an API service? That is not something that you can directly derive from the instance-level metrics such as CPU util & network IOPs that ceilometer collects. Cheers, Eoghan - Original Message - > Hello everyone, > > Please what are the formulas which can do the mappings from low levels > metrics ( extracted from ceilometer ) to the QoS values. > I know how to calculate the response time of a service from the values > bandwith , inbytes .. > > Are you aware of other formulas for other values of QoS . > > Thank you > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Ceilometer meter list not showing all meters
- Original Message - > Hi Glynn, > > I`m having similar issues with Havana release. Can I use your advices on > full-blown OpenStack, or they are strictly DevStack ones? The point I made about the split collector service only applies to post-Havana, e.g. an Icehouse-1 install, but not to a pure Havana-based install. Cheers, Eoghan > Thanks, > NM > > -- > Nick Maslov > Sent with Airmail > > On January 2, 2014 at 5:35:19 PM, Eoghan Glynn (egl...@redhat.com) wrote: > > > Hi Swapnil, > > The key distinction between the compute meters you're seeing and > the ones that are absent is that the latter are derived from notifications > emitted by nova, whereas the former are generated via polling of the > hypervisor. > > I suspect the reason you're not seeing the notification-driven meters > is a side-effect of the recent split-off of the notification agent from > the collector service: > > https://blueprints.launchpad.net/ceilometer/+spec/split-collector > > Is your devstack clone sufficiently recent to include the following > commit? > > https://github.com/openstack-dev/devstack/commit/1c402286 > > If not, you'll need to fetch and rebase your devstack. > > If so, please also check that your localrc includes ceilometer-anotification > in the enabled services, e.g. > > grep 'enable_service .*ceilometer-anotification' devstack/localrc > > Cheers, > Eoghan > > > > - Original Message - > > > > > > Hi, > > > > > > > > I have the latest openstack deployed(through devstack) with Ceilometer > > (ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api) > > installed. > > > > > > > > from the meter list i am getting only the following meters data. > > > > > > > > cpu, cpu_util, disk.read.bytes, disk.read.requests, disk.write.bytes, > > disk.write.requests, instance, instance:m1.nano, network.incoming.bytes, > > network.incoming.packets, network.outgoing.bytes, network.outgoing.packets > > > > > > > > What about the rest of the meters like ram,vcpus,etc as mentioned in this > > url: http://docs.openstack.org/developer/ceilometer/measurements.html > > > > > > > > I referred the following web pages for additional configurations required : > > http://docs.openstack.org/developer/ceilometer/configuration.html > > > > http://docs.openstack.org/developer/ceilometer/install/manual.html#installing-manually > > > > > > > > I have also asked it on Launchpad: > > https://answers.launchpad.net/ceilometer/+question/241511 > > > > > > > > Why i am not able to get other meters data? > > > > > > > > > > > > Regards, > > > > Swapnil > > > > > > DISCLAIMER == This e-mail may contain privileged and confidential > > information which is the property of Persistent Systems Ltd. It is intended > > only for the use of the individual or entity to which it is addressed. If > > you are not the intended recipient, you are not authorized to read, retain, > > copy, print, distribute or use this message. If you have received this > > communication in error, please notify the sender and delete all copies of > > this message. Persistent Systems Ltd. does not accept any liability for > > virus infected mails. > > > > ___ > > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > Post to : openstack@lists.openstack.org > > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Heat/Ceilometer/Havana]: Auto scaling no longer occurring after some time
Hi Juha,
Are you using Havana?
If so, your alarm resource templates seem to be missing setting the
"repeat_actions" attribute to true. Continuous notification was required
in order for the Heat autoscaling cooldown logic (and continued scaling
actions) to work.
This was a quirk of the Heat implementation in Havan, but TBH from a
usability PoV should have always had this set to True by default. This
is fixed now on Heat:master:
https://github.com/openstack/heat/commit/4dc987ef
but hasn't been backported to Heat:stable/stable.
The issue you see with the instance.scheduled message being rejected with
"signature invalid" is not related to autoscaling, and in case I've fixed
it in Ceilometer:master and stable/havana:
https://bugs.launchpad.net/ceilometer/+bug/1262255
released in:
https://launchpad.net/ceilometer/+milestone/2013.2.2
The issue you see with mongo complaining that a metering message is not
okForStorage is generally caused by a stray period ('.') in some resource
metadata key.
Where the metadata is prefixed by 'metering.', then the periods are
mapped to underscores, so in your case:
{ "Key" : "metering.server_group", "Value" : "Group_A" },
^^
that mapping should have occurred. In any case, I'd be interested in hearing
which actual metering messages are being rejected with not okForStorage.
Thanks,
Eoghan
> Hi,
>
> I'm having some problems concerning auto scaling feature.
> Any ideas?
>
> First scaling up and down is working just fine. But then when tested later on
> scaling down/up is no longer working properly.
> Scaling down may occur even it shouldn't or scaling up doesn't occur even it
> should. When in this situation I remove all the
> received metric data from the DB, auto scaling starts to work again.
>
> Ceilometer is configured to use Mongo and the auto scaling is based on the
> cpu_util metrics.
>
> Related configurations:
> ---
> /etc/ceilometer/pipeline.yaml on compute nodes:
>
> name: cpu_pipeline
> interval: 15
>
> /etc/ceilometer/ceilometer.conf on controller:
> evaluation_interval=15
>
> Heat template used:
> ---
> "Resources" : {
>
> "Group_A" : {
> "Type" : "AWS::AutoScaling::AutoScalingGroup",
> "Properties" : {
> "AvailabilityZones" : { "Fn::GetAZs" : ""},
> "LaunchConfigurationName" : { "Ref" : "Group_A_Config" },
> "MinSize" : "1",
> "MaxSize" : "3",
> "Tags" : [
> { "Key" : "metering.server_group", "Value" : "Group_A" },
> { "Key" : "custom_metadata", "Value" : "test" }
> ],
> "VPCZoneIdentifier" : [ { "Ref" : "PrivateSubnetId" } ]
> }
> },
>
> "Group_A_Config" : {
> "Type" : "AWS::AutoScaling::LaunchConfiguration",
> "Properties": {
> "ImageId" : { "Ref" : "ImageId" },
> "InstanceType" : { "Ref" : "InstanceType" },
> "KeyName" : { "Ref" : "KeyName" }
> }
> },
>
> "ScaleUpPolicy" : {
> "Type" : "AWS::AutoScaling::ScalingPolicy",
> "Properties" : {
> "AdjustmentType" : "ChangeInCapacity",
> "AutoScalingGroupName" : { "Ref" : "Group_A" },
> "Cooldown" : "20",
> "ScalingAdjustment" : "1"
> }
> },
>
> "ScaleDownPolicy" : {
> "Type" : "AWS::AutoScaling::ScalingPolicy",
> "Properties" : {
> "AdjustmentType" : "ChangeInCapacity",
> "AutoScalingGroupName" : { "Ref" : "Group_A" },
> "Cooldown" : "20",
> "ScalingAdjustment" : "-1"
> }
> },
>
> "CPUAlarmHigh": {
> "Type": "OS::Ceilometer::Alarm",
> "Properties": {
> "description": "Scale-up if CPU is greater than 90% for 20 seconds",
> "meter_name": "cpu_util",
> "statistic": "avg",
> "period": "20",
> "evaluation_periods": "1",
> "threshold": "90",
> "alarm_actions":
> [ {"Fn::GetAtt": ["ScaleUpPolicy", "AlarmUrl"]} ],
> "matching_metadata":
> {"metadata.user_metadata.server_group": "Group_A" },
> "comparison_operator": "gt"
> }
> },
>
> "CPUAlarmLow": {
> "Type": "OS::Ceilometer::Alarm",
> "Properties": {
> "description": "Scale-down if CPU is less than 50% for 20 seconds",
> "meter_name": "cpu_util",
> "statistic": "avg",
> "period": "20",
> "evaluation_periods": "1",
> "threshold": "50",
> "alarm_actions":
> [ {"Fn::GetAtt": ["ScaleDownPolicy", "AlarmUrl"]} ],
> "matching_metadata":
> {"metadata.user_metadata.server_group": "Group_A" },
> "comparison_operator": "lt"
> }
>
> In ceilometer logs I can see the following kind of warnings:
>
> <44>Feb 24 08:41:08 node-16
> ceilometer-ceilometer.collector.dispatcher.database WARNING: message
> signature invalid, discarding message: {u'counter_name':
> u'instance.scheduled', u'user_id': None, u'message_signature':
> u'd1b49ddf004edc5b7a8dc9405b42a71f2ae975d04c25838c3dc0ea0e6f6e4edd',
> u'timestamp': u'2014-02-24 08:41:08.334580', u'resource_id':
> u'48c815ab-01c9-4ac8-9096-ac171976598c', u'message_id':
> u'67e611e4-9d2f-11e3-81f1-080027e519cb', u'source': u'openstack',
> u'counter_unit': u'instance', u'counter_volume': 1, u'project_id':
> u'efcca4ba425c4beda73eb31a54df931a', u'resource_metadata': {u'instance_id':
> u'48c815ab-01c9-4ac8-9096-ac171976598c', u'weighted_host': {u'host':
> u'node-18',
Re: [Openstack] [Heat/Ceilometer/Havana]: Auto scaling no longer occurring after some time
f24fb107d548b26',
> u'resource_metadata': {u'state_description': u'', u'event_type':
> u'compute.instance.exists', u'availability_zone': None, u'terminated_at':
> u'', u'ephemeral_gb': 0, u'instance_type_id': 2, u'bandwidth': {},
> u'deleted_at': u'', u'reservation_id': u'r-hu2pxg8f', u'instance_id':
> u'5c85465e-f685-46b6-b32a-71a7e3bbbddd', u'user_id':
> u'ef4e983291ef4ad1b88eb1f776bd52b6', u'hostname':
> u'tyky-group-a-wste7bd63rkl-group-a-0-2kuqkcywx6ti', u'state': u'active',
> u'launched_at': u'2014-02-24T11:23:21.00', u'metadata':
> [{u'instance_uuid': u'5c85465e-f685-46b6-b32a-71a7e3bbbddd', u'deleted': 0,
> u'created_at': u'2014-02-24T11:23:13.00', u'updated_at': None,
> u'value': u'Group_A', u'key': u'metering.server_group', u'deleted_at':
> None, u'id': 170}, {u'instance_uuid':
> u'5c85465e-f685-46b6-b32a-71a7e3bbbddd', u'deleted': 0, u'created_at':
> u'2014-02-24T11:23:13.00', u'updated_at': None, u'value':
> u'tyky-Group_A-wste7bd63rkl', u'key': u'AutoScalingGroupName',
> u'deleted_at': None, u'id': 171}, {u'instance_uuid':
> u'5c85465e-f685-46b6-b32a-71a7e3bbbddd', u'deleted': 0, u'created_at':
> u'2014-02-24T11:23:13.00', u'updated_at': None, u'value': u'true',
> u'key': u'assign_floating_ip', u'deleted_at': None, u'id': 172}], u'node':
> u'node-18', u'ramdisk_id': u'', u'access_ip_v6': None, u'disk_gb': 1,
> u'access_ip_v4': None, u'kernel_id': u'', u'host': u'conductor.node-16',
> u'display_name': u'tyky-Group_A-wste7bd63rkl-Group_A-0-2kuqkcywx6ti',
> u'image_ref_url': u'
> http://192.168.100.3:9292/images/11848cbf-a428-4dfb-8818-2f0a981f540b',
> u'audit_period_beginning': u'2014-01-01 00:00:00', u'root_gb': 1,
> u'tenant_id': u'efcca4ba425c4beda73eb31a54df931a', u'created_at':
> u'2014-02-24T11:23:13.00', u'memory_mb': 512, u'instance_type':
> u'm1.tiny', u'vcpus': 1, u'image_meta': {u'min_disk': u'1',
> u'container_format': u'bare', u'min_ram': u'0', u'disk_format': u'qcow2',
> u'base_image_ref': u'11848cbf-a428-4dfb-8818-2f0a981f540b'},
> u'architecture': None, u'audit_period_ending': u'2014-02-01 00:00:00',
> u'os_type': None, u'instance_flavor_id': u'1'}, u'source': u'openstack',
> u'counter_unit': u'instance', u'counter_volume': 1, u'project_id':
> u'efcca4ba425c4beda73eb31a54df931a', u'message_id':
> u'30af474c-9d4b-11e3-b0e0-080027e519cb', u'counter_type': u'gauge'}]},
> u'_context_auth_token': '', u'_context_show_deleted': False,
> u'_context_tenant': None, u'_unique_id':
> u'6d1b3d50a1344561abd0b18ed91c0415', u'_context_is_admin': True,
> u'version': u'1.0', u'_context_read_only': False, u'_context_user': None,
> u'method': u'record_metering_data'}
> <47>Feb 24 12:00:01 node-16
> ceilometer-ceilometer.openstack.common.rpc.amqp DEBUG: unpacked
> context: {'read_only': False, 'show_deleted': False, 'auth_token':
> '', 'is_admin': True, 'user': None, 'request_id':
> u'req-5543e2de-cc1d-48d0-975c-62e103d17498', 'tenant': None}
> <47>Feb 24 12:00:01 node-16
> ceilometer-ceilometer.collector.dispatcher.database DEBUG: metering
> data instance for 5c85465e-f685-46b6-b32a-71a7e3bbbddd @ 2014-02-24
> 12:00:01.598433: 1
> <47>Feb 24 12:00:01 node-16 ceilometer-amqp DEBUG: Channel open
> <44>Feb 24 12:00:01 node-16 ceilometer-ceilometer.publisher.rpc AUDIT:
> Publishing 1 samples on metering
> <47>Feb 24 12:00:01 node-16
> ceilometer-ceilometer.openstack.common.rpc.amqp DEBUG: Making
> asynchronous cast on metering...
>
Re: [Openstack] [Heat/Ceilometer/Havana]: Auto scaling no longer occurring after some time
Juha,
What is the actual cpu_util trend looking like about the time
upscaling occurs?
In the original template you provided, the cooldown period was set
so as to be quite short (IIRC, 20s).
So if your artificial load on the first instance drives the cpu_util
above the high-water-mark alarm threshold, e.g. to say 91%, then the
newly launched instance has little load to contend with, giving an
average cpu_util of the instance group of ~46%, then the continual
scale-up/scale-down thrashing that you see is just autoscaling doing
exactly what you've told it to do.
To avoid this, you'll need to:
* ensure that the "load" is spread across the current instance group
members in a roughly fair distribution (this is often achieved in
practice using a load balancer randomizing or round-robining)
* increase the cooldown period to allow the load distribution to
"settle" after a scaling operation has taken place
* ensure that the low-water-mark alarm threshold is sufficiently
distant from that of the high-water-mark alarm
Cheers,
Eoghan
- Original Message -
> Hi,
>
> Some update... I yesterday added "repeat_actions" : true -definition to
> OS::Ceilometer::Alarm resources in the Heat template:
>
> "CPUAlarmHigh": {
> "Type": "OS::Ceilometer::Alarm",
> "Properties": {
> "description": "Scale-up if CPU is greater than 90% for 30 seconds",
> "meter_name": "cpu_util",
> "statistic": "avg",
> "period": "30",
> "evaluation_periods": "1",
> "threshold": "90",
> "alarm_actions":
> [ {"Fn::GetAtt": ["ScaleUpPolicy", "AlarmUrl"]} ],
> "matching_metadata":
> {"metadata.user_metadata.server_group": "Group_A" },
> "comparison_operator": "gt",
> "repeat_actions" : true
> }
> },
>
> "CPUAlarmLow": {
> "Type": "OS::Ceilometer::Alarm",
> "Properties": {
> "description": "Scale-down if CPU is less than 50% for 30 seconds",
> "meter_name": "cpu_util",
> "statistic": "avg",
> "period": "30",
> "evaluation_periods": "1",
> "threshold": "50",
> "alarm_actions":
> [ {"Fn::GetAtt": ["ScaleDownPolicy", "AlarmUrl"]} ],
> "matching_metadata":
> {"metadata.user_metadata.server_group": "Group_A" },
> "comparison_operator": "lt",
> "repeat_actions" : true
> }
> }
>
> ...and everything seemed to work fine. But now I just created a stack again
> and generated some load inside the first VM started. Scaling up occurred,
> but after that the system is now continuously scaling up and down the VMs
> even the load situation doesn't change. Seems to be the "repeat_actions"
> definitions didn't help after all...
>
> Br,
> -Juha
>
>
> On 25 February 2014 00:27, Steven Dake < sd...@redhat.com > wrote:
>
>
>
> Juha,
>
> Copying Angus so he sees. He wrote a big majority of the ceilometer + heat
> integration and might have a better idea of the details of the problem you
> face.
>
>
> On 02/24/2014 01:27 AM, Juha Tynninen wrote:
>
>
>
> Hi,
>
> I'm having some problems concerning auto scaling feature.
> Any ideas?
>
> First scaling up and down is working just fine. But then when tested later on
> scaling down/up is no longer working properly.
> Scaling down may occur even it shouldn't or scaling up doesn't occur even it
> should. When in this situation I remove all the
> received metric data from the DB, auto scaling starts to work again.
>
> Ceilometer is configured to use Mongo and the auto scaling is based on the
> cpu_util metrics.
>
> Related configurations:
> ---
> /etc/ceilometer/pipeline.yaml on compute nodes:
>
> name: cpu_pipeline
> interval: 15
>
> /etc/ceilometer/ceilometer.conf on controller:
> evaluation_interval=15
>
> Heat template used:
> ---
> "Resources" : {
>
> "Group_A" : {
> "Type" : "AWS::AutoScaling::AutoScalingGroup",
> "Properties" : {
> "AvailabilityZones" : { "Fn::GetAZs" : ""},
> "LaunchConfigurationName" : { "Ref" : "Group_A_Config" },
> "MinSize" : "1",
> "MaxSize" : "3",
> "Tags" : [
> { "Key" : "metering.server_group", "Value" : "Group_A" },
> { "Key" : "custom_metadata", "Value" : "test" }
> ],
> "VPCZoneIdentifier" : [ { "Ref" : "PrivateSubnetId" } ]
> }
> },
>
> "Group_A_Config" : {
> "Type" : "AWS::AutoScaling::LaunchConfiguration",
> "Properties": {
> "ImageId" : { "Ref" : "ImageId" },
> "InstanceType" : { "Ref" : "InstanceType" },
> "KeyName" : { "Ref" : "KeyName" }
> }
> },
>
> "ScaleUpPolicy" : {
> "Type" : "AWS::AutoScaling::ScalingPolicy",
> "Properties" : {
> "AdjustmentType" : "ChangeInCapacity",
> "AutoScalingGroupName" : { "Ref" : "Group_A" },
> "Cooldown" : "20",
> "ScalingAdjustment" : "1"
> }
> },
>
> "ScaleDownPolicy" : {
> "Type" : "AWS::AutoScaling::ScalingPolicy",
> "Properties" : {
> "AdjustmentType" : "ChangeInCapacity",
> "AutoScalingGroupName" : { "Ref" : "Group_A" },
> "Cooldown" : "20",
> "ScalingAdjustment" : "-1"
> }
> },
>
> "CPUAlarmHigh": {
> "Type": "OS::Ceilometer::Alarm",
> "Properties": {
> "description": "Scale-up if CPU is greater than 90% for 20 seconds",
> "meter_name": "cpu_util",
> "statistic": "avg",
> "
Re: [Openstack] [Heat/Ceilometer/Havana]: Auto scaling no longer occurring after some time
246-8099-e558858d2cf4 | cpu_util | gauge | 18.87 |
> % | 2014-02-25T11:17:51 |
> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 18.33 |
> % | 2014-02-25T11:18:06 |
> Group_A-2:
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.53 |
> % | 2014-02-25T11:11:41 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.33 |
> % | 2014-02-25T11:11:56 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.53 |
> % | 2014-02-25T11:12:11 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.6 | % |
> 2014-02-25T11:12:26 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.8 | % |
> 2014-02-25T11:12:41 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.73 |
> % | 2014-02-25T11:12:56 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.07 |
> % | 2014-02-25T11:13:11 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.73 |
> % | 2014-02-25T11:13:26 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.6 | % |
> 2014-02-25T11:13:41 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.67 |
> % | 2014-02-25T11:13:56 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.27 |
> % | 2014-02-25T11:14:11 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.33 |
> % | 2014-02-25T11:14:26 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.33 |
> % | 2014-02-25T11:14:41 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.87 |
> % | 2014-02-25T11:14:56 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.73 |
> % | 2014-02-25T11:15:11 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.375 | % |
> 2014-02-25T11:15:27 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.0 | % |
> 2014-02-25T11:15:42 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.53 |
> % | 2014-02-25T11:15:57 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.53 |
> % | 2014-02-25T11:16:12 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.53 |
> % | 2014-02-25T11:16:27 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.33 |
> % | 2014-02-25T11:16:42 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.53 |
> % | 2014-02-25T11:16:57 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.87 |
> % | 2014-02-25T11:17:12 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.6 | % |
> 2014-02-25T11:17:27 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.47 |
> % | 2014-02-25T11:17:42 |
> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.53 |
> % | 2014-02-25T11:17:57 |
> Br,
> -Juha
>
>
>
>
> On 25 February 2014 11:22, Eoghan Glynn wrote:
>
> >
> > Juha,
> >
> > What is the actual cpu_util trend looking like about the time
> > upscaling occurs?
> >
> > In the original template you provided, the cooldown period was set
> > so as to be quite short (IIRC, 20s).
> >
> > So if your artificial load on the first instance drives the cpu_util
> > above the high-water-mark alarm threshold, e.g. to say 91%, then the
> > newly launched instance has little load to contend with, giving an
> > average cpu_util of the instance group of ~46%, then the continual
> > scale-up/scale-down thrashing that you see is just autoscaling doing
> > exactly what you've told it to do.
> >
> > To avoid this, you'll need to:
> >
> > * ensure that the "load" is spread across the current instance group
> > members in a roughly fair distribution (this is often achieved in
> > practice using a load balancer randomizing or round-robining)
> >
> > * increase the cooldown period to allow the load distribution to
> > "settle" after a scaling operation has taken place
> >
> > * ensure that the low-water-mark alarm threshold is sufficiently
> > distant from that of the high-water-mark alarm
> >
> > Cheers,
> > Eoghan
> >
> > - Original Message -
> > > Hi,
> > >
> > > Some update... I yesterday added "repeat_actions" : true -definition to
> > > OS::Ceilometer::Alarm resources in the Heat template:
> > >
> > > "CPUAlarmHigh": {
> > > "Type": "OS::Ceilometer::Alarm",
> > > "Properties": {
> > > "desc
Re: [Openstack] [Heat/Ceilometer/Havana]: Auto scaling no longer occurring after some time
:10:58 | 4 | 17.0 > | 120.86667 | 274.9 | 68.73 | 20.0 | > 2014-02-25T11:10:36 | 2014-02-25T11:10:56 | > | 30 | 2014-02-25T11:10:58 | 2014-02-25T11:11:28 | 4 | > 16.33 | 109.7 | 234.46667 | 58.616667 | 20.0 | > 2014-02-25T11:11:06 | 2014-02-25T11:11:26 | > | 30 | 2014-02-25T11:11:28 | 2014-02-25T11:11:58 | 6 | > 13.53 | 107.4 | 280.1 | 46.69 | 20.0 | > 2014-02-25T11:11:36 | 2014-02-25T11:11:56 | > | 30 | 2014-02-25T11:11:58 | 2014-02-25T11:12:28 | 6 | > 14.53 | 107.4 | 275.0 | 45.83 | 20.0 | > 2014-02-25T11:12:06 | 2014-02-25T11:12:26 | > | 30 | 2014-02-25T11:12:28 | 2014-02-25T11:12:58 | 6 | > 13.73 | 107.26667 | 278.2 | 46.37 | 20.0 | > 2014-02-25T11:12:36 | 2014-02-25T11:12:56 | > | 30 | 2014-02-25T11:12:58 | 2014-02-25T11:13:28 | 6 | > 13.07 | 107.46667 | 277.7 | 46.28 | 20.0 | > 2014-02-25T11:13:06 | 2014-02-25T11:13:26 | > | 30 | 2014-02-25T11:13:28 | 2014-02-25T11:13:58 | 6 | 13.6 > | 106.86667 | 269.12917 | 44.854861 | 21.0 | > 2014-02-25T11:13:36 | 2014-02-25T11:13:57 | > | 30 | 2014-02-25T11:13:58 | 2014-02-25T11:14:28 | 6 | > 14.27 | 113.928571429 | 276.286904762 | 46.0478174603 | 21.0 | > 2014-02-25T11:14:06 | 2014-02-25T11:14:27 | > | 30 | 2014-02-25T11:14:28 | 2014-02-25T11:14:58 | 6 | > 13.33 | 116.0 | 280.2125 | 46.702083 | 21.0 | > 2014-02-25T11:14:36 | 2014-02-25T11:14:57 | > | 30 | 2014-02-25T11:14:58 | 2014-02-25T11:15:28 | 6 | > 13.73 | 108.1 | 279.70833 | 46.618056 | 21.0 | > 2014-02-25T11:15:06 | 2014-02-25T11:15:27 | > | 30 | 2014-02-25T11:15:28 | 2014-02-25T11:15:58 | 6 | > 13.53 | 108.7 | 278.86667 | 46.48 | 21.0 | > 2014-02-25T11:15:36 | 2014-02-25T11:15:57 | > | 30 | 2014-02-25T11:15:58 | 2014-02-25T11:16:28 | 6 | > 13.53 | 106.46667 | 276.9 | 46.16 | 21.0 | > 2014-02-25T11:16:06 | 2014-02-25T11:16:27 | > | 30 | 2014-02-25T11:16:28 | 2014-02-25T11:16:58 | 6 | > 13.33 | 106.46667 | 276.8 | 46.13 | 21.0 | > 2014-02-25T11:16:36 | 2014-02-25T11:16:57 | > | 30 | 2014-02-25T11:16:58 | 2014-02-25T11:17:28 | 6 | > 13.87 | 105.7 | 277.7 | 46.28 | 21.0 | > 2014-02-25T11:17:06 | 2014-02-25T11:17:27 | > | 30 | 2014-02-25T11:17:28 | 2014-02-25T11:17:58 | 6 | > 13.53 | 106.9 | 277.7 | 46.28 | 21.0 | > 2014-02-25T11:17:36 | 2014-02-25T11:17:57 | > ... > > Br, > -Juha > > > On 25 February 2014 13:53, Eoghan Glynn wrote: > > > > > Juha, > > > > What are the actual average cpu_util stats for those periods > > in which scaling occurred or did not occur contrary to your > > expectations? > > > > I mean, as reported by the ceilometer API, as opposed to being > > totted up manually: > > > > $ ceilometer statistics -m cpu_util -q > > metadata.user_metadata.server_group=GroupA -p 30 > > > > Cheers, > > Eoghan > > > > - Original Message - > > > Hi, > > > > > > Many thanks again. > > > > > > I fine tuned a little bit the heat template having now defined: > > > > > > Scale up: period 30, threshold 90, comparison_operator gt, statistic avg, > > > cooldown 60 > > > Scale down: period 30, threshold 30, comparison_operator lt, statistic > > avg, > > > cooldown 60 > > > > > > Workflow: > > > - create stack -> GroupA-0 instance is started > > > - generate load inside GroupA-0 -> cpu_util counter increses to >100% > > > - Group_A-1 instance gets automatically started and after a short while > > > also Group_A-2 > > > - Situation remains the same, 3 instances keep on running, no down > > scaling > > > occurs. > > > > > > According to current thresholds down scaling shouldn't occur any longer > > > since: > > > 106.9 + 18.33 + 13.53 = ~139. And 139 / 3 = 46 > > > > > > ...but I don't now see why the Group_A-2 was started in the first place. > > > > > > cpu_util counters received: > > > > > > Group_A-0: > > > | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | > > 34.27 | > > > % | 2014-02-25T11:05:56 | > > > | a7e07a40-45fe-48d2-81c5-4124
Re: [Openstack] [Heat/Ceilometer/Havana]: Auto scaling no longer occurring after some time
> Hi, > > >>>>The simplest explanation is that you're seeing a slight offset > >>>>between the cadence of cpu_util gathering (15s) and the less rapid > >>>>alarm evaluation interval (30s, right?). > > You mean evaluation_interval in ceilometer.conf? Yes, in the alarm section of the /etc/ceilometer/ceilometer.conf: [alarm] evaluation_interval = 15 > That's set to 15. So as an > summary different periods currently in use: > > ceilometer.conf in controller: > - evaluation_interval=15 OK, I thought that was 30s from your earlier mails. No matter, an offset effect (albeit smaller) can still occur. > pipeline.yaml on compute nodes: > - name: cpu_pipeline > interval: 15 > > OS::Ceilometer::Alarm > - period 30, evaluation periods 1 So every 15s, the alarm is evaluated with a sliding time window of 30s into the past. So a time T, the alarm evaluator looks at the statistics over the duration: (T-30s,T) then 15s later, it looks at: (T-15s,T+15s) then a further 15s later: (T,T+30s) etc. > AWS::AutoScaling::ScalingPolicy > - Cooldown: 60 > > I'm still a little bit lost what kind of side effects these different > periods may have with each other. > But would you have any suggestions how I could fine tune my values so that > I would eliminate the If the semantics of Heat autoscaling cooldown are identical to the analogous AWS concept (i.e. the period after a scaling activity ends and before another scaling activity can start) then simply increasing the cooldown period will have the effect you seek (i.e. the avoidance of the second questionable scale-up action with the launch of instance GroupA-2). > possibility of extra instances to be started or that bumping the instance > count continuously up and down occurs. > I'm just trying to get upscaling /downscaling to occur in a controlled > manner (fast if possible). > > Also one other question: When you check the stats with... > ceilometer statistics -m cpu_util -q > metadata.user_metadata.server_group=Group_A -p 30 > ...command, with what value should -p match to? The period in > OS::Ceilometer::Alarm resource? Yes, as the intent is to replicate the stats query issued by the alarm alarm evaluator. > >>> $ ceilometer alarm-list | grep GroupA > >>> $ ceilometer alarm-history -a $ALARM_ID > > I must have some older ceilometer client installed, mine doesn't know > alarm-history options. Alarm history has been supported by the client since 1.0.6: https://pypi.python.org/pypi/python-ceilometerclient/1.0.6 > Also alarm-list output doesn't have Group name in its output. Can you copy the alarm-list output (after you upgrade your CLI). /Eoghan > Thanks again. I really appreciate all your help. > > Br, > -Juha > > > On 25 February 2014 15:22, Eoghan Glynn wrote: > > > > > K, eglynn deploys Occam's razor ... > > > > The simplest explanation is that you're seeing a slight offset > > between the cadence of cpu_util gathering (15s) and the less rapid > > alarm evaluation interval (30s, right?). > > > > These periods are not in lock-step. > > > > Let's interleave the statistics with the instance launch times: > > > > | 30 | 2014-02-25T11:09:28 | 2014-02-25T11:09:58 | 2 | > > 118.3 | 120.1 | 238.46667 | 119.2 | 15.0 | > > 2014-02-25T11:09:41 | 2014-02-25T11:09:56 | > > > > Group_A-1: 2014-02-25T11:09:57.00 > > Should it have occurred: yes > > The average is 119.2, calculated from two samples from the same > > original instance. > > > > | 30 | 2014-02-25T11:09:58 | 2014-02-25T11:10:28 | 3 | > > 34.33 | 120.1 | 274.26667 | 91.42 | 15.0 | > > 2014-02-25T11:10:11 | 2014-02-25T11:10:26 | > > | 30 | 2014-02-25T11:10:28 | 2014-02-25T11:10:58 | 4 | 17.0 > >| 120.86667 | 274.9 | 68.73 | 20.0 | > > 2014-02-25T11:10:36 | 2014-02-25T11:10:56 | > > > > Group_A-2: 2014-02-25T11:11:12.00 > > Should it have occurred: arguable > > The average is now 68.73 calculated from two samples each from the > > original and scale-up instance. > > So the low-watermark alarm will not have fired (as 68.73 >= 30), > > hence scale-down actions should not have occurred. > > The high-watermark alarm will shortly revert to OK, but since the the > > alarm evaluation period is presumably 30s, that may take a few more seconds > > before that alarm state transition occurs and is reported to heat. > > > > | 30 | 2014-02-25T11:10:58 | 2014-02-25T11:11:
Re: [Openstack] [Heat/Ceilometer/Havana]: Auto scaling no longer occurring after some time
- Original Message - > On Mon, Feb 24, 2014 at 04:46:17AM -0500, Eoghan Glynn wrote: > > > > Hi Juha, > > > > Are you using Havana? > > > > If so, your alarm resource templates seem to be missing setting the > > "repeat_actions" attribute to true. Continuous notification was required > > in order for the Heat autoscaling cooldown logic (and continued scaling > > actions) to work. > > > > This was a quirk of the Heat implementation in Havan, but TBH from a > > usability PoV should have always had this set to True by default. This > > is fixed now on Heat:master: > > > > https://github.com/openstack/heat/commit/4dc987ef > > > > but hasn't been backported to Heat:stable/stable. > > I just took a look, and I don't think we can backport it, because it's > changing the resource interface default > > It's possible (although unlikely) that someone could be relying on the > existing default so I don't think the patch is a valid candidate for a > stable backport, unfortunately. Are ceilometer alarms typically used in heat templates for anything other than autoscaling I wonder? If not, then I think it would be OK to change the default repeat_actions on stable, as it would only impact users who are relying on a feature to *not* work ;) But if alarms are used in a general purpose sense, then you're probably correct on the suitability for the stable branch. Cheers, Eoghan ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] assistcance required on ceilometer alarm-evaluator and ceilometer-alarm-notifier
A quick look at [1] suggests that the Ubuntu packages may not have been updated to accommodate the alarm services. Can you clarify this with the package owner? (also listed on [1]) Cheers, Eoghan [1] https://launchpad.net/ubuntu/+source/ceilometer > > Hi team , > > > > Can any one help in in providing the link to install > ceilometer-alarm-evaluator and ceil ometer-alarm-notifier and also package > for ubuntu 12.04 .? > > > > In install document nothing much mentioned about ceilometer-alarm-evaluator > and ceil ometer-alarm-notifier . How can I verify this after installation ? > > > > Regards, > > Malleshi C N > > > > This message is for the designated recipient only and may contain privileged, > proprietary, or otherwise confidential information. If you have received it > in error, please notify the sender immediately and delete the original. Any > other use of the e-mail by you is prohibited. Where allowed by local law, > electronic communications with Accenture and its affiliates, including > e-mail and instant messaging (including content), may be scanned by our > systems for the purposes of information security and assessment of internal > compliance with Accenture policy. > __ > > www.accenture.com > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] ceilometer-alarm
>
> Hello every one ,
>
>
>
> I am working on ceilometer-alarm configuration . when my cpu load increases >
> 30 how I will be notified ?.
>
> Below is details of my alarm. Please help me
>
>
>
>
>
>
>
> +---+--+
>
> | Property | Value |
>
> +---+--+
>
> | alarm_actions | [u'https://192.168.100.217/horizon'] |
You've configured your alarm to notify the endpoint:
https://192.168.100.217/horizon
with a HTTP POST when the alarm fires. I'd suspect this is not
what you intended to do.
Cheers,
Eoghan
> | user_id | admin |
>
> | name | cpuutlization |
>
> | enabled | True |
>
> | rule | {u'meter_name': u'cpu', u'evaluation_periods': 1, u'period': 60, |
>
> | | u'statistic': u'avg', u'threshold': 30.0, u'query': [], |
>
> | | u'comparison_operator': u'gt'} |
>
> | alarm_id | 5e9085ef-e0e5-4e8a-afdb-7987ebe47943 |
>
> | state | alarm |
>
> | insufficient_data_actions | [] |
>
> | repeat_actions | False |
>
> | ok_actions | [] |
>
> | project_id | 536518d5b38d4f3e9dcab26403d4d6e8 |
>
> | type | threshold |
>
> | description | Threshholdvalue |
>
> +---+--+
>
> root@Tcontroller:/home/oss# ceilometer alarm-list
>
> +--+--+---+-++--+-+--+
>
> | Name | Description | State | Enabled | Continuous | Alarm ID | User ID |
> | Project ID |
>
> +--+--+---+-++--+-+--+
>
> | cpuutlization | Threshholdvalue | alarm | True | False |
> | 5e9085ef-e0e5-4e8a-afdb-7987ebe47943 | admin |
> | 536518d5b38d4f3e9dcab26403d4d6e8 |
>
> | memory_over_load | Threshhold_value | alarm | True | False |
> | 6133d8de-670d-4c64-996b-930c9c843a2c | admin |
> | 536518d5b38d4f3e9dcab26403d4d6e8 |
>
> +--+--+---+-++--+-+--+
>
> root@Tcontroller:/home/oss#
>
>
>
> This message is for the designated recipient only and may contain privileged,
> proprietary, or otherwise confidential information. If you have received it
> in error, please notify the sender immediately and delete the original. Any
> other use of the e-mail by you is prohibited. Where allowed by local law,
> electronic communications with Accenture and its affiliates, including
> e-mail and instant messaging (including content), may be scanned by our
> systems for the purposes of information security and assessment of internal
> compliance with Accenture policy.
> __
>
> www.accenture.com
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Request for help - Heat Auto-scaling
What version of Heat are you using?
The repeat_actions attribute on the alarms was needed to set
explicitly True in Havana (whereas this is now the default).
This continuous notification is needed for the Heat autoscaling
logic to kick in successfully.
So if using Havana, please add this setting to CPUAlarmHigh
& CPUAlarmLow.
Cheers,
Eoghan
- Original Message -
> Hello Jay,
> Thanks, here is my template:
>
> {
> "AWSTemplateFormatVersion" : "2014-03-06",
>
> "Parameters" : {
> "InstanceType" : {
> "Description" : "WebServer EC2 instance type",
> "Type" : "String",
> "Default" : "m1.small",
> "ConstraintDescription" : "must be a valid EC2 instance type."
> },
> "WebServerPort" : {
> "Description" : "TCP/IP port of the web server",
> "Type" : "String",
> "Default" : ""
> },
> "KeyName" : {
> "Description" : "Name of an existing EC2 KeyPair to enable SSH access to the
> instances",
> "Type" : "String",
> "Default" : "damonkey"
> }
> },
>
> "Resources" : {
> "WebServerGroup" : {
> "Type" : "AWS::AutoScaling::AutoScalingGroup",
> "Properties" : {
> "AvailabilityZones" : { "Fn::GetAZs" : "" },
> "LaunchConfigurationName" : { "Ref" : "LaunchConfig" },
> "MinSize" : "1",
> "MaxSize" : "3"
> }
> },
> "ScaleUpPolicy": {
> "Type": "AWS::AutoScaling::ScalingPolicy",
> "Properties": {
> "AdjustmentType": "ChangeInCapacity",
> "AutoScalingGroupName": "WebServerGroup",
> "Cooldown": "60",
> "ScalingAdjustment": "1"
> }
> },
> "ScaleDownPolicy": {
> "Type": "AWS::AutoScaling::ScalingPolicy",
> "Properties": {
> "AdjustmentType": "ChangeInCapacity",
> "AutoScalingGroupName": "WebServerGroup",
> "Cooldown": "60",
> "ScalingAdjustment": "-1"
> }
> },
> "CPUAlarmHigh": {
> "Type": "OS::Ceilometer::Alarm",
> "Properties": {
> "description": "Scale-up if CPU is greater than 90% for 10 seconds",
> "meter_name": "cpu_util",
> "statistic": "avg",
> "period": "10",
> "evaluation_periods": "1",
> "threshold": "90",
> "alarm_actions": [ {"Fn::GetAtt": ["ScaleUpPolicy", "AlarmUrl"]} ],
> "matching_metadata": {"metadata.user_metadata.server_group": "WebServerGroup"
> },
> "comparison_operator": "gt"
> }
> },
> "CPUAlarmLow": {
> "Type": "OS::Ceilometer::Alarm",
> "Properties": {
> "description": "Scale-down if CPU is less than 50% for 10 seconds",
> "meter_name": "cpu_util",
> "statistic": "avg",
> "period": "10",
> "evaluation_periods": "1",
> "threshold": "50",
> "alarm_actions": [ {"Fn::GetAtt": ["ScaleDownPolicy", "AlarmUrl"]} ],
> "matching_metadata": {"metadata.user_metadata.server_group": "WebServerGroup"
> },
> "comparison_operator": "lt"
> }
> },
> "LaunchConfig" : {
> "Type" : "AWS::AutoScaling::LaunchConfiguration",
> "Properties" : {
> "KeyName" : { "Ref" : "KeyName" },
> "ImageId" : "CirrOS 0.3.1",
> "UserData" : { "Fn::Base64" : { "Ref" : "WebServerPort" }},
> "SecurityGroups" : [ "default" ],
> "InstanceType" : { "Ref" : "InstanceType" }
> }
> }
> }
>
> }
>
>
> 2014-03-13 13:29 GMT+08:00 Micheal < pannov.t...@gmail.com > :
>
>
>
> Does Heat support auto-scaling in Havana ? The cloudwatch seems to be
> deprecated, and the new mechanism with ceilometer seems not working either.
> I can create stack successfully, but the stack with
> AWS::AutoScaling::AutoScalingGroup can not auto-scaling as expected.
> All replies appreciated, thanks!
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Request for help - Heat Auto-scaling
Try changing:
"repeat_actions": "true"
to:
"repeat_actions": True
- Original Message -
> Eoghan, thanks for your reply.
>
>
> I modified the alarm in my template, like this:
> 67 "CPUAlarmLow": {
> 68 "Type": "OS::Ceilometer::Alarm",
> 69 "Properties": {
> 70 "description": "Scale-down if CPU is less than 20% for 10
> seconds",
> 71 "meter_name": "cpu_util",
> 72 "statistic": "avg",
> 73 "period": "10",
> 74 "evaluation_periods": "1",
> 75 "threshold": "20",
> 76 "alarm_actions": [ {"Fn::GetAtt": ["ScaleDownPolicy",
> "AlarmUrl"]} ],
> 77 "matching_metadata": {"metadata.user_metadata.server_group":
> "WebServerGroup" },
> 78 "comparison_operator": "lt",
> 79 "repeat_actions": "true"
> 80 }
> 81 }
>
>
> but there's an error while creating the stack, here is the log:
>
>
> {"error_message": {"debuginfo": null, "faultcode": "Server", "faultstring":
> "repeat_actions: Wrong type. Expected '', got ''"}}
> 160 log_http_response
> /usr/lib/python2.6/site-packages/ceilometerclient/common/http.py:121
> 161 2014-03-14 16:55:08.835 2997 WARNING ceilometerclient.common.http [-]
> Request returned failure status.
> 162 2014-03-14 16:55:08.835 2997 ERROR heat.engine.resource [-] CREATE :
> CeilometerAlarm "CPUAlarmHigh"
>
>
>
>
> 2014-03-13 19:26 GMT+08:00 Eoghan Glynn :
>
> >
> > What version of Heat are you using?
> >
> > The repeat_actions attribute on the alarms was needed to set
> > explicitly True in Havana (whereas this is now the default).
> >
> > This continuous notification is needed for the Heat autoscaling
> > logic to kick in successfully.
> >
> > So if using Havana, please add this setting to CPUAlarmHigh
> > & CPUAlarmLow.
> >
> > Cheers,
> > Eoghan
> >
> >
> > - Original Message -
> > > Hello Jay,
> > > Thanks, here is my template:
> > >
> > > {
> > > "AWSTemplateFormatVersion" : "2014-03-06",
> > >
> > > "Parameters" : {
> > > "InstanceType" : {
> > > "Description" : "WebServer EC2 instance type",
> > > "Type" : "String",
> > > "Default" : "m1.small",
> > > "ConstraintDescription" : "must be a valid EC2 instance type."
> > > },
> > > "WebServerPort" : {
> > > "Description" : "TCP/IP port of the web server",
> > > "Type" : "String",
> > > "Default" : ""
> > > },
> > > "KeyName" : {
> > > "Description" : "Name of an existing EC2 KeyPair to enable SSH access to
> > the
> > > instances",
> > > "Type" : "String",
> > > "Default" : "damonkey"
> > > }
> > > },
> > >
> > > "Resources" : {
> > > "WebServerGroup" : {
> > > "Type" : "AWS::AutoScaling::AutoScalingGroup",
> > > "Properties" : {
> > > "AvailabilityZones" : { "Fn::GetAZs" : "" },
> > > "LaunchConfigurationName" : { "Ref" : "LaunchConfig" },
> > > "MinSize" : "1",
> > > "MaxSize" : "3"
> > > }
> > > },
> > > "ScaleUpPolicy": {
> > > "Type": "AWS::AutoScaling::ScalingPolicy",
> > > "Properties": {
> > > "AdjustmentType": "ChangeInCapacity",
> > > "AutoScalingGroupName": "WebServerGroup",
> > > "Cooldown": "60",
> > > "ScalingAdjustment": "1"
> > > }
> > > },
> > > "ScaleDownPolicy": {
> > > "Type": "AWS::AutoScaling::ScalingPolicy",
> > > "Properties": {
> > > "AdjustmentType": "ChangeInCapacity",
> > > "AutoScalingGroupName": "WebServer
Re: [Openstack] [Ceilometer] Example "create alarm" via REST API
> Hi All,
>
> Can somebody give me an example of how I’d create an alarm via the Telemetry
> (aka Ceilometer) REST API? I can’t for the life of me find a simple example
> online, say for example, how to set an alarm for when cpu_util > 80% for a
> given running instance.
See this little RDO getting-started guide I wrote a while back:
http://openstack.redhat.com/CeilometerQuickStart
there's an example therein of creating an alarm via the CLI:
$ ceilometer alarm-threshold-create --name cpu_high --description 'instance
running hot' \
--meter-name cpu_util --threshold 70.0 --comparison-operator gt
--statistic avg \
--period 600 --evaluation-periods 3 \
--alarm-action 'log://' \
--query resource_id=INSTANCE_ID
Just modify the period, evaluation-periods, threshold to suit your use-case.
To see the actual JSON payload, simply use the --debug option:
$ ceilometer --debug alarm-threshold-create ...
...
curl -i -X POST -H 'X-Auth-Token: TOKEN' -H 'Content-Type: application/json'
-H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' -d
'{"alarm_actions": ["log://"], "description": "instance running hot",
"threshold_rule": {"meter_name": "cpu_util", "evaluation_periods": 3, "period":
600, "statistic": "avg", "threshold": 70.0, "query": [{"field": "resource_id",
"type": "", "value": "INSTANCE_ID", "op": "eq"}], "comparison_operator": "gt"},
"repeat_actions": false, "type": "threshold", "name": "cpu_high"}'
http://IP_ADDR:8777/v2/alarms
You could also look at the official project API docco here:
http://docs.openstack.org/developer/ceilometer/webapi/v2.html
Cheers,
Eoghan
>
> I saw this example in a presentation somewhere, but it’s not exactly
> self-explanatory.
>
> POST /v2/alarms
>
> {
> "alarm_actions": [
> "http://site:8000/alarm";
> ],
> "insufficient_data_actions": [
> "http://site:8000/nodata";
> ],
> "ok_actions": [
> "http://site:8000/ok";
> ],
> "comparison_operator": "gt",
> "description": "An alarm",
> "evaluation_periods": 2,
> "matching_metadata": {
> "key_name": "key_value"
> },
> "meter_name": "storage.objects",
> "name": "SwiftObjectAlarm",
> "period": 240,
> "statistic": "avg",
> "threshold": 200
> }
>
> Thanks,
> Mark
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Ceilometer] Example "create alarm" via REST API
> Hello Eoghan,
>
> Thanks for the steps..
>
> when I launched my stack(autoscaling), Alarms are created but not generating,
> showing insufficient data. In the log I found below error
>
> I have found something from my log .
>
> ==> ceilometer-collector.log <==
> 2014-03-25 05:40:56.308 1047 ERROR stevedore.extension [-] error calling
> 'port': 'tenant_id'
> 2014-03-25 05:40:56.308 1047 ERROR stevedore.extension [-] 'tenant_id'
> 2014-03-25 05:40:56.308 1047 TRACE stevedore.extension Traceback (most
> recent call last):
> 2014-03-25 05:40:56.308 1047 TRACE stevedore.extension File
> "/usr/lib/python2.7/dist-packages/stevedore/extension.py", line 145, in
> _invoke_one_plugin
> 2014-03-25 05:40:56.308 1047 TRACE stevedore.extension
> response_callback(func(e, *args, **kwds))
> 2014-03-25 05:40:56.308 1047 TRACE stevedore.extension File
> "/usr/lib/python2.7/dist-packages/ceilometer/collector/service.py", line
> 293, in _process_notification_for_ext
> 2014-03-25 05:40:56.308 1047 TRACE stevedore.extension
> p(list(ext.obj.to_samples(notification)))
> 2014-03-25 05:40:56.308 1047 TRACE stevedore.extension File
> "/usr/lib/python2.7/dist-packages/ceilometer/network/notifications.py",
> line 89, in process_notification
> 2014-03-25 05:40:56.308 1047 TRACE stevedore.extension
> project_id=message['payload']['tenant_id'],
> 2014-03-25 05:40:56.308 1047 TRACE stevedore.extension KeyError: 'tenant_id'
> 2014-03-25 05:40:56.308 1047 TRACE stevedore.extension
What version are you using?
That's an issue with incoming neutron notification, shouldn't impact
on cpu_util gathering.
Do you have visibility on the stats related to the instance? e.g.
$ ceilometer statistics -m cpu_util -q resource=$INSTANCE_ID
/Eoghan
> refer:
> https://bugs.launchpad.net/ceilometer/+bug/1276761
>
> I am not sure its a bug or I am doing something wrong ..?
>
> Please let me know
>
> -Original Message-
> From: Eoghan Glynn [mailto:egl...@redhat.com]
> Sent: Friday, March 28, 2014 3:31 PM
> To: Mark Vlcek (mavlcek)
> Cc: openstack
> Subject: Re: [Openstack] [Ceilometer] Example "create alarm" via REST API
>
>
>
> > Hi All,
> >
> > Can somebody give me an example of how I’d create an alarm via the
> > Telemetry (aka Ceilometer) REST API? I can’t for the life of me find a
> > simple example online, say for example, how to set an alarm for when
> > cpu_util > 80% for a given running instance.
>
> See this little RDO getting-started guide I wrote a while back:
>
> http://openstack.redhat.com/CeilometerQuickStart
>
> there's an example therein of creating an alarm via the CLI:
>
> $ ceilometer alarm-threshold-create --name cpu_high --description 'instance
> running hot' \
> --meter-name cpu_util --threshold 70.0 --comparison-operator gt
> --statistic avg \
> --period 600 --evaluation-periods 3 \
> --alarm-action 'log://' \
> --query resource_id=INSTANCE_ID
>
> Just modify the period, evaluation-periods, threshold to suit your use-case.
>
> To see the actual JSON payload, simply use the --debug option:
>
> $ ceilometer --debug alarm-threshold-create ...
> ...
> curl -i -X POST -H 'X-Auth-Token: TOKEN' -H 'Content-Type:
> application/json' -H 'Accept: application/json' -H 'User-Agent:
> python-ceilometerclient' -d '{"alarm_actions": ["log://"], "description":
> "instance running hot", "threshold_rule": {"meter_name": "cpu_util",
> "evaluation_periods": 3, "period": 600, "statistic": "avg", "threshold":
> 70.0, "query": [{"field": "resource_id", "type": "", "value":
> "INSTANCE_ID", "op": "eq"}], "comparison_operator": "gt"},
> "repeat_actions": false, "type": "threshold", "name": "cpu_high"}'
> http://IP_ADDR:8777/v2/alarms
>
> You could also look at the official project API docco here:
>
> http://docs.openstack.org/developer/ceilometer/webapi/v2.html
>
> Cheers,
> Eoghan
>
>
> >
> > I saw this example in a presentation somewhere, but it’s not exactly
> > self-explanatory.
> >
> > POST /v2/alarms
> >
> > {
> > "alarm_actions": [
> > "http://site:8000/alarm";
> > ],
> > "insuffi
Re: [Openstack] [Ceilometer/Heat/Havana]: Ceilometer statistics not available for custom metrics.
Juha,
Your problem is the embedded period in the metadata key: "metering.server_group"
If the metric were gathered by ceilometer itself in the usual way, then the
compute agent would transform that problematic payload as follows, from:
{ ..., "resource_metadata" : { "AutoScalingGroupName":
"tykyauto-Group_B-hmknsgn35efz", "metering.server_group": "Group_B" }, ... }
to:
{ ..., "resource_metadata" : { "AutoScalingGroupName":
"tykyauto-Group_B-hmknsgn35efz", "user_metadata": {"server_group": "Group_B"}
}, ... }
You should follow the same pattern.
Cheers,
Eoghan
- Original Message -
> Maybe this is because I didn't fill in instance related metadata (scaling
> group name and such) to the REST call I made when adding custom metric data
> to Ceilometer. I tried to create metric data again, now with metadata
> filled:
>
> $ curl -X POST -H 'X-Auth-Token: 0722fcd0f403425bb8564808c37e8dc8' -H
> 'Content-Type: application/json' -d '[ { "counter_name": "vm_cpu_load",
> "resource_id": "e7eaf484-38b6-4689-8490-40aa8f0df8ae", "resource_metadata" :
> { "AutoScalingGroupName": "tykyauto-Group_B-hmknsgn35efz",
> "metering.server_group": "Group_B" }, "counter_unit": "%", "counter_volume":
> 11, "counter_type": "gauge" } ]'
> http://192.168.100.5:8777/v2/meters/vm_cpu_load
>
> ...but as a result I can see the following error in ceilometer log:
>
> <43>Apr 3 14:24:01 node-6 ceilometer-ceilometer.collector.dispatcher.database
> ERROR: Failed to record metering data: not okForStorage
> Traceback (most recent call last):
> File
> "/usr/lib/python2.7/dist-packages/ceilometer/collector/dispatcher/database.py",
> line 65, in record_metering_data
> self.storage_conn.record_metering_data(meter)
> File "/usr/lib/python2.7/dist-packages/ceilometer/storage/impl_mongodb.py",
> line 451, in record_metering_data
> upsert=True,
> File "/usr/lib/python2.7/dist-packages/pymongo/collection.py", line 487, in
> update
> check_keys, self.__uuid_subtype), safe)
> File "/usr/lib/python2.7/dist-packages/pymongo/mongo_client.py", line 969, in
> _send_message
> rv = self.__check_response_to_last_error(response)
> File "/usr/lib/python2.7/dist-packages/pymongo/mongo_client.py", line 911, in
> __check_response_to_last_error
> raise OperationFailure(details["err"], details["code"])
> OperationFailure: not okForStorage
>
> Hmm. What am I doing wrong here?
>
> Thanks,
> -Juha
>
>
>
>
> On 2 April 2014 14:04, Juha Tynninen < juha.tynni...@tieto.com > wrote:
>
>
>
> Hi,
>
> I'm sending custom Ceilometer metrics from inside VM instance with REST call
> to
> http://192.168.100.5:8777/v2/meters/vm_cpu_load .
>
> This is successful and I can see the entered metric data with Ceilometer:
>
> # ceilometer sample-list -m vm_cpu_load
> -q="resource_id=91951d0a-9a43-4894-99fb-ac67a1098771" | tail -n +4 | head -n
> -1 | sort -k 12
> ...
> | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 2.6 | % |
> | 2014-03-30T19:20:38.08 |
> | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 3.3 | % |
> | 2014-03-30T19:20:58.223000 |
> | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 2.6 | % |
> | 2014-03-30T19:21:18.078000 |
> | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 28.6 | % |
> | 2014-03-30T19:21:38.894000 |
> | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 1.0 | % |
> | 2014-03-30T19:21:59.37 |
> | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 2.3 | % |
> | 2014-03-30T19:22:20.255000 |
> | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 0.3 | % |
> | 2014-03-30T19:22:40.351000 |
> | 91951d0a-9a43-4894-99fb-ac67a1098771 | vm_cpu_load | gauge | 1.9 | % |
> | 2014-03-30T19:23:00.317000 |
>
> # ceilometer meter-list | grep vm_cpu_load | grep
> 91951d0a-9a43-4894-99fb-ac67a1098771
> | vm_cpu_load | gauge | % | 91951d0a-9a43-4894-99fb-ac67a1098771 |
> | 2884e2f624224227bb63d77a040126e6 | a12aee6f0da04d8d976eb4b761a73e14 |
>
> I've started the instance with a Heat template having AutoScaling defined and
> I'm trying to base the scaling actions to this custom metric.
> The problem is that the autoscaling does not occur.
>
> "Resources" : {
>
> "Group_B" : {
> "Type" : "AWS::AutoScaling::AutoScalingGroup",
> "Properties" : {
> "AvailabilityZones" : { "Fn::GetAZs" : ""},
> "LaunchConfigurationName" : { "Ref" : "Group_B_Config" },
> "MinSize" : "1",
> "MaxSize" : "3",
> "Tags" : [
> { "Key" : "metering.server_group", "Value" : "Group_B" }
> ],
> "VPCZoneIdentifier" : [ { "Ref" : "Private Application Subnet ID" } ]
> }
> },
> ...
> "Group_B_Config" : {
> "Type" : "AWS::AutoScaling::LaunchConfiguration",
> "Properties": {
> "ImageId" : { "Ref" : "Image Id" },
> "InstanceType" : { "Ref" : "Instance Type" },
> "KeyName" : { "Ref" : "Key Name" }
> }
> },
> ...
> "CPUAlarmHigh": {
> "Type": "OS::Ceilometer::Alarm",
> "Properties": {
> "description": "Scale-up if CPU is greater than 80% for 60 seconds",
> "meter_name": "vm_cpu_load",
> "statistic":
Re: [Openstack] [Ceilometer/Heat/Havana]: Ceilometer statistics not available for custom metrics.
Hi Juha,
Smells like a bug in the sample POST API, in the sense that:
"resource_metadata" : { ... "user_metadata": {"server_group": "Group_B"} }
is flattened to:
"metadata": { ... "user_metadata.server_group": "Group_B" }
in the metering message generated from the sample.
I'll dig some more and file bug. BTW what exact version are you using?
Cheers,
Eoghan
- Original Message -
> Hi Eoghan,
>
> Thank you. Tried this, but unfortunately it seems the user_metadata part
> causes a failure.
> Command having just AutoScalingGroupName as a metadata goes through ok:
>
> curl -X POST -H 'X-Auth-Token: f66288ad283d4ee0a322d03c95db2a4b' -H
> 'Content-Type: application/json' -d '[ { "counter_name": "vm_cpu_load",
> "resource_id": "8d326543-cde9-4c3c-9c7e-3973cfbcb057", "resource_metadata"
> : { "AutoScalingGroupName": "tykyauto-Group_B-ljhkoj244qzh" },
> "counter_unit": "%", "counter_volume": 11, "counter_type": "gauge" } ]'
> http://192.168.100.5:8777/v2/meters/vm_cpu_load
>
> ...but when I add the user_metadata part:
>
> curl -X POST -H 'X-Auth-Token: f66288ad283d4ee0a322d03c95db2a4b' -H
> 'Content-Type: application/json' -d '[ { "counter_name": "vm_cpu_load",
> "resource_id": "8d326543-cde9-4c3c-9c7e-3973cfbcb057", "resource_metadata"
> : { "AutoScalingGroupName": "tykyauto-Group_B-ljhkoj244qzh",
> "user_metadata": {"server_group": "Group_B"} }, "counter_unit": "%",
> "counter_volume": 11, "counter_type": "gauge" } ]'
> http://192.168.100.5:8777/v2/meters/vm_cpu_load
>
> ...the following error occurs:
>
> <43>Apr 4 09:08:56 node-6
> ceilometer-ceilometer.collector.dispatcher.database ERROR: Failed to record
> metering data: not okForStorage
> Traceback (most recent call last):
> File
> "/usr/lib/python2.7/dist-packages/ceilometer/collector/dispatcher/database.py",
> line 65, in record_metering_data
> self.storage_conn.record_metering_data(meter)
> File
> "/usr/lib/python2.7/dist-packages/ceilometer/storage/impl_mongodb.py", line
> 451, in record_metering_data
> upsert=True,
> File "/usr/lib/python2.7/dist-packages/pymongo/collection.py", line 487,
> in update
> check_keys, self.__uuid_subtype), safe)
> File "/usr/lib/python2.7/dist-packages/pymongo/mongo_client.py", line
> 969, in _send_message
> rv = self.__check_response_to_last_error(response)
> File "/usr/lib/python2.7/dist-packages/pymongo/mongo_client.py", line
> 911, in __check_response_to_last_error
> raise OperationFailure(details["err"], details["code"])
> OperationFailure: not okForStorage
>
> I have mongo configured as a database for Ceilometer (otherwise
> ceilometer-alarm-evaluator error ERROR: Server-side error: "metaquery not
> implemented" occurs).
>
> In our environment the following versions of Ceilometer components have
> been installed:
>
> 2013.2.2:
> ceilometer-agent-central
> ceilometer-alarm-evaluator
> ceilometer-alarm-notifier
> ceilometer-api
> ceilometer-collector
> ceilometer-common
> python-ceilometer
>
> 1:1.0.5:
> python-ceilometerclient
>
> Br,
> -Juha
>
>
> On 3 April 2014 17:18, Eoghan Glynn wrote:
>
> >
> > Juha,
> >
> > Your problem is the embedded period in the metadata key:
> > "metering.server_group"
> >
> > If the metric were gathered by ceilometer itself in the usual way, then the
> > compute agent would transform that problematic payload as follows, from:
> >
> > { ..., "resource_metadata" : { "AutoScalingGroupName":
> > "tykyauto-Group_B-hmknsgn35efz", "metering.server_group": "Group_B" }, ...
> > }
> >
> > to:
> >
> > { ..., "resource_metadata" : { "AutoScalingGroupName":
> > "tykyauto-Group_B-hmknsgn35efz", "user_metadata": {"server_group":
> > "Group_B"} }, ... }
> >
> > You should follow the same pattern.
> >
> > Cheers,
> > Eoghan
> >
> > - Original Message -
> > > Maybe this is because I didn't fill in instance related metadata (scaling
> > > group name and such) to the REST call I made when adding custom metric
>
Re: [Openstack] [Ceilometer/Heat/Havana]: Ceilometer statistics not available for custom metrics.
> Hi Juha,
>
> Smells like a bug in the sample POST API, in the sense that:
>
> "resource_metadata" : { ... "user_metadata": {"server_group": "Group_B"} }
>
> is flattened to:
>
> "metadata": { ... "user_metadata.server_group": "Group_B" }
>
> in the metering message generated from the sample.
>
> I'll dig some more and file bug. BTW what exact version are you using?
Here's the promised bug with a detailed explanation of why this issue occurs:
https://bugs.launchpad.net/ceilometer/+bug/1302664
Cheers,
Eoghan
> Cheers,
> Eoghan
>
> - Original Message -
> > Hi Eoghan,
> >
> > Thank you. Tried this, but unfortunately it seems the user_metadata part
> > causes a failure.
> > Command having just AutoScalingGroupName as a metadata goes through ok:
> >
> > curl -X POST -H 'X-Auth-Token: f66288ad283d4ee0a322d03c95db2a4b' -H
> > 'Content-Type: application/json' -d '[ { "counter_name": "vm_cpu_load",
> > "resource_id": "8d326543-cde9-4c3c-9c7e-3973cfbcb057", "resource_metadata"
> > : { "AutoScalingGroupName": "tykyauto-Group_B-ljhkoj244qzh" },
> > "counter_unit": "%", "counter_volume": 11, "counter_type": "gauge" } ]'
> > http://192.168.100.5:8777/v2/meters/vm_cpu_load
> >
> > ...but when I add the user_metadata part:
> >
> > curl -X POST -H 'X-Auth-Token: f66288ad283d4ee0a322d03c95db2a4b' -H
> > 'Content-Type: application/json' -d '[ { "counter_name": "vm_cpu_load",
> > "resource_id": "8d326543-cde9-4c3c-9c7e-3973cfbcb057", "resource_metadata"
> > : { "AutoScalingGroupName": "tykyauto-Group_B-ljhkoj244qzh",
> > "user_metadata": {"server_group": "Group_B"} }, "counter_unit": "%",
> > "counter_volume": 11, "counter_type": "gauge" } ]'
> > http://192.168.100.5:8777/v2/meters/vm_cpu_load
> >
> > ...the following error occurs:
> >
> > <43>Apr 4 09:08:56 node-6
> > ceilometer-ceilometer.collector.dispatcher.database ERROR: Failed to record
> > metering data: not okForStorage
> > Traceback (most recent call last):
> > File
> > "/usr/lib/python2.7/dist-packages/ceilometer/collector/dispatcher/database.py",
> > line 65, in record_metering_data
> > self.storage_conn.record_metering_data(meter)
> > File
> > "/usr/lib/python2.7/dist-packages/ceilometer/storage/impl_mongodb.py", line
> > 451, in record_metering_data
> > upsert=True,
> > File "/usr/lib/python2.7/dist-packages/pymongo/collection.py", line 487,
> > in update
> > check_keys, self.__uuid_subtype), safe)
> > File "/usr/lib/python2.7/dist-packages/pymongo/mongo_client.py", line
> > 969, in _send_message
> > rv = self.__check_response_to_last_error(response)
> > File "/usr/lib/python2.7/dist-packages/pymongo/mongo_client.py", line
> > 911, in __check_response_to_last_error
> > raise OperationFailure(details["err"], details["code"])
> > OperationFailure: not okForStorage
> >
> > I have mongo configured as a database for Ceilometer (otherwise
> > ceilometer-alarm-evaluator error ERROR: Server-side error: "metaquery not
> > implemented" occurs).
> >
> > In our environment the following versions of Ceilometer components have
> > been installed:
> >
> > 2013.2.2:
> > ceilometer-agent-central
> > ceilometer-alarm-evaluator
> > ceilometer-alarm-notifier
> > ceilometer-api
> > ceilometer-collector
> > ceilometer-common
> > python-ceilometer
> >
> > 1:1.0.5:
> > python-ceilometerclient
> >
> > Br,
> > -Juha
> >
> >
> > On 3 April 2014 17:18, Eoghan Glynn wrote:
> >
> > >
> > > Juha,
> > >
> > > Your problem is the embedded period in the metadata key:
> > > "metering.server_group"
> > >
> > > If the metric were gathered by ceilometer itself in the usual way, then
> > > the
> > > compute agent would transform that problematic payload as follows, from:
> > >
> > > { ..., "resource_metadata" : { "AutoScalingGroupName":
> > > "tykyauto-Group_B-hmknsgn35efz", "metering.server_group": "
Re: [Openstack] openstack - Ceilometer error - [root@compute1 ceilometer]# ceilometer meter-list Error communicating with http://controller:8777 [Errno 111] Connection refused
> Hi All, > > Please find the error iam getting after finishing the ceilometer > configuration in controller and compute. > > Error: > > [root@compute1 ceilometer]# ceilometer meter-list > Error communicating with http://controller:8777 [Errno 111] Connection > refused > > I have started all the services. I noticed 8777 port is not listening. > > Please gimme some advice. Check if the ceilometer-api service is actually running on the expected node. e.g. on Fedora and derivatives with RPMs installed: $ sudo service openstack-ceilometer-api status elsewhere: $ ps -fe | grep ceilometer-api Also check your firewall rules to ensure that the ceilometer-api endpoint (i.e. port 8777) is accessible from the host on which you run the client. Cheers, Eoghan > I have finished almost all except ceilometer. > > Attaching the output of #ceilometer --debug meter-list > > Regards, > Dhanesh ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] openstack - Ceilometer error - [root@compute1 ceilometer]# ceilometer meter-list Error communicating with http://controller:8777 [Errno 111] Connection refused
What's your configured database connection? (in /etc/ceilometer/ceilometer.conf) If its a sqlalchemy-based URL (e.g. mysql or postgres) have you run ceilometer-dbsync? (either directly, or a side-effect of the installation process) - Original Message - > Hi All, > > ps -fe | grep ceilometer-api > > No process is running. > > status is showing its dead. > > > Api Error log. > > [root@controller ceilometer]# tailf api.log > 2014-05-20 14:42:39.476 10768 WARNING keystoneclient.middleware.auth_token > [-] Configuring auth_uri to point to the public identity endpoint is > required; clients may not be able to authenticate against an admin endpoint > 2014-05-20 14:42:39.477 10768 INFO keystoneclient.middleware.auth_token [-] > Using /tmp/keystone-signing-w05DPS as cache directory for signing > certificate > 2014-05-20 14:42:39.877 10768 CRITICAL ceilometer [-] OperationalError: > (OperationalError) unable to open database file None None > > 2014-05-20 14:49:47.686 12502 INFO keystoneclient.middleware.auth_token [-] > Starting keystone auth_token middleware > 2014-05-20 14:49:47.687 12502 WARNING keystoneclient.middleware.auth_token > [-] Configuring admin URI using auth fragments. This is deprecated, use > 'identity_uri' instead. > 2014-05-20 14:49:47.687 12502 WARNING keystoneclient.middleware.auth_token > [-] Configuring auth_uri to point to the public identity endpoint is > required; clients may not be able to authenticate against an admin endpoint > > 2014-05-20 14:49:47.688 12502 INFO keystoneclient.middleware.auth_token [-] > Using /tmp/keystone-signing-zXbRzr as cache directory for signing > certificate > 2014-05-20 14:49:48.080 12502 CRITICAL ceilometer [-] OperationalError: > (OperationalError) unable to open database file None None > > > > Regards, > Dhanesh. > > > > > On Tue, May 20, 2014 at 1:29 PM, Eoghan Glynn wrote: > > > > > > > > Hi All, > > > > > > Please find the error iam getting after finishing the ceilometer > > > configuration in controller and compute. > > > > > > Error: > > > > > > [root@compute1 ceilometer]# ceilometer meter-list > > > Error communicating with http://controller:8777 [Errno 111] Connection > > > refused > > > > > > I have started all the services. I noticed 8777 port is not listening. > > > > > > Please gimme some advice. > > > > Check if the ceilometer-api service is actually running on the expected > > node. > > > > e.g. on Fedora and derivatives with RPMs installed: > > > > $ sudo service openstack-ceilometer-api status > > > > elsewhere: > > > > $ ps -fe | grep ceilometer-api > > > > Also check your firewall rules to ensure that the ceilometer-api endpoint > > (i.e. port 8777) is accessible from the host on which you run the client. > > > > Cheers, > > Eoghan > > > > > I have finished almost all except ceilometer. > > > > > > Attaching the output of #ceilometer --debug meter-list > > > > > > Regards, > > > Dhanesh > > > > > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] openstack - Ceilometer error - [root@compute1 ceilometer]# ceilometer meter-list Error communicating with http://controller:8777 [Errno 111] Connection refused
Set debug=True and verbose=True in your ceilometer.conf. Restart the ceilometer API service. Check /var/log/ceilometer/api.log for errors. Similarly for the central agent. - Original Message - > Hi All, > > > 8777 port is not up i started all the service. > > I have followed the icehouse document for fedora. > > > [root@controller ~]# /etc/init.d/openstack-ceilometer-api restart > Stopping openstack-ceilometer-api: [FAILED] > Starting openstack-ceilometer-api: [ OK ] > [root@controller ~]# /etc/init.d/openstack-ceilometer-api restart > Stopping openstack-ceilometer-api: [ OK ] > Starting openstack-ceilometer-api: [ OK ] > [root@controller ~]# netstat -atlpn | grep 8777 > > note: not showing the 8777 port > > ceilometer service status > > > [root@controller ~]# /etc/init.d/openstack-ceilometer-api status > openstack-ceilometer-api dead but pid file exists > > [root@controller ~]# /etc/init.d/openstack-ceilometer-central status > openstack-ceilometer-central dead but pid file exists > > [root@controller ~]# /etc/init.d/openstack-ceilometer-collector status > openstack-ceilometer-collector (pid 8905) is running... > > [root@controller ~]# /etc/init.d/openstack-ceilometer-notification status > openstack-ceilometer-agent-notification (pid 10307) is running... > > > [root@controller ~]# /etc/init.d/openstack-ceilometer-alarm-notifier status > openstack-ceilometer-alarm-notifier (pid 8947) is running... > > [root@controller ~]# /etc/init.d/openstack-ceilometer-alarm-evaluator status > openstack-ceilometer-alarm-evaluator (pid 8926) is running... > > > > > > Attaching the ceilometer.conf file along with this mail. Please fing the > attachment. > > > > Verify the Telemetry installation > > To test the Telemetry installation, download an image from the Image > Service, and use the *ceilometer* command to display usage statistics. > >1. > >Use the ceilometer meter-list command to test the access to Telemetry: > >$ ceilometer meter-list > > > > Error: > > ceilometer meter-list > Error communicating with http://controller:8777 [Errno 111] Connection > refused > > > Regards, > Dhanesh. > > > On Tue, May 20, 2014 at 3:04 PM, Eoghan Glynn wrote: > > > > > What's your configured database connection? > > > > (in /etc/ceilometer/ceilometer.conf) > > > > If its a sqlalchemy-based URL (e.g. mysql or postgres) have you run > > ceilometer-dbsync? > > > > (either directly, or a side-effect of the installation process) > > > > > > - Original Message - > > > Hi All, > > > > > > ps -fe | grep ceilometer-api > > > > > > No process is running. > > > > > > status is showing its dead. > > > > > > > > > Api Error log. > > > > > > [root@controller ceilometer]# tailf api.log > > > 2014-05-20 14:42:39.476 10768 WARNING > > keystoneclient.middleware.auth_token > > > [-] Configuring auth_uri to point to the public identity endpoint is > > > required; clients may not be able to authenticate against an admin > > endpoint > > > 2014-05-20 14:42:39.477 10768 INFO keystoneclient.middleware.auth_token > > [-] > > > Using /tmp/keystone-signing-w05DPS as cache directory for signing > > > certificate > > > 2014-05-20 14:42:39.877 10768 CRITICAL ceilometer [-] OperationalError: > > > (OperationalError) unable to open database file None None > > > > > > 2014-05-20 14:49:47.686 12502 INFO keystoneclient.middleware.auth_token > > [-] > > > Starting keystone auth_token middleware > > > 2014-05-20 14:49:47.687 12502 WARNING > > keystoneclient.middleware.auth_token > > > [-] Configuring admin URI using auth fragments. This is deprecated, use > > > 'identity_uri' instead. > > > 2014-05-20 14:49:47.687 12502 WARNING > > keystoneclient.middleware.auth_token > > > [-] Configuring auth_uri to point to the public identity endpoint is > > > required; clients may not be able to authenticate against an admin > > endpoint > > > > > > 2014-05-20 14:49:47.688 12502 INFO keystoneclient.middleware.auth_token > > [-] > > > Using /tmp/keystone-signing-zXbRzr as cache directory for signing > > > certificate > > > 2014-05-20 14:49:48.080 12502 CRITICAL ceilometer [-] OperationalError: > > > (OperationalError) unable to o
Re: [Openstack] openstack - Ceilometer error - [root@compute1 ceilometer]# ceilometer meter-list Error communicating with http://controller:8777 [Errno 111] Connection refused
> OperationalError: (OperationalError) unable to open database file None None Your config file implies mongodb usage for the metering store: [database] connection = mongodb://ceilometer:ceilometer@controller:27017/ceilometer Is mongo installed and running the expected host & port? (controller:27017) - Original Message - > Hi > > please find the log file for ceilometer api > > [root@controller ceilometer]# tailf /var/log/ceilometer/api.log > 2014-05-27 15:16:30.236 4914 WARNING keystoneclient.middleware.auth_token > [-] Configuring auth_uri to point to the public identity endpoint is > required; clients may not be able to authenticate against an admin endpoint > 2014-05-27 15:16:30.237 4914 INFO keystoneclient.middleware.auth_token [-] > Using /tmp/keystone-signing-FvjNMu as cache directory for signing > certificate > 2014-05-27 15:16:30.654 4914 CRITICAL ceilometer [-] OperationalError: > (OperationalError) unable to open database file None None > > 2014-05-27 15:19:08.520 4950 INFO keystoneclient.middleware.auth_token [-] > Starting keystone auth_token middleware > 2014-05-27 15:19:08.521 4950 WARNING keystoneclient.middleware.auth_token > [-] Configuring admin URI using auth fragments. This is deprecated, use > 'identity_uri' instead. > 2014-05-27 15:19:08.521 4950 WARNING keystoneclient.middleware.auth_token > [-] Configuring auth_uri to point to the public identity endpoint is > required; clients may not be able to authenticate against an admin endpoint > 2014-05-27 15:19:08.523 4950 INFO keystoneclient.middleware.auth_token [-] > Using /tmp/keystone-signing-14uzsO as cache directory for signing > certificate > 2014-05-27 15:19:08.913 4950 CRITICAL ceilometer [-] OperationalError: > (OperationalError) unable to open database file None None > > please find the log file for ceilometer central. > > 2014-05-27 15:19:59.182 4969 ERROR ceilometer.openstack.common.threadgroup > [-] coercing to Unicode: need string or buffer, NoneType found > 2014-05-27 15:19:59.182 4969 TRACE ceilometer.openstack.common.threadgroup > Traceback (most recent call last): > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup File > "/usr/lib/python2.6/site-packages/ceilometer/openstack/common/threadgroup.py", > line 125, in wait > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup x.wait() > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup File > "/usr/lib/python2.6/site-packages/ceilometer/openstack/common/threadgroup.py", > line 47, in wait > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup return self.thread.wait() > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup File > "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line 168, in > wait > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup return self._exit_event.wait() > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup File > "/usr/lib/python2.6/site-packages/eventlet/event.py", line 116, in wait > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup return hubs.get_hub().switch() > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup File > "/usr/lib/python2.6/site-packages/eventlet/hubs/hub.py", line 187, in switch > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup return self.greenlet.switch() > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup File > "/usr/lib/python2.6/site-packages/eventlet/greenthread.py", line 194, in > main > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup result = function(*args, > **kwargs) > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup File > "/usr/lib/python2.6/site-packages/ceilometer/openstack/common/service.py", > line 486, in run_service > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup service.start() > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup File > "/usr/lib/python2.6/site-packages/ceilometer/agent.py", line 137, in start > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup self.pipeline_manager = > pipeline.setup_pipeline() > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.openstack.common.threadgroup File > "/usr/lib/python2.6/site-packages/ceilometer/pipeline.py", line 524, in > setup_pipeline > 2014-05-27 15:19:59.182 4969 TRACE > ceilometer.opensta
Re: [Openstack] [metering] Considerations and Roadmap in Ceilometer (or other component) for Financial Management
> On Mon, Jun 02, 2014 at 02:52:15AM +, Lee Calcote (lecalcot) wrote: > > Hi, > > > > What support does Ceilometer provide today and what support is planned to > > provide for financial management? While Ceilometer provides functionality > > for *metering* and *billing integration* as two categories of financial > > management, does it provide for others (e.g. *pricing* - a method to set > > prices on common objects)? I consider that financial management breaks > > into these categories (and quite possibly others): > > The main goal of ceilometer is metering, and from what I understand > all the billing processing is not something that fit or will in this > project. Your understanding is correct ... directly addressing the billing stage of the pipeline was explicitly a non-goal for ceilometer from the very outset IIRC. Cheers, Eoghan > > Is support for these other categories planned for Ceilometer or other > > components? Have these use cases been successfully provided for in > > Ceilometer to date or have they yet to be achieved - > > https://wiki.openstack.org/wiki/Ceilometer/blueprints/support-for-advance-s > > ervice-billing-models? > > > We've started some work around the question, the project is hosted on > stackforge : https://github.com/stackforge/cloudkitty > Our main goal at the moment is to create reports with billing > informations. Everything is gathered directly from ceilometer. > > In a near future we want to add the pricing informations directly in > horizon. > > At the moment we're not addressing accounting/financial management > functions. > > We've only really worked on what we needed to implement. We would be > happy to hear about your use cases to see where the project should head. > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [ceilometer] ERROR in collector : Failed to record metering data
You need to run:
ceilometer-dbsync --config-file /etc/ceilometer/ceilometer.conf
in order to create the required schema in the database.
Cheers,
Eoghan
- Original Message -
>
>
> Hi all,
>
>
>
> I am trying to use mysql as database for ceilometer. I created database as
> follows
>
> CREATE DATABASE ceilometer;
>
>
>
> GRANT ALL PRIVILEGES ON ceilometer.* TO 'ceilometer'@'localhost' \
>
> IDENTIFIED BY 'CEILOMETER_DBPASS';
>
>
>
> GRANT ALL PRIVILEGES ON ceilometer.* TO 'ceilometer'@'%' \
>
> IDENTIFIED BY 'CEILOMETER_DBPASS';
>
>
>
> And mentioned it in ceilometer conf file.
>
> connection=mysql://ceilometer:CEILOMETER_DBPASS@100.30.30.221/ceilometer?charset=utf8
>
>
>
> But ceilometer collector is failing to create metering data
>
>
>
> root@koteswar-ice-osc:~# ceilometer meter-list
>
> WARNING (http:172) Request returned failure status.
>
> HTTPInternalServerError (HTTP 500)
>
>
>
> LOG:
>
> 2014-06-01 22:26:41.220 32219 ERROR ceilometer.dispatcher.database
> [req-c0453bd8-2849-4cfb-9698-3032f65e4d32 - - - - -] Failed to record
> metering data: (ProgrammingError) (1146, "Table 'ceilometer.source' doesn't
> exist") 'SELECT source.id AS source_id \nFROM source \nWHERE source.id = %s'
> ('openstack',)
>
> 2014-06-01 22:26:41.220 32219 TRACE ceilometer.dispatcher.database Traceback
> (most recent call last):
>
> 2014-06-01 22:26:41.220 32219 TRACE ceilometer.dispatcher.database File
> "/usr/lib/python2.7/dist-packages/ceilometer/dispatcher/database.py", line
> 67, in record_metering_data
>
> 2014-06-01 22:26:41.220 32219 TRACE ceilometer.dispatcher.database
> self.storage_conn.record_metering_data(meter)
>
> 2014-06-01 22:26:41.220 32219 TRACE ceilometer.dispatcher.database File
> "/usr/lib/python2.7/dist-packages/ceilometer/storage/impl_sqlalchemy.py",
> line 322, in record_metering_data
>
> 2014-06-01 22:26:41.220 32219 TRACE ceilometer.dispatcher.database
> data['source'])
>
>
>
> Am I missed anything here? Please give me some pointers to “how to use mysql
> for celometer”.
>
> It is working fine with mongoDB but failing with MYSQL with the above errors.
>
>
>
> Thanks in advance,
>
> Koteswar
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] ceilometer output not showing properly.
> Hi All, > > > ICEHOUSE with Centos KVM (Two tier ). > > While verifying the ceilometer meter-list its showing outputs but when i put > the statistics command its output is null. > > Please guide me on this. > > > > Commands: > > > [root@controller ~]# ceilometer meter-list > +-+---+---++--+--+ > | Name | Type | Unit | Resource ID | User ID | Project ID | > +-+---+---++--+--+ > | disk.ephemeral.size | gauge | GB | 05dfa5db-40c3-4002-a356-1eb530914d86 | > | 4753cf10dd5a405285412b2c499b13a6 | 863c1374386043f6a78ee9eb0bbd7adb | > | disk.ephemeral.size | gauge | GB | 1149f13d-7438-4395-92f3-86fad3a1ad4e | > | 4753cf10dd5a405285412b2c499b13a6 | 863c1374386043f6a78ee9eb0bbd7adb | > | disk.ephemeral.size | gauge | GB | 16c59c57-3074-46d5-9940-41c318caffa7 | > | 4753cf10dd5a405285412b2c499b13a6 | 863c1374386043f6a78ee9eb0bbd7adb | > > Verify the Telemetry installation > > > To test the Telemetry installation, download an image from the Image Service, > and use the ceilometer command to display usage statistics. > > > [root@controller ~]# glance image-download > "Opencascade_Centos6.3_OpenGL_OS_IMAGE" > opencascade.img > [root@controller ~]# ceilometer statistics -m image.download -p 60 > ++--++---+-+-+-+-+--++--+ > | Period | Period Start | Period End | Count | Min | Max | Sum | Avg | > | Duration | Duration Start | Duration End | > ++--++---+-+-+-+-+--++--+ > ++--++---+-+-+-+-+--++--+ > Have you configured glance to emit notifications? Can you see statistics for any other meters? Cheers, Eoghan > its not displaying the output. > > > > Regards, > Dhanesh M. > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Ceilometer unable to meter LBaaS
> Hi, > > I have a requirement to meter LBaaS using Ceilometer. > > I have installed LBaaS agent on a single node Icehouse and > I am able to administer LBaaS via Horizon. I have followed the steps > mentioned in > http://docs.openstack.org/admin-guide-cloud/content/install_neutron-lbaas-agent.html > > I have created a Load Balancer and a pool of 2 VMs under the Load Balancer. > > I am currently not able to get any LBaaS related readings on Ceilometer. > > My need is to get the LBaaS measurements mentioned in the URL > http://docs.openstack.org/developer/ceilometer/measurements.html > > I came across the URL > https://blueprints.launchpad.net/neutron/+spec/lbaas-ceilometer-integration > which says that Ceilometer will only be able to measure LBaaS in the Juno > release. > > Kindly let me know if there is a way to get Ceilometer to meter LBaaS.in > IceHouse. Well that feature was only added in the Juno timeframe. Being a feature (as opposed to a big-fix) it would not be backported to stable/icehouse branch, as per standard backporting policy in the OpenStack community. So you will need to move to Juno to take advantage of the new feature. Cheers, Eoghan > > Regards, > -- > Vivek Varghese Cherian (विवेक वर्गीस चेरियान) > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Query regarding ceilometer keystone readings.
> I am trying to enable Ceilometer meters for Keystone in IceHouse. I am > referring the url > http://docs.openstack.org/developer/ceilometer/measurements.html for the > Keystone meters. > > I am following the url > http://docs.openstack.org/developer/ceilometer/install/manual.html > and I have already created a service for ceilometer in keystone and also > Create an endpoint in keystone for ceilometer, as mentioned. > > I am not getting any keystone related meters using the ceilometer meter-list > in Icehouse. Support for those meters was only added in Juno, so would not be available in Icehouse. Note the difference between the master docs source: https://github.com/openstack/ceilometer/blob/master/doc/source/measurements.rst and the stable/icehouse version: https://github.com/openstack/ceilometer/blob/stable/icehouse/doc/source/measurements.rst Cheers, Eoghan > I would like to know if any further configuration changes at the ceilometer > and/or > keystone end is required to get the readings. Also wanted to confirm if these > measurements are for the Juno release or if they are supported in Icehouse. > > > > Regards, > -- > Vivek Varghese Cherian (विवेक वर्गीस चेरियान) > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Swift with Ceilometer
> Hello, > I wanted to get some more information on Swift with Ceilometer > integration. I see this in the documentation. > > http://docs.openstack.org/developer/ceilometer/measurements.html#object-storage-swift > > Are these the only measurements supported? Yes. > Can I get performance numbers also from Ceilometer, or any other way? What kind of performance numbers did you have in mind? > Also is there anything needed to be done to enable Ceilometer, other > than enabling the middleware? The middleware is only required in order to gather the meters related to API traffic, i.e. storage.objects.incoming.bytes storage.objects.outgoing.bytes storage.api.request The other meters are gathered by polling the swift API, so only need the swift endpoint to be available in the keystone service catalog and the ceilometer central agent to be running. Cheers, Eoghan ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Swift with Ceilometer
> Thank you:) > > I am also looking for things like PUTs/sec, GETS/sec, etc to be > available, in addition to possibly other statistics like overall > bandwidth, latency numbers for object buckets, etc. Are those sorts of > stats available? Since we meter GETs and PUTs per-tenant, we don't have direct metering of overall GETs and PUTs per-second rates (though in theory it would be possible for an administrative user to calculate such numbers via the ceilometer API). Latency OTOH is not measured for the swift API by ceilometer. Cheers, Eoghan > On Thu, Nov 6, 2014 at 11:12 PM, Eoghan Glynn wrote: > > > > > >> Hello, > >> I wanted to get some more information on Swift with Ceilometer > >> integration. I see this in the documentation. > >> > >> http://docs.openstack.org/developer/ceilometer/measurements.html#object-storage-swift > >> > >> Are these the only measurements supported? > > > > Yes. > > > >> Can I get performance numbers also from Ceilometer, or any other way? > > > > What kind of performance numbers did you have in mind? > > > >> Also is there anything needed to be done to enable Ceilometer, other > >> than enabling the middleware? > > > > The middleware is only required in order to gather the meters related to > > API traffic, i.e. > > > > storage.objects.incoming.bytes > > storage.objects.outgoing.bytes > > storage.api.request > > > > The other meters are gathered by polling the swift API, so only need the > > swift endpoint to be available in the keystone service catalog and the > > ceilometer central agent to be running. > > > > Cheers, > > Eoghan > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Ceilometer Api error in Juno
Hi,
How did you install ceilometer, using packages or direct from git?
If using packages, what OS are you working on? (Fedora, Ubuntu, CentOS etc.)
Note that the bson.code module is provided by the python-bson package on
Fedora, which is a dependency of python-pymongo, which is in turn required
by the ceilometer packages.
I suspect there is a similar dependency structure on Ubuntu.
These dependencies are generally handled by the underlying package manager,
i.e. the yum utility in the case of Fedora or CentOS.
Cheers,
Eoghan
- m channappa negalur wrote:
> Hello Geeks,
>
> I have installed three node openstack Juno. I was configuring ceilometer
> using mongodb as back end.
>
> I found my ceilometer-api is not starting and throwing some module error.
>
> root@Control:/var/log/ceilometer# tail -50 ceilometer-api.log
> 2014-11-15 12:02:02.124 23900 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/stevedore/extension.py", line 170, in
> _load_plugins
> 2014-11-15 12:02:02.124 23900 TRACE ceilometer
> self._on_load_failure_callback(self, ep, err)
> 2014-11-15 12:02:02.124 23900 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/stevedore/driver.py", line 50, in
> _default_on_load_failure
> 2014-11-15 12:02:02.124 23900 TRACE ceilometer raise err
> 2014-11-15 12:02:02.124 23900 TRACE ceilometer ImportError: No module named
> bson.code
> 2014-11-15 12:02:02.124 23900 TRACE ceilometer
> 2014-11-16 22:22:30.649 17570 CRITICAL ceilometer [-] ImportError: No module
> named bson.code
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer Traceback (most recent call
> last):
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer File
> "/usr/bin/ceilometer-api", line 10, in
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer sys.exit(main())
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/ceilometer/cmd/api.py", line 23, in main
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer srv = app.build_server()
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/ceilometer/api/app.py", line 157, in
> build_server
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer app = load_app()
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/ceilometer/api/app.py", line 153, in
> load_app
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer return
> deploy.loadapp("config:" + cfg_file)
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 247, in
> loadapp
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer return loadobj(APP, uri,
> name=name, **kw)
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 272, in
> loadobj
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer return context.create()
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in
> create
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer return
> self.object_type.invoke(self)
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 203, in
> invoke
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer app =
> context.app_context.create()
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in
> create
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer return
> self.object_type.invoke(self)
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 146, in
> invoke
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer return
> fix_call(context.object, context.global_conf, **context.local_conf)
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/paste/deploy/util.py", line 55, in fix_call
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer val = callable(*args, **kw)
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/ceilometer/api/app.py", line 181, in
> app_factory
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer return
> VersionSelectorApplication()
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/ceilometer/api/app.py", line 104, in
> __init__
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer self.v2 =
> setup_app(pecan_config=pc)
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/ceilometer/api/app.py", line 68, in
> setup_app
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer
> storage.get_connection_from_config(cfg.CONF, 'metering'),
> 2014-11-16 22:22:30.649 17570 TRACE ceilometer File
> "/usr/lib/python2.7/dist-packages/ceilometer/storage/__init__.py", line 82,
Re: [Openstack] Ceilometer Api error in Juno
You don't need to delete the sqlite DB, just configure the ceilometer.conf to use a mongodb connection URL. However it seems like you don't have all the mongodb client-side dependencies all installed. BTW how did you install mongodb? Looking at the Trusty packaging for python-ceilometer: http://packages.ubuntu.com/trusty-updates/python/python-ceilometer I see that it depends on python-pymongo: http://packages.ubuntu.com/trusty/python-pymongo which in turn depends on python-bson as expected: http://packages.ubuntu.com/trusty/python-bson Can you check if those packages are installed? $ sudo dpkg -s python-pymongo Cheers, Eoghan - m channappa negalur wrote: > Hello Eoghan, > > Thanks for your reply. I have installed Juno on Ubuntu 14.04 . > > 1.How did you install ceilometer, using packages or direct from git?. > Ans: I have installed it from Juno repsiotory. > > > I want to configure ceilometer to use mongodb as a backend. Is it require to > delete ceilometer.sqlite db under /var/lib/ceilometer and also I need to > remove it from the configuration /etc/ceilometer/ceilometer.conf.. ? > > If your answer is yes, then it will start throwing error as I mentioned below > and ceilometer-api will stop running and 8777 port will stop listening to > ceilometer-api. > > Please let me know how I can proceed further. > > > This is the error I have received again. > > ==> ceilometer-collector.log <== > 2014-11-17 13:05:26.808 937 ERROR stevedore.extension [-] Could not load > 'database': No module named bson.code > 2014-11-17 13:05:26.809 937 ERROR stevedore.extension [-] No module named > bson.code > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension Traceback (most recent > call last): > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension File > "/usr/lib/python2.7/dist-packages/stevedore/extension.py", line 162, in > _load_plugins > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension verify_requirements, > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension File > "/usr/lib/python2.7/dist-packages/stevedore/named.py", line 123, in > _load_one_plugin > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension verify_requirements, > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension File > "/usr/lib/python2.7/dist-packages/stevedore/extension.py", line 180, in > _load_one_plugin > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension obj = > plugin(*invoke_args, **invoke_kwds) > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension File > "/usr/lib/python2.7/dist-packages/ceilometer/dispatcher/database.py", line > 41, in __init__ > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension self.storage_conn = > storage.get_connection_from_config(conf) > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension File > "/usr/lib/python2.7/dist-packages/ceilometer/storage/__init__.py", line 82, > in get_connection_from_config > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension return > get_connection(url, namespace) > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension File > "/usr/lib/python2.7/dist-packages/ceilometer/storage/__init__.py", line 93, > in get_connection > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension mgr = > driver.DriverManager(namespace, engine_name) > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension File > "/usr/lib/python2.7/dist-packages/stevedore/driver.py", line 45, in __init__ > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension > verify_requirements=verify_requirements, > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension File > "/usr/lib/python2.7/dist-packages/stevedore/named.py", line 55, in __init__ > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension verify_requirements) > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension File > "/usr/lib/python2.7/dist-packages/stevedore/extension.py", line 170, in > _load_plugins > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension > self._on_load_failure_callback(self, ep, err) > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension File > "/usr/lib/python2.7/dist-packages/stevedore/driver.py", line 50, in > _default_on_load_failure > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension raise err > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension ImportError: No module > named bson.code > > > Regards, > Malleshi CN > > -Original Message- > From: Eoghan Glynn [mailto:egl...@redhat.com] > Sent: Monday, November 17, 2014 5:31 PM > To: Channappa Negalur, M. > Cc: openstack@lists.openstack.org > Subject: Re: [O
Re: [Openstack] Ceilometer Api error in Juno
> Hello Eoghan, > > I have installed mongodb using below command as per the document. Which document exactly? > 1. apt-get install mongodb-server ( this case mongodb will not be installed) > > 2. apt-get install mongodb : if I use this , mongodb-server will > automatically installed as a dependencies. I suspect install this mongodb meta-package caused mongodb-clients to installed. Whereas the actual client-side dependency that ceilometer has is on python-pymongo, as opposed mongodb-clients. This can be clearly seen from: http://packages.ubuntu.com/trusty/python-ceilometer [...] > If I won't delete sqlite db, all ceilometer data will be stored in sqlitedb. > If I am wrong correct me , because I can see the size of the file increasing > . Deleting is not the key here, rather stopping ceilometer using sql-a to store data is what you need: 1. Ensure the connection_url in the ceilometer.conf is using a mongodb URL[1] 2. Ensure the python-pymongo package is installed 3. Restart the services that use the metering store (ceilometer-api, collector and notification-agent) Cheers, Eoghan [1] http://docs.openstack.org/developer/ceilometer/install/manual.html#mongodb > root@Control:/var/lib/ceilometer# du -sh * > 312Kceilometer.sqlite > root@Control:/var/lib/ceilometer# > > > Thanks for your assistance. > > Regards, > Malleshi CN > > > -Original Message- > From: Eoghan Glynn [mailto:egl...@redhat.com] > Sent: Monday, November 17, 2014 7:17 PM > To: Channappa Negalur, M. > Cc: openstack@lists.openstack.org > Subject: RE: [Openstack] Ceilometer Api error in Juno > > > You don't need to delete the sqlite DB, just configure the ceilometer.conf to > use a mongodb connection URL. > > However it seems like you don't have all the mongodb client-side dependencies > all installed. > > BTW how did you install mongodb? > > Looking at the Trusty packaging for python-ceilometer: > > http://packages.ubuntu.com/trusty-updates/python/python-ceilometer > > I see that it depends on python-pymongo: > > http://packages.ubuntu.com/trusty/python-pymongo > > which in turn depends on python-bson as expected: > > http://packages.ubuntu.com/trusty/python-bson > > Can you check if those packages are installed? > > $ sudo dpkg -s python-pymongo > > Cheers, > Eoghan > > - m channappa negalur wrote: > > Hello Eoghan, > > > > Thanks for your reply. I have installed Juno on Ubuntu 14.04 . > > > > 1.How did you install ceilometer, using packages or direct from git?. > > Ans: I have installed it from Juno repsiotory. > > > > > > I want to configure ceilometer to use mongodb as a backend. Is it require > > to delete ceilometer.sqlite db under /var/lib/ceilometer and also I need > > to remove it from the configuration /etc/ceilometer/ceilometer.conf.. ? > > > > If your answer is yes, then it will start throwing error as I mentioned > > below and ceilometer-api will stop running and 8777 port will stop > > listening to ceilometer-api. > > > > Please let me know how I can proceed further. > > > > > > This is the error I have received again. > > > > ==> ceilometer-collector.log <== > > 2014-11-17 13:05:26.808 937 ERROR stevedore.extension [-] Could not > > load 'database': No module named bson.code > > 2014-11-17 13:05:26.809 937 ERROR stevedore.extension [-] No module > > named bson.code > > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension Traceback (most > > recent call last): > > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension File > > "/usr/lib/python2.7/dist-packages/stevedore/extension.py", line 162, in > > _load_plugins > > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension > > verify_requirements, > > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension File > > "/usr/lib/python2.7/dist-packages/stevedore/named.py", line 123, in > > _load_one_plugin > > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension > > verify_requirements, > > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension File > > "/usr/lib/python2.7/dist-packages/stevedore/extension.py", line 180, in > > _load_one_plugin > > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension obj = > > plugin(*invoke_args, **invoke_kwds) > > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension File > > "/usr/lib/python2.7/dist-packages/ceilometer/dispatcher/database.py", line > > 41, in __init__ > > 2014-11-17 13:05:26.809 937
Re: [Openstack] Ceilometer Arithmetic Transformer
> Hi all,
>
> I am using ceilometer with arithmetic transformer to combine two meters.
> Here is an extract of my pipeline.yaml (it's just a dummy test)
>
> sources:
> - name: disk_source
>interval: 600
>meters:
>- "disk.read.bytes"
>- "disk.read.requests"
>- "disk.write.bytes"
>- "disk.write.requests"
>sinks:
>- disk_sink
>- disk_read_write_sink
>
> sinks:
> - name: disk_read_write_sink
>transformers:
>- name: "arithmetic"
> parameters:
> target:
> name: "disk.read.write.bytes"
> unit: "B"
> type: "cumulative"
> expr: "2*$(disk.read.bytes) + 2*$(disk.write.bytes)"
>publishers:
>- rpc://
>
>
> I get this error:
> "Unable to perform calculation, not all of {_disk_write_bytes_ESC,
> _disk_read_bytes_ESC} are present"
That warning indicates that not all the meters referred to the expression
are available in the transformer cache when the pipeline is flushed.
It's not obvious why that's occurring in your case, as the config looks
correct.
Can I ask if both the disk.read.bytes and disk.read.bytes meters are
being successfully published via the disk_sink?
Cheers,
Eoghan
> Anyone using this transformer?
>
> Thanks!
>
> Claudio
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] memory.usage meter not displayed in ceilometer meter-list
> Hi, > > I am running a single node Juno on Ubuntu 14.04 > > I am not able to get the memory.usage ceilometer meter in Nova. > > I have made the following settings in my nova.conf file as > per the install guide > http://docs.openstack.org/juno/install-guide/install/apt/content/ceilometer-agent-nova.html > , > > instance_usage_audit=True > instance_usage_audit_period = hour > notify_on_state_change = vm_and_task_state > notification_driver = nova.openstack.common.notifier.rpc_notifier > notification_driver = ceilometer.compute.nova_notifier > > Is there any other settings I have to do in order to obtain the memory.usage > meter in Ceilometer. What versions of ceilometer, libvirt and qemu are you using? Note that this support only landed on Oct 21, 2014, so won't be in a released version until kilo: https://github.com/openstack/ceilometer/commit/a7cf24e1 Also, note the documented version and image requirements: To enable the libvirt memory.usage supporting, you need libvirt version 1.1.1+, qemu version 1.5+, and you need to prepare suitable balloon driver in the image, particularly for Windows guests, most modern Linuxes have it built in. The memory.usage meters can't be fetched without image balloon driver. Cheers, Eoghan > > Regards, > -- > Vivek Varghese Cherian > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] memory.usage meter not displayed in ceilometer meter-list
> > What versions of ceilometer, libvirt and qemu are you using? > > > > > root@juno14:~# libvirtd --version > libvirtd (libvirt) 1.2.2 > root@juno14:~# > > > root@juno14:~# ceilometer --version > 1.0.10 That's the version of the python-ceilometerclient that you've installed, as opposed to the service-side ceilometer packages. Cheers, Eoghan > root@juno14:~# > > > root@juno14:~# qemu-system-x86_64 --version > QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.6), Copyright (c) > 2003-2008 Fabrice Bellard > root@juno14:~# > > > > > Note that this support only landed on Oct 21, 2014, so won't be in a > > released version until kilo: > > > > https://github.com/openstack/ceilometer/commit/a7cf24e1 > > > > Also, note the documented version and image requirements: > > > > To enable the libvirt memory.usage supporting, you need libvirt > > version 1.1.1+, qemu version 1.5+, and you need to prepare suitable > > balloon > > driver in the image, particularly for Windows guests, most modern Linuxes > > have it built in. The memory.usage meters can't be fetched without image > > balloon driver. > > > > > Thanks Eoghan for the pointers. > > > Regards, > -- > Vivek Varghese Cherian > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Ceilometer] looking for alarm best practice - please help
> Hi folks, > > > > I wonder if anyone could share some best practice regarding to the usage of > ceilometer alarm. We are using the alarm evaluation/notification of > ceilometer and we don’t feel very well of the way we use it. Below is our > problem: > > > > > > Scenario: > > When cpu usage or memory usage above a certain threshold, alerts should be > displayed on admin’s web page. There should be a 3 level alerts according to > meter value, namely notice, warning, fatal. Notice means the meter value is > between 50% ~ 70%, warning means between 70% ~ 85% and fatal means above 85% > > For example: > > * when one vm’s cpu usage is 72%, an alert message should be displayed saying > “Warning: vm[d9b7018b-06c4-4fba-8221-37f67f6c6b8c] cpu usage is above 70%”. > > * when one vm’s memory usage is 90%, another alert message should be created > saying “Fatal: vm[d9b7018b-06c4-4fba-8221-37f67f6c6b8c] memory usage is > above 85%” > > > > Our current Solution: > > We used ceilometer alarm evaluation/notification to implement this. To > distinguish which VM and which meter is above what value, we’ve created one > alarm for each VM by each condition. So, to monitor 1 VM, 6 alarms will be > created because there are 2 meters and for each meter there are 3 levels. > That means, if there are 100 VMs to be monitored, 600 alarms will be > created. > > > > Problems: > > * The first problem is, when the number of meters increases, the number of > alarms will be multiplied. For example, customer may want alerts on disk and > network IO rates, and if we do that, there will be 4*3=12 alarms for each > VM. > > * The second problem is, when one VM is created, multiple alarms will be > created, meaning multiple http requests will be fired. In the case above, 6 > HTTP requests will be needed once a VM is created. And this number also > increases as the number of meters goes up. One way of reducing both the number of alarms and the volume of notifications would be to group related VMs, if such a concept exists in your use-case. This is effectively how Heat autoscaling uses ceilometer, alarming on the average of some statistic over a set of instances (as opposed to triggering on individual instances). The VMs could be grouped by setting user-metadata of form: nova boot ... --meta metering.my_server_group=foobar Any user-metadata prefixed with 'metering.' will be preserved by ceilometer in the resource_metadata.user_metedata stored for each sample, so that it can used to select the statistics on which the alarm is based, e.g. ceilometer alarm-threshold-create --name cpu_high_foobar \ --description 'warning: foobar instance group running hot' \ --meter-name cpu_util --threshold 70.0 \ --comparison-operator gt --statistic avg \ ... --query metadata.user_metedata.my_server_group=foobar This approach is of course predicated on the there being some natural grouping relation between instances in your environment. Cheers, Eoghan > = > > > > Do anyone have any suggestions? > > > > > > > > Best Regards! > > Kurt Rao > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] ceilometer question: metering number of running instances
> Hi all, > > I'm looking for a way of how to meter the number of running instances (per > tenant). > > Currently, the Sum value in ceilometer statistics command's output is > confusing, mostly because the high number of notifications generated by nova > for each instance. As a result, also the graph in Resource Usage view does > not > seem really useful at least for 'instances' meter. > > (See https://bugs.launchpad.net/ceilometer/+bug/1396257 for this problem) > > So, what is the correct way? Should I group the statistics output by > resource_id like > > ceilometer statistics -m instance -q 'timestamp>2014-12-03T00' -g resource_id You could use the new selectable cardinality aggregate added in icehouse, e.g. ceilometer statistics -a 'cardinality<-resource_id' \ -m instance -q 'timestamp>2014-12-03T00:00:00' which counts the number of distinct value of a particular attribute within the matching samples (in this cse, the instance UUID). Cheers, Eoghan > and just count the number of resources in this output, which should (?) be > the > number of running instances? > > Jiri > > -- > Jiri Suchomel > > SUSE LINUX, s.r.o. > Lihovarská 1060/12 > tel: +420 284 028 960 > 190 00 Praha 9, Czech Republichttp://www.suse.cz > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] ceilometer question: metering number of running instances
> > Hi all, > > > > I'm looking for a way of how to meter the number of running instances (per > > tenant). > > > > Currently, the Sum value in ceilometer statistics command's output is > > confusing, mostly because the high number of notifications generated by > > nova > > for each instance. As a result, also the graph in Resource Usage view does > > not > > seem really useful at least for 'instances' meter. > > > > (See https://bugs.launchpad.net/ceilometer/+bug/1396257 for this problem) > > > > So, what is the correct way? Should I group the statistics output by > > resource_id like > > > > ceilometer statistics -m instance -q 'timestamp>2014-12-03T00' -g > > resource_id > > You could use the new selectable cardinality aggregate added in icehouse, > e.g. > > ceilometer statistics -a 'cardinality<-resource_id' \ > -m instance -q 'timestamp>2014-12-03T00:00:00' > > which counts the number of distinct value of a particular attribute > within the matching samples (in this cse, the instance UUID). Note though that this will report the number of distinct instances that existed at *any* time within the matching time-span for the query. You could get more fine-grained numbers by bucketizing the values with a period e.g.: ceilometer statistics -a 'cardinality<-resource_id' \ -m instance -q 'timestamp>2014-12-03T00:00:00' -p 1800 for 30 minute buckets. You shouldn't set that period any tighter than the polling interval for the instance meter (600s by default) - otherwise you'll empty periods due to the lack of samples as opposed to the lack of instances. Cheers, Eoghan ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [openstack][ceilometer][webhook]
> Hello, > > > > I have a running instance of ceilometer in my system, I want to create an > alarm through ceilometer without using heat template. There is a command > line API called ceilometer alarm-create. > > > > Now I want the alarm in such a way that it will trigger an instance creation > after a value is greater than the threshold. I know that [--alarm-action > ] serves the purpose. But what should i put in the Webhook > url?? The webhook URL is simply a HTTP endpoint to which ceilometer will send a POST request when the alarm fires. > How do i generate a webhook url which will tell ceilometer to create an > instance? If you want to trigger the creation of an instance when the alarm fires, that sounds exactly like what Heat autoscaling already provides (in that case, the webhook endpoint is already provided by Heat, so you don't have to set anything up from scratch). Cheers, Eoghan > Can some body help me with regards to this web hook url? > > > > Regards, > > Subbareddy, > > Persistent systems ltd. > > > DISCLAIMER == This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Naming polls - and some issues
> >> Hey all! > >> > >> The poll emails for the P and Q naming have started to go out - and > >> we're experiencing some difficulties. Not sure at the moment what's > >> going on ... but we'll keep working on the issues and get ballots to > >> everyone as soon as we can. > > > > You'll need to re-send at least some emails, because the link I received > > is wrong - the site just reports > > > > "Your voter key is invalid. You should have received a correct URL by > > email." > > Yup. That would be a key symptom of the problems. One of the others is > that I just uploaded 3000 of the emails to the Q poll and it shows 0 > active voters. > > I think maybe it needs a nap... Any chance we could remove "Quay" from the Q release naming poll before the links are fixed and the real voting starts? Otherwise we risk looking a bit silly, since "Quay" for the Q release would be somewhat akin to choosing "Street" for the S release ;) Cheers, Eoghan ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [openstack-dev] Naming polls - and some issues
> (top posting on purpose) > > I have re-started the Q poll and am slowly adding all of you fine folks > to it. Let's keep our fingers crossed that it works this time. > > I also removed Quay. Somehow my brain didn't process the "it would be > like naming the S release "Street"" when reading the original names. > Based on the naming critera, "Circular Quay" would be a great option for > "Circular" - but sadly we already named the C release Cactus. It's > possible this choice will make someone unhappy, and if it does, I'm > certainly sorry. On the other hand, there are _so_ many awesome names > possible in this list, I don't think we'll miss it. Excellent, thanks Monty for fixing this ... agreed that the remaining Q* choices are more than enough. Cheers, Eoghan > I'll fire out new emails for P once Q is up and going. > > On 07/15/2016 11:02 AM, Jamie Lennox wrote: > > Partially because its name is Circular Quay, so it would be like calling > > the S release Street for Street. > > > > Having said that there are not that many of them and Sydney people know > > what you mean when you are going to the Quay. > > > > > > On 14 July 2016 at 21:35, Neil Jerram > <mailto:n...@tigera.io>> wrote: > > > > Not sure what the problem would be with 'Quay' or 'Street' - they > > both sound like good options to me. > > > > > > On Thu, Jul 14, 2016 at 11:29 AM Eoghan Glynn > <mailto:egl...@redhat.com>> wrote: > > > > > > > > > >> Hey all! > > > >> > > > >> The poll emails for the P and Q naming have started to go > > out - and > > > >> we're experiencing some difficulties. Not sure at the > > moment what's > > > >> going on ... but we'll keep working on the issues and get > > ballots to > > > >> everyone as soon as we can. > > > > > > > > You'll need to re-send at least some emails, because the > > link I received > > > > is wrong - the site just reports > > > > > > > > "Your voter key is invalid. You should have received a > > correct URL by > > > > email." > > > > > > Yup. That would be a key symptom of the problems. One of the > > others is > > > that I just uploaded 3000 of the emails to the Q poll and it > > shows 0 > > > active voters. > > > > > > I think maybe it needs a nap... > > > > Any chance we could remove "Quay" from the Q release naming poll > > before > > the links are fixed and the real voting starts? > > > > Otherwise we risk looking a bit silly, since "Quay" for the Q > > release > > would be somewhat akin to choosing "Street" for the S release ;) > > > > Cheers, > > Eoghan > > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > > > <http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [openstack-dev] [User-committee] Boston Forum - Formal Submission Now Open!
Thanks for putting this together! But one feature gap is some means to tag topic submissions, e.g. tagging the project-specific topics by individual project relevance. That could be a basis for grouping topics, to allow folks to better manage their time during the Forum. (e.g. if someone was mostly interested in say networking issues, they could plan to attend all the neutron- and kuryr-tagged topics more easily if those slots were all scheduled in a near-contiguous block with minimal conflicts) On Mon, Mar 20, 2017 at 9:49 PM, Emilien Macchi wrote: > +openstack-dev mailing-list. > > On Mon, Mar 20, 2017 at 3:55 PM, Melvin Hillsman wrote: >> Hey everyone! >> >> We have made it to the next stage of the topic selection process for the >> Forum in Boston. >> >> Starting today, our submission tool is open for you to submit abstracts for >> the most popular sessions that came out of your brainstorming. Please note >> that the etherpads are not being pulled into the submission tool and >> discussion around which sessions to submit are encouraged. >> >> We are asking all session leaders to submit their abstracts at: >> >> http://forumtopics.openstack.org/ >> >> before 11:59PM UTC on Sunday April 2nd! >> >> We are looking for a good mix of project-specific, cross-project or >> strategic/whole-of-community discussions, and sessions that emphasize >> collaboration between users and developers are most welcome! >> >> We assume that anything submitted to the system has achieved a good amount >> of discussion and consensus that it is a worthwhile topic. After submissions >> close, a team of representatives from the User Committee, the Technical >> Committee, and Foundation staff will take the sessions proposed by the >> community and fill out the schedule. >> >> You can expect the draft schedule to be released on April 10th. >> >> Further details about the Forum can be found at: >> https://wiki.openstack.org/wiki/Forum >> >> Regards, >> >> OpenStack User Committee >> >> >> ___ >> User-committee mailing list >> user-commit...@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee >> > > > > -- > Emilien Macchi > > __ > 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 ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
