Automation
Automation lets Asternodis tell the rest of your tooling that something is happening. A failover is rarely an isolated act: you probably also want to silence monitoring, post to a channel, open a ticket, or flip a load balancer.
Admin only.
Events
A hook fires on any of four points:
| Event | Fires |
|---|---|
| Before failover | immediately before a failover begins |
| After failover | once the failover completes |
| Before DR test | immediately before a non-disruptive test starts |
| After DR test | once the test finishes |
The pre_ events are the useful ones for suppression — silence the alerts
before the guest stops answering, not after your phone has already gone off.
Adding a hook
Give it a URL and pick the events it should receive. Asternodis POSTs to that
URL when the event fires, identifying itself with an Asternodis-hook
user-agent.
Use Test on any hook to deliver a sample event immediately. Do this when you add it — a webhook you’ve never fired is a webhook you don’t know works, and a failover is a bad time to discover the URL was wrong.
A note on security
Hook deliveries are not currently signed. The receiving endpoint cannot cryptographically verify that a request genuinely came from Asternodis, so:
- prefer an endpoint that is not publicly reachable, or one that carries a secret in the URL path
- don’t have the receiver take destructive action on an unauthenticated POST alone
Treat a hook as a notification, not an authenticated command.
Related
- Recovery Plans — the failover and DR-test runs that trigger these events.
- Operations — watching the run the hook is reporting on.
- Users & security — who is allowed to configure automation.