How to design a ticket integration solution?

It is often necessary to setup alert or ticket integration between two monitoring solutions. For example, sending alerts from one system to an ITSM or SIEM.

I will refer to the data being transferred as alerts here for simplicity.

Where do you start?

First determine your requirements:

• Are you moving alerts alone or do you need the raw data (tables)?
• The easiest option is using a built-in forwarder or notification channel. For example, send an email for each new alert. Many of these services have data egress or export features.
• One-way integration usually involves sending new alerts alone (like email notifications).
• A two-way integration reflects new alerts and updates, either partially or fully synchronized between two systems. For example, changes in System-A are reflected in System-B.

Look for out of the box and community solutions. These may be all you need or a sample solution. Examples may include built-in options, templates, notification tools, forwarders, etc. Look closely at the output or notification options and the alert input options on both sides. What does the exported alert look like (what fields and formats)? What are the input requirements to create a new alert?

System integration often involves one or more scheduled scripts. Consider your orchestration options. Determine where these scripts will run. This could be a scheduled task, runbook, logic app, function, or equivalent running on a server, server-less platform, or orchestration solution.

Most monitoring tools have a programmatic interface. This could be a command-line, PowerShell, or API. Most monitoring tools also have one or more notification channel for emails and such (native outbound). Monitoring tools can also read data from events and files (native inbound). Determine how you will get (query) and update (put) to both.

We also have common incident or alert attributes that we can leverage including the owner, ID, status, severity, category, tag, comments, etc. These are usually the values that we synchronize and can be used as a tracker or watermark in the automation process.

Let me pseudo out the workflow:

Script #1 – The New Alert Forwarder script sends new alerts from System-A to System-B and updates (or marks) the alert status in System A to confirm. Confirmation may not be required if this is a one-way solution. Note that we link the alerts on both sides using alert IDs.

1. Every 5 minutes.
2. Get all new alerts from System-A (all open alerts since the last successful sync).
3. Modify or enrich the alert data in transit to meet System B alert requirements (usually we need to make some changed here). For example, change the severity format.
4. Recreate those alerts on System-B (making sure to add the alert ID from System-A someplace for tracking purposes).
5. Confirm success by capturing the new alert ID (or retry).
6. Update the alerts in System A (Note the System-B alert ID and URL if possible) and change the status (for example to active or in progress).
7. Record the last successful sync time. We use this to avoid gaps if there is an interruption.

Script #2 – The Update A-to-B Script sends key updates from System-A to System-B.

1. Every 5 minutes.
2. Get all alerts in System-A that have been updated since the last successful sync.
3. Get the key values (assignee, comment, status, etc.) and the System-B ID from these alerts.
4. Update each System-B alert with those values.
5. Note the last successful sync time.

Script #3 – The Update B-to-A Script sends key updates from System-B to System-A.

1. Every 5 minutes.
2. Get all alerts in System-B that have been updated since the last successful sync.
3. Get the key values (assignee, comment, status, etc.) and the System-A ID.
4. Update each System-A alert with those values.
5. Note the last successful sync time.

This process works rather well. It covers alert closure and reopening. You might add some error checking and guide rails to account for outages and overlaps. For example, you may not want to allow reopening of alerts or prevent parts of the sync in one direction. Establishing logging and monitoring of this process can also be useful.

One alternative is to synchronize the table(s) where the alert/incident data is stored. Forward or mirror the tables and use a native alert rule to monitor these tables. Though this tends to be a one-way connection.