Mr. Twardowski, known in literature, forced the devil to bathe in holy water. As we read: "he bathed the poor man up to his neck." In a similar situation we can put Operations Manager via the appropriate Powershell command.
Reviewing the Operations Manager log, you can sometimes come across event 26373:
Trying to look for where this message comes from and how it arrives is difficult, as we don't have many clues in the message itself. The number of records and the TypeId parameter indicate that someone (or something) is trying to retrieve all the monitored objects (every monitored object regardless of its class comes from System.Entity).
If the message appears systematically (cyclically), it can be assumed that there is a monitoring-related mechanism that triggers the message. Sometimes, however, it is a testimony to the activity of users of the monitoring system running Powershell commands related to Operations Manager.
As particularly "meritorious" here is the command Get-SCOMMonitoringObject, which, given without parameters, usually produces this effect. However, this is not the case on small laboratory instances of Operations Manager, where you can, for example, call a command with complete impunity: (Get-SCOMMonitoringObject).count
The Get-SCOMMonitoringObject command itself dates back to Operations Manager 2007 and is now just an alias for the command Get-SCOMClassInstance. This can be seen, if only by comparing the results:
PS C:\> (Get-SCOMClassInstance).count
652
PS C:\> (Get-SCOMMonitoringObject).count
652
Of course, the ultimate argument here is to check:
PS C:³> Get-Command Get-SCOMMonitoringObject |fl
DisplayName : Get-SCOMMonitoringObject
CommandType : Alias
Definition : Get-SCOMClassInstance
ReferencedCommand : Get-SCOMClassInstance
ResolvedCommand : Get-SCOMClassInstance
The effect described above can occur in the form of cyclic entries in the Operations Manager log if a performance rule is triggered "Approved.System.Center.Operations.Manager.2016.Performance.Monitoring.GetSCOMMonitoringObject.PowerShell.Script.Perf.Rule," found in the "System Center Operations Manager 2012 R2 Performance Monitoring" Management Pack.
Of course, this rule is disabled by default, so it won't cause a rash of 26373 messages until it is enabled via Override.