Open Stack

Hi,

Can you please give us some more details about your scenario with
Prometheus? Please try and give as many details as possible, so we can try
to reproduce the bug.


What do you mean by “if the alarm is resolved, the alarm manager makes a
silence, or removes the alarm rule from Prometheus”? these are different
cases. None of them works in your environment?

Which Prometheus and Alertmanager versions are you using?

 Please try to change the Vitrage loglevel to DEBUG (set “debug = true” in
/etc/vitrage/vitrage.conf) and send me the Vitrage collector, graph and api
logs.

Regarding the multi nodes, I'm not sure I understand your configuration. Do
you mean there is more than one OpenStack and Nova? more than one host?
more than one vm?

Basically, vms are deleted from Vitrage in two cases:
1. After each periodic call to get_all of nova.instance datasource. By
default this is done once in 10 minutes.
2. Immediately, if you have the following configuration in
/etc/nova/nova.conf:
notification_topics = notifications,vitrage_notifications

So, please check your nova.conf and also whether the vms are deleted after
10 minutes.

Thanks,
Ifat


On Thu, Oct 4, 2018 at 7:12 AM Won <wjstk16 at gmail.com> wrote:

> Thank you for your reply Ifat.
>
> The alertmanager.yml file already contains 'send_resolved:true'.
> However, the alarm does not disappear from the alarm list and the entity
> graph even if the alarm is resolved, the alarm manager makes a silence, or
> removes the alarm rule from Prometheus.
> The only way to remove alarms is to manually remove them from the db. Is
> there any other way to remove the alarm?
> Entities(vm) that run on multi nodes in the rocky version have similar
> symptoms. There was a symptom that the Entities created on the multi-node
> would not disappear from the Entity Graph even after deletion.
> Is this a bug in rocky version?
>
> Best Regards,
> Won
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20181004/c5fd5613/attachment.html>