The aim of this first challenge is to understand how telemetry is collected from VMs running on Azure. Azure Monitor and the associated sink are leveraged to collect telemetry directly into Azure Monitor for dashboarding and alerting purposes.
Feel free to achieve this objective using the Azure Portal or by modifying the bicep code.
Tip: If you decide to use code think about managed identities and VM extensions.
Understand the concept of counters, how to collect them as well as how to configure Alerts and display them in a Dashboard.
To do that you will have to stress the SQL using HammerDB and collect the DB counter as well as the CPU counters of the VMSS after loading the CPU and display them on a Dashboard.
- Create an empty DB "tpcc" in the SQL server
- Enable the collection of the following counter:
- \SQLServer:Databases(*)\Active Transactions
- Stress the "tpcc" DB using HammerDB. For detailed instructions, see section HammerDB Configuration below.
- Simulate a CPU load on the VM Scale Set using the cpuGenLoadwithPS.ps1
- Pin the metric of the above SQL counter as well as the average VMSS CPU utilization to your Dashboard
- Create an Alert to be notified in case the SQL active transactions went above 40
- Create an Alert to get notified if the average CPU load on the VMSS is above 75%
- Suppress the Alerts over the weekends
Show the dashboard with the metric in it, which should also show a spike representing before and after the DB stress
- HammerDB
- Finding the counter
- In case you will modify the code (keep in mind you need to convert to bicep and match the syntax)
- Converting to bicep and bicep playground
-
From the Visual Studio Server, download and install the latest version of HammerDB
-
Open HammerDB and double click on SQL Server to start configuring the transaction load. In the dialog that opens, click OK.
-
Drill into SQL Server \ TPC-C \ Schema Build and double click on Options
-
Modify the Build Options for the following:
- SQL Server: Name of your SQL Server
- SQL Server ODBC Driver: SQL Server
- Authentication: SQL Server Authentication
- SQL Server User ID: sqladmin
- SQL Server User Password: <password you used during the deployment>
- SQL Server Database: tpcc
- Number of Warehouses: 50
- Virtual Users to Build Schema: 50
**Note: **Setting the last two at 50 should generate enough load to trip a threshold and run long enough for you to graph to show a spike
- Double click on Build and Click Yes to kick of a load test.
When the test is running it should look like the screenshot below:
TIP: If you would like to run a second test you must first delete the database you created and recreate it. HammerDB will not run a test against a database that has data in it. When you run a test is fills the database with a bunch of sample data.
Are you sure? finished trying? ;-) Challenge 2: The solution