What is a Service Desk?
ITIL’s definition of a service desk is: “The single point of contact between the service provider and the users. A typical service desk manages incidents and service requests, and also handles communication with the users.” Service desk is also sometimes referred to as Help Desk.
Service desks such as JIRA, Autotask and ServiceNow, often also support multiple IT Service Management (ITSM) activities. For example, a service desk usually encompasses ITSM activities that include service request management, incident management, knowledge management, self-service, and reporting. There are also usually strong links to problem and change management processes.
A Service Desk or Help Desk Ticketing System enables organizations (though administrators and help desk staff) to keep track of tickets raised by users or by the system, attend to them, reassign them to appropriate department or organizations, and generate reports and more.
Integration between Monitoring Tools and Service Desks
When monitoring tools detect issues in the infrastructure and/or applications they monitor, the alerts generated in the monitoring tools can be used to create tickets in a Service Desk/Help Desk system. A manual process of ticket creation and updating is time consuming, laborious and error-prone. For most enterprise organizations, tickets mean money and out-of-date information in the ticketing system causes delays, unnecessary investigations of long resolved issues and costs. A true enterprise grade integration should enable automated management and updates between the Service Desk and monitoring systems as required leveraging the rich APIs most Service Desks offer.
The advantage of an automated integration between monitoring systems and service desk systems is that, if done correctly, little or no manual intervention is necessary. Alerts from the monitoring tool will create tickets automatically in the Service Desk system and when a problem is resolved, the monitoring tool detects this and automatically closes the ticket in the Service Desk system.
When integrating a monitoring tool with a Service Desk tool, it is essential to define how an alarm in the monitoring tool is going to be mapped to a ticket in the Service Desk tool.
Typically, monitoring tools have IDs for alarms, while Service Desk tools have a different set of IDs for tickets. Integration of the monitoring tool with the Service Desk tool involves mapping the alarm ID to a ticket ID. This mapping is necessary so that:
- When a new alarm is generated, a new ticket is created in the Service Desk tool.
- When an existing alarm’s status is modified, this change in reflected in the corresponding ticket in the Service Desk tool as well.
- When an alarm is closed/cleared in the monitoring tool, the corresponding ticket in the Service Desk tool is cleared as well.
When integrating a monitoring tool with a Service Desk tool, it is also necessary that the priorities of the alarm are mapped to pre-existing priorities assigned to a ticket in the Service Desk tool as well.
Many monitoring products claim to support integrations with Service Desk tools. Be sure to investigate claims of such integrations carefully, as what many vendors offer is simply a shallow interface to send an email to the ticketing system, with the expectation you then configure the ticketing software to process the email and ongoing manually update and synchronize the ticket to the state of the system that was/is at fault.
How to Integrate IT Monitoring Tools and Service Desk Tools
While we understand that an integration is necessary, the question is where should the core capability for the integration be implemented?
- In the Service Desk tool: If the monitoring system sends alerts to the Service Desk tool over email, there is no way for the Service Desk tool to communicate back to the monitoring tool. In a similar manner, if the monitoring system sends an SNMP trap whenever it detects an alert, the communication is one-way – from the monitoring tool to the Service Desk tool. In such a case, the integration work – i.e., mapping of an alert ID to a ticket ID – must be done in the Service Desk tool. The mapping has to be maintained in the Service Desk tool and whenever it sends an alert, the monitoring tool must make sure that it sends an alert ID to the Service Desk tool. This approach has several drawbacks. If each monitoring tool sends messages in different formats, the Service Desk tool has to be modified to support all the different formats of messages. Furthermore, each time a new monitoring tool is added to the infrastructure, the Service Desk tool has to be modified as well.
- In the monitoring tool: The alternative approach is to maintain the alarm ID to ticket ID mapping in the monitoring tool. This is a more scalable approach as the Service Desk tool does not have to change every time a new monitoring tool is added. To support this approach, most Service Desk tools today support REST or web services APIs. To use the APIs, the monitoring tool uses a HTTPS connection to access a URL, communicates new alarm information to the Service Desk tool, creates a ticket and obtains a ticket ID from it. Whenever, the alarm is updated, the monitoring tool contacts the Service Desk tool and using its APIs, updates the priority of the corresponding ticket. In the same manner, when an alarm is cleared, the ticket in the Service Desk tool is automatically closed.
eG Enterprise Provides a Range of Options for Service Desk Integration
There are several out of the box modes that eG Enterprise supports for Service Desk Integration:
- Email Integration: If you really do only want to send emails to the Service Desk system, then the eG manager can be configured so that whenever an alarm undergoes a change – either generation, modification, or closure – the manager communicates this information to a Service Desk system as an email message. Formatted email messages are sent to a mailbox from where the Service Desk system has to retrieve the messages and process them appropriately.
- SNMP integration: The eG Enterprise manager can be configured to send SNMP traps to a Service Desk system. Traps are sent for each and every state change detected by the monitoring tool. Each trap will have an alarm ID associated with it and the Service Desk tool is responsible for processing the traps and creating/updating/closing trouble tickets accordingly.
- API-based Integration: This is the preferred integration option as all the necessary processing can be done in the monitoring tool itself, without requiring additional integration work to be done in the Service Desk tool. eG Enterprise includes out of the box web services/REST API support for several Service Desk systems, without the need for any complex instrumentation.
Figure 5 shows the different ITSM integration options in eG Enterprise. Technologies supported include:
All these options are available regardless of the applications, infrastructure and stacks you are monitoring using eG Innovations and as such apply to our support for:
- Workspaces: Citrix, VMware, Microsoft AVD (was WVD), AWS
- Kubernetes and Docker
- Cloud: AWS, Azure, Google
- Networking and Storage Infrastructure
- Web Services and applications
- Lots more!
If you are looking to evaluate a monitoring solution, do look at whether a vendor is offering a tight integration with the Service Desk tool. Without the right integrations being available, you may end up spending for several days/weeks of professional services to get the tight integration you need between your monitoring tool and your service desk tool.
If you feel there is something missing with our Service Desk integration capabilities, or your needs go further – please do comment below or contact me or the product team directly!