Can I disable a component of application Monitor Template?

I'd like to do the same thing. Deployment Health shows I've exceeded the maximum recommended value of SAM elements per poller and I've found that even disabled components count towards this element count. This makes it difficult when we have tons of elements that use IIS and SQL AppInsight. In fact, I have a SQL server that has 100+ databases and it shows that it's got 2862 active components assigned to it. I thought that it was an error, so I removed AppInsight from it, and sure enough, it dropped the element count by that much. I sorted the active components by count and at this point, I need one poller just to cover 8 of our servers that have IIS and SQL AppInsight. 

I have always treated that deployment health page as just some dev's best guess, not the gospel of how to do Orion.  It's not giving you any kind of measurement driven performance analysis and saying these are definitely problems that are impacting your system, its just comparing your data to a collection of hard coded queries with static limits that may or may not have caused problems to some SW customer some time in the past. It seemed to me that whoever built those rules had never actually stress tested a large Orion install in a real world environment.

I've had no problems with beefy pollers running as many as 30k appinsight components. The thing to keep in mind is that many of the components in an appinsight template work by making a single request that returns a whole bunch of data that SAM then breaks apart into dozens or hundreds of components.  Think of, for example, issuing a single query against a DB and getting a whole page of results, versus running hundreds of individual queries requesting one row of data at a time.  The single request has dramatically less overhead on the network connections, which tends to be where the polling engine runs into hard to resolve bottlenecks.  I split out my counts of appinsight components on all my dashboards so I could see what we have in "conventional" components versus how much we have in appinsight. 

The place where you really can understand impact  and SAM health is by tracking the numbers of SAM polling errors that are showing up in your logs.  I used a bunch of different powershell monitors to parse these because for me when things are all polling perfectly then you can handle a ton of components, but once you start piling up a lot of errors then things kind of exponentially get worse because of the built in retry timers.  Orion is basically assuming it will make XX requests per minute, and once you start having to wait for a lot of timeouts and retries you can really wreck that schedule.

A really solid health indicator I used was to track the percentage of my SAM components that were unknown at any given time.  The rule of thumb I had picked  up from my environment was that each component that was misconfigured and can't poll correctly impacts the polling engine at least as much as 5 properly running components.  When that number started to trend up my system suffered issues.

I have always treated that deployment health page as just some dev's best guess, not the gospel of how to do Orion.  It's not giving you any kind of measurement driven performance analysis and saying these are definitely problems that are impacting your system, its just comparing your data to a collection of hard coded queries with static limits that may or may not have caused problems to some SW customer some time in the past. It seemed to me that whoever built those rules had never actually stress tested a large Orion install in a real world environment.

I've had no problems with beefy pollers running as many as 30k appinsight components. The thing to keep in mind is that many of the components in an appinsight template work by making a single request that returns a whole bunch of data that SAM then breaks apart into dozens or hundreds of components.  Think of, for example, issuing a single query against a DB and getting a whole page of results, versus running hundreds of individual queries requesting one row of data at a time.  The single request has dramatically less overhead on the network connections, which tends to be where the polling engine runs into hard to resolve bottlenecks.  I split out my counts of appinsight components on all my dashboards so I could see what we have in "conventional" components versus how much we have in appinsight. 

The place where you really can understand impact  and SAM health is by tracking the numbers of SAM polling errors that are showing up in your logs.  I used a bunch of different powershell monitors to parse these because for me when things are all polling perfectly then you can handle a ton of components, but once you start piling up a lot of errors then things kind of exponentially get worse because of the built in retry timers.  Orion is basically assuming it will make XX requests per minute, and once you start having to wait for a lot of timeouts and retries you can really wreck that schedule.

A really solid health indicator I used was to track the percentage of my SAM components that were unknown at any given time.  The rule of thumb I had picked  up from my environment was that each component that was misconfigured and can't poll correctly impacts the polling engine at least as much as 5 properly running components.  When that number started to trend up my system suffered issues.

This is sage advice and I set the same eyes on unknown counts