Whilst looking into the plethora of Apps and Integrations for Slack I noticed there was no integration for Microsoft Azure Application Insights, really I would like to see when an alert is triggered in a channel so looked into what I can do to get that. As Slack is such a popular tool used by Devs (and DevOps) I’d say there will be something official by Microsoft in the future.
I did come across a repo with schemas for Logic Apps, but ultimately I would prefer to use a dynamic Azure Function as it only uses resources when it’s working, and therefore costs a lot less; really it will cost me nothing as there will be no need for an alert to trigger, right?
Keep in mind that at the time of writing Azure Application Insights and Azure Functions are in preview, and the instructions below may need a tweak as time goes on. At a guess these features will be GA (general availability) come this year’s Ignite conference in Atlanta, GA (Georgia).
Although this is using Application Insights to Slack as the points on each end, this is more of a tutorial to use Azure Functions to take a payload from one webhook and send out a payload to a different webhook.
Step 1: Add webhook integration to Slack channel
Go to whatever Slack channel you want to. Hit the settings icon and select Add an app or integration.
In the top right of the screen, click Build and click Make a custom Integration and then Incoming WebHooks
Make sure the channel you are posting to is correct and click Add Incoming Webhooks integration
Change whatever settings you want in here, but the most important part to know is the Webhook URL, we’ll need to know this later on.
Step 2: Create function
For this step I’ll assume you have basic knowledge of Azure, and how to navigate around the Azure Portal.
Create a new Function App resource.
The real awesomeness of the Azure Functions is in the Dynamic option in the App Service plan; where the function is sitting on shared resources and spun up/down as needed, not running all the time and spending your hard-earned. Choosing the Classic plan allows you to have the functions running on your own WebApp, just like on Logic Apps (and why I chose to use functions in the first place).
Once loaded, you will be hit with a large screen asking your scenario and language. Ignore that and select New Function on the left of the masses of blue.
Here you will be hit with template options, I chose Generic Webhook – Node but if you want to go off with a C# function go right ahead. The rest of this post talks how to work with the Node option.
Name your function and click create.
You should now see something like this, which is where we will do (most of) our magic.
Lets have a look at what we have to work with here. Click on the View files button below the code editor and you should see two files available; function.json and index.js
You don’t need to worry too much about function.json; it defines the specifics of the functions, all of which can be done with the web interface rather than editing the JSON itself.
index.js is important though, this is the entry point for what happens to your function; you can work with more files but this is where the magic begins. The sample code is a hello world of sorts, taking in some data and sending it back. We will use most of this and replace just only a little bit of what is there.
But first, we need to install a node package – request.
Step 3: Add node packages
Click on the plus in the file list and add package.json, this is needed for npm to install the right stuff. You can see what JSON I have added to this, and it only specifies that I need request 2.7.4, which is the latest at the time of writing.
I don’t know if you know this next part, but all Azure WebApps (which functions run on) have a secondary site running Kudu.
In order to see this, grab the first chunk of the Function Url from above the code editor and put in .scm after the name of your Function App; then load it up in another browser window.
You may need to authenticate from here, and that is why I feel fine showing you the URL above.
I am not going to run you through Kudu, but it is pretty powerful, what we are going to use is the command line tool to install the relevant node packages for us to complete our function. Up top, click Debug Console > CMD; you should see a familiar command prompt.
Navigate to D:\home\sites\wwwroot\ and run npm install
You will probably get a few error messages, but I don’t care. What I wanted to have installed has been installed.
You can see this now under the list of files back on your function.
Step 4: Add some code
About time we did that, right? Well there is not much to do on this, functions make things a little too easy.
You can grab the bits from my github repo, or follow the instructions below.
Go to index.js and change the following bit of the script…
Obviously, you will need to replace with the webhook URL that was supplied by Slack back at step 1
What we just did
Upon receiving a payload, the function now sends out a new message to Slack. It’s a pretty simple message, just saying “Something happened!!” with a hyperlink to a URL from the payload. We will look into filling it out a bit more later on.
Check out your good work
Right at the bottom of your function page there is a Run section, here is where you can test out your code.
Copy and paste the following JSON into your the request body, and click Save and run.
This should be what you get…
But the real good bit is in your Slack channel…
Pretty rad huh? The only bit left to do now is receive the alert from the Azure alert.
Step 5: Add function hook to Azure alert
In my application insights I have a web test that will ping a site every fifteen minutes from nine locations around the world, if three don’t respond an alert will trigger. This is where we will add in the webhook sending a payload to our cool new function.
Copy the Function URL…
…and paste it here in the settings of your alert, remembering to save your changes
That’s it! You’re done. Now all you need to do is shut down all your servers so the test fails, and you can get an alert; rather than doing that I just changed the URL that was being pinged, but shutting down your production environment does seem to be the more thorough option, don’t you agree?
Where to from here
The info being sent to Slack is pretty lame at the moment, all it does is provide the vaguest message I could think of and a clickable link to the failing alert. If you want to fill it out you should have a look at the following links to see what you can work with.
If you are interested more in the Kudu part, have aread of this blog post on MSDN.
In the future I would like to add the functionality to add a Backlog Item/Bug into VSTS, but that will be another post in the future.