settingsLogin | Registersettings

[Openstack-operators] [openstack-operators][Ceilometer vs Monasca] Alarms: Ceilometer vs Monasca

0 votes

Hi,

i have a question about alarms in openstack.

I want autoscaling with heat, and I'm looking for metric/alarm project
which I can use with heat.
I found that I can use Monasca or Ceilometer (with Aodh).
My question is:
Is any of you using heat (autoscaling) in production?
If yes what are you using (Monasca, Ceilometer, other) for metric and
alarms, and why?

--
Pozdrawiam,
Krzysztof Świątek


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
asked Aug 16, 2017 in openstack-operators by Krzysztof_Świątek (120 points)   1 1

2 Responses

0 votes

Hi,

I use Aodh + Gnocchi for autoscaling. I also use Mistral + Zaqar for
auto-healing. See the example below, hope it helps.

Main template:

(...)
mongocluster:
type: OS::Heat::AutoScalingGroup
properties:
cooldown: 60
desiredcapacity: 2
max
size: 3
minsize: 1
resource:
type: ./mongocluster.yaml
properties:
network: { get
attr: [ voicisnetwork, beomnet ] }
flavor: { get
param: flavor }
image: { getparam: image }
key
name: { getparam: keyname }
basemgmtsecuritygroup: { getattr: [ securitygroups,
base
mgmt ] }
mongodbsecuritygroup: { getattr: [ securitygroups, mongodb ] }
rootstackid: {getparam: "OS::stackid"}
metadata: {"metering.servergroup": {getparam: "OS::stack_id"}}

mongodbscaleuppolicy:
type: OS::Heat::ScalingPolicy
properties:
adjustmenttype: changeincapacity
auto
scalinggroupid: {getresource: mongocluster}
cooldown: 60
scaling
adjustment: 1

mongodbscaledownpolicy:
type: OS::Heat::ScalingPolicy
properties:
adjustmenttype: changeincapacity
auto
scalinggroupid: {getresource: mongocluster}
cooldown: 60
scaling
adjustment: -1

cpualarmhigh:
type: OS::Aodh::GnocchiAggregationByResourcesAlarm
properties:
description: Scale-up if the average CPU > 95% for 1 minute
metric: cpuutil
aggregation
method: mean
granularity: 300
evaluationperiods: 1
threshold: 80
resource
type: instance
comparisonoperator: gt
alarm
actions:
- strreplace:
template: trust+url
params:
url: {get
attr: [mongodbscaleuppolicy, signalurl]}
query:
str
replace:
template: '{"=": {"servergroup": "stackid"}}'
params:
stackid: {getparam: "OS::stack_id"}

cpualarmlow:
type: OS::Aodh::GnocchiAggregationByResourcesAlarm
properties:
metric: cpuutil
aggregation
method: mean
granularity: 300
evaluationperiods: 1
threshold: 5
resource
type: instance
comparisonoperator: lt
alarm
actions:
- strreplace:
template: trust+url
params:
url: {get
attr: [mongodbscaledownpolicy, signalurl]}
query:
str
replace:
template: '{"=": {"servergroup": "stackid"}}'
params:
stackid: {getparam: "OS::stack_id"}

outputs:
mongostackid:
description: UUID of the cluster nested stack
value: {getresource: mongocluster}
scale
upurl:
description: >
This URL is the webhook to scale up the autoscaling group. You
can invoke the scale-up operation by doing an HTTP POST to this
URL; no body nor extra headers are needed.
value: {get
attr: [mongodbscaleuppolicy, alarmurl]}
scale
dnurl:
description: >
This URL is the webhook to scale down the autoscaling group.
You can invoke the scale-down operation by doing an HTTP POST to
this URL; no body nor extra headers are needed.
value: {get
attr: [mongodbscaledownpolicy, alarmurl]}
ceilometer
query:
value:
strreplace:
template: >
ceilometer statistics -m cpu
util
-q metadata.usermetadata.stack=stackval -p 60 -a avg
params:
stackval: { get
param: "OS::stackid" }
description: >
This is a Ceilometer query for statistics on the cpu
util meter
Samples about OS::Nova::Server instances in this stack. The -q
parameter selects Samples according to the subject's metadata.
When a VM's metadata includes an item of the form metering.X=Y,
the corresponding Ceilometer resource has a metadata item of the
form usermetadata.X=Y and samples about resources so tagged can
be queried with a Ceilometer query term of the form
metadata.user
metadata.X=Y. In this case the nested stacks give
their VMs metadata that is passed as a nested stack parameter,
and this stack passes a metadata of the form metering.stack=Y,
where Y is this stack's ID.

mongocluster.yaml

heattemplateversion: ocata

description: >
MongoDB cluster node

metadata:
type: json

rootstackid:
type: string
default: ""

conditions:
isstandalone: {equals: [{getparam: rootstackid}, ""]}

