The new Azure Monitor Agent, is available for preview in the Azure Portal, lets have a look at how to configure data collection for this new experience.
If the Azure Monitor blade there are a couple of changes, we’re interested in the new option called Data Collection Rules this is how we’ll tell out new agent what data to collect.
Clicking new we can see there’s a few tabs to configure, under Basics, we need to name our rule, choose a subscription and resource group.
Next we need to choose the Virtual Machines we can to add to the rule, this will also deploy the agent to the VM if necessary. Note that due to the agent being in preview that it is not available in all regions currently.
Below the selected machines are all set and ready to go.
Finally we need to configure what this rule is collecting, you can choose logs or metrics and you can be more granular then before when it comes to log collection with a custom filter.
You can also have log and metrics collections in the same rule.
Once everything is configured simply click create, the agent will be deployed if necessary and the collection will start.
I encountered a minor issue today which luckily proved simple to solve. Hopefully this proves useful to others.
In a brand new SCOM 2019 deployment the scheduled reports weren’t sending. After investigation I found the below error in the Application log on the SSRS server:
SQL Server Scheduled Job ’62A9826E-082B-4ACD-9270-6BC13FC260BE’ (0x832F33183531EF4483665BBBFCCEBD9A) – Status: Failed – Invoked on: 2020-08-05 11:00:00 – Message: The job failed. Unable to determine if the owner (DOMAIN\USER) of job 62A9826E-082B-4ACD-9270-6BC13FC260BE has server access (reason: Could not obtain information about Windows NT group/user ‘DOMAIN\USER’, error code 0x5. [SQLSTATE 42000] (Error 15404)).
The SSRS Instance, in this case SQL 2016 SP2, was deployed using system accounts for the SQL Server and SQL agent services. Simply changing these to use a domain account with access to the SQL instance resolved the issue and reports started sending shortly after.
Let me start by saying that this news is really exciting, as any one in the monitoring world can tell you SCOM has faced a little bit of uncertainty in the past and the announcement of an upcoming SCOMaaS offering from Microsoft sends a clear message that the product has a place in the companies future.
Not a lot of information is available yet but here’s what we do know:
For starters the solution will be containerized which will leverage all of the benefits of containers such as speed of deployment and scaling to name a few.
A SCOM administrator will be able to “lift & shift” their existing SCOM environment into Azure – Aakash Basavaraj Program Manager for the SCOM Team at Microsoft.
This bodes well for existing SCOM customers as it means that the ability to easily migrate to a SCOMaaS solution will be available and that they won’t have to set up their new platform from scratch. This really shows that Microsoft has given thought and care towards truly bringing SCOM to the cloud.
When will is be available?
Unfortunately no details are available yet around timelines or pricing, I know I’ll be watching this develop with keen interest. One thing is for certain SCOM and Azure Monitor are now more firmly hand in hand then ever before.
It’s quite a common ask, as to how to take the data in an Azure Monitor Logs workspace and create a report that can then be scheduled. Lets take a look at how we can achieve that.
Immediately we are talking about automation when we use the word schedule and Azure has several tools which we can use. The best fit in this case is Logic Apps.
In this example we will create a report showing if any agents haven’t had a successful heartbeat in the past 24 hours.
Navigate to the Logic Apps blade in your Azure Portal and click +Add
Populate the fields selecting my subscription and resource group, creating a new RG if necessary. Then I’ll give my logic app a name and choose my Azure region and click Review + Create and then Create
Once the deployment is complete I can navigate to the resource and it automatically opens the Logic Apps Designer. Now every Logic App needs to start with a trigger and because I want to run a schedule I am going to use Recurrence
I want this on a daily basis so I’m going to enter 24 Hour as my parameters and then click new step
Search for Run Query and Visualize Results as this option will allow a KQL query as a parameter and the results can be manipulated in a variety of ways. Make sure to select the one for Azure Monitor Logs and not for Azure Data Explorer.
You will need to sign in to create a connection with Azure Monitor Logs. Now populate the fields choosing the subscription, resource group and workspace that contains the data you want to use in your report. Put your query in the relevant section and choose chart type HTML.
| project TimeGenerated, Computer
| where TimeGenerated < now()
| summarize ["Last Heartbeat"]=max(TimeGenerated) by Computer
| where ["Last Heartbeat"] < ago(24h)
The last thing that needs to be done is connect the logic app to a step to send email, click New Step, search for send an email, I’ll be using Office365 but you can use other providers. Select Send an email v2 and sign in to create the connection.
Populate as below making sure to include the attachments
Click save and we’re all good to go. Now test by clicking Run.
You should receive an email with an attachment and voila opening it will have a nice html table with our query results.
These steps can be easily replicated and amended to be used for any number of handy reports using your Azure Monitor Logs data.
The latest Update Rollup for SCOM 2016 is out, you can get it here
A decent update fixing a couple of issues that have been around for a while. As always test before applying to your production environments.
What’s new and fixed?
Fixed: On Windows Computer View of SCOM Console, Queries are optimized for better performance.
Fixed: We have updated SPROC to handle Alert Source Path Names which are greater than 512 in length. It was a mismatch where the table which was populating the DB was allowing larger strings while the table which was populated in this view took only 512. This caused data truncation and subsequently console crash.
Fixed: Made changes to the IP address parameter to support both IPv4 and IPv6 windows cluster.
Fixed: Fixed the issue with conversion of data smaller than 0.01 which was generated by Rule or Monitor. The data was transformed to a wrong (big) value on systems with OS locale language which has comma (“,”) instead of dot (“.”) as decimal format.
Fixed: Fixed the schedule reports through the Schedule Management Wizard in APM AppAdvisor. Previously, it was failing with XML Malformed exception.
Fixed: In a scenario where SCOM monitors 100s of virtual machines hosted on a single Hyper-v server; every hour the MonitoringHost.exe of each Virtual machine write into the VM page file simultaneously. Due to this concurrent paging, every hour disk I/O increases and database becomes unresponsive. HealthService.exe now have Memory Trimming enabled by default on an hourly schedule. A registry key is provided to disable the memory trimming and control the duration.
Registry key is: “HKLM\Software\Microsoft\Microsoft Operations Manager\3.0\Setup\MonitoringHost\MemoryTrimming“Enable – 0 (Trimming is disabled); 1 (trimming is enabled)DelayInSeconds – Time period agent waits to start trimming (default is 120s)PeriodInSeconds – Recurring period at which the working set should be trimmed (default is 3600s)
Fixed: Downtime duration will be calculated correctly for non-US time format in Downtime Report.
Fixed: fn_MPVersionDependentId creates an ID for each installed MP. The ID is a SHA1 hash of string “MPName, Version, Schema”. When the “Schema” part is omitted, it generates different hash which doesn’t match with the expected value. In the fix, “Schema=2” part is re-added in fn_MPVersionDependentId.
Fixed: We have made sure that correct end date for Availability, Health and Performance Details are shown in reports
Enabled support for MSOLEDBSQL driver so that users may move from SQL Native Client.