Versions Compared

Version Old Version 13 New Version 14
Changes made by

Jennifer Murray (Unlicensed)

Jennifer Murray (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Section
bordertrue

Description: 

Xymon is the web based monitoring tool of choice for Administrators and staff supporting ITSO Windows and Unix processes on the Purdue Campus. It performs a valuable duty, giving the trained eye a quick overview of the hardware and processes that may be out of synch for several key University areas.


In general, IOC staff will only need to respond to Critical (Red) alerts that affect production devices (Servers, Virtual Machines, etc.) All production Xymon alerts should also be reflected in SquaredUp. Generally, if a critical production alert appears in Xymon for more

...

than 20 minutes, a system administrator or equivalent will need to be contacted regarding their malfunctioning equipment. In the event of a hardware failure, contact the appropriate system owner ASAP. Each shift is responsible for learning their time of day’s appropriate contact procedures.


Section

Location:

Xymon: All non-green

...

systems -  Keep this link up on workstation.

https://monitor.itap.purdue.edu/- Top level view that displays alerts by group. It is suggested that one create a sidebar for this view.

Categories include:

  • ITIS Services – Production, Non-production, Pre-production machines and VMs for a number of systems such as Oracle, Banner, Blackboard, SAP. 

...

  • IOC Operators should only be concerned with devices nested within Production.
  • Infrastructure – There are no devices exclusively within this category that Technical Operators are required to monitor.
  • Platform Support – Windows production and test boxes for applications. This category is in place for Windows administrators. There are no devices exclusively within this category that Technical Operators are required to monitor.




Panel
titleOn - Call Instructions

Before calling on any alarm review the following: 

  1. Locate the night's planned maintenance in the Footprints Change and Release Management workspace calendar to ensure the device is not scheduled to be down. 
  2. If a server is either specifically mentioned in an RFC or can be inferred to be part of an RFC, no calls should be placed to the group responsible for the system.  
  3. If the system is listed as anything other than production under ITIS services in the main view in Xymon do not call. 
  4. Operators only need to call for an Xymon alarm if it is also showing on Squared Up. 

After a new Squared Up alert pops up for a production machine, If the alert is still present after 20 minutes Operations will need to call the group responsible for the system. 

  1. After a new Xymon critical alert pops up for a production machine, begin considering which group to contact, if any. If the alert is still present after 20 minutes Operations will need to call the system owner.
  2. Is the alert for a clustered device? Some systems, likeMailhub, are clustered, and thus can have several alerts before one needs to take action. Generally clustered machines will NOT alarm in Squared Up for individual boxes, but they will inXymon. This clue can help an operator determine the severity of the Xymon alert. There are some clustered systems which react in the opposite manner - They will alert in Squared Up but not Xymon until critical mass is reached. In these cases ensure enough machines are in alert before contacting the appropriate admins. 
  3. Locate the night's planned maintenance in the Footprints Change and Release Management Workspace Calendar to ensure the device is not scheduled to be down.
  4. Xymon- Click the status icon (pictured below) along the row corresponding to the trouble server.  
  5. Some admins have placed instructions for which alarms should be ignored or contact instructions in this page (pictured below is an example of these instructions). Follow any special instructions for the machine OR use the Configuration Management Database (CMDB) to locate the appropriate on-call. 
  6. Call the on-call and inform them of the situation, affected device, and any other issues that may be cropping up due to the alert. Send a follow-up email. For CPU, memory, and disk alerts, paste the Xymon alert text into the email. 
  7. Log the contact, and appropriate follow-up activities.

...