Update:
I was using a test API key in "Suppress Notifications" mode for my tests detailed below. But my production service which already uses roughly the same code with a non-"Suppress Notifications" API key could attach tags to alerts as expected. This is probably a bug on OpsGenie side.
Original post:
I'm using Python 3.7 http.client library to post alerts to this API https://docs.opsgenie.com/docs/alert-api#create-alert
def request(method, url, params, headers):
parsed = urllib.parse.urlparse(url)
conn = http.client.HTTPSConnection(parsed.netloc)
full_path = parsed.path
headers = headers or {}
body = json.dumps(params)
headers['Content-Type'] = 'application/json'
logging.info("full_path:%r body:%r headers:%r", full_path, body, headers)
conn.request(method, full_path, body, headers)
params = dict(
message='I am testing OpsGenie API',
description='describe it!',
tags=['Tag0', 'Tag1'],
details=dict(detail0='Detail0', detail1='Detail1'),
source=socket.gethostname()
)
I can see the resulting alert has message, description, and source fields as expected (as well as entity, alias, and source, when I add them)
but I can't seem to add tags and details. As if the API discards them.
The logger displays something like this
'{"message": "I am testing OpsGenie API", "description": "describe it!", "tags": ["Tag0", "Tag1"], "details": {"detail0": "Detail0", "detail1": "Detail1"}, "source": "mymachine.local"}'
which looks like a valid JSON payload. Could any of you shed some light on this problem?
Hi @Kai Noda !
I just tested this with my own account and found suppressing the integration itself was not enough to reproduce this. I used cURL to send the request, but payloads with details and tags still made it into the alert:
curl -X POST 'https://api.opsgenie.com/v2/alerts' -d '{"message":"test","details":{"host_name":"localhost","host_alias":"hostname"}, "tags":["Tag1"]}' -H 'Authorization: GenieKey XXXXXX' -H 'Content-type: application/json'
Have you modified the API integration at all from default? This might be a better issue to resolve by reaching out to our support team directly.
Hmm I created a new key and switched keys from the one I created back in Apr 2019 to it, then the problem magically disappeared.
The same test script, two different keys with the same (default) permissions + "Suppress" mode, different results reproducibly. This must be a bug on your side.
Anyways I can move forward now.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Kai Noda Glad to hear the requests are working now.
If you'd like to look into the issues you were seeing with the other API integration, please feel free to create a ticket with our support team or stop by the in-product chat and we can take a closer look.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.