Today I am publishing a utility called PingTimeLog. The idea is simple; ping a group of servers and write the response time to Azure Log Analytics. This utility is intended to be run as a Runbook on an Azure Automation Hybrid Worker. Alternatively, it will run as a scheduled task on a server in your datacenter. The output is written to Azure Log Analytics as a custom Type, allowing users to plot response times in a time chart.
But First, Why?
The goal is to view WAN latency between a central data center and remote sites to track SLA and alert if latency falls outside a given range. The draft version wrote data to Azure Table Storage with the intent to use PowerBI to report on the response rate. Turns out, it far easier to log the data to Log Analytics with the Log Analytics HTTP Data Collector API.
I feel compelled to point out that there are a lot of other tools available with more features for monitoring latency on a WAN circuit. PingPlotter is one that comes to mind as a tool that can track more than just response time. One of the goals, however, was write the data to Log Analytics. Logging to Log Analytics allows me to leverage one dashboard to monitor WAN latency along with other infrastructure health indicators. An example of a Ling Chart below That was not an easy option with third party tools. The other factor was price. Most 3rd party tools cost money, but PowerShell, and this utility, is free.
Another reason I created this is to demonstrate Azure features that can be used to monitor an environment. Once logged with the API Data Collector, the data can be charted in the OMS Workspace as a line chart workspace tile. The utility runs as an Azure Automation Runbook on a Hybrid Worker in a central data center. All of these technologies have been covered in different videos I have published. Links to the resources are at the end of this post.
How it Works
Hopefully you will find the utility help, well, helpful. At a high level, it pings a group of servers at a given interval and writes the response time to Log Analytics. This utility needs an Azure Log Analytics workspace to function. If you don’t have a Log Analytics Workspace you are in luck. All the information you need to set one up is here.
There are two inputs for the utility, hours to run and server list. Hours to run set the amount of time the script will continue to run. Default is one hour. With a one hour runtime, the utility will need to be started every hour. This will keep it constantly running and prevent gaps in data. You could set it to run for 24 and have it start start it once a day. However, if there is a problem such as a server restart, you may miss a significant amount of data. Running an hour for an hour will minimize the impact if the job ends prematurely.
The second input is a list of servers. You can pass this to the utility when the script runs or set the default value within the utility. These are the servers or IP’s the utility will ping and report on.
There are two ways to run it, as a scheduled task or on an Azure Automation Hybrid Worker.
Running as a scheduled task does not require an Azure Automation account. Set up the Task Scheduler on the computer you want the ping command to come from. Make sure to match the hours to run with how frequently the utility is started.
Azure Automation Hybrid Worker
An Azure Automation account and a Hybrid Worker at the source location is required for this configuration. The Hybrid Worker has a couple advantages over scheduled tasks such as central job monitoring and the Log Analytics Workspace Key can be secured as an encrypted variable in Azure Automation. As with the scheduled task option, match the hours to run with how frequently the utility is started. Azure Automation will stop scripts that run longer than 3 hours, so keep that in mind when configuring the utility.
Note that this utility will not run in Azure. It uses the Windows Ping command and that is not a valid command when ran in Azure Automation.
The Utility can be found here:
Additional resources here: