Thought Process for Xymon Page Layout - Sanity Check
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
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 <Don.Kuhlman at schawk.com> 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)
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 <sholmes42 at mac.com<mailto:sholmes42 at mac.com>> Date: Wed, 4 Apr 2012 11:59:05 -0400 To: Don Kuhlman <don.kuhlman at schawk.com<mailto:don.kuhlman at schawk.com>> 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 <Don.Kuhlman at schawk.com<mailto:Don.Kuhlman at schawk.com>> 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)
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 <Don.Kuhlman at schawk.com> 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 <sholmes42 at mac.com> Date: Wed, 4 Apr 2012 11:59:05 -0400 To: Don Kuhlman <don.kuhlman at schawk.com> 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 <Don.Kuhlman at schawk.com>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)
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
-- 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)
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 <sholmes42 at mac.com<mailto:sholmes42 at mac.com>> Date: Wed, 4 Apr 2012 12:39:11 -0400 To: Don Kuhlman <don.kuhlman at schawk.com<mailto:don.kuhlman at schawk.com>> 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 <Don.Kuhlman at schawk.com<mailto:Don.Kuhlman at schawk.com>> 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 <sholmes42 at mac.com<mailto:sholmes42 at mac.com>> Date: Wed, 4 Apr 2012 11:59:05 -0400 To: Don Kuhlman <don.kuhlman at schawk.com<mailto:don.kuhlman at schawk.com>> 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 <Don.Kuhlman at schawk.com<mailto:Don.Kuhlman at schawk.com>> 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)
Xymon mailing list Xymon at xymon.com<mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon
-- 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)
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
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
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 <Don.Kuhlman at schawk.com> 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
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
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/
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" <Don.Kuhlman at schawk.com> 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/
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
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 <ralphmitchell at gmail.com<mailto:ralphmitchell at gmail.com>> Date: Thu, 5 Apr 2012 17:44:23 -0400 To: Don Kuhlman <don.kuhlman at schawk.com<mailto:don.kuhlman at schawk.com>> 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" <Don.Kuhlman at schawk.com<mailto:Don.Kuhlman at schawk.com>> 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/
Xymon mailing list Xymon at xymon.com<mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon
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 <sholmes42 at mac.com> 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 <Don.Kuhlman at schawk.com> 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)
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
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 <ralphmitchell at gmail.com>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 <sholmes42 at mac.com> 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 <Don.Kuhlman at schawk.com> 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)
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
-- 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)
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 Jamison at newasterisk.com<mailto:Jamison at newasterisk.com>
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 <ralphmitchell at gmail.com<mailto:ralphmitchell at gmail.com>> 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 <sholmes42 at mac.com<mailto:sholmes42 at mac.com>> 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 <Don.Kuhlman at schawk.com<mailto:Don.Kuhlman at schawk.com>> 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)
Xymon mailing list Xymon at xymon.com<mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon
-- 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)
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.).
......BruceFrom: 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
Jamison at newasterisk.com
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 <ralphmitchell at gmail.com> 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 <sholmes42 at mac.com> 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 <Don.Kuhlman at schawk.com> 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: 1-630-671-5169 | Fax: 630-893-1648 | bewhite at fellowes.com | 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.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
--
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 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 <jamison at newasterisk.com>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****
Jamison at newasterisk.com****
*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 <ralphmitchell at gmail.com> 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 <sholmes42 at mac.com> 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 <Don.Kuhlman at schawk.com> 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)
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
-- ****
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) ****
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
-- 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.
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 <glh.forums at gmail.com> 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 <jamison at newasterisk.com> 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
Jamison at newasterisk.com
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 <ralphmitchell at gmail.com> 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 <sholmes42 at mac.com> 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 <Don.Kuhlman at schawk.com> 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)
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
--
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)
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
-- 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.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
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 <sholmes42 at mac.com> 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 <Don.Kuhlman at schawk.com> 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)
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
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 <martin.flemming at desy.de> 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
martin
Ralph Mitchell
On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <sholmes42 at mac.com> 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 <Don.Kuhlman at schawk.com> 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)
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Yes, that would be handy to have!
...Bruce
Bruce White Senior Enterprise Systems Engineer | Phone: 1-630-671-5169 | Fax: 630-893-1648 | bewhite at fellowes.com | 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
martinRalph Mitchell
On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <sholmes42 at mac.com> 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 <Don.Kuhlman at schawk.com> 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)
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
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_clientsRalph Mitchell
On Fri, Apr 13, 2012 at 2:48 AM, Martin Flemming <martin.flemming at desy.de> 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
martin
Ralph Mitchell
On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <sholmes42 at mac.com> 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 <Don.Kuhlman at schawk.com> 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)
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Yes, thanks a lot !
And Xymonton is the right place :-)
Thanks & Cheers
martinOn 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_clientsRalph Mitchell
On Fri, Apr 13, 2012 at 2:48 AM, Martin Flemming <martin.flemming at desy.de> 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
martin
Ralph Mitchell
On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <sholmes42 at mac.com> 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 <Don.Kuhlman at schawk.com> 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)
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Gruss
Martin FlemmingMartin Flemming DESY / IT office : Building 2b / 008a Notkestr. 85 phone : 040 - 8998 - 4667 22603 Hamburg mail : martin.flemming at desy.de
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_clientsRalph Mitchell
On Fri, Apr 13, 2012 at 2:48 AM, Martin Flemming <martin.flemming at desy.de> 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
martin
Ralph Mitchell
On Wed, Apr 4, 2012 at 11:59 AM, Steve Holmes <sholmes42 at mac.com> 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 <Don.Kuhlman at schawk.com> 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)
participants (7)
-
bewhite＠fellowes.com
-
Don.Kuhlman＠schawk.com
-
glh.forums＠gmail.com
-
jamison＠newasterisk.com
-
martin.flemming＠desy.de
-
ralphmitchell＠gmail.com
-
sholmes42＠mac.com