DOCS-15178 ftdc failure fatal mongos (#4000) (#4137)

* Docs 15178 ftdc failure fatal mongos (#4000)

* First draft updating mongos/mongod info to state FTDC thread failures are fatal

* Fixed merged content

* Removed self-reference links

* Removed self-reference links

* Removed mention of behavior change from 3.x

* Internal review feedback

* Internal review feedback

* Fixed future tense and latin in main mongod/mongos topics

* Added missing ref

Author: nvillahermosa-mdb

source/administration/analyzing-mongodb-performance.txt

@@ -145,16 +145,11 @@ The following profiling levels are available:
 Full Time Diagnostic Data Capture
 ---------------------------------
 
-To facilitate analysis of the MongoDB server behavior by MongoDB Inc.
-engineers, :binary:`mongod` and :binary:`mongos` processes include a 
-Full Time Diagnostic Data Collection (FTDC) mechanism. FTDC data files 
-are compressed, are not human-readable, and inherit the same file access
-permissions as the MongoDB data files. Only users with access to FTDC 
-data files can transmit the FTDC data. MongoDB Inc. engineers cannot 
-access FTDC data independent of system owners or operators. MongoDB 
-processes run with FTDC on by default. For more information on MongoDB
-Support options, visit
-`Getting Started With MongoDB Support <https://www.mongodb.com/support/get-started?tck=docs_server>`_.
+To help MongoDB engineers analyze server behavior, :binary:`~bin.mongod` and
+:binary:`~bin.mongos` processes include a Full Time Diagnostic Data
+Capture (FTDC) mechanism. FTDC is enabled by default. Due to its
+importance in debugging deployments, FTDC thread failures are fatal and
+stop the parent ``mongod`` or ``mongos`` process.
 
 .. important:: FTDC Privacy
 

source/core/sharded-cluster-query-router.txt

@@ -1,4 +1,3 @@
-
 .. _sharded-cluster-query-routing:
 .. _sharding-read-operations:
 
@@ -15,21 +14,21 @@ mongos
    :class: singlecol
 
 MongoDB :binary:`~bin.mongos` instances route queries and write operations
-to :term:`shards <shard>` in a sharded cluster. :binary:`~bin.mongos` provide the
+to :term:`shards <shard>` in a sharded cluster. ``mongos`` provides the
 only interface to a sharded cluster from the perspective of
 applications. Applications never connect or communicate directly with
 the shards.
 
-The :binary:`~bin.mongos` tracks what data is on which shard by caching
+The ``mongos`` tracks what data is on which shard by caching
 the metadata from the :ref:`config servers
-<sharded-cluster-config-server>`. The :binary:`~bin.mongos` uses the
+<sharded-cluster-config-server>`. The ``mongos`` uses the
 metadata to route operations from applications and clients to the
-:binary:`~bin.mongod` instances. A :binary:`~bin.mongos` has no *persistent*
+:binary:`~bin.mongod` instances. A ``mongos`` has no *persistent*
 state and consumes minimal system resources.
 
-The most common practice is to run :binary:`~bin.mongos` instances on the
+The most common practice is to run ``mongos`` instances on the
 same systems as your application servers, but you can maintain
-:binary:`~bin.mongos` instances on the shards or on other dedicated
+``mongos`` instances on the shards or on other dedicated
 resources.  See also :ref:`sharded-cluster-components-distribution`.
 
 Routing And Results Process
@@ -43,51 +42,45 @@ cluster>` by:
 
 #. Establishing a cursor on all targeted shards.
 
-The :binary:`~bin.mongos` then merges the data from each of the
+The ``mongos`` then merges the data from each of the
 targeted shards and returns the result document. Certain
 query modifiers, such as :ref:`sorting<sharding-mongos-sort>`,
-are performed on each shard before :binary:`~bin.mongos` 
+are performed on each shard before ``mongos`` 
 retrieves the results.
 
-.. versionchanged:: 3.6
-
-   For :ref:`aggregation operations <aggregation-pipeline>` that
-   run on multiple shards, if the operations do not require running on
-   the database's :term:`primary shard`, these operations may route the
-   results back to the :binary:`~bin.mongos` where the results are then
-   merged.
+:ref:`Aggregation operations <aggregation-pipeline>` running on multiple
+shards may route results back to the :binary:`~bin.mongos` to merge results if they don't need to run on the database's :term:`primary shard`.
 
-   There are two cases in which a pipeline is ineligible to run on
-   :binary:`~bin.mongos`.
+There are two cases in which a pipeline is ineligible to run on
+:binary:`~bin.mongos`.
 
-   The first case occurs when the merge part of the split pipeline
-   contains a stage which *must* run on a primary shard. For instance,
-   if ``$lookup`` requires access to an unsharded collection in the same
-   database as the sharded collection on which the aggregation is running,
-   the merge is obliged to run on the primary shard.
-
-   The second case occurs when the merge part of the split pipeline
-   contains a stage which may write temporary data to disk, such as
-   ``$group``, and the client has specified ``allowDiskUse:true``. In this
-   case, assuming that there are no other stages in the merge pipeline
-   which require the primary shard, the merge will run on a
-   randomly-selected shard in the set of shards targeted by the
-   aggregation.
-
-   For more information on how the work of aggregation is split among
-   components of a sharded cluster query, use ``explain:true`` as a
-   parameter to the :method:`~db.collection.aggregate()` call. The
-   return will include three json objects. ``mergeType`` shows where the
-   stage of the merge happens ("primaryShard", "anyShard", or "mongos").
-   ``splitPipeline`` shows which operations in your pipeline have run on
-   individual shards. ``shards`` shows the work each shard has done.
+The first case occurs when the merge part of the split pipeline
+contains a stage which *must* run on a primary shard. For instance,
+if ``$lookup`` requires access to an unsharded collection in the same
+database as the sharded collection on which the aggregation is running,
+the merge is obliged to run on the primary shard.
+
+The second case occurs when the merge part of the split pipeline
+contains a stage which may write temporary data to disk, such as
+``$group``, and the client has specified ``allowDiskUse:true``. In this
+case, assuming that there are no other stages in the merge pipeline
+which require the primary shard, the merge runs on a
+randomly-selected shard in the set of shards targeted by the aggregation.
+
+For more information on how the work of aggregation is split among
+components of a sharded cluster query, use ``explain:true`` as a
+parameter to the :method:`~db.collection.aggregate()` call. The
+return includes three json objects. ``mergeType`` shows where the
+stage of the merge happens ("primaryShard", "anyShard", or "mongos").
+``splitPipeline`` shows which operations in your pipeline have run on
+individual shards. ``shards`` shows the work each shard has done.
 
 In some cases, when the :term:`shard key` or a prefix of the shard key
 is a part of the query, the :binary:`~bin.mongos` performs a
 :ref:`targeted operation<sharding-mongos-targeted>`, routing queries to
 a subset of shards in the cluster.
 
-:binary:`~bin.mongos` performs a :ref:`broadcast
+``mongos`` performs a :ref:`broadcast
 operation<sharding-mongos-broadcast>` for queries that do *not* include the
 :term:`shard key`, routing queries to *all* shards in the cluster. Some
 queries that do include the shard key may still result in a broadcast
@@ -97,9 +90,9 @@ selectivity of the query.
 See :ref:`sharding-query-isolation` for more on targeted and
 broadcast operations.
 
-Starting in MongoDB 4.4, :binary:`~bin.mongos` can support :ref:`hedge
-reads <mongos-hedged-reads>` to minimize latencies. See :ref:`hedge
-reads <mongos-hedged-reads>` for more information.
+``mongos`` can support :ref:`hedged reads <mongos-hedged-reads>` to
+minimize latencies. See :ref:`hedged reads <mongos-hedged-reads>` for
+more information.
 
 How ``mongos`` Handles Query Modifiers
 --------------------------------------
@@ -131,7 +124,7 @@ from the shards and skips the appropriate number of documents when assembling
 the complete result.
 
 When used in conjunction with a :method:`~cursor.limit()`, the
-:binary:`~bin.mongos` will pass the *limit* plus the value of the
+:binary:`~bin.mongos` passes the *limit* plus the value of the
 :method:`~cursor.skip()` to the shards to improve the efficiency of these
 operations.
 
@@ -366,6 +359,11 @@ fCV Compatibility
 
 .. include:: /includes/fact-mongos-fcv.rst
 
+Full Time Diagnostic Data Capture Requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. include:: /includes/fact-mongod-mongos-ftdc-thread.rst
+
 
 Connection Pools
 ~~~~~~~~~~~~~~~~

source/includes/fact-mongod-mongos-ftdc-thread.rst

@@ -0,0 +1,7 @@
+:binary:`~bin.mongod` includes a :ref:`Full Time Diagnostic Data Capture
+<ftdc-stub>` mechanism to assist MongoDB engineers with troubleshooting
+deployments. If this thread fails, it terminates the originating process.
+To avoid the most common failures, confirm that the user running the
+process has permissions to create the FTDC ``diagnostic.data``
+directory. For ``mongod`` the directory is within
+:setting:`storage.dbPath`. For ``mongos`` it is parallel to :setting:`systemLog.path`.