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'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. 

Something sounds very off about this, but I'm not sure what. You should be able to get loads of appinsight out of a poller, and they should cap out at 50 components against licensing and what not each.

It DOES seem off, but the numbers match up when I remove the AppInsight for SQL from this one server and then add it back. The AppInsight for SQL template has just over 100 components on it, is it possible that it's counting every single one of those components times the number of individual DBs on that server?

It might depend how your're counting - If it's for license reasons that should read 50, if it's reported right out of the components table, ie how much data, then yeah that'll scale with the amount of DBs for sure

I'm a big fan of the SQL user experience monitor. If you've got a couple metrics you actually care about you can assign just that and it's super lightweight and easy to read by comparison

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

Thats exactly what is happening.  I don't have the exact numbers in front of me, but I know IIS Sites, App Pools, and Database servers when using AppInsight could have stupid numbers of components.  I want to say its somewhere between 20 and 40 components per App Pool/Site/Database.  I have an IIS server in the envirionment that has around 28k components on it.

As Mesverrum mentioned below, AppInsight operates a little different than other SAM monitors.  They are really optimized calls, so its only a couple calls to the server itself that the primary server branches into the individual components.

I've had support tell me on numerous instances that I'm way over polling capacity on my APEs, but once I point out that the majority of what they are seeing is Appinsight, they drop it and we move on with the issue at hand.