While reading the Teams News recap from December 2020, I found one thing that caught my attention particularly: Custom Praise Badges in Teams. Let’s try this. But first, those badges are the default ones:
They are good starting point. But to take it a step further, to really engage people and praise, you need some specific badges that mean something for your company.
To add a new badge all you have to do is to go to Teams Admin (obviously it requires you having the Teams Administrator Role):
Click on Teams Apps –> Manage Apps
Search for “Praise” and open it
Click on Settings and scroll down to Custom Badges
Click on “Create a custom badge”
Give it a name, upload a picture, define the text color and the background color.
That’s it! When I added my little construction worker badge, it took seconds (but be patient if takes more time).
Custom badges might be this little “extra” that make difference for better adoption and better collaboration in your team and your organization.
Of course, for those who has not tried the Praise feature in Teams yet, I highly recommend it. Next time you want to say “Thanks” to someone or show your appreciation, just hit this tiny badge button within the “New Conversation” in Teams.
Elio wrote his blog post in April this year – in the times of the lockdown in Belgium. In Sweden, we hadn’t a real lockdown, but it seems that it might come times when my children would need to be at home more while I work. In that case a superclear system that shows when I have important meetings is just awesome. Maybe, with that I am prepared for such times.
But to be really honest, the main driving factor is the fact that it is very satisfying to tinker around with this DIY stuff 😜😎
There is a python wrapper for MSGraph which is awesome, but it needs more contributors:
Azure Alerts are awesome for monitoring of solutions in Azure. If you are about to set up your first Alert Rules in Azure, then it’s a guide for you. Configuring alert rules can be quite intimidating at first, with all the options, metrics, evaluation times, etc.
Here is a very very simple setup that can serve as a teaser and help you get started with the Azure Alerts.
I’ll use Teams as an easy way to set up notifications.
The core solution (alert handler) will be an Azure Function, also because it’s fast and easy to set up.
A reliable failing resource
“Reliable failing”, huh? Yes, this oxymoron is the best description of what we are looking for: a resource in Azure that can fail reliably (“fail faster”), so that we can trigger our alerts while developing.
To do that an easy way, we’ll just create a logic app and let it fail all the time.
Run it, and you’ll see how it fails as intended.
When you’re done setting up the alerts, you can remove the failing logic app.
On the other end we need a reliable communication channel.
Let’s pick a channel in a team and create an incoming webhook. I call my webhook alert-hook. (Just to make it easier to follow this guide, it will appear here and there)
Why incoming webhook? Because it is easy to create and send messages to, and also with the right notifications on that channel and the Teams mobile you’ll get the smoothest way of setting up push notifications! Isn’t it great to get your custom alerts directly on you mobile in real time?
When you see the “hello world” from alert-hook in your Teams channel, then you’re ready to proceed with the next step.
Now it’s time to set up the core of that solution – a handler that will receive alerts and pass it to the Teams channel.
Why do we need an Alert Handler? Well, because you can’t send the alerts directly to a Teams channel (or whatever communication channel you choose), they have different schemas. But also, an Alert Handler is an opportunity to make an alert more readable (e.g. by formatting it as an adaptive card), and even filtering out some alerts or parts of them (e.g. in some scenarios only Fired Events (not Resolved) are relevant for notifications).
For the sake of simplicity, let’s just create PowerShell Azure Function in the Azure Portal. Just choose everything latest (in my case it was PowerShell Core 7.0, Consumption Plan, West Europe). If you uncertain, check this post:
We need those 4 steps. I created a simplified diagram of the properties that you need have in mind:
Alert Rule Scope
When you click on “New alert rule”, the Scope will be already defined, it will point to the “Failing Resource”.
Alert Rule Condition
There are so many signals and possibilities. In this guide, just choose “Runs Failed” as a Signal.
In the Alert Logic, select “Greater than or equal”, 1; 5 minutes Granularity Period and 1 minute Frequency of Evaluation. No comment on them right now. Just do it.
When we’re done, re-visit this page and try other things, right now we just want to have an alert directly when our failing resource fails.
Action Group is what gets triggered. It is billed and that’s why it is connected to a Resource Group (it might be another resource group, it does not need to be in the same place as our “Failing Resource”). Just create a new one:
Here is a simplified diagram of an action group:
Action Group Action – Webhook
There are a couple of options for Notifications and Actions to try out. Let’s focus on the Webhook in this guide. In the picture it is called GenericTolleAlertHook.
Copy the Uri from the your function (“Get function url”) and paste it into the Webhook URI.
Important: enable the common alert schema. That will save much of the pain.
Common Alert Schema
The payload in the alert may vary. To make it more predictable for parsing in the alert handler, we just need to enable the common schema, which will be crucial when we will extact and send some data to the Teams channel.
Action Group Bonus Tip: It might be not obvious when you set up it in the Azure Portal, but an alert rule can have 1 or multiple action groups (!). And the other way around: An action group can be used in multiple Alert Rules.
That makes it very flexible, we could create one generic Action Group that notifies Teams and reuse it across alert rules.
Alert Rule Details
The last step is to give the rule a name and description. Keep the Severity as it is right now.
Alert Handler Improvements
We need one more thing to call this guide complete: rather than saying Hello World, we need to have “Alert Fired” and what alert (alert rule name), to make it useful for real.
Let’s re-visit the alert-hook function and make some improvements. Remember the common alert schema? Make sure you enable it in the Alert Rule -> Action Group -> Action. When you do that you will get payloads like these I get:
When you look at them you can see some attributes that we can make use of:
We’ll use the alertRule and monitorCondition properties, that we’ll send in the body of the incoming webhook to Teams:
Let’s test and run. Copy and paste a sample alert payload (with the common alert schema). The links are above.
It should result in a new post in your Teams channel:
A simple alert rule is configured. Enjoy! Discover more and if you would like new challenges here are some tasks that you can try:
Try to update the payload in the Teams incoming webhook to make an adaptive card.
Fired vs. Resolved
It might be good to have different paths for Fired and Resolved. I find it confusing when Resolved Notifications appear alongside with Fired Events. It’s better to suppress the Resolved notifications, or at least format them differently, or maybe even post them as answers to an existing posts (the original Fired posts)?
Azure Alerts are great. Start with a simple set up, see it working and improve continously. An ActionGroup can be reused, you can have a generic Action Group. That makes it easy to set up new alert rules and and you only need to update the action in one place only. Of course, the alert rules can have their specific actions as well, you can connect more than one action group to an alert rule. Use Common Alert Schema to avoid parsing errors and to achieve a generic action group.
Teams is a good notifications destination, especially for your first Alert Rule, it’s easy to set up, does not mean additional costs and (best of all), you and your colleagues can enable notifications the destination channel (channel with your incoming webhook), that way you will be immediately notified when something fails in your Azure Applications, – both on Desktop and in your mobile! Good DevOps, isn’t it?