Closed pauldix closed 3 weeks ago
Hi @pauldix,
Thanks for your thoughts. I understand the use-case for trigger
and resolve
, but would we ever auto-acknowledge an incident?
With regards to what is returned, perhaps for an initial implementation it should just return the HTTP status code?
acknowledge
is for completeness and it's something we may need in the UI at some point. For the responses, we need them on trigger
if the user doesn't specify a dedup_key
since that will be auto-created and included in the response. For now I'd have it return an object like:
{
"status_code": 202,
"result": {
"status": "success",
"message": "Event processed",
"dedup_key": "samplekeyhere"
}
}
Where result
is the parsed response body.
This issue has had no recent activity and will be closed soon.
Flux users should be able to send events to PagerDuty. PagerDuty functions should go in the
pagerduty
namespace in the standard library. Details on PD's API can be found here: https://v2.developer.pagerduty.com/docs/send-an-event-events-api-v2We can start with three functions:
trigger
which will have arguments for each of the items in the API.token
,routing_key
,summary
,source
, andseverity
are all required arguments where the others are optional.acknowledge
which will taketoken
,routing_key
, anddedup_key
as required arguments with no other optional arguments.resolve
which will taketoken
,routing_key
, anddedup_key
as required arguments with no other optional arguments.How should the responses be materialized? As a table? As an object of the parsed JSON response? Also, should we have a
routing_key
that is an integration for InfluxDB that is set to the default? I'm not sure if that's something that makes sense or if it should always be provided by the user.//cc @rawkode @nathanielc @timhallinflux @russorat