Open Stack

I left Bartosz some comments on his review, and I'll add a few things below.

joseph

On 12/13/18 12:52 AM, openstack-discuss-request at lists.openstack.org wrote
> From: Ifat Afek <ifatafekn at gmail.com>
> Message-ID:
> 	<CALxdkcxxrtYYv+f4-enZ2uuA88qJdPuze732Ufg6MLMADBcOtg at mail.gmail.com>
>
> Hi Witek,
>
> On Wed, Dec 12, 2018 at 5:04 PM Bedyk, Witold <witold.bedyk at est.fujitsu.com>
> wrote:
>
>
>>> There is one issue that we need to close though – how to connect the
>>> Monasca alarms to the resources in Vitrage.
>>> In order to connect an alarm to a resource, Vitrage should be able to
>>> identify that resource in its entity graph using the dimensions coming from
>>> Monasca. I understood that these dimensions are configurable and not
>>> pre-defined.
>> Correct. To make the picture complete: every alarm contains an associated
>> `metric name` and a set of dimensions which identify the monitored
>> resource. Both metric name and dimensions could potentially be used in
>> Vitrage.
>>
>>
>>
>> 1. For OpenStack services we typically use dimension keys `hostname` and
>> `service`. Examples would be:
>>
>>                  `name`: `http_status`, `dimensions`: {`hostname`: `node1`,
>> `service`: `keystone`, `url`: `http://node1/identity`
>> <http://node1/identity>}
>>
>>
>>
>> Libvirt metrics all have the dimension keys `hostname`,
>> `service`=`compute`, `resource_id`=instance_id
>>
>
> By instance_id do you mean the libvirt id or the OpenStack UUID? In order
> to correlate the id with the vm that exists in Vitrage, we need the Nova
> UUID.
> Another question: are these dimensions names always the same? Is it
> possible to change their names?
>
I believe it is the OpenStack id in each case.

Dimension names are always the same per type of metric, but different 
metrics can define different dimensions.

For example, the http_status metric has a 'url' but disk.space_used_perc 
has a 'device' and cpu.idle_perc has neither.  All metrics have 
'hostname', 'service', and a few other dimensions in common.

>> 2. For other resources I’m not sure if we can define a general rule for
>> assignments. As you have said, the unique information may be included in
>> more the one dimension.
>>
>>
>>
>> For Prometheus, we use labels on each metric as dimensions. Additional
>> dimensions can be configured in agent per Prometheus endpoint.
>>
We also have a monasca-ceilometer component (aka. Ceilosca) that can 
send metrics from Ceilometer to Monasca. These metrics include the 
OpenStack resource_id of the source of the metric. Any alarms created 
from Ceilometer data can carry through that resource_id. From what I've 
seen we don't currently include a resource_type, but that should be 
something we can configure in the metric. If nothing else, we may be 
able to statically define the resource_type as part of the metric 
definition (each alarm will be specific to the type of resource 
anyway).  But don't hold me to that - I have some more reading to do to 
understand the nuances. :) The dimensions from the metrics are carried 
over to the alarms.
> <snip>
> Can you give us some more examples of Monasca dimensions?

As Witek said, the metric dimensions are pretty flexible. You can see 
some of the dimensions mentioned in my answer above. I can try to pull a 
list of some standard alarm definitions and associated metrics from a 
SUSE install, or if we have a particular few alarms we want to start 
with then we can focus on those.