Monitoring temperature sensors in remote locations with Twilio, Azure Automation and Log Analytics - Part 3
This is part three of my little three part series on how to monitor temperature sensors in remote locations with Twilio, Azure Automation and OMS. It describes my current OMS solution and the costs associated with the solution, in case that you want to build something similar.
For the background of this post, please read part one. Part two describes some of the technical aspects and lessons learned.
Let me show you once again the complete custom OMS solution dashboard:
OMS solutions and alarming overview
For those of you, who are not yet aware of the general data flow in OMS regarding solutions and alarming:
Everything is based upon the Log Analytics records stored in the OMS workspace. You can define queries by leveraging the powerful Azure Log Analytics query language. Based on these queries you can either create Alerts or specific vizualisation items called tiles. A tile could be a chart or a list for example. Multiple tile can form a custom OMS solution.
All of the dashboard tiles in my custom solution are based on specific queries against my custom log type DirkBriClimateSensorDataV2_CL:
Showing the health state of my devices is just a query that retrieves the HealthState property of the last record written per device:
DirkBriClimateSensorDataV2_CL | where DeviceLocation_s matches regex "Lager*" | summarize arg_max(TimeGenerated, *) by DeviceLocation_s | project Location=DeviceLocation_s,HealthState=HealthState_s | order by Location asc
And the last access time tile query is based on the TimeGenerated property of the latest record written by each device.
The line charts for temperature and humidity are based on a query like this:
DirkBriClimateSensorDataV2_CL | where DeviceLocation_s matches regex "Lager*" and IsAlertMessage_b==false | summarize avg(TemperatureValue_d) by DeviceLocation_s,bin(TimeGenerated, 1h) | project Location=DeviceLocation_s,Temperature=avg_TemperatureValue_d,TimeGenerated
One of my main objectives was to get an alert, when a threshold is exceeded, the device lost power or anything else unexpected happens. The logic behind this is covered within my "text message receive and process" runbook in Azure Automation. The runbook decides, if something is good (HealthState = "OK" ), unknown (someState = "Unknown" ) or an out-of-band alert (IsAlertMessage = TRUE).
In OMS I simply need to write the right query and configure an alert based on this query:
To get an alert, when a specific device in a location is unhealthy (HealthState <> "OK" ), I query for HealthState <> "OK" within the last 24h. OMS will execute this query every 5 minutes and will raise an alert, if the query returns 1 or more results:
DirkBriClimateSensorDataV2_CL | where DeviceLocation_s matches regex "Lager*" | summarize arg_max(TimeGenerated, *) by DeviceLocation_s | where HealthState_s <> "OK"
The alert E-mail created by this alert looks like this:
The mail displays the query and the values of the matching result.
And of course: The dashboard will also display the current health state for easy detection:
Costs of the solution
Ok, now its time to speak about costs. How much does this solution it cost?
Everything depends upon the amount of devices and how frequent you whish to collect data. The more frequent, the more text messages you need to send and pay for.
- One time costs
One time costs occur only for purchasing the devices. The DRH-3015 costs about 70 EUR, the RTU-5023 with antenna and power suply around 90 EUR
- Re-occuring (monthly) costs
You need a mobile phone number from Twilio. That will cost 5 USD per Month. Every text message received will charge 0,0075 USD/message. Every text message send will be charged 0,085 USD/message.
- Azure Automation
You can use the free version for this solution. 500 min per month should be enough -> 0 EUR
You can use the free tier for this solution. 500 mb data and 7 days of storage should be enough -> 0 EUR
- Text messages from devices
These costs are hard to calculate, as they depend on how frequently you want to get status messages and/or trigger these. And it depends on your provider. I am using a provider that charges me 4 EUR/month per device (SIM card) for 300 text messages. That would allow me to send 8 status messages every day (every 3h) and some buffer for out-of-band messages.
I calculate with roughly 6 EUR per month and device for in- and outbound text messages and 5 USD for the Twilio number.
So it is time to have a look at my objectives and what I had achieved with this solution:
- Get an alert as quick as possible, when the room temperature fall out of a defined range
The device will send an out-of-band alert message to Twilio that gets translated into a record with HealthState <> "OK" and IsAlertMessage = TRUE. That will trigger an OMS alert.
Additionally I could have created a query that checks, if the TempValue_d property is above/below a certain value.
- Get an alert as quick as possible, when there is a power outage in one of the locations
The device will send an out-of-band alert message to Twilio that gets translated into a record with HealthState <> "OK" and IsAlertMessage = TRUE. I also created a query that checks for devices not sending any data in a certain time frame. So either way I will get an alert, if a device dies.
- Get an overview (dashboard) of the current state of all locations from wherever I might be
See the dashboard above.
- Get an alert whenever one of the monitoring devices in a location dies (malfunction or other issue)
I also created a query that checks for devices not sending any data in a certain time frame. So either way I will get an alert, if a devices dies.
- [Optional] Track the temperature on a very basic level
See the dashboard above.
- [Optional] Track and alert the humidity in the room
See the dashboard above.
- Spent as little time and as little money as possible
Well, that is an interesting question. I spend around 3 days total for testing and developing. From a cost perspective, it is within my personal limits. But to be honest: this solution does not scale well regarding costs. The more frequent I want to collect data from the devices, the more I have to pay...
I really had some fun creating this solution. It is not perfect and I still have ideas for improvement. But hey, we are living in times of agile development, Dev-Ops and SCRUM, so this is my first working release after Sprint 1 :)
Using cloud based services like Azure Automation, OMS and Twilio can create powerful solutions even for guys like me, that are IT-Pro's and not Dev's. I wanted to show you a private use case for these technologies and I hope you liked it.
Feedback is always welcome and I might continue this series, once I implemented more feature. PowerBI integration is already on the horizon :)