resources:

mongodbserver:
type: OS::Nova::Server
properties:
name: { strreplace: { params: { randomstring: { getresource:
random
str }, zone: { getparam: zone } }, template:
mongodb-random
string.zone } }
image: { getparam: image }
flavor: { get
param: flavor }
metadata: {getparam: metadata}
key
name: { getparam: keyname }
networks:
- port: { getresource: omport }
userdataformat: SOFTWARECONFIG
user
data: { getresource: serverclu_init }

alarm_queue:
type: OS::Zaqar::Queue

erroreventalarm:
type: OS::Aodh::EventAlarm
properties:
eventtype: compute.instance.update
query:
- field: traits.instance
id
value: {getresource: mongodbserver}
op: eq
- field: traits.state
value: error
op: eq
alarm
queues:
- {getresource: alarmqueue}

deletedeventalarm:
type: OS::Aodh::EventAlarm
properties:
eventtype: compute.instance.delete.start
query:
- field: traits.instance
id
value: {getresource: mongodbserver}
op: eq
alarm
queues:
- {getresource: alarmqueue}

alarmcachewait:
type: OS::Heat::TestResource
properties:
actionwaitsecs:
create: 60
update: 60
value:
listjoin:
- ''
- - {get
attr: [erroreventalarm, show]}
- {getattr: [deletedevent_alarm, show]}

alarmsubscription:
type: OS::Zaqar::MistralTrigger
properties:
queue
name: {getresource: alarmqueue}
workflowid: {getresource: autoheal}
input:
stackid: {getparam: "OS::stackid"}
root
stackid:
if:
- is
standalone
- {getparam: "OS::stackid"}
- {getparam: "rootstack_id"}

autoheal:
type: OS::Mistral::Workflow
properties:
description: >
Mark a server as unhealthy and commence a stack update to replace
it.
input:
stackid:
root
stackid:
type: direct
tasks:
- name: resources
markunhealthy
action:
list
join:
- ' '
- - heat.resourcesmarkunhealthy
- stackid=<% $.stack_id %>
- resource
name=<% env().notification.body.reason_data.event.traits.where($[0] = 'instance_id').select($[2]).first() %>
- markunhealthy=true
- resource
statusreason='Marked by alarm'
on
success:
- stacksupdate
- name: stacks
update
action: heat.stacksupdate stackid=<% $.root_stack_id %>
existing=true

outputs:
privatemgmtip:
description: IP address in private management network
value: { getattr: [ beomport, fixedips, 0, ipaddress ] }
internal
ip:
description: IP address in private rt network
value: { getattr: [ bertport, fixedips, 0, ipaddress ] }
OS::stack
id:
description: The server UUID
value: {getresource: mongodbserver}
condition: {not: is
standalone}

Best Regards

On Wed, Aug 16, 2017 at 1:44 PM, Krzysztof Świątek <
krzysztof.swiatek@corp.ovh.com> wrote:

Hi,

i have a question about alarms in openstack.

I want autoscaling with heat, and I'm looking for metric/alarm project
which I can use with heat.
I found that I can use Monasca or Ceilometer (with Aodh).
My question is:
Is any of you using heat (autoscaling) in production?
If yes what are you using (Monasca, Ceilometer, other) for metric and
alarms, and why?

--
Pozdrawiam,
Krzysztof Świątek


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


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Aug 16, 2017 by Pedro_Sousa (1,760 points)   6 11
0 votes

On Wed, Aug 16, 2017 at 6:44 AM, Krzysztof Świątek
krzysztof.swiatek@corp.ovh.com wrote:
Hi,

i have a question about alarms in openstack.

I want autoscaling with heat, and I'm looking for metric/alarm project
which I can use with heat.
I found that I can use Monasca or Ceilometer (with Aodh).
My question is:
Is any of you using heat (autoscaling) in production?
If yes what are you using (Monasca, Ceilometer, other) for metric and
alarms, and why?

I don't think many people know that Monasca can be used with heat for
autoscaling, so it's good that you know. :)

That said, I think it's fairly safe to say that the most common of the
two in production for autoscaling will be ceilometer, and that is the
only one I've used in production. So, it's not to say that one is
better than the other, but rather that Ceilometer is more commonly
used. If it was me I would probably use Ceilometer unless I knew I
also wanted to provide monitoring as a service to my end users and did
not need to provide telemetry to them. Usually ceilometer is useful in
other areas, such as billing, etc.

Ceilometer and it's related systems have changed a lot recently for
the better to separate out some components into other projects like
panko and gnocchi and aodh. There are definitely retention and backend
storage type and tuning that have to be considered.

Thanks,
Curtis.

--
Pozdrawiam,
Krzysztof Świątek


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

--
Blog: serverascode.com


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Aug 17, 2017 by Curtis (4,180 points)   2 4
...