Configuring posting format in Slack extension

slack
questions

(Victor Pavlushkov) #1

Hello,

For our logs-based monitoring, we are using Elasticsearch watchers that are sending the alerts to PagerDuty in a format like that

{
  "client": "Kibana",
  "client_url": "https://kibana.myserver.com/goto/bla-bla-bla",
  "contexts": [
    {
      "type": "link",
      "href": "https://kibana.myserver.com/goto/bla-bla-bla",
      "text": "View the incident in Kibana"
    }
  ],
  "description": "During last hour, Production server has logged 5 times fatal error message Declined card",
  "event_type": "trigger",
  "incident_key": "fatal-errors",
  "service_key": "my-service-key-here"
}

and thanks to Slack extension it gets synced and handled like that:

Notice that the “Triggered” post has only the incident ID and the description, but the client_url and contexts are missing. Is there any way to configure the extension specifying how the Slack post should be formatted/which fields should be there? Somehow, I could not find it… :thinking:

Thanks!


(Jay Chiarella) #2

Hi Victor,

Unfortunately it’s not currently possible to pass client_url and contexts in the Slack message. However, I’d be happy to add your vote to the feature request to extend the capabilities of our Slack extension.

When we receive product feedback from a customer, we add the request for our Product team through a separate internal system.

Cheers,

Jay


(John Baldo) #3

Hi There, @VictorPavlushkov.

Thanks for suggesting this. As Jay mentioned, we don’t support it today but I help look after our Slack extension and I’ve noted this feedback. We had a similar request here: Configuring posting format in Slack extension

I realize it’s not ideal to write something yourself, but if this is an urgent need for you, it would be possible to use our webhooks to get that information on trigger and post to Slack. Here’s our webhooks documentation. And Slack has their own docs.

Thanks again for the feedback.


(Victor Pavlushkov) #4

Hello John,

Thank you for the hint! I was just thinking that the extension application anyway should have some template to post into Slack. So why instead of using a global template have it configurable per service and make it editable? :smile:

For example, this is how our configuration looks like when configuring Slack alert from Elasticsearch watcher:

"notify-slack": {
      "throttle_period_in_millis": 1800000,
      "slack": {
        "account": "monitoring",
        "message": {
          "from": "watcher",
          "to": ["#dev-1-backend"],
          "text": "Supply Monitoring",
          "attachments": [
            {
              "color": "warning",
              "title": "No capacity",
              "text": "During last 30 mins, the server has reported *{{ctx.payload.hits.total}} times* that there is no capacity :facepalm1: \nCheck out in Kibana https://kibana.myserver.com/goto/bla-bla-bla",
              "mrkdwn_in": ["text"]
            }
          ]
        }
    }
}

Regards

Victor


(Simon Fiddaman) #5

This and image attachments are the things that cause some of our teams to configure their Slack Integrations to come direct from their source instead of via PagerDuty.

Having worked with the Slack Webhooks and message formatting there a bit, I’d also support customisable templates (either like the Slack “test message formatting” page, where you can see what you’re getting, or like the existing Custom Event Transform integration, but as an Extension).

The main reason the per-Service (or maybe per-Integration?) templates would be good is support for adding eg documentation links which we send for all Nagios alerts in the notes url, or Sensu alerts buried in the blob. We use pdagent but it doesn’t have a way I’ve found to set client_url or other attachment types.

Basically in addition to getting the info we want out of PagerDuty and into Slack, how that’s stored changes from Integration to Integration.


#6

I also would like to be able to add some fields to Slack message, in my case they are “details” and “notes” from events API.


(system) #7