On 5 Dec 2016, at 16:18, Adam Armstrong <adama@memetic.org> wrote:_______________________________________________Hi,I've sent a request to that URL with the entire list of variables.For most services we have to send a single "entity" name which includes the hostname, entity type and entity name, since most services aren't set up to care about the information separately. I've not sent anything like that in this case, but it can be added.It also sent the graph image array, which I can strip out, since most services won't make use if it!Thanks,adam.On 05/12/2016 13:04:24, Halit Okumuş <halit@opsgenie.com> wrote:
Hi Adam,_______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observiumThe current integration was made, months ago, according to your old webhook content. And there are existing, in-use configurations in OpsGenie at the moment. We can't just throw them away and change that, can we? That's why we suggested the webhook content before. I don't care how crappy your payload was, we're just trying to make use of the two products together.Alright, cooling down, we can do a rewrite. We'll make a V2 integration which will make use of the fields you mentioned and deprecate our old one. Can you send an example of that request to http://4kmm916oxm9m.runscope.net ?Cheers,HalitOn Mon, Dec 5, 2016 at 3:37 PM, Çağla Arıkan <cagla@opsgenie.com> wrote:Begin forwarded message:From: "Adam Armstrong" <adama@memetic.org>Subject: Re: [Observium] OpsGenie Observium IntegrationDate: 5 December 2016 at 15:33:44 GMT+3To: "" <observium@observium.org>Reply-To: Observium Network Observation System <observium@observium.org>______________________________Oh god. I hate when you start looking through contributed code and realise it was written by someone who hadn't even bothered to make sure it does what it's supposed to do.At the moment the integration sends this payload :$payload = array("apiKey" => $endpoint['api_key'],"message" => $message_tags['TITLE'],"description" => $message_tags['METRICS'] . PHP_EOL . PHP_EOL . 'Conditions: '. PHP_EOL . $message_tags['CONDITIONS'],"alias" => $message_tags['ALERT_ID'],"entity" => $message_tags['DEVICE_HOSTNAME'], "source" => php_uname('n'),"details" => array("Alert URL" => $message_tags['ALERT_URL'],"Duration" => $message_tags['DURATION'],"Hardware" => $message_tags['DEVICE_HARDWARE'], "OS" => $message_tags['DEVICE_OS'],"Location" => $message_tags['DEVICE_LOCATION'], ),);We're able to supply these fields from our alerting code :'ALERT_STATE''ALERT_URL''ALERT_ID''ALERT_MESSAGE''CONDITIONS''METRICS''DURATION''ENTITY_LINK''ENTITY_NAME''ENTITY_TYPE''ENTITY_DESCRIPTION''ENTITY_GRAPHS_ARRAY' // Json encoded images array'DEVICE_HOSTNAME''DEVICE_LINK''DEVICE_HARDWARE''DEVICE_OS''DEVICE_LOCATION''DEVICE_UPTIME'The existing integration doesn't seem to provide the actual entity being alerted information in a useful manner, so could probably do with being rewritten itself so we can better match the capabilities of the two platforms.adam.On 05/12/2016 12:24:21, Adam Armstrong <adama@memetic.org> wrote:
Please don't use the generic webhook crap. There's a reason it's marked as "(Old)" now.I get 400 bad request when using either of those URLs. Our OpsGenie integration (which was contributed a couple of weeks ago) currently sends :{"recipients":"","api_key":"2f79c4d5-7c26-4429-8e5b- 6e2b936800cc"} {"apiKey":"2f79c4d5-7c26-4429-8e5b-6e2b936800cc","message":" RECOVER: [omega.memetic.org] [processor] [Average] Processor usage is above 80%","description":"processor_ usage = 40\n\nConditions: \n","alias":"46864","entity":" omega.memetic.org ","source":"omega.memetic.org ","details":{"Alert URL":"http:\/\/dev.observium. org:80 \/device\/device=12\/tab=alert\/alert_entry=46864\/ ","Duration":"1m 26s (2016-12-05 13:20:00)","Hardware":"Generic x86 [64bit]","OS":"Linux 3.13.0-96-generic Ubuntu 14.04","Location":"Hetzner, Nuremberg, Germany"}} Trying to parse an arbitrary text field is a really bad idea when we can provide that data in separate fields.adam.On 05/12/2016 12:18:29, Çağla Arıkan <cagla@opsgenie.com> wrote:
When you change the URL, the integration will work properly. To make the integration work properly, we should get the same payload that you send for generic webhook integration this can be found below:{ "originator": "observium sender", "body": "ALERT: [localhost] [device] device is down\ndevice_status = 0" }We will fix the documents as you described.Thanks,Çağla ArıkanOn 5 Dec 2016, at 15:12, Adam Armstrong <adama@memetic.org> wrote:______________________________The description for the "add integration" part of OpsGenie also references to deprecated generic webhook from Observium. Please don't use that.Please rewrite your integration to use the specific OpsGenie integration we provide.adam.On 05/12/2016 12:03:49, Çağla Arıkan <cagla@opsgenie.com> wrote:
Hi there,I am a software engineer at OpsGenie. We have developed an integration specific to Observium. Thus, we would be very pleased if you can fix your integration so that it uses /v1/json/observium endpoint rather than /v1/json/alert endpoint. Observium Integration works similar to generic Webhook integration but we customised it for Observium. You can check our Observium Integration document for more information which can be found at https://www.opsgenie.com/docs/integrations/observium- .integration Best Regards,Çağla Arıkan_________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/ observium _________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/ observium
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium