cond.Alarm) in Intersight, every alarm creation, change, and clear is sent to Flashduty On-call. Each Intersight alarm maps to one Flashduty alert: it is triggered when the alarm is created, updated when its severity changes, and recovered when Intersight clears it (Cleared).
In Flashduty On-call
You can get the push URL in either of the following ways.
Use a dedicated integration
- In the Flashduty console, select Channels and open a channel
- Select Settings → Integrations → Dedicated integrations, then click Add an integration
- Select Cisco Intersight and click Save
- Open the generated integration card and copy the push URL
Use a shared integration
- In the Flashduty console, select Integration Center → Alert Events
- Select Cisco Intersight and enter an integration name
- Configure the default route and select a channel; you can add more rules under Routes after the integration is created
- Click Save and copy the generated push URL
In Cisco Intersight
1
Create the webhook
- Sign in to Cisco Intersight and go to Settings → Webhooks
- Create a webhook, enter a name, and paste the full Flashduty push URL, including
integration_key, as the webhook URL - Define the Secret field as any string you like. Intersight uses it to sign requests; Flashduty does not verify signatures, so any value works
2
Subscribe to alarms
Add a subscription to the webhook with the alarm object type
cond.Alarm, and select the Created and Modified events. The Modified event is required: a severity change and a clear are both updates to the same alarm, so without it the Flashduty alert never recovers.Subscribe only to cond.Alarm. Flashduty rejects pushes for other object types, such as workflow.WorkflowInfo, with an object type error.3
Save and verify
- Intersight can send a request that carries no alarm (
EventObjectTypeempty,Eventnull,OperationNone), the shape shown in Cisco’s webhook validation guide; Cisco does not document exactly when it is sent. Flashduty turns that request into an Info test alert titledCisco Intersight test notification. It does not recover on its own, so close it by hand - Wait for a device to raise an alarm (or cause a fault in a test environment) and confirm the alert appears in Flashduty. When the alarm clears, confirm the alert recovers
Event types
Alert Key
Flashduty uses the alarm’s
Moid, the fixed identifier Intersight assigns to each alarm, as the Alert Key. Creation, updates, and the clear of one alarm share the same Alert Key. Changes to the name, description, severity, or time do not change it, and a request without a Moid is rejected.
Status and severity
Labels
About signatures
Intersight signs requests with HMAC using the Secret you set (
Authorization and Digest headers). Flashduty does not verify signatures, so the integration_key in the push URL is the only credential. Keep it private.
Troubleshooting
- Flashduty receives nothing: confirm the webhook URL is complete and includes
integration_key, and that Intersight can reach the public internet - Parameter error returned: an object type error means the subscription covers an object other than
cond.Alarm; a missingMoidmeans the push is not an alarm object - An alert does not recover: confirm the subscription includes the Modified event, because a clear is pushed as an update
- The test alert stays open: the Info alert from the test request must be closed by hand