Thought Process for Xymon Page Layout - Sanity Check
list Don Kuhlman
Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check… Do you set up your main page to list things by OS, then by environment – like this: Unix - then Prod, Dev, Test, Uat, etc. Windows – then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostname Applications Infrastructure Other Systems Under Server lists by hostname – I have now made up UNIX-MAC and WINDOWS Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category – like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod & Dev systems – Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K
list Steve Holmes
Don, We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon). Our main page contains 3 groups: Services Platform Support Infrastructure Under Services there are sub pages: Production Non-Production Pre-production Decommissioned Under Platform Support there is currently only: Platform Windows Servers Under Infrastructure: Authentication Network Server Provisioning Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order. Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call. Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else. The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like. Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers. The Platform Windows Servers sub page contains sub pages for Prod and Non-Prod, each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet. Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally. Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do. HTH Steve
▸
On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> wrote:
Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check… Do you set up your main page to list things by OS, then by environment – like this: Unix - then Prod, Dev, Test, Uat, etc. Windows – then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostname Applications Infrastructure Other Systems Under Server lists by hostname – I have now made up UNIX-MAC and WINDOWS Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category – like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod & Dev systems – Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K
--
If they give you ruled paper, write the other way. -Juan Ramon Jimenez,
poet, Nobel Prize in literature (1881-1958)
I prayed for freedom for twenty years, but received no answer until I
prayed with my legs. -Frederick Douglass, Former slave, abolitionist,
editor, and orator (1817-1895)
list Don Kuhlman
Thanks Steve! I appreciate your thoughtful response. More questions… Do you use the "group-only" directives to add or remove columns on your pages or do you use the "Class" directives to help arrange and organize things, or do you strictly use the page categories to help with alerts and notifications? Or maybe I am misunderstanding the use of the Class: directives from the man page. Is it only for log file monitoring? Regards, Don K
▸
From: Steve Holmes <user-ec1bf77b1b44@xymon.invalid<mailto:user-ec1bf77b1b44@xymon.invalid>>
Date: Wed, 4 Apr 2012 11:59:05 -0400
To: Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid<mailto:user-5eb2bfadc6c6@xymon.invalid>>
Cc: Xymon Email List <xymon at xymon.com<mailto:xymon at xymon.com>>
Subject: Re: [Xymon] Thought Process for Xymon Page Layout - Sanity Check
Don,
We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon).
Our main page contains 3 groups:
Services
Platform Support
Infrastructure
Under Services there are sub pages:
Production
Non-Production
Pre-production
Decommissioned
Under Platform Support there is currently only:
Platform Windows Servers
Under Infrastructure:
Authentication
Network
Server Provisioning
Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order.
Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call.
Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else.
The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like.
Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers. The Platform Windows Servers sub page contains sub pages for Prod and Non-Prod, each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet.
Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally.
Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do.
HTH
Steve
On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid<mailto:user-5eb2bfadc6c6@xymon.invalid>> wrote:
Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check…
Do you set up your main page to list things by OS, then by environment – like this:
Unix - then Prod, Dev, Test, Uat, etc.
Windows – then Prod, Dev, Test, Uat, etc.
Do you also use Application groups and then arrange them by OS and environment ?
App1, Unix, Prod
App1, Unix, Dev
Or
App1, Prod
App1, Dev
Here's what I've been doing and I'm having second thoughts about the logic of doing it this way:
Main xymon page lists the following Pages
Server lists by hostnameApplications InfrastructureOther Systems
▸
Under Server lists by hostname – I have now made up UNIX-MAC and WINDOWS
Under each of these I have PROD and DEV
Under the Applications I have several business Applications -
App1
App2
App3
In each of the App1, App2, App3, I have Prod and Dev subpages
I'm creating include files for each category – like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc.
Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg
I would like to be able to setup base rules for monitoring the Prod & Dev systems – Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense.
Then I want to create very specific service, process, or other monitoring for the application servers.
Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way?
Thanks
Don K
--
If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958)
I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
list Steve Holmes
I use group-compress rather than group-only, that way I don't have to predict which columns to show. I've never been able to get the CLASS thing to work. I tried, but either I don't understand it or it just doesn't work :-). I rely heavily on the page directives for controlling alerts. It works for us. Seve
▸
On Wed, Apr 4, 2012 at 12:33 PM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> wrote:
Thanks Steve! I appreciate your thoughtful response. More questions… Do you use the "group-only" directives to add or remove columns on your pages or do you use the "Class" directives to help arrange and organize things, or do you strictly use the page categories to help with alerts and notifications? Or maybe I am misunderstanding the use of the Class: directives from the man page. Is it only for log file monitoring? Regards, Don K From: Steve Holmes <user-ec1bf77b1b44@xymon.invalid> Date: Wed, 4 Apr 2012 11:59:05 -0400 To: Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> Cc: Xymon Email List <xymon at xymon.com> Subject: Re: [Xymon] Thought Process for Xymon Page Layout - Sanity Check Don, We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon). Our main page contains 3 groups: Services Platform Support Infrastructure Under Services there are sub pages: Production Non-Production Pre-production Decommissioned Under Platform Support there is currently only: Platform Windows Servers Under Infrastructure: Authentication Network Server Provisioning Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order. Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call. Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else. The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like. Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers. The Platform Windows Servers sub page contains sub pages for Prod and Non-Prod, each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet. Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally. Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do. HTH Steve On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid>wrote:Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check… Do you set up your main page to list things by OS, then by environment – like this: Unix - then Prod, Dev, Test, Uat, etc. Windows – then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostnameApplications InfrastructureOther Systems Under Server lists by hostname – I have now made up UNIX-MAC and WINDOWS Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category – like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod & Dev systems – Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
list Don Kuhlman
Cool. Thanks again Steve. That was my reasoning for using the page directives too – eg, use the page directives to control alerts. I think I need to do some clean up on those hosts files and includes now. :) I need to experiment with the group-compress too so I can understand the effects as I need to clean up some columns on those pages. Same here for the CLASS directive – I have a win32 in there, but haven't been able to figure out how best to use it.
▸
Regards,
Don K
From: Steve Holmes <user-ec1bf77b1b44@xymon.invalid<mailto:user-ec1bf77b1b44@xymon.invalid>>
Date: Wed, 4 Apr 2012 12:39:11 -0400
To: Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid<mailto:user-5eb2bfadc6c6@xymon.invalid>>
Cc: Xymon Email List <xymon at xymon.com<mailto:xymon at xymon.com>>
Subject: Re: [Xymon] Thought Process for Xymon Page Layout - Sanity Check
I use group-compress rather than group-only, that way I don't have to predict which columns to show.
I've never been able to get the CLASS thing to work. I tried, but either I don't understand it or it just doesn't work :-).
I rely heavily on the page directives for controlling alerts. It works for us.
Seve
On Wed, Apr 4, 2012 at 12:33 PM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid<mailto:user-5eb2bfadc6c6@xymon.invalid>> wrote:
Thanks Steve! I appreciate your thoughtful response. More questions…
Do you use the "group-only" directives to add or remove columns on your pages or do you use the "Class" directives to help arrange and organize things, or do you strictly use the page categories to help with alerts and notifications?
Or maybe I am misunderstanding the use of the Class: directives from the man page. Is it only for log file monitoring?
Regards,
Don K
From: Steve Holmes <user-ec1bf77b1b44@xymon.invalid<mailto:user-ec1bf77b1b44@xymon.invalid>>
Date: Wed, 4 Apr 2012 11:59:05 -0400
To: Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid<mailto:user-5eb2bfadc6c6@xymon.invalid>>
Cc: Xymon Email List <xymon at xymon.com<mailto:xymon at xymon.com>>
Subject: Re: [Xymon] Thought Process for Xymon Page Layout - Sanity Check
Don,
We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon).
Our main page contains 3 groups:
Services
Platform Support
Infrastructure
Under Services there are sub pages:
Production
Non-Production
Pre-production
Decommissioned
Under Platform Support there is currently only:
Platform Windows Servers
Under Infrastructure:
Authentication
Network
Server Provisioning
Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order.
Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call.
Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else.
The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like.
Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers. The Platform Windows Servers sub page contains sub pages for Prod and Non-Prod, each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet.
Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally.
Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do.
HTH
Steve
On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid<mailto:user-5eb2bfadc6c6@xymon.invalid>> wrote:
Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check…
Do you set up your main page to list things by OS, then by environment – like this:
Unix - then Prod, Dev, Test, Uat, etc.
Windows – then Prod, Dev, Test, Uat, etc.
Do you also use Application groups and then arrange them by OS and environment ?
App1, Unix, Prod
App1, Unix, Dev
Or
App1, Prod
App1, Dev
Here's what I've been doing and I'm having second thoughts about the logic of doing it this way:
Main xymon page lists the following Pages
Server lists by hostnameApplicationsInfrastructureOther Systems
▸
Under Server lists by hostname – I have now made up UNIX-MAC and WINDOWS
Under each of these I have PROD and DEV
Under the Applications I have several business Applications -
App1
App2
App3
In each of the App1, App2, App3, I have Prod and Dev subpages
I'm creating include files for each category – like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc.
Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg
I would like to be able to setup base rules for monitoring the Prod & Dev systems – Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense.
Then I want to create very specific service, process, or other monitoring for the application servers.
Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way?
Thanks
Don K
--
If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958)
I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
--
If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958)
I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
list Ralph Mitchell
Steve, On your side-note - I needed to do pretty much the same thing, for a dog-n-pony presentation to management. I don't know the *best* way to do it, but I got a second set of pages up by duplicating /home/xymon/server and changing a bunch of references in xymonserver.cfg in the copy to point to the copy structure. Then I replicated the [xymongen] entry in the original xymon/server/etc/tasks.cfg and pointed ENVFILE to the copy. Some of the reports still pull up all the hosts, but the alternate all-non-green page only shows systems that are listed in the alternate's hosts.cfg. If you have your systems split out into multiple files under hosts.d, you could just link the relevant file to the copy to avoid duplication of effort. I'm sure it can be done better, I just needed something *now* rather than *perfect*... As for ghost entries, I have a script that converts the ghost list into an "Unconfigured Client" page so that any new system shows up there within about 10 minutes of first checking in. People in other groups were installing the client on a bunch of SuSE systems I don't have access to, and we're also installing the client as part of a RHEL kickstart from Satellite. Ralph Mitchell
▸
On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <user-ec1bf77b1b44@xymon.invalid> wrote:Don, We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon). Our main page contains 3 groups: Services Platform Support Infrastructure Under Services there are sub pages: Production Non-Production Pre-production Decommissioned Under Platform Support there is currently only: Platform Windows Servers Under Infrastructure: Authentication Network Server Provisioning Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order. Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call. Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else. The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like. Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers. The Platform Windows Servers sub page contains sub pages for Prod and Non-Prod, each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet. Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally. Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do. HTH Steve On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> wrote:Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check… Do you set up your main page to list things by OS, then by environment – like this: Unix - then Prod, Dev, Test, Uat, etc. Windows – then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostname Applications Infrastructure Other Systems Under Server lists by hostname – I have now made up UNIX-MAC and WINDOWS Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category – like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod & Dev systems – Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
list Steve Holmes
Ralph, Thanks for the suggestion. That sounds like an awful lot of work, though.
▸
Steve
On Wed, Apr 4, 2012 at 12:55 PM, Ralph Mitchell <user-00a5e44c48c0@xymon.invalid>wrote:
Steve, On your side-note - I needed to do pretty much the same thing, for a dog-n-pony presentation to management. I don't know the *best* way to do it, but I got a second set of pages up by duplicating /home/xymon/server and changing a bunch of references in xymonserver.cfg in the copy to point to the copy structure. Then I replicated the [xymongen] entry in the original xymon/server/etc/tasks.cfg and pointed ENVFILE to the copy. Some of the reports still pull up all the hosts, but the alternate all-non-green page only shows systems that are listed in the alternate's hosts.cfg. If you have your systems split out into multiple files under hosts.d, you could just link the relevant file to the copy to avoid duplication of effort. I'm sure it can be done better, I just needed something *now* rather than *perfect*... As for ghost entries, I have a script that converts the ghost list into an "Unconfigured Client" page so that any new system shows up there within about 10 minutes of first checking in. People in other groups were installing the client on a bunch of SuSE systems I don't have access to, and we're also installing the client as part of a RHEL kickstart from Satellite. Ralph Mitchell On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <user-ec1bf77b1b44@xymon.invalid> wrote:Don, We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon). Our main page contains 3 groups: Services Platform Support Infrastructure Under Services there are sub pages: Production Non-Production Pre-production Decommissioned Under Platform Support there is currently only: Platform Windows Servers Under Infrastructure: Authentication Network Server Provisioning Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order. Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call. Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else. The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like. Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers.ThePlatform Windows Servers sub page contains sub pages for Prod andNon-Prod,each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet. Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally. Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do. HTH Steve On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> wrote:Hi folks. I have been modifying our xymon server host cfg file setups.Ihave been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check… Do you set up your main page to list things by OS, then by environment – like this: Unix - then Prod, Dev, Test, Uat, etc. Windows – then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostname Applications Infrastructure Other Systems Under Server lists by hostname – I have now made up UNIX-MAC and WINDOWS Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category – like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod &Devsystems – Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
list Jamison Maxwell
Currently, I'm with a rather small company with one site. So, my page layout is pretty simple. There are pages for production, development, network, storage, and external(DMZ). In production systems Unix boxes are all together, we have few compared to Windows, and Windows boxes are separated by function, i.e. database, file, web, email. Other pages are much the same way. The only reason I separate Unix from Windows, though, is because I think that putting the Unix stuff, which uses certain columns, and the Windows stuff, which bbwin gives certain columns is ugly because of the empty test columns. I use group-compress. Previously, I was with a rather large employer. At that company, there were pages for sites, and then subpages like described above. Jamison Maxwell user-87d336c3dce6@xymon.invalid<mailto:user-87d336c3dce6@xymon.invalid>
▸
From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Steve Holmes
Sent: Wednesday, April 04, 2012 2:51 PM
To: Ralph Mitchell
Cc: Xymon Email List
Subject: Re: [Xymon] Thought Process for Xymon Page Layout - Sanity Check
Ralph,
Thanks for the suggestion. That sounds like an awful lot of work, though.
Steve
On Wed, Apr 4, 2012 at 12:55 PM, Ralph Mitchell <user-00a5e44c48c0@xymon.invalid<mailto:user-00a5e44c48c0@xymon.invalid>> wrote:
Steve,
On your side-note - I needed to do pretty much the same thing, for a
dog-n-pony presentation to management. I don't know the *best* way to
do it, but I got a second set of pages up by duplicating
/home/xymon/server and changing a bunch of references in
xymonserver.cfg in the copy to point to the copy structure. Then I
replicated the [xymongen] entry in the original
xymon/server/etc/tasks.cfg and pointed ENVFILE to the copy.
Some of the reports still pull up all the hosts, but the alternate
all-non-green page only shows systems that are listed in the
alternate's hosts.cfg. If you have your systems split out into
multiple files under hosts.d, you could just link the relevant file to
the copy to avoid duplication of effort.
I'm sure it can be done better, I just needed something *now* rather
than *perfect*...
As for ghost entries, I have a script that converts the ghost list
into an "Unconfigured Client" page so that any new system shows up
there within about 10 minutes of first checking in. People in other
groups were installing the client on a bunch of SuSE systems I don't
have access to, and we're also installing the client as part of a RHEL
kickstart from Satellite.
Ralph Mitchell
On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <user-ec1bf77b1b44@xymon.invalid<mailto:user-ec1bf77b1b44@xymon.invalid>> wrote:Don, We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon). Our main page contains 3 groups: Services Platform Support Infrastructure Under Services there are sub pages: Production Non-Production Pre-production Decommissioned Under Platform Support there is currently only: Platform Windows Servers Under Infrastructure: Authentication Network Server Provisioning Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order. Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call. Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else. The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like. Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers. The Platform Windows Servers sub page contains sub pages for Prod and Non-Prod, each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet. Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally. Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do. HTH Steve On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid<mailto:user-5eb2bfadc6c6@xymon.invalid>> wrote:Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check... Do you set up your main page to list things by OS, then by environment - like this: Unix - then Prod, Dev, Test, Uat, etc. Windows - then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostname Applications Infrastructure Other Systems Under Server lists by hostname - I have now made up UNIX-MAC and WINDOWS Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category - like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod & Dev systems - Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
list Bruce White
Our main page is divided into Production, Administration (backups,
windows update, virus scanners, etc.) and development. Within each main
division, we have a page for a given location around the world (i.e. HQ,
Australia, Canada, etc.), finally items are classified into one of three
categories: Servers, Network, Other (i.e. UPSs, Tape Libraries, SAN
equipment, etc.).
......Bruce
From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf
Of Jamison Maxwell
Sent: Wednesday, April 04, 2012 6:31 PM
To: xymon at xymon.com
▸
Subject: Re: [Xymon] Thought Process for Xymon Page Layout - Sanity
Check
Currently, I'm with a rather small company with one site. So, my page
layout is pretty simple. There are pages for production, development,
network, storage, and external(DMZ). In production systems Unix boxes
are all together, we have few compared to Windows, and Windows boxes are
separated by function, i.e. database, file, web, email. Other pages are
much the same way. The only reason I separate Unix from Windows,
though, is because I think that putting the Unix stuff, which uses
certain columns, and the Windows stuff, which bbwin gives certain
columns is ugly because of the empty test columns. I use
group-compress.
Previously, I was with a rather large employer. At that company, there
were pages for sites, and then subpages like described above.
Jamison Maxwell
user-87d336c3dce6@xymon.invalid
▸
From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf
Of Steve Holmes
Sent: Wednesday, April 04, 2012 2:51 PM
To: Ralph Mitchell
Cc: Xymon Email List
Subject: Re: [Xymon] Thought Process for Xymon Page Layout - Sanity
Check
Ralph,
Thanks for the suggestion. That sounds like an awful lot of work,
though.
Steve
On Wed, Apr 4, 2012 at 12:55 PM, Ralph Mitchell
<user-00a5e44c48c0@xymon.invalid> wrote:
Steve,
On your side-note - I needed to do pretty much the same thing, for a
dog-n-pony presentation to management. I don't know the *best* way to
do it, but I got a second set of pages up by duplicating
/home/xymon/server and changing a bunch of references in
xymonserver.cfg in the copy to point to the copy structure. Then I
replicated the [xymongen] entry in the original
xymon/server/etc/tasks.cfg and pointed ENVFILE to the copy.
Some of the reports still pull up all the hosts, but the alternate
all-non-green page only shows systems that are listed in the
alternate's hosts.cfg. If you have your systems split out into
multiple files under hosts.d, you could just link the relevant file to
the copy to avoid duplication of effort.
I'm sure it can be done better, I just needed something *now* rather
than *perfect*...
As for ghost entries, I have a script that converts the ghost list
into an "Unconfigured Client" page so that any new system shows up
there within about 10 minutes of first checking in. People in other
groups were installing the client on a bunch of SuSE systems I don't
have access to, and we're also installing the client as part of a RHEL
kickstart from Satellite.
Ralph Mitchell
On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <user-ec1bf77b1b44@xymon.invalid> wrote:Don, We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon). Our main page contains 3 groups: Services Platform Support Infrastructure Under Services there are sub pages: Production Non-Production Pre-production Decommissioned Under Platform Support there is currently only: Platform Windows Servers Under Infrastructure: Authentication Network Server Provisioning Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order. Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call. Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else. The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like. Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers. The Platform Windows Servers sub page contains sub pages for Prod and
Non-Prod,
each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in.
We
could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet. Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally. Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting
NOPROPS on
all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do. HTH Steve On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> wrote:Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check... Do you set up your main page to list things by OS, then by environment - like this: Unix - then Prod, Dev, Test, Uat, etc. Windows - then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostname Applications Infrastructure Other Systems Under Server lists by hostname - I have now made up UNIX-MAC and
WINDOWS
Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category - like
HostsApp1Prod.cfg,
HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod &
Dev
systems - Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K-- If they give you ruled paper, write the other way. -Juan Ramon
Jimenez,
poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
Bruce White Senior Enterprise Systems Engineer | Phone: X-XXX-XXX-XXXX | Fax: XXX-XXX-XXXX | user-58f975e8bf9d@xymon.invalid | http://www.fellowes.com/ Disclaimer: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Fellowes, Inc.
▸
-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
list Don Kuhlman
Hi folks. I'm working on reconfiguring my hosts.cfg file structures. Using a lot of includes to try and streamline and organize things. I ran into a question about how the sorting works when using the include directives. For example, I now have the main hosts.cfg file set up to show systems by OS – UNIX/MAC and WINDOWS Under there is PROD/Dev. Under there I use includes like hosts-windows-prod.cfg, hosts-windows-dev.cfg, etc. These hosts-windows-prod.cfg etc files may include other files that I have setup by an application. For example, the application named APP1, has certain servers. It also has DEV & PROD servers. So I built a hosts-windows-app1-prod.cfg file, hosts-windows-app1-dev.cfg file. The file hosts-windows-app1-prod.cfg would be included in the hosts-windows-prod.cfg file, etc. So, how do I use the group-sorted directive to get the entire set of hosts in order if there are three different includes in the subpage or subparent groups ? More explanation below… Server1 – is in app1 in hosts-windows-app1-prod.cfg Winserver1 – is in app2 in hosts-windows-app2-prod.cfg When I use the include hosts-windows-app1-prod and include hosts-windows-app2-prod directive, with a group-sorted comand above the include statements, I'm not getting Server1 before Winserver1. Thanks Don K
list Don Kuhlman
I'm sure this is a dumb question, but I've spent most of the morning googling around and skimming through the man pages for xymon to try and figure out how to make a list of hosts shown on a particular web page line up to the left side vs. being centered. I have searched for "margins", "left justified", "web page column alignment" and still can't find the method to get certain hosts to left align on a web page. I only want to do it for certain web pages, not all host lists, or all pages. Any help would be greatly appreciated! Thanks Don K
list Don Kuhlman
Hello again folks. Today must be my xymon question day. I just posted a query about re-organizing our xymon structure via a lot of include files, by OS, App, etc. While researching this, I came across the bit below from the man pages in xymongen. If I understand this correctly, isn't this another way or the best way to organize hosts in pages without duplicating a lot of host names in different cfg files or over dosing with "includes" ? Maybe this is only for a specific type of requirement. Would anyone care to comment further ? Thanks Don K BUILDING ALTERNATE PAGESETS With version 1.4 of xymongen comes the possibility to generate multiple sets of pages from the same data. Suppose you have two groups of people looking at the Xymon webpages. Group A wants to have the hosts grouped by the client, they belong to. This is how you have Xymon set up - the default pageset. Now group B wants to have the hosts grouped by operating system - let us call it the "os" set. Then you would add the page layout to hosts.cfg like this: ospage win Microsoft Windows ossubpage win-nt4 MS Windows NT 4 osgroup NT4 File servers osgroup NT4 Mail servers ossubpage win-xp MS Windows XP ospage unix Unix ossubpage unix-sun Solaris ossubpage unix-linux Linux This defines a set of pages with one top-level page (the xymon.html page), two pages linked from xymon.html (win.html and unix.html), and from e.g. the win.html page there are subpages win-nt4.html and win-xp.html The syntax is identical to the normal "page" and "subpage" directives in hosts.cfg, but the directive is prefixed with the pageset name. Dont put any hosts in-between the page and subpage directives - just add all the directives at the top of the hosts.cfg file. How do you add hosts to the pages, then ? Simple - just put a tag "OS:win-xp" on the host definition line. The "OS" must be the same as prefix used for the pageset names, but in uppercase. The "win-xp" must match one of the pages or subpages defined within this pageset. E.g. 207.46.249.190 www.microsoft.com<http://www.microsoft.com/>; # OS:win-xp http://www.microsoft.com/ 64.124.140.181 www.sun.com<http://www.sun.com/>; # OS:unix-sun http://www.sun.com/
list Greg Hubbard
If you get to any size at all you will probably find it hard to put any configuration together that will make sense to everyone. I watch the non-green view, not the main view. After all, most of us (including me) can only look at one thing at a time. The "critical systems" view is a better version of the non-green view, but it is more trouble to set up. Once you get used to it, the non-green view looks better and better all the time! GLH
▸
On Wed, Apr 4, 2012 at 6:31 PM, Jamison Maxwell <user-87d336c3dce6@xymon.invalid>wrote:
Currently, I’m with a rather small company with one site. So, my page layout is pretty simple. There are pages for production, development, network, storage, and external(DMZ). In production systems Unix boxes are all together, we have few compared to Windows, and Windows boxes are separated by function, i.e. database, file, web, email. Other pages are much the same way. The only reason I separate Unix from Windows, though, is because I think that putting the Unix stuff, which uses certain columns, and the Windows stuff, which bbwin gives certain columns is ugly because of the empty test columns. I use group-compress.**** ** ** Previously, I was with a rather large employer. At that company, there were pages for sites, and then subpages like described above.**** ** ** ** ** ** ** Jamison Maxwell**** user-87d336c3dce6@xymon.invalid**** ** ** *From:* xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] *On Behalf Of *Steve Holmes *Sent:* Wednesday, April 04, 2012 2:51 PM *To:* Ralph Mitchell *Cc:* Xymon Email List *Subject:* Re: [Xymon] Thought Process for Xymon Page Layout - Sanity Check**** ** ** Ralph, Thanks for the suggestion. That sounds like an awful lot of work, though. Steve**** On Wed, Apr 4, 2012 at 12:55 PM, Ralph Mitchell <user-00a5e44c48c0@xymon.invalid> wrote:**** Steve, On your side-note - I needed to do pretty much the same thing, for a dog-n-pony presentation to management. I don't know the *best* way to do it, but I got a second set of pages up by duplicating /home/xymon/server and changing a bunch of references in xymonserver.cfg in the copy to point to the copy structure. Then I replicated the [xymongen] entry in the original xymon/server/etc/tasks.cfg and pointed ENVFILE to the copy. Some of the reports still pull up all the hosts, but the alternate all-non-green page only shows systems that are listed in the alternate's hosts.cfg. If you have your systems split out into multiple files under hosts.d, you could just link the relevant file to the copy to avoid duplication of effort. I'm sure it can be done better, I just needed something *now* rather than *perfect*... As for ghost entries, I have a script that converts the ghost list into an "Unconfigured Client" page so that any new system shows up there within about 10 minutes of first checking in. People in other groups were installing the client on a bunch of SuSE systems I don't have access to, and we're also installing the client as part of a RHEL kickstart from Satellite. Ralph Mitchell**** On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <user-ec1bf77b1b44@xymon.invalid> wrote:Don, We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon). Our main page contains 3 groups: Services Platform Support Infrastructure Under Services there are sub pages: Production Non-Production Pre-production Decommissioned Under Platform Support there is currently only: Platform Windows Servers Under Infrastructure: Authentication Network Server Provisioning Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order. Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call. Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else. The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like. Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers.ThePlatform Windows Servers sub page contains sub pages for Prod andNon-Prod,each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet. Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally. Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do. HTH Steve On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> wrote:Hi folks. I have been modifying our xymon server host cfg file setups.Ihave been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check… Do you set up your main page to list things by OS, then by environment – like this: Unix - then Prod, Dev, Test, Uat, etc. Windows – then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostname Applications Infrastructure Other Systems Under Server lists by hostname – I have now made up UNIX-MAC and WINDOWS Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category – like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod &Devsystems – Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895) ********-- **** If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895) **** ** **
--
Disclaimer: 1) all opinions are my own, 2) I may be completely wrong, 3)
my advice is worth at least as much as what you are paying for it, or your
money cheerfully refunded.
list Ralph Mitchell
I think that works fine for pages and sub-pages, but you still get all the hosts in the non green page. Ralph Mitchell
▸
On Apr 5, 2012 3:07 PM, "Don Kuhlman" <user-5eb2bfadc6c6@xymon.invalid> wrote:
Hello again folks. Today must be my xymon question day. I just posted a query about re-organizing our xymon structure via a lot of include files, by OS, App, etc. While researching this, I came across the bit below from the man pages in xymongen. If I understand this correctly, isn't this another way or the best way to organize hosts in pages without duplicating a lot of host names in different cfg files or over dosing with "includes" ? Maybe this is only for a specific type of requirement. Would anyone care to comment further ? Thanks Don K BUILDING ALTERNATE PAGESETS With version 1.4 of xymongen comes the possibility to generate multiple sets of pages from the same data. Suppose you have two groups of people looking at the Xymon webpages. Group A wants to have the hosts grouped by the client, they belong to. This is how you have Xymon set up - the default pageset. Now group B wants to have the hosts grouped by operating system - let us call it the "os" set. Then you would add the page layout to hosts.cfg like this: ospage win Microsoft Windows ossubpage win-nt4 MS Windows NT 4 osgroup NT4 File servers osgroup NT4 Mail servers ossubpage win-xp MS Windows XP ospage unix Unix ossubpage unix-sun Solaris ossubpage unix-linux Linux This defines a set of pages with one top-level page (the xymon.html page), two pages linked from xymon.html (win.html and unix.html), and from e.g. the win.html page there are subpages win-nt4.html and win-xp.html The syntax is identical to the normal "page" and "subpage" directives in hosts.cfg, but the directive is prefixed with the pageset name. Dont put any hosts in-between the page and subpage directives - just add all the directives at the top of the hosts.cfg file. How do you add hosts to the pages, then ? Simple - just put a tag "OS:win-xp" on the host definition line. The "OS" must be the same as prefix used for the pageset names, but in uppercase. The "win-xp" must match one of the pages or subpages defined within this pageset. E.g.
207.46.249.190 www.microsoft.com # OS:win-xp http://www.microsoft.com/ 64.124.140.181 www.sun.com # OS:unix-sun http://www.sun.com/
list Don Kuhlman
Thanks Ralph. I did some testing with the OS directives as below. It appears as though the new pages are "hidden" as I don't see any links on the main pages to them, which means I can find them by directly entering their url. Has anyone else tried this and have you used another method to show the link to the servers by os directly on a xymon web page ? ospage win Windows Servers ossubpage win-prod Production ossubpage win-dev Dev ospage macunix Mac-Unix Servers ossubpage macunix-prod Production ossubpage macunix-dev Dev Regards, Don K
▸
From: Ralph Mitchell <user-00a5e44c48c0@xymon.invalid<mailto:user-00a5e44c48c0@xymon.invalid>> Date: Thu, 5 Apr 2012 17:44:23 -0400 To: Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid<mailto:user-5eb2bfadc6c6@xymon.invalid>> Cc: Xymon Email List <xymon at xymon.com<mailto:xymon at xymon.com>> Subject: Re: [Xymon] Another method to group and categorize hosts - "Building Alternate Pagesets" I think that works fine for pages and sub-pages, but you still get all the hosts in the non green page. Ralph Mitchell On Apr 5, 2012 3:07 PM, "Don Kuhlman" <user-5eb2bfadc6c6@xymon.invalid<mailto:user-5eb2bfadc6c6@xymon.invalid>> wrote: Hello again folks. Today must be my xymon question day. I just posted a query about re-organizing our xymon structure via a lot of include files, by OS, App, etc. While researching this, I came across the bit below from the man pages in xymongen. If I understand this correctly, isn't this another way or the best way to organize hosts in pages without duplicating a lot of host names in different cfg files or over dosing with "includes" ? Maybe this is only for a specific type of requirement. Would anyone care to comment further ? Thanks Don K BUILDING ALTERNATE PAGESETS With version 1.4 of xymongen comes the possibility to generate multiple sets of pages from the same data. Suppose you have two groups of people looking at the Xymon webpages. Group A wants to have the hosts grouped by the client, they belong to. This is how you have Xymon set up - the default pageset. Now group B wants to have the hosts grouped by operating system - let us call it the "os" set. Then you would add the page layout to hosts.cfg like this: ospage win Microsoft Windows ossubpage win-nt4 MS Windows NT 4 osgroup NT4 File servers osgroup NT4 Mail servers ossubpage win-xp MS Windows XP ospage unix Unix ossubpage unix-sun Solaris ossubpage unix-linux Linux This defines a set of pages with one top-level page (the xymon.html page), two pages linked from xymon.html (win.html and unix.html), and from e.g. the win.html page there are subpages win-nt4.html and win-xp.html The syntax is identical to the normal "page" and "subpage" directives in hosts.cfg, but the directive is prefixed with the pageset name. Dont put any hosts in-between the page and subpage directives - just add all the directives at the top of the hosts.cfg file. How do you add hosts to the pages, then ? Simple - just put a tag "OS:win-xp" on the host definition line. The "OS" must be the same as prefix used for the pageset names, but in uppercase. The "win-xp" must match one of the pages or subpages defined within this pageset. E.g. 207.46.249.190 www.microsoft.com<http://www.microsoft.com/>; # OS:win-xp http://www.microsoft.com/ 64.124.140.181 www.sun.com<http://www.sun.com/>; # OS:unix-sun http://www.sun.com/
list Ralph Mitchell
I think it's hard-wired into the pagegen.c program. Every table
element starts with:
<TD ALIGN=CENTER>
in xymon-4.3.7/xymongen/pagegen.c at line 542.
Ralph Mitchell
▸
On Thu, Apr 5, 2012 at 3:02 PM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> wrote:I'm sure this is a dumb question, but I've spent most of the morning googling around and skimming through the man pages for xymon to try and figure out how to make a list of hosts shown on a particular web page line up to the left side vs. being centered. I have searched for "margins", "left justified", "web page column alignment" and still can't find the method to get certain hosts to left align on a web page. I only want to do it for certain web pages, not all host lists, or all pages. Any help would be greatly appreciated! Thanks Don K
list Ralph Mitchell
EDS Enterprise Command Center in Tulsa only ever watched the non-green view. Too much clicking back and forth otherwise, with over 350 systems scattered through a bunch of pages.
▸
Ralph Mitchell
On Thu, Apr 5, 2012 at 3:39 PM, Greg Hubbard <user-435e16ecfd6a@xymon.invalid> wrote:If you get to any size at all you will probably find it hard to put any configuration together that will make sense to everyone. I watch the non-green view, not the main view. After all, most of us (including me) can only look at one thing at a time. The "critical systems" view is a better version of the non-green view, but it is more trouble to set up. Once you get used to it, the non-green view looks better and better all the time! GLH
On Wed, Apr 4, 2012 at 6:31 PM, Jamison Maxwell <user-87d336c3dce6@xymon.invalid>
▸
wrote:Currently, I’m with a rather small company with one site. So, my page layout is pretty simple. There are pages for production, development, network, storage, and external(DMZ). In production systems Unix boxes are all together, we have few compared to Windows, and Windows boxes are separated by function, i.e. database, file, web, email. Other pages are much the same way. The only reason I separate Unix from Windows, though, is because I think that putting the Unix stuff, which uses certain columns, and the Windows stuff, which bbwin gives certain columns is ugly because of the empty test columns. I use group-compress. Previously, I was with a rather large employer. At that company, there were pages for sites, and then subpages like described above. Jamison Maxwell user-87d336c3dce6@xymon.invalid From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Steve Holmes Sent: Wednesday, April 04, 2012 2:51 PM To: Ralph Mitchell Cc: Xymon Email List Subject: Re: [Xymon] Thought Process for Xymon Page Layout - Sanity Check Ralph, Thanks for the suggestion. That sounds like an awful lot of work, though. Steve On Wed, Apr 4, 2012 at 12:55 PM, Ralph Mitchell <user-00a5e44c48c0@xymon.invalid> wrote: Steve, On your side-note - I needed to do pretty much the same thing, for a dog-n-pony presentation to management. I don't know the *best* way to do it, but I got a second set of pages up by duplicating /home/xymon/server and changing a bunch of references in xymonserver.cfg in the copy to point to the copy structure. Then I replicated the [xymongen] entry in the original xymon/server/etc/tasks.cfg and pointed ENVFILE to the copy. Some of the reports still pull up all the hosts, but the alternate all-non-green page only shows systems that are listed in the alternate's hosts.cfg. If you have your systems split out into multiple files under hosts.d, you could just link the relevant file to the copy to avoid duplication of effort. I'm sure it can be done better, I just needed something *now* rather than *perfect*... As for ghost entries, I have a script that converts the ghost list into an "Unconfigured Client" page so that any new system shows up there within about 10 minutes of first checking in. People in other groups were installing the client on a bunch of SuSE systems I don't have access to, and we're also installing the client as part of a RHEL kickstart from Satellite. Ralph Mitchell On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <user-ec1bf77b1b44@xymon.invalid> wrote:Don, We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon). Our main page contains 3 groups: Services Platform Support Infrastructure Under Services there are sub pages: Production Non-Production Pre-production Decommissioned Under Platform Support there is currently only: Platform Windows Servers Under Infrastructure: Authentication Network Server Provisioning Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order. Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call. Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else. The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like. Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers. The Platform Windows Servers sub page contains sub pages for Prod and Non-Prod, each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet. Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally. Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do. HTH Steve On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> wrote:Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check… Do you set up your main page to list things by OS, then by environment – like this: Unix - then Prod, Dev, Test, Uat, etc. Windows – then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostname Applications Infrastructure Other Systems Under Server lists by hostname – I have now made up UNIX-MAC and WINDOWS Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category – like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod & Dev systems – Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)-- Disclaimer: 1) all opinions are my own, 2) I may be completely wrong, 3) my advice is worth at least as much as what you are paying for it, or your money cheerfully refunded.
list Martin Flemming
▸
On Wed, 4 Apr 2012, Ralph Mitchell wrote:
As for ghost entries, I have a script that converts the ghost list into an "Unconfigured Client" page so that any new system shows up there within about 10 minutes of first checking in.
Hi, Ralph ! Thats sounds cool, is it possible to share this script ? thanks & cheers martin
▸
Ralph Mitchell On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <user-ec1bf77b1b44@xymon.invalid> wrote:Don, We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon). Our main page contains 3 groups: Services Platform Support Infrastructure Under Services there are sub pages: Production Non-Production Pre-production Decommissioned Under Platform Support there is currently only: Platform Windows Servers Under Infrastructure: Authentication Network Server Provisioning Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order. Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call. Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else. The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like. Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers. The Platform Windows Servers sub page contains sub pages for Prod and Non-Prod, each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet. Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally. Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do. HTH Steve On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> wrote:Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check… Do you set up your main page to list things by OS, then by environment – like this: Unix - then Prod, Dev, Test, Uat, etc. Windows – then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostname Applications Infrastructure Other Systems Under Server lists by hostname – I have now made up UNIX-MAC and WINDOWS Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category – like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod & Dev systems – Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
list Ralph Mitchell
Let's see if the script makes it through the mail... :-) I run this thing from xymon's crontab. It doesn't really require any particular xymon environment, but you could equally well from it from the xymon tasks.cfg like any other ext test. One of these days I'll get around to posting things like this to xymonton... Ralph Mitchell On Fri, Apr 13, 2012 at 2:48 AM, Martin Flemming
▸
<user-f286aaa49a76@xymon.invalid> wrote:On Wed, 4 Apr 2012, Ralph Mitchell wrote:As for ghost entries, I have a script that converts the ghost list into an "Unconfigured Client" page so that any new system shows up there within about 10 minutes of first checking in.Hi, Ralph ! Thats sounds cool, is it possible to share this script ? thanks & cheers martinRalph Mitchell On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <user-ec1bf77b1b44@xymon.invalid> wrote:Don, We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon). Our main page contains 3 groups: Services Platform Support Infrastructure Under Services there are sub pages: Production Non-Production Pre-production Decommissioned Under Platform Support there is currently only: Platform Windows Servers Under Infrastructure: Authentication Network Server Provisioning Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order. Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call. Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else. The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like. Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers. The Platform Windows Servers sub page contains sub pages for Prod and Non-Prod, each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet. Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally. Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do. HTH Steve On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> wrote:Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check… Do you set up your main page to list things by OS, then by environment – like this: Unix - then Prod, Dev, Test, Uat, etc. Windows – then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostname Applications Infrastructure Other Systems Under Server lists by hostname – I have now made up UNIX-MAC and WINDOWS Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category – like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod & Dev systems – Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
Attachments (1)
list Bruce White
Yes, that would be handy to have!
...Bruce
▸
Bruce White Senior Enterprise Systems Engineer | Phone: X-XXX-XXX-XXXX | Fax: XXX-XXX-XXXX | user-58f975e8bf9d@xymon.invalid | http://www.fellowes.com/ Disclaimer: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Fellowes, Inc. -----Original Message-----
▸
From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Martin Flemming
Sent: Friday, April 13, 2012 1:49 AM
To: xymon at xymon.com
Subject: Re: [Xymon] Thought Process for Xymon Page Layout - Sanity Check
On Wed, 4 Apr 2012, Ralph Mitchell wrote:
As for ghost entries, I have a script that converts the ghost list into an "Unconfigured Client" page so that any new system shows up there within about 10 minutes of first checking in.
Hi, Ralph ! Thats sounds cool, is it possible to share this script ? thanks & cheers martin
Ralph Mitchell On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <user-ec1bf77b1b44@xymon.invalid> wrote:Don, We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon). Our main page contains 3 groups: Services Platform Support Infrastructure Under Services there are sub pages: Production Non-Production Pre-production Decommissioned Under Platform Support there is currently only: Platform Windows Servers Under Infrastructure: Authentication Network Server Provisioning Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order. Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call. Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else. The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like. Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers. The Platform Windows Servers sub page contains sub pages for Prod and Non-Prod, each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet. Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally. Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do. HTH Steve On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> wrote:Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check... Do you set up your main page to list things by OS, then by environment - like this: Unix - then Prod, Dev, Test, Uat, etc. Windows - then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostname Applications Infrastructure Other Systems Under Server lists by hostname - I have now made up UNIX-MAC and WINDOWS Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category - like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod & Dev systems - Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
list Ralph Mitchell
I don't know if the script attachment made it through or not, but I've
just added it to Xymonton anyway:
http://xymonton.org/addons:unconfigured_clients
▸
Ralph Mitchell
On Fri, Apr 13, 2012 at 2:48 AM, Martin Flemming
▸
<user-f286aaa49a76@xymon.invalid> wrote:On Wed, 4 Apr 2012, Ralph Mitchell wrote:As for ghost entries, I have a script that converts the ghost list into an "Unconfigured Client" page so that any new system shows up there within about 10 minutes of first checking in.Hi, Ralph ! Thats sounds cool, is it possible to share this script ? thanks & cheers martinRalph Mitchell On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <user-ec1bf77b1b44@xymon.invalid> wrote:Don, We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon). Our main page contains 3 groups: Services Platform Support Infrastructure Under Services there are sub pages: Production Non-Production Pre-production Decommissioned Under Platform Support there is currently only: Platform Windows Servers Under Infrastructure: Authentication Network Server Provisioning Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order. Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call. Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else. The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like. Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers. The Platform Windows Servers sub page contains sub pages for Prod and Non-Prod, each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet. Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally. Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do. HTH Steve On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> wrote:Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check… Do you set up your main page to list things by OS, then by environment – like this: Unix - then Prod, Dev, Test, Uat, etc. Windows – then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostname Applications Infrastructure Other Systems Under Server lists by hostname – I have now made up UNIX-MAC and WINDOWS Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category – like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod & Dev systems – Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
list Martin Flemming
Yes, thanks a lot ! And Xymonton is the right place :-) Thanks & Cheers martin
▸
On Sat, 14 Apr 2012, Ralph Mitchell wrote:
I don't know if the script attachment made it through or not, but I've just added it to Xymonton anyway: http://xymonton.org/addons:unconfigured_clients Ralph Mitchell On Fri, Apr 13, 2012 at 2:48 AM, Martin Flemming <user-f286aaa49a76@xymon.invalid> wrote:On Wed, 4 Apr 2012, Ralph Mitchell wrote:As for ghost entries, I have a script that converts the ghost list into an "Unconfigured Client" page so that any new system shows up there within about 10 minutes of first checking in.Hi, Ralph ! Thats sounds cool, is it possible to share this script ? thanks & cheers martinRalph Mitchell On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <user-ec1bf77b1b44@xymon.invalid> wrote:Don, We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon). Our main page contains 3 groups: Services Platform Support Infrastructure Under Services there are sub pages: Production Non-Production Pre-production Decommissioned Under Platform Support there is currently only: Platform Windows Servers Under Infrastructure: Authentication Network Server Provisioning Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order. Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call. Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else. The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like. Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers. The Platform Windows Servers sub page contains sub pages for Prod and Non-Prod, each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet. Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally. Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do. HTH Steve On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> wrote:Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check… Do you set up your main page to list things by OS, then by environment – like this: Unix - then Prod, Dev, Test, Uat, etc. Windows – then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostname Applications Infrastructure Other Systems Under Server lists by hostname – I have now made up UNIX-MAC and WINDOWS Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category – like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod & Dev systems – Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
Gruss
Martin Flemming
Martin Flemming
DESY / IT office : Building 2b / 008a
Notkestr. 85 phone : XXX - XXXX - XXXX
22603 Hamburg mail : user-f286aaa49a76@xymon.invalid
list Martin Flemming
Hi and once again ! The script ist working perfectly, but i've got the issue if i removed one host from the new gernerated ghost-list to a "offical" server-page, this host appears after running the script again in the gernerated ghost-list :-( After restart of xymond, the host doesn't appear again of course, but i don't want restart xymond everytime, if a new ghosthost arrives .... .. or is this the only possiblity ? .. a kill -SIGHUP (xymond-pid) didn't work ... .. i work with xymond 4.3.7 cheers, martin
▸
On Sun, 15 Apr 2012, Martin Flemming wrote:
Yes, thanks a lot ! And Xymonton is the right place :-) Thanks & Cheers martin On Sat, 14 Apr 2012, Ralph Mitchell wrote:I don't know if the script attachment made it through or not, but I've just added it to Xymonton anyway: http://xymonton.org/addons:unconfigured_clients Ralph Mitchell On Fri, Apr 13, 2012 at 2:48 AM, Martin Flemming <user-f286aaa49a76@xymon.invalid> wrote:On Wed, 4 Apr 2012, Ralph Mitchell wrote:As for ghost entries, I have a script that converts the ghost list into an "Unconfigured Client" page so that any new system shows up there within about 10 minutes of first checking in.Hi, Ralph ! Thats sounds cool, is it possible to share this script ? thanks & cheers martinRalph Mitchell On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <user-ec1bf77b1b44@xymon.invalid> wrote:Don, We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon). Our main page contains 3 groups: Services Platform Support Infrastructure Under Services there are sub pages: Production Non-Production Pre-production Decommissioned Under Platform Support there is currently only: Platform Windows Servers Under Infrastructure: Authentication Network Server Provisioning Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order. Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call. Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else. The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like. Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers. The Platform Windows Servers sub page contains sub pages for Prod and Non-Prod, each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet. Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally. Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do. HTH Steve On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> wrote:Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check… Do you set up your main page to list things by OS, then by environment – like this: Unix - then Prod, Dev, Test, Uat, etc. Windows – then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostname Applications Infrastructure Other Systems Under Server lists by hostname – I have now made up UNIX-MAC and WINDOWS Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category – like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod & Dev systems – Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)
list Ralph Mitchell
Sigh - and copy my reply to the list as well. Ralph Mitchell On Thu, Apr 19, 2012 at 7:00 AM, Ralph Mitchell <user-00a5e44c48c0@xymon.invalid> wrote:
I have the same thing going on with 4.3.6. Try just commenting hosts out in the generated ghost-list. The script greps in the file for each ghost it finds, and doesn't distinguish between active entries and those commented out. It seems like xymon may be remembering ghost clients even after they get a regular hosts file entry and start showing up elsewhere. I should probably use xymon's hostgrep to see if the ghost appears elsewhere. Ralph Mitchell On Thu, Apr 19, 2012 at 4:31 AM, Martin Flemming
▸
<user-f286aaa49a76@xymon.invalid> wrote:Hi and once again ! The script ist working perfectly, but i've got the issue if i removed one host from the new gernerated ghost-list to a "offical" server-page, this host appears after running the script again in the gernerated ghost-list :-( After restart of xymond, the host doesn't appear again of course, but i don't want restart xymond everytime, if a new ghosthost arrives .... .. or is this the only possiblity ? .. a kill -SIGHUP (xymond-pid) didn't work ... .. i work with xymond 4.3.7 cheers, martin On Sun, 15 Apr 2012, Martin Flemming wrote:Yes, thanks a lot ! And Xymonton is the right place :-) Thanks & Cheers martin On Sat, 14 Apr 2012, Ralph Mitchell wrote:I don't know if the script attachment made it through or not, but I've just added it to Xymonton anyway: http://xymonton.org/addons:unconfigured_clients Ralph Mitchell On Fri, Apr 13, 2012 at 2:48 AM, Martin Flemming <user-f286aaa49a76@xymon.invalid> wrote:On Wed, 4 Apr 2012, Ralph Mitchell wrote:As for ghost entries, I have a script that converts the ghost list into an "Unconfigured Client" page so that any new system shows up there within about 10 minutes of first checking in.Hi, Ralph ! Thats sounds cool, is it possible to share this script ? thanks & cheers martinRalph Mitchell On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <user-ec1bf77b1b44@xymon.invalid> wrote:Don, We have wrestled with the same issues. We started with systems organized by OS (Unix/Windows) and then as more apps became multi-platform have moved away from the platform centric organization, with some exceptions. The reason for the change is so we can see at a glance when there is a problem in a service we support so when there is a problem the customers for that service can be notified, unless the problem is fixed before the customers have to be notified (which is the big payoff with using Xymon). Our main page contains 3 groups: Services Platform Support Infrastructure Under Services there are sub pages: Production Non-Production Pre-production Decommissioned Under Platform Support there is currently only: Platform Windows Servers Under Infrastructure: Authentication Network Server Provisioning Prod and non-prod each have a list of application/service areas as sub pages, each of which is a list of hosts in logical groups with no respect for OS platform. Within the groups the hosts are listed in alpha order. Pre-production contains hosts which are not in production yet, but will be heading there (with some arm twisting at times). The reason for this is the OPS center only calls support for alerts that show up on a production page. Hosts in pre-prod (as well as non-prod) can fail without causing a call. Decommissioned is where we put host entries for hosts that are just that. We keep them there for a year after they've gone off line in case someone wants to see the history. They all have noconn and all the NOPROPS so they don't show up anywhere else. The Infrastructure group is also production, but not application specific. This is an area currently under development so it is incomplete. There we have network devices, DNS servers, and the like. Platform Support was a special request from the Windows admins to group all of the windows servers in one place (with duplicate entries) so they don't have to look through all of the application pages to find their servers. The Platform Windows Servers sub page contains sub pages for Prod and Non-Prod, each of which is grouped by application area. Yes, this duplicates the work I have to do when Windows systems are added, but they know that if they don't tell me exactly where to put the duplicate entry it won't go in. We could also put a page in there for Linux/Solaris admins, but that hasn't been requested, yet. Many times when a new server shows up in the ghost report I have to ask the admins for information about where it should go. Our naming convention helps, but not totally. Side note: OPS likes to watch the all-non-green page. But that contains non-green tests for non-prod as well as prod. I would really like to be able to provide them with an all-non-green-prod-only (for lack of better terminology) so they could easily see what they need to. Putting NOPROPS on all non-prod would prevent the admins from being able to use the same page to watch everything. Something I'm not willing to do. HTH Steve On Wed, Apr 4, 2012 at 10:57 AM, Don Kuhlman <user-5eb2bfadc6c6@xymon.invalid> wrote:Hi folks. I have been modifying our xymon server host cfg file setups. I have been moving page layouts around. I thought I would send a note to the list to see what others are doing in their web page layouts just to have a sanity check… Do you set up your main page to list things by OS, then by environment – like this: Unix - then Prod, Dev, Test, Uat, etc. Windows – then Prod, Dev, Test, Uat, etc. Do you also use Application groups and then arrange them by OS and environment ? App1, Unix, Prod App1, Unix, Dev Or App1, Prod App1, Dev Here's what I've been doing and I'm having second thoughts about the logic of doing it this way: Main xymon page lists the following Pages Server lists by hostname Applications Infrastructure Other Systems Under Server lists by hostname – I have now made up UNIX-MAC and WINDOWS Under each of these I have PROD and DEV Under the Applications I have several business Applications - App1 App2 App3 In each of the App1, App2, App3, I have Prod and Dev subpages I'm creating include files for each category – like HostsApp1Prod.cfg, HostsApp1Dev.cfg, HostsApp2Prod.cfg, HostsApp2Dev.cfg, etc. Now that I've changed it, I will probably need to create new HostsApp1ProdUnixMac.cfg, HostsApp1ProdWindows.cfg I would like to be able to setup base rules for monitoring the Prod & Dev systems – Prod disk, mem, cpu is different than Dev disk, mem, cpu, etc. That's why I thought breaking out by OS and then environment would make sense. Then I want to create very specific service, process, or other monitoring for the application servers. Does this seem like a good way to go, or am I making it too complicated by breaking everything down this way? Thanks Don K-- If they give you ruled paper, write the other way. -Juan Ramon Jimenez, poet, Nobel Prize in literature (1881-1958) I prayed for freedom for twenty years, but received no answer until I prayed with my legs. -Frederick Douglass, Former slave, abolitionist, editor, and orator (1817-1895)