About Supportability of SCOM APM Agent by SharePoint Products

For SharePoint 2013, SharePoint 2013 is in “extended support” state. Any integration of newer version of SCOM agent is out of support for SharePoint supportability perspective.
Microsoft strongly suggest upgrade to the most recent version of Sharepoint which is “SharePoint Server 2019”.
Supportability options are also available for SharePoint 2016 with builds of May CU 2018 or higher.

Please check the product life cycle
https://support.microsoft.com/en-us/lifecycle/search/935

Since November 2018, SCOM 2016 APM agent with UR6 or higher builds are supported using with Sharepoint 2016 and SharePoint 2019.
More information about Update Rollup 6 (UR6) for SCOM 2016

https://kevinholman.com/2018/10/31/ur6-for-scom-2016-step-by-step/

Be aware that SCOM build number versus Monitoring Agent version is different things.

https://buildnumbers.wordpress.com/scom/

https://blogs.technet.microsoft.com/kevinjustin/2018/09/06/mma-agent-and-scom-agent-version-numbers/

Using earlier version SCOM 2012  (including SP1 , R2 )  APM agent with any SharePoint product is “Not supported”. Because the necessary fixes are not implemented on this version.
Again SCOM product compoents may use without APM agent.

Most of the SCOM APM and SharePoint problems also related with .NET version that in use. It is impossible to test for every scenarios and builds.
Which causes limited supportability options most of the scenarios.

Our main supportability approach for Sharepoint;

Any kind of 3rd party profiler or Microsoft based profilers (which is also considered 3rd party for SharePoint perspective) we have only “Limited Support” and “Not recommended”
(If the products are in supported builds otherwise it is “not supported” at all)

For Microsoft based (like APM) or 3rd party (.NET) profilers (where injects their binaries inside IIS worker processes and intercept executions in several points) is “not recommended” with SharePoint production envrionment.
Still they may be useful for pre-production to test and verify custom solution behaviours with in “Limited Support”.

SharePoint have highly complex implementation with IIS and ASP.NET which profiler may cause extra overhead and abnormalities.

SharePoint core works on native code and mostly wraps with .NET wrappers and do heavy interops which mostly .NET profilers useless for monitoring the core and very open to causes abnormalities and may crashes.

Profilers causes extra overhead already on SharePoint which is already a heavy product.

Sharepoint with combined .NET , ASP.NET and OS system has more than enough performance counters for profiling and monitoring perspective.

Profilers may mask underlying problems or hardining troubleshooting for deepdive analysis like dumps and memory traces, that increases our problem resolution times and may cause misleading directions.
Microsoft Support team mostly request to remove/uninstall the 3rd party profiler for before working related scenarios.

In Summary,

Use as much as possible for monitoring or profiling purposeses already provided performance counters by the SharePoint, .Net and OS System.
Avoid any kind of binary injecting codes/profilers inside worker processes where SharePoint runs for specially production environments.