Nagvis - html bar gadget labels gets reset to top left

[solarmon]

Hi,

I have created a service object that is displayed as std_html_bar gadget. I have enabled 'label_show' for it and for 'label_text' has set it to the default "[service_description]".

The first issue I notice is that the label does not appear until I move the object - it gets placed below the gadget.

I lock the object, or use 'Lock/unlock all' and it seems to stay there. However, after the next map refresh the label is moved to the top left of the map. This happens to all the std_html_bar gadget object labels.

I can get the labels to go back under its parent object by editing it and moving it. But the same thing just happens again and all the labels gets place on the top left corner of the map.

How can this behaviour be resolved?

[cdienger]

What are the label_x and label_y values set to for the object's label? Try setting them to "center" and "bottom" respectively and let us know if that fixes the problem.

[solarmon]

Hi @cdienger

I had only set/enabled:

label_show = Yes
label_text = [service_description]

I did not set the 'label_x' and 'label_y' so they are (or should be) using the map default of 'center' and 'bottom' respectively.

I tried manually setting 'label_x' and 'label_y' to 'center' and 'bottom' respectively, but that did not resolve the issue.

I don't have this issue with host objects when their labels are set manually as:

label_show = Yes
label_text = [name]
label_x = -41
label_y = +78

Also change a host object so that the label_x and label_y are left as default and still don't have any issues with those labels.

I also tried manually setting label_x and label_y with relative coordinates - for example:

label_x = -2
label_y = +37

But again, the label gets moved to the top left corner. When I check the object settings again, the coordinates are still there and have not been changed.

So it looks like the bug is for when the gadget label is drawn when the map is refreshed and does not respect the coordinates. During editing mode it does respects the coordinates. But when not in edit mode and the map refreshes/redraws, the gadget label coordinates are not respected.

[ssax]

Looks like it could be related to this:

Code: Select all

https://github.com/NagVis/nagvis/issues/81

[solarmon]

So do I continue with the support here? Or are you saying it is a NagVis issue, and not a Nagios XI NagVis plugin issue, and I should open a ticket on Github (which I have an account already)?

[ssax]

I tried the latest version from Nagvis's github repo and it still had the issue, and at this point, since we are not the developers of this application, please reach out the NagVis team for assistance.

[solarmon]

I've opened a Github ticket for this issue:

https://github.com/NagVis/nagvis/issues/214

[ssax]

Thank you, I validated that 1.9.14 (latest) doesn't fix the issue as well so it's an open bug for them.

[solarmon]

@ssax

I've noticed another labelling issue.

For a line object, I assume the label coordinates should be relative to the line object. For example:

label_x = +10
label_y = +10

If I update these coordinates manually, it is OK and the label is placed as expected.

However, if I drag the label, the coordinates values seems to get updated to an absolute value, but the "+" prefix is kept. For example, I drag the label only slightly to the right, but the coordinates gets updated to:

label_x = +534
label_y = +509

So now, when the I come out of edit mode and refresh the map, the label gets drawn at a relative position to the line object but using absolute values - so it is way off where it should be!!

There seems to be general issue with labelling!

[ssax]

Thanks for posting that, I tried to get it to work by changing the code and it seems to do this:

Set the initial position to 0,0 in the beginning
- Do a bunch of other stuff
- Call the place method to place it to the position you want it
---- This place method I think is the one that isn't working but I don't know their code and the changes I tried didn't work. I think it's likely something further down in their code but I don't know their code very well, I just try to fix bugs if I'm able.