Add cardinality tips to FAQ and sqlserver input (#6852)

docs/FAQ.md

@@ -43,6 +43,33 @@ If running as a service add the environment variable to `/etc/default/telegraf`:
 GODEBUG=netdns=cgo
 ```
 
+### Q: How can I manage series cardinality?
+
+High [series cardinality][], when not properly managed, can cause high load on
+your database.  Telegraf attempts to avoid creating series with high
+cardinality, but some monitoring workloads such as tracking containers are are
+inherently high cardinality.  These workloads can still be monitored, but care
+must be taken to manage cardinality growth.
+
+You can use the following techniques to avoid cardinality issues:
+
+- Use [metric filtering][] options to exclude unneeded measurements and tags.
+- Write to a database with an appropriate [retention policy][].
+- Limit series cardinality in your database using the
+  [max-series-per-database][] and [max-values-per-tag][] settings.
+- Consider using the [Time Series Index][tsi].
+- Monitor your databases using the [show cardinality][] commands.
+- Consult the [InfluxDB documentation][influx docs] for the most up-to-date techniques.
+
+[series cardinality]: https://docs.influxdata.com/influxdb/v1.7/concepts/glossary/#series-cardinality
+[metric filtering]: https://github.com/influxdata/telegraf/blob/master/docs/CONFIGURATION.md#metric-filtering
+[retention policy]: https://docs.influxdata.com/influxdb/latest/guides/downsampling_and_retention/
+[max-series-per-database]: https://docs.influxdata.com/influxdb/latest/administration/config/#max-series-per-database-1000000
+[max-values-per-tag]: https://docs.influxdata.com/influxdb/latest/administration/config/#max-values-per-tag-100000
+[tsi]: https://docs.influxdata.com/influxdb/latest/concepts/time-series-index/
+[show cardinality]: https://docs.influxdata.com/influxdb/latest/query_language/spec/#show-cardinality
+[influx docs]: https://docs.influxdata.com/influxdb/latest/
+
 ### Q: When will the next version be released?
 
 The latest release date estimate can be viewed on the

plugins/inputs/sqlserver/README.md

@@ -109,7 +109,14 @@ The new (version 2) metrics provide:
 - *Server properties*: Number of databases in all possible states (online, offline, suspect, etc.), cpu count, physical memory, SQL Server service uptime, and SQL Server version. In the case of Azure SQL relevent properties such as Tier, #Vcores, Memory etc.
 - *Wait stats*: Wait time in ms, number of waiting tasks, resource wait time, signal wait time, max wait time in ms, wait type, and wait category. The waits are categorized using the same categories used in Query Store.
 - *Schedulers* - This captures sys.dm_os_schedulers.
-- *SqlRequests* - This captures a snapshot of dm_exec_requests and dm_exec_sessions that gives you running requests as well as wait types and blocking sessions
+- *SqlRequests* - This captures a snapshot of dm_exec_requests and
+  dm_exec_sessions that gives you running requests as well as wait types and
+  blocking sessions.
+
+  In order to allow tracking on a per statement basis this query produces a
+  unique tag for each query.  Depending on the database workload, this may
+  result in a high cardinality series.  Reference the FAQ for tips on
+  [managing series cardinality][cardinality].
 - *Azure Managed Instances*
   - Stats from `sys.server_resource_stats`:
     - cpu_count
@@ -165,3 +172,5 @@ The following metrics can be used directly, with no delta calculations:
 Version 2 queries have the following tags:
 - `sql_instance`: Physical host and instance name (hostname:instance)
 - database_name:  For Azure SQLDB, database_name denotes the name of the Azure SQL Database as server name is a logical construct.
+
+[cardinality]: /docs/FAQ.md#user-content-q-how-can-i-manage-series-cardinality