- 1 Hi, Jonas here!
- 2 TL;DR
- 3 A baseline as a starting point:
- 4 The setup options:
- 5 Log Analytics agent setup:
- 6 Defining the baseline
- 7 Sizing estimates
- 8 List of useful performance counters
- 9 Data visualization
- 10 Data preview:
- 11 Alerting and monitoring:
- 12 Conclusion:
- 13 Disclaimer:
- 14 Resources:
Hi, Jonas here!
Or as we say in the north of Germany: “Moin Moin!”
I am a Customer Engineer based in Germany and I recently played a bit with Azure Log Analytics (now called Azure Monitor) and the on-premises monitoring capabilities and I want to show you, how easy it is to monitor your own MECM / ConfigMgr environment.
If you ever saw performance problems in your ConfigMgr environment and if you are interested in an easy way to create a ConfigMgr performance baseline, this is the right article for you. I am explaining the concept and setup and provide a list of useful performance counters in the: “List of useful performance counters” section below.
Analyzing the gathered data will be a topic for a next article though, but you will be able to output something like shown in the picture below:
A baseline as a starting point:
When you encounter a performance issue in you environment you might not be able to tell if that is just the result of a normal increase in usage and you simply need more CPU or RAM or if what you encounter is an anomaly were you need to find the root cause to be able to get back to normal without the extra need for resources.
A baseline can help you answer this very basic question and then act before the real problem starts.
So, if you have gathered data for about a month or so and you see something like this:
You have your baseline with some ups and downs, and you should be able to tell, if the next performance decrease is just a normal increase in usage (as shown in the left picture below) or an anomaly which you need to analyze and fix (as shown in the right picture below). (A very simplified graphic visualization)
The setup options:
As mentioned before, I am using Azure Monitor/Azure Log Analytics to monitor my on-premises environment and Log Analytics gives me two options to send data to the Log Analytics service.
You can either send the data directly from the monitoring agent (running on the local machine) to Azure Log Analytics (see option 1 below) or use the Azure Log Analytics Gateway if not every machine has direct access to the internet (see option 2 below).
You can find the documentation here: LINK
Option 1: Direct connection:
Option 2: Log Analytics Gateway:
Log Analytics agent setup:
Since my machines have direct access, I simply installed the Log Analytics agent on them and used option 1 (see above) to send performance data to my workspace and I followed the following steps:
Step 1: Create Log Analytics workspace
All you need is an Azure Subscription where you can create an Azure Log Analytics workspace. The steps are documented here: Create workspace
Step 2: Install Log Analytics agent
Go to your new Log Analytics workspace and click on “Agents management” to download the Log Analytics agent to the machines you would like to monitor.
During the agent setup select “Connect the agent to Azure Log Analytics (OMS)” and click “Next”.
On the next page you need to copy and paste the “Workspace ID” and the “Primary Key” from the “Agents management” site we used earlier to point the agent to the correct workspace. If you need to set up a proxy for the connection, you can do this via the “Advanced” button.
Step 3: Verify connectivity
You can find the installed “Microsoft Monitoring Agent” in Control Panel under “System and Security”. (you will find multiple names for the agent in the documentation)
On the “Azure Log Analytics (OMS)” tab you can verify the successful connection to you Log Analytics workspace:
If you go back to the “Agents management” site in your Log analytics workspace, you can click on “Go to logs” to verify the successful connection of your agents.
You should be redirected to the “Logs” section, where the following query should output your connected machines.
Keep in mind that it can take a minute for the first data to show up and you might need to click on “Get started” if you see the page for the first time:
If not, go to “Logs” and run the following query:
| where OSType == ‘Windows’
| summarize arg_max(TimeGenerated, *) by SourceComputerId
| sort by Computer
| render table
Defining the baseline
All you have to do is to add the needed performance counters and let the agent gather the data.
Go to “Advanced settings” in your “Log Analytics workspace“ and click on “Data”, “Windows Performance Counters” and add the counters you like with the plus sign:
For most default counters you can simply use the search box next to the plus sign and add them, but what if we need to add some counters not in the list, the ConfigMgr counters for example?
I wrote a little script called “Get-PerfCounterList.ps1” to help you find the correct counter names and be able to easily copy and paste them into Log Analytics.
The script can be downloaded here: LINK
IMPORTANT: Run the script as an administrator on the machine you want to monitor with Log Analytics, otherwise only a subset of counters might be visible.
The output is a simple grid view showing you all the available performance counters on the machine.
And if you filter for “SMS” for example, you get a list of the ConfigMgr counters and the path you need for Log Analytics.
All you have to do is to choose the counter you like to monitor and copy the path into the counter search field in Log Analytics and hit the plus sign to add the counter to the list.
If there are multiple instances available (as shown in the screenshot above via the green arrows) you can select multiple counters in the grid view and click on “OK” to get another grid view of those specific instances and the correct path names:
The script is also helpful if you use a named instance to store your ConfigMgr SQL DB, because you then need the exact name of the performance counter.
Since I am using a SQL instance called “INST01”, my counters look like this for example: “MSSQL$INST01:Memory…” instead of “SQLServer:Memory…”:
As mentioned before, simply copy and paste the counter you like into the search bar and click on the plus sign next to it:
I added the “SMS Inbox(*)File Current Count” counter in my example and since the counter will only be refreshed every 15 minutes locally, I set the sample interval to 900 seconds.
Since the counter has 32 instances and each instance will have an entry in Log Analytics, the higher sample interval will limit the data which needs to be stored in Log Analytics.
(At the time of writing the maximum sample interval was 1800 seconds (30 minutes))
When you are done adding all the needed counters, click on “Save” and the counter configuration will automatically be sent to every connected agent.
The actual amount of data stored in Log Analytics depends on the sample interval per counter, the number of counters, the number of instances per counter and the number of agents sending data to the workspace.
Use the script mentioned above to see how many instances each counter has and check if each instance is needed or if just a subset is enough to get the baseline you need and adjust the sample interval to save storage space if needed.
You will find more details about that topic in the Log Analytics documentation:
List of useful performance counters
I will not explain every counter in detail, because that would be an article on its own, instead I will add some notes to some of them, if I feel that’s important to the baseline for ConfigMgr.
It is also not a complete list of counters, but the list should give you the most useful data for your baseline.
Use the search term: “Windows Performance Counters Explained” to find resources about the counters and how they are helpful.
Operating System related:
LogicalDiskAvg. Disk sec/Read
LogicalDiskAvg. Disk sec/Write
LogicalDiskCurrent Disk Queue Length
Memory% Committed Bytes In Use
Network AdapterBytes Received/sec
Network AdapterBytes Sent/sec
Network InterfaceBytes Total/sec
Processor(_Total)% Processor Time
SystemProcessor Queue Length
SQL Server related:
SQLServer:Access MethodsFull Scans/sec
SQLServer:Access MethodsIndex Searches/sec
SQLServer:Access MethodsIndex Searches/sec
SQLServer:Access MethodsTable Lock Escalations/sec
SQLServer:Access MethodsIndex Searches/sec
SQLServer:Buffer ManagerFree pages
SQLServer:Buffer ManagerLazy writes/sec
SQLServer:Buffer ManagerPage life expectancy
SQLServer:Buffer ManagerStolen pages
SQLServer:Buffer ManagerTarget pages
SQLServer:Buffer ManagerTotal pages
SQLServer:Locks(*)Number of Deadlocks/sec
SQLServer:Memory ManagerMemory Grants Outstanding
SQLServer:Memory ManagerMemory Grants Pending
SQLServer:Memory ManagerTarget Server Memory (KB)
SQLServer:Memory ManagerTotal Server Memory (KB)
SQLServer:Plan Cache(Object Plans)Cache Object Counts
SQLServer:Plan Cache(SQL Plans)Cache Object Counts
SQLServer:Plan Cache(Object Plans)Cache Pages
SQLServer:Plan Cache(SQL Plans)Cache Pages
SQLServer:SQL StatisticsBatch Requests/sec
SQLServer:SQL StatisticsSQL Compilations/sec
SQLServer:SQL StatisticsSQL Re-Compilations/sec
SQLServer:Wait Statistics(*)Memory grant queue waits
SQLServer:Wait Statistics(*)Network IO waits
SQLServer:Wait Statistics(*)Page latch waits
SQLServer:Wait Statistics(*)Wait for the worker
SMS Inbox(*)File Current Count (will only be updated every 15 minutes locally)
SMS Outbox(*)File Current Count (will only be updated every 15 minutes locally)
SMS AD Group DiscoveryDDRs generated/minute
SMS AD System DiscoveryDDRs generated/minute
SMS Discovery Data ManagerUser DDRs Processed/minute
SMS Inventory Data LoaderMIFs Processed/minute
SMS Software Inventory ProcessorSINVs Processed/minute
SMS Software Metering ProcessorSWM Usage Records Processed/minute
SMS State SystemMessage Records Processed/min
SMS Status Messages(*)Processed/sec
Web Service(*)Bytes Sent/sec
Web Service(*)Bytes Received/sec
To analyze the gathered data, got to your Azure Log Analytics workspace and click “Logs” (1).
The actual data is stored in the “Perf” table (2) under “LogManagement” and can be queried via the query window (3) using KQL (Kusto Query Language).
In my example, the output is a “timechart” (4), but it can be any type of output Azure Log Analytics is capable of.
The query I am using is just an example, because analyzing the data is a topic on its own and might be worth another article.
Other example queries can be found here: LINK
By clicking on the preview icon (see below) you will get a result set with 10 entries back, which helps to explore the gathered data and to finetune your KQL queries:
Alerting and monitoring:
You can create alerts and send out notifications when certain criteria are met, like CPU is at 90% for the last 15 minutes, or a ConfigMgr inbox has over 1000 files in it for the last hour or so and you have the ability to use multiple reporting features to visualize the data like, Azure Monitor Workbooks, Azure Portal Dashboards or PowerBI reports.
I will not explain those topics in this article, since each part would be a topic for its own article. Instead I provide you with a list of links to the documentation if you want to start right away:
Azure Portal dashboards: LINK
Azure Monitor Workbooks: LINK
PowerBI reports: LINK
Azure Log Analytics / Azure Monitor gives you an easy way of gathering performance data and building your ConfigMgr performance baseline and with KQL and the Alerting feature you have powerful tools to analyze the data and generate alerts when needed.
Have fun monitoring your environment and let me know what you think
This posting is provided “AS IS” with no warranties, and confers no rights
Windows and Linux performance data sources in Azure Monitor:
Azure Monitor pricing:
Create a Log Analytics workspace in the Azure portal:
Log Analytics agent overview:
Azure Portal dashboards:
Azure Monitor Workbooks: