)]}'
{"specs/stein/approved/map-monasca-dimensions.rst":[{"author":{"_account_id":28695,"name":"Bartosz Zurkowski","email":"b.zurkowski@samsung.com","username":"b.zurkowski"},"change_message_id":"79b511b3fc085ab9d6665f4a1261abca756511c7","unresolved":false,"context_lines":[{"line_number":32,"context_line":"is connected with an ``on`` edge to the right resource in the graph."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Alarms based on libvirt metrics"},{"line_number":36,"context_line":"-------------------------------"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"All libvirt alarms have the following dimensions:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_1f94f943","line":35,"updated":"2018-12-25 14:12:34.000000000","message":"From standard use cases. Do you think we could associate Nova hosts in Vitrage Entity Graph by \"hostname\" dimension collected as System metrics [1]?\n\n[1] https://github.com/openstack/monasca-agent/blob/master/docs/Plugins.md#system-metrics","commit_id":"f3a63c0a85832e5712eaef590dd12c2a4b80f206"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"efa1e7985633de22f487d042fd8b677917bdcb27","unresolved":false,"context_lines":[{"line_number":32,"context_line":"is connected with an ``on`` edge to the right resource in the graph."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Alarms based on libvirt metrics"},{"line_number":36,"context_line":"-------------------------------"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"All libvirt alarms have the following dimensions:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_bf994520","line":35,"in_reply_to":"1f769fc5_1f94f943","updated":"2018-12-25 17:12:30.000000000","message":"Sorry, I didn\u0027t understand the question. Is there a reason why we shouldn\u0027t be able to do it? do you think I should add system metrics as a separate section in the document?","commit_id":"f3a63c0a85832e5712eaef590dd12c2a4b80f206"},{"author":{"_account_id":28695,"name":"Bartosz Zurkowski","email":"b.zurkowski@samsung.com","username":"b.zurkowski"},"change_message_id":"79b511b3fc085ab9d6665f4a1261abca756511c7","unresolved":false,"context_lines":[{"line_number":39,"context_line":""},{"line_number":40,"context_line":"* hostname"},{"line_number":41,"context_line":"* service: always ``compute``"},{"line_number":42,"context_line":"* resource_id: the OpenStack UUID of the instance (always?)"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Alarms based on libvirt CPU metrics"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_bf3b859a","line":42,"range":{"start_line":42,"start_character":51,"end_line":42,"end_character":58},"updated":"2018-12-25 14:12:34.000000000","message":"According to documentation [1] YES:\n\n All metrics include resource_id and zone (availability zone) dimensions\n\n[1] https://github.com/openstack/monasca-agent/blob/master/docs/Libvirt.md#vm-dimensions","commit_id":"f3a63c0a85832e5712eaef590dd12c2a4b80f206"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"efa1e7985633de22f487d042fd8b677917bdcb27","unresolved":false,"context_lines":[{"line_number":39,"context_line":""},{"line_number":40,"context_line":"* hostname"},{"line_number":41,"context_line":"* service: always ``compute``"},{"line_number":42,"context_line":"* resource_id: the OpenStack UUID of the instance (always?)"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Alarms based on libvirt CPU metrics"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_5f9ef107","line":42,"range":{"start_line":42,"start_character":51,"end_line":42,"end_character":58},"in_reply_to":"1f769fc5_bf3b859a","updated":"2018-12-25 17:12:30.000000000","message":"Done","commit_id":"f3a63c0a85832e5712eaef590dd12c2a4b80f206"},{"author":{"_account_id":28695,"name":"Bartosz Zurkowski","email":"b.zurkowski@samsung.com","username":"b.zurkowski"},"change_message_id":"79b511b3fc085ab9d6665f4a1261abca756511c7","unresolved":false,"context_lines":[{"line_number":49,"context_line":""},{"line_number":50,"context_line":".. code-block:: json"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"  {"},{"line_number":53,"context_line":"    \u0027name\u0027: \u0027cpu.utilization_perc\u0027,"},{"line_number":54,"context_line":"    \u0027dimensions\u0027: {"},{"line_number":55,"context_line":"      \u0027hostname\u0027: \u0027node1\u0027,"},{"line_number":56,"context_line":"      \u0027service\u0027: \u0027compute\u0027,"},{"line_number":57,"context_line":"      \u0027resource_id\u0027: \u0027202c983a-70bf-435d-baaa-d0ea910cf8fd\u0027"},{"line_number":58,"context_line":"    }"},{"line_number":59,"context_line":"  }"},{"line_number":60,"context_line":""},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"**Vitrage resource**"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_5f5911fc","line":59,"range":{"start_line":52,"start_character":0,"end_line":59,"end_character":3},"updated":"2018-12-25 14:12:34.000000000","message":"Maybe a good idea would be to include full alarm response somewhere in the scope of this spec. A separate section before the case study titled \"Monasca alarm structure\" - what do you think?\n\nPresented JSON snippets without prior mention about full alarm structure are a little bit misleading, e.g. they do not point that the dimensions are nested in the \"metrics\" field and that there may be multiple metrics associated with given alarm.\n\n[1] https://github.com/openstack/monasca-api/blob/master/docs/monasca-api-spec.md#response-examples-19","commit_id":"f3a63c0a85832e5712eaef590dd12c2a4b80f206"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"efa1e7985633de22f487d042fd8b677917bdcb27","unresolved":false,"context_lines":[{"line_number":49,"context_line":""},{"line_number":50,"context_line":".. code-block:: json"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"  {"},{"line_number":53,"context_line":"    \u0027name\u0027: \u0027cpu.utilization_perc\u0027,"},{"line_number":54,"context_line":"    \u0027dimensions\u0027: {"},{"line_number":55,"context_line":"      \u0027hostname\u0027: \u0027node1\u0027,"},{"line_number":56,"context_line":"      \u0027service\u0027: \u0027compute\u0027,"},{"line_number":57,"context_line":"      \u0027resource_id\u0027: \u0027202c983a-70bf-435d-baaa-d0ea910cf8fd\u0027"},{"line_number":58,"context_line":"    }"},{"line_number":59,"context_line":"  }"},{"line_number":60,"context_line":""},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"**Vitrage resource**"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_1fb15990","line":59,"range":{"start_line":52,"start_character":0,"end_line":59,"end_character":3},"in_reply_to":"1f769fc5_5f5911fc","updated":"2018-12-25 17:12:30.000000000","message":"Done","commit_id":"f3a63c0a85832e5712eaef590dd12c2a4b80f206"},{"author":{"_account_id":28695,"name":"Bartosz Zurkowski","email":"b.zurkowski@samsung.com","username":"b.zurkowski"},"change_message_id":"79b511b3fc085ab9d6665f4a1261abca756511c7","unresolved":false,"context_lines":[{"line_number":71,"context_line":""},{"line_number":72,"context_line":".. code-block:: json"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"  {"},{"line_number":75,"context_line":"    \u0027name\u0027: \u0027disk.allocation\u0027,"},{"line_number":76,"context_line":"    \u0027dimensions\u0027: {"},{"line_number":77,"context_line":"      \u0027hostname\u0027: \u0027node1\u0027,"},{"line_number":78,"context_line":"      \u0027service\u0027: \u0027compute\u0027,"},{"line_number":79,"context_line":"      \u0027resource_id\u0027: \u0027202c983a-70bf-435d-baaa-d0ea910cf8fd\u0027"},{"line_number":80,"context_line":"      \u0027device\u0027: \u0027/dev/sda1\u0027,"},{"line_number":81,"context_line":"    }"},{"line_number":82,"context_line":"  }"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"**Vitrage resource**"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_7f2c0d47","line":82,"range":{"start_line":74,"start_character":0,"end_line":82,"end_character":3},"updated":"2018-12-25 14:12:34.000000000","message":"As pointed out above, since alarm definitions may be based on multiple metrics (e.g. avg(cpu) \u003e 60% and disk usage \u003e 40%), there may be multiple metrics associated with raised alarm.\n\nExample:\n\n    {\n        \"elements\": [\n            {\n                \"id\": \"f9935bcc-9641-4cbf-8224-0993a947ea83\",\n                \"alarm_definition\": {\n                    ...\n                },\n                \"metrics\": [\n                    {\n                        \"name\": \"cpu.some_metric\",\n                        \"dimensions\": {\n                            \"hostname\": \"devstack\",\n                            ...\n                        }\n                    },\n                    {\n                        \"name\": \"disk.some_metric\",\n                        \"dimensions\": {\n                            \"hostname\": \"devstack\",\n                            ...\n                        }\n                    },\n                    ...\n                ],\n                \"state\": \"OK\",\n                ...\n            }\n        ]\n    }\n\nWe should elaborate a way to identify Vitrage entity from multiple metrics.\n\nFrom what I understood reading through SIG conversations and analyzing Monasca docs: dimensions of each metric uniquely describe given resource (Witold, please confirm).\n\nIt is not fully clear for me, however, whether alarm is raised always on single resource. Monasca documentation seems to state otherwise [1]. Witold, could you discuss about this? If one defines alarm without match_by option does it mean that alarm is raised only once and aggregates multiple resources - implicates that alarm metrics will point to different resources?\n\nI already started drafting the code. The approach that I propose is to iterate through alarm metrics until given metric allows to identify entity in Vitrage Graph (we have some mapping defined in the code).\n\nPseudo code:\n\n    def find_associated_entity(alarm):\n        for metric in alarm[\u0027metrics\u0027]:\n            vitrage_entity \u003d identify_entity_from_metric(metric)\n            if vitrage_entity:\n                return vitrage_entity\n\n\n    def identify_entity_from_metric(metric):\n        name \u003d metric[\u0027name\u0027]\n        dims \u003d metric[\u0027dimensions\u0027]\n        if \u0027resource_type\u0027 in dims and \u0027resource_id\u0027 in dims:\n            return (dims[\u0027resource_type\u0027], dims[\u0027resource_id\u0027])\n        mapping \u003d ALARM_METRICS_MAPPING.get(name)\n        if mapping:\n            return (dims[mapping[\u0027resource_type\u0027]], dims[mapping[\u0027resource_id\u0027]])\n\n[1] https://github.com/openstack/monasca-api/blob/master/docs/monasca-api-spec.md#alarm-definitions-and-alarms","commit_id":"f3a63c0a85832e5712eaef590dd12c2a4b80f206"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"efa1e7985633de22f487d042fd8b677917bdcb27","unresolved":false,"context_lines":[{"line_number":71,"context_line":""},{"line_number":72,"context_line":".. code-block:: json"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"  {"},{"line_number":75,"context_line":"    \u0027name\u0027: \u0027disk.allocation\u0027,"},{"line_number":76,"context_line":"    \u0027dimensions\u0027: {"},{"line_number":77,"context_line":"      \u0027hostname\u0027: \u0027node1\u0027,"},{"line_number":78,"context_line":"      \u0027service\u0027: \u0027compute\u0027,"},{"line_number":79,"context_line":"      \u0027resource_id\u0027: \u0027202c983a-70bf-435d-baaa-d0ea910cf8fd\u0027"},{"line_number":80,"context_line":"      \u0027device\u0027: \u0027/dev/sda1\u0027,"},{"line_number":81,"context_line":"    }"},{"line_number":82,"context_line":"  }"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"**Vitrage resource**"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_1f7639da","line":82,"range":{"start_line":74,"start_character":0,"end_line":82,"end_character":3},"in_reply_to":"1f769fc5_7f2c0d47","updated":"2018-12-25 17:12:30.000000000","message":"Thanks for the example, I wasn\u0027t aware of it. I\u0027ll be happy to hear from Witek about real use cases where different metrics are used, and whether the metrics are defined on the same resource or not.\n\nRegarding the pseudo code - where did you implement it? in the driver? what I have in mind is to make the decision in a configuration file and not in the code, to make it more flexible. If you already thought of another solution then let\u0027s discuss it.\n\n(in any case, the first step as Witek suggested should be to document the use cases).","commit_id":"f3a63c0a85832e5712eaef590dd12c2a4b80f206"},{"author":{"_account_id":28695,"name":"Bartosz Zurkowski","email":"b.zurkowski@samsung.com","username":"b.zurkowski"},"change_message_id":"79b511b3fc085ab9d6665f4a1261abca756511c7","unresolved":false,"context_lines":[{"line_number":109,"context_line":""},{"line_number":110,"context_line":"**Vitrage resource**"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"Vitrage resource should be identified by the ``device`` dimension (?)"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Ceilometer metrics"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_1ff879c2","line":112,"range":{"start_line":112,"start_character":0,"end_line":112,"end_character":16},"updated":"2018-12-25 14:12:34.000000000","message":"In my opinion, all we can do for now regarding system metrics (CPU, disk, network) is to raise alarm on VM.","commit_id":"f3a63c0a85832e5712eaef590dd12c2a4b80f206"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"efa1e7985633de22f487d042fd8b677917bdcb27","unresolved":false,"context_lines":[{"line_number":109,"context_line":""},{"line_number":110,"context_line":"**Vitrage resource**"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"Vitrage resource should be identified by the ``device`` dimension (?)"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Ceilometer metrics"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_ff2a5d8e","line":112,"range":{"start_line":112,"start_character":0,"end_line":112,"end_character":16},"in_reply_to":"1f769fc5_1ff879c2","updated":"2018-12-25 17:12:30.000000000","message":"Done","commit_id":"f3a63c0a85832e5712eaef590dd12c2a4b80f206"},{"author":{"_account_id":10311,"name":"Joseph Davis","email":"joseph.davis@suse.com","username":"joadavis"},"change_message_id":"2733bfaf0aa60d660058b2f89c06e4f0910c8d49","unresolved":false,"context_lines":[{"line_number":191,"context_line":""},{"line_number":192,"context_line":"Ceilometer metrics"},{"line_number":193,"context_line":"------------------"},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"**Monasca alarm**"},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"All Ceilometer metrics have a ``resource_id`` dimension that holds the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffd0ebdf_0262563f","line":194,"updated":"2019-01-04 16:38:51.000000000","message":"Being an engineer who worked on it, I\u0027d be inclined to add a note here that Ceilometer metrics only come through Monasca alarms if the monasca-ceilometer feature is used, and include a link to Ceilosca wiki.  But that might be distracting from the focus of this spec.","commit_id":"472589a37f76508ff764ff4f7c4af3c8bda42033"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"ed1087091738c66cc5cf71c2cca828448a44ad5c","unresolved":false,"context_lines":[{"line_number":191,"context_line":""},{"line_number":192,"context_line":"Ceilometer metrics"},{"line_number":193,"context_line":"------------------"},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"**Monasca alarm**"},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"All Ceilometer metrics have a ``resource_id`` dimension that holds the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_64f7c7f7","line":194,"in_reply_to":"ffd0ebdf_0262563f","updated":"2019-01-07 08:17:29.000000000","message":"I think we can definitely add a link to Ceilosca","commit_id":"472589a37f76508ff764ff4f7c4af3c8bda42033"},{"author":{"_account_id":10311,"name":"Joseph Davis","email":"joseph.davis@suse.com","username":"joadavis"},"change_message_id":"2733bfaf0aa60d660058b2f89c06e4f0910c8d49","unresolved":false,"context_lines":[{"line_number":238,"context_line":"**Vitrage resource**"},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"TBD: How to distinguish between the two options?"},{"line_number":241,"context_line":""},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"Alarms based on more than one metric"},{"line_number":244,"context_line":"------------------------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffd0ebdf_c2d0cecc","line":241,"updated":"2019-01-04 16:38:51.000000000","message":"How does Vitrage handle node and VIP resources?  Does it use a resource ID to track them as resources in the graph?","commit_id":"472589a37f76508ff764ff4f7c4af3c8bda42033"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"ed1087091738c66cc5cf71c2cca828448a44ad5c","unresolved":false,"context_lines":[{"line_number":238,"context_line":"**Vitrage resource**"},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"TBD: How to distinguish between the two options?"},{"line_number":241,"context_line":""},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"Alarms based on more than one metric"},{"line_number":244,"context_line":"------------------------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_04a27b9b","line":241,"in_reply_to":"ffd0ebdf_c2d0cecc","updated":"2019-01-07 08:17:29.000000000","message":"AFAIK, nobody modelled VIPs in Vitrage so far, but it is an interesting use case. I can imagine a VIP as an entity in the graph that is connected to the specific services. An alarm can be raised on the VIP entity and then we can have RCA like \"if there is an alarm on the VIP and the VIP is connected to keystone on controller1 and controller1 is down...\".\n\nMaybe we can identify the VIP resource by the service and ip.","commit_id":"472589a37f76508ff764ff4f7c4af3c8bda42033"},{"author":{"_account_id":10311,"name":"Joseph Davis","email":"joseph.davis@suse.com","username":"joadavis"},"change_message_id":"2733bfaf0aa60d660058b2f89c06e4f0910c8d49","unresolved":false,"context_lines":[{"line_number":274,"context_line":"TBD - should the alarm in Vitrage be connected to one of the resources, to all"},{"line_number":275,"context_line":"of the resources, or to none of them?"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Proposed change"},{"line_number":279,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":280,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffd0ebdf_dde19300","line":277,"updated":"2019-01-04 16:38:51.000000000","message":"Monasca also supports aggregated metrics, which are metrics based on combining other metrics.  For example \u0027mem.usable_mb_agg\u0027 could represent the amount of usable memory across all compute hosts.  An alarm could be created on this aggregated metric to alert an operator when all hosts are running out of memory (and maybe a new compute needs to be ordered), but would not be tied to a single resource ID.\n\nThis is something we would want to consider in the future, but for our first pass we don\u0027t need to focus on that use case.  Especially as I don\u0027t know how that should be represented in a Vitrage graph. :)\n\nreference: monasca-transform","commit_id":"472589a37f76508ff764ff4f7c4af3c8bda42033"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"ed1087091738c66cc5cf71c2cca828448a44ad5c","unresolved":false,"context_lines":[{"line_number":274,"context_line":"TBD - should the alarm in Vitrage be connected to one of the resources, to all"},{"line_number":275,"context_line":"of the resources, or to none of them?"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Proposed change"},{"line_number":279,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":280,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_64b6e7dc","line":277,"in_reply_to":"ffd0ebdf_dde19300","updated":"2019-01-07 08:17:29.000000000","message":"I think that we should handle all use cases in the spec, and then split the implementation to stages. I want to be sure that we have a good solution (even if a bit complicated) for every use case.","commit_id":"472589a37f76508ff764ff4f7c4af3c8bda42033"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"419a466c99f59e9e8adc73feaaeadd504d20e8ee","unresolved":false,"context_lines":[{"line_number":107,"context_line":""},{"line_number":108,"context_line":".. _monasca_alarm_description: https://github.com/openstack/monasca-api/blob/master/docs/monasca-api-spec.md#response-examples-19"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Interpretation of metrics field"},{"line_number":111,"context_line":"^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"Each metric entry included in alarm object describes monitored entity uniquely."}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_243bff38","line":110,"range":{"start_line":110,"start_character":0,"end_line":110,"end_character":31},"updated":"2019-01-07 08:46:37.000000000","message":"Great explanation. I think that in addition to this section, we should add the specific examples under the \u0027use cases\u0027 section, so we can describe which Vitrage resources should be chosen in each case.","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"419a466c99f59e9e8adc73feaaeadd504d20e8ee","unresolved":false,"context_lines":[{"line_number":132,"context_line":""},{"line_number":133,"context_line":"::"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"    Alarm 1 - Metrics: avg(cpu.idle_perc{service\u003dmonitoring,hostname\u003dmini-mon}) and avg(cpu.user_perc{service\u003dmonitoring,hostname\u003dmini-mon})"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"Similarly, if there is no grouping in the alarm definition (e.g. by hostname or"},{"line_number":138,"context_line":"resource ID), then the alarm will be created once and will aggregate metrics"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_44e643eb","line":135,"range":{"start_line":135,"start_character":0,"end_line":135,"end_character":140},"updated":"2019-01-07 08:46:37.000000000","message":"Is the threshold missing here?","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":16222,"name":"witek","email":"witold.bedyk@suse.com","username":"witek"},"change_message_id":"b006f1f148a35fa93ee57511e22b0a89a76455d3","unresolved":false,"context_lines":[{"line_number":132,"context_line":""},{"line_number":133,"context_line":"::"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"    Alarm 1 - Metrics: avg(cpu.idle_perc{service\u003dmonitoring,hostname\u003dmini-mon}) and avg(cpu.user_perc{service\u003dmonitoring,hostname\u003dmini-mon})"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"Similarly, if there is no grouping in the alarm definition (e.g. by hostname or"},{"line_number":138,"context_line":"resource ID), then the alarm will be created once and will aggregate metrics"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_a1c82a55","line":135,"range":{"start_line":135,"start_character":0,"end_line":135,"end_character":140},"in_reply_to":"dfd5e7cf_44e643eb","updated":"2019-01-08 09:40:17.000000000","message":"I guess, Bartosz wanted to list only metrics here. In that case aggregation functions (avg) should be removed. We could represent it as a list:\n\n  [cpu.idle_perc{service\u003dmonitoring,hostname\u003dmini-mon},\n   cpu.user_perc{service\u003dmonitoring,hostname\u003dmini-mon}]","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"419a466c99f59e9e8adc73feaaeadd504d20e8ee","unresolved":false,"context_lines":[{"line_number":149,"context_line":""},{"line_number":150,"context_line":"::"},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"    Alarm 1 - Metrics: cpu.idle_perc{service\u003dmonitoring,hostname\u003dmini-mon}"},{"line_number":153,"context_line":"    Alarm 2 - Metrics: cpu.idle_perc{service\u003dmonitoring,hostname\u003ddevstack}"},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"Summarizing, alarm object may contain multiple metrics, each of which describes"},{"line_number":156,"context_line":"related resource uniquely. One alarm can be related to various types of metrics"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_84050b7d","line":153,"range":{"start_line":152,"start_character":0,"end_line":153,"end_character":74},"updated":"2019-01-07 08:46:37.000000000","message":"In that case, we will simply have two independent alarms, each of them with a single resource. Right?","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":16222,"name":"witek","email":"witold.bedyk@suse.com","username":"witek"},"change_message_id":"b006f1f148a35fa93ee57511e22b0a89a76455d3","unresolved":false,"context_lines":[{"line_number":149,"context_line":""},{"line_number":150,"context_line":"::"},{"line_number":151,"context_line":""},{"line_number":152,"context_line":"    Alarm 1 - Metrics: cpu.idle_perc{service\u003dmonitoring,hostname\u003dmini-mon}"},{"line_number":153,"context_line":"    Alarm 2 - Metrics: cpu.idle_perc{service\u003dmonitoring,hostname\u003ddevstack}"},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"Summarizing, alarm object may contain multiple metrics, each of which describes"},{"line_number":156,"context_line":"related resource uniquely. One alarm can be related to various types of metrics"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_81272613","line":153,"range":{"start_line":152,"start_character":0,"end_line":153,"end_character":74},"in_reply_to":"dfd5e7cf_84050b7d","updated":"2019-01-08 09:40:17.000000000","message":"Yes. This example illustrates well that evaluating `match_by`  parameter might be very useful to define the mapping. Please compare the last comment below.","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":16222,"name":"witek","email":"witold.bedyk@suse.com","username":"witek"},"change_message_id":"b006f1f148a35fa93ee57511e22b0a89a76455d3","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"**Vitrage resource**"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"TBD: How to distinguish between the two options?"},{"line_number":289,"context_line":""},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_a1aeea2b","line":288,"range":{"start_line":288,"start_character":0,"end_line":288,"end_character":48},"updated":"2019-01-08 09:40:17.000000000","message":"Important note on these examples. \u0027hostname\u0027 is assigned to the location where the agent is installed. \u0027url\u0027 is the target endpoint which is checked. Per default we configure http_status checks for OpenStack services running on the same node as monasca-agent. In that case (example 1) \u0027hostname\u0027 and hostname part of the \u0027url\u0027 are the same. The metric in that configuration informs if the service is running.\n\nSecond example is less common. \u0027hostname\u0027 and hostname part of \u0027url\u0027 are different. The metric additionally informs about connectivity between hostname and url.","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":16222,"name":"witek","email":"witold.bedyk@suse.com","username":"witek"},"change_message_id":"9fa2e2c561d798b186cef3f9a2ec2d9d5a6d0923","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"**Vitrage resource**"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"TBD: How to distinguish between the two options?"},{"line_number":289,"context_line":""},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":6,"id":"bfdaf3ff_881164af","line":288,"range":{"start_line":288,"start_character":0,"end_line":288,"end_character":48},"in_reply_to":"bfdaf3ff_01ffb401","updated":"2019-01-15 11:02:27.000000000","message":"Sorry, wrong wording. In this example at the end we have to map to the Vitrage ID which corresponds to the local node.","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":16222,"name":"witek","email":"witold.bedyk@suse.com","username":"witek"},"change_message_id":"620c41bc4aa375ffc0eb12df44454150d951dd30","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"**Vitrage resource**"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"TBD: How to distinguish between the two options?"},{"line_number":289,"context_line":""},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":6,"id":"bfdaf3ff_210ab589","line":288,"range":{"start_line":288,"start_character":0,"end_line":288,"end_character":48},"in_reply_to":"bfdaf3ff_4eada886","updated":"2019-01-30 09:16:28.000000000","message":"The node Monasca agent runs on, so yes, hostname dimension should be used.","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"26fd7f037ef9dcbe6be5285cf9d323e0fe01c487","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"**Vitrage resource**"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"TBD: How to distinguish between the two options?"},{"line_number":289,"context_line":""},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":6,"id":"bfdaf3ff_4eada886","line":288,"range":{"start_line":288,"start_character":0,"end_line":288,"end_character":48},"in_reply_to":"bfdaf3ff_881164af","updated":"2019-01-16 15:34:20.000000000","message":"And who know what the local node is? is it the node that Vitrage runs on? or the node that the agent runs on? can Vitrage get this information from Monasca?","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"950ec717dacb18433619fe11d2e1576d929e21a6","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"**Vitrage resource**"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"TBD: How to distinguish between the two options?"},{"line_number":289,"context_line":""},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":6,"id":"bfdaf3ff_01ffb401","line":288,"range":{"start_line":288,"start_character":0,"end_line":288,"end_character":48},"in_reply_to":"bfdaf3ff_88b67dd9","updated":"2019-01-13 10:04:31.000000000","message":"What do you mean by \"some other logic\"?","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":19134,"name":"Eyal","email":"eyalb1@gmail.com","username":"eyalb"},"change_message_id":"2e72d967bd5884b599742eff845088d0409308dc","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"**Vitrage resource**"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"TBD: How to distinguish between the two options?"},{"line_number":289,"context_line":""},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_b95b7e2c","line":288,"range":{"start_line":288,"start_character":0,"end_line":288,"end_character":48},"in_reply_to":"dfd5e7cf_3618fd1b","updated":"2019-01-08 12:30:35.000000000","message":"should use the host part of the url which can be IPv4, IPv6 or hostname","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"a3e1fa8be740b635548721c52f1e0aefd3c63e57","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"**Vitrage resource**"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"TBD: How to distinguish between the two options?"},{"line_number":289,"context_line":""},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_e9a35e4e","line":288,"range":{"start_line":288,"start_character":0,"end_line":288,"end_character":48},"in_reply_to":"dfd5e7cf_5ed7cf4c","updated":"2019-01-09 09:08:52.000000000","message":"So in this example, \u0027localhost\u0027 should be (somehow) replaced by the agent\u0027s hostname?","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"88282fb17058ef5a855820c9bf5a6dc269d6f97e","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"**Vitrage resource**"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"TBD: How to distinguish between the two options?"},{"line_number":289,"context_line":""},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_3618fd1b","line":288,"range":{"start_line":288,"start_character":0,"end_line":288,"end_character":48},"in_reply_to":"dfd5e7cf_a1aeea2b","updated":"2019-01-08 12:02:53.000000000","message":"So if I understand correctly, Vitrage only cares about the \u0027url\u0027 dimension, and should use the ip part of it. Right?","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":16222,"name":"witek","email":"witold.bedyk@suse.com","username":"witek"},"change_message_id":"e174f02f1cbfaed906295588b40e0c9b98180d09","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"**Vitrage resource**"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"TBD: How to distinguish between the two options?"},{"line_number":289,"context_line":""},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_5ed7cf4c","line":288,"range":{"start_line":288,"start_character":0,"end_line":288,"end_character":48},"in_reply_to":"dfd5e7cf_b95b7e2c","updated":"2019-01-08 17:52:29.000000000","message":"Yes, with caveat: for example, the automatic agent configuration script sets something like \u0027url\u0027\u003d\u0027http://localhost/identity\u0027.\n\nIn the first step we could limit the implementation to the case where only local endpoints are tested and use \u0027hostname\u0027 dimension for mapping.","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":16222,"name":"witek","email":"witold.bedyk@suse.com","username":"witek"},"change_message_id":"86b26a658ad3eee89d639592c3c42cbb75bef05f","unresolved":false,"context_lines":[{"line_number":285,"context_line":""},{"line_number":286,"context_line":"**Vitrage resource**"},{"line_number":287,"context_line":""},{"line_number":288,"context_line":"TBD: How to distinguish between the two options?"},{"line_number":289,"context_line":""},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":6,"id":"bfdaf3ff_88b67dd9","line":288,"range":{"start_line":288,"start_character":0,"end_line":288,"end_character":48},"in_reply_to":"dfd5e7cf_e9a35e4e","updated":"2019-01-11 14:44:18.000000000","message":"Yes, or some other logic.","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"419a466c99f59e9e8adc73feaaeadd504d20e8ee","unresolved":false,"context_lines":[{"line_number":308,"context_line":""},{"line_number":309,"context_line":"::"},{"line_number":310,"context_line":""},{"line_number":311,"context_line":"    Monasca metric dimensions -\u003e (Vitrage resource type, Vitrage resource ID)"},{"line_number":312,"context_line":""},{"line_number":313,"context_line":"Based on the dimensions of given metric, it should be possible to precisely"},{"line_number":314,"context_line":"determine resource type and resource ID of associated vertex in the Entity"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_24521f69","line":311,"range":{"start_line":311,"start_character":0,"end_line":311,"end_character":77},"updated":"2019-01-07 08:46:37.000000000","message":"Not necessarily. We are able to identify the resources by other properties, as long as the result is unique. For example, you could identify a NIC by a combination of the hostname and NIC name. \n\nThe resource is determined in the transformer\u0027s get_enrich_query() method, where you can return any combination of properties and the processor finds all matching entities. \n\nYou can also see, as an example, the spec we\u0027ve just wrote for Prometheus resource mapping: https://specs.openstack.org/openstack/vitrage-specs/specs/stein/approved/prometheus-datasource.html\n\nI\u0027m not sure yet if this approach will also work for Monasca, but it\u0027s worth checking.","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"419a466c99f59e9e8adc73feaaeadd504d20e8ee","unresolved":false,"context_lines":[{"line_number":326,"context_line":"based on a list of several metrics, would be able to identify all associated"},{"line_number":327,"context_line":"resources skipping the duplicates."},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"Having an alarm object, the matching algorithm should analyze the entire list"},{"line_number":330,"context_line":"of alarm metrics. For each of them, based on the dimensions of given metric,"},{"line_number":331,"context_line":"try to determine the type of resource and its identifier. Duplicates should be"},{"line_number":332,"context_line":"skipped by doing lookup to a structure of already identified resources - if"},{"line_number":333,"context_line":"given pair of resource type and resource ID already exist, skip it. Finally,"},{"line_number":334,"context_line":"create and connect alarm vertex for each identified resource."},{"line_number":335,"context_line":""},{"line_number":336,"context_line":"TBD:"},{"line_number":337,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_e403b70e","line":334,"range":{"start_line":329,"start_character":0,"end_line":334,"end_character":61},"updated":"2019-01-07 08:46:37.000000000","message":"How about this approach: for each metric, map the resource separately, according to the mapping configuration. \n\nThen, we should handle different cases:\n\n1. A single resource - easy\n\n2. Metrics with an \u0027and\u0027 condition - relate the alarm in the graph to all of the resources (add several \u0027on\u0027 edges). This will require some refactoring in Vitrage, since part of the code was written under the assumption that every alarm has a single resource. \n\n3. Metrics with an \u0027or\u0027 condition - this is more complicated. I can think of adding a new type of edge, \u0027maybe_on\u0027, or alternatively add a \u0027probability\u0027 property to an edge. For example, the alarm is on host1 with 50% probability and on host2 with 50% probability. This is a new feature that should be added to Vitrage, including template language support, smart sub-graph matching, etc. \n\n4. Could there be a mix of \u0027and\u0027 and \u0027or\u0027 in the same alarm?","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":16222,"name":"witek","email":"witold.bedyk@suse.com","username":"witek"},"change_message_id":"e174f02f1cbfaed906295588b40e0c9b98180d09","unresolved":false,"context_lines":[{"line_number":326,"context_line":"based on a list of several metrics, would be able to identify all associated"},{"line_number":327,"context_line":"resources skipping the duplicates."},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"Having an alarm object, the matching algorithm should analyze the entire list"},{"line_number":330,"context_line":"of alarm metrics. For each of them, based on the dimensions of given metric,"},{"line_number":331,"context_line":"try to determine the type of resource and its identifier. Duplicates should be"},{"line_number":332,"context_line":"skipped by doing lookup to a structure of already identified resources - if"},{"line_number":333,"context_line":"given pair of resource type and resource ID already exist, skip it. Finally,"},{"line_number":334,"context_line":"create and connect alarm vertex for each identified resource."},{"line_number":335,"context_line":""},{"line_number":336,"context_line":"TBD:"},{"line_number":337,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_9ed777ee","line":334,"range":{"start_line":329,"start_character":0,"end_line":334,"end_character":61},"in_reply_to":"dfd5e7cf_9683e904","updated":"2019-01-08 17:52:29.000000000","message":"The alarm can have multiple metrics because of two reasons:\n\n* compound alarm expression with several metrics joined with logical operator\n* aggregated alarm without grouping (match_by)\n\nThis information is available via API [1].\n\n[1] https://github.com/openstack/monasca-api/blob/master/docs/monasca-api-spec.md#get-alarm-definition\n\nYes, that\u0027s user\u0027s decision how she defines the alarm but in Vitrage context we want to have unambiguous assignment to the resource. Match_by offers the most effective way to assure that.","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"a3e1fa8be740b635548721c52f1e0aefd3c63e57","unresolved":false,"context_lines":[{"line_number":326,"context_line":"based on a list of several metrics, would be able to identify all associated"},{"line_number":327,"context_line":"resources skipping the duplicates."},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"Having an alarm object, the matching algorithm should analyze the entire list"},{"line_number":330,"context_line":"of alarm metrics. For each of them, based on the dimensions of given metric,"},{"line_number":331,"context_line":"try to determine the type of resource and its identifier. Duplicates should be"},{"line_number":332,"context_line":"skipped by doing lookup to a structure of already identified resources - if"},{"line_number":333,"context_line":"given pair of resource type and resource ID already exist, skip it. Finally,"},{"line_number":334,"context_line":"create and connect alarm vertex for each identified resource."},{"line_number":335,"context_line":""},{"line_number":336,"context_line":"TBD:"},{"line_number":337,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_c96c5a0a","line":334,"range":{"start_line":329,"start_character":0,"end_line":334,"end_character":61},"in_reply_to":"dfd5e7cf_9ed777ee","updated":"2019-01-09 09:08:52.000000000","message":"Ok, thanks","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":16222,"name":"witek","email":"witold.bedyk@suse.com","username":"witek"},"change_message_id":"b006f1f148a35fa93ee57511e22b0a89a76455d3","unresolved":false,"context_lines":[{"line_number":326,"context_line":"based on a list of several metrics, would be able to identify all associated"},{"line_number":327,"context_line":"resources skipping the duplicates."},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"Having an alarm object, the matching algorithm should analyze the entire list"},{"line_number":330,"context_line":"of alarm metrics. For each of them, based on the dimensions of given metric,"},{"line_number":331,"context_line":"try to determine the type of resource and its identifier. Duplicates should be"},{"line_number":332,"context_line":"skipped by doing lookup to a structure of already identified resources - if"},{"line_number":333,"context_line":"given pair of resource type and resource ID already exist, skip it. Finally,"},{"line_number":334,"context_line":"create and connect alarm vertex for each identified resource."},{"line_number":335,"context_line":""},{"line_number":336,"context_line":"TBD:"},{"line_number":337,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_fcbb39e2","line":334,"range":{"start_line":329,"start_character":0,"end_line":334,"end_character":61},"in_reply_to":"dfd5e7cf_e403b70e","updated":"2019-01-08 09:40:17.000000000","message":"The problem is that only the alarm body with metric list does not give enough information about conditional operator. It just lists all the metrics which have been taken into alarm evaluation.\n\nWhat we perhaps could do is to use grouping parameter (match_by) to identify the relevant dimension. \u0027match_by\u0027 parameter is not available in the alarm itself but in the alarm definition.","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"88282fb17058ef5a855820c9bf5a6dc269d6f97e","unresolved":false,"context_lines":[{"line_number":326,"context_line":"based on a list of several metrics, would be able to identify all associated"},{"line_number":327,"context_line":"resources skipping the duplicates."},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"Having an alarm object, the matching algorithm should analyze the entire list"},{"line_number":330,"context_line":"of alarm metrics. For each of them, based on the dimensions of given metric,"},{"line_number":331,"context_line":"try to determine the type of resource and its identifier. Duplicates should be"},{"line_number":332,"context_line":"skipped by doing lookup to a structure of already identified resources - if"},{"line_number":333,"context_line":"given pair of resource type and resource ID already exist, skip it. Finally,"},{"line_number":334,"context_line":"create and connect alarm vertex for each identified resource."},{"line_number":335,"context_line":""},{"line_number":336,"context_line":"TBD:"},{"line_number":337,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"dfd5e7cf_9683e904","line":334,"range":{"start_line":329,"start_character":0,"end_line":334,"end_character":61},"in_reply_to":"dfd5e7cf_fcbb39e2","updated":"2019-01-08 12:02:53.000000000","message":"I don\u0027t fully understand.\n\nYou are saying that the \u0027and\u0027, \u0027or\u0027 etc. are not part of the alarm body? are they part of the alarm definition? is this information available to Vitrage (even through a different api call)? is it expected to change over time?\n\nI can think of a solution where Vitrage reads (and maybe caches) the alarm definitions, in order to decide about the resource relations. Do you think it could work?\n\nRegarding the match_by: isn\u0027t it the user\u0027s decision whether to use it or not? ideally, we would like to support all possible kinds of alarm definitions","commit_id":"2049eee238b0852ef057c8ae1a47182a2413f104"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"a3e1fa8be740b635548721c52f1e0aefd3c63e57","unresolved":false,"context_lines":[{"line_number":363,"context_line":"    expression: \"net.in_errors_sec \u003e 5 or net.out_errors_sec \u003e 5\""},{"line_number":364,"context_line":"    match_by:   \"hostname\""},{"line_number":365,"context_line":""},{"line_number":366,"context_line":"The alarm triggered by this definition aggregates both metric names named in"},{"line_number":367,"context_line":"expression across all NICs on the monitored system. There will be one alarm per"},{"line_number":368,"context_line":"hostname."},{"line_number":369,"context_line":""},{"line_number":370,"context_line":""},{"line_number":371,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":7,"id":"dfd5e7cf_49e4eaac","line":368,"range":{"start_line":366,"start_character":0,"end_line":368,"end_character":9},"updated":"2019-01-09 09:08:52.000000000","message":"Let me make sure I understand: Vitrage will receive one alarm per hostname, with two metric names. The alarm will be triggered if the aggregated values across all NICs pass one of the thresholds. \n\nVitrage does not have to be aware of the alarm definition in this case. It will raise an alarm on the \u0027hostname\u0027. The NICs information is also irrelevant for Vitrage in this example.\n\nAm I right?","commit_id":"6e23a8066a5708ad684f2f9215c550df6cdbaf91"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"26fd7f037ef9dcbe6be5285cf9d323e0fe01c487","unresolved":false,"context_lines":[{"line_number":363,"context_line":"    expression: \"net.in_errors_sec \u003e 5 or net.out_errors_sec \u003e 5\""},{"line_number":364,"context_line":"    match_by:   \"hostname\""},{"line_number":365,"context_line":""},{"line_number":366,"context_line":"The alarm triggered by this definition aggregates both metric names named in"},{"line_number":367,"context_line":"expression across all NICs on the monitored system. There will be one alarm per"},{"line_number":368,"context_line":"hostname."},{"line_number":369,"context_line":""},{"line_number":370,"context_line":""},{"line_number":371,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfdaf3ff_4e50485e","line":368,"range":{"start_line":366,"start_character":0,"end_line":368,"end_character":9},"in_reply_to":"bfdaf3ff_08a81475","updated":"2019-01-16 15:34:20.000000000","message":"I would like to cover compound alarms in the design, even if we don\u0027t implement it at the first stage, because I don\u0027t want to change the configuration file format later on. \n\nI think that your suggestion will work, but is quite confusing. \n\nHow about:\n\n* first stage - metrics mapping\n\n* second stage - alarms mapping\n\n* the alarms mapping will have a preference, and only if not found then the metrics mapping will be used.","commit_id":"6e23a8066a5708ad684f2f9215c550df6cdbaf91"},{"author":{"_account_id":19159,"name":"Ifat Afek","email":"ifat.afek@nokia.com","username":"ifat_afek"},"change_message_id":"950ec717dacb18433619fe11d2e1576d929e21a6","unresolved":false,"context_lines":[{"line_number":363,"context_line":"    expression: \"net.in_errors_sec \u003e 5 or net.out_errors_sec \u003e 5\""},{"line_number":364,"context_line":"    match_by:   \"hostname\""},{"line_number":365,"context_line":""},{"line_number":366,"context_line":"The alarm triggered by this definition aggregates both metric names named in"},{"line_number":367,"context_line":"expression across all NICs on the monitored system. There will be one alarm per"},{"line_number":368,"context_line":"hostname."},{"line_number":369,"context_line":""},{"line_number":370,"context_line":""},{"line_number":371,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfdaf3ff_860dfa3f","line":368,"range":{"start_line":366,"start_character":0,"end_line":368,"end_character":9},"in_reply_to":"bfdaf3ff_2b12eb59","updated":"2019-01-13 10:04:31.000000000","message":"Ok. So if the alarm is called compound_nic_alarm then in the configuration file we should map something like:\n\nalarm_name: compound_nic_alarm\n    dimension: hostname -\u003e vitrage \u0027id\u0027 property\n\n\nMeaning: the value of the \u0027hostname\u0027 dimension should be mapped to the \u0027id\u0027 property in Vitrage. This should be enough to uniquely identify the host. And this definition should be done for the alarm and not for the metrics (unlike what I thought before).\n\nDoes it make sense?","commit_id":"6e23a8066a5708ad684f2f9215c550df6cdbaf91"},{"author":{"_account_id":16222,"name":"witek","email":"witold.bedyk@suse.com","username":"witek"},"change_message_id":"620c41bc4aa375ffc0eb12df44454150d951dd30","unresolved":false,"context_lines":[{"line_number":363,"context_line":"    expression: \"net.in_errors_sec \u003e 5 or net.out_errors_sec \u003e 5\""},{"line_number":364,"context_line":"    match_by:   \"hostname\""},{"line_number":365,"context_line":""},{"line_number":366,"context_line":"The alarm triggered by this definition aggregates both metric names named in"},{"line_number":367,"context_line":"expression across all NICs on the monitored system. There will be one alarm per"},{"line_number":368,"context_line":"hostname."},{"line_number":369,"context_line":""},{"line_number":370,"context_line":""},{"line_number":371,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9fdfeff1_c2d35e5f","line":368,"range":{"start_line":366,"start_character":0,"end_line":368,"end_character":9},"in_reply_to":"bfdaf3ff_4e50485e","updated":"2019-01-30 09:16:28.000000000","message":"Sounds good, it will allow to cover standard cases with the metrics mapping and provide flexible mechanism to address the rest with alarms mapping. Optimally, the first stage should cover most of the cases which would reduce operational effort.","commit_id":"6e23a8066a5708ad684f2f9215c550df6cdbaf91"},{"author":{"_account_id":16222,"name":"witek","email":"witold.bedyk@suse.com","username":"witek"},"change_message_id":"9fa2e2c561d798b186cef3f9a2ec2d9d5a6d0923","unresolved":false,"context_lines":[{"line_number":363,"context_line":"    expression: \"net.in_errors_sec \u003e 5 or net.out_errors_sec \u003e 5\""},{"line_number":364,"context_line":"    match_by:   \"hostname\""},{"line_number":365,"context_line":""},{"line_number":366,"context_line":"The alarm triggered by this definition aggregates both metric names named in"},{"line_number":367,"context_line":"expression across all NICs on the monitored system. There will be one alarm per"},{"line_number":368,"context_line":"hostname."},{"line_number":369,"context_line":""},{"line_number":370,"context_line":""},{"line_number":371,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfdaf3ff_08a81475","line":368,"range":{"start_line":366,"start_character":0,"end_line":368,"end_character":9},"in_reply_to":"bfdaf3ff_860dfa3f","updated":"2019-01-15 11:02:27.000000000","message":"Yes, it makes sense.\nWe could also stay with mapping on metrics but limit the integration only to alarms including metrics which all map to single Vitrage resource ID. Also, the mapping could include a list of dimensions it would try to match. In this example it could look like:\n\n  metric: net.in_errors_sec\n    dimensions:\n      device -\u003e vitrage \u0027nic\u0027 resource\n      hostname -\u003e vitrage \u0027node\u0027 resource\n  metric: net.out_errors_sec\n    dimensions:\n      device -\u003e vitrage \u0027nic\u0027 resource\n      hostname -\u003e vitrage \u0027node\u0027 resource\n\nMapping on NIC would be tried first. If more than one NIC is listed in the alarm, mapping on node would be attempted.\nMore complex examples probably do not make much sense and would be very difficult to handle. \n\nAnyway, I would not cover compound alarms in the first implementation.","commit_id":"6e23a8066a5708ad684f2f9215c550df6cdbaf91"},{"author":{"_account_id":16222,"name":"witek","email":"witold.bedyk@suse.com","username":"witek"},"change_message_id":"86b26a658ad3eee89d639592c3c42cbb75bef05f","unresolved":false,"context_lines":[{"line_number":363,"context_line":"    expression: \"net.in_errors_sec \u003e 5 or net.out_errors_sec \u003e 5\""},{"line_number":364,"context_line":"    match_by:   \"hostname\""},{"line_number":365,"context_line":""},{"line_number":366,"context_line":"The alarm triggered by this definition aggregates both metric names named in"},{"line_number":367,"context_line":"expression across all NICs on the monitored system. There will be one alarm per"},{"line_number":368,"context_line":"hostname."},{"line_number":369,"context_line":""},{"line_number":370,"context_line":""},{"line_number":371,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":7,"id":"bfdaf3ff_2b12eb59","line":368,"range":{"start_line":366,"start_character":0,"end_line":368,"end_character":9},"in_reply_to":"dfd5e7cf_49e4eaac","updated":"2019-01-11 14:44:18.000000000","message":"Vitrage will receive one alarm per hostname, with 2 x number of nics metrics. `in_errors` for all nics + `out_errors` for all nics. The alarm will be triggered when any of these metrics (for any nic) will exceed the corresponding threshold.\n\nYes, in that case NICs information is irrelevant for Vitrage. If we would like to assign the alarm to NIC resource we would need to define it as grouped (match_by \u003d [\"hostname\", \"device\"]).\n\nThe \"match_by\" information is available from alarm definition, not alarm, if that was the question.","commit_id":"6e23a8066a5708ad684f2f9215c550df6cdbaf91"}]}