Submit a ticketCall us

Systems Monitoring for Dummies
Our new eBook will teach you the fundamentals and help you create monitors and alerts that are effective, meaningful, and actionable. Monitoring is more than a checkbox on your to-do list. This free eBook will give you practical advice to help you succeed in all aspects of monitoring – discovery, alerting, remediation, and troubleshooting. Don’t miss out on this indispensable resource for newbies, experienced IT pros, and everyone in between. Register Now.

Home > Success Center > Orion Platform > Orion Documentation > Orion Trouble Ticket System Integration

Orion Trouble Ticket System Integration

Created by Magdalena.Markova, last modified by Magdalena.Markova on Nov 08, 2017

Views: 165 Votes: 0 Revisions: 106

Updated: October 25, 2017

Summary

Sending email messages from the Orion Platform to the Trouble Ticket System (TTS) is the most common method used to integrate Orion Platform products with a TTS. This method offers an easy integration with existing systems.

This article provides more information about how this integration works, how to plan and test it.

Other integration options include:

Learn more:

Step 1: Review how the integration works

The diagram shows an Orion Platform server integrated with a trouble ticket system:

  1. Alerts on the Orion server send emails to the SMTP server.
  2. The SMTP server forwards the email alerts to the specified primary recipient. Some emails are addressed to the TTS, others to network engineers.
  3. The TTS creates actions and assigns them based on the input from the alert emails.Image_003.png

Step 2: Specify requirements for integrating your TTS

When an alert condition occurs, the Orion Platform sends an alert email to the SMTP server.

Trouble Ticket Systems (TTSs) use parsers to extract the trouble ticket information from emails and other sources. You must specify the information included in the emails. Consult your TTS vendor documentation for specific requirements to your TTS version.

Possible vendor requirements include:

  • SMTP server name and network information for the TTS return emails.
  • A TTS return email address to indicate an alert was received.
  • Event types used by the Orion Platform to send email alerts to the TTS.
  • Capabilities and format of an Orion Platform email alert.
  • Event criticality.
  • TTS requirements for accepting the email text.
  • Static information, such as severity level and impact, included in the TTS body or subject header.
  • Dynamic (variable) information the TTS expects from the Orion Platform, such as node ID, IP address, contact information and the alert trigger time for the affected device.

    Variables require a specific format. For example:  ${variable}

  • Alert reset actions that clear automated alerts when the alert conditions no longer apply.
  • Any requirements to automatically acknowledge alerts.

Example requirements for a WAN node down TTS alert

The following example alert is configured and implemented as a WAN-only alert. It contains both static and dynamic information.
Email Subject: ${N=SwisEntity;M=Caption} at ${N=SwisEntity;M=IP_Address} went down at ${N=Alerting;M=AlertTriggerTime}

Email body:

Impact: 2

Urgency: 2

Priority: 3

ContactType: monitoring service OpenedBy: Solarwinds

Category: network

SubCategory: wan Type: access failure

AssignmentGroupAssignmentGroup: network

The Orion Platform server populates the email subject variables with alert details about the node with issues. The email body contains static text information specific to this alert. 

The static text information is intended for the TTS and is unnecessary for a direct Orion Platform email alert.

  • To apply alerts only to WAN interfaces or WAN routers, label WAN interfaces and routers with a custom property, such as the yes/no custom property WAN_Routers. This can help you define the static information in the alerts and assign the alerts to device types. See Custom properties for more information.
  • SolarWinds recommends using an alert variable, such as an IP address, to uniquely define the device.
  • Device identifiers, such as a node name, may include case sensitivity or other formatting issues that can generate device identification errors.

Requirements to automatically acknowledge alerts

Specify an alert reset action to clear alerts sent to the TTS. Example:

Email Subject: ${N=SwisEntity;M=Caption} at ${N=SwisEntity;M=IP_Address} returned to service as ${N=SwisEntity;M=StatusDescription}

To automatically clear alerts in email integration, follow these steps:

  1. Create the alert trigger condition and trigger action that sends an email notification to the TTS.

  2. Apply a reset condition to the alert.

  3. Create an email reset action to communicate the updated node status to the TTS.

  4. Apply TTS logic to clear the ticket or change the ticket status.

