<div dir="ltr"><p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">Hi Joseph,</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">Thanks for your comments.</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">What I understand is that we can always assume that Vitrage
gets from Monasca enough dimensions to identify the resource in Vitrage, and
the challenge is to define a mechanism for correlating the Monasca dimensions
with Vitrage resource properties. </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">I thought of a possible solution. We can write in Vitrage
a configuration file, which defines for every metric which dimension(s) from
Monsaca should be mapped to which property in Vitrage in order to uniquely identify
the resource. For example, for libvirt metrics, ‘resource_id’ dimension should
be mapped to ‘id’ in Vitrage. </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">A draft of the file structure:</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">* metric_name: the name of the metric in Monasca</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">* vitrage_property: the name of a property to match in the
Vitrage resource</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">* vitrage_property_value: the value to match based on the
dimensions coming from Monasca</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">For example:</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">config:</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> - metric_name: low_disk_space</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">
vitrage_property: id</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">
vitrage_property_value: ${resource_id} #
resource_id is the dimension of libvirt metrics</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> - metric_name:
low_disk_space</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">
vitrage_property: id</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">
vitrage_property_value: ${hosname} #
in case the disk_space is monitored for a host (?)</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> - metric_name:
http_status</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">
vitrage_property: service_id</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">
vitrage_property_value: ${hostname}/${service}</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> - metric_name: nic_status</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">
vitrage_property: id</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> vitrage_property_value:
${hostname}/${nic_name}</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt 27pt;font-family:Calibri">-<span style="font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:"Times New Roman"">
</span><span dir="LTR"></span>…</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">What do you think?</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">Can a metric like low_disk_space be set both for an
instance (with a resource_id that is uuid) and for a host (with hostname)? How can
we tell which dimension to use?</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">Do you think that this configuration can solve the POC
use case?</p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri"> </p>
<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-family:Calibri">Ifat</p><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 15, 2018 at 5:50 AM Joseph Davis <<a href="mailto:joseph.davis@suse.com">joseph.davis@suse.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I left Bartosz some comments on his review, and I'll add a few things below.<br>
<br>
joseph<br>
<br>
On 12/13/18 12:52 AM, <a href="mailto:openstack-discuss-request@lists.openstack.org" target="_blank">openstack-discuss-request@lists.openstack.org</a> wrote<br>
> From: Ifat Afek <<a href="mailto:ifatafekn@gmail.com" target="_blank">ifatafekn@gmail.com</a>><br>
> Message-ID:<br>
> <<a href="mailto:CALxdkcxxrtYYv%2Bf4-enZ2uuA88qJdPuze732Ufg6MLMADBcOtg@mail.gmail.com" target="_blank">CALxdkcxxrtYYv+f4-enZ2uuA88qJdPuze732Ufg6MLMADBcOtg@mail.gmail.com</a>><br>
><br>
> Hi Witek,<br>
><br>
> On Wed, Dec 12, 2018 at 5:04 PM Bedyk, Witold <<a href="mailto:witold.bedyk@est.fujitsu.com" target="_blank">witold.bedyk@est.fujitsu.com</a>><br>
> wrote:<br>
><br>
><br>
>>> There is one issue that we need to close though – how to connect the<br>
>>> Monasca alarms to the resources in Vitrage.<br>
>>> In order to connect an alarm to a resource, Vitrage should be able to<br>
>>> identify that resource in its entity graph using the dimensions coming from<br>
>>> Monasca. I understood that these dimensions are configurable and not<br>
>>> pre-defined.<br>
>> Correct. To make the picture complete: every alarm contains an associated<br>
>> `metric name` and a set of dimensions which identify the monitored<br>
>> resource. Both metric name and dimensions could potentially be used in<br>
>> Vitrage.<br>
>><br>
>><br>
>><br>
>> 1. For OpenStack services we typically use dimension keys `hostname` and<br>
>> `service`. Examples would be:<br>
>><br>
>> `name`: `http_status`, `dimensions`: {`hostname`: `node1`,<br>
>> `service`: `keystone`, `url`: `<a href="http://node1/identity" rel="noreferrer" target="_blank">http://node1/identity`</a><br>
>> <<a href="http://node1/identity" rel="noreferrer" target="_blank">http://node1/identity</a>>}<br>
>><br>
>><br>
>><br>
>> Libvirt metrics all have the dimension keys `hostname`,<br>
>> `service`=`compute`, `resource_id`=instance_id<br>
>><br>
><br>
> By instance_id do you mean the libvirt id or the OpenStack UUID? In order<br>
> to correlate the id with the vm that exists in Vitrage, we need the Nova<br>
> UUID.<br>
> Another question: are these dimensions names always the same? Is it<br>
> possible to change their names?<br>
><br>
I believe it is the OpenStack id in each case.<br>
<br>
Dimension names are always the same per type of metric, but different <br>
metrics can define different dimensions.<br>
<br>
For example, the http_status metric has a 'url' but disk.space_used_perc <br>
has a 'device' and cpu.idle_perc has neither. All metrics have <br>
'hostname', 'service', and a few other dimensions in common.<br>
<br>
>> 2. For other resources I’m not sure if we can define a general rule for<br>
>> assignments. As you have said, the unique information may be included in<br>
>> more the one dimension.<br>
>><br>
>><br>
>><br>
>> For Prometheus, we use labels on each metric as dimensions. Additional<br>
>> dimensions can be configured in agent per Prometheus endpoint.<br>
>><br>
We also have a monasca-ceilometer component (aka. Ceilosca) that can <br>
send metrics from Ceilometer to Monasca. These metrics include the <br>
OpenStack resource_id of the source of the metric. Any alarms created <br>
from Ceilometer data can carry through that resource_id. From what I've <br>
seen we don't currently include a resource_type, but that should be <br>
something we can configure in the metric. If nothing else, we may be <br>
able to statically define the resource_type as part of the metric <br>
definition (each alarm will be specific to the type of resource <br>
anyway). But don't hold me to that - I have some more reading to do to <br>
understand the nuances. :) The dimensions from the metrics are carried <br>
over to the alarms.<br>
> <snip><br>
> Can you give us some more examples of Monasca dimensions?<br>
<br>
As Witek said, the metric dimensions are pretty flexible. You can see <br>
some of the dimensions mentioned in my answer above. I can try to pull a <br>
list of some standard alarm definitions and associated metrics from a <br>
SUSE install, or if we have a particular few alarms we want to start <br>
with then we can focus on those.<br>
<br>
<br>
</blockquote></div></div>