Benefits of central alerting

Central alerting in the Management Portal is independent of the existing alerts provided directly by your x360Recover appliances and vaults - and it has different (though similar) sets of possible conditions for which it will raise alerts.  

Many (though not all) of the native device alerts have corresponding duplicate alerts within the central alerting framework.  When enabling central alerting, it may be desirable to disable some alert classes on your managed devices in order to eliminate duplicate tickets for the same event.

Central alerting provides a single point of configuration for monitoring of all your managed devices.  This provides coverage for the most vital metrics, including:

• Are all my devices online and reporting?
• Are there any storage issues with my devices?
• Have all my protected systems had a recent backup?
• Have all my protected systems replicated recently to the cloud?
• Are all my devices running the latest x360Recover version?

Key Differences

Central alerting excels at reporting present state data for your managed devices and protected systems using SLA-based logic. 

• One key advantage of central alerting is the ability to report when devices are missing or down.  Since a failed appliance or vault obviously cannot report itself or raise alerts, this is a critical enhancement for managing and monitoring your deployed devices.
• Individual devices have better native alerting for detailed health states.  Not all hardware related events are reported to the Management Portal, so some alert classes are only available via device alerts.

In general, the following alert types can be disabled on your individual appliances and vaults (for both email and ConnectWise alerting)

• Agent Status
• Boot VM Checks
• Disk Usage
• Failed Backup
• Missed Backup
• Successful Backup
• Pool Status
• Replication

The remaining alert types are not fully covered by central alerting and should remain enabled.

Note that Central Alerting uses email ticketing only and does not integrate directly with ConnectWise.  It was designed to provide a general-purpose alerting system that would be widely applicable to all types of PSA while retaining round trip ticket management in the majority of cases. 

Central Alerting is separate and distinct from the ConnectWise policy settings functionality, which is still useful for managing direct ConnectWise integration settings at the device level.

How it Works

To enable central alerting, log in to your Management Portal and navigate to the Settings -> Report Settings.  Click to enable Ticketing and fill in the required mail server settings.  

Note: Enabling the Email Delivery settings is a prerequisite to enabling Ticketing.

Enter the POP3 server that corresponds to the existing SMTP server for the configured mail account, the POP3 port to use, and the email destination to which alert tickets should be sent.  Typically this would be the email ticket gateway address used by your PSA solution.

When ticketing is enabled and new alerts are delivered, the backend engine collects responses to emails returned by your PSA via POP3 mail pickup.  The subject line of these response messages is retained and echoed back in future updates to open alerts.  In this way, round-trip ticketing can be accomplished with most PSA systems. 

A single ticket is generated for each unique alert, updated periodically if it has not been resolved (and potentially even closed) automatically, via PSA automation rules, if supported.  This eliminates the noise of generating new PSA tickets with every change or update to a single alert that many simple email alerting systems encounter and provides for a powerful PSA-agnostic ticketing integration.

Every metric within Reporting that is scored as good or bad is an alert-able item.  Whenever any Reporting metric transitions from a good state (green) to a bad state (yellow or red) an alert will be opened, and an email will be sent to the target ticketing portal destination.

Alerts that remain in an open state will receive additional update notifications once every 24 hours. 

Once a given metric has been resolved and transitions back into a closed state (green) then a final email notification will be delivered updating the PSA ticket with the fact that the issue has been resolved.

If your PSA solution supports automation rules and triggers based upon the message content of email ticketing, you can configure such rules to automatically close tickets based upon these final update notifications.

Alert Message Format

Emails for alerts delivered by Central Alerting will have the following formats:

New Alerts 

When new alerts are opened, a new alert email will be delivered.

Subject: x360Recover Alert: <Customer Name> <Device Name> <Alert Name>

Message Body:

x360Recover Ticket Generated by Global Management Reporting

Customer: <Customer Name>
Device: <Device Name>
Identifier: <Unique Message Identifier>
Raised At: <Alert creation time>

Reported Issue: <Alert details>

Alert Updates 

Once every 24 hours, alerts that have not yet been resolved will receive an update

Subject:  <(See Description below)>

The subject line delivered for update messages will be a copy of whatever was returned by the PSA system when originally opening the ticket.  Typically, this is an echo of the original email sent to the PSA with a ticket number embedded within it somewhere.  If no reply was returned from the PSA, the original alert message email will be echoed.  Most PSA systems will recognize the returned subject line, extract the ticket number, and apply the message body as a new note or update to the original PSA ticket.

Message Body:

This issue is still unresolved after 24 hours

Please investigate

Closed Alerts 

Once an alert has been resolved, a final message will be delivered advising the PSA to close the ticket.

Subject: (<See Description above>)

Message Body:

x360Recover Ticket Closed by Global Management Reporting

Customer: <Customer Name>
Device: <Device Name>
Identifier: <Unique Message Identifier>
Issue Cleared At: <Alert closed time>

This issue has been resolved.  This ticket can be closed.

PSA Automation

If your PSA supports automation rules based upon the content of email message bodies, you may configure such rules to perform useful actions.  Some examples would be automatically closing resolved alerts, assigning tickets to specific customers, moving tickets to a specific service queue, etc.