In some environments, the status change initiated by the reset can close a ticket. In other environments, the ticket is assigned to an engineer who reviews, verifies, and closes the ticket manually.

Step 3: Implement a test plan

After you define all requirements, test the alerting integration. The test plan should ensure that the Orion Platform/TTS tickets are implemented to yield the maximum benefit and cause the least disturbance.

When designing a test plan, consider the following aspects:

Alert recipients

There are two groups of alert recipients:

  • Recipients who receive Orion Platform alerts
  • Recipients that receive TTS alert actions

Make these groups complementary so that the Orion Platform server directly alerts on issues that are out of the scope of the TTS requirements.

TTS alerts or Orion Platform alerts

Both direct Orion Platform product alerts and TTS alerts have unique abilities and so both are used in production environments.

Set the TTS to send alert actions for issues that require a ticket.

Set the Orion Platform products to send direct alerts that do not need to go through the ticket system, such as:

  • Orion Platform test alerts
  • Alerts for systems that do not impact end users
  • Warning alerts for exceeding thresholds
  • Alerts for parties outside of the TTS user domain, such as third-party staffing or maintenance
  • Other alerts that do not require a ticket in the TTS

Example test flow

The final test plan should include the following elements:

  • The purpose of initial alert(s) to be created and tested.
  • Orion Platform-only initial alert test targets.
  • Criteria for success in initial Orion Platform-only alerts.
  • Migration of Orion Platform-only initial test alert to TTS test group only.
  • Criteria for success of integration TTS test alert and action(s) to test group. Expansion of TTS test alert actions to broader parties.
  • Criteria for acceptance of broader test.
  • Final decision to implement first TTS alert and associated communications.
  • Requirements for the rollout of subsequent TTS alerts and actions.

The following is an example of a test plan flow.

Image_010.png

When testing alerts, copy alerts and save them under a new name. Make sure you rename and enable the new copy and disable alerts that are no longer used. You can either retain both an Orion Platform-only alert for a small group and the TTS-enabled alert for a broader audience to keep a backup system to notify critical parties of network outages should TTS problems occur.

See Test alert triggers and actions

Step 4: Transition alerts to production

After you verify that TTS alerts and actions meet the requirements set out in the planning phase, implement the alerts.

SolarWinds recommends that you test alerts with a limited TTS audience before you roll out all alerts.

Some Orion Platform customers have created script-based solutions for integrating alerts. Script-based solutions can add flexibility, but they are more complex than an email integration. For more information on these integration solutions, see posts on THWACK.

Acknowledge alerts automatically

The direction of integrated email information flow is one way, moving from the Orion server to the SMTP gateway to the TTS. You can use the Orion SDK to automatically set the alert status to acknowledged in Orion when a TTS email is sent. The SDK is a special developer tool and is not intended for typical Orion Platform users.

Using the Orion SDK kit requires the know-how to use a Developer’s Tool Kit without tutoring or special instructions. Learn more about the SDK:

Integrate TTS web functions into the Orion Web Console

Most TTS platforms offer a web interface for creating, updating, or viewing tickets. Orion Platform products offer two widgets, or resources, you can use to display the TTS information in the Orion Web Console: User Links and Custom HTML.

For specific information on your TTSs web abilities, refer to the manufacturer’s documentation.

To display the TTS details in the Orion Web Console:

  1. Add the User Links or Custom HTML widget to a view.
  2. Configure the widget to display the TTS details. See Widget configuration examples in the Orion Platform online help for details about configuring the User links and Custom HTML widgets.

User links 

Include the TTS URL in a User Links resource added to an Orion Web Console view.

Image_012.png

Custom HTML widget

Some TTS platforms supply a web ticket status interface you can include in an Orion view as a Custom HTML widget. This web interface might require authentication, but should not interfere with the widget functionality when you enter the credentials.

Some TTS platforms may allow a pass-through authentication within the custom HTML. The example below is a mock-up of a possible TTS Custom HTML resource.

Image_013.png

Last modified

Tags

Classifications

Public