Skip to main content
Use a webhook destination in Zenoss Cloud (now Virtana Service Observability) to send events to Flashduty On-call. Each Zenoss event maps to one Flashduty alert: it triggers when a Zenoss trigger matches the event and recovers when the event status becomes Closed.

In Flashduty On-call

You can get the integration push URL in either of the following ways.

Use a dedicated integration

  1. In the Flashduty console, select Channel and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add integration
  3. Select Zenoss, then click Save
  4. Open the generated integration card and copy the Push URL

Use a shared integration

  1. In the Flashduty console, go to Integration Center → Alert Events
  2. Select Zenoss and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routing after creation
  4. Click Save and copy the generated Push URL

Configure Zenoss

Zenoss sends notifications through a destination, a trigger, and a rule. Creating a rule requires the Manager role.
1

Add a webhook destination in Zenoss

Where: Zenoss › ADMIN › Actions › DESTINATIONS › ADD DESTINATIONZenoss sends notifications through a destination, a trigger, and a rule. Creating a rule requires the Manager role.Click SAVE.
2

Add an event trigger in Zenoss

Where: Zenoss › ADMIN › Actions › TRIGGERS › ADD TRIGGER
3

Add a rule and turn on update notifications in Zenoss

Where: Zenoss › ADMIN › Actions › RULES › ADD RULEClick SAVE.
4

Generate an event and verify in Zenoss

Where: Zenoss › ADMIN › Actions › DESTINATIONS › TEST
  1. Make Zenoss produce an event that matches the trigger and confirm Flashduty receives an active alert
  2. Close the event (or wait for it to close) and confirm the alert recovers
The TEST button on the destination page sends a test message. The Zenoss documentation does not describe the test message body, so Flashduty cannot tell it apart from a real event and it may open an alert; close it manually after verifying. It only proves connectivity, so verify with a real event.

Alert key

Flashduty builds the Alert Key from the event ID (context.Context.Event.id in the message). Zenoss identifies an event by its name plus dimensions and documents the event ID as the key for retrieving that event, so repeat notifications, updates, and the close of one event are expected to carry the same ID and share one Alert Key. Zenoss does not state this for the close notification in so many words: before going live, close one test event and confirm its alert recovers instead of a new alert opening. Changes to severity, summary, status, or time do not change the Alert Key. The top-level id of the message is the notification ID, different on every delivery, and is not used. A message without an event ID is rejected.

Status and severity

A notification without an event in its context (context.Context.Event missing) is also acknowledged and ignored. A notification that carries no event (for example from a non-event trigger) creates no alert; Flashduty returns success.

Labels

The event summary (summary) becomes the alert description.

Troubleshooting

  • Flashduty returns a parameter error: Confirm that the URL is complete and includes integration_key, and that the destination does not use Custom Payload
  • The alert does not recover: Confirm that Send updates is on in the rule and that the trigger does not exclude Closed events
  • No event arrives in Flashduty: Confirm that the rule is enabled and the trigger matches; events with status Suppressed create no alert
  • The same event notifies repeatedly: Repeat notification in a Zenoss rule resends at its interval; these notifications merge into the same alert
For field details, see the Zenoss webhook message example.