Feature: Grouped Non-green view
I sent this message the other day but it appears to be strangely split up in the archives:
http://www.xymon.com/archive/2010/12/msg00030.html http://www.xymon.com/archive/2010/12/msg00031.html
So I'm resending it:
I'd love to see an option for the "non-green view" (bb2) to be grouped by the "page" attribute in bb-hosts. I would visualize this as still having a list one one page but separated by the title of each "page" while maintaining the page sort order as in the main view.
From what I can tell this functionality would live in bbgen, I looked through its help file but didn't see any option to enable this.
I would see this as a useful way to assist in troubleshoot or to organize what systems to fix during outage or possibly scheduled maintenance where you may have a large portion of your hosts down. For example, we have a page for the core of our network that's first in bb-hosts. Having this always at the top instead of mixed in with 100's of other things we would be great.
Looking at bbdisplay/pagegen.c under do_bb2_page I see:
bb2page.subpages = NULL;
bb2page.groups = NULL;But no other references to these. Is this feature on the roadmap?
--Chris
In <AANLkTi=jrkDGhdhGaLFg5ut9QtvXKu46UfeRmpqe4ky9 at mail.gmail.com> Chris Wopat <me at falz.net> writes:
I sent this message the other day but it appears to be strangely split up in the archives:
http://www.xymon.com/archive/2010/12/msg00030.html http://www.xymon.com/archive/2010/12/msg00031.html
How weird! It seems that MHonArc mistakenly sees the line
From what I can tell this ... and triggers on the "From " as being the start of a new message.
Regards, Henrik
In <AANLkTi=jrkDGhdhGaLFg5ut9QtvXKu46UfeRmpqe4ky9 at mail.gmail.com> Chris Wopat <me at falz.net> writes:
I'd love to see an option for the "non-green view" (bb2) to be grouped by the "page" attribute in bb-hosts. I would visualize this as still having a list one one page but separated by the title of each "page" while maintaining the page sort order as in the main view.
From what I can tell this functionality would live in bbgen, I looked through its help file but didn't see any option to enable this.
Correct, the bb2 page doesn't have any structure.
I would see this as a useful way to assist in troubleshoot or to organize what systems to fix during outage or possibly scheduled maintenance where you may have a large portion of your hosts down. For example, we have a page for the core of our network that's first in bb-hosts. Having this always at the top instead of mixed in with 100's of other things we would be great.
Why can't you use the new "Critical Systems" view and assign different priorities to the systems ? E.g. your core network infrastructure is priority 1, critical servers priority 2, and the rest priority 3 (or lower).
Is this feature on the roadmap?
No.
The nongreen page ("bb2" in the older versions) is a bad idea, in my opinion. Trying to fit every non-green status into one single page might work if you have a very small setup, but it just doesn't work at the datacenter level - e.g. right now I have 3575 non-green statuses split over 2650 hosts. And that's a normal Wednesday morning. I stopped generating the nongreen page a long time ago.
Even for a small setup it quickly becomes unmanageable, because an event-log entry from a Windows server will (nearly) always make the non-green page go red.
So there are no enhancements planned for the nongreen page. If anything, I would like the static HTML pages (those generated by xymoongen / bbgen) to entirely disappear and be replaced with dynamically generated pages. Then we can start discussing how to configure what they should look like, and in the end we may end up with something that you can configure to work the way you describe :-)
Regards, Henrik
Hi Henrik,
Sorry but I have to reply to your mail:
Le 08/12/10 08:32, Henrik St??rner a écrit :
The nongreen page ("bb2" in the older versions) is a bad idea, in my opinion. Trying to fit every non-green status into one single page might work if you have a very small setup, but it just doesn't work at the datacenter level - e.g. right now I have 3575 non-green statuses split over 2650 hosts. And that's a normal Wednesday morning. I stopped generating the nongreen page a long time ago.
In my opinion the non green page is the best feature of xymon :-)
This is what makes this monitoring system so useful on production networks compared to software like nagios or HP openview. These classical monitoring software just gather all events, raise tons of alarms and at the end you don't have a global view of the state of your services and there's so much alarms (either critical or not) that you can't guess if something is wrong or not.
The non-green view is giving to network controllers the overview of all the monitored services on a single page, and this is great: the background color indicates the global status of your services. Now the hard part is to keep this page green and this is a challenge for system and network engineers:
- they need to think about the importance of alarms and don't report events which aren't a threat for the service
- they have to setup the hosts monitoring properly including filters on the logs to monitor only useful stuff
- when a red alarm is generated they need to react by either fix the root cause of the problem in order to not let it happen again or reduce it from red to yellow or even remove it completely
During the time engineers are fixing the problem, the controllers can disable the alarms and the non-green view isn't polluted with those red alarms anymore.
In the end having a monitoring system with such a constraint implies good IT work rules and the service benefits from that. We're monitoring a quite large network and guess what: our nongreen view is most of the time green ! :-) When it goes red the guys are reacting fast because they know it's serious.
Even for a small setup it quickly becomes unmanageable, because an event-log entry from a Windows server will (nearly) always make the non-green page go red.
Such messages should be treated: either fixed on the windows server or filtered-out on the xymon server so that they don't appear anymore.
So there are no enhancements planned for the nongreen page.
Fine. Keep it like this it's perfect.
If anything, I would like the static HTML pages (those generated by xymoongen / bbgen) to entirely disappear and be replaced with dynamically generated pages. Then we can start discussing how to configure what they should look like, and in the end we may end up with something that you can configure to work the way you describe :-)
Maybe you could do both: keep the static pages and add dynamically generated pages ?
Regards, Henrik
Regards, Francois.
In <4CFF6643.1060308 at free.fr> Francois Claire <fclaire at free.fr> writes:
Sorry but I have to reply to your mail:
Nothing to be sorry for! This list is (also) for discussing how to improve Xymon.
Le 08/12/10 08:32, Henrik St??rner a �crit :
The nongreen page ("bb2" in the older versions) is a bad idea, in my opinion. Trying to fit every non-green status into one single page might work if you have a very small setup, but it just doesn't work at the datacenter level - e.g. right now I have 3575 non-green statuses split over 2650 hosts. And that's a normal Wednesday morning. I stopped generating the nongreen page a long time ago.
In my opinion the non green page is the best feature of xymon :-)
It's obvious that there are many ways of using Xymon, and I should not try to judge one way as "better" than others. That certainly was not my intention. I was merely responding to a request for enhancing the current nongreen page, and in my opinion that should be done differently.
I have no intention of removing the nongreen page - the code is there, it works, and to some Xymon users it is really useful. For others - myself included - it is useless because it is too crowded.
[snip description of a well-run setup]
In the end having a monitoring system with such a constraint implies good IT work rules and the service benefits from that. We're monitoring a quite large network and guess what: our nongreen view is most of the time green ! :-) When it goes red the guys are reacting fast because they know it's serious.
I'd wish I could do that, but it is just not possible for me. So different environments means different needs.
So there are no enhancements planned for the nongreen page.
Fine. Keep it like this it's perfect.
If anything, I would like the static HTML pages (those generated by xymoongen / bbgen) to entirely disappear and be replaced with dynamically generated pages. Then we can start discussing how to configure what they should look like, and in the end we may end up with something that you can configure to work the way you describe :-)
Maybe you could do both: keep the static pages and add dynamically generated pages ?
Sure, there are no plans to remove the nongreen page. But I'd like to do enhancements elsewhere.
Regards, Henrik
On Wed, Dec 8, 2010 at 1:32 AM, Henrik Størner <henrik at hswn.dk> wrote:
Why can't you use the new "Critical Systems" view and assign different priorities to the systems ? E.g. your core network infrastructure is priority 1, critical servers priority 2, and the rest priority 3 (or lower).
We don't use NK at all so I will have to investigate it to see if it's useful to us. Grouping items regardless of how critical they are would still be incredibly useful for us to troubleshoot just about anything, even less critical stuff.
On Wed, Dec 8, 2010 at 5:04 AM, Francois Claire <fclaire at free.fr> wrote:
In the end having a monitoring system with such a constraint implies good IT work rules and the service benefits from that. We're monitoring a quite large network and guess what: our nongreen view is most of the time green ! :-) When it goes red the guys are reacting fast because they know it's serious.
This is how our network is run. It's a challenge to keep things green but they're supposed to. Windows hosts do always go red if someone's printer isn't mapped during remote desktop so in almost all cases we completely disable syslog monitoring in windows. The same holds true to other systems- if something is red a lot we must come up with a fix or change how we're monitoring things. The non-green page is used the most.
I'm still curious what those two code snippets are for? Again they were in bbdisplay/pagegen.c:
bb2page.subpages = NULL;
bb2page.groups = NULL;--Chris
In <AANLkTikrx=O_XGOhrhND8FwLjYgs02-Ei0JUX9u46kzj at mail.gmail.com> Chris Wopat <me at falz.net> writes:
I'm still curious what those two code snippets are for? Again they were in bbdisplay/pagegen.c:
bb2page.subpages = NULL; bb2page.groups = NULL;
Inside xymongen (bbgen), it's the same code that is used to generate the normal pages, the nongreen page and the old "NK" page. So this is simply a necessary initialisation since the nongreen/bb2 page doesn't have any subpages or groups.
If you would like an explanation of what this datastructure looks like inside xymongen, then have a look at the xymongen/xymongen.h file (bbdisplay/bbgen.h in 4.2.3) - there's a rather large comment at the top describing how the internal datastructure is.
Regards, Henrik
participants (3)
-
fclaire＠free.fr
-
henrik＠hswn.dk
-
me＠falz.net