Whenever I start a new Solarwinds monitoring project, companies and organisations always ask me about methods of tracking monitoring requirements.

The best way to track these requirements is with request forms. Hopefully one day Solarwinds will incorporate these kind of request forms into their products but until then these forms will act as an aid to understanding the monitoring process.

I have written previous articles about the need for organising requests from users so a monitoring engineer can better understand the users requirements for monitoring.

One of the common problems between a monitoring engineer and the general infrastructure team / dev team / network team is that of communication and lack of understanding of the monitoring process.

Before a monitoring engineer can setup a node or application to be monitored, key decisions need to be made about threshold settings for each node or group of nodes, application monitoring, alerts to apply to the nodes and many other considerations.

All of the information being entered into Solarwinds should be standardised so that future engineers do not have to suffer with disorganised custom fields or dashboards in disarray.

To try and help solve the confusion and to improve communications I have generated four forms explained below. Feel free to share.

The Node Monitoring Request Form.

Allowing us to capture :

  • The name of the node.
  • The IP address.
  • The polling method.
  • Custom properties.
  • UDT info.
  • Engineering notes, is it a VMWARE device, domain controller or should we manage it with NCM?
  • Custom thresholds.
  • IPAM addition.
  • Application monitoring requirement.
  • Group membership.
  • The list resources that should be monitored.

The Alert Request Form

Allowing us to capture :

  • Name of the alert.
  • Description of the alert.
  • Evaluation time period.
  • Alert on, Node, Application or Volume.
  • Trigger Condition.
  • Reset Condition.
  • Time of Day.
  • Trigger Action.
  • Reset Action.

The Report Request Form

Allowing us to capture :

  • Basic Report Requirement Statement.
  • How is the data to be displayed? – Table Headings
  • Server Information.
  • Application Information.

The Web Transaction Request Form

Allowing us to capture :

  • Basic WPM Requirement Statement.
  • Server FQDN.
  • Applications to be monitored / HTTP:// HTTPS://
  • Action Steps.
  • Special Requirements. Wait Times. Text verification. Image Verification.

Thanks for reading and if you have any further requests for forms please comment below and i’ll add them in.