AlertMagic - Configuring AlertMagic

AlertMagic is configured at https://alert.magicsuite.net/. Everything described below is done through the web application - most of it in Alert Studio - and no manual configuration files are required. Because alerting configuration can seem complex at first, we offer a QuickStart package to get you up and running, and most customers have Panoramic Data build the initial configuration with them; you are however free to do it all yourself. Ask about our free training and certification.

The building blocks

AlertMagic configuration is a small hierarchy. From the bottom up:

• Deployment Target - a deployed instance of the AlertMagic engine (for example Panoramic Data staging, Panoramic Data production, or a customer-hosted deployment). Integrations are assigned to a target; most customers use one operated by Panoramic Data.
• Alert Management System (AMS) - where alerts come from: LogicMonitor, Cisco Meraki, or Microsoft Azure.
• Issue Management System (IMS) - where incidents go: AutoTask PSA, Cherwell, ConnectWise Manage, Jira, Microsoft Dynamics, ServiceNow, or SolarWinds Service Desk.
• Integration - a 1:1 mapping from one AMS to one IMS, with its own webhook credentials, environment-specific Variables, and metric dimension names.
• Integration Version - a complete, versioned alerting configuration for an Integration. Versions are edited as drafts in Alert Studio and have no effect until activated; exactly one version is active at a time.

Inside a configuration version

• Payload and Fields - a sample of what the AMS sends, and the fields interpreted from it, which every expression can reference.
• Deduplication - collapses repeated notifications, with optional field transformations to normalise values (such as lower-casing a host name) before comparison.
• Incident Specs - the heart of the configuration, processed in order. Each spec has:
  • a condition - does this spec apply to the notification;
  • an incident query and alert signature - how to find an existing open incident for the same underlying problem;
  • mappings - the field values written when creating or updating the incident (mappings are performed first);
  • comments - conditionally added to the incident, each with a subject and body;
  • actions - one or more expressions executed towards the end of processing the spec, each with a trigger reason, typically calling back into the AMS or IMS (for example acknowledging the alert);
  • problem specs - an optional nested layer that recognises recurring incidents and manages a Problem record, with the same query, mappings, comments, and actions shape;
  • Stop if Condition Met - optionally prevents any later specs from running.
• Maintenance Windows - scheduled periods during which incoming notifications are suppressed entirely: recurring (a CRON schedule with a duration and time zone), one-off (between two times), or an advanced custom condition. Created with a wizard from the Add button.
• Snippets and Cached Snippets - reusable expression text local to the version; cached snippets are evaluated once and reused per notification per incident spec.
• Tests - saved in-app tests that prove individual expressions behave as expected, including with a simulated current time.

How a notification is processed

When the AMS delivers a notification to an Integration's endpoint, it is queued and processed by the Integration's Deployment Target using the active version:

1. The payload is validated and its fields are parsed.
2. Maintenance windows are evaluated first: if any window is active, the notification is suppressed and processing stops - no incidents are created or updated, and the suppressed notification does not count towards deduplication.
3. Deduplication then discards repeats of recently seen notifications.
4. Each incident spec runs in order: if its condition passes, the incident query looks for an existing open incident; the incident is created or updated using the mappings; comments and actions run conditionally; and problem specs, if configured, do the same at the problem level.

Every payload's journey, outcome, and processing logs are visible on the Payloads page, correlated by Tracking ID, and a payload can be replayed after configuration is corrected.

Expressions

Almost every configuration value - conditions, queries, mappings, comment text, actions - is an NCalc expression. Expressions can reference the parsed payload fields, and text substitution using the {{name}} format pulls in Integration Variables and Snippets. A family of AlertMagic-specific functions (all prefixed am_) reads from and writes to the connected systems - see Expression Functions (am_*) for the reference. During development, Mocks in Alert Studio stand in for those remote calls so nothing touches the real systems.

Getting a configuration live

1. Edit a draft version in Alert Studio (or import one).
2. Prove the behaviour on the Testing tab with a test payload, mocks, and simulated time where needed.
3. Save, then Activate - activation is the equivalent of setting it live. To change a live configuration, use Save (new version), edit the new draft, and activate it when ready.

If you would like help at any point, contact support - configuration reviews and the QuickStart service are exactly for